mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-pm@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH] cpufreq: tegra: add regulator dependency for T124
Date: Wed, 9 Dec 2015 14:47:34 +0000	[thread overview]
Message-ID: <20151209144734.GB5727@sirena.org.uk> (raw)
In-Reply-To: <5668188F.2080202@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

On Wed, Dec 09, 2015 at 12:03:27PM +0000, Jon Hunter wrote:
> On 08/12/15 21:52, Arnd Bergmann wrote:

> > My first attempt was to implement a helper for this function
> > for regulator_sync_voltage, but Mark Brown explained:

> >    We don't do this for *all* regulator API functions - there's some where
> >    using them strongly suggests that there is actually a dependency on
> >    the regulator API.  This does seem like it might be falling into the
> >    specialist category [...]
> >    Looking at the code I'm pretty unclear on what the authors think the
> >    use of _sync_voltage() is doing in the first place so it may be even
> >    better to just remove the call.  It seems to have been included in the
> >    first commit so there's not changelog explaining things and there's
> >    no comment either.  I'd *expect* it to be a noop as far as I can see.

> In this sequence we are switching from the DFLL clock source (which
> directly controls the voltage) back to a PLL (which does not control the
> voltage directly). What we want to do is to restore the voltage back to
> the voltage it was operating at before we switched to the DFLL clock
> (which could have changed it).

If changes implemented by the clock driver are trashing the regulator
settings I would expect the clock driver to be responsible for fixing
things up rather than another driver that happens to use the clock.  I'd
also expect some kind of internal documentation explaining what's going
on, and possibly 

> I am not familiar with regulator_sync_voltage() but from the comment it
> does say that it will re-apply the last voltage that was configured for
> the regulator. So I can see what they were doing. The question I have
> is, if the consumer has not explicitly called regulator_set_voltage()
> then what does regulator_sync_voltage() do? I am wondering if we should
> have been doing a regulator_get_voltage() during the probe and a
> regulator_set_voltage() when switching back?

This *is* the sort of thing _sync() is intended for, though it's mainly
expected to be used in cases like suspend where things have been powered
off.  As you can see from the code it's based on the settings that
software made, but then if nothing in software has any need to configure
anything then why do we even care that the hardware changed anything?

Setting the voltage you've read back sounds broken, if the hardware
might randomly change things how do you know the settings we read were
sane?  Shouldn't we know what voltage range the device requires in a
given mode and set that - that's much more normal?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-12-09 14:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 21:52 Arnd Bergmann
2015-12-09  2:16 ` Viresh Kumar
2015-12-09 12:03 ` Jon Hunter
2015-12-09 14:47   ` Mark Brown [this message]
2015-12-09 17:33     ` Jon Hunter
2015-12-09 20:10       ` Mark Brown
2015-12-10 10:07         ` Jon Hunter
2015-12-10 11:35           ` Mark Brown
2015-12-10 12:12             ` Jon Hunter
2015-12-12  2:26 ` Rafael J. Wysocki

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=20151209144734.GB5727@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=arnd@arndb.de \
    --cc=gnurou@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    --cc=viresh.kumar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®