Non-console UART issues with 8xx

[Eran Duchan]

Thanks for the pointers, Scott.
Looks like some elbow grease is in order. I will post any results I have
once I get to this :-/

Eran

On Fri, Apr 15, 2011 at 11:41 PM, Scott Wood <scottwood at freescale.com>wrote:

> On Fri, 15 Apr 2011 02:52:22 +0300
> Eran Duchan <pavius at gmail.com> wrote:
>
> > Hey list
> >
> > I have a custom MPC875 board running 2.6.37. SMC1 is the console, SCC4 is
> a
> > general purpose UART (DTS is set up accordingly). No hardware or software
> > flow control for either.
> >
> > The issue is simple: the non-console UART transmits garbled characters at
> > the end of the transmission.
>
> Hmm, there's a wait_closing field in uart_cpm_port that doesn't seem to be
> initialized anywhere.
>
> The driver should also be sending the STOP_TX/GRA_STOP_TX command *before*
> clearing the transmit enable bits, rather than after.
>
> >  For example, set up SMC1 to console (works
> > perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw and
> > then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something
> like
> > "1234567ø". Set the SCC4 as console (same baud rates) and the problem is
> > reversed (SCC4 works perfect, SMC1 transmit garbled).
> >
> > Rx direction seems fine, after some rudementary testing.
> >
> > I dived into the code and see that the console UART has a completely
> > different initialization sequence than the non-console UART. Short of
> diving
> > into this ancient CPM architecture - does anyone have an idea?
>
> The console is a bit different because it has a user that isn't tied to an
> open file-handle -- which doesn't interact well with the driver's
> (possibly misguided) desire to actually deconfigure the hardware when not
> open.
>
> -Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20110416/56ca6e28/attachment.html>