[U-Boot] [PATCH v4 2/2] NS16550: buffer reads

[Graeme Russ <graeme.russ@gmail.com>]

Hi Simon, Albert,

On 22/10/11 19:44, Albert ARIBAUD wrote:
> Le 17/10/2011 18:40, Simon Glass a ?crit :

[snip]

>>> On the other hand, we also have the rule that things that are useful
>>> to some and that don't hurt others should be allowed to go in.
>>>
>>> What makes me hesitate are two things:
>>>
>>> - The patch promises a feature (multi-line input), but fails to
>>>   provide a reliably working implementation.

I fully agree with this - We should strive to eliminate bugs, not cover
them with more dirt :)

>> I *think* it does the best possible within the fundamental design
>> decision constraint. If there is more it can do, please let me have
>> your ideas. I don't believe buffering conflicts with the constraint -
>> they are separate things. But yes in systems with interrupts normally
>> the input buffer is filled in the background and drained in the
>> foreground.
> 
> There *is* a much better solution within the fundamental single tasking 
> design constraint, and it is the one that was invented precisely for 
> this: flow control. Granted, hardware flow control may be impractical, 
> and that's why software flow control was conceived as early as 1963 and 
> is still widely used today and supported by any serial software or 
> driver worth its salt.

Agree - flow control is the way to go

> Well, FWIW, were I the serial code maintainer, I'd NAK this and ask for 
> a XON/XOFF implementation.
> 
>> In any case this patch is
>> not the end of the story as serial needs some work - another objection
>> you didn't mention above is that this function lives in only one
>> driver. Is that a good thing (hide it away) or a bad thing (all
>> drivers should support it and the implementation should move up a
>> level)?
> 
> Software flow control, whatever way it is implemented, is pure SW and 
> hardware independent, so it should be a generic thing. If XON/XOFF input 
> flow control gets implemented (and I believe it should), then it should 
> be done above hardware serial drivers.

One problem I see with XON/XOFF is that if we don't send XOFF at the right
time, we run the risk of entering a busy loop (any reasonable timeout delay
for example) and loosing input. So in theory, we would need to send XOFF
after every getc() and XON before each getc() and then need to delay a bit
to wait for the character (unless tstc returns true in which case we can
just grab the char in the buffer) which seems a bit excessive.

Maybe we need disable/enable flow control functions for when we know we
will be entering a busy loop the consumes serial input (ymodem and kermit
transfers and readline for example)

Regards,

Graeme