[maverick][PATCH] UBUNTU: SAUCE: Load SysLink modules on start-up on OMAP4 devices

Lee Jones lee.jones at canonical.com
Wed Jul 7 11:52:08 UTC 2010


Hi Nicolas,

Thank you for your comments.

>> >> +static struct platform_device omap4_syslink_device = {
>> >> +     .name          = "syslink_ipc",
>> >> +     .id            = -1,
>> >> +     .num_resources = 0,
>> >> +};
>> >>
>> >> +static struct platform_device *omap4_syslink_devices[] = {
>> >> +        &omap4_syslink_device,
>> >> +};
>> >> +
> > 
> > is it worth using an array of platform_device for just 1 device? At least the array should be marked as __initdata so that 
> > it does not take memory after init. However I would prefer not to use an array.
> > 

I thought by doing this way it would be easier if we were to add more devices at a later date.

I did have __initdata there. I took it out during debugging, as it was causing compile errors. I would be fine now though.

I have no preference either way - pick one and we'll run with it.

>> >> +module_init(omap4_syslink_init);
> > 
> > you aren't in a module here, this code is built-in in the kernel (and will always be). This is supposed to be called during 
> > platform init, not during do_initcall. Can we call this function from the machine init function instead of using this trick? (e.g. omap_4430sdp_init() and omap_panda_init())

Yes, this code is built-in, but it is part of the SysLink code, which is a module and is happy to be initiated at the same time.

Do: "grep -nHre module_init arch/*", and you'll see it is used many times within architecture specific code.

> > Can we call this function from the machine init function instead of using this trick? (e.g. omap_4430sdp_init() and omap_panda_init())

We can call the function from each machine, but it will need to be added to every OMAP4 machine that you release.

There are other *_initcalls available if you'd rather change it - some will work, some won't:

early_initcall    - kills the kernel (I think this is done before the platform code is initiated)
core_initcall     - not tried
postcore_initcall - not tried
arch_initcall     - not tried
subsys_initcall   - not tried
fs_initcall       - not tried
rootfs_initcall   - not tried
device_initcall   - not tried
late_initcall     - not tried

If anyone else has any better ideas (or knows the _correct_ solution), feel free to chirp in.

Kind regards,
Lee




More information about the kernel-team mailing list