Controlling Driver Load Order

Controlling Driver Load Order

[Robert Emanuele]

Greetings,

Hopefully this is an easy question but I haven't found a solution yet.

On my at91sam9g45 platform I need my i2c drivers to load before the
framebuffer driver.  The i2c drivers control a power management IC
which is needed to enable the graphics controller.

Is there a way to set up that order?

Thank you,

Rob Emanuele

Controlling Driver Load Order

[Robert Emanuele]

Greetings,

Hopefully this is an easy question but I haven't found a solution yet.

On my at91sam9g45 platform I need my i2c drivers to load before the
framebuffer driver.  The i2c drivers control a power management IC
which is needed to enable the graphics controller.

Is there a way to set up that order?

Thank you,

Rob Emanuele

Controlling Driver Load Order

[Linus Walleij]

2010/5/26 Robert Emanuele <rob@emanuele.us>:

> On my at91sam9g45 platform I need my i2c drivers to load before the
> framebuffer driver. ?The i2c drivers control a power management IC
> which is needed to enable the graphics controller.
>
> Is there a way to set up that order?

The usual trick (which you can find in a lot of other I2C busses) is to use
a core_initcall() instead of module_init().

You find the different init levels in include/linux/init.h

Yours,
Linus Walleij

Re: Controlling Driver Load Order

[Linus Walleij]

2010/5/26 Robert Emanuele <rob@emanuele.us>:

> On my at91sam9g45 platform I need my i2c drivers to load before the
> framebuffer driver.  The i2c drivers control a power management IC
> which is needed to enable the graphics controller.
>
> Is there a way to set up that order?

The usual trick (which you can find in a lot of other I2C busses) is to use
a core_initcall() instead of module_init().

You find the different init levels in include/linux/init.h

Yours,
Linus Walleij

Controlling Driver Load Order

[Linus Walleij]

2010/5/26 Linus Walleij <linus.ml.walleij@gmail.com>:
> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
>
>> On my at91sam9g45 platform I need my i2c drivers to load before the
>> framebuffer driver. ?The i2c drivers control a power management IC
>> which is needed to enable the graphics controller.
>>
>> Is there a way to set up that order?
>
> The usual trick (which you can find in a lot of other I2C busses) is to use
> a core_initcall() instead of module_init().

No, sorry that will probably not work.

I meant subsystem_initcall().

Yours,
Linus Walleij

Re: Controlling Driver Load Order

[Linus Walleij]

2010/5/26 Linus Walleij <linus.ml.walleij@gmail.com>:
> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
>
>> On my at91sam9g45 platform I need my i2c drivers to load before the
>> framebuffer driver.  The i2c drivers control a power management IC
>> which is needed to enable the graphics controller.
>>
>> Is there a way to set up that order?
>
> The usual trick (which you can find in a lot of other I2C busses) is to use
> a core_initcall() instead of module_init().

No, sorry that will probably not work.

I meant subsystem_initcall().

Yours,
Linus Walleij

Controlling Driver Load Order

[Wolfram Sang]

On Wed, May 26, 2010 at 11:04:01PM +0200, Linus Walleij wrote:
> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
> 
> > On my at91sam9g45 platform I need my i2c drivers to load before the
> > framebuffer driver. ?The i2c drivers control a power management IC
> > which is needed to enable the graphics controller.
> >
> > Is there a way to set up that order?
> 
> The usual trick (which you can find in a lot of other I2C busses) is to use
> a core_initcall() instead of module_init().

Correct, but it's subsys_initcall().

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100527/7c89b860/attachment.sig>

Re: Controlling Driver Load Order

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

On Wed, May 26, 2010 at 11:04:01PM +0200, Linus Walleij wrote:
> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
> 
> > On my at91sam9g45 platform I need my i2c drivers to load before the
> > framebuffer driver.  The i2c drivers control a power management IC
> > which is needed to enable the graphics controller.
> >
> > Is there a way to set up that order?
> 
> The usual trick (which you can find in a lot of other I2C busses) is to use
> a core_initcall() instead of module_init().

