subject:"Re\: OMAP3\/AM3517 EHCI USB Issue"

Re: OMAP3/AM3517 EHCI USB Issue

2014-09-19 Thread Roger Quadros

On 09/19/2014 12:37 PM, Michael Trimarchi wrote:
> Hi Roger
> 
> On Fri, Sep 19, 2014 at 11:22 AM, Roger Quadros  wrote:
>> Hi Michael,
>>

>
> It should be noted that the external HUB must be prevented from 
> autosuspend
> otherwise the resume fails.

 OK. I was able to reproduce the issue on my beagleboard as well. The key 
 to reproduce the issue is to use a device which has autosuspend working. 
 Earlier I was using a mass storage device so couldn't reproduce the issue. 
 On using a HUB I could see the issue. Debugging this issue is on my action 
 list.

>>>
>>> I will keep an eye out for the fix if it is possible. The implementation of
>>> the remote resume workaround as listed in the sprz306d.pdf seems to hack
>>> into the core EHCI drivers and limits you to a single USB host.
>>>
>>
>> Please see Advisory 1.1.33 HSUSB Interoperability Issue with SMSC USB3320 PHY
>> (sprz306d errata doc).
>>
>> It seems ULPI suspend/resume is broken and there is no workaround. So you 
>> have to
>> prevent the USB device connected at root port from suspending.
>>
> 
> It's very important to understand if this affect even OMAP4 and
> tusb1210 that is suggested by TI.
> 

This particular issue was fixed in omap3630 ES1.1 onwards. But that doesn't 
mean OMAP4
is free of issues around USB EHCI. 4430 brought it's own set of issues which
were fixed in 4460. But there were still some issues requiring software 
workaround
especially around USB suspend/resume.

e.g. There is still an issue with both 4430 and 4460 called i701 
(USB Host - Possible Interoperability With External PHY At Resume Time)
which is observed on certain PHYs (at least not on usb3320).
There is a software workaround for that.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-09-19 Thread Michael Trimarchi

Hi Roger

On Fri, Sep 19, 2014 at 11:22 AM, Roger Quadros  wrote:
> Hi Michael,
>
> On 08/04/2014 06:27 PM, Michael Welling wrote:
>> On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote:
>>> On 08/02/2014 02:51 AM, Michael Welling wrote:
 On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling  
 wrote:
> On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
>> On 07/29/2014 06:20 PM, Michael Welling wrote:
>>> On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
 Hi Michael,

 On 07/28/2014 09:10 PM, Felipe Balbi wrote:
> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
 On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> On Fri, 25 Jul 2014, Michael Welling wrote:
>
>> The plot thickens
>>
>> So if I run the above command before anything is plugged into 
>> the ports
>> the HUB disconnects.
>>
>> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>> [   63.068839] usb 1-1: USB disconnect, device number 2
>>
>> Here is the output of the usbmon output when running the above 
>> command:
>> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>> de382e40 3788890604 C Ci:001:00 0 4 = 0705
>> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>> de382e40 3788893093 C Ci:001:00 0 4 = 0001
>> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>> de382e40 3788894958 C Ci:001:00 0 4 = 0001
>> de7d92c0 3788896519 S Ii:001:01 -115 4 <
>> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>> de382e40 3788900188 C Ci:001:00 0 4 = 0705
>> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>> de382e40 3788905793 C Co:001:00 0 0
>> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>> de7d92c0 3788943013 S Ii:001:01 -115 4 <
>> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>> de382e40 3788961175 C Co:001:00 0 0
>> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>> de382e40 3788965395 C Ci:002:00 -71 0
>> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>> de249040 3788968362 C Co:001:00 0 0
>> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>> de7d92c0 378906 S Ii:001:01 -115 4 <
>> de249040 3789023423 C Ci:001:00 0 4 = 01051200
>> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>> de249040 3789026815 C Co:001:00 0 0
>> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>> de249040 378923 C Ci:001:00 0 4 = 00010300
>> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>> de249040 3789232404 C Co:001:00 0 0
>> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>> de249040 3789235345 C Co:001:00 0 0
>> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>> de249040 3789237201 C Co:001:00 0 0
>> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>> de249040 3789238510 C Co:001:00 0 0
>> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>> de249040 3789241661 C Ci:001:00 0 4 = 00010300
>> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>> de249040 3789243921 C Co:001:00 0 0
>> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>> de249040 3789246930 C Co:001:00 0 0
>> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>> de7d92c0 3789452462 C Ii:001:01 -2 0

Re: OMAP3/AM3517 EHCI USB Issue

2014-09-19 Thread Roger Quadros

Hi Michael,

On 08/04/2014 06:27 PM, Michael Welling wrote:
> On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote:
>> On 08/02/2014 02:51 AM, Michael Welling wrote:
>>> On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling  
>>> wrote:
 On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
> On 07/29/2014 06:20 PM, Michael Welling wrote:
>> On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
>>> Hi Michael,
>>>
>>> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
 On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
>> Hi,
>>
>> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
>>> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
 On Fri, 25 Jul 2014, Michael Welling wrote:

> The plot thickens
>
> So if I run the above command before anything is plugged into the 
> ports
> the HUB disconnects.
>
> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> [   63.068839] usb 1-1: USB disconnect, device number 2
>
> Here is the output of the usbmon output when running the above 
> command:
> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> de382e40 3788890604 C Ci:001:00 0 4 = 0705
> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> de382e40 3788893093 C Ci:001:00 0 4 = 0001
> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> de382e40 3788894958 C Ci:001:00 0 4 = 0001
> de7d92c0 3788896519 S Ii:001:01 -115 4 <
> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> de382e40 3788900188 C Ci:001:00 0 4 = 0705
> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> de382e40 3788905793 C Co:001:00 0 0
> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> de7d92c0 3788943013 S Ii:001:01 -115 4 <
> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> de382e40 3788961175 C Co:001:00 0 0
> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> de382e40 3788965395 C Ci:002:00 -71 0
> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> de249040 3788968362 C Co:001:00 0 0
> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> de7d92c0 378906 S Ii:001:01 -115 4 <
> de249040 3789023423 C Ci:001:00 0 4 = 01051200
> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> de249040 3789026815 C Co:001:00 0 0
> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> de249040 378923 C Ci:001:00 0 4 = 00010300
> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> de249040 3789232404 C Co:001:00 0 0
> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> de249040 3789235345 C Co:001:00 0 0
> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> de249040 3789237201 C Co:001:00 0 0
> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> de249040 3789238510 C Co:001:00 0 0
> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> de249040 3789241661 C Ci:001:00 0 4 = 00010300
> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> de249040 3789243921 C Co:001:00 0 0
> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> de249040 3789246930 C Co:001:00 0 0
> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> de7d92c0 3789452462 C Ii:001:01 -2 0
>
> Not sure what any of it means.

 Basically it means what you said above: the hub disconnected.  I 
 can

Re: OMAP3/AM3517 EHCI USB Issue

2014-08-04 Thread Michael Welling

On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote:
> On 08/02/2014 02:51 AM, Michael Welling wrote:
> > On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling  
> > wrote:
> >> On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
> >>> On 07/29/2014 06:20 PM, Michael Welling wrote:
>  On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
> > Hi Michael,
> >
> > On 07/28/2014 09:10 PM, Felipe Balbi wrote:
> >> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
> >>> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
>  Hi,
> 
>  On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> > On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> >> On Fri, 25 Jul 2014, Michael Welling wrote:
> >>
> >>> The plot thickens
> >>>
> >>> So if I run the above command before anything is plugged into the 
> >>> ports
> >>> the HUB disconnects.
> >>>
> >>> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> >>> [   63.068839] usb 1-1: USB disconnect, device number 2
> >>>
> >>> Here is the output of the usbmon output when running the above 
> >>> command:
> >>> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> >>> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de382e40 3788890604 C Ci:001:00 0 4 = 0705
> >>> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> >>> de382e40 3788893093 C Ci:001:00 0 4 = 0001
> >>> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> >>> de382e40 3788894958 C Ci:001:00 0 4 = 0001
> >>> de7d92c0 3788896519 S Ii:001:01 -115 4 <
> >>> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de382e40 3788900188 C Ci:001:00 0 4 = 0705
> >>> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> >>> de382e40 3788905793 C Co:001:00 0 0
> >>> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> >>> de7d92c0 3788943013 S Ii:001:01 -115 4 <
> >>> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> >>> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> >>> de382e40 3788961175 C Co:001:00 0 0
> >>> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> >>> de382e40 3788965395 C Ci:002:00 -71 0
> >>> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> >>> de249040 3788968362 C Co:001:00 0 0
> >>> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> >>> de7d92c0 378906 S Ii:001:01 -115 4 <
> >>> de249040 3789023423 C Ci:001:00 0 4 = 01051200
> >>> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> >>> de249040 3789026815 C Co:001:00 0 0
> >>> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de249040 378923 C Ci:001:00 0 4 = 00010300
> >>> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> >>> de249040 3789232404 C Co:001:00 0 0
> >>> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> >>> de249040 3789235345 C Co:001:00 0 0
> >>> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> >>> de249040 3789237201 C Co:001:00 0 0
> >>> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> >>> de249040 3789238510 C Co:001:00 0 0
> >>> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de249040 3789241661 C Ci:001:00 0 4 = 00010300
> >>> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> >>> de249040 3789243921 C Co:001:00 0 0
> >>> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> >>> de249040 3789246930 C Co:001:00 0 0
> >>> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> >>> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> >>> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> >>> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> >>> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> >>> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> >>> de7d92c0 3789452462 C Ii:001:01 -2 0
> >>>
> >>> Not sure what any of it means.
> >>
> >> Basically it means what you said above: the hub disconnected.  I 
> >> can't
> >> tell why.  You'll have to ask someone who's fam

Re: OMAP3/AM3517 EHCI USB Issue

2014-08-04 Thread Roger Quadros

On 08/02/2014 02:51 AM, Michael Welling wrote:
> On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling  wrote:
>> On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
>>> On 07/29/2014 06:20 PM, Michael Welling wrote:
 On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
> Hi Michael,
>
> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>>> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
 Hi,

 On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
