Skip to contentSkip to conversation

arch_initcall time

DISCUSSION Sean MacLennan 4 participants 5 messages Feb 18, 2008

lore
Share & tools
lore
#0 lore raw

I need to call i2c_register_board_info for the new i2c style ad7414 driver. This needs to be called at arch initcall time. Currently I just do this:

static int __init warp_arch_init(void)

{
	i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
	return 0;
}

arch_initcall(warp_arch_init);

It works, but is there a "better" place to put this? None of the other powerpc platforms make this call and I want to get it right, so that others don't blindly follow my example ;)

I kept the name vague rather than specific in case more drivers need to be setup this way in the future.

Cheers,
Sean

#1 lore raw
Quoted 10 lines · Sean MacLennan

I need to call i2c_register_board_info for the new i2c style ad7414 driver. This needs to be called at arch initcall time. Currently I just do this:

static int __init warp_arch_init(void)

{
        i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
        return 0;
}

arch_initcall(warp_arch_init);

Yes, this is the right thing to do, but use machine_arch_initcall() instead so that it doesn't get called if it is not your board.

Cheers,
g.

Signature · 2 lines
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
#2 lore raw
Quoted 12 lines · Grant Likely
Quoted 10 lines · Sean MacLennan

I need to call i2c_register_board_info for the new i2c style ad7414 driver. This needs to be called at arch initcall time. Currently I just do this:

static int __init warp_arch_init(void)

{
        i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
        return 0;
}

arch_initcall(warp_arch_init);

Quoted 2 lines

Yes, this is the right thing to do, but use machine_arch_initcall() instead so that it doesn't get called if it is not your board.

That being said, I believe there is infrastructure to handle the creation of your i2c board info from the device tree. Your i2c board info should not be hard coded.

Cheers,
g.

Signature · 2 lines
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
#3 lore raw
Quoted 13 lines · Grant Likely
Quoted 12 lines · Grant Likely
Quoted 10 lines · Sean MacLennan

I need to call i2c_register_board_info for the new i2c style ad7414 driver. This needs to be called at arch initcall time. Currently I just do this:

static int __init warp_arch_init(void)

{
        i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
        return 0;
}

arch_initcall(warp_arch_init);

Quoted 6 lines
Quoted 2 lines

Yes, this is the right thing to do, but use machine_arch_initcall() instead so that it doesn't get called if it is not your board.

That being said, I believe there is infrastructure to handle the creation of your i2c board info from the device tree. Your i2c board info should not be hard coded.

Jon Smirl's patches? Not yet, unfortunately. It didn't make .25, but maybe for .26.

(I will need to do it specifically on my platform, like fsl_soc already does, as a stopgap until then).

-Olof

#4 lore raw
Quoted 21 lines · On Mon, 18 Feb 2008 12:42:40 -0600 Olof Johansson <[email protected]> wrote:
Quoted 13 lines · Grant Likely
Quoted 12 lines · Grant Likely
Quoted 10 lines · Sean MacLennan

I need to call i2c_register_board_info for the new i2c style ad7414 driver. This needs to be called at arch initcall time. Currently I just do this:

static int __init warp_arch_init(void)

{
        i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
        return 0;
}

arch_initcall(warp_arch_init);

Quoted 6 lines
Quoted 2 lines

Yes, this is the right thing to do, but use machine_arch_initcall() instead so that it doesn't get called if it is not your board.

That being said, I believe there is infrastructure to handle the creation of your i2c board info from the device tree. Your i2c board info should not be hard coded.

Quoted 5 lines

Jon Smirl's patches? Not yet, unfortunately. It didn't make .25, but maybe for .26.

(I will need to do it specifically on my platform, like fsl_soc already does, as a stopgap until then).

That, and Sean is still working on getting the iic device-tree-compliant driver through as well :)

josh