Date: Fri, 7 Mar 1997 10:27:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bmcgover@cisco.com (Brian McGovern) Cc: hackers@FreeBSD.ORG Subject: Re: Internal vs. External buffers Message-ID: <199703071727.KAA16934@phaeton.artisoft.com> In-Reply-To: <199703071455.JAA01713@bmcgover-pc.cisco.com> from "Brian McGovern" at Mar 7, 97 09:55:12 am
next in thread | previous 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. 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. 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. 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.. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703071727.KAA16934>