RE: Smart Reflex pm patches causes a kernel panic

RE: Smart Reflex pm patches causes a kernel panic

[Tero.Kristo]

Hi Elvis,

I think I saw something similar last week, and it was caused by not having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in sr_configure_vp():

                vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
                        PRM_VP1_CONFIG_ERRORGAIN |
                        PRM_VP1_CONFIG_TIMEOUTEN |
>>>                        mpu_opps[resource_get_level("vdd1_opp")].vsel <<
                        OMAP3430_INITVOLTAGE_SHIFT; 

SR2 has similar code a bit later.

You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at all in your board files, this null pointer exception would actually indicate a problem like that more likely.

-Tero

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org 
>[mailto:linux-omap-owner@vger.kernel.org] On Behalf Of ext Elvis Dowson
>Sent: 19 May, 2009 14:21
>To: Kevin Hilman
>Cc: Linux OMAP Users
>Subject: Smart Reflex pm patches causes a kernel panic
>
>Hi Kevin,
>		  I get a kernel panic on my TI OMAP 3503 when 
>I incorporate the SR patches. How can I trace and debug this 
>to find the cause of this null pointer error ?
>
>Power Management for TI OMAP3.
>mmc0: mmc_rescan - card ocr from io_op=0x00000000, err = -110
>pm_dbg_init()
>Unable to handle kernel NULL pointer dereference at virtual 
>address 0000001e pgd = c0004000 [0000001e] *pgd=00000000 
>Internal error: Oops: 5 [#1] PREEMPT Modules linked in:
>CPU: 0    Not tainted  (2.6.29-omap1 #1)
>PC is at sr_configure_vp+0x28/0x1bc
>LR is at sr_configure_vp+0x1c/0x1bc
>pc : [<c01055f4>]    lr : [<c01055e8>]    psr: 60000113
>sp : cf81ff28  ip : cf81ff28  fp : cf81ff3c
>r10: 00000000  r9 : 00000000  r8 : 00000001
>r7 : c0012b44  r6 : 00000000  r5 : c05c8660  r4 : c05c8624
>r3 : 00000000  r2 : 00000001  r1 : 80000113  r0 : 00000000
>Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>Control: 10c5387d  Table: 80004019  DAC: 00000017 Process 
>swapper (pid: 1, stack limit = 0xcf81e2e8)
>Stack: (0xcf81ff28 to 0xcf820000)
>ff20:                   c05c8660 c05c8624 cf81ff5c cf81ff40 c0012bc8  
>c01055d8
>ff40: 00000000 08012954 c002d9d0 c002da20 cf81ffd4 cf81ff60 
>c00f52f8 c0012b50
>ff60: cf81ff8c cf81ff70 c01cb9e4 c01cb6a8 cf81ff00 cf9a26e0 c01cbae4
>cf81ff96
>ff80: cf81ffbc cf81ff90 c014d408 c01cb970 c02fb2b4 35339600 
>00000031 00000000
>ffa0: 00000192 c05d2034 00000000 00000000 cf81ffd4 c002d9d0 
>c002da20 00000000
>ffc0: 00000000 00000000 cf81fff4 cf81ffd8 c00083fc c00f52ac 00000000
>00000001
>ffe0: 00000000 00000000 00000000 cf81fff8 c011e2b8 c0008384 
>0836d404 5777f140
>Backtrace:
>[<c01055cc>] (sr_configure_vp+0x0/0x1bc) from [<c0012bc8>]
>(omap3_sr_init+0x84/0x114)
>  r4:c05c8624
>[<c0012b44>] (omap3_sr_init+0x0/0x114) from [<c00f52f8>]
>(do_one_initcall+0x58/0x198)
>  r5:c002da20 r4:c002d9d0
>[<c00f52a0>] (do_one_initcall+0x0/0x198) from [<c00083fc>] 
>(kernel_init 
>+0x84/0xf4)
>  r8:00000000 r7:00000000 r6:00000000 r5:c002da20 r4:c002d9d0 
>[<c0008378>] (kernel_init+0x0/0xf4) from [<c011e2b8>] (do_exit 
>+0x0/0x7d0)
>  r5:00000000 r4:00000000
>Code: eb0024a7 e59f3180 e3500000 05933000 (01d301be) ---[ end 
>trace eadc9c7cb4a7e9eb ]--- Kernel panic - not syncing: 
>Attempted to kill init!
>
>
>I have extracted the pm patches by doing a
>
>git format-patch master
>
>on the pm branch. This generates 186 patch files, as of today.
>
>Since I don't know which particular patch is causing the 
>problem, I need to fully exclude the following patch numbers 
>to prevent the kernel panic.
>
>#           
>file://omap-pm/0149-OMAP3-SR-Fix-init-voltage-on-OPP-change.patch 
>;patch=1 \
>#           
>file://omap-pm/0151-OMAP3-SR-Update-VDD1-2-voltages-at-boot.patch 
>;patch=1 \
>#           
>file://omap-pm/0152-OMAP3-SR-Use-sysclk-for-SR-CLKLENGTH-calc.patch 
>;patch=1 \
>#           
>file://omap-pm/0153-OMAP3-SR-Disable-SR-autocomp-only-for-CORE-
>trans.patch 
>;patch=1 \
>#           
>file://omap-pm/0154-OMAP3-SR-Reset-voltage-level-on-SR-disable.patch 
>;patch=1 \
>#           
>file://omap-pm/0155-OMAP3-SR-Replace-printk-s-with-pr_-calls.patch 
>;patch=1 \
>#           file://omap-pm/0156-OMAP3-SR-Remove-redundant- 
>defines.patch;patch=1 \
>#           
>file://omap-pm/0157-OMAP3-SR-Replace-SR_PASS-FAIL-SR_TRUE-FALSE.patch 
>;patch=1 \
>#           file://omap-pm/0158-OMAP3-SR-Replace-0x1-n-with-BIT- 
>n.patch;patch=1 \
>#           
>file://omap-pm/0159-OMAP3-clock-Remove-virt_vdd1-2_prcm_set.patch 
>;patch=1 \
>
>The following patches (from 167 to 186) are more recent, and 
>no necessary to reproduce the crash above:
>
>#           
>file://omap-pm/0168-OMAP3-SR-Fix-SR-driver-to-check-for-omap-pm
>-return.patch 
>;patch=1 \
>#           
>file://omap-pm/0169-OMAP3-PM-Don-t-do-unnecessary-searches-in-o
>map_sr_.patch 
>;patch=1 \
>#           
>file://omap-pm/0181-OMAP-PM-SmartReflex-has-build-dependency-on
>-OMAP-P.patch 
>;patch=1 \
>#           
>file://omap-pm/0186-OMAP3-PM-Fix-Smartreflex-when-used-with-PM_
>NOOP-la.patch 
>;patch=1 \
>
>Excluding the SR patches gives me a workable kernel that 
>doesn't crash on startup.
>
>Best regards,
>
>Elvis
>--
>To unsubscribe from this list: send the line "unsubscribe 
>linux-omap" in the body of a message to 
>majordomo@vger.kernel.org More majordomo info at  
>http://vger.kernel.org/majordomo-info.html
>

Re: Smart Reflex pm patches causes a kernel panic

[Roger Quadros]

ext Tero.Kristo@nokia.com wrote:
> Hi Elvis,
> 
> I think I saw something similar last week, and it was caused by not having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in sr_configure_vp():
> 
>                 vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
>                         PRM_VP1_CONFIG_ERRORGAIN |
>                         PRM_VP1_CONFIG_TIMEOUTEN |
>>>>                        mpu_opps[resource_get_level("vdd1_opp")].vsel <<
>                         OMAP3430_INITVOLTAGE_SHIFT; 
> 
> SR2 has similar code a bit later.
> 
> You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at all in your board files, this null pointer exception would actually indicate a problem like that more likely.
> 
> -Tero
> 
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org 
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of ext Elvis Dowson
>> Sent: 19 May, 2009 14:21
>> To: Kevin Hilman
>> Cc: Linux OMAP Users
>> Subject: Smart Reflex pm patches causes a kernel panic
>>
>> Hi Kevin,
>> 		  I get a kernel panic on my TI OMAP 3503 when 
>> I incorporate the SR patches. How can I trace and debug this 
>> to find the cause of this null pointer error ?
>>
>> Power Management for TI OMAP3.
>> mmc0: mmc_rescan - card ocr from io_op=0x00000000, err = -110
>> pm_dbg_init()
>> Unable to handle kernel NULL pointer dereference at virtual 
>> address 0000001e pgd = c0004000 [0000001e] *pgd=00000000 
>> Internal error: Oops: 5 [#1] PREEMPT Modules linked in:
>> CPU: 0    Not tainted  (2.6.29-omap1 #1)
>> PC is at sr_configure_vp+0x28/0x1bc
>> LR is at sr_configure_vp+0x1c/0x1bc
>> pc : [<c01055f4>]    lr : [<c01055e8>]    psr: 60000113
>> sp : cf81ff28  ip : cf81ff28  fp : cf81ff3c
>> r10: 00000000  r9 : 00000000  r8 : 00000001
>> r7 : c0012b44  r6 : 00000000  r5 : c05c8660  r4 : c05c8624
>> r3 : 00000000  r2 : 00000001  r1 : 80000113  r0 : 00000000
>> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>> Control: 10c5387d  Table: 80004019  DAC: 00000017 Process 
>> swapper (pid: 1, stack limit = 0xcf81e2e8)
>> Stack: (0xcf81ff28 to 0xcf820000)
>> ff20:                   c05c8660 c05c8624 cf81ff5c cf81ff40 c0012bc8  
>> c01055d8
>> ff40: 00000000 08012954 c002d9d0 c002da20 cf81ffd4 cf81ff60 
>> c00f52f8 c0012b50
>> ff60: cf81ff8c cf81ff70 c01cb9e4 c01cb6a8 cf81ff00 cf9a26e0 c01cbae4
>> cf81ff96
>> ff80: cf81ffbc cf81ff90 c014d408 c01cb970 c02fb2b4 35339600 
>> 00000031 00000000
>> ffa0: 00000192 c05d2034 00000000 00000000 cf81ffd4 c002d9d0 
>> c002da20 00000000
>> ffc0: 00000000 00000000 cf81fff4 cf81ffd8 c00083fc c00f52ac 00000000
>> 00000001
>> ffe0: 00000000 00000000 00000000 cf81fff8 c011e2b8 c0008384 
>> 0836d404 5777f140
>> Backtrace:
>> [<c01055cc>] (sr_configure_vp+0x0/0x1bc) from [<c0012bc8>]
>> (omap3_sr_init+0x84/0x114)
>>  r4:c05c8624
>> [<c0012b44>] (omap3_sr_init+0x0/0x114) from [<c00f52f8>]
>> (do_one_initcall+0x58/0x198)
>>  r5:c002da20 r4:c002d9d0
>> [<c00f52a0>] (do_one_initcall+0x0/0x198) from [<c00083fc>] 
>> (kernel_init 
>> +0x84/0xf4)
>>  r8:00000000 r7:00000000 r6:00000000 r5:c002da20 r4:c002d9d0 
>> [<c0008378>] (kernel_init+0x0/0xf4) from [<c011e2b8>] (do_exit 
>> +0x0/0x7d0)
>>  r5:00000000 r4:00000000
>> Code: eb0024a7 e59f3180 e3500000 05933000 (01d301be) ---[ end 
>> trace eadc9c7cb4a7e9eb ]--- Kernel panic - not syncing: 
>> Attempted to kill init!
>>
>>
>> I have extracted the pm patches by doing a
>>
>> git format-patch master
>>
>> on the pm branch. This generates 186 patch files, as of today.
>>
>> Since I don't know which particular patch is causing the 
>> problem, I need to fully exclude the following patch numbers 
>> to prevent the kernel panic.
>>
>> #           
>> file://omap-pm/0149-OMAP3-SR-Fix-init-voltage-on-OPP-change.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0151-OMAP3-SR-Update-VDD1-2-voltages-at-boot.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0152-OMAP3-SR-Use-sysclk-for-SR-CLKLENGTH-calc.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0153-OMAP3-SR-Disable-SR-autocomp-only-for-CORE-
>> trans.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0154-OMAP3-SR-Reset-voltage-level-on-SR-disable.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0155-OMAP3-SR-Replace-printk-s-with-pr_-calls.patch 
>> ;patch=1 \
>> #           file://omap-pm/0156-OMAP3-SR-Remove-redundant- 
>> defines.patch;patch=1 \
>> #           
>> file://omap-pm/0157-OMAP3-SR-Replace-SR_PASS-FAIL-SR_TRUE-FALSE.patch 
>> ;patch=1 \
>> #           file://omap-pm/0158-OMAP3-SR-Replace-0x1-n-with-BIT- 
>> n.patch;patch=1 \
>> #           
>> file://omap-pm/0159-OMAP3-clock-Remove-virt_vdd1-2_prcm_set.patch 
>> ;patch=1 \
>>
>> The following patches (from 167 to 186) are more recent, and 
>> no necessary to reproduce the crash above:
>>
>> #           
>> file://omap-pm/0168-OMAP3-SR-Fix-SR-driver-to-check-for-omap-pm
>> -return.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0169-OMAP3-PM-Don-t-do-unnecessary-searches-in-o
>> map_sr_.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0181-OMAP-PM-SmartReflex-has-build-dependency-on
>> -OMAP-P.patch 
>> ;patch=1 \
>> #           
>> file://omap-pm/0186-OMAP3-PM-Fix-Smartreflex-when-used-with-PM_
>> NOOP-la.patch 
>> ;patch=1 \
>>
>> Excluding the SR patches gives me a workable kernel that 
>> doesn't crash on startup.
>>
>> Best regards,
>>
>> Elvis
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-omap" in the body of a message to 
>> majordomo@vger.kernel.org More majordomo info at  
>> http://vger.kernel.org/majordomo-info.html
>> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Elvis,

Currently Smartreflex (SR) is dependent on SRF to get OPP levels. Just make sure 
you select CONFIG_OMAP_PM_SRF when using SR. OR you can disable Smartreflex till 
this issue is fixed.

I am working on a patch that will make Smartreflex independent of SRF. I will 
post this soon.

cheers,
Roger.

Re: Smart Reflex pm patches causes a kernel panic

[Roger Quadros]

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

ext Elvis Dowson wrote:
> Thanks for the info, Roger! I'll wait for that patch!
> 
> Elvis
> 
>>
>> Currently Smartreflex (SR) is dependent on SRF to get OPP levels. Just 
>> make sure you select CONFIG_OMAP_PM_SRF when using SR. OR you can 
>> disable Smartreflex till this issue is fixed.
>>
>> I am working on a patch that will make Smartreflex independent of SRF. 
>> I will post this soon.
> 

Elvis,

Can you please try and verify if the problem goes away with the attached patch.
Thanks.

-roger

[-- Attachment #2: 0001-OMAP3-PM-Make-Smartreflex-driver-independent-of-SR.patch --]
[-- Type: text/x-patch, Size: 4671 bytes --]

From: Roger Quadros <ext-roger.quadros@nokia.com>
Date: Tue, 19 May 2009 14:15:56 +0300
Subject: [PATCH] OMAP3: PM: Make Smartreflex driver independent of SRF

This removes Smartreflex driver's dependency on SRF layer to get
OPPs for VDD1 and VDD2. Now Smartreflex is usable irrespective of the
underlying PM layer.

Signed-off-by: Roger Quadros <ext-roger.quadros@nokia.com>
---
 arch/arm/mach-omap2/smartreflex.c |   74 ++++++++++++++++++++++++++++++++-----
 1 files changed, 64 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index b032366..b66d237 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -143,6 +143,57 @@ static u32 cal_test_nvalue(u32 sennval, u32 senpval)
 		(rnsenn << NVALUERECIPROCAL_RNSENN_SHIFT));
 }
 
+/* determine the current OPP from the frequency
+ * we need to give this function last element of OPP rate table
+ * and the frequency
+ */
+static u16 get_opp(struct omap_opp *opp_freq_table,
+					unsigned long freq)
+{
+	struct omap_opp *prcm_config;
+
+	prcm_config = opp_freq_table;
+
+	if (prcm_config->rate <= freq)
+		return prcm_config->opp_id; /* Return the Highest OPP */
+	for (; prcm_config->rate; prcm_config--)
+		if (prcm_config->rate < freq)
+			return (prcm_config+1)->opp_id;
+		else if (prcm_config->rate == freq)
+			return prcm_config->opp_id;
+	/* Return the least OPP */
+	return (prcm_config+1)->opp_id;
+}
+
+static u16 get_vdd1_opp(void)
+{
+	u16 opp;
+	struct clk *clk;
+
+	clk = clk_get(NULL, "dpll1_ck");
+
+	if (clk == NULL || IS_ERR(clk) || mpu_opps == NULL)
+		return 0;
+
+	opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk->rate);
+	return opp;
+}
+
+static u16 get_vdd2_opp(void)
+{
+	u16 opp;
+	struct clk *clk;
+
+	clk = clk_get(NULL, "dpll3_m2_ck");
+
+	if (clk == NULL || IS_ERR(clk) || l3_opps == NULL)
+		return 0;
+
+	opp = get_opp(l3_opps + MAX_VDD2_OPP, clk->rate);
+	return opp;
+}
+
+
 static void sr_set_clk_length(struct omap_sr *sr)
 {
 	struct clk *sys_ck;
@@ -248,13 +299,15 @@ static void sr_configure_vp(int srid)
 {
 	u32 vpconfig;
 	u32 vsel;
+	u32 target_opp_no;
 
 	if (srid == SR1) {
-		if (!omap_pm_vdd1_get_opp())
+		target_opp_no = get_vdd1_opp();
+		if (!target_opp_no)
 			/* Assume Nominal OPP as current OPP unknown */
 			vsel = mpu_opps[VDD1_OPP3].vsel;
 		else
-			vsel = mpu_opps[omap_pm_vdd1_get_opp()].vsel;
+			vsel = mpu_opps[target_opp_no].vsel;
 
 		vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
 			PRM_VP1_CONFIG_ERRORGAIN |
@@ -295,11 +348,12 @@ static void sr_configure_vp(int srid)
 				       OMAP3_PRM_VP1_CONFIG_OFFSET);
 
 	} else if (srid == SR2) {
-		if (!omap_pm_vdd2_get_opp())
+		target_opp_no = get_vdd2_opp();
+		if (!target_opp_no)
 			/* Assume Nominal OPP */
 			vsel = l3_opps[VDD2_OPP3].vsel;
 		else
-			vsel = l3_opps[omap_pm_vdd2_get_opp()].vsel;
+			vsel = l3_opps[target_opp_no].vsel;
 
 		vpconfig = PRM_VP2_CONFIG_ERROROFFSET |
 			PRM_VP2_CONFIG_ERRORGAIN |
@@ -397,7 +451,7 @@ static int sr_reset_voltage(int srid)
 	u32 vc_bypass_value;
 
 	if (srid == SR1) {
-		target_opp_no = omap_pm_vdd1_get_opp();
+		target_opp_no = get_vdd1_opp();
 		if (!target_opp_no) {
 			pr_info("Current OPP unknown: Cannot reset voltage\n");
 			return 1;
@@ -405,7 +459,7 @@ static int sr_reset_voltage(int srid)
 		vsel = mpu_opps[target_opp_no].vsel;
 		reg_addr = R_VDD1_SR_CONTROL;
 	} else if (srid == SR2) {
-		target_opp_no = omap_pm_vdd2_get_opp();
+		target_opp_no = get_vdd2_opp();
 		if (!target_opp_no) {
 			pr_info("Current OPP unknown: Cannot reset voltage\n");
 			return 1;
@@ -641,9 +695,9 @@ void enable_smartreflex(int srid)
 			sr_clk_enable(sr);
 
 			if (srid == SR1)
-				target_opp_no = omap_pm_vdd1_get_opp();
+				target_opp_no = get_vdd1_opp();
 			else if (srid == SR2)
-				target_opp_no = omap_pm_vdd2_get_opp();
+				target_opp_no = get_vdd2_opp();
 
 			if (!target_opp_no) {
 				pr_info("Current OPP unknown \
@@ -786,7 +840,7 @@ static ssize_t omap_sr_vdd1_autocomp_store(struct kobject *kobj,
 	if (value == 0) {
 		sr_stop_vddautocomap(SR1);
 	} else {
-		u32 current_vdd1opp_no = omap_pm_vdd1_get_opp();
+		u32 current_vdd1opp_no = get_vdd1_opp();
 		if (!current_vdd1opp_no) {
 			pr_err("sr_vdd1_autocomp: Current VDD1 opp unknown\n");
 			return -EINVAL;
@@ -826,7 +880,7 @@ static ssize_t omap_sr_vdd2_autocomp_store(struct kobject *kobj,
 	if (value == 0) {
 		sr_stop_vddautocomap(SR2);
 	} else {
-		u32 current_vdd2opp_no = omap_pm_vdd2_get_opp();
+		u32 current_vdd2opp_no = get_vdd2_opp();
 		if (!current_vdd2opp_no) {
 			pr_err("sr_vdd2_autocomp: Current VDD2 opp unknown\n");
 			return -EINVAL;
-- 
1.6.0.4

Re: Smart Reflex pm patches causes a kernel panic

[Roger Quadros]

ext Elvis Dowson wrote:
> Hi Roger,
>             I'll try it right away.
> 
> Elvis
> 
> On May 19, 2009, at 4:04 PM, Roger Quadros wrote:
> 
>>>>
>>
>> Elvis,
>>
>> Can you please try and verify if the problem goes away with the 
>> attached patch.
>> Thanks.
>>

My earlier patch will not work for you since smartreflex driver is still 
referencing mpu_opps without checking.

You will have to use this in your board init file

omap2_init_common_hw(NULL, omap3_mpu_rate_table,
                              omap3_dsp_rate_table, omap3_l3_rate_table);

The first parameter is SDRAM timings, you can figure out and pass something 
saner instead of NULL. e.g. mt46h32m32lf6_sdrc_params.

-roger

Re: Smart Reflex pm patches causes a kernel panic

[Koen Kooi]

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


Op 19 mei 2009, om 19:50 heeft Elvis Dowson het volgende geschreven:

> I guess the answer is all three.

This works for me: http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/recipes/linux/linux-omap-pm/overo-cpufreq.diff

regards,

Koen

[-- Attachment #2: Dit deel van het bericht is digitaal ondertekend --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: Smart Reflex pm patches causes a kernel panic

[Kevin Hilman]

Roger Quadros <ext-roger.quadros@nokia.com> writes:

> ext Tero.Kristo@nokia.com wrote:
>> Hi Elvis,
>>
>> I think I saw something similar last week, and it was caused by not having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in sr_configure_vp():
>>
>>                 vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
>>                         PRM_VP1_CONFIG_ERRORGAIN |
>>                         PRM_VP1_CONFIG_TIMEOUTEN |
>>>>>                        mpu_opps[resource_get_level("vdd1_opp")].vsel <<
>>                         OMAP3430_INITVOLTAGE_SHIFT; 
>>
>> SR2 has similar code a bit later.
>>
>> You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at all in your board files, this null pointer exception would actually indicate a problem like that more likely.
>>
>> -Tero
>>
>>> -----Original Message-----
>>> From: linux-omap-owner@vger.kernel.org
>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of ext Elvis
>>> Dowson
>>> Sent: 19 May, 2009 14:21
>>> To: Kevin Hilman
>>> Cc: Linux OMAP Users
>>> Subject: Smart Reflex pm patches causes a kernel panic
>>>
>>> Hi Kevin,
>>> 		  I get a kernel panic on my TI OMAP 3503 when I
>>> incorporate the SR patches. How can I trace and debug this to find
>>> the cause of this null pointer error ?
>>>

[...]

>
> Elvis,
>
> Currently Smartreflex (SR) is dependent on SRF to get OPP levels. Just
> make sure you select CONFIG_OMAP_PM_SRF when using SR. OR you can
> disable Smartreflex till this issue is fixed.
>
> I am working on a patch that will make Smartreflex independent of
> SRF. I will post this soon.
>

Elvis,

Where are you getting the PM branch?  By this problem I'm pretty sure
you're not using the current published PM branch.  Since there are
some fixes in place.

The current PM branch has a Kconfig patch that makes SR dependent on SRF
so you should not see this problem.

Kevin

RE: Smart Reflex pm patches causes a kernel panic

[Tero.Kristo]

 

>-----Original Message-----
>From: ext Elvis Dowson [mailto:elvis.dowson@mac.com] 
>Sent: 19 May, 2009 14:49
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: Linux OMAP Users
>Subject: Re: Smart Reflex pm patches causes a kernel panic
>
>Hi Tero,
>		Thanks for the reply. I'll try this out. I 
>don't think mpu_opps is defined for my board_overo.c file. I 
>guess I should look at the board_sdp3430.c as an example for this?

Yes, take a look at it. You are basically missing some parameters in a call to omap2_init_common_hw(), at least the version I am looking at here has a few NULL pointers passed. The rate tables (mpu + l3) should be posted as parameters in that.

-Tero

>
>Thanks and do let me know!
>
>Best regards,
>
>Elvis
>
>
>On May 19, 2009, at 3:41 PM, Tero.Kristo@nokia.com wrote:
>
>> Hi Elvis,
>>
>> I think I saw something similar last week, and it was caused by not 
>> having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked 
>> line in sr_configure_vp():
>>
>>                vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
>>                        PRM_VP1_CONFIG_ERRORGAIN |
>>                        PRM_VP1_CONFIG_TIMEOUTEN |
>>>>>                        
>>>>> mpu_opps[resource_get_level("vdd1_opp")].vsel <<
>>                        OMAP3430_INITVOLTAGE_SHIFT;
>>
>> SR2 has similar code a bit later.
>>
>> You will also get a failure if mpu_opps[] and/or l3_opps[] is not 
>> defined at all in your board files, this null pointer 
>exception would 
>> actually indicate a problem like that more likely.
>
>