>> On Fri, 25 Jul 2014, Michael Welling wrote:
>>
>>> The plot thickens
>>>
>>> So if I run the above command before anything is plugged into the 
>>> ports
>>> the HUB disconnects.
>>>
>>> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>>> [   63.068839] usb 1-1: USB disconnect, device number 2
>>>
>>> Here is the output of the usbmon output when running the above 
>>> command:
>>> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>>> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de382e40 3788890604 C Ci:001:00 0 4 = 0705
>>> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>>> de382e40 3788893093 C Ci:001:00 0 4 = 0001
>>> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>>> de382e40 3788894958 C Ci:001:00 0 4 = 0001
>>> de7d92c0 3788896519 S Ii:001:01 -115 4 <
>>> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de382e40 3788900188 C Ci:001:00 0 4 = 0705
>>> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>>> de382e40 3788905793 C Co:001:00 0 0
>>> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>>> de7d92c0 3788943013 S Ii:001:01 -115 4 <
>>> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>>> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>>> de382e40 3788961175 C Co:001:00 0 0
>>> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>>> de382e40 3788965395 C Ci:002:00 -71 0
>>> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>>> de249040 3788968362 C Co:001:00 0 0
>>> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>>> de7d92c0 378906 S Ii:001:01 -115 4 <
>>> de249040 3789023423 C Ci:001:00 0 4 = 01051200
>>> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>>> de249040 3789026815 C Co:001:00 0 0
>>> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de249040 378923 C Ci:001:00 0 4 = 00010300
>>> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>>> de249040 3789232404 C Co:001:00 0 0
>>> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>>> de249040 3789235345 C Co:001:00 0 0
>>> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>>> de249040 3789237201 C Co:001:00 0 0
>>> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>>> de249040 3789238510 C Co:001:00 0 0
>>> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de249040 3789241661 C Ci:001:00 0 4 = 00010300
>>> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>>> de249040 3789243921 C Co:001:00 0 0
>>> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>>> de249040 3789246930 C Co:001:00 0 0
>>> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>>> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>>> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>>> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>>> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>>> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>>> de7d92c0 3789452462 C Ii:001:01 -2 0
>>>
>>> Not sure what any of it means.
>>
>> Basically it means what you said above: the hub disconnected.  I 
>> can't
>> tell why.  You'll have to ask someone who's familiar with the 
>> hardware
>> on that board.
>
> Sadly, there is no one more familar with this specific hardware than 
> myself.
>
> I can however ellaborate the hardware setup of the USB

Re: OMAP3/AM3517 EHCI USB Issue

2014-08-01 Thread Michael Welling

On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling  wrote:
> On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
>> On 07/29/2014 06:20 PM, Michael Welling wrote:
>> > On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
>> >> Hi Michael,
>> >>
>> >> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
>> >>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>>  On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
>> >> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
>> >>> On Fri, 25 Jul 2014, Michael Welling wrote:
>> >>>
>>  The plot thickens
>> 
>>  So if I run the above command before anything is plugged into the 
>>  ports
>>  the HUB disconnects.
>> 
>>  root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>>  [   63.068839] usb 1-1: USB disconnect, device number 2
>> 
>>  Here is the output of the usbmon output when running the above 
>>  command:
>>  root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>>  de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de382e40 3788890604 C Ci:001:00 0 4 = 0705
>>  de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>>  de382e40 3788893093 C Ci:001:00 0 4 = 0001
>>  de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>>  de382e40 3788894958 C Ci:001:00 0 4 = 0001
>>  de7d92c0 3788896519 S Ii:001:01 -115 4 <
>>  de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de382e40 3788900188 C Ci:001:00 0 4 = 0705
>>  de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>>  de382e40 3788905793 C Co:001:00 0 0
>>  de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>>  de7d92c0 3788943013 S Ii:001:01 -115 4 <
>>  de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>>  de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>>  de382e40 3788961175 C Co:001:00 0 0
>>  de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>>  de382e40 3788965395 C Ci:002:00 -71 0
>>  de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>>  de249040 3788968362 C Co:001:00 0 0
>>  de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>>  de7d92c0 378906 S Ii:001:01 -115 4 <
>>  de249040 3789023423 C Ci:001:00 0 4 = 01051200
>>  de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>>  de249040 3789026815 C Co:001:00 0 0
>>  de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de249040 378923 C Ci:001:00 0 4 = 00010300
>>  de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>>  de249040 3789232404 C Co:001:00 0 0
>>  de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>>  de249040 3789235345 C Co:001:00 0 0
>>  de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>>  de249040 3789237201 C Co:001:00 0 0
>>  de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>>  de249040 3789238510 C Co:001:00 0 0
>>  de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de249040 3789241661 C Ci:001:00 0 4 = 00010300
>>  de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>>  de249040 3789243921 C Co:001:00 0 0
>>  de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>>  de249040 3789246930 C Co:001:00 0 0
>>  de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>>  de7d92c0 3789452462 C Ii:001:01 -2 0
>> 
>>  Not sure what any of it means.
>> >>>
>> >>> Basically it means what you said above: the hub disconnected.  I 
>> >>> can't
>> >>> tell why.  You'll have to ask someone who's familiar with the 
>> >>> hardware
>> >>> on that board.
>> >>
>> >> Sadly, there is no one more familar with this specific hardware than 
>> >> myself.
>> >>
>> >> I can however ellaborate the hardware setup of the USB subsystem in
>> >> case there is someone out t

Re: OMAP3/AM3517 EHCI USB Issue

2014-08-01 Thread Michael Welling

On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
> On 07/29/2014 06:20 PM, Michael Welling wrote:
> > On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
> >> Hi Michael,
> >>
> >> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
> >>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>  On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> >> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> >>> On Fri, 25 Jul 2014, Michael Welling wrote:
> >>>
>  The plot thickens
> 
>  So if I run the above command before anything is plugged into the 
>  ports
>  the HUB disconnects.
> 
>  root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>  [   63.068839] usb 1-1: USB disconnect, device number 2
> 
>  Here is the output of the usbmon output when running the above 
>  command:
>  root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>  de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>  de382e40 3788890604 C Ci:001:00 0 4 = 0705
>  de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>  de382e40 3788893093 C Ci:001:00 0 4 = 0001
>  de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>  de382e40 3788894958 C Ci:001:00 0 4 = 0001
>  de7d92c0 3788896519 S Ii:001:01 -115 4 <
>  de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>  de382e40 3788900188 C Ci:001:00 0 4 = 0705
>  de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>  de382e40 3788905793 C Co:001:00 0 0
>  de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>  de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>  de7d92c0 3788943013 S Ii:001:01 -115 4 <
>  de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>  de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>  de382e40 3788961175 C Co:001:00 0 0
>  de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>  de382e40 3788965395 C Ci:002:00 -71 0
>  de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>  de249040 3788968362 C Co:001:00 0 0
>  de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>  de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>  de7d92c0 378906 S Ii:001:01 -115 4 <
>  de249040 3789023423 C Ci:001:00 0 4 = 01051200
>  de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>  de249040 3789026815 C Co:001:00 0 0
>  de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>  de249040 378923 C Ci:001:00 0 4 = 00010300
>  de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>  de249040 3789232404 C Co:001:00 0 0
>  de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>  de249040 3789235345 C Co:001:00 0 0
>  de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>  de249040 3789237201 C Co:001:00 0 0
>  de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>  de249040 3789238510 C Co:001:00 0 0
>  de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>  de249040 3789241661 C Ci:001:00 0 4 = 00010300
>  de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>  de249040 3789243921 C Co:001:00 0 0
>  de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>  de249040 3789246930 C Co:001:00 0 0
>  de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>  de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>  de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>  de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>  de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>  de7d92c0 3789452462 C Ii:001:01 -2 0
> 
>  Not sure what any of it means.
> >>>
> >>> Basically it means what you said above: the hub disconnected.  I 
> >>> can't 
> >>> tell why.  You'll have to ask someone who's familiar with the 
> >>> hardware 
> >>> on that board.
> >>
> >> Sadly, there is no one more familar with this specific hardware than 
> >> myself.
> >>
> >> I can however ellaborate the hardware setup of the USB subsystem in
> >> case there is someone out there that has used a similar setup.
> >>
> >> The board uses the AM3517 SoC from TI. The SoC's USB host port 
> >> (HSUSB1) is
> >> c

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-31 Thread Stefan Herbrechtsmeier


Am 29.07.2014 17:20, schrieb Michael Welling:

On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:

Hi Michael,

On 07/28/2014 09:10 PM, Felipe Balbi wrote:

On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:

On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:

Hi,

On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:

On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:

On Fri, 25 Jul 2014, Michael Welling wrote:


The plot thickens

So if I run the above command before anything is plugged into the ports
the HUB disconnects.

root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
[   63.068839] usb 1-1: USB disconnect, device number 2

Here is the output of the usbmon output when running the above command:
root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
de382e40 3788890604 C Ci:001:00 0 4 = 0705
de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
de382e40 3788893093 C Ci:001:00 0 4 = 0001
de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
de382e40 3788894958 C Ci:001:00 0 4 = 0001
de7d92c0 3788896519 S Ii:001:01 -115 4 <
de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
de382e40 3788900188 C Ci:001:00 0 4 = 0705
de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
de382e40 3788905793 C Co:001:00 0 0
de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
de7d92c0 3788942065 C Ii:001:01 0 1 = 02
de7d92c0 3788943013 S Ii:001:01 -115 4 <
de382e40 3788943145 C Ci:001:00 0 4 = 03050400
de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
de382e40 3788961175 C Co:001:00 0 0
de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
de382e40 3788965395 C Ci:002:00 -71 0
de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
de249040 3788968362 C Co:001:00 0 0
de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
de7d92c0 3789022194 C Ii:001:01 0 1 = 02
de7d92c0 378906 S Ii:001:01 -115 4 <
de249040 3789023423 C Ci:001:00 0 4 = 01051200
de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
de249040 3789026815 C Co:001:00 0 0
de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
de249040 378923 C Ci:001:00 0 4 = 00010300
de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
de249040 3789232404 C Co:001:00 0 0
de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
de249040 3789235345 C Co:001:00 0 0
de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
de249040 3789237201 C Co:001:00 0 0
de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
de249040 3789238510 C Co:001:00 0 0
de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
de249040 3789241661 C Ci:001:00 0 4 = 00010300
de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
de249040 3789243921 C Co:001:00 0 0
de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
de249040 3789246930 C Co:001:00 0 0
de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789286255 C Ci:001:00 0 4 = 0001
de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789332606 C Ci:001:00 0 4 = 0001
de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789371146 C Ci:001:00 0 4 = 0001
de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789411097 C Ci:001:00 0 4 = 0001
de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789451081 C Ci:001:00 0 4 = 0001
de7d92c0 3789452462 C Ii:001:01 -2 0

