Nishanth Menon [off-list ref] writes:

On 02/10/2014 12:28 PM, Kevin Hilman wrote:

quoted

Roger Quadros [off-list ref] writes:

quoted

+devicetree

On 02/10/2014 05:59 PM, Nishanth Menon wrote:

quoted

Hi,

A quick note to report that I saw regression in today's next tag (logs
indicate around EHCI) boot on various TI platforms:

Note: crane and sdp2430 are not expected to pass with
multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
but USB is disabled there)

next-20140210-multi_v7_defconfig
 1: am335x-evm:  Boot PASS: http://slexy.org/raw/s2zYHdPb94
 2:  am335x-sk:  Boot PASS: http://slexy.org/raw/s2UChLyzSE
 3: am3517-evm:  Boot FAIL: http://slexy.org/raw/s20Br9XLO1
around ehci

 4:  am37x-evm:  Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
around ehci

 5: am43xx-epos:  Boot PASS: http://slexy.org/raw/s2byveBYtT
 6: BeagleBoard-XM:  Boot FAIL: http://slexy.org/raw/s21sOgJNwK
around ehci

 7: BeagleBone-Black:  Boot PASS: http://slexy.org/raw/s2ovVNAmO7
 8:      crane: No Image built - Missing platform support?:
 9:       dra7:  Boot PASS: http://slexy.org/raw/s217qwaXsM
10:        ldp:  Boot FAIL: http://slexy.org/raw/s203IvjE23
around ehci

11: PandaBoard-ES:  Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
around ehci

I think the problem is that ehci-platform driver gets loaded instead of ehci-omap.

In the DT node we have compatible ids for both. e.g. for omap4.dtsi

                        usbhsehci: ehci@4a064c00 {
                                compatible = "ti,ehci-omap", "usb-ehci";
                                reg = <0x4a064c00 0x400>;
                                interrupt-parent = <&gic>;
                                interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
                        };

Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?

A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms.

I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
fixed the problem for me on 3530/overo, 3730/beagle-xM and
4460/panda-es.  But I don't think that's the right fix.  First we have
to figure out why ehci-omap stopped getting loaded first.

Wont that depend on driver probe order? of_match_device is fairly
simple compatible walk through without looking at other drivers which
might also be compatible, but not yet probed?

The issue started I think with the following patch getting merged:
ehci-platform: Add support for clks and phy passed through devicetree
some version of http://www.spinics.net/lists/linux-usb/msg101061.html
introduced { .compatible = "usb-ehci", },

This is what I was getting at: an understanding of what caused the
failue in the first place.

Now, in the build we have two drivers which dts claims compatibility
with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
for the platform. Thinking that way, in fact, the current
compatibility even matches drivers/usb/host/ehci-ppc-of.c which
obviously wont work either.

Right, so I agree that it makes sense to remove a compatible string
where there is no compatability, but a couple other things should happen
here.

1) changelog should describe why this compatible string is in the omap
dtsi files in first place.

2) investigation into the patch that introduced this change to double
check it's not introducing other breakage as well.

Kevin