Hi Paul, Paul Walmsley <[email protected]> writes:
> On Fri, 30 Sep 2011, Abhilash K V wrote: > >> From: Abhilash K V <[email protected]> >> >> If PMIC info is not available in omap_vp_init(), abort. >> >> Signed-off-by: Abhilash K V <[email protected]> >> --- >> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