Not sure what any of it means.

Basically it means what you said above: the hub disconnected.  I can't
tell why.  You'll have to ask someone who's familiar with the hardware
on that board.

Sadly, there is no one more familar with this specific hardware than myself.

I can however ellaborate the hardware setup of the USB subsystem in
case there is someone out there that has used a similar setup.

The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is
connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
provide two downstream USB ports.

The very same hardware worked with the 2.6.37 kernel that I am trying to
move away from.

It should be noted that the USB hardware work on the 3.2 kernel as well.


Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
the same behavior.

It should be noted that the 3.10 kernel did not even detect the external
HUB and the 3.14 kernel exhibits the same failure as 3.16.


Do you have off-while-idle enabled ? This could be, as Alan suggested, a
problem with remote wakeup. EHCI on TI parts is kinda awkward, if you
will, and getting remote wakeup with PM working, is generally a
challenge.

How would one determine if off-while-idle is enabled? Is this a flag in an
entry in the devicetree?

there is a pm_debug file on debugfs which you can use. Set autosuspend
delay to UART (it's set to -1 by default, IIRC), then leave the board
idle for a couple minutes, then read /sys/kernel/debug/pm_debug and see
if the

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-30 Thread Michael Welling

On Wed, Jul 30, 2014 at 1:59 PM, Michael Welling  wrote:
> On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
>> On 07/29/2014 06:20 PM, Michael Welling wrote:
>> > On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
>> >> Hi Michael,
>> >>
>> >> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
>> >>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>>  On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
>> >> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
>> >>> On Fri, 25 Jul 2014, Michael Welling wrote:
>> >>>
>>  The plot thickens
>> 
>>  So if I run the above command before anything is plugged into the 
>>  ports
>>  the HUB disconnects.
>> 
>>  root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>>  [   63.068839] usb 1-1: USB disconnect, device number 2
>> 
>>  Here is the output of the usbmon output when running the above 
>>  command:
>>  root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>>  de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de382e40 3788890604 C Ci:001:00 0 4 = 0705
>>  de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>>  de382e40 3788893093 C Ci:001:00 0 4 = 0001
>>  de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>>  de382e40 3788894958 C Ci:001:00 0 4 = 0001
>>  de7d92c0 3788896519 S Ii:001:01 -115 4 <
>>  de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de382e40 3788900188 C Ci:001:00 0 4 = 0705
>>  de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>>  de382e40 3788905793 C Co:001:00 0 0
>>  de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>>  de7d92c0 3788943013 S Ii:001:01 -115 4 <
>>  de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>>  de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>>  de382e40 3788961175 C Co:001:00 0 0
>>  de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>>  de382e40 3788965395 C Ci:002:00 -71 0
>>  de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>>  de249040 3788968362 C Co:001:00 0 0
>>  de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>>  de7d92c0 378906 S Ii:001:01 -115 4 <
>>  de249040 3789023423 C Ci:001:00 0 4 = 01051200
>>  de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>>  de249040 3789026815 C Co:001:00 0 0
>>  de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de249040 378923 C Ci:001:00 0 4 = 00010300
>>  de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>>  de249040 3789232404 C Co:001:00 0 0
>>  de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>>  de249040 3789235345 C Co:001:00 0 0
>>  de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>>  de249040 3789237201 C Co:001:00 0 0
>>  de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>>  de249040 3789238510 C Co:001:00 0 0
>>  de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de249040 3789241661 C Ci:001:00 0 4 = 00010300
>>  de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>>  de249040 3789243921 C Co:001:00 0 0
>>  de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>>  de249040 3789246930 C Co:001:00 0 0
>>  de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>>  de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>>  de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>>  de7d92c0 3789452462 C Ii:001:01 -2 0
>> 
>>  Not sure what any of it means.
>> >>>
>> >>> Basically it means what you said above: the hub disconnected.  I 
>> >>> can't
>> >>> tell why.  You'll have to ask someone who's familiar with the 
>> >>> hardware
>> >>> on that board.
>> >>
>> >> Sadly, there is no one more familar with this specific hardware than 
>> >> myself.
>> >>
>> >> I can however ellaborate the hardware setup of the USB subsystem in
>> >> case there is someone out

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-30 Thread Michael Welling

On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
> On 07/29/2014 06:20 PM, Michael Welling wrote:
> > On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
> >> Hi Michael,
> >>
> >> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
> >>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>  On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> >> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> >>> On Fri, 25 Jul 2014, Michael Welling wrote:
> >>>
>  The plot thickens
> 
>  So if I run the above command before anything is plugged into the 
>  ports
>  the HUB disconnects.
> 
>  root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>  [   63.068839] usb 1-1: USB disconnect, device number 2
> 
>  Here is the output of the usbmon output when running the above 
>  command:
>  root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>  de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>  de382e40 3788890604 C Ci:001:00 0 4 = 0705
>  de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>  de382e40 3788893093 C Ci:001:00 0 4 = 0001
>  de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>  de382e40 3788894958 C Ci:001:00 0 4 = 0001
>  de7d92c0 3788896519 S Ii:001:01 -115 4 <
>  de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>  de382e40 3788900188 C Ci:001:00 0 4 = 0705
>  de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>  de382e40 3788905793 C Co:001:00 0 0
>  de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>  de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>  de7d92c0 3788943013 S Ii:001:01 -115 4 <
>  de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>  de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>  de382e40 3788961175 C Co:001:00 0 0
>  de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>  de382e40 3788965395 C Ci:002:00 -71 0
>  de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>  de249040 3788968362 C Co:001:00 0 0
>  de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>  de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>  de7d92c0 378906 S Ii:001:01 -115 4 <
>  de249040 3789023423 C Ci:001:00 0 4 = 01051200
>  de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>  de249040 3789026815 C Co:001:00 0 0
>  de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>  de249040 378923 C Ci:001:00 0 4 = 00010300
>  de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>  de249040 3789232404 C Co:001:00 0 0
>  de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>  de249040 3789235345 C Co:001:00 0 0
>  de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>  de249040 3789237201 C Co:001:00 0 0
>  de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>  de249040 3789238510 C Co:001:00 0 0
>  de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>  de249040 3789241661 C Ci:001:00 0 4 = 00010300
>  de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>  de249040 3789243921 C Co:001:00 0 0
>  de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>  de249040 3789246930 C Co:001:00 0 0
>  de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>  de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>  de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>  de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>  de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>  de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>  de7d92c0 3789452462 C Ii:001:01 -2 0
> 
>  Not sure what any of it means.
> >>>
> >>> Basically it means what you said above: the hub disconnected.  I 
> >>> can't 
> >>> tell why.  You'll have to ask someone who's familiar with the 
> >>> hardware 
> >>> on that board.
> >>
> >> Sadly, there is no one more familar with this specific hardware than 
> >> myself.
> >>
> >> I can however ellaborate the hardware setup of the USB subsystem in
> >> case there is someone out there that has used a similar setup.
> >>
> >> The board uses the AM3517 SoC from TI. The SoC's USB host port 
> >> (HSUSB1) is
> >> c

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-30 Thread Roger Quadros

On 07/29/2014 06:20 PM, Michael Welling wrote:
> On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
>> Hi Michael,
>>
>> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
>>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
 On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
>> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
>>> On Fri, 25 Jul 2014, Michael Welling wrote:
>>>
 The plot thickens

 So if I run the above command before anything is plugged into the ports
 the HUB disconnects.

 root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
 [   63.068839] usb 1-1: USB disconnect, device number 2

 Here is the output of the usbmon output when running the above command:
 root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
 de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
 de382e40 3788890604 C Ci:001:00 0 4 = 0705
 de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
 de382e40 3788893093 C Ci:001:00 0 4 = 0001
 de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
 de382e40 3788894958 C Ci:001:00 0 4 = 0001
 de7d92c0 3788896519 S Ii:001:01 -115 4 <
 de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
 de382e40 3788900188 C Ci:001:00 0 4 = 0705
 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
 de382e40 3788905793 C Co:001:00 0 0
 de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
 de7d92c0 3788942065 C Ii:001:01 0 1 = 02
 de7d92c0 3788943013 S Ii:001:01 -115 4 <
 de382e40 3788943145 C Ci:001:00 0 4 = 03050400
 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
 de382e40 3788961175 C Co:001:00 0 0
 de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
 de382e40 3788965395 C Ci:002:00 -71 0
 de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
 de249040 3788968362 C Co:001:00 0 0
 de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
 de7d92c0 3789022194 C Ii:001:01 0 1 = 02
 de7d92c0 378906 S Ii:001:01 -115 4 <
 de249040 3789023423 C Ci:001:00 0 4 = 01051200
 de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
 de249040 3789026815 C Co:001:00 0 0
 de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
 de249040 378923 C Ci:001:00 0 4 = 00010300
 de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
 de249040 3789232404 C Co:001:00 0 0
 de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
 de249040 3789235345 C Co:001:00 0 0
 de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
 de249040 3789237201 C Co:001:00 0 0
 de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
 de249040 3789238510 C Co:001:00 0 0
 de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
 de249040 3789241661 C Ci:001:00 0 4 = 00010300
 de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
 de249040 3789243921 C Co:001:00 0 0
 de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
 de249040 3789246930 C Co:001:00 0 0
 de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
 de2490c0 3789286255 C Ci:001:00 0 4 = 0001
 de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
 de2490c0 3789332606 C Ci:001:00 0 4 = 0001
 de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
 de2490c0 3789371146 C Ci:001:00 0 4 = 0001
 de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
 de2490c0 3789411097 C Ci:001:00 0 4 = 0001
 de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
 de2490c0 3789451081 C Ci:001:00 0 4 = 0001
 de7d92c0 3789452462 C Ii:001:01 -2 0

 Not sure what any of it means.
>>>
>>> Basically it means what you said above: the hub disconnected.  I can't 
>>> tell why.  You'll have to ask someone who's familiar with the hardware 
>>> on that board.
>>
>> Sadly, there is no one more familar with this specific hardware than 
>> myself.
>>
>> I can however ellaborate the hardware setup of the USB subsystem in
>> case there is someone out there that has used a similar setup.
>>
>> The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) 
>> is
>> connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
>> provide two downstream USB ports.
>>
>> The very same hardware worked with the 2.6.37 kernel that I am trying to
>> move away from.
> 
> It should be noted that the USB hardware work on the 3.2 kernel as w

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-29 Thread Alan Stern

