LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: linuxppc-dev@ozlabs.org
Subject: Re: mpc52xx_uart.c - Port Overruns
Date: Fri, 03 Jul 2009 13:42:46 +0200	[thread overview]
Message-ID: <m2ws6qm1qh.fsf@ohwell.denx.de> (raw)
In-Reply-To: c788c1220907021823y384b78c1x2bb9e0fc3268c0e0@mail.gmail.com

Hi Damien,

> I am writing to ask about some particular behaviour we saw with the MPC5121 PSC
> UART, using the 2.6.24 Freescle BSP kernel, although examining the code of the
> linux-2.6-denx tree (git commit 7cb16ec2590815a67e5fb5c8994ead536613d922), the
> behavior is almost identical except for incrementing an overrrun counter.
>
> In particular, yesterday we observed a port overrun (from the overrun flags
> being set when looking with the BDI) on one of our PSC Ports.   When it was
> observed, we saw that every second byte coming from the serial port was 0x00.
>
> Examining the interrupt routine of the mpc52xx_uart.c:
>
> static inline int
> mpc52xx_uart_int_rx_chars(struct uart_port *port)
> {
> <snip>
>         tty_insert_flip_char(tty, ch, flag);
>         if (status & MPC52xx_PSC_SR_OE) {
>             /*
>              * Overrun is special, since it's
>              * reported immediately, and doesn't
>              * affect the current character
>              */
>             tty_insert_flip_char(tty, 0, TTY_OVERRUN);
>             port->icount.overrun++;
>         }
> <snip>
> }
>
> So, from my deduction, it is inserting a 0x00 for every overrun error that
> occurs, however, the overrun flag is never cleared.  Therefore fro every byte
> that is received, the overrup flag is still set and therefore we're observing
> the 0x00 being inserted for every "real" byte coming into the port
>
> Is there a particular reason why the overrun flag is not cleared? That is,
> parity, framing and breaks are acknowledged with:
>
>             /* Clear error condition */
>             out_8(&PSC(port)->command, MPC52xx_PSC_RST_ERR_STAT);
>
> But the overrun isn't cleared.   Is there are particular reason why?  Is
> userspace meant to detect this condition and reset the port?  Was it
> automatically cleared on the 5200 when reading the status, but the 5121 is
> exhibiting strange behavior? 

This is likely only forgotten in the driver.  I remember fixing this in
our 2.4 kernel tree a long time ago[1].

Cheers
  Detlev

[1] http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commitdiff;h=00097a16641865b88568b807c9680b50c74bda84

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de

      reply	other threads:[~2009-07-03 11:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-03  1:23 mpc52xx_uart.c - Port Overruns Damien Dusha
2009-07-03 11:42 ` Detlev Zundel [this message]

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=m2ws6qm1qh.fsf@ohwell.denx.de \
    --to=dzu@denx.de \
    --cc=linuxppc-dev@ozlabs.org \
    /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