Date: Fri, 07 Mar 1997 14:32:33 -0500 From: Brian McGovern <bmcgover@cisco.com> To: terry@lambert.org, hackers@freebsd.org Subject: Cyclom Card Message-ID: <199703071932.OAA03741@bmcgover-pc.cisco.com>
next in thread | raw e-mail | index | archive | help
>> Ok. Hopefully the last question for this morning. Still using >> my 460K Cyclom card. The question is, should I use RAM on the >> card for the serial buffers, using the interrupt routine to >> copy the data from the card to the tty routines, or set the >> driver up to use Bus Mastering to write to buffers inside the >> kernel dataspace, then use the interrupt handler to shove the >> data in the buffers in to the tty routines? Or, is there a >> better way to be able to move blocks of data at a time in to >> the tty routines for processing? > >I think you should use the RAM on the card so that delays servicing >the interrupts (which will be lower priority for SIO than for some >other devices which may also be active) will not affect your ability >to keep up with the data stream. > Ok, I'll buy that, even though the UARTs on the board themselves have like 16 byte FIFOs, it makes sense for longer interrupts. >The problem with using the bus mastering DMA (which I assume will >also generate an interrupt to signal when the transfer is complete) >is that bus mastering DMA may need to be bounced if there is an ISA >version of this card, or if there is an EISA version and you are >using a not-quite-EISA motherboard or chipset. > There is no ISA version of the card (nor will there be). Interrupts on the card is an interesting issue. It will generate the interrupt when the buffer is almost full (even if its on the host... It uses a ring buffering scheme, so if the head and tail get too close - poof - an interrupt), or when data has been received and a reasonable amount of time has passed (with no new data coming in) >The DMA issue, even if this is going to always be a PCI driver and >is therefore immune to bounce requirements, is that the buffer >allocation will have to occur prior to the transfer setup, way >before the card initiates the transfer. This could, potentially, >hold a lot of buffers hostage if you used standard buffers. > Since it uses a ring buffering scheme, even to the host, I suspect it'll move no more bytes than whats available in the buffer, so "locking" the buffers shouldn't be an issue. Also, each port on the board will only use one buffer. >If you intend to preallocate wired memory for the DMA, and do your >own transfer to the tty buffer, then using DMA is probably not a bad >thing; however, you are back to the interrupt processing latency >issue, unless you can guarantee split top/bottom processing for the >interrupts (if you can, then you can double your DMA buffer requirements >and set up the second DMA after the first completes, as long as you >guarantee to treat the transfer from the first DMA to tty buffer as >high enough priority that the second buffer won't be completed and >retarget the first DMA buffer before the first DMA buffer has drained. >Right now, there are not a lot of top/bottom drivers in FreeBSD. > >A second issue for a smart card, if this is a smart card, is that >you can actually move some of the cannonical processing off to the >card itself, and use an IPC facility (which you define) to modify the >contents of the tty structs onthe card. Whether this is useful >really depends on your primary use: if this is an async serial card >driving terminal or modems, as opposed to a sync serial card driving >high speed links, then it's useful to colocate the tty structs like >this. Most major serial board vendors (Computone, Intelliport, Arnet, >et. al.) have historically done this for smart cards to offload the >host processor, and to let them have features like "transarent printing" >which only becomes active in the ground state of the attached terminal. >Unlike VMS systems, unless you have an automaton on the host system >(most times on board the smart card), you can't tell if you are in >the middle of an escape sequence or not, with disasterous results for >secondary channles for transparent print, terminal mice for POS systems, >bar code readers, etc.. > This card is definately a smart card. My hopes were to set up larger buffers on the host system (or find some way to plug the DMA directly in to the tty routines), and have the card use these as transmit and receive buffers. Then, on an interrupt (probably RX highwatermark/data in buffer w/no new data coming in), I'd read the buffer in to the TTY routines. On a TX buffer low water mark/empty interrupt, I'd get some more waiting characters out of the tty buffer, and in to the TX buffer. Again, if I could tie the latter right in to the tty buffers, all the better. I'm not quite sure I understand your reference to top/bottom drivers. I suspect my driver would conform to this (?), as read/write routines would dump the info in to and out of the tty buffering scheme (so I can use all the line disciplines). Then, I'd have an interrupt handler (and a tweak in the write routine to get things started on the first write) that shuffled data to/from the tty routines to the card's buffers. IOCTL calls would manipulate the tty structures on the cards (which are different than the BSD tty structures), and then send down the appropriate hardware commands to get the card to implement them. > > Regards, > Terry Lambert > terry@lambert.org >- --- -Brian >Any opinions in this posting are my own and not those of my present >or previous employers. > I try not to have opinions, merely facts.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703071932.OAA03741>