On Tue, 29 Jul 2014, Michael Welling wrote:

> Today I enabled debugging in the core hub driver and found that
> once the external HUB suspends, the root HUB suspends.

Naturally.  You can prevent that by forcing the root hub to remain 
active.

> Once the root HUB suspends, it seems there is no way for the external
> HUB to wake the root HUB with the hardware setup that I have.

> Here is what happens when I echo on into the power control for the HUB
> afterwards:
> 
> root@som3517:/# echo on > /sys/bus/usb/devices/1-1/power/control
> [ 1050.003689] hub 1-0:1.0: hub_resume
> [ 1050.011306] usb usb1-port1: status 0507 change 
> [ 1050.019975] hub 1-0:1.0: state 7 ports 3 chg  evt 
> [ 1050.028076] usb 1-1: usb auto-resume
> [ 1050.065904] hub 1-0:1.0: state 7 ports 3 chg  evt 0002
> [ 1050.084623] usb 1-1: finish resume
> [ 1050.092469] usb 1-1: retry with reset-resume
> [ 1050.156167] hub 1-0:1.0: port_wait_reset: err = -16
> [ 1050.161331] usb usb1-port1: not enabled, trying reset again...
> [ 1050.376402] usb usb1-port1: logical disconnect
> [ 1050.381354] usb 1-1: gone after usb resume? status -19
> [ 1050.386941] usb 1-1: can't resume, status -19
> [ 1050.391537] usb usb1-port1: logical disconnect
> [ 1050.400203] usb usb1-port1: status 0100, change 0003, 12 Mb/s
> [ 1050.406410] usb 1-1: USB disconnect, device number 2
> [ 1050.411650] usb 1-1: unregistering device
> [ 1050.604563] usb usb1-port1: debounce total 100ms stable 100ms status 0x100
> [ 1050.611901] hub 1-0:1.0: state 7 ports 3 chg  evt 
> [ 1050.618428] hub 1-0:1.0: hub_suspend

The hub disconnects.

> Further research led me to find multiple errata that may be causing this
> issue.
> 
> www.ti.com/lit/pdf/sprz306

That 1.1.18 advisory looks pretty bad.

> Still does not explain why the same hardware works with the 2.6.37 and
> 3.2 kernels.

Maybe you should try bisection.  It's slow but it gives you an answer.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-29 Thread Michael Welling

On Tue, Jul 29, 2014 at 12:51:45AM -0700, Tony Lindgren wrote:
> * Felipe Balbi  [140728 11:13]:
> > On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
> > > On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> > > > > > 
> > > > > > Basically it means what you said above: the hub disconnected.  I 
> > > > > > can't 
> > > > > > tell why.  You'll have to ask someone who's familiar with the 
> > > > > > hardware 
> > > > > > on that board.
> > > > > 
> > > > > Sadly, there is no one more familar with this specific hardware than 
> > > > > myself.
> > > > > 
> > > > > I can however ellaborate the hardware setup of the USB subsystem in
> > > > > case there is someone out there that has used a similar setup.
> > > > > 
> > > > > The board uses the AM3517 SoC from TI. The SoC's USB host port 
> > > > > (HSUSB1) is
> > > > > connected to a USB3320 PHY. The PHY is connected to a USB2512 switch 
> > > > > to
> > > > > provide two downstream USB ports.
> > > > > 
> > > > > The very same hardware worked with the 2.6.37 kernel that I am trying 
> > > > > to
> > > > > move away from.
> > > > > 
> > > > > Today I am going to try using 3.10 and 3.14 kernels see if they 
> > > > > exhibit
> > > > > the same behavior.
> > > > 
> > > 
> > > It should be noted that the 3.10 kernel did not even detect the external
> > > HUB and the 3.14 kernel exhibits the same failure as 3.16.
> > > 
> > > > Do you have off-while-idle enabled ? This could be, as Alan suggested, a
> > > > problem with remote wakeup. EHCI on TI parts is kinda awkward, if you
> > > > will, and getting remote wakeup with PM working, is generally a
> > > > challenge.
> > > 
> > > How would one determine if off-while-idle is enabled? Is this a flag in an
> > > entry in the devicetree?
> > 
> > there is a pm_debug file on debugfs which you can use. Set autosuspend
> > delay to UART (it's set to -1 by default, IIRC), then leave the board
> > idle for a couple minutes, then read /sys/kernel/debug/pm_debug and see
> > if the OFF() counters are increasing.
> > 
> > Adding linux-omap to Cc. Also Tony, who has a simple script to enable
> > pm_runtime on UART.
> 
> I doubt that you have off-while-idle enabled as you need to manually
> enable the timeouts for UARTs for it to trigger :) I would check the
> related power and clock lines with a scope to see if there are glitches
> on them.
> 
> In any case, would be nice to have this EHCI stuff be sorted out for
> good in the mainline kernel as we do have things working pretty well
> for other things.

Today I enabled debugging in the core hub driver and found that
once the external HUB suspends, the root HUB suspends.

Once the root HUB suspends, it seems there is no way for the external
HUB to wake the root HUB with the hardware setup that I have.

root@som3517:~# dmesg | grep hub
[0.617964] usbcore: registered new interface driver hub
[2.818449] hub 1-0:1.0: USB hub found
[2.822980] hub 1-0:1.0: 3 ports detected
[2.827354] hub 1-0:1.0: standalone hub
[2.831402] hub 1-0:1.0: individual port power switching
[2.837067] hub 1-0:1.0: individual port over-current protection
[2.843400] hub 1-0:1.0: power on to power good time: 20ms
[2.851414] hub 1-0:1.0: local power source is good
[2.860133] hub 1-0:1.0: enabling power on all ports
[3.169607] hub 1-0:1.0: state 7 ports 3 chg 0002 evt 
[3.584251] hub 1-1:1.0: USB hub found
[3.592571] hub 1-1:1.0: 2 ports detected
[3.597095] hub 1-1:1.0: standalone hub
[3.601187] hub 1-1:1.0: individual port power switching
[3.606875] hub 1-1:1.0: individual port over-current protection
[3.614899] hub 1-1:1.0: TT per port
[3.618711] hub 1-1:1.0: TT requires at most 8 FS bit times (666 ns)
[3.625558] hub 1-1:1.0: power on to power good time: 100ms
[3.654652] hub 1-1:1.0: local power source is good
[3.662134] hub 1-1:1.0: enabling power on all ports
[3.766183] hub 1-1:1.0: state 7 ports 2 chg  evt 
[3.772116] hub 1-1:1.0: hub_suspend
[3.804789] hub 1-0:1.0: hub_suspend

Here is what happens when I echo on into the power control for the HUB
afterwards:

root@som3517:/# echo on > /sys/bus/usb/devices/1-1/power/control
[ 1050.003689] hub 1-0:1.0: hub_resume
[ 1050.011306] usb usb1-port1: status 0507 change 
[ 1050.019975] hub 1-0:1.0: state 7 ports 3 chg  evt 
[ 1050.028076] usb 1-1: usb auto-resume
[ 1050.065904] hub 1-0:1.0: state 7 ports 3 chg  evt 0002
[ 1050.084623] usb 1-1: finish resume
[ 1050.092469] usb 1-1: retry with reset-resume
[ 1050.156167] hub 1-0:1.0: port_wait_reset: err = -16
[ 1050.161331] usb usb1-port1: not enabled, trying reset again...
[ 1050.376402] usb usb1-port1: logical disconnect
[ 1050.381354] usb 1-1: gone after usb resume? status -19
[ 1050.386941] usb 1-1: can't resume, status -19
[ 1050.391537] usb usb1-port1: logical disconnect
[ 1050.400203] usb usb1-port1: status 0100, change 0003, 12 Mb/s
[ 1050.406410] usb 1-1: USB disco

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-29 Thread Michael Welling

On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
> Hi Michael,
> 
> On 07/28/2014 09:10 PM, Felipe Balbi wrote:
> > On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
> >> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
>  On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> > On Fri, 25 Jul 2014, Michael Welling wrote:
> >
> >> The plot thickens
> >>
> >> So if I run the above command before anything is plugged into the ports
> >> the HUB disconnects.
> >>
> >> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> >> [   63.068839] usb 1-1: USB disconnect, device number 2
> >>
> >> Here is the output of the usbmon output when running the above command:
> >> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> >> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de382e40 3788890604 C Ci:001:00 0 4 = 0705
> >> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> >> de382e40 3788893093 C Ci:001:00 0 4 = 0001
> >> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> >> de382e40 3788894958 C Ci:001:00 0 4 = 0001
> >> de7d92c0 3788896519 S Ii:001:01 -115 4 <
> >> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de382e40 3788900188 C Ci:001:00 0 4 = 0705
> >> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> >> de382e40 3788905793 C Co:001:00 0 0
> >> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> >> de7d92c0 3788943013 S Ii:001:01 -115 4 <
> >> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> >> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> >> de382e40 3788961175 C Co:001:00 0 0
> >> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> >> de382e40 3788965395 C Ci:002:00 -71 0
> >> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> >> de249040 3788968362 C Co:001:00 0 0
> >> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> >> de7d92c0 378906 S Ii:001:01 -115 4 <
> >> de249040 3789023423 C Ci:001:00 0 4 = 01051200
> >> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> >> de249040 3789026815 C Co:001:00 0 0
> >> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de249040 378923 C Ci:001:00 0 4 = 00010300
> >> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> >> de249040 3789232404 C Co:001:00 0 0
> >> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> >> de249040 3789235345 C Co:001:00 0 0
> >> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> >> de249040 3789237201 C Co:001:00 0 0
> >> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> >> de249040 3789238510 C Co:001:00 0 0
> >> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de249040 3789241661 C Ci:001:00 0 4 = 00010300
> >> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> >> de249040 3789243921 C Co:001:00 0 0
> >> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> >> de249040 3789246930 C Co:001:00 0 0
> >> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> >> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> >> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> >> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> >> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> >> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> >> de7d92c0 3789452462 C Ii:001:01 -2 0
> >>
> >> Not sure what any of it means.
> >
> > Basically it means what you said above: the hub disconnected.  I can't 
> > tell why.  You'll have to ask someone who's familiar with the hardware 
> > on that board.
> 
>  Sadly, there is no one more familar with this specific hardware than 
>  myself.
> 
>  I can however ellaborate the hardware setup of the USB subsystem in
>  case there is someone out there that has used a similar setup.
> 
>  The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) 
>  is
>  connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
>  provide two downstream USB ports.
> 
>  The very same hardware worked with the 2.6.37 kernel that I am trying to
>  move away from.

