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

[Wolfgang Denk]

Dear Graeme,

In message <CALButCKRs7kNa086V-jUC0h-yjA7jfNo+2C9ifKpoREsdmWZQA at mail.gmail.com> you wrote:
> 
> This problem comes down to managing two asynchronous tasks - Command
> Processing and Serial Input Processing. Any solution to the problem
> is going to involve task switching. The way this is done in U-Boot
> currently is:

I wonder how this idea of "tasks" sneaked into your brain.

I agree that one thing we suffer from is a clean device model.  And I
will not hesitate to agree that things would be way easier if the
serial driver was interrupt based.

But tasks in the classical sense have nothing to do with it (I don't
consider an ISR a "task").

>  - When in the main() loop, U-Boot is effectively running a Command
>    Processing Taks (monitor inbound characters, determine when a
>    command has been entered) which continually switches over to Serial
>    Input Processing Task. When a valid command is detected, U-Boot
>    switches to the corresponding Command Processing Task
>  - Some 'commands' (file transfers in particular) have their own Serial
>    Input Processing Sub-Tasks - The Command Processing Task may run for a
>    'significant' amount of time after these Sub-Tasks are finished with
>    and no longer processing serial input

I disagree completely.  There is no such thing as "Command Processing
Tasks" or "Serial Input Processing Tasks" or Subtasks or anything like
that.  There are no tasks at all.

> When you are dealing with asynchronous tasks, you can task switch by
> either:
> 
>  1) Using a hardware interrupt (either a tick-timer or interrupt line from
>     the serial UART)

Yes, an interrupt driven driver would be one valid approach to
adddress this issue.  It brings additional complexity in other areas,
though - things like code size, need for dual mode (polled before
relocation, interrupt driven later?) etc. come to mind.

>  2) Littering the main taks with co-operative interrupt calls
>  3) Task switch at clearly defined locations in the code

> Option 1 is not supported in U-Boot

??? What makes you think so?  It's frowned upon, because the
disadvantages are way bigger than the advantages, but that's all.

> Option 2 is used by U-Boot for triggering the watchdog - It's not pretty,
> but in the absence of #1, we have no other option

This is another misconception.  We do have interrupts on some
architectures, but if you trigger a watchdog from a timer interrupt or
similar you can as well turn it off.  That's not how a watchdog is
supposed to work.

> Option 3 is all we are left with...

I disagree.

> I suggested a solution whereby any task which _knows_ it switches to the
> Serial Input Processing Taks (i.e. calls getc()) can:

Please stop talking about a "Serial Input Processing Task". What you
mean is a serial driver.  This driver is supposed to provide nothing
else to the "application code" than the functionality we can attach to
the stdin and stdout/stderr I/O channels.

All things like flow control (be it hard or soft), buffering, etc.
etc. are internal to the serial driver only.

Actually please stop talking about tasks at all.  U-Boot is
single-tasked.  Period.

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
Cogito cogito ergo cogito sum - "I think that I  think,  therefore  I
think that I am."          - Ambrose Bierce, "The Devil's Dictionary"