polling for sio?

[othermark]

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);