It should be noted that the USB hardware work on the 3.2 kernel as well.

> 
>  Today I am going to try using 3.10

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-29 Thread Roger Quadros

Hi Michael,

On 07/28/2014 09:10 PM, Felipe Balbi wrote:
> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
>> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
 On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> On Fri, 25 Jul 2014, Michael Welling wrote:
>
>> The plot thickens
>>
>> So if I run the above command before anything is plugged into the ports
>> the HUB disconnects.
>>
>> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>> [   63.068839] usb 1-1: USB disconnect, device number 2
>>
>> Here is the output of the usbmon output when running the above command:
>> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
>> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
>> de382e40 3788890604 C Ci:001:00 0 4 = 0705
>> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
>> de382e40 3788893093 C Ci:001:00 0 4 = 0001
>> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
>> de382e40 3788894958 C Ci:001:00 0 4 = 0001
>> de7d92c0 3788896519 S Ii:001:01 -115 4 <
>> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
>> de382e40 3788900188 C Ci:001:00 0 4 = 0705
>> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
>> de382e40 3788905793 C Co:001:00 0 0
>> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
>> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
>> de7d92c0 3788943013 S Ii:001:01 -115 4 <
>> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
>> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
>> de382e40 3788961175 C Co:001:00 0 0
>> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
>> de382e40 3788965395 C Ci:002:00 -71 0
>> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
>> de249040 3788968362 C Co:001:00 0 0
>> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
>> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
>> de7d92c0 378906 S Ii:001:01 -115 4 <
>> de249040 3789023423 C Ci:001:00 0 4 = 01051200
>> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
>> de249040 3789026815 C Co:001:00 0 0
>> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
>> de249040 378923 C Ci:001:00 0 4 = 00010300
>> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
>> de249040 3789232404 C Co:001:00 0 0
>> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
>> de249040 3789235345 C Co:001:00 0 0
>> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
>> de249040 3789237201 C Co:001:00 0 0
>> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
>> de249040 3789238510 C Co:001:00 0 0
>> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
>> de249040 3789241661 C Ci:001:00 0 4 = 00010300
>> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
>> de249040 3789243921 C Co:001:00 0 0
>> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
>> de249040 3789246930 C Co:001:00 0 0
>> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
>> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
>> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
>> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
>> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
>> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
>> de7d92c0 3789452462 C Ii:001:01 -2 0
>>
>> Not sure what any of it means.
>
> Basically it means what you said above: the hub disconnected.  I can't 
> tell why.  You'll have to ask someone who's familiar with the hardware 
> on that board.

 Sadly, there is no one more familar with this specific hardware than 
 myself.

 I can however ellaborate the hardware setup of the USB subsystem in
 case there is someone out there that has used a similar setup.

 The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is
 connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
 provide two downstream USB ports.

 The very same hardware worked with the 2.6.37 kernel that I am trying to
 move away from.

 Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
 the same behavior.
>>>
>>
>> It should be noted that the 3.10 kernel did not even detect the external
>> HUB and the 3.14 kernel exhibits the same failure as 3.16.
>>
>>> Do you have off-while-idle enabled ? This could be, as Alan suggested, a
>>> problem with remote wakeup. EHCI on TI parts is

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-29 Thread Tony Lindgren

* Felipe Balbi  [140728 11:13]:
> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
> > On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> > > > > 
> > > > > Basically it means what you said above: the hub disconnected.  I 
> > > > > can't 
> > > > > tell why.  You'll have to ask someone who's familiar with the 
> > > > > hardware 
> > > > > on that board.
> > > > 
> > > > Sadly, there is no one more familar with this specific hardware than 
> > > > myself.
> > > > 
> > > > I can however ellaborate the hardware setup of the USB subsystem in
> > > > case there is someone out there that has used a similar setup.
> > > > 
> > > > The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) 
> > > > is
> > > > connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
> > > > provide two downstream USB ports.
> > > > 
> > > > The very same hardware worked with the 2.6.37 kernel that I am trying to
> > > > move away from.
> > > > 
> > > > Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
> > > > the same behavior.
> > > 
> > 
> > It should be noted that the 3.10 kernel did not even detect the external
> > HUB and the 3.14 kernel exhibits the same failure as 3.16.
> > 
> > > Do you have off-while-idle enabled ? This could be, as Alan suggested, a
> > > problem with remote wakeup. EHCI on TI parts is kinda awkward, if you
> > > will, and getting remote wakeup with PM working, is generally a
> > > challenge.
> > 
> > How would one determine if off-while-idle is enabled? Is this a flag in an
> > entry in the devicetree?
> 
> there is a pm_debug file on debugfs which you can use. Set autosuspend
> delay to UART (it's set to -1 by default, IIRC), then leave the board
> idle for a couple minutes, then read /sys/kernel/debug/pm_debug and see
> if the OFF() counters are increasing.
> 
> Adding linux-omap to Cc. Also Tony, who has a simple script to enable
> pm_runtime on UART.

I doubt that you have off-while-idle enabled as you need to manually
enable the timeouts for UARTs for it to trigger :) I would check the
related power and clock lines with a scope to see if there are glitches
on them.

In any case, would be nice to have this EHCI stuff be sorted out for
good in the mainline kernel as we do have things working pretty well
for other things.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-28 Thread Felipe Balbi

On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> > > On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> > > > On Fri, 25 Jul 2014, Michael Welling wrote:
> > > > 
> > > > > The plot thickens
> > > > > 
> > > > > So if I run the above command before anything is plugged into the 
> > > > > ports
> > > > > the HUB disconnects.
> > > > > 
> > > > > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> > > > > [   63.068839] usb 1-1: USB disconnect, device number 2
> > > > > 
> > > > > Here is the output of the usbmon output when running the above 
> > > > > command:
> > > > > root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> > > > > de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de382e40 3788890604 C Ci:001:00 0 4 = 0705
> > > > > de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> > > > > de382e40 3788893093 C Ci:001:00 0 4 = 0001
> > > > > de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> > > > > de382e40 3788894958 C Ci:001:00 0 4 = 0001
> > > > > de7d92c0 3788896519 S Ii:001:01 -115 4 <
> > > > > de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de382e40 3788900188 C Ci:001:00 0 4 = 0705
> > > > > de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> > > > > de382e40 3788905793 C Co:001:00 0 0
> > > > > de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> > > > > de7d92c0 3788943013 S Ii:001:01 -115 4 <
> > > > > de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> > > > > de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> > > > > de382e40 3788961175 C Co:001:00 0 0
> > > > > de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> > > > > de382e40 3788965395 C Ci:002:00 -71 0
> > > > > de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> > > > > de249040 3788968362 C Co:001:00 0 0
> > > > > de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> > > > > de7d92c0 378906 S Ii:001:01 -115 4 <
> > > > > de249040 3789023423 C Ci:001:00 0 4 = 01051200
> > > > > de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> > > > > de249040 3789026815 C Co:001:00 0 0
> > > > > de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de249040 378923 C Ci:001:00 0 4 = 00010300
> > > > > de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> > > > > de249040 3789232404 C Co:001:00 0 0
> > > > > de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> > > > > de249040 3789235345 C Co:001:00 0 0
> > > > > de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> > > > > de249040 3789237201 C Co:001:00 0 0
> > > > > de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> > > > > de249040 3789238510 C Co:001:00 0 0
> > > > > de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de249040 3789241661 C Ci:001:00 0 4 = 00010300
> > > > > de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> > > > > de249040 3789243921 C Co:001:00 0 0
> > > > > de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> > > > > de249040 3789246930 C Co:001:00 0 0
> > > > > de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> > > > > de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> > > > > de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> > > > > de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> > > > > de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > > de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> > > > > de7d92c0 3789452462 C Ii:001:01 -2 0
> > > > > 
> > > > > Not sure what any of it means.
> > > > 
> > > > Basically it means what you said above: the hub disconnected.  I can't 
> > > > tell why.  You'll have to ask someone who's familiar with the hardware 
> > > > on that board.
> > > 
> > > Sadly, there is no one more familar with this specific hardware than 
> > > myself.
> > > 
> > > I can however ellaborate the hardware setup of the USB subsystem in
> > > case there is someone out there that has used a similar setup.
> > > 
> > > The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is
> > > connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
> > > provide two downstream USB ports.
> > > 
> > > The very same hardware worked with the 2.6.37 kernel that I am trying to
> > > move away from.
> > > 
> > > Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
> > > the same behavior.
> > 
> 
> It should be noted that the 3.10 kernel did not even detect the ex

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-28 Thread Michael Welling

