From: t-kristo@ti.com (Tero Kristo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
Date: Thu, 23 Feb 2012 11:08:53 +0200 [thread overview]
Message-ID: <1329988133.4102.500.camel@sokoban> (raw)
In-Reply-To: <CAOMWX4d+M9oagDtmSqG=X8Ln4kUEyLaqpfB9Pz0Y+6RmK=sjYw@mail.gmail.com>
On Wed, 2012-02-22 at 19:37 -0600, Menon, Nishanth wrote:
> On Tue, Feb 21, 2012 at 08:04, Tero Kristo <t-kristo@ti.com> wrote:
> [...]
> > diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
> > index 949938d..940a0d6 100644
> > --- a/arch/arm/mach-omap2/voltage.h
> > +++ b/arch/arm/mach-omap2/voltage.h
>
> [...]
> > @@ -171,6 +169,18 @@ struct omap_voltdm_pmic {
> > u8 (*uv_to_vsel) (unsigned long uV);
> > };
> >
> > +struct omap_vp_param {
> > + u32 vddmax;
> > + u32 vddmin;
> > +};
> > +
>
> Thinking a little deeper about this(SoC level vdd min and max) on a
> slightly different angle- core of the question that intend to answer
> are:
> - what is the least voltage we want to allow in active transtion? it
> should not be lower than retention voltage.
I think this is a fair assumption, so we could init the vddmin to be the
same as the retention voltage for the domain (or even drop the
parameter.)
> - what is the max voltage we want to allow in active transition? it
> should be the max Nom voltage of all the OPPs for that domain.
Isn't it higher? I guess smartreflex can scale voltages even up from the
nominal level if we have a really old and/or bad silicon. Limiting this
to max opp would be bad, no? Maybe we could use max opp voltage + some
margin though... but what would be a safe margin here?
>
> In effect, why do we even need to register
> "voltdm->vp_param->vdd[min|max]"? We already have that info - right?
> On the other hand it might be safer to do this way to handle quirks in
> future SoCs.. but thought I'd spit it out anyways..
>
> > +struct omap_vc_param {
> and elsewhere - please add kernel-doc struct documentation as well
> when new structs are introduced?
Yea, I can add those for next version.
> > + u32 on;
> > + u32 onlp;
> > + u32 ret;
> > + u32 off;
> > +};
> > +
> [...]
>
> Regards,
> Nishanth Menon
next prev parent reply other threads:[~2012-02-23 9:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-21 14:04 [PATCHv5 00/14] arm: omap3: auto-ret / auto-off support Tero Kristo
2012-02-21 14:04 ` [PATCHv5 01/14] arm: OMAP3+: PM: VP: use uV for max and min voltage limits Tero Kristo
2012-02-21 14:04 ` [PATCHv5 02/14] arm: omap: voltage: renamed vp_vddmin and vp_vddmax fields Tero Kristo
2012-02-21 14:40 ` Menon, Nishanth
2012-02-21 14:53 ` Russell King - ARM Linux
2012-02-21 15:32 ` Tero Kristo
2012-02-21 15:38 ` Nishanth Menon
2012-02-21 14:04 ` [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation Tero Kristo
2012-02-23 1:37 ` Menon, Nishanth
2012-02-23 9:08 ` Tero Kristo [this message]
2012-02-23 15:05 ` Menon, Nishanth
2012-02-21 14:04 ` [PATCHv5 04/14] arm: omap: voltage: add definition for pmic startup / shutdown times Tero Kristo
2012-02-21 14:04 ` [PATCHv5 05/14] arm: omap4: add " Tero Kristo
2012-02-21 14:04 ` [PATCHv5 06/14] arm: omap: add support for oscillator setup Tero Kristo
2012-02-21 14:44 ` Menon, Nishanth
2012-02-21 14:04 ` [PATCHv5 07/14] arm: omap3+: vp: use new vp_params for calculating vddmin and vddmax Tero Kristo
2012-02-21 14:04 ` [PATCHv5 08/14] arm: omap3+: voltage: use oscillator data to calculate setup times Tero Kristo
2012-02-21 14:04 ` [PATCHv5 09/14] arm: omap4: use pmic params for calculating pmic " Tero Kristo
2012-02-21 14:04 ` [PATCHv5 10/14] TEMP: arm: OMAP3: beagle rev-c4: enable OPP6 Tero Kristo
2012-02-21 14:04 ` [PATCHv5 11/14] arm: omap: beagle: set oscillator startup time to 10ms for rev c4 Tero Kristo
2012-02-21 14:04 ` [PATCHv5 12/14] arm: omap3: vc: auto_ret / auto_off support Tero Kristo
2012-02-21 14:04 ` [PATCHv5 13/14] arm: omap3: voltage: fix channel configuration Tero Kristo
2012-02-21 14:04 ` [PATCHv5 14/14] arm: omap: pm: wait for domain wakeup if changing state of idle domain Tero Kristo
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=1329988133.4102.500.camel@sokoban \
--to=t-kristo@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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