Date: Thu, 8 Apr 2004 14:51:36 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: othermark <atkin901@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: polling for sio? Message-ID: <20040408215136.GI567@funkthat.com> In-Reply-To: <c51voo$jt$1@sea.gmane.org> References: <c519i5$5vt$1@sea.gmane.org> <20040407170422.GF567@funkthat.com> <c51voo$jt$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
othermark wrote this message on Wed, Apr 07, 2004 at 15:36 -0700:
> 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;
I'm talking about changing FIFO_RX_MEDH to FIFO_RX_MEDL (or _LOW if
absolutly necessary).. This will cause the interrupt to be triggered
sooner giving the interrupts more time to be serviced before an overflow
occured... I thought there was an option for setting this by default,
but I guess not...
Also, you can try to compile with PUC_FASTINTR to try and install using
a fast interrupt (it gets called in the interrupt handler instead of
being scheduled to run), but you have to make sure that the interrupt
that the puc card is on does not share an interrupt with any other
devices... This is easier in the apic case, but may require shuffling
cards around to isolate an int pin for that card only...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040408215136.GI567>