On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> > On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> > > On Fri, 25 Jul 2014, Michael Welling wrote:
> > > 
> > > > The plot thickens
> > > > 
> > > > So if I run the above command before anything is plugged into the ports
> > > > the HUB disconnects.
> > > > 
> > > > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> > > > [   63.068839] usb 1-1: USB disconnect, device number 2
> > > > 
> > > > Here is the output of the usbmon output when running the above command:
> > > > root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> > > > de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de382e40 3788890604 C Ci:001:00 0 4 = 0705
> > > > de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> > > > de382e40 3788893093 C Ci:001:00 0 4 = 0001
> > > > de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> > > > de382e40 3788894958 C Ci:001:00 0 4 = 0001
> > > > de7d92c0 3788896519 S Ii:001:01 -115 4 <
> > > > de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de382e40 3788900188 C Ci:001:00 0 4 = 0705
> > > > de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> > > > de382e40 3788905793 C Co:001:00 0 0
> > > > de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> > > > de7d92c0 3788943013 S Ii:001:01 -115 4 <
> > > > de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> > > > de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> > > > de382e40 3788961175 C Co:001:00 0 0
> > > > de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> > > > de382e40 3788965395 C Ci:002:00 -71 0
> > > > de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> > > > de249040 3788968362 C Co:001:00 0 0
> > > > de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> > > > de7d92c0 378906 S Ii:001:01 -115 4 <
> > > > de249040 3789023423 C Ci:001:00 0 4 = 01051200
> > > > de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> > > > de249040 3789026815 C Co:001:00 0 0
> > > > de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de249040 378923 C Ci:001:00 0 4 = 00010300
> > > > de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> > > > de249040 3789232404 C Co:001:00 0 0
> > > > de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> > > > de249040 3789235345 C Co:001:00 0 0
> > > > de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> > > > de249040 3789237201 C Co:001:00 0 0
> > > > de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> > > > de249040 3789238510 C Co:001:00 0 0
> > > > de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de249040 3789241661 C Ci:001:00 0 4 = 00010300
> > > > de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> > > > de249040 3789243921 C Co:001:00 0 0
> > > > de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> > > > de249040 3789246930 C Co:001:00 0 0
> > > > de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> > > > de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> > > > de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> > > > de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> > > > de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> > > > de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> > > > de7d92c0 3789452462 C Ii:001:01 -2 0
> > > > 
> > > > Not sure what any of it means.
> > > 
> > > Basically it means what you said above: the hub disconnected.  I can't 
> > > tell why.  You'll have to ask someone who's familiar with the hardware 
> > > on that board.
> > 
> > Sadly, there is no one more familar with this specific hardware than myself.
> > 
> > I can however ellaborate the hardware setup of the USB subsystem in
> > case there is someone out there that has used a similar setup.
> > 
> > The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is
> > connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
> > provide two downstream USB ports.
> > 
> > The very same hardware worked with the 2.6.37 kernel that I am trying to
> > move away from.
> > 
> > Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
> > the same behavior.
> 

It should be noted that the 3.10 kernel did not even detect the external
HUB and the 3.14 kernel exhibits the same failure as 3.16.

> Do you have off-while-idle enabled ? This could be, as Alan suggested, a
> problem with remote wakeup. EHCI on TI parts is kinda awkward, if you
> will, and getting remote wakeup with PM working, is generally a
> ch

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-28 Thread Felipe Balbi

Hi,

On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> > On Fri, 25 Jul 2014, Michael Welling wrote:
> > 
> > > The plot thickens
> > > 
> > > So if I run the above command before anything is plugged into the ports
> > > the HUB disconnects.
> > > 
> > > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> > > [   63.068839] usb 1-1: USB disconnect, device number 2
> > > 
> > > Here is the output of the usbmon output when running the above command:
> > > root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> > > de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de382e40 3788890604 C Ci:001:00 0 4 = 0705
> > > de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> > > de382e40 3788893093 C Ci:001:00 0 4 = 0001
> > > de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> > > de382e40 3788894958 C Ci:001:00 0 4 = 0001
> > > de7d92c0 3788896519 S Ii:001:01 -115 4 <
> > > de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de382e40 3788900188 C Ci:001:00 0 4 = 0705
> > > de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> > > de382e40 3788905793 C Co:001:00 0 0
> > > de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> > > de7d92c0 3788943013 S Ii:001:01 -115 4 <
> > > de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> > > de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> > > de382e40 3788961175 C Co:001:00 0 0
> > > de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> > > de382e40 3788965395 C Ci:002:00 -71 0
> > > de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> > > de249040 3788968362 C Co:001:00 0 0
> > > de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> > > de7d92c0 378906 S Ii:001:01 -115 4 <
> > > de249040 3789023423 C Ci:001:00 0 4 = 01051200
> > > de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> > > de249040 3789026815 C Co:001:00 0 0
> > > de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de249040 378923 C Ci:001:00 0 4 = 00010300
> > > de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> > > de249040 3789232404 C Co:001:00 0 0
> > > de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> > > de249040 3789235345 C Co:001:00 0 0
> > > de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> > > de249040 3789237201 C Co:001:00 0 0
> > > de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> > > de249040 3789238510 C Co:001:00 0 0
> > > de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de249040 3789241661 C Ci:001:00 0 4 = 00010300
> > > de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> > > de249040 3789243921 C Co:001:00 0 0
> > > de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> > > de249040 3789246930 C Co:001:00 0 0
> > > de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> > > de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> > > de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> > > de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> > > de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> > > de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> > > de7d92c0 3789452462 C Ii:001:01 -2 0
> > > 
> > > Not sure what any of it means.
> > 
> > Basically it means what you said above: the hub disconnected.  I can't 
> > tell why.  You'll have to ask someone who's familiar with the hardware 
> > on that board.
> 
> Sadly, there is no one more familar with this specific hardware than myself.
> 
> I can however ellaborate the hardware setup of the USB subsystem in
> case there is someone out there that has used a similar setup.
> 
> The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is
> connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
> provide two downstream USB ports.
> 
> The very same hardware worked with the 2.6.37 kernel that I am trying to
> move away from.
> 
> Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
> the same behavior.

Do you have off-while-idle enabled ? This could be, as Alan suggested, a
problem with remote wakeup. EHCI on TI parts is kinda awkward, if you
will, and getting remote wakeup with PM working, is generally a
challenge.

Roger, in Cc, has worked with EHCI and got all of the PM details merged
upstream, maybe he can give you a hint.

-- 
balbi


signature.asc
Description: Digital signature

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-28 Thread Michael Welling

On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
> On Fri, 25 Jul 2014, Michael Welling wrote:
> 
> > The plot thickens
> > 
> > So if I run the above command before anything is plugged into the ports
> > the HUB disconnects.
> > 
> > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> > [   63.068839] usb 1-1: USB disconnect, device number 2
> > 
> > Here is the output of the usbmon output when running the above command:
> > root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> > de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> > de382e40 3788890604 C Ci:001:00 0 4 = 0705
> > de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> > de382e40 3788893093 C Ci:001:00 0 4 = 0001
> > de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> > de382e40 3788894958 C Ci:001:00 0 4 = 0001
> > de7d92c0 3788896519 S Ii:001:01 -115 4 <
> > de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> > de382e40 3788900188 C Ci:001:00 0 4 = 0705
> > de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> > de382e40 3788905793 C Co:001:00 0 0
> > de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> > de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> > de7d92c0 3788943013 S Ii:001:01 -115 4 <
> > de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> > de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> > de382e40 3788961175 C Co:001:00 0 0
> > de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> > de382e40 3788965395 C Ci:002:00 -71 0
> > de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> > de249040 3788968362 C Co:001:00 0 0
> > de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> > de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> > de7d92c0 378906 S Ii:001:01 -115 4 <
> > de249040 3789023423 C Ci:001:00 0 4 = 01051200
> > de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> > de249040 3789026815 C Co:001:00 0 0
> > de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> > de249040 378923 C Ci:001:00 0 4 = 00010300
> > de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> > de249040 3789232404 C Co:001:00 0 0
> > de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> > de249040 3789235345 C Co:001:00 0 0
> > de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> > de249040 3789237201 C Co:001:00 0 0
> > de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> > de249040 3789238510 C Co:001:00 0 0
> > de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> > de249040 3789241661 C Ci:001:00 0 4 = 00010300
> > de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> > de249040 3789243921 C Co:001:00 0 0
> > de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> > de249040 3789246930 C Co:001:00 0 0
> > de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> > de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> > de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> > de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> > de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> > de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> > de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> > de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> > de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> > de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> > de7d92c0 3789452462 C Ii:001:01 -2 0
> > 
> > Not sure what any of it means.
> 
> Basically it means what you said above: the hub disconnected.  I can't 
> tell why.  You'll have to ask someone who's familiar with the hardware 
> on that board.

Sadly, there is no one more familar with this specific hardware than myself.

I can however ellaborate the hardware setup of the USB subsystem in
case there is someone out there that has used a similar setup.

The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is
connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to
provide two downstream USB ports.

The very same hardware worked with the 2.6.37 kernel that I am trying to
move away from.

Today I am going to try using 3.10 and 3.14 kernels see if they exhibit
the same behavior.

> 
> Alan Stern
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-28 Thread Alan Stern

On Fri, 25 Jul 2014, Michael Welling wrote:

