Re: Problem with full speed devices on PowerPC MPC5121 host port

Re: Problem with full speed devices on PowerPC MPC5121 host port

[Matthias Fuchs]

On 22.12.2011 18:39, Greg KH wrote:
> On Thu, Dec 22, 2011 at 12:48:45PM +0100, Matthias Fuchs wrote:
>> Hi,
>>
>> I ran into trouble when using the MPC5121 with full speed
>> USB devices. I've seen the issue with USB serial converters
>> based on FTDI and Prolific chips.
>>
>> After connecting the device they first work fine. But when
>> I stress the converter communications stalls. I can even force
>> this behavior when doing a flood ping against the device.
>> Then it only takes a few seconds until USB gets weird.
>>
>> After some time and several CTRL-C to stop the application
>> that uses the ttyUSBx port I get a kernel message:
>>
>> 	ftdi_sio ttyUSB0: error from flowcontrol urb
>>
>> The only thing that reanimates the USB port is doing a reboot.
> 
> Not removing and inserting the device again?  unloading the ftdi_sio
> driver and reloading it?
Right. First I used a monolithic kernel with ftdi_sio and ehci_hcd build
in. Now I did the test again with fsl_mph_dr_of, ehci_hcd, usbserial and
ftdi_sio loaded as modules. After the error occured, I
removed the device and unloaded the modules. After reloading them
USB is still weird.

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

> If you look at the data using usbmon, does anything look odd?
As long as everything works fine usbmon outputs data like this. It stops
a short time after I started the flood ping to the board.
df9c16c0 697164417 C Bi:1:002:1 0 2 = 0160
df9c16c0 697164436 S Bi:1:002:1 -115 512 <
df9c16c0 697165417 C Bi:1:002:1 0 2 = 0160
df9c16c0 697165441 S Bi:1:002:1 -115 512 <
df9c16c0 697166417 C Bi:1:002:1 0 2 = 0160
df9c16c0 697166435 S Bi:1:002:1 -115 512 <
df9c16c0 697167417 C Bi:1:002:1 0 9 = 01605f54 48452051 55
df9c16c0 697167450 S Bi:1:002:1 -115 512 <
df9c16c0 697168417 C Bi:1:002:1 0 14 = 01604943 4b204252 4f574e20 464f
df9c16c0 697168450 S Bi:1:002:1 -115 512 <
df9c16c0 697169420 C Bi:1:002:1 0 13 = 01605820 4a554d50 53204f56 45
df9c16c0 697169453 S Bi:1:002:1 -115 512 <
df9c16c0 697170418 C Bi:1:002:1 0 14 = 01605220 54484520 4c415a59 2044
df9c16c0 697170451 S Bi:1:002:1 -115 512 <
df9c16c0 697171417 C Bi:1:002:1 0 14 = 01604f47 20313233 34353637 3839
df9c16c0 697171450 S Bi:1:002:1 -115 512 <

Then I try to abort my application. This result in

df9c1340 712766944 S Co:1:002:0 s 40 02 0000 0000 0000 0
df9c1340 717776208 C Co:1:002:0 -2 0
df9c1340 717776503 S Co:1:002:0 s 40 01 0300 0000 0000 0
df9c1340 722786213 C Co:1:002:0 -2 8 >
df9c16c0 722796202 C Bi:1:002:1 -2 0

And finally I try to restart my application:

df9c12c0 791192447 S Co:1:002:0 s 40 00 0000 0000 0000 0
df9c12c0 796202240 C Co:1:002:0 -2 0
df9c12c0 796203289 S Co:1:002:0 s 40 02 0000 0000 0000 0
df9c12c0 801213213 C Co:1:002:0 -2 0
df9c16c0 801213518 S Bi:1:002:1 -115 512 <
df9c12c0 801213560 S Co:1:002:0 s 40 01 0303 0000 0000 0
df9c12c0 806223208 C Co:1:002:0 -2 0
df9c12c0 806223411 S Co:1:002:0 s 40 02 0000 0000 0000 0
df9c12c0 811233210 C Co:1:002:0 -2 0
df9c1440 821344904 S Co:1:002:0 s 40 02 0000 0000 0000 0
df9c1440 826354209 C Co:1:002:0 -2 8 >
df9c1440 826354515 S Co:1:002:0 s 40 01 0300 0000 0000 0
df9c1440 831364204 C Co:1:002:0 -2 0
df9c16c0 831374203 C Bi:1:002:1 -2 0

> And what kernel version are you using here?
Now I switched to 3.2.0 with only minimal changes for our hardware.
But (as expected) I get the same problems.

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.

I put linuxppc-dev on CC. Perhaps soneone in that community can double
check it on a Freescale evaluation board.

Matthias

Re: Problem with full speed devices on PowerPC MPC5121 host port

[Alan Stern]

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.

Alan Stern

Re: Problem with full speed devices on PowerPC MPC5121 host port

[Matthias Fuchs]

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

Re: Problem with full speed devices on PowerPC MPC5121 host port

[Anatolij Gustschin]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

Hi Matthias,

On Tue, 17 Jan 2012 15:12:50 +0100
Matthias Fuchs <matthias.fuchs@esd.eu> wrote:

> 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.

Can you try the attached patch? Does it have an impact?

Best regards,
Anatolij

[-- Attachment #2: 0001-usb-ehci-fsl-set-INCR8-mode-for-system-bus-interface.patch --]
[-- Type: text/x-patch, Size: 2242 bytes --]

>From 4cf7463af262230fcc0db95b2f47b0dcbf76daa9 Mon Sep 17 00:00:00 2001
From: Anatolij Gustschin <agust@denx.de>
Date: Wed, 18 Jan 2012 01:01:06 +0100
Subject: [PATCH] usb: ehci-fsl: set INCR8 mode for system bus interface

Port commit 69b4acc1dc4aa98a8f1016684fc99aba10156f87
(USB: Set INCR8 mode for system bus interface.) from Freescale
ltib 2.6.24 kernel for mpc512x:

This is a work-around for the USB-bus-hang problem observed
on MPC512x when there is heavy simultaneous PATA write activity.

See also "12.4 The USB controller can issue transactions that lock
up the AHB bus under certain conditions" in MPC5121e (M36P) Errata

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
 drivers/usb/host/ehci-fsl.c |   10 ++++++++++
 drivers/usb/host/ehci-fsl.h |    2 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index e90344a..a6a6722 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -346,6 +346,14 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
 
 	ehci_reset(ehci);
 
+#ifdef CONFIG_PPC_MPC512x
+	/*
+	 * set SBUSCFG:AHBBRST so that control msgs don't
+	 * fail when doing heavy PATA writes.
+	 */
+	ehci_writel(ehci, SBUSCFG_INCR8, hcd->regs + FSL_SOC_USB_SBUSCFG);
+#endif
+
 	retval = ehci_fsl_reinit(ehci);
 	return retval;
 }
@@ -469,6 +477,8 @@ static int ehci_fsl_mpc512x_drv_resume(struct device *dev)
 	ehci_writel(ehci, ISIPHYCTRL_PXE | ISIPHYCTRL_PHYE,
 		    hcd->regs + FSL_SOC_USB_ISIPHYCTRL);
 
+	ehci_writel(ehci, SBUSCFG_INCR8, hcd->regs + FSL_SOC_USB_SBUSCFG);
+
 	/* restore EHCI registers */
 	ehci_writel(ehci, pdata->pm_command, &ehci->regs->command);
 	ehci_writel(ehci, pdata->pm_intr_enable, &ehci->regs->intr_enable);
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index 4918062..0855be8 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -19,6 +19,8 @@
 #define _EHCI_FSL_H
 
 /* offsets for the non-ehci registers in the FSL SOC USB controller */
+#define FSL_SOC_USB_SBUSCFG	0x90
+#define SBUSCFG_INCR8		0x02	/* INCR8, specified */
 #define FSL_SOC_USB_ULPIVP	0x170
 #define FSL_SOC_USB_PORTSC1	0x184
 #define PORT_PTS_MSK		(3<<30)
-- 
1.7.1

Re: Problem with full speed devices on PowerPC MPC5121 host port

[Matthias Fuchs]

Hi Anatolij,

On 18.01.2012 12:08, Anatolij Gustschin wrote:
> Hi Matthias,
> 
> On Tue, 17 Jan 2012 15:12:50 +0100
> Matthias Fuchs <matthias.fuchs@esd.eu> wrote:
> 
>> 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.
> 
> Can you try the attached patch? Does it have an impact?

Yes, in deed, it solved my problem :-) Finally I noticed that
the problem is listed in the CPU's errata document.

You could update the comment and commit message to "... when there is
heavy simultaneus PATA write or network activity".

I vote for getting this mainline.

Tested-by: Matthias Fuchs <matthias.fuchs@esd.ue>

Matthias

Re: Problem with full speed devices on PowerPC MPC5121 host port

[Anatolij Gustschin]

Hi Matthias,

On Wed, 18 Jan 2012 14:42:20 +0100
Matthias Fuchs <matthias.fuchs@esd.eu> wrote:
...
> > Can you try the attached patch? Does it have an impact?
> 
> Yes, in deed, it solved my problem :-) Finally I noticed that
> the problem is listed in the CPU's errata document.
> 
> You could update the comment and commit message to "... when there is
> heavy simultaneus PATA write or network activity".
> 
> I vote for getting this mainline.
> 
> Tested-by: Matthias Fuchs <matthias.fuchs@esd.ue>

Thanks for testing! I'll rework to remove ifdef in the patch
and fix commit message and then resubmit.

Anatolij