Hi Paul,
Paul Walmsley <paul@xxxxxxxxx> writes:
> On Fri, 30 Sep 2011, Abhilash K V wrote:
>
>> From: Abhilash K V <abhilash.kv@xxxxxx>
>>
>> If PMIC info is not available in omap_vp_init(), abort.
>>
>> Signed-off-by: Abhilash K V <abhilash.kv@xxxxxx>
>> ---
>> arch/arm/mach-omap2/vp.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
>> index 66bd700..0ed3d13 100644
>> --- a/arch/arm/mach-omap2/vp.c
>> +++ b/arch/arm/mach-omap2/vp.c
>> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
>> u32 val, sys_clk_rate, timeout, waittime;
>> u32 vddmin, vddmax, vstepmin, vstepmax;
>>
>> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
>> + pr_err("%s: PMIC info requried to configure VP for "
>> + "vdd_%s not populated.Hence cannot initialize VP\n",
>> + __func__, voltdm->name);
>> + return;
>> + }
>> +
>
> Just wondering about the intent of this patch. Is the goal here to not
> call omap_vp_init() for chips that don't have a VP IP block? If so, then
> implementing code that does that directly seems like a better approach
> than using the PMIC data? Because it seems likely that even SoCs without
> VP IP blocks will have PMICs on the board, right?
You're right, this isn't really relevant for this series since AM35x
doesn't have VP, and hence shouldn't even be calling omap_vp_init().
However, this does fix a bug on devices that do have VP where the VP is
initialized before PMIC info has been registered.
So, I'll queue this patch as a fix for the voltage layer, but it should
not have been included in the AM35x series.
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
