* Re: Problem with full speed devices on PowerPC MPC5121 host port [not found] ` <20111222173900.GD28856@kroah.com> @ 2012-01-06 11:55 ` Matthias Fuchs 2012-01-06 18:03 ` Alan Stern 0 siblings, 1 reply; 6+ messages in thread From: Matthias Fuchs @ 2012-01-06 11:55 UTC (permalink / raw) To: Greg KH; +Cc: linuxppc-dev, linux-usb 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with full speed devices on PowerPC MPC5121 host port 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 0 siblings, 1 reply; 6+ messages in thread From: Alan Stern @ 2012-01-06 18:03 UTC (permalink / raw) To: Matthias Fuchs; +Cc: Greg KH, linux-usb, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with full speed devices on PowerPC MPC5121 host port 2012-01-06 18:03 ` Alan Stern @ 2012-01-17 14:12 ` Matthias Fuchs 2012-01-18 11:08 ` Anatolij Gustschin 0 siblings, 1 reply; 6+ messages in thread From: Matthias Fuchs @ 2012-01-17 14:12 UTC (permalink / raw) To: Alan Stern; +Cc: Greg KH, linux-usb, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with full speed devices on PowerPC MPC5121 host port 2012-01-17 14:12 ` Matthias Fuchs @ 2012-01-18 11:08 ` Anatolij Gustschin 2012-01-18 13:42 ` Matthias Fuchs 0 siblings, 1 reply; 6+ messages in thread From: Anatolij Gustschin @ 2012-01-18 11:08 UTC (permalink / raw) To: Matthias Fuchs; +Cc: linuxppc-dev, linux-usb [-- 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Problem with full speed devices on PowerPC MPC5121 host port 2012-01-18 11:08 ` Anatolij Gustschin @ 2012-01-18 13:42 ` Matthias Fuchs 2012-01-19 9:34 ` Anatolij Gustschin 0 siblings, 1 reply; 6+ messages in thread From: Matthias Fuchs @ 2012-01-18 13:42 UTC (permalink / raw) To: Anatolij Gustschin; +Cc: linuxppc-dev, linux-usb 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with full speed devices on PowerPC MPC5121 host port 2012-01-18 13:42 ` Matthias Fuchs @ 2012-01-19 9:34 ` Anatolij Gustschin 0 siblings, 0 replies; 6+ messages in thread From: Anatolij Gustschin @ 2012-01-19 9:34 UTC (permalink / raw) To: Matthias Fuchs; +Cc: linuxppc-dev, linux-usb 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-19 9:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
2012-01-18 11:08 ` Anatolij Gustschin
2012-01-18 13:42 ` Matthias Fuchs
2012-01-19 9:34 ` Anatolij Gustschin
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).