> The plot thickens
> 
> So if I run the above command before anything is plugged into the ports
> the HUB disconnects.
> 
> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> [   63.068839] usb 1-1: USB disconnect, device number 2
> 
> Here is the output of the usbmon output when running the above command:
> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
> de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
> de382e40 3788890604 C Ci:001:00 0 4 = 0705
> de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
> de382e40 3788893093 C Ci:001:00 0 4 = 0001
> de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
> de382e40 3788894958 C Ci:001:00 0 4 = 0001
> de7d92c0 3788896519 S Ii:001:01 -115 4 <
> de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
> de382e40 3788900188 C Ci:001:00 0 4 = 0705
> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
> de382e40 3788905793 C Co:001:00 0 0
> de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
> de7d92c0 3788942065 C Ii:001:01 0 1 = 02
> de7d92c0 3788943013 S Ii:001:01 -115 4 <
> de382e40 3788943145 C Ci:001:00 0 4 = 03050400
> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
> de382e40 3788961175 C Co:001:00 0 0
> de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
> de382e40 3788965395 C Ci:002:00 -71 0
> de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
> de249040 3788968362 C Co:001:00 0 0
> de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
> de7d92c0 3789022194 C Ii:001:01 0 1 = 02
> de7d92c0 378906 S Ii:001:01 -115 4 <
> de249040 3789023423 C Ci:001:00 0 4 = 01051200
> de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
> de249040 3789026815 C Co:001:00 0 0
> de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
> de249040 378923 C Ci:001:00 0 4 = 00010300
> de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
> de249040 3789232404 C Co:001:00 0 0
> de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
> de249040 3789235345 C Co:001:00 0 0
> de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
> de249040 3789237201 C Co:001:00 0 0
> de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
> de249040 3789238510 C Co:001:00 0 0
> de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
> de249040 3789241661 C Ci:001:00 0 4 = 00010300
> de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
> de249040 3789243921 C Co:001:00 0 0
> de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
> de249040 3789246930 C Co:001:00 0 0
> de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789286255 C Ci:001:00 0 4 = 0001
> de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789332606 C Ci:001:00 0 4 = 0001
> de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789371146 C Ci:001:00 0 4 = 0001
> de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789411097 C Ci:001:00 0 4 = 0001
> de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
> de2490c0 3789451081 C Ci:001:00 0 4 = 0001
> de7d92c0 3789452462 C Ii:001:01 -2 0
> 
> Not sure what any of it means.

Basically it means what you said above: the hub disconnected.  I can't 
tell why.  You'll have to ask someone who's familiar with the hardware 
on that board.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Michael Welling

On Fri, Jul 25, 2014 at 02:12:42PM -0400, Alan Stern wrote:
> On Fri, 25 Jul 2014, Michael Welling wrote:
> 
> > > What if you prevent the root hub from going into runtime suspend?  Or 
> > > prevent the external hub from going into runtime suspend?  You could be 
> > > facing a wakeup problem.
> > 
> > This helps, it appears that the issue is with the external HUB.
> > 
> > If I disable the autosuspend on the external USB HUB I can plug and
> > unplug the devices as many times as I want.
> > 
> > root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> > 
> > The external USB HUB is USB2512 and is right on the board.
> > How do I go about either preventing the suspend or fixing the code such
> > that it works?
>

The plot thickens

So if I run the above command before anything is plugged into the ports
the HUB disconnects.

root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
[   63.068839] usb 1-1: USB disconnect, device number 2

Here is the output of the usbmon output when running the above command:
root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 <
de382e40 3788890604 C Ci:001:00 0 4 = 0705
de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 <
de382e40 3788893093 C Ci:001:00 0 4 = 0001
de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 <
de382e40 3788894958 C Ci:001:00 0 4 = 0001
de7d92c0 3788896519 S Ii:001:01 -115 4 <
de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 <
de382e40 3788900188 C Ci:001:00 0 4 = 0705
de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
de382e40 3788905793 C Co:001:00 0 0
de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 <
de7d92c0 3788942065 C Ii:001:01 0 1 = 02
de7d92c0 3788943013 S Ii:001:01 -115 4 <
de382e40 3788943145 C Ci:001:00 0 4 = 03050400
de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
de382e40 3788961175 C Co:001:00 0 0
de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 <
de382e40 3788965395 C Ci:002:00 -71 0
de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
de249040 3788968362 C Co:001:00 0 0
de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 <
de7d92c0 3789022194 C Ii:001:01 0 1 = 02
de7d92c0 378906 S Ii:001:01 -115 4 <
de249040 3789023423 C Ci:001:00 0 4 = 01051200
de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
de249040 3789026815 C Co:001:00 0 0
de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 <
de249040 378923 C Ci:001:00 0 4 = 00010300
de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
de249040 3789232404 C Co:001:00 0 0
de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
de249040 3789235345 C Co:001:00 0 0
de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
de249040 3789237201 C Co:001:00 0 0
de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
de249040 3789238510 C Co:001:00 0 0
de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 <
de249040 3789241661 C Ci:001:00 0 4 = 00010300
de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
de249040 3789243921 C Co:001:00 0 0
de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
de249040 3789246930 C Co:001:00 0 0
de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789286255 C Ci:001:00 0 4 = 0001
de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789332606 C Ci:001:00 0 4 = 0001
de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789371146 C Ci:001:00 0 4 = 0001
de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789411097 C Ci:001:00 0 4 = 0001
de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 <
de2490c0 3789451081 C Ci:001:00 0 4 = 0001
de7d92c0 3789452462 C Ii:001:01 -2 0

Not sure what any of it means.

> One way to prevent the hub from suspending is to use the echo command 
> above.  Another way is to set the autosuspend value to -1.  Or set the 
> usbcore autosuspend module parameter to -1, which affects the default 
> autosuspend setting for all USB devices.
> 
> As for fixing the code... that's harder to answer because as far as I
> know, there is nothing wrong in the code.  Maybe the problem is in an
> area I'm not familiar with (such as the phy support), or maybe you have
> non-compliant hardware.
> 
> You can get more information as follows: enable suspend, let the hub go
> into runtime suspend, then plug in a device, and disable suspend.  The
> port status information in the resulting usbmon trace is likely to show
> whether the hub responded properly to the hotplug event.
> 
> If you're asking about config options to disable runtime suspend, you 
> can turn off CONFIG_PM_RUNTIME.  But that will prevent runtime suspend 
> for _all_ devices on the system, which probably isn't what you want.  
> If you want to edit the code to prevent USB hubs (or any USB device) 
> from ever going into runtime suspend, I can tell you what to change.
> 
> > It should be noted that the CONFIG_USB_SUSPEND option not

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Alan Stern

On Fri, 25 Jul 2014, Michael Welling wrote:

> > What if you prevent the root hub from going into runtime suspend?  Or 
> > prevent the external hub from going into runtime suspend?  You could be 
> > facing a wakeup problem.
> 
> This helps, it appears that the issue is with the external HUB.
> 
> If I disable the autosuspend on the external USB HUB I can plug and
> unplug the devices as many times as I want.
> 
> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
> 
> The external USB HUB is USB2512 and is right on the board.
> How do I go about either preventing the suspend or fixing the code such
> that it works?

One way to prevent the hub from suspending is to use the echo command 
above.  Another way is to set the autosuspend value to -1.  Or set the 
usbcore autosuspend module parameter to -1, which affects the default 
autosuspend setting for all USB devices.

As for fixing the code... that's harder to answer because as far as I
know, there is nothing wrong in the code.  Maybe the problem is in an
area I'm not familiar with (such as the phy support), or maybe you have
non-compliant hardware.

You can get more information as follows: enable suspend, let the hub go
into runtime suspend, then plug in a device, and disable suspend.  The
port status information in the resulting usbmon trace is likely to show
whether the hub responded properly to the hotplug event.

If you're asking about config options to disable runtime suspend, you 
can turn off CONFIG_PM_RUNTIME.  But that will prevent runtime suspend 
for _all_ devices on the system, which probably isn't what you want.  
If you want to edit the code to prevent USB hubs (or any USB device) 
from ever going into runtime suspend, I can tell you what to change.

> It should be noted that the CONFIG_USB_SUSPEND option not longer exists
> in the kernel but it is still referenced in the documentation.
> 
> http://lxr.free-electrons.com/source/Documentation/usb/power-management.txt

Yes.  There was a proposal to update the documentation posted on the 
mailing list a few weeks ago.  I don't know what happened to it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Michael Welling

On Fri, Jul 25, 2014 at 12:50 PM, Michael Welling  wrote:
> On Fri, Jul 25, 2014 at 01:19:23PM -0400, Alan Stern wrote:
>> On Fri, 25 Jul 2014, Michael Welling wrote:
>>
>> > On Fri, Jul 25, 2014 at 10:02:15AM -0400, Alan Stern wrote:
>> > > On Thu, 24 Jul 2014, Michael Welling wrote:
>> > >
>> > > > So I may be barking up the wrong tree on this one.
>> > > >
>> > > > Today I discovered something that may lead to the resolution of my 
>> > > > issue.
>> > > >
>> > > > The hardware I am using incorporates a USB switch on-board to avoid the
>> > > > having an external switch to plug in keyboards etc. If two devices are 
>> > > > plugged
>> > > > into the downstream ports they are both detected on boot. When I unplug
>> > > > one of the devices and plug it back in, it is detected again.
>> > > >
>> > > > As long as one downstream device ports is populated the device 
>> > > > discovery works
>> > > > on the other. Any clue on this?
>> > > >
>> > > > This reminded of a note that I made on the schematic after talking to 
>> > > > SMSC.
>> > > >
>> > > > Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.
>> > > >
>> > > > This is a PHY register that may actually be accessible in
>> > > > drivers/usb/phy/phy-ulpi.c
>> > > > but it looks like I cannot access the code from device tree.
>> > > >
>> > > > What would be the best way to go about adding support for this?
>> > >
>> > > Maybe you would learn more if you enabled USB debugging in your kernel.
>> > > Or if you used usbmon to see what the USB traffic is doing.
>> >
>> > The trafic stops all together when both USB devices are unplugged for
>> > the first time.
>> >
>> > The external USB HUB is still present in the device list but it does not
>> > detect anything after the last disconnect.
>>
>> What if you prevent the root hub from going into runtime suspend?  Or
>> prevent the external hub from going into runtime suspend?  You could be
>> facing a wakeup problem.
>
> This helps, it appears that the issue is with the external HUB.
>
> If I disable the autosuspend on the external USB HUB I can plug and
> unplug the devices as many times as I want.
>
> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control
>
> The external USB HUB is USB2512 and is right on the board.
> How do I go about either preventing the suspend or fixing the code such
> that it works?
>
> It should be noted that the CONFIG_USB_SUSPEND option not longer exists
> in the kernel but it is still referenced in the documentation.
>
> http://lxr.free-electrons.com/source/Documentation/usb/power-management.txt

Ooops it also mentions its elimination. -1 for reading skills.

>
>>
>> Alan Stern
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Michael Welling

