Can request_firmware be called from a platform_driver ?
Hi I have a fully working system to which I want to add the request firmware mechanism to an existing platform driver I have working. I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that I could figure this out. What I see with firmware_request() is that the kernel makes the firmware request and does not find any firmware and mdev sees nothing. However if I change my code to do request_firmare_nowait(), the entire system comes up and about 30seconds in the timeout calls my kernel side continue for request_firmare_nowait() and I DO now see my request handled by mdev, however it is a REMOVE request not the ADD request. All this makes me think that platform drivers exist before the hotplug mechanism is able to operate, is this true ? Many thanks Mike
Hi Mike, On Wed, Apr 18, 2012 at 11:07 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
Hi
I have a fully working system to which I want to add the request firmware mechanism to an existing platform driver I have working.
I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that I could figure this out.
What I see with firmware_request() is that the kernel makes the firmware request and does not find any firmware and mdev sees nothing.
However if I change my code to do request_firmare_nowait(), the entire system comes up and about 30seconds in the timeout calls my kernel side continue for request_firmare_nowait() and I DO now see my request handled by mdev, however it is a REMOVE request not the ADD request.
All this makes me think that platform drivers exist before the hotplug mechanism is able to operate, is this true ?
Well, request_firmware is ultimately serviced by a user-space process. So platform drivers compiled statically into the kernel get initialized long before user-space starts. Platform drivers compiled as modules will get the firmware loaded much more quickly after loading the module. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
On Wed, Apr 18, 2012 at 2:15 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Mike,
On Wed, Apr 18, 2012 at 11:07 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
Hi
I have a fully working system to which I want to add the request firmware mechanism to an existing platform driver I have working.
I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that I could figure this out.
What I see with firmware_request() is that the kernel makes the firmware request and does not find any firmware and mdev sees nothing.
However if I change my code to do request_firmare_nowait(), the entire system comes up and about 30seconds in the timeout calls my kernel side continue for request_firmare_nowait() and I DO now see my request handled by mdev, however it is a REMOVE request not the ADD request.
All this makes me think that platform drivers exist before the hotplug mechanism is able to operate, is this true ?
Well, request_firmware is ultimately serviced by a user-space process.
So platform drivers compiled statically into the kernel get initialized long before user-space starts.
Platform drivers compiled as modules will get the firmware loaded much more quickly after loading the module.
Yes this makes sense... I have seen that too ... but is there an elegant way to wait for maybe a uevent and honor the request_firmware_no_wait() call within the platform driver code?
-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
BR Subbu
-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Wednesday, April 18, 2012 3:15 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@kernelnewbies.org Subject: Re: Can request_firmware be called from a platform_driver ? Hi Mike, On Wed, Apr 18, 2012 at 11:07 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
Hi
I have a fully working system to which I want to add the request firmware mechanism to an existing platform driver I have working.
I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that I could figure this out.
What I see with firmware_request() is that the kernel makes the firmware request and does not find any firmware and mdev sees nothing.
However if I change my code to do request_firmare_nowait(), the entire system comes up and about 30seconds in the timeout calls my kernel side continue for request_firmare_nowait() and I DO now see my request handled by mdev, however it is a REMOVE request not the ADD request.
All this makes me think that platform drivers exist before the hotplug mechanism is able to operate, is this true ?
Well, request_firmware is ultimately serviced by a user-space process. So platform drivers compiled statically into the kernel get initialized long before user-space starts. Platform drivers compiled as modules will get the firmware loaded much more quickly after loading the module.
Thanks Dave,
Currently in make menuconfig I put '*' against it to compile it into the kernel, I made it an 'm' so that it is made as a module. For modules made outside the tree I call modprobe to load them, but I never made a module in the tree before, I don't know how to get its init called. When it was compiled in, I called the init from my machine init directly in my mach-lcp/arch.c via platform_device_register() Mike -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
HI Mike, On Wed, Apr 18, 2012 at 1:24 PM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Wednesday, April 18, 2012 3:15 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@kernelnewbies.org Subject: Re: Can request_firmware be called from a platform_driver ?
Hi Mike,
On Wed, Apr 18, 2012 at 11:07 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
Hi
I have a fully working system to which I want to add the request firmware mechanism to an existing platform driver I have working.
I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that I could figure this out.
What I see with firmware_request() is that the kernel makes the firmware request and does not find any firmware and mdev sees nothing.
However if I change my code to do request_firmare_nowait(), the entire system comes up and about 30seconds in the timeout calls my kernel side continue for request_firmare_nowait() and I DO now see my request handled by mdev, however it is a REMOVE request not the ADD request.
All this makes me think that platform drivers exist before the hotplug mechanism is able to operate, is this true ?
Well, request_firmware is ultimately serviced by a user-space process.
So platform drivers compiled statically into the kernel get initialized long before user-space starts.
Platform drivers compiled as modules will get the firmware loaded much more quickly after loading the module.
Thanks Dave,
Currently in make menuconfig I put '*' against it to compile it into the kernel, I made it an 'm' so that it is made as a module. For modules made outside the tree I call modprobe to load them, but I never made a module in the tree before, I don't know how to get its init called. When it was compiled in, I called the init from my machine init directly in my mach-lcp/arch.c via platform_device_register()
As far as init being called, this is identical for modules compiled as part of the kernel as it is for modules compiled out of tree. Normally, you would use module_init to specify a function to be called. This function will be called when a module is loaded (regardless of whether its compiled in or out of tree). For modules statically compiled into the kernel, module_init becomes the same as device_initcall. For code compiled as a module, all of the various xxx_initcall stuff gets translated to module_init See: include/linux/init.h -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Wednesday, April 18, 2012 5:07 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@kernelnewbies.org Subject: Re: Can request_firmware be called from a platform_driver ? HI Mike, On Wed, Apr 18, 2012 at 1:24 PM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Wednesday, April 18, 2012 3:15 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@kernelnewbies.org Subject: Re: Can request_firmware be called from a platform_driver ?
Hi Mike,
On Wed, Apr 18, 2012 at 11:07 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
Hi
I have a fully working system to which I want to add the request firmware mechanism to an existing platform driver I have working.
I instrumented mdev in busybox 1.5.1 and in firmware_class.c 2.6.35 so that I could figure this out.
What I see with firmware_request() is that the kernel makes the firmware request and does not find any firmware and mdev sees nothing.
However if I change my code to do request_firmare_nowait(), the entire system comes up and about 30seconds in the timeout calls my kernel side continue for request_firmare_nowait() and I DO now see my request handled by mdev, however it is a REMOVE request not the ADD request.
All this makes me think that platform drivers exist before the hotplug mechanism is able to operate, is this true ?
Well, request_firmware is ultimately serviced by a user-space process.
So platform drivers compiled statically into the kernel get initialized long before user-space starts.
Platform drivers compiled as modules will get the firmware loaded much more quickly after loading the module.
Thanks Dave,
Currently in make menuconfig I put '*' against it to compile it into the kernel, I made it an 'm' so that it is made as a module. For modules made outside the tree I call modprobe to load them, but I never made a module in the tree before, I don't know how to get its init called. When it was compiled in, I called the init from my machine init directly in my mach-lcp/arch.c via platform_device_register()
As far as init being called, this is identical for modules compiled as part of the kernel as it is for modules compiled out of tree. Normally, you would use module_init to specify a function to be called. This function will be called when a module is loaded (regardless of whether its compiled in or out of tree). For modules statically compiled into the kernel, module_init becomes the same as device_initcall. For code compiled as a module, all of the various xxx_initcall stuff gets translated to module_init See: include/linux/init.h
Thanks, my module does use module_init, but now that this code is compiled as a module and not compiled into the kernel, I find that the .probe method is never called so I must still be missing something.
I tried calling the probe directly in the init but this still fails with modprobe complaining. Should my .probe be called if my init only calls platform_driver_register and this module is loaded with modprobe rather than by the kernel booting? And really I only want to call the probe method so that I can get hold of a struct platform_device *pdev to call firmware_request() with, maybe I am going about this completely incorrectly? I see at this link http://lwn.net/Articles/198461/ they do not use a platform_driver_register but a device_register, is that my mistake ? Still struggling, but I am now using the shotgun programming approach of trying anything I can dream up to figure it out :-) Mike
Hi Mike, On Thu, Apr 19, 2012 at 9:42 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
...snip...
Thanks, my module does use module_init, but now that this code is compiled as a module and not compiled into the kernel, I find that the .probe method is never called so I must still be missing something.
I tried calling the probe directly in the init but this still fails with modprobe complaining.
Should my .probe be called if my init only calls platform_driver_register and this module is loaded with modprobe rather than by the kernel booting? And really I only want to call the probe method so that I can get hold of a struct platform_device *pdev to call firmware_request() with, maybe I am going about this completely incorrectly?
In order for your probe routine to be called there has to be both a device and driver registered with the same name. Normally the device is registered in the board init, and the driver does the call to register the driver in its init routine. When a match is found, that then causes the probe routine to be called. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
-----Original Message----- From: Dave Hylands [mailto:dhylands@gmail.com] Sent: Thursday, April 19, 2012 1:13 PM To: Holmes, Michael A (Mike) Cc: kernelnewbies@kernelnewbies.org Subject: Re: Can request_firmware be called from a platform_driver ? Hi Mike, On Thu, Apr 19, 2012 at 9:42 AM, Holmes, Michael A (Mike) <Mike.Holmes@lsi.com> wrote:
...snip...
Thanks, my module does use module_init, but now that this code is compiled as a module and not compiled into the kernel, I find that the .probe method is never called so I must still be missing something.
I tried calling the probe directly in the init but this still fails with modprobe complaining.
Should my .probe be called if my init only calls platform_driver_register and this module is loaded with modprobe rather than by the kernel booting? And really I only want to call the probe method so that I can get hold of a struct platform_device *pdev to call firmware_request() with, maybe I am going about this completely incorrectly?
In order for your probe routine to be called there has to be both a device and driver registered with the same name. Normally the device is registered in the board init, and the driver does the call to register the driver in its init routine. When a match is found, that then causes the probe routine to be called. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
Thank you again Dave, you are a genius! All the little pieces have now fallen into place. I even see why I was not getting the mdev events originally; I was copying code that set up a driver which is only 1/2 the picture, it is when the device matches a driver later on that the mdev events should be triggered. platform.txt now makes sense to me, it was opaque before, the answer is written there clearly, but I didn't see it in all the times I had read it.
Mike
participants (3)
-
Dave Hylands -
Holmes, Michael A (Mike) -
Subramaniam Appadodharana