From: Doug Anderson <dianders@chromium.org>
To: Mark Brown <broonie@kernel.org>
Cc: Alexandru Stan <amstan@chromium.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
Jaehoon Chung <jh80.chung@samsung.com>,
Seungwon Jeon <tgih.jun@samsung.com>,
Alim Akhtar <alim.akhtar@samsung.com>,
Sonny Rao <sonnyrao@chromium.org>,
Andrew Bresticker <abrestic@chromium.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Liam Girdwood <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] regulator: core: Support trying to get close to a certain voltage
Date: Thu, 11 Dec 2014 19:31:43 -0800 [thread overview]
Message-ID: <CAD=FV=W1r2MXNHXTRiO1pBPWurvgqq+dSoOPgpSJ_zAbpU7T4Q@mail.gmail.com> (raw)
In-Reply-To: <20141212002410.GB11764@sirena.org.uk>
Mark,
On Thu, Dec 11, 2014 at 4:24 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Dec 11, 2014 at 11:55:55AM -0800, Doug Anderson wrote:
>> On Thu, Dec 11, 2014 at 9:09 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Please also bear in mind the need to handle shared supplies in your
>> > implementation.
>
>> I'm being dense, can you give more details? Do you want me to grab
>> the mutex or do something smarter like track the voltage / tolerance
>> requested by multiple clients and resolve them, or ...?
>
> I mean the latter - what happens if more than one consumer is trying to
> use the regulator? This is IIRC why _set_voltage_tol() uses the cheap
> and nasty implementation it does.
Ah, I see. I don't think I've ever encountered a case where there
were two consumers for a regulator that actually requested voltages...
...but isn't regulator_set_voltage_tol() broken there? If you have
two clients, A and B and a regulator that can go 1.0V to 5.0V in .05V
increments:
A requests 1.8V +/- .1V. We get 1.8V
B requests 1.7V +/- .05V.
The above could be achievable with a voltage of 1.75V but it won't
work with the current regulator_set_voltage_tol() I think.
> There's also the potential
> performance considerations for the DVS type applications now I think
> about it.
Iterating through voltages is really that slow? If so, perhaps we
could add some caching to keep track of what voltage we actually got
last time... I could also add an optimization to try the exact
requested voltage right away...
-Doug
WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] regulator: core: Support trying to get close to a certain voltage
Date: Thu, 11 Dec 2014 19:31:43 -0800 [thread overview]
Message-ID: <CAD=FV=W1r2MXNHXTRiO1pBPWurvgqq+dSoOPgpSJ_zAbpU7T4Q@mail.gmail.com> (raw)
In-Reply-To: <20141212002410.GB11764@sirena.org.uk>
Mark,
On Thu, Dec 11, 2014 at 4:24 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Dec 11, 2014 at 11:55:55AM -0800, Doug Anderson wrote:
>> On Thu, Dec 11, 2014 at 9:09 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Please also bear in mind the need to handle shared supplies in your
>> > implementation.
>
>> I'm being dense, can you give more details? Do you want me to grab
>> the mutex or do something smarter like track the voltage / tolerance
>> requested by multiple clients and resolve them, or ...?
>
> I mean the latter - what happens if more than one consumer is trying to
> use the regulator? This is IIRC why _set_voltage_tol() uses the cheap
> and nasty implementation it does.
Ah, I see. I don't think I've ever encountered a case where there
were two consumers for a regulator that actually requested voltages...
...but isn't regulator_set_voltage_tol() broken there? If you have
two clients, A and B and a regulator that can go 1.0V to 5.0V in .05V
increments:
A requests 1.8V +/- .1V. We get 1.8V
B requests 1.7V +/- .05V.
The above could be achievable with a voltage of 1.75V but it won't
work with the current regulator_set_voltage_tol() I think.
> There's also the potential
> performance considerations for the DVS type applications now I think
> about it.
Iterating through voltages is really that slow? If so, perhaps we
could add some caching to keep track of what voltage we actually got
last time... I could also add an optimization to try the exact
requested voltage right away...
-Doug
next prev parent reply other threads:[~2014-12-12 3:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 20:58 [PATCH 1/4] regulator: core: Support trying to get close to a certain voltage Doug Anderson
2014-12-10 20:58 ` Doug Anderson
2014-12-10 20:58 ` [PATCH 2/4] mmc: core: Add mmc_regulator_set_vqmmc() Doug Anderson
2014-12-10 20:58 ` Doug Anderson
2014-12-10 20:58 ` [PATCH 3/4] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch Doug Anderson
2014-12-10 20:58 ` Doug Anderson
2014-12-10 20:58 ` [PATCH 4/4] ARK: dts: Specify VMMC and VQMMC on rk3288-evb Doug Anderson
2014-12-10 20:58 ` Doug Anderson
2014-12-10 20:58 ` Doug Anderson
2014-12-10 23:53 ` [PATCH 1/4] regulator: core: Support trying to get close to a certain voltage Mark Brown
2014-12-10 23:53 ` Mark Brown
2014-12-11 1:08 ` Alexandru Stan
2014-12-11 1:08 ` Alexandru Stan
2014-12-11 12:31 ` Mark Brown
2014-12-11 12:31 ` Mark Brown
2014-12-11 16:09 ` Doug Anderson
2014-12-11 16:09 ` Doug Anderson
2014-12-11 17:09 ` Mark Brown
2014-12-11 17:09 ` Mark Brown
2014-12-11 19:55 ` Doug Anderson
2014-12-11 19:55 ` Doug Anderson
2014-12-12 0:24 ` Mark Brown
2014-12-12 0:24 ` Mark Brown
2014-12-12 3:31 ` Doug Anderson [this message]
2014-12-12 3:31 ` Doug Anderson
2014-12-12 12:59 ` Mark Brown
2014-12-12 12:59 ` Mark Brown
2014-12-15 22:11 ` Doug Anderson
2014-12-15 22:11 ` Doug Anderson
2014-12-16 13:13 ` Mark Brown
2014-12-16 13:13 ` Mark Brown
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='CAD=FV=W1r2MXNHXTRiO1pBPWurvgqq+dSoOPgpSJ_zAbpU7T4Q@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=abrestic@chromium.org \
--cc=alim.akhtar@samsung.com \
--cc=amstan@chromium.org \
--cc=broonie@kernel.org \
--cc=heiko@sntech.de \
--cc=jh80.chung@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=sonnyrao@chromium.org \
--cc=tgih.jun@samsung.com \
--cc=ulf.hansson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.