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 

[PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock

2014-07-15 Thread Stefan Herbrechtsmeier
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).

Signed-off-by: Stefan Herbrechtsmeier 
Cc: Laurent Pinchart 
Cc: Tony Lindgren 
Cc: Tero Kristo 
Cc: 
Cc: 
---
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = <0x1e>;
reg = <0x0d00>;
ti,set-bit-to-disable;
+   ti,set-rate-parent;
};
 
dpll4_m6_ck: dpll4_m6_ck {
-- 
2.0.1

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