Date: Wed, 07 Apr 2004 15:36:02 -0700 From: othermark <atkin901@yahoo.com> To: freebsd-hackers@freebsd.org Subject: Re: polling for sio? Message-ID: <c51voo$jt$1@sea.gmane.org> References: <c519i5$5vt$1@sea.gmane.org> <20040407170422.GF567@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:
> othermark wrote this message on Wed, Apr 07, 2004 at 09:17 -0700:
>> I'm just looking into DEVICE_POLLING. Would it be difficult to add
>> polling
>> functionality to uart or sio? My main objective would be to get rid of
>> silo overflows in the sio device for shared interrupt devices.
>
> I would say that more time would be better spent on either lowering
> your fifo levels (to make the interrupts trigger earlier)
So, I assume you're referring to this comment below. Are you referring
to lowering the amount available to sio or to the trigger level latency?
/*
* Use a fifo trigger level low enough so that the input
* latency from the fifo is less than about 16 msec and
* the total latency is less than about 30 msec. These
* latencies are reasonable for humans. Serial comms
* protocols shouldn't expect anything better since modem
* latencies are larger.
*
* The fifo trigger level cannot be set at RX_HIGH for high
* speed connections without further work on reducing
* interrupt disablement times in other parts of the system,
* without producing silo overflow errors.
*/
com->fifo_image = com->unit == siotsunit ? 0
: t->c_ispeed <= 4800
? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX_MEDH;
> , or fix
> sio so that COM_MULTIPORT (for shared interrupts) doesn't poll all
> sio devices, and instead it keeps track of which devices need to be
> polled for each interrupt (and possible use the AST/4 register to
> decide which ports to query)....
>
> uart already has most of this logic, but I haven't written an isa
> attachment for it to make use of the interrupt routing logic..
I have a multi-port PCI card under puc and sio that has 4 19200
connections to it now, and when data is streaming across all of
them at once, I get several silo overflows. Would it be better
to run this under puc + uart?
As an aside, there's some good comments in parts of sio, it makes it more
enjoyable to understand. I enjoyed these in particular:
- do you suppose that this is still a problem?
/*
* "& 0x7F" is to avoid the gcc-1.40 generating a slow
* jump from the top of the loop to here
*/
line_status = inb(com->line_status_port) & 0x7F;
- I can understand a certain usec delay between disabling
the fifo and reading, but is it 'superstitous?'...
/*
* XXX the delays are for superstitious
* historical reasons. It must be less than
* the character time at the maximum
* supported speed (87 usec at 115200 bps
* 8N1). Otherwise we might loop endlessly
* if data is streaming in. We used to use
* delays of 100. That usually worked
* because DELAY(100) used to usually delay
* for about 85 usec instead of 100.
*/
DELAY(50);
if (!(inb(com->line_status_port) & LSR_RXRDY))
break;
sio_setreg(com, com_fifo, 0);
DELAY(50);
(void) inb(com->data_port);
--
othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c51voo$jt$1>