Initialization of musb on board-omap2beagle fails in platform_driver_probe

Initialization of musb on board-omap2beagle fails in platform_driver_probe

[Ben Gamari]

Today I've had a very frustrating time trying to bring up a BeagleBoard
(arch/arm/mach-omap2/board-omap2beagle.c) with the 2.6.38
kernel. Unfortunately musb has been giving me great difficulties,

 # modprobe g_ether
[   25.276855] usb_gadget_probe_driver 1815: usb_gadget_probe_driver, no dev??
modprobe: Failed to load module g_ether: No such device.

After a great deal of printking, I've determined that the error is
coming from platform_driver_probe (platform.c:499). The code in question
appears to be a check ensuring that any devices being probe were first
registered. When the musb-hdrc module is probed, this check seems to
fail with code = 1 and list_empty(&drv->driver.p->klist_devices.k_list)
= 1.

What exactly is this check supposed to accomplish? Why would it fail
during musb initialization? The relevant call path is,

  kernel_init -> do_one_initcall -> musb_init -> platform_driver_probe
  
Both musb_init and platform_driver_probe return with -19. As far as I
can tell, the board's init_machine successfully calls usb_musb_init
from omap3_beagle_init, so the device should be registered well before
arriving in musb_init.

Any ideas would be greatly appreciated. Cheers,

 - Ben

Re: Initialization of musb on board-omap2beagle fails in platform_driver_probe

[Felipe Balbi]

Hi,

On Sat, Mar 26, 2011 at 07:42:34PM -0400, Ben Gamari wrote:
> Today I've had a very frustrating time trying to bring up a BeagleBoard
> (arch/arm/mach-omap2/board-omap2beagle.c) with the 2.6.38

there's no board-omap2beagle

> kernel. Unfortunately musb has been giving me great difficulties,
> 
>  # modprobe g_ether
> [   25.276855] usb_gadget_probe_driver 1815: usb_gadget_probe_driver, no dev??
> modprobe: Failed to load module g_ether: No such device.
> 
> After a great deal of printking, I've determined that the error is
> coming from platform_driver_probe (platform.c:499). The code in question
> appears to be a check ensuring that any devices being probe were first
> registered. When the musb-hdrc module is probed, this check seems to
> fail with code = 1 and list_empty(&drv->driver.p->klist_devices.k_list)
> = 1.

looking at your .config from previous mail, it's wrong. You're trying to
use am35x glue layer while you be using omap2430, just change:

- CONFIG_USB_MUSB_AM35X=y
+ # CONFIG_USB_MUSB_AM35X is not set
+ CONFIG_USB_MUSB_OMAP2PLUS=y

-- 
balbi

Re: Initialization of musb on board-omap2beagle fails in platform_driver_probe

[Ben Gamari]

On Mon, 28 Mar 2011 11:37:22 +0300, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
> 
> On Sat, Mar 26, 2011 at 07:42:34PM -0400, Ben Gamari wrote:
> > Today I've had a very frustrating time trying to bring up a BeagleBoard
> > (arch/arm/mach-omap2/board-omap2beagle.c) with the 2.6.38
> 
> there's no board-omap2beagle
> 
My apologies, s/omap2/omap3.

> > kernel. Unfortunately musb has been giving me great difficulties,
> > 
> >  # modprobe g_ether
> > [   25.276855] usb_gadget_probe_driver 1815: usb_gadget_probe_driver, no dev??
> > modprobe: Failed to load module g_ether: No such device.
> > 
> > After a great deal of printking, I've determined that the error is
> > coming from platform_driver_probe (platform.c:499). The code in question
> > appears to be a check ensuring that any devices being probe were first
> > registered. When the musb-hdrc module is probed, this check seems to
> > fail with code = 1 and list_empty(&drv->driver.p->klist_devices.k_list)
> > = 1.
> 
> looking at your .config from previous mail, it's wrong. You're trying to
> use am35x glue layer while you be using omap2430, just change:
> 
Alright, fair enough. The mishmash of IP found in these ARM devices can
make it very difficult to determine the correct configuration at
times. Thanks for your help!

- Ben