lkml.org 
[lkml]   [2011]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: musb as module broken in 2.6.38
    Am 16.03.2011 11:48, schrieb Felipe Balbi:
    > Hi,
    >
    > On Mar 16, 2011, at 12:43 PM, Alexander Holler wrote:
    >
    >> 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.
    >
    > I guess I know what the problem is. If you search for omap2430_init
    > in vmlinux it won't be there. I guess when a directory is marked as
    > obj-m, Kbuild won't search for symbols to be statically linked to vmlinux
    > on that directory. Since we use the same Kconfig entry to select musb as
    > module and include drivers/usb/musb directory into build system, we
    > are falling into that case.
    >
    > Try changing drivers/usb/musb to obj-y in drivers/Makefile and see if things
    > start working.

    Thanks, seems to be the right way, but doesn't work without more
    changes. I get some undefined references e.g. to stuff in musb_core.c
    and musb_debug (otg_state_string and musb_debug). I assume it's because
    musb_core and musb_debug are part of the module musb_hdrc.

    Regards,

    Alexander Holler


    \
     
     \ /
      Last update: 2011-03-16 12:25    [W:3.753 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site