Messages in this thread | | | Date | Wed, 16 Mar 2011 11:43:33 +0100 | From | Alexander Holler <> | Subject | Re: musb as module broken in 2.6.38 |
| |
Am 16.03.2011 11:38, schrieb Felipe Balbi: > hi, > > On Mar 16, 2011, at 12:30 PM, Alexander Holler wrote: >> Am 16.03.2011 11:24, schrieb Felipe Balbi: >>> Hi, >>> >>> On Mar 16, 2011, at 12:17 PM, Alexander Holler wrote: >>>>> static int __init omap2430_probe(struct platform_device *pdev) >>>> >>>> Neither omap2430_init() nor omap2430_probe() will be called here. >>> >>> and why is that ? It's even in sysfs already: >>> >>>>>> beagle linux # ls /sys/devices/platform/ | grep musb >>>>>> musb-omap2430 >> >> Don't know, I haven't written or changed the driver. ;) > > hehe, Just thought that you had something in mind already. > > probe() functions are called when, in case of platform_devices, > the name matches with driver name. musb-omap2430 platform_device > is allocated in arch/arm/mach-omap2/usb-musb.c, then musb-2430 > driver lives in drivers/usb/musb/omap2430.c. musb-2430 allocates a > platform_device for musb-hdrc core driver. > > We did that because the same core is used in many different platforms > (OMAP, discrete chips, ST-Ericsson, DaVinci, PCI cards, etc) so we > needed to "abstract" platform-specific details such as clock handling > and power management. > > There's still work to be done, for sure, e.g. the DMA part is still quite > screwed up, but the drivers are correctly named which means they > should be matching and probing. Now, musb-hdrc isn't probing, as > you say, and I'd like to know why. I'll try to spend some time in > it when I get back to the office.
I currently assume it's something with
subsys_initcall(omap2430_init);
Have to read about subsys_initcall() and why omap2430_init isn't called here.
Regards,
Alexander Holler
| |