Hello,
in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the
platform-driver was splitted and musb-omap2430 is used for several
boards (arch/arm/mach-omap2/usb-musb.c).
But musb_hdrc still uses musb-hdrc as name when platform_driver_probe()
is called. The result is that loading the driver (when build as a
module) doesn't work anymore (it doesn't find the platform-device).
Do I miss something or was something forgotten when the glue-layers for
musb got introduced?
(The driver still works when linked into the kernel, but is
disfunctional when build as a module.)
Regards,
Alexander Holler
Hi,
On Wed, Mar 16, 2011 at 02:55:53AM +0100, Alexander Holler wrote:
> in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the
> platform-driver was splitted and musb-omap2430 is used for several
> boards (arch/arm/mach-omap2/usb-musb.c).
>
> But musb_hdrc still uses musb-hdrc as name when
> platform_driver_probe() is called. The result is that loading the
> driver (when build as a module) doesn't work anymore (it doesn't find
> the platform-device).
>
> Do I miss something or was something forgotten when the glue-layers
> for musb got introduced?
>
> (The driver still works when linked into the kernel, but is
> disfunctional when build as a module.)
Send me the output you get on console and a snippet of the .config with
the MUSB section.
--
balbi
Am 16.03.2011 10:03, schrieb Felipe Balbi:
> Hi,
>
> On Wed, Mar 16, 2011 at 02:55:53AM +0100, Alexander Holler wrote:
>> in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the
>> platform-driver was splitted and musb-omap2430 is used for several
>> boards (arch/arm/mach-omap2/usb-musb.c).
>>
>> But musb_hdrc still uses musb-hdrc as name when
>> platform_driver_probe() is called. The result is that loading the
>> driver (when build as a module) doesn't work anymore (it doesn't find
>> the platform-device).
>>
>> Do I miss something or was something forgotten when the glue-layers
>> for musb got introduced?
>>
>> (The driver still works when linked into the kernel, but is
>> disfunctional when build as a module.)
>
> Send me the output you get on console and a snippet of the .config with
> the MUSB section.
I don't see the need for it, but here it is:
------------
beagle linux # grep -i MUSB .config
CONFIG_USB_MUSB_HDRC=m
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_PERIPHERAL is not set
CONFIG_USB_MUSB_OTG=y
CONFIG_USB_GADGET_MUSB_HDRC=y
CONFIG_USB_MUSB_HDRC_HCD=y
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_MUSB_DEBUG=y
beagle linux # modprobe musb_hdrc
FATAL: Error inserting musb_hdrc
(/lib/modules/2.6.38-beagleboard-00002-g0017ea0-dirty/kernel/drivers/usb/musb/musb_hdrc.ko):
No such device
beagle linux # tail -n 1 /var/log/messages
Mar 16 10:37:51 beagle kernel: [ 177.302825] musb-hdrc: version 6.0,
musb-dma, otg (peripheral+host), debug=5
beagle linux # ls /sys/devices/platform/ | grep musb
musb-omap2430
------------
The problem in detail:
Through modprobe musb_core.c:musb_init() is called, and this calls
platform_driver_probe() with a pointer to a struct of platform_device
where the name is musb-hdrc.
drivers/base/platform.c:platform_driver_probe() fails with -ENODEV
because it doesn't find a platform device with the name musb-hdrc
(list_empty()) which is understandable because the platform-device has
the name musb-omap2430.
Regards,
Alexander Holler
On Wed, Mar 16, 2011 at 10:47:21AM +0100, Alexander Holler wrote:
> Am 16.03.2011 10:03, schrieb Felipe Balbi:
> >Hi,
> >
> >On Wed, Mar 16, 2011 at 02:55:53AM +0100, Alexander Holler wrote:
> >>in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the
> >>platform-driver was splitted and musb-omap2430 is used for several
> >>boards (arch/arm/mach-omap2/usb-musb.c).
> >>
> >>But musb_hdrc still uses musb-hdrc as name when
> >>platform_driver_probe() is called. The result is that loading the
> >>driver (when build as a module) doesn't work anymore (it doesn't find
> >>the platform-device).
> >>
> >>Do I miss something or was something forgotten when the glue-layers
> >>for musb got introduced?
> >>
> >>(The driver still works when linked into the kernel, but is
> >>disfunctional when build as a module.)
> >
> >Send me the output you get on console and a snippet of the .config with
> >the MUSB section.
>
> I don't see the need for it, but here it is:
>
> ------------
> beagle linux # grep -i MUSB .config
> CONFIG_USB_MUSB_HDRC=m
> # CONFIG_USB_MUSB_TUSB6010 is not set
> CONFIG_USB_MUSB_OMAP2PLUS=y
> # CONFIG_USB_MUSB_AM35X is not set
> # CONFIG_USB_MUSB_HOST is not set
> # CONFIG_USB_MUSB_PERIPHERAL is not set
> CONFIG_USB_MUSB_OTG=y
> CONFIG_USB_GADGET_MUSB_HDRC=y
> CONFIG_USB_MUSB_HDRC_HCD=y
> # CONFIG_MUSB_PIO_ONLY is not set
> CONFIG_USB_MUSB_DEBUG=y
> beagle linux # modprobe musb_hdrc
> FATAL: Error inserting musb_hdrc (/lib/modules/2.6.38-beagleboard-00002-g0017ea0-dirty/kernel/drivers/usb/musb/musb_hdrc.ko):
> No such device
> beagle linux # tail -n 1 /var/log/messages
> Mar 16 10:37:51 beagle kernel: [ 177.302825] musb-hdrc: version 6.0,
> musb-dma, otg (peripheral+host), debug=5
> beagle linux # ls /sys/devices/platform/ | grep musb
> musb-omap2430
> ------------
>
> The problem in detail:
>
> Through modprobe musb_core.c:musb_init() is called, and this calls
> platform_driver_probe() with a pointer to a struct of platform_device
> where the name is musb-hdrc.
> drivers/base/platform.c:platform_driver_probe() fails with -ENODEV
> because it doesn't find a platform device with the name musb-hdrc
> (list_empty()) which is understandable because the platform-device
> has the name musb-omap2430.
look further, omap2430.c allocates musb-hdrc platform_device. The
problem is a different one.
static int __init omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data;
struct platform_device *musb;
struct omap2430_glue *glue;
struct clk *clk;
int ret = -ENOMEM;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(&pdev->dev, "failed to allocate glue context\n");
goto err0;
}
musb = platform_device_alloc("musb-hdrc", -1);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
goto err1;
}
--
balbi
Am 16.03.2011 10:55, schrieb Felipe Balbi:
> On Wed, Mar 16, 2011 at 10:47:21AM +0100, Alexander Holler wrote:
>> ------------
>> beagle linux # grep -i MUSB .config
>> CONFIG_USB_MUSB_HDRC=m
>> # CONFIG_USB_MUSB_TUSB6010 is not set
>> CONFIG_USB_MUSB_OMAP2PLUS=y
>> # CONFIG_USB_MUSB_AM35X is not set
>> # CONFIG_USB_MUSB_HOST is not set
>> # CONFIG_USB_MUSB_PERIPHERAL is not set
>> CONFIG_USB_MUSB_OTG=y
>> CONFIG_USB_GADGET_MUSB_HDRC=y
>> CONFIG_USB_MUSB_HDRC_HCD=y
>> # CONFIG_MUSB_PIO_ONLY is not set
>> CONFIG_USB_MUSB_DEBUG=y
>> beagle linux # modprobe musb_hdrc
>> FATAL: Error inserting musb_hdrc (/lib/modules/2.6.38-beagleboard-00002-g0017ea0-dirty/kernel/drivers/usb/musb/musb_hdrc.ko):
>> No such device
>> beagle linux # tail -n 1 /var/log/messages
>> Mar 16 10:37:51 beagle kernel: [ 177.302825] musb-hdrc: version 6.0,
>> musb-dma, otg (peripheral+host), debug=5
>> beagle linux # ls /sys/devices/platform/ | grep musb
>> musb-omap2430
>> ------------
>>
>> The problem in detail:
>>
>> Through modprobe musb_core.c:musb_init() is called, and this calls
>> platform_driver_probe() with a pointer to a struct of platform_device
>> where the name is musb-hdrc.
>> drivers/base/platform.c:platform_driver_probe() fails with -ENODEV
>> because it doesn't find a platform device with the name musb-hdrc
>> (list_empty()) which is understandable because the platform-device
>> has the name musb-omap2430.
>
> look further, omap2430.c allocates musb-hdrc platform_device. The
> problem is a different one.
>
> static int __init omap2430_probe(struct platform_device *pdev)
Neither omap2430_init() nor omap2430_probe() will be called here.
Regards,
Alexander Holler
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
(ps: sorry if it's mis-formatted, I'm on the go, not using my laptop)
--
balbi
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. ;)
But I will look (later) if I will find the reason.
Regards,
Alexander Holler
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.
--
balbi
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
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.
--
balbi
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
On Wed, Mar 16, 2011 at 12:21:38PM +0100, Alexander Holler wrote:
> 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.
yeah, just saw it. I need to fix up the musb_debug part... I guess there
was a patch making otg_state_string generic (as it should be) will get
that. I guess a fix for this can't come to -rc though, it would depend
on new features, unfortunately :-(
--
balbi