devicetree vs. MODULE_DEPEND

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

devicetree vs. MODULE_DEPEND

Manuel Stühn
Hi list,

is it correct, that the sequence in the devicetree-blob defines the
probing sequence without considering the MODULE_DEPEND-macro?

I stumbled over an unexpected behavior during the ti_pruss-driver
development. Because the ti-pruss is gone in the default devicetree, I
activate it via the overlay-framework and put it to the address
"/ocp/pruss@4a300000".  The devicetree-blob contains the entry and the
driver gets probed, but it fails to enable its clock.
This is quite obvious as according to dmesg the am335x_prcm0 is probed
_after_ the ti_pruss0 device. So I tried to handle this by adding an
explicit dependency to ti_prcm into the ti_pruss driver like:
MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1);

It compiles cleanly, unfortunately this changes nothing. Only placing it
in the devicetree after the prcm-node or loading it as a module after
the OS booted up makes the device probe correctly.

Any ideas?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devicetree vs. MODULE_DEPEND

Ian Lepore-3
On Wed, 2017-08-09 at 22:59 +0200, Manuel Stühn wrote:

> Hi list,
>
> is it correct, that the sequence in the devicetree-blob defines the 
> probing sequence without considering the MODULE_DEPEND-macro?
>
> I stumbled over an unexpected behavior during the ti_pruss-driver 
> development. Because the ti-pruss is gone in the default devicetree,
> I 
> activate it via the overlay-framework and put it to the address 
> "/ocp/pruss@4a300000".  The devicetree-blob contains the entry and
> the 
> driver gets probed, but it fails to enable its clock. 
> This is quite obvious as according to dmesg the am335x_prcm0 is
> probed 
> _after_ the ti_pruss0 device. So I tried to handle this by adding an 
> explicit dependency to ti_prcm into the ti_pruss driver like: 
> MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1);
>
> It compiles cleanly, unfortunately this changes nothing. Only placing
> it 
> in the devicetree after the prcm-node or loading it as a module
> after 
> the OS booted up makes the device probe correctly.
>
> Any ideas?
MODULE_DEPEND only affects the kernel linker.  It ensures that other
modules you depend on automatically get loaded along with your module.

Try the attached patch to ensure that the clocks driver is loaded
earlier than drivers that might rely on it.

-- Ian

Index: am335x/am335x_prcm.c
===================================================================
--- am335x/am335x_prcm.c (revision 322019)
+++ am335x/am335x_prcm.c (working copy)
@@ -465,8 +465,8 @@ static driver_t am335x_prcm_driver = {
 
 static devclass_t am335x_prcm_devclass;
 
-DRIVER_MODULE(am335x_prcm, simplebus, am335x_prcm_driver,
- am335x_prcm_devclass, 0, 0);
+EARLY_DRIVER_MODULE(am335x_prcm, simplebus, am335x_prcm_driver,
+ am335x_prcm_devclass, 0, 0, BUS_PASS_TIMER + BUS_PASS_ORDER_EARLY);
 MODULE_VERSION(am335x_prcm, 1);
 MODULE_DEPEND(am335x_prcm, ti_scm, 1, 1, 1);
 

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: devicetree vs. MODULE_DEPEND

Manuel Stühn
On Wed, 09 Aug 2017 15:59:21 -0600, Ian Lepore wrote

> On Wed, 2017-08-09 at 22:59 +0200, Manuel Stühn wrote:
>> Hi list,
>>
>> is it correct, that the sequence in the devicetree-blob defines the
>> probing sequence without considering the MODULE_DEPEND-macro?
>>
>> I stumbled over an unexpected behavior during the ti_pruss-driver
>> development. Because the ti-pruss is gone in the default devicetree,
>> I
>> activate it via the overlay-framework and put it to the address
>> "/ocp/pruss@4a300000".  The devicetree-blob contains the entry and
>> the
>> driver gets probed, but it fails to enable its clock.
>> This is quite obvious as according to dmesg the am335x_prcm0 is
>> probed
>> _after_ the ti_pruss0 device. So I tried to handle this by adding an
>> explicit dependency to ti_prcm into the ti_pruss driver like:
>> MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1);
>>
>> It compiles cleanly, unfortunately this changes nothing. Only placing
>> it
>> in the devicetree after the prcm-node or loading it as a module
>> after
>> the OS booted up makes the device probe correctly.
>>
>> Any ideas?
>
> MODULE_DEPEND only affects the kernel linker.  It ensures that other
> modules you depend on automatically get loaded along with your module.
>
> Try the attached patch to ensure that the clocks driver is loaded
> earlier than drivers that might rely on it.
>

The patch works for me, thanks for your help!
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"