Skip to contentSkip to conversation

OMAP: pm.c correct the initcall for an early init.

PATCH Superseded Thara Gopinath 2 participants 5 messages Dec 1, 2010 – Dec 15, 2010

Subsystems (4)
Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP power management support

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Thara Gopinath

author
#0 lore raw

PATCH 1/1 OMAP: pm.c correct the initcall for an early init.

omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation

Signed-off-by Thara Gopinath <[email protected]>
---
 arch/arm/mach-omap2/pm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/pm.c +1 -1
index 59ca03b..6ec2ee1 100644
@@ -143,5 +143,5 @@ static int __init omap2_common_pm_init(void)
 
 	return 0;
 }
-device_initcall(omap2_common_pm_init);
+postcore_initcall(omap2_common_pm_init);
Signature · 1 line
1.7.0.4
#1 lore raw
Quoted 6 lines · Thara Gopinath

omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation

Why postcore? there are several other inicalls earlier than device_initcall.

Also, does this actually work? Is the driver core initialized at postcore_initcall time such that omap_devices w/platform_device creation actually works?

Kevin

Quoted 15 lines
Signed-off-by Thara Gopinath <[email protected]>
---
 arch/arm/mach-omap2/pm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/pm.c +1 -1
index 59ca03b..6ec2ee1 100644
@@ -143,5 +143,5 @@ static int __init omap2_common_pm_init(void)
 
 	return 0;
 }
-device_initcall(omap2_common_pm_init);
+postcore_initcall(omap2_common_pm_init);
author
#2 lore raw
Quoted 18 lines
Quoted 18 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, December 02, 2010 7:03 PM
To: Gopinath, Thara
Cc: [email protected]
Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init.

Quoted 6 lines · Thara Gopinath

omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation

Quoted 2 lines
Quoted 2 lines

Why postcore? there are several other inicalls earlier than device_initcall.

Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their init, we will again have to bump up the init priority of this fn.
It is a good thing to do this early on in the boot cycle rather than later.

Quoted 4 lines
Quoted 4 lines

Also, does this actually work? Is the driver core initialized at postcore_initcall time such that omap_devices w/platform_device creation actually works?

Yes by post_initcall the omap_device initializations would have happened. In fact these initializations happen as core_initcall.

Quoted 18 lines
Quoted 18 lines

Kevin

Quoted 15 lines
Signed-off-by Thara Gopinath <[email protected]>
---
 arch/arm/mach-omap2/pm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/pm.c +1 -1
index 59ca03b..6ec2ee1 100644
@@ -143,5 +143,5 @@ static int __init omap2_common_pm_init(void)
 
 	return 0;
 }
-device_initcall(omap2_common_pm_init);
+postcore_initcall(omap2_common_pm_init);
#3 lore raw
Quoted 19 lines · Thara
Quoted 16 lines
Quoted 16 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, December 02, 2010 7:03 PM
To: Gopinath, Thara
Cc: [email protected]
Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init.

Quoted 6 lines · Thara Gopinath

omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation

Quoted 2 lines
Quoted 2 lines

Why postcore? there are several other inicalls earlier than device_initcall.

Quoted 6 lines

Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their init, we will again have to bump up the init priority of this fn.
It is a good thing to do this early on in the boot cycle rather than later.

OK, please describe this in more detail the changelog.

Thanks,

Kevin

author
#4 lore raw
Quoted 33 lines
Quoted 33 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, December 14, 2010 6:37 AM
To: Gopinath, Thara
Cc: [email protected]
Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init.

Quoted 22 lines · Thara
Quoted 16 lines
Quoted 16 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, December 02, 2010 7:03 PM
To: Gopinath, Thara
Cc: [email protected]
Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init.

Quoted 6 lines · Thara Gopinath

omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation

Quoted 2 lines
Quoted 2 lines

Why postcore? there are several other inicalls earlier than device_initcall.

Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their

Quoted 6 lines
Quoted 6 lines

init,

Quoted 3 lines

we will again have to bump up the init priority of this fn. It is a good thing to do this early on in the boot cycle rather than later.

OK, please describe this in more detail the changelog.

Ok Will repost

Regards
Thara