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

[Wolfgang Denk]

Dear Graeme,

In message <CALButCKQ_bgpOZquozzQnU01v41Y+uWo8ELLNqSE15D30p52ug at mail.gmail.com> you wrote:
> 
> Well, I have the feeling than an console API might be in order. The way
> U-Boot is structured at the moment, serial I/O is kind of taken for
> granted to 'just exist' and nobody needs to really be self-aware that
> they use it...

Indeed. All we need is a working set of srdin/stdout/stderr.  Keep in
mind that anything couldbe attached - not only a serial line.

>           ... The same cannot be said of users of USB and Network -
> Net is a good example - all 'users' of net call NetLoop() which does
> an eth_init()...do stuff...eth_halt()

Driver API...

> So maybe a serial API which 'users' must 'wake up' and 'sleep'...

Arghhh...

>  - console_configure() - Set parameters (port, baud rate etc)
>  - console_wake() - Prepare the console (could be serial, USB, netconsole)
>  - console_flush() - Throw away any buffered characters
>  - console_getc(), console_putc(), console_tstc() - Self explainatory
>  - console_sleep() - Shut the console down (send XOFF, turn of USB etc)

Forget it.  We will not have a separate and completely non-standard "serial API".
If anything gets changed here, then in the context of a general driver
API cleanup, or at least based on a design for such a generic driver
API.

> UART like your SPI example. The command line interpreter calls
> console_sleep() to release the serial UART resource before the command
> which uses the multiplexed device wakes that device, does it's thing and
> shuts the device down before returning to the command line interpreter
> which wakes up the serial UART...

Sorry, but that's crappy by design.

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
Marriage is the sole cause of divorce.