Correct, but it's subsys_initcall().

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Controlling Driver Load Order

[Robert Emanuele]

Maybe I'm not describing this correctly...
In my platform init_machine I had something like this:
{
at91_add_device_i2c(1, my_i2c_devices, ARRAY_SIZE(my_i2c_devices));

add_my_display


On Wed, May 26, 2010 at 4:52 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 26, 2010 at 11:04:01PM +0200, Linus Walleij wrote:
>> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
>>
>> > On my at91sam9g45 platform I need my i2c drivers to load before the
>> > framebuffer driver. ?The i2c drivers control a power management IC
>> > which is needed to enable the graphics controller.
>> >
>> > Is there a way to set up that order?
>>
>> The usual trick (which you can find in a lot of other I2C busses) is to use
>> a core_initcall() instead of module_init().
>
> Correct, but it's subsys_initcall().
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Wolfram Sang ? ? ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv9tE4ACgkQD27XaX1/VRsuwgCgtuBO/G43yUxbTED+MdBf6tUv
> 9hYAn0WL0L475IYsXqiOlUMzGmdrAcr7
> =KcVU
> -----END PGP SIGNATURE-----
>
>

Re: Controlling Driver Load Order

[Robert Emanuele]

Maybe I'm not describing this correctly...
In my platform init_machine I had something like this:
{
at91_add_device_i2c(1, my_i2c_devices, ARRAY_SIZE(my_i2c_devices));

add_my_display


On Wed, May 26, 2010 at 4:52 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 26, 2010 at 11:04:01PM +0200, Linus Walleij wrote:
>> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
>>
>> > On my at91sam9g45 platform I need my i2c drivers to load before the
>> > framebuffer driver.  The i2c drivers control a power management IC
>> > which is needed to enable the graphics controller.
>> >
>> > Is there a way to set up that order?
>>
>> The usual trick (which you can find in a lot of other I2C busses) is to use
>> a core_initcall() instead of module_init().
>
> Correct, but it's subsys_initcall().
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv9tE4ACgkQD27XaX1/VRsuwgCgtuBO/G43yUxbTED+MdBf6tUv
> 9hYAn0WL0L475IYsXqiOlUMzGmdrAcr7
> =KcVU
> -----END PGP SIGNATURE-----
>
>

Controlling Driver Load Order

[Robert Emanuele]

Thank you for the suggestions but maybe I'm not describing this correctly...

In my platform's init_machine I had something like this:
{
    at91_add_device_i2c(1, my_i2c_devices, ARRAY_SIZE(my_i2c_devices));

    add_my_display();
}

Both of those calls lead to a platform_device_add.  I've tried moving
the at91_add_device_i2c into a function that was referenced by
subsys_initcall() like so:
static void __init power_control_init(void)
{
	at91_add_device_i2c(1, my_i2c_devices, ARRAY_SIZE(my_i2c_devices));
}
subsys_initcall(power_control_init);

Still the framebuffer device would initialize first and it would lack
having the i2c chips it needs ready.  That is the order I'm trying to
straighten out.

Thank you,

Rob

On Wed, May 26, 2010 at 4:52 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 26, 2010 at 11:04:01PM +0200, Linus Walleij wrote:
>> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
>>
>> > On my at91sam9g45 platform I need my i2c drivers to load before the
>> > framebuffer driver. ?The i2c drivers control a power management IC
>> > which is needed to enable the graphics controller.
>> >
>> > Is there a way to set up that order?
>>
>> The usual trick (which you can find in a lot of other I2C busses) is to use
>> a core_initcall() instead of module_init().
>
> Correct, but it's subsys_initcall().
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Wolfram Sang ? ? ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv9tE4ACgkQD27XaX1/VRsuwgCgtuBO/G43yUxbTED+MdBf6tUv
> 9hYAn0WL0L475IYsXqiOlUMzGmdrAcr7
> =KcVU
> -----END PGP SIGNATURE-----
>
>

Re: Controlling Driver Load Order

[Robert Emanuele]

Thank you for the suggestions but maybe I'm not describing this correctly...

In my platform's init_machine I had something like this:
{
    at91_add_device_i2c(1, my_i2c_devices, ARRAY_SIZE(my_i2c_devices));

    add_my_display();
}

Both of those calls lead to a platform_device_add.  I've tried moving
the at91_add_device_i2c into a function that was referenced by
subsys_initcall() like so:
static void __init power_control_init(void)
{
	at91_add_device_i2c(1, my_i2c_devices, ARRAY_SIZE(my_i2c_devices));
}
subsys_initcall(power_control_init);

Still the framebuffer device would initialize first and it would lack
having the i2c chips it needs ready.  That is the order I'm trying to
straighten out.

Thank you,

Rob

On Wed, May 26, 2010 at 4:52 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 26, 2010 at 11:04:01PM +0200, Linus Walleij wrote:
>> 2010/5/26 Robert Emanuele <rob@emanuele.us>:
>>
>> > On my at91sam9g45 platform I need my i2c drivers to load before the
>> > framebuffer driver.  The i2c drivers control a power management IC
>> > which is needed to enable the graphics controller.
>> >
>> > Is there a way to set up that order?
>>
>> The usual trick (which you can find in a lot of other I2C busses) is to use
>> a core_initcall() instead of module_init().
>
> Correct, but it's subsys_initcall().
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv9tE4ACgkQD27XaX1/VRsuwgCgtuBO/G43yUxbTED+MdBf6tUv
> 9hYAn0WL0L475IYsXqiOlUMzGmdrAcr7
> =KcVU
> -----END PGP SIGNATURE-----
>
>

Re: Controlling Driver Load Order

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Wed, May 26, 2010 at 06:39:13PM -0700, Robert Emanuele wrote:

> Still the framebuffer device would initialize first and it would lack
> having the i2c chips it needs ready.  That is the order I'm trying to
> straighten out.

Understood. Our pointers were probably not precise enough, sorry. Please try
this patch and give a Tested-by-tag if it solves your problems.

From: Wolfram Sang <w.sang@pengutronix.de>
Date: Thu, 27 May 2010 06:03:48 +0200
Subject: [PATCH] i2c-at91: use subsys_initcall() for early initialization

I2C needs to be available early, so other subsystems can access it.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Robert Emanuele <rob@emanuele.us>
Cc: Ben Dooks <ben-linux@fluff.org>
---

 drivers/i2c/busses/i2c-at91.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 305c075..bea5794 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -313,13 +313,12 @@ static int __init at91_i2c_init(void)
 {
 	return platform_driver_register(&at91_i2c_driver);
 }
+subsys_initcall(at91_i2c_init);
 
 static void __exit at91_i2c_exit(void)
 {
 	platform_driver_unregister(&at91_i2c_driver);
 }
-
-module_init(at91_i2c_init);
 module_exit(at91_i2c_exit);
 
 MODULE_AUTHOR("Rick Bronson");


-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Controlling Driver Load Order

[Wolfram Sang]

On Wed, May 26, 2010 at 06:39:13PM -0700, Robert Emanuele wrote:

> Still the framebuffer device would initialize first and it would lack
> having the i2c chips it needs ready.  That is the order I'm trying to
> straighten out.

Understood. Our pointers were probably not precise enough, sorry. Please try
this patch and give a Tested-by-tag if it solves your problems.

From: Wolfram Sang <w.sang@pengutronix.de>
Date: Thu, 27 May 2010 06:03:48 +0200
Subject: [PATCH] i2c-at91: use subsys_initcall() for early initialization

I2C needs to be available early, so other subsystems can access it.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Robert Emanuele <rob@emanuele.us>
Cc: Ben Dooks <ben-linux@fluff.org>
---

 drivers/i2c/busses/i2c-at91.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 305c075..bea5794 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -313,13 +313,12 @@ static int __init at91_i2c_init(void)
 {
 	return platform_driver_register(&at91_i2c_driver);
 }
+subsys_initcall(at91_i2c_init);
 
 static void __exit at91_i2c_exit(void)
 {
 	platform_driver_unregister(&at91_i2c_driver);
 }
-
-module_init(at91_i2c_init);
 module_exit(at91_i2c_exit);
 
 MODULE_AUTHOR("Rick Bronson");


-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100527/0ac368f0/attachment.sig>

Re: Controlling Driver Load Order

[Robert Emanuele]

Hi Wolfram,

I am using the i2c-gpio.c driver, not the i2c-at91 driver.  The Atmel
folks have expressed concerns over their i2c silicon and wrote a gpio
version.

Anyway, I better understand the subsys_initcall now and applied that
to the i2c-gpio and my i2c chip driver.  That worked perfectly for my
issue.  I'd be happy to return a patch of this.  Would be this the
sort of thing that would benefit from a config option?  Something
like:

#if defined(CONFIG_EARLY_i2C_GPIO)
subsys_initcall(i2c_gpio_init);
#else
module_init(i2c_gpio_init);
#endif

I appreciate your help and direction.

Thank you,

Rob

On Wed, May 26, 2010 at 9:13 PM, Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> On Wed, May 26, 2010 at 06:39:13PM -0700, Robert Emanuele wrote:
>
>> Still the framebuffer device would initialize first and it would lack
>> having the i2c chips it needs ready.  That is the order I'm trying to
>> straighten out.
>
> Understood. Our pointers were probably not precise enough, sorry. Please try
> this patch and give a Tested-by-tag if it solves your problems.
>
> From: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Date: Thu, 27 May 2010 06:03:48 +0200
> Subject: [PATCH] i2c-at91: use subsys_initcall() for early initialization
>
> I2C needs to be available early, so other subsystems can access it.
>
> Signed-off-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Robert Emanuele <rob-3bOSxtzXIkJzbRFIqnYvSA@public.gmane.org>
> Cc: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
> ---
>
>  drivers/i2c/busses/i2c-at91.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 305c075..bea5794 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -313,13 +313,12 @@ static int __init at91_i2c_init(void)
>  {
>        return platform_driver_register(&at91_i2c_driver);
>  }
> +subsys_initcall(at91_i2c_init);
>
>  static void __exit at91_i2c_exit(void)
>  {
>        platform_driver_unregister(&at91_i2c_driver);
>  }
> -
> -module_init(at91_i2c_init);
>  module_exit(at91_i2c_exit);
>
>  MODULE_AUTHOR("Rick Bronson");
>
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv98YYACgkQD27XaX1/VRsvlwCffUOH2qAsWbaG2EmIf1Cl2H+I
> 8P4AoInnCS69XCfq6wIFku1hUgeT8hlG
> =vGcD
> -----END PGP SIGNATURE-----
>
>

Re: Controlling Driver Load Order

[Robert Emanuele]

Hi Wolfram,

I am using the i2c-gpio.c driver, not the i2c-at91 driver.  The Atmel
folks have expressed concerns over their i2c silicon and wrote a gpio
version.

Anyway, I better understand the subsys_initcall now and applied that
to the i2c-gpio and my i2c chip driver.  That worked perfectly for my
issue.  I'd be happy to return a patch of this.  Would be this the
sort of thing that would benefit from a config option?  Something
like:

#if defined(CONFIG_EARLY_i2C_GPIO)
subsys_initcall(i2c_gpio_init);
#else
module_init(i2c_gpio_init);
#endif

I appreciate your help and direction.

Thank you,

Rob

On Wed, May 26, 2010 at 9:13 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 26, 2010 at 06:39:13PM -0700, Robert Emanuele wrote:
>
>> Still the framebuffer device would initialize first and it would lack
>> having the i2c chips it needs ready.  That is the order I'm trying to
>> straighten out.
>
> Understood. Our pointers were probably not precise enough, sorry. Please try
> this patch and give a Tested-by-tag if it solves your problems.
>
> From: Wolfram Sang <w.sang@pengutronix.de>
> Date: Thu, 27 May 2010 06:03:48 +0200
> Subject: [PATCH] i2c-at91: use subsys_initcall() for early initialization
>
> I2C needs to be available early, so other subsystems can access it.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Robert Emanuele <rob@emanuele.us>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>
>  drivers/i2c/busses/i2c-at91.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 305c075..bea5794 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -313,13 +313,12 @@ static int __init at91_i2c_init(void)
>  {
>        return platform_driver_register(&at91_i2c_driver);
>  }
> +subsys_initcall(at91_i2c_init);
>
>  static void __exit at91_i2c_exit(void)
>  {
>        platform_driver_unregister(&at91_i2c_driver);
>  }
> -
> -module_init(at91_i2c_init);
>  module_exit(at91_i2c_exit);
>
>  MODULE_AUTHOR("Rick Bronson");
>
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv98YYACgkQD27XaX1/VRsvlwCffUOH2qAsWbaG2EmIf1Cl2H+I
> 8P4AoInnCS69XCfq6wIFku1hUgeT8hlG
> =vGcD
> -----END PGP SIGNATURE-----
>
>

Controlling Driver Load Order

[Robert Emanuele]

Hi Wolfram,

I am using the i2c-gpio.c driver, not the i2c-at91 driver.  The Atmel
folks have expressed concerns over their i2c silicon and wrote a gpio
version.

Anyway, I better understand the subsys_initcall now and applied that
to the i2c-gpio and my i2c chip driver.  That worked perfectly for my
issue.  I'd be happy to return a patch of this.  Would be this the
sort of thing that would benefit from a config option?  Something
like:

#if defined(CONFIG_EARLY_i2C_GPIO)
subsys_initcall(i2c_gpio_init);
#else
module_init(i2c_gpio_init);
#endif

I appreciate your help and direction.

Thank you,

Rob

On Wed, May 26, 2010 at 9:13 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 26, 2010 at 06:39:13PM -0700, Robert Emanuele wrote:
>
>> Still the framebuffer device would initialize first and it would lack
>> having the i2c chips it needs ready. ?That is the order I'm trying to
>> straighten out.
>
> Understood. Our pointers were probably not precise enough, sorry. Please try
> this patch and give a Tested-by-tag if it solves your problems.
>
> From: Wolfram Sang <w.sang@pengutronix.de>
> Date: Thu, 27 May 2010 06:03:48 +0200
> Subject: [PATCH] i2c-at91: use subsys_initcall() for early initialization
>
> I2C needs to be available early, so other subsystems can access it.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Robert Emanuele <rob@emanuele.us>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>
> ?drivers/i2c/busses/i2c-at91.c | ? ?3 +--
> ?1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 305c075..bea5794 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -313,13 +313,12 @@ static int __init at91_i2c_init(void)
> ?{
> ? ? ? ?return platform_driver_register(&at91_i2c_driver);
> ?}
> +subsys_initcall(at91_i2c_init);
>
> ?static void __exit at91_i2c_exit(void)
> ?{
> ? ? ? ?platform_driver_unregister(&at91_i2c_driver);
> ?}
> -
> -module_init(at91_i2c_init);
> ?module_exit(at91_i2c_exit);
>
> ?MODULE_AUTHOR("Rick Bronson");
>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Wolfram Sang ? ? ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkv98YYACgkQD27XaX1/VRsvlwCffUOH2qAsWbaG2EmIf1Cl2H+I
> 8P4AoInnCS69XCfq6wIFku1hUgeT8hlG
> =vGcD
> -----END PGP SIGNATURE-----
>
>

Re: Controlling Driver Load Order

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

> Anyway, I better understand the subsys_initcall now and applied that
> to the i2c-gpio and my i2c chip driver.  That worked perfectly for my

With chip-driver you mean the PMIC? Yes, that is probably needed there, too.
Which driver is it?

> issue.  I'd be happy to return a patch of this.  Would be this the
> sort of thing that would benefit from a config option?  Something

Nope, there is no bigger drawback to this and probably a number of useres
wouldn't know what to select here. Just patch the module_init() away.

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Controlling Driver Load Order

[Wolfram Sang]

> Anyway, I better understand the subsys_initcall now and applied that
> to the i2c-gpio and my i2c chip driver.  That worked perfectly for my

With chip-driver you mean the PMIC? Yes, that is probably needed there, too.
Which driver is it?

> issue.  I'd be happy to return a patch of this.  Would be this the
> sort of thing that would benefit from a config option?  Something

Nope, there is no bigger drawback to this and probably a number of useres
wouldn't know what to select here. Just patch the module_init() away.

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100527/89732004/attachment.sig>

Re: Controlling Driver Load Order

[Ryan Mallon]

Robert Emanuele wrote:
> Hi Wolfram,
> 
> I am using the i2c-gpio.c driver, not the i2c-at91 driver.  The Atmel
> folks have expressed concerns over their i2c silicon and wrote a gpio
> version.
> 
> Anyway, I better understand the subsys_initcall now and applied that
> to the i2c-gpio and my i2c chip driver.  That worked perfectly for my
> issue.  I'd be happy to return a patch of this.  Would be this the
> sort of thing that would benefit from a config option?  Something
> like:
> 
> #if defined(CONFIG_EARLY_i2C_GPIO)
> subsys_initcall(i2c_gpio_init);
> #else
> module_init(i2c_gpio_init);
> #endif

Looks like this has already been done:
http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg03056.html

There was a discussion a while back to make all of the embedded i2c
busses be subsys_initcall since i2c is often a system bus on embedded
devices. Looks the i2c_gpio driver got missed the first time round.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Controlling Driver Load Order

[Ryan Mallon]

Robert Emanuele wrote:
> Hi Wolfram,
> 
> I am using the i2c-gpio.c driver, not the i2c-at91 driver.  The Atmel
> folks have expressed concerns over their i2c silicon and wrote a gpio
> version.
> 
> Anyway, I better understand the subsys_initcall now and applied that
> to the i2c-gpio and my i2c chip driver.  That worked perfectly for my
> issue.  I'd be happy to return a patch of this.  Would be this the
> sort of thing that would benefit from a config option?  Something
> like:
> 
> #if defined(CONFIG_EARLY_i2C_GPIO)
> subsys_initcall(i2c_gpio_init);
> #else
> module_init(i2c_gpio_init);
> #endif

Looks like this has already been done:
http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg03056.html

There was a discussion a while back to make all of the embedded i2c
busses be subsys_initcall since i2c is often a system bus on embedded
devices. Looks the i2c_gpio driver got missed the first time round.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: Controlling Driver Load Order

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]


> Looks like this has already been done:
> http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg03056.html

Always ask which kernel is used, sigh...

> 
> There was a discussion a while back to make all of the embedded i2c
> busses be subsys_initcall since i2c is often a system bus on embedded

Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
patch above as well ;))

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Controlling Driver Load Order

