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

Wolfgang Denk wd at denx.de
Tue Oct 25 20:41:44 CEST 2011


Dear Graeme Russ,

In message <4EA67491.5090802 at gmail.com> you wrote:
> 
> Well, if a command reads from the console (a transfer command for example)
> and then has a long delay (busy processing loop) before returning back to
> the command line processor then that command must be fundamentally broken -

???? Could you please explain what makes you think so?

What the command does, and when it performs I/O or when it spens time
for other tasks is only up to the command.

If anything is broken then it is a design that puts restrictions on
such behaviour.

>  a) Fix the command so it isn't broken
>  b) Have the command tell the console it has finished with the console
>     before it starts the busy loop
>  c) Use UART managed hardware flow control
>  d) Implement interrupt based serial drivers
>  e) Prohibit multi-line input

Prohibit is a bit of a strong word here.  "Not support" is more like
it.

> So let's assume for the meantime that there are no 'broken' commands we can

This is not an assumption.  No implementation must put any
restrictions on the timing behaviour of any commands.

> simply issue an XOFF before running each command - That should eliminate

That's brainded overhead. In 99.999% of all cases it's not needed.
And it happens at completely the wrong place.

Serial flow control is something we should deal with in the serial
driver code.  Nowhere else.

I will not accept such a design nor such an implementation.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Have you lived in this village all your life?"        "No, not yet."


More information about the U-Boot mailing list