From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vx0-f179.google.com (mail-vx0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 08ED2B6FDC for ; Sat, 16 Apr 2011 16:40:33 +1000 (EST) Received: by vxi40 with SMTP id 40so3033765vxi.38 for ; Fri, 15 Apr 2011 23:40:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110415154110.1b523da0@schlenkerla.am.freescale.net> References: <20110415154110.1b523da0@schlenkerla.am.freescale.net> Date: Sat, 16 Apr 2011 09:40:29 +0300 Message-ID: Subject: Re: Non-console UART issues with 8xx From: Eran Duchan To: Scott Wood Content-Type: multipart/alternative; boundary=bcaec50163892f3d6504a1036f97 Cc: linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --bcaec50163892f3d6504a1036f97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wrote= : > On Fri, 15 Apr 2011 02:52:22 +0300 > Eran Duchan 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 softwa= re > > 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 b= e > 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 an= d > > then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something > like > > "1234567=F8". 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 a= n > open file-handle -- which doesn't interact well with the driver's > (possibly misguided) desire to actually deconfigure the hardware when not > open. > > -Scott > > --bcaec50163892f3d6504a1036f97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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@freescale.com> wrote:
On Fri, 15 Apr 2011 02:52= :22 +0300
Eran Duchan <pavius@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 softw= are
> 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*<= br> clearing the transmit enable bits, rather than after.

> =A0For example, set up SMC1 to console (works
> perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw a= nd
> then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be someth= ing like
> "1234567=F8". 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 t= ied 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


--bcaec50163892f3d6504a1036f97--