[Wolfram Sang]

> Looks like this has already been done:
> http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg03056.html

Always ask which kernel is used, sigh...

> 
> There was a discussion a while back to make all of the embedded i2c
> busses be subsys_initcall since i2c is often a system bus on embedded

Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
patch above as well ;))

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100527/79d43255/attachment.sig>

Re: Controlling Driver Load Order

[Ryan Mallon]

Wolfram Sang wrote:
>> Looks like this has already been done:
>> http://www.mail-archive.com/linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg03056.html
> 
> Always ask which kernel is used, sigh...

Sorry? I didn't see a kernel version mentioned. I went looking because I
had though that i2c-gpio was already subsys_initcall.

>> There was a discussion a while back to make all of the embedded i2c
>> busses be subsys_initcall since i2c is often a system bus on embedded
> 
> Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
> patch above as well ;))
> 

Moving the embedded i2c busses to subsys_initcall was discussed here:
http://lists.lm-sensors.org/pipermail/i2c/2008-June/004142.html. The
i2c_gpio bus got mentioned, which is why I thought it had already been
changed.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: Controlling Driver Load Order

[Ryan Mallon]

Wolfram Sang wrote:
>> Looks like this has already been done:
>> http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg03056.html
> 
> Always ask which kernel is used, sigh...

Sorry? I didn't see a kernel version mentioned. I went looking because I
had though that i2c-gpio was already subsys_initcall.

