From: Kevin Hilman <khilman@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Abhilash K V <abhilash.kv@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, tony@atomide.com,
linux@arm.linux.org.uk, b-cousson@ti.com, aneesh@ti.com,
santosh.shilimkar@ti.com, christian.gmeiner@gmail.com
Subject: Re: [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
Date: Fri, 30 Sep 2011 15:14:49 -0700 [thread overview]
Message-ID: <87ty7tfzja.fsf@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1109301240070.12185@utopia.booyaka.com> (Paul Walmsley's message of "Fri, 30 Sep 2011 12:41:44 -0600 (MDT)")
Hi Paul,
Paul Walmsley <paul@pwsan.com> writes:
> On Fri, 30 Sep 2011, Abhilash K V wrote:
>
>> From: Abhilash K V <abhilash.kv@ti.com>
>>
>> If PMIC info is not available in omap_vp_init(), abort.
>>
>> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
>> ---
>> 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
next prev parent reply other threads:[~2011-09-30 22:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 6:12 [PATCH v5 0/3] AM3517: Booting up Abhilash K V
2011-09-30 6:12 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Abhilash K V
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
2011-09-30 6:12 ` [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init Abhilash K V
2011-09-30 18:41 ` Paul Walmsley
2011-09-30 22:14 ` Kevin Hilman [this message]
2011-09-30 21:10 ` Kevin Hilman
2011-09-30 21:00 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Kevin Hilman
2011-09-30 23:27 ` Kevin Hilman
2011-10-11 7:59 ` Koyamangalath, Abhilash
2011-10-11 17:40 ` Kevin Hilman
2011-09-30 8:17 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Paul Walmsley
2011-10-07 9:12 ` Paul Walmsley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ty7tfzja.fsf@ti.com \
--to=khilman@ti.com \
--cc=abhilash.kv@ti.com \
--cc=aneesh@ti.com \
--cc=b-cousson@ti.com \
--cc=christian.gmeiner@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paul@pwsan.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox