mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: "Chris Zhong" <zyw@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	linux-rockchip@lists.infradead.org,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"Javier Martinez Canillas" <javier.martinez@collabora.co.uk>
Subject: Re: [PATCH] regulator: rk808: Add support setting suspend voltage
Date: Wed, 8 Oct 2014 19:19:59 +0100	[thread overview]
Message-ID: <20141008181959.GG4609@sirena.org.uk> (raw)
In-Reply-To: <CAD=FV=U5ng8egj4b5Mz1gwFpJPFxJmnSzhT0iRtOj=7VxFTbSA@mail.gmail.com>

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

On Wed, Oct 08, 2014 at 09:12:59AM -0700, Doug Anderson wrote:
> On Wed, Oct 8, 2014 at 5:49 AM, Mark Brown <broonie@kernel.org> wrote:

> > No, this is not the case.  The suspend mode settings are a completely
> > different set of settings activated when the system goes into suspend
> > with explicit hardware support.  If no configuration for this mode is
> > provided then

> I think maybe you missed finishing your sentence?

nothing will be changed.

> >> I believe that won't be the case for your driver.  The rk808 will (I
> >> think) automatically transition to the "suspend voltage" settings for
> >> ALL regulators at suspend time.  If you didn't explicitly set the
> >> suspend voltage then you'll move to whatever the default voltage is,
> >> right?

> > As ever the hardware configuration won't be touched by the kernel unless
> > it's explicitly told to do something.

> I guess my point is that the kernel's inaction is actually causing
> something unexpected to happen.  Robots can't let humans come to harm
> by inaction any more than they can harm them by action.

> Specifically I would expect that voltages would stay constant when the
> rk808 "sleep" pin is asserted if I didn't explicitly say to disable
> this regulator at sleep time and I didn't explicitly specify a voltage
> at sleep time.  As Chris's patch stands right now this isn't the case.

The assumption has to be that the configuration that the device has is
essential to bringing the system into and out of suspend, if we went and
overrode everything with the current runtime configuration I'd expect
we'd break a whole bunch of systems and severely impact the power
consumption in suspend of more.  What you're asking for is just not how
these systems are designed, complain to your electrical engineers.  With
this model for doing things suspend entry and exit is defined and
sequenced at system design time (often with limited configuration so
really at tapeout time).  

> When the kernel driver sets it to 1.9V, it will go through
> regulator_set_voltage_sel_regmap() which will set the BUCK4_ON_VSEL
> register and we'll be at 1.9V.  Great, we're at 1.9V.  Now we're ready
> to go to sleep.  I'd expect that the voltage would stay at 1.9V, but
> it won't.  BUCK4_SLP_VSEL was never programmed so it's at whatever the
> default is (1.8V) and we will transition there.

No, if the driver needs a particular state during suspend it needs to
explicitly set the suspend mode, that's what those APIs are there for.
Remember that a suspended device is supposed to not be doing anything
anyway most of the time...

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

  reply	other threads:[~2014-10-08 18:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07  8:43 Chris Zhong
2014-10-07 17:48 ` Doug Anderson
2014-10-08  8:46   ` Javier Martinez Canillas
2014-10-08 16:30     ` Doug Anderson
2014-10-08 12:49   ` Mark Brown
2014-10-08 16:12     ` Doug Anderson
2014-10-08 18:19       ` Mark Brown [this message]
2014-10-07 18: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=20141008181959.GG4609@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=javier.martinez@collabora.co.uk \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=zyw@rock-chips.com \
    /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

Powered by JetHome