[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191008120611.GG4382@sirena.co.uk>
Date: Tue, 8 Oct 2019 13:06:11 +0100
From: Mark Brown <broonie@...nel.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: linux-kernel@...r.kernel.org, Dmitry Osipenko <digetx@...il.com>,
Liam Girdwood <lgirdwood@...il.com>,
Lucas Stach <l.stach@...gutronix.de>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH] regulator: core: Skip balancing of the enabled
regulators in regulator_enable()
On Tue, Oct 08, 2019 at 02:01:15PM +0200, Marek Szyprowski wrote:
> On 08.10.2019 13:50, Mark Brown wrote:
> > This then means that for users that might legitimately enable and
> > disable regulators that need to be constrained are forced to change the
> > voltage when they enable the regualtors in order to have their
> > constraints take effect which seems bad. I'd rather change the the
> > cpufreq consumers to either not do the enable (since there really should
> > be an always-on constraint this should be redundant, we might need to
> > fix the core to take account of their settings though I think we lost
> > that) or to set the voltage to whatever they need prior to doing their
> > first enable, that seems more robust.
> Well, I'm open for other ways of fixing this issue. Calling enable on
> always-on regulator imho should not change its rate...
Yes, although there is the whole "don't touch things until a consumer
tells us to" thing going on. I had expected that this was kicking in
because we weren't paying attention to the constraints of disabled
regulators but I can't see the code implementing that any more so I
guess we removed it at some point (it was always debatable).
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists