From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] NS16550: buffer reads
Date: Tue, 25 Oct 2011 19:34:25 +1100 [thread overview]
Message-ID: <4EA67491.5090802@gmail.com> (raw)
In-Reply-To: <20111025073111.875461408EA7@gemini.denx.de>
Hi Wolfgang,
On 25/10/11 18:31, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <CALButCLNEjjEB=1zvvikrVo5-X9vyYOECU1-ZrpXf2myavM+Pg@mail.gmail.com> you wrote:
>>
>> Now 1c) makes the bold assumption that any command which calls getc()
>> 'knows what it is doing' and will consume all input characters at a fast
>> enough rate AND will not invoke a delay between receiving the last
>> character and returning back to the command line interpreter. If the
>> command knows it received characters and knows it will invoke a delay (some
>> kind of post-processing) then in order to not lose characters, the command
>> MUST issue it's own XOFF - nothing else aside from an interrupt driven
>> serial driver will solve the problem in this case.
>
> This is a fundamentally broken design. No command should ever need to
> have any such knowledge, not to mention that we must not littering
> potentially all code with serial flow control calls.
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 -
there are five ways I see to fix it:
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
> You will have really hard times to get anything like that into mainline.
So let's assume for the meantime that there are no 'broken' commands we can
simply issue an XOFF before running each command - That should eliminate
most dropped character issues - This is Simon's latest 2-patch series.
Adding rx_flush() and a small local buffer will fix dropped characters due
to insufficiently small local UART Rx buffers (and brain-dead remote Tx
buffers) - That's a separate small patch
So any remaining dropped character issues are reduced to 'broken' commands
that use console I/O and then enter a busy loop which does not process
console I/O - Now we're into hack territory
Regards,
Graeme
next prev parent reply other threads:[~2011-10-25 8:34 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-16 5:14 [U-Boot] [PATCH v4 1/2] NS16550: trivial code clean for checkpatch Simon Glass
2011-10-16 5:14 ` [U-Boot] [PATCH v4 2/2] NS16550: buffer reads Simon Glass
2011-10-16 12:57 ` Albert ARIBAUD
2011-10-16 17:06 ` Simon Glass
2011-10-16 20:13 ` Wolfgang Denk
2011-10-16 20:47 ` Simon Glass
2011-10-16 21:03 ` Wolfgang Denk
2011-10-17 11:08 ` Wolfgang Denk
2011-10-17 16:25 ` Simon Glass
2011-10-17 20:19 ` Simon Glass
2011-10-17 20:33 ` Wolfgang Denk
2011-10-17 20:58 ` Simon Glass
2011-10-22 8:29 ` Albert ARIBAUD
2011-10-17 12:18 ` Wolfgang Denk
2011-10-17 16:40 ` Simon Glass
2011-10-22 8:44 ` Albert ARIBAUD
2011-10-22 22:15 ` Graeme Russ
2011-10-23 8:20 ` Wolfgang Denk
2011-10-23 11:50 ` Graeme Russ
2011-10-23 17:15 ` Wolfgang Denk
2011-10-23 20:17 ` Graeme Russ
2011-10-23 21:22 ` Wolfgang Denk
2011-10-23 21:32 ` [U-Boot] [PATCH v2] " Graeme Russ
2011-10-23 22:18 ` Wolfgang Denk
2011-10-23 23:30 ` Graeme Russ
2011-10-24 4:47 ` Simon Glass
2011-10-24 18:46 ` Wolfgang Denk
2011-10-24 19:26 ` Graeme Russ
2011-10-24 20:00 ` Wolfgang Denk
2011-10-24 20:40 ` Graeme Russ
2011-10-24 21:59 ` Wolfgang Denk
2011-10-24 22:22 ` Graeme Russ
2011-10-24 23:31 ` J. William Campbell
2011-10-25 7:31 ` Wolfgang Denk
2011-10-25 8:34 ` Graeme Russ [this message]
2011-10-25 18:41 ` Wolfgang Denk
2011-10-25 22:37 ` Graeme Russ
2011-10-25 23:17 ` Simon Glass
[not found] ` <CALButCK2XnZ=HR72VaXioCfxkMFgMh2JbXzSDq9TadgKFH52rQ@mail.gmail.com >
2011-10-25 23:37 ` Graeme Russ
2011-10-25 23:48 ` Simon Glass
2011-10-26 3:41 ` Graeme Russ
2011-10-26 7:00 ` Wolfgang Denk
2011-10-26 9:18 ` Graeme Russ
2011-10-26 10:19 ` Wolfgang Denk
2011-10-26 16:55 ` Scott Wood
2011-10-26 18:17 ` Wolfgang Denk
2011-10-26 18:50 ` Scott Wood
2011-10-26 19:19 ` Wolfgang Denk
2011-10-26 6:54 ` Wolfgang Denk
2011-10-23 18:17 ` [U-Boot] [PATCH v4 2/2] " Wolfgang Denk
2011-10-23 18:20 ` [U-Boot] [PATCH v4 1/2] NS16550: trivial code clean for checkpatch Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2011-10-15 0:03 [U-Boot] [PATCH v2] NS16550: buffer reads Simon Glass
2011-10-15 10:43 ` Albert ARIBAUD
2011-10-15 14:47 ` Simon Glass
2011-10-15 16:02 ` Wolfgang Denk
2011-10-15 16:12 ` Simon Glass
2011-10-15 16:21 ` Albert ARIBAUD
2011-10-15 16:50 ` Simon Glass
2011-10-15 17:45 ` Simon Glass
2011-10-15 19:14 ` Wolfgang Denk
2011-10-16 4:46 ` Simon Glass
2011-10-16 19:52 ` Wolfgang Denk
2011-10-16 21:02 ` Simon Glass
2011-10-15 19:05 ` Wolfgang Denk
2011-10-15 19:00 ` Wolfgang Denk
2011-10-16 4:39 ` Simon Glass
2011-10-16 19:47 ` Wolfgang Denk
2011-10-16 20:43 ` Simon Glass
2011-10-16 21:00 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA67491.5090802@gmail.com \
--to=graeme.russ@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox