[U-Boot] [PATCH v2] NS16550: buffer reads

[Graeme Russ]

Hi Wolfgang,

On 25/10/11 05:46, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <CALButCKD2ucJ0ZUQJpLCP2ABYcCzO-mACa=FPWczCTVeHeoTKg at mail.gmail.com> you wrote:
>>
>>>> If so, could it not be possible that a Kermit/ymodem command followed by a
>>>> time consuming command on the same line cause lost input?
>>>
>>> I don't think so.  All serial transfers use a protocol - and when the
>>> transfer is complete, it does not matter any more, because no more
>>> data are flowing.
>>
>> My point is that the transfer turns off flow control - When the transfer
>> completes, flow control will be off when the next command begins to run.
> 
> Why would any of the transfer commands actually turn off flow control?

getc() sends an XOFF

> There is no need to do that so far.  And even if they do - that's no
> fundamental difference to now, where we are not reading the input
> then, either.
> 
>> If the next command is one which takes a long time to execute and it is on
>> the same line as the transfer command (i.e. no \r to send XOFF) and the
>> user types something then that input can be lost.
> 
> I don't understand what you mean.  We're talking about a single line
> of input here, right?  Re-enabling XON is not needed before we're
> ready to read the next line.  And during that, no characters would be
> lost because none are sent due to flow control being shut off.
> 
>> I think the solution is fairly trivial though - During the processing of
>> commands entered via readline(), cause an XOFF to be sent each time (i.e.
>> immediately before) the command string is dispatched a to the command
>> processor just in case the previous command called getc() (and thus caused
>> an XON to be sent)
> 
> This sounds like unneeded overhead to me.

consider the follow (admittedly canned) example:

loadb ; sleep 20

An XOFF will be sent when the user hits 'enter' but loadb will send an XON
when it calls getc(). Now after the transfer is complete, there will have
been no XOFF before the sleep command is run so if the user enters anything
during the sleep command, those characters can be lost

Regards,

Graeme