Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes
authorRuss Dill <Russ.Dill@ti.com>
Thu, 21 Jun 2012 10:44:32 +0000 (03:44 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 27 Jun 2012 02:44:18 +0000 (19:44 -0700)
commitafd6bb387323154ff6554b52d333ec6efb8efe61
tree9cb0ee7d305cd45165faba1ac5f50b1a720bf6c6
parent984e97483a143f95d861b7218161ae033df293ab
Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes

an oops on boot for all omap3xxx platforms that use usbhs_omap for
EHCI. The actual oops comes from faulty ehci-omap cleanup, but the
failure caused by the change is evidenced here:

[    3.655059] ehci-omap ehci-omap.0: utmi_p1_gfclk failed error:-2
[    3.661376] ehci-omap: probe of ehci-omap.0 failed with error -2

utmi_p1_gfclk is a clock that exists on OMAP4, but not OMAP3. In the
OMAP3 case, it is configured as a dummy clock. However, OMAP4 lists
the dev_id as NULL, but OMAP3 lists it as "usbhs_omap".

Attempting to get that clock from ehci-omap then fails. The solution
is to just change the clock3xxx_data.c for dummy clocks used in the
errata fix to match the dev_id, NULL, used in clock44xx_data.c.

Tested on BB-xM.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arm/mach-omap2/clock3xxx_data.c