>> There was a discussion a while back to make all of the embedded i2c
>> busses be subsys_initcall since i2c is often a system bus on embedded
> 
> Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
> patch above as well ;))
> 

Moving the embedded i2c busses to subsys_initcall was discussed here:
http://lists.lm-sensors.org/pipermail/i2c/2008-June/004142.html. The
i2c_gpio bus got mentioned, which is why I thought it had already been
changed.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Controlling Driver Load Order

[Ryan Mallon]

Wolfram Sang wrote:
>> Looks like this has already been done:
>> http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg03056.html
> 
> Always ask which kernel is used, sigh...

Sorry? I didn't see a kernel version mentioned. I went looking because I
had though that i2c-gpio was already subsys_initcall.

>> There was a discussion a while back to make all of the embedded i2c
>> busses be subsys_initcall since i2c is often a system bus on embedded
> 
> Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
> patch above as well ;))
> 

Moving the embedded i2c busses to subsys_initcall was discussed here:
http://lists.lm-sensors.org/pipermail/i2c/2008-June/004142.html. The
i2c_gpio bus got mentioned, which is why I thought it had already been
changed.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: Controlling Driver Load Order

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

> > Always ask which kernel is used, sigh...
> 
> Sorry? I didn't see a kernel version mentioned. I went looking because I
> had though that i2c-gpio was already subsys_initcall.

