From: Hong Xu <hong.xu@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] AT91: Small fix on AT91 USART initialization code
Date: Tue, 02 Aug 2011 09:51:10 +0800 [thread overview]
Message-ID: <4E37580E.7010302@atmel.com> (raw)
In-Reply-To: <4E36BA8B.6070007@emk-elektronik.de>
Hi Reinhard,
On 08/01/2011 10:39 PM, Reinhard Meyer wrote:
> Dear Hong Xu,
> > Before reset dbgu transmitter, we just wait TXEMPTY to drain the
> > transmitter register. If not doing this, we may sometimes see several
> > weird characters from DBGU.
> >
> > A short delay is also added to make sure the new serial settings are
> > settled.
> >
> > Signed-off-by: Hong Xu<hong.xu@atmel.com>
> > ---
> > Change since V1:
> > - Fix comment for easy reading
> >
> > drivers/serial/atmel_usart.c | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
> > index e326b2b..6f9c2de 100644
> > --- a/drivers/serial/atmel_usart.c
> > +++ b/drivers/serial/atmel_usart.c
> > @@ -49,17 +49,23 @@ int serial_init(void)
> > {
> > atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
> >
> > + /* Just in case: drain transmitter register */
> > + while (!(readl(&usart->csr)& USART3_BIT(TXEMPTY)))
> > + ;
> > +
>
> You still have not addressed my concern about a possible hang situation
> here!
> I rather have _some_ weird characters than an apparently dead board...
> When do we have the possibility of weird characters anyway?
> Only if a preloader makes output and transfers to u-boot before its output
> has been flushed. Any other situations?
This is the main cause. I monitored some versions of bootstraps check
TXRDY before sending data to THR (Transmitter holding register). And for
the last character, they won't wait till the character has been sent
out. (And maybe there are similar places in U-Boot before calling
serial_init, I'm not sure)
The possibility of hang, I don't think so. Reason,
TXEMPTY means "There are no characters in DBGU_THR and there are no
characters being processed by the transmitter."
Theoretically this situation shall be met here. But of course a timeout
can be added defensively (chip goes mad? :)
What's your opinion?
BR,
Eric
>
> Best Regards,
> Reinhard
>
next prev parent reply other threads:[~2011-08-02 1:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-01 11:30 [U-Boot] [PATCH V2] AT91: Small fix on AT91 USART initialization code Hong Xu
2011-08-01 14:39 ` Reinhard Meyer
2011-08-02 1:51 ` Hong Xu [this message]
2011-08-02 9:54 ` Reinhard Meyer
2011-08-02 10:31 ` Hong Xu
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=4E37580E.7010302@atmel.com \
--to=hong.xu@atmel.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