On Fri, Jul 25, 2014 at 01:19:23PM -0400, Alan Stern wrote:
> On Fri, 25 Jul 2014, Michael Welling wrote:
> 
> > On Fri, Jul 25, 2014 at 10:02:15AM -0400, Alan Stern wrote:
> > > On Thu, 24 Jul 2014, Michael Welling wrote:
> > > 
> > > > So I may be barking up the wrong tree on this one.
> > > > 
> > > > Today I discovered something that may lead to the resolution of my 
> > > > issue.
> > > > 
> > > > The hardware I am using incorporates a USB switch on-board to avoid the
> > > > having an external switch to plug in keyboards etc. If two devices are 
> > > > plugged
> > > > into the downstream ports they are both detected on boot. When I unplug
> > > > one of the devices and plug it back in, it is detected again.
> > > > 
> > > > As long as one downstream device ports is populated the device 
> > > > discovery works
> > > > on the other. Any clue on this?
> > > > 
> > > > This reminded of a note that I made on the schematic after talking to 
> > > > SMSC.
> > > > 
> > > > Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.
> > > > 
> > > > This is a PHY register that may actually be accessible in
> > > > drivers/usb/phy/phy-ulpi.c
> > > > but it looks like I cannot access the code from device tree.
> > > > 
> > > > What would be the best way to go about adding support for this?
> > > 
> > > Maybe you would learn more if you enabled USB debugging in your kernel.  
> > > Or if you used usbmon to see what the USB traffic is doing.
> > 
> > The trafic stops all together when both USB devices are unplugged for
> > the first time.
> > 
> > The external USB HUB is still present in the device list but it does not
> > detect anything after the last disconnect.
> 
> What if you prevent the root hub from going into runtime suspend?  Or 
> prevent the external hub from going into runtime suspend?  You could be 
> facing a wakeup problem.

This helps, it appears that the issue is with the external HUB.

If I disable the autosuspend on the external USB HUB I can plug and
unplug the devices as many times as I want.

root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control

The external USB HUB is USB2512 and is right on the board.
How do I go about either preventing the suspend or fixing the code such
that it works?

It should be noted that the CONFIG_USB_SUSPEND option not longer exists
in the kernel but it is still referenced in the documentation.

http://lxr.free-electrons.com/source/Documentation/usb/power-management.txt

> 
> Alan Stern
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Alan Stern

On Fri, 25 Jul 2014, Michael Welling wrote:

> On Fri, Jul 25, 2014 at 10:02:15AM -0400, Alan Stern wrote:
> > On Thu, 24 Jul 2014, Michael Welling wrote:
> > 
> > > So I may be barking up the wrong tree on this one.
> > > 
> > > Today I discovered something that may lead to the resolution of my issue.
> > > 
> > > The hardware I am using incorporates a USB switch on-board to avoid the
> > > having an external switch to plug in keyboards etc. If two devices are 
> > > plugged
> > > into the downstream ports they are both detected on boot. When I unplug
> > > one of the devices and plug it back in, it is detected again.
> > > 
> > > As long as one downstream device ports is populated the device discovery 
> > > works
> > > on the other. Any clue on this?
> > > 
> > > This reminded of a note that I made on the schematic after talking to 
> > > SMSC.
> > > 
> > > Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.
> > > 
> > > This is a PHY register that may actually be accessible in
> > > drivers/usb/phy/phy-ulpi.c
> > > but it looks like I cannot access the code from device tree.
> > > 
> > > What would be the best way to go about adding support for this?
> > 
> > Maybe you would learn more if you enabled USB debugging in your kernel.  
> > Or if you used usbmon to see what the USB traffic is doing.
> 
> The trafic stops all together when both USB devices are unplugged for
> the first time.
> 
> The external USB HUB is still present in the device list but it does not
> detect anything after the last disconnect.

What if you prevent the root hub from going into runtime suspend?  Or 
prevent the external hub from going into runtime suspend?  You could be 
facing a wakeup problem.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Michael Welling

On Fri, Jul 25, 2014 at 10:02:15AM -0400, Alan Stern wrote:
> On Thu, 24 Jul 2014, Michael Welling wrote:
> 
> > So I may be barking up the wrong tree on this one.
> > 
> > Today I discovered something that may lead to the resolution of my issue.
> > 
> > The hardware I am using incorporates a USB switch on-board to avoid the
> > having an external switch to plug in keyboards etc. If two devices are 
> > plugged
> > into the downstream ports they are both detected on boot. When I unplug
> > one of the devices and plug it back in, it is detected again.
> > 
> > As long as one downstream device ports is populated the device discovery 
> > works
> > on the other. Any clue on this?
> > 
> > This reminded of a note that I made on the schematic after talking to SMSC.
> > 
> > Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.
> > 
> > This is a PHY register that may actually be accessible in
> > drivers/usb/phy/phy-ulpi.c
> > but it looks like I cannot access the code from device tree.
> > 
> > What would be the best way to go about adding support for this?
> 
> Maybe you would learn more if you enabled USB debugging in your kernel.  
> Or if you used usbmon to see what the USB traffic is doing.

The trafic stops all together when both USB devices are unplugged for
the first time.

The external USB HUB is still present in the device list but it does not
detect anything after the last disconnect.

[  686.780928] usb 1-1.1: USB disconnect, device number 3
de249440 1778606192 C Ii:002:01 0 1 = 02
de249440 1778606263 S Ii:002:01 -115 1 <
de37df40 1778606439 S Ci:002:00 s a3 00  0001 0004 4 <
de37df40 1778607418 C Ci:002:00 0 4 = 00010100
de37df40 1778607564 S Co:002:00 s 23 01 0010 0001  0
de37df40 1778608186 C Co:002:00 0 0
de32dd40 1778617248 C Ii:003:01 -108 0
de79a2c0 1778663228 S Ci:002:00 s a3 00  0001 0004 4 <
de79a2c0 1778664392 C Ci:002:00 0 4 = 0001
de310dc0 1778702124 S Ci:002:00 s a3 00  0001 0004 4 <
de310dc0 1778702417 C Ci:002:00 0 4 = 0001
de310dc0 1778742058 S Ci:002:00 s a3 00  0001 0004 4 <
de310dc0 1778743170 C Ci:002:00 0 4 = 0001
de310dc0 1778782078 S Ci:002:00 s a3 00  0001 0004 4 <
de310dc0 1778782276 C Ci:002:00 0 4 = 0001
de310dc0 1778822059 S Ci:002:00 s a3 00  0001 0004 4 <
de310dc0 1778822254 C Ci:002:00 0 4 = 0001
de249440 1778825402 C Ii:002:01 -2 0
de310dc0 1778828574 S Co:002:00 s 00 03 0001   0
de310dc0 1778830677 C Co:002:00 0 0
de310dc0 1778831792 S Co:001:00 s 23 03 0002 0001  0
de310dc0 1778833243 C Co:001:00 0 0
de74b1c0 1778853787 C Ii:001:01 -2 0
^C
root@som3517:/sys/kernel/debug/usb/usbmon# lsusb
Bus 001 Device 002: ID 0424:2512 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

> 
> Alan Stern
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-25 Thread Alan Stern

On Thu, 24 Jul 2014, Michael Welling wrote:

> So I may be barking up the wrong tree on this one.
> 
> Today I discovered something that may lead to the resolution of my issue.
> 
> The hardware I am using incorporates a USB switch on-board to avoid the
> having an external switch to plug in keyboards etc. If two devices are plugged
> into the downstream ports they are both detected on boot. When I unplug
> one of the devices and plug it back in, it is detected again.
> 
> As long as one downstream device ports is populated the device discovery works
> on the other. Any clue on this?
> 
> This reminded of a note that I made on the schematic after talking to SMSC.
> 
> Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.
> 
> This is a PHY register that may actually be accessible in
> drivers/usb/phy/phy-ulpi.c
> but it looks like I cannot access the code from device tree.
> 
> What would be the best way to go about adding support for this?

Maybe you would learn more if you enabled USB debugging in your kernel.  
Or if you used usbmon to see what the USB traffic is doing.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

2014-07-24 Thread Michael Welling

On Wed, Jul 23, 2014 at 3:34 PM, Michael Welling  wrote:
> There appears to be a bug in the USB host driver for the AM3517 in the
> 3.16 kernel. When the AM3517 board boots with a USB device plugged in
> the host it detects and works fines as long as it is plugged in.
>
> The board does not detect any device that is hotplugged and the kernel
> message report nothing.
>
> The board that I am porting is using the USB3320 PHY connected to the
> USB host 1 interface. It should be noted that the same hardware worked
> fine using an old 2.6.30 kernel.
>
> The kernel has drastically changed since then and it appears that
> something broke along the way.
>
> I did notice this magical code in the old kernel:
> http://marc.info/?l=linux-usb&m=127841764930798&w=2
So I may be barking up the wrong tree on this one.

Today I discovered something that may lead to the resolution of my issue.

The hardware I am using incorporates a USB switch on-board to avoid the
having an external switch to plug in keyboards etc. If two devices are plugged
into the downstream ports they are both detected on boot. When I unplug
one of the devices and plug it back in, it is detected again.

As long as one downstream device ports is populated the device discovery works
on the other. Any clue on this?

This reminded of a note that I made on the schematic after talking to SMSC.

Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.

This is a PHY register that may actually be accessible in
drivers/usb/phy/phy-ulpi.c
but it looks like I cannot access the code from device tree.

What would be the best way to go about adding support for this?

Added a few more on the CC list to see if I can get any answers.

https://lkml.org/lkml/2013/12/4/50

>
> Since then the PHY code and host driver have been seperated. I am not
> sure that the soft reset is ever being performed. I do notice that there
> are remnants of the old driver as there are multiple macro defines that
> are never used in the driver:
> #define EHCI_INSNREG05_ULPI (0xA4)
> #define EHCI_INSNREG05_ULPI_CONTROL_SHIFT   31
> #define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT   24
> #define EHCI_INSNREG05_ULPI_OPSEL_SHIFT 22
> #define EHCI_INSNREG05_ULPI_REGADD_SHIFT16
> #define EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
> #define EHCI_INSNREG05_ULPI_WRDATA_SHIFT0
>
> Any advice as to how to address this would be greatly appreciated.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

Re: OMAP3/AM3517 EHCI USB Issue

29 matches

Site Navigation

Mail list logo

Footer information