Roger Quadros <ext-roger.quadros@xxxxxxxxx> writes:
> ext Tero.Kristo@xxxxxxxxx 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@xxxxxxxxxxxxxxx
>>> [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
