linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Meade <chuck@ThePTRGroup.com>
To: linuxppc-dev@lists.ozlabs.org
Subject: Re: Continuing UCC UART woes
Date: Thu, 24 Jun 2010 10:44:04 -0400	[thread overview]
Message-ID: <4C236F34.3020406@ThePTRGroup.com> (raw)
In-Reply-To: <4C23621D.1010600@mlbassoc.com>

>> You can use strategic printk debugging in the ucc_uart.c driver to
>> determine
>> on the Tx side what is going wrong.  For example, after you tell the
>> QE to
>> output chars, wait a bit and printk out the BD.  See if the QE is
>> clearing the
>> READY bit in that BD.  That will tell you if the QE is even processing
>> the BD
>> or not.
> 
> I've also done this - the descriptors are set up, never touched by the QE
> Odd that input always works, output works only very rarely.

You could check alignment of the BD address to be sure that got setup correctly.
Make sure you are not looking at a cached version of the BD, and make sure
you waited long enough for the QE to have processed it.

>> Also ensure that for all these other UCCs that you are using that the
>> CD, CTS,
>> RTS pins are set up as plain GPIO pins if you do not have them hooked
>> up to
>> actual CD, CTS, RTS signals.  If you *are* using HW flow control,
>> probe all the
>> signals to be sure they are all correct.
> 
> No change whether these pins are configured or not.

I would definitely leave these configured as GPIOs if the correct signals
are not present at the pins.

You could look through the pdf that is in that zipfile and make sure you are
following (that the driver is following) all the restrictions for soft UART
mode.

Perhaps printk debug in ucc_slow_init to make sure the UCC is getting set up correctly.
I would probably also make sure that the Tx parameter ram is allocated and
aligned OK.

Make sure you specify unique port-number fields in your dts for each of these UCC UARTs.

Beyond that, if printk-debugging does not show anything, then you may want to contact
Freescale and try to find out what the Soft UART mode microcode patch capabilities are,
in terms of exactly how many simultaneous UCC UARTs it has been proven to support.
The QE has processing limits, and maybe the soft UART microcode patch can't support
multiple UCC UARTs(?)  It's worth it to find out from Freescale I suppose.

Chuck Meade
chuck@ThePTRGroup.com

      reply	other threads:[~2010-06-24 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24 12:54 Continuing UCC UART woes Gary Thomas
2010-06-24 13:31 ` Gary Thomas
2010-06-24 13:38 ` Chuck Meade
2010-06-24 13:48   ` Gary Thomas
2010-06-24 14:44     ` Chuck Meade [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=4C236F34.3020406@ThePTRGroup.com \
    --to=chuck@theptrgroup.com \
    --cc=linuxppc-dev@lists.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;
as well as URLs for NNTP newsgroup(s).