From: l.stach@pengutronix.de (Lucas Stach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] cpufreq: add i.MX5 cpufreq driver
Date: Mon, 26 May 2014 15:58:17 +0200 [thread overview]
Message-ID: <1401112697.4829.56.camel@weser.hi.pengutronix.de> (raw)
In-Reply-To: <CAKohponzJma6yNueMef2Q4k+qT-n7boV0tx0pCqjFmuQWj6TXg@mail.gmail.com>
Am Montag, den 26.05.2014, 19:14 +0530 schrieb Viresh Kumar:
> On 26 May 2014 18:41, Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Just to mention that I am trying to help you and am not opposing any
> change. We can add this field if its really required and I am just trying
> to understand your problem and if we can solve it with current code.
>
I understand this and I think we are having a productive conversation
here. I just wanted to make it clear that the currently existing
voltage-tolerance property isn't sufficient for the use-cases I have in
mind.
> > No, setting voltage-tolerance to zero means I don't accept any tolerance
> > at all. Though in practice I have a variable tolerance as I just have a
> > fixed maximum voltage for the chip.
> >
> > For example the i.MX53 has a fixed maximum voltage of 1.4V on the cpu
> > rail, so for the slowest OPP the acceptable voltage range is 0.8V to
> > 1.4V, for the fastest OPP the range is 1.3V to 1.4V.
> >
> > So if someone connects a fixed 1.3V regulator, I want to still be able
> > to use all OPPs, even though the slowest OPP wants 0.8V ideally. If I
> > were to use a tolerance I would have to set is to some relatively strict
> > value, in order to not exceed the maximum voltage at the highest OPP,
> > but this would mean I could not use the slowest OPP because it's out of
> > the tolerance range.
>
> I understood the problem now. But I feel there is nothing imx specific here.
> It should be a general concern and I want to know how are people
> working around it currently.
>
I think the voltage-tolerance property is ok for SoCs where we have a
strictly defined voltage level for one OPP and where the tolerance is
used to account for the fact that most regulators can only closely, but
not exactly, match the OPP defined voltage.
> IOW can we say that you want tolerance to work only on the positive
> side? But no tolerance on the -ve side ?
>
Right, the OPP defined voltages are minimum voltages for the OPP
frequency, so we should not undercut them.
> Also, your example dts says that you do have different voltage levels
> for each frequency but actually the regulator may only support a
> single voltage. i.e. 1.4 volts.
>
Right, the OPP in my example define the minimum required voltage for
each frequency. This is in accordance to the OPP binding. But for this
chip the datasheet explicitly says that it is ok to power the cpu rail
with up to 1.4V, regardless of the current operating frequency. So this
1.4V is really the upper bound I would like to pass to the regulator
framework. This ensures that the driver still works properly even if the
external regulator can't scale down to the minimum (or in other words
optimal) voltage.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2014-05-26 13:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-26 10:15 [PATCH 1/4] clk: imx5: add step and cpu_podf mux Lucas Stach
2014-05-26 10:15 ` [PATCH 2/4] cpufreq: add i.MX5 cpufreq driver Lucas Stach
2014-05-26 10:32 ` Viresh Kumar
2014-05-26 10:45 ` Lucas Stach
2014-05-26 11:06 ` Viresh Kumar
2014-05-26 12:35 ` Lucas Stach
2014-05-26 12:56 ` Viresh Kumar
2014-05-26 13:11 ` Lucas Stach
2014-05-26 13:44 ` Viresh Kumar
2014-05-26 13:58 ` Lucas Stach [this message]
2014-05-26 15:22 ` Viresh Kumar
2014-05-26 15:28 ` Lucas Stach
2014-05-26 15:35 ` Viresh Kumar
2014-05-26 15:57 ` Lucas Stach
2014-05-26 16:22 ` Viresh Kumar
2014-05-26 10:15 ` [PATCH 3/4] ARM: imx53: instanciate cpufreq device Lucas Stach
2014-05-26 10:15 ` [PATCH 4/4] ARM: imx53: add basic cpufreq properties to dtsi Lucas Stach
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=1401112697.4829.56.camel@weser.hi.pengutronix.de \
--to=l.stach@pengutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).