Date: Fri, 7 Mar 1997 13:19:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bmcgover@cisco.com (Brian McGovern) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: Cyclom Card Message-ID: <199703072019.NAA17224@phaeton.artisoft.com> In-Reply-To: <199703071932.OAA03741@bmcgover-pc.cisco.com> from "Brian McGovern" at Mar 7, 97 02:32:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Computone and Arnet did this on SCO Xenix. When SCO went to rev. 3.x, they changed the size of their bufs from 32 to 24 characters to keep the kernel structure size the same. Unless you drove a port over a certain rate, you never got more thn 24 bytes in the buffer, and life was grand. If you drove the port faster, then it overwrote whatever 8 bytes followed the buf, and you got screwed bigtime. I would recommend *against* relying on the driver somehow knowing how much data can fit in a tty bufe in core, and transferring directly to the tty buffers for this reason. I kind of doubt that you could transfer with small enough granularity to fit, anyway. Unless you rewrite the code on the card (is it download code?), the use of the ring buffers internally in the tty code would probably cause a pessimal usage conflict anyway, unless you rewrote the tty code to natively use the cards buffering format (clearly, that won't work for all cards, each of which might have yet another format). > 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. That's standard smart card architecture, really. The biggest error most vendors run into in implementation (most notably, the Altos 2000 series "multidrop" RS422 serial boards) is a single control queue for inbound and outbound messages... means that you must complete your call for the read before you can write -- a bad thing. The "top/bottom" reference has to do with noting the data availability at hard interrupt time, then sceduling a soft interrupt. The actual data manipulation would not occur at hard interrupt time (and therefore not occur at high SPL). The benefit in doing this is increased interrupt concurrency, especially if you have multiple cards and your communications overall is bursty (as it's likely to be) and therefore you don't have a unform load at all times across the cards. The danger in doing this is that you must service the soft interrupt before you can reuse the DMA transfer area (or the on card buffers, if the CPU is moving the data). If the card takes the IACK as a signal that it's OK to reuse the buffer, then this can be problematic. So whether you can do this or not is dependent on how the card acts. In general, you will want to double-buffer, so that you can leave an ack pending as long as you don't become congested. Double-buffering, too, relies on the ability to say "go ahead" to the board apart from the IACK. Given typical implemenation of "ring-buffer-in-host-memory" style board communication, I suspect that if you went the DMA route, you wouldn't be able to make this distinction. On the other hand, if the ring buffer was not the tty buffer, then you would implicitly have to implement the "soft" interrupt events at interrupt level, because the card would expect the ring to have been at least partially drained by the IRQ servicing. The FreeBSD internals on how the SPL's mask/unmask, and how the "fast" interrupt handling actually works is probably useful here. Bruce would be a better reference on most of this than me... my experience in writing this kind of driver is all VMS/Xenix/SVR3/SVR4, so it's a bit dated for doing exactly what you are doing. 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?199703072019.NAA17224>