From: Matthias Fuchs <matthias.fuchs@esd.eu>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>,
linux-usb@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: Problem with full speed devices on PowerPC MPC5121 host port
Date: Tue, 17 Jan 2012 15:12:50 +0100 [thread overview]
Message-ID: <4F1581E2.9030400@esd.eu> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1201061258040.1326-100000@iolanthe.rowland.org>
On 06.01.2012 19:03, Alan Stern wrote:
> On Fri, 6 Jan 2012, Matthias Fuchs wrote:
>
>> For my eyes it does not really look like a general USB issue.
>> It looks like a problem with the Freescale EHCI implementation that is
>> influenced by high interrupt or internal bus load caused by the flood ping.
>
> Indeed, it might be a problem with the built-in Transaction Translator.
> That would explain why it affect full-speed devices.
>
> However, I would expect the resetting the controller hardware (which
> happens when you reload the ehci-fsl driver) would fix any such issues.
> It's hard to imagine how a problem could survive a reset like that.
I did the tests again. When the error occured I reloaded the ehci-hcd driver and reconnected the device. It ends up with some kernel messages
that come up time after time:
usb 1-1: new full-speed USB device number 2 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full-speed USB device number 3 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full-speed USB device number 4 using fsl-ehci
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full-speed USB device number 5 using fsl-ehci
usb 1-1: device not accepting address 5, error -110
hub 1-0:1.0: unable to enumerate USB device on port 1
A recommondation from freescale was to check the TXFILLTUNING register settings ("Initialization of this registers can produce problem if full-speed device is used").
So I tried various values in the TXFILLTUNING register (I added this
code to ehci_reset()). Finally I disabled USB streaming mode in the USBMODE register (set bit USBMODE_SDIS - btw., it should be defined as "1 << 4" in ehci_def.h at least for the MPC5121).
All this does not fix the problem or even have an impact.
This is my stripped down version of the test:
on the MPC5121 unit I do nothing but:
$~ stty -F /dev/ttyUSB0 -echo -crtscts -cstopb
$~ stty -F /dev/ttyUSB0 115200
$~ while true; do \
read LINE < /dev/ttyUSB0 \
echo $LINE > /dev/ttyUSB0 \
done
The other side looks like this:
$~ while true; do \
echo "_THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 1234567890#" > /dev/ttyS0 \
done
and also I start a flood ping against the MPC5121 unit (.. to speed things up).
Can anybody with a MPC5121 board try to reproduce this?
Matthias
next prev parent reply other threads:[~2012-01-17 14:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4EF3191D.9040508@esd.eu>
[not found] ` <20111222173900.GD28856@kroah.com>
2012-01-06 11:55 ` Problem with full speed devices on PowerPC MPC5121 host port Matthias Fuchs
2012-01-06 18:03 ` Alan Stern
2012-01-17 14:12 ` Matthias Fuchs [this message]
2012-01-18 11:08 ` Anatolij Gustschin
2012-01-18 13:42 ` Matthias Fuchs
2012-01-19 9:34 ` Anatolij Gustschin
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=4F1581E2.9030400@esd.eu \
--to=matthias.fuchs@esd.eu \
--cc=greg@kroah.com \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.