Re: Problem with full speed devices on PowerPC MPC5121 host port
Hi Matthias, On Wed, 18 Jan 2012 14:42:20 +0100 Matthias Fuchs matthias.fu...@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.fu...@esd.ue Thanks for testing! I'll rework to remove ifdef in the patch and fix commit message and then resubmit. Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with full speed devices on PowerPC MPC5121 host port
Hi Matthias, On Tue, 17 Jan 2012 15:12:50 +0100 Matthias Fuchs matthias.fu...@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 From 4cf7463af262230fcc0db95b2f47b0dcbf76daa9 Mon Sep 17 00:00:00 2001 From: Anatolij Gustschin ag...@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 ag...@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 (330) -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with full speed devices on PowerPC MPC5121 host port
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.fu...@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.fu...@esd.ue Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with full speed devices on PowerPC MPC5121 host port
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with full speed devices on PowerPC MPC5121 host port
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 0 df9c1340 717776208 C Co:1:002:0 -2 0 df9c1340 717776503 S Co:1:002:0 s 40 01 0300 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 0 df9c12c0 796202240 C Co:1:002:0 -2 0 df9c12c0 796203289 S Co:1:002:0 s 40 02 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 0 df9c12c0 806223208 C Co:1:002:0 -2 0 df9c12c0 806223411 S Co:1:002:0 s 40 02 0 df9c12c0 811233210 C Co:1:002:0 -2 0 df9c1440 821344904 S Co:1:002:0 s 40 02 0 df9c1440 826354209 C Co:1:002:0 -2 8 df9c1440 826354515 S Co:1:002:0 s 40 01 0300 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with full speed devices on PowerPC MPC5121 host port
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
