Re: patch - at91 serial drivers assumed realtime response for DSR routines

[Eric Doenges <Eric dot Doenges at DynaPel dot com>]

Thomas Koeller wrote:
> Laurent GONZALEZ wrote:
>
> > > This cannot be avoided. The driver must be able to respond to any
> > > single character received, because an application might want to
> > > receive characters sent one by one.
> >
> > And that is the major point. Carefully reading the at91 manual, it is to
> > notice that at91 provide a powerfull timeout mechanism, to raise an
> > interrupt if the line is idle after the last receive character. Using
> > this, the driver will respond to a single char under ligth load, and
> > will use full buffering capability under heavy load.
>
>
> But that would result in arbitrary delays that are visible to the
> application. You would need to pick some delay value at random, or
> make it a configuration parameter. I find this undesirable; it is
> not the driver's business to enforce this kind of policy decision
> upon the application. If it needs to transfer data at a rate that
> significantly loads the CPU in order to serve its purpose (maybe in
> bursts only), than it must be able to do so.

Just my 2 (Euro) cents here (disclaimer: I've never worked with the
AT91 before, so my opinion may be entirely worthless).

If this timeout is choosen to be very short - say the time necessary
to receive half a character at the current baud rate - an application
that deals with single characters should normally(*) not be affected. At
the same time, I think it is reasonable to assume that high-speed data
coming in bursts will come without any pauses in between, so the timeout 
won't harm those applications either. And in any case, the timeout could
be made configurable via an ioctl, with the default being no timeout.

(*) I say 'normally' because I realise that some applications might need
to determine the exact time a byte was received, for instance to
satisfy some form of time triggered communication protocoll. However.
I would argue that such an application should probably not be using a
generic serial driver.
--
--------------------------------------------------------------------
|     Eric Doenges              |     DynaPel Laboratories GmbH    |
|     Tel: +49 89 962428 23     |     Fraunhoferstrasse 9/2        |
|     Fax: +49 89 962428 90     |     D - 85737 Ismaning, Germany  |
--------------------------------------------------------------------