Re: Regression on next-20140116 [Was: [PATCH 3/3 v4] usb: chipidea:hw_phymode_configure moved before ci_usb_phy_init]

From: Uwe Kleine-König
Date: Wed Jan 22 2014 - 16:41:50 EST


Hello,

On Wed, Jan 22, 2014 at 10:49:51AM +0100, Uwe Kleine-König wrote:
> On Tue, Dec 03, 2013 at 04:01:50PM +0800, Chris Ruehl wrote:
> > usb: chipidea: hw_phymode_configure moved before ci_usb_phy_init
> > hw_phymode_configure configures the PORTSC registers and allow the
> > following phy_inits to operate on the right parameters. This fix a problem
> > where the UPLI (ISP1504) could not detected, because the Viewport was not
> > available and read the viewport return 0's only.
> This patch (or a later revision of it to be more exact) made it into
> mainline as cd0b42c2a6d2.
>
> On an i.MX27 based machine I'm hitting an oops (see below) on
> next-20140116 + a few patches. (I didn't switch to 3.13+ yet, as I think
> not everything I need has landed there.) The oops goes away (and still
> better, lsusb reports my connected devices instead of "unable to
> initialize libusb: -99") when I do at least one of the following:
>
> - set CONFIG_USB_CHIPIDEA=y instead of =m
> - revert commit
> cd0b42c2a6d2 (usb: chipidea: put hw_phymode_configure before ci_usb_phy_init)
I debugged that a bit further and the problem is that
hw_phymode_configure depends on the phy's clk being enabled (i.e.
usb_ipg_gate) and this is only enforced in ci_usb_phy_init (via
usb_phy_init -> usb_gen_phy_init). When CONFIG_USB_CHIPIDEA=y the init
call to disable all unused clocks wasn't run yet and so the clock is
still on as this is the boot default.

Considering that it's already late today and that I don't know the
chipidea driver I'm sure there are people who can come up with a better
patch with less effort than me. Any volunteers?

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/