Sorry, I missed emphasizing that my comment was meant as a "note-to-myself".
You were perfectly right, of course, I should have done the same.

> >> There was a discussion a while back to make all of the embedded i2c
> >> busses be subsys_initcall since i2c is often a system bus on embedded
> > 
> > Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
> > patch above as well ;))
> > 
> 
> Moving the embedded i2c busses to subsys_initcall was discussed here:
> http://lists.lm-sensors.org/pipermail/i2c/2008-June/004142.html. The
> i2c_gpio bus got mentioned, which is why I thought it had already been
> changed.

Thanks for the pointer!

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Controlling Driver Load Order

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

> > Always ask which kernel is used, sigh...
> 
> Sorry? I didn't see a kernel version mentioned. I went looking because I
> had though that i2c-gpio was already subsys_initcall.

Sorry, I missed emphasizing that my comment was meant as a "note-to-myself".
You were perfectly right, of course, I should have done the same.

> >> There was a discussion a while back to make all of the embedded i2c
> >> busses be subsys_initcall since i2c is often a system bus on embedded
> > 
> > Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
> > patch above as well ;))
> > 
> 
> Moving the embedded i2c busses to subsys_initcall was discussed here:
> http://lists.lm-sensors.org/pipermail/i2c/2008-June/004142.html. The
> i2c_gpio bus got mentioned, which is why I thought it had already been
> changed.

Thanks for the pointer!

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Controlling Driver Load Order

[Wolfram Sang]

> > Always ask which kernel is used, sigh...
> 
> Sorry? I didn't see a kernel version mentioned. I went looking because I
> had though that i2c-gpio was already subsys_initcall.

Sorry, I missed emphasizing that my comment was meant as a "note-to-myself".
You were perfectly right, of course, I should have done the same.

> >> There was a discussion a while back to make all of the embedded i2c
> >> busses be subsys_initcall since i2c is often a system bus on embedded
> > 
> > Oh, where was that? Can't recall (but couldn't recall that I acked the i2c-gpio
> > patch above as well ;))
> > 
> 
> Moving the embedded i2c busses to subsys_initcall was discussed here:
> http://lists.lm-sensors.org/pipermail/i2c/2008-June/004142.html. The
> i2c_gpio bus got mentioned, which is why I thought it had already been
> changed.

Thanks for the pointer!

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100528/5f9d5fe7/attachment.sig>