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:11:03 +0200 [thread overview]
Message-ID: <1401109863.4829.46.camel@weser.hi.pengutronix.de> (raw)
In-Reply-To: <CAKohpo=ncHUmtJOEw4FZG1BWUSuiQK4n+ETEMJWJj9UoPz2cnw@mail.gmail.com>
Am Montag, den 26.05.2014, 18:26 +0530 schrieb Viresh Kumar:
> On 26 May 2014 18:05, Lucas Stach <l.stach@pengutronix.de> wrote:
[...]
>
> > 2. Usage of a fixed max voltage, rather than a voltage-tolerance. i.MX5
> > has a fixed maximum voltage, which is valid across all operating points.
> > I'm really opposed to using a tolerance value, where we instead could
> > have a well defined range. So for merging imx5-cpufreq into cpufreq-cpu0
> > this driver really need to handle this case.
> > Does adding a separate property for this, while keeping the
> > voltage-tolerance for the existing users, sound like a change you would
> > accept?
>
> It looks you can just send voltage-tolerance to "zero" and this should work
> for you.. No need of another field.
>
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.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2014-05-26 13:11 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 [this message]
2014-05-26 13:44 ` Viresh Kumar
2014-05-26 13:58 ` Lucas Stach
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=1401109863.4829.46.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).