[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