public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Mark Brown <broonie@kernel.org>
Cc: Sangbeom Kim <sbkim73@samsung.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Tomasz Figa <t.figa@samsung.com>,
	Yadwinder Singh Brar <yadi.brar@samsung.com>,
	Sachin Kamat <sachin.kamat@linaro.org>
Subject: Re: [PATCH 2/3] regulator: s2mps11: Add set_suspend_disable for S2MPS14
Date: Thu, 06 Mar 2014 15:42:22 +0100	[thread overview]
Message-ID: <1394116942.25853.14.camel@AMDC1943> (raw)
In-Reply-To: <20140306093826.GO13126@sirena.org.uk>

On Thu, 2014-03-06 at 17:38 +0800, Mark Brown wrote:
> On Wed, Mar 05, 2014 at 10:22:52AM +0100, Krzysztof Kozlowski wrote:
> 
> > +	ret = regmap_read(rdev->regmap, rdev->desc->enable_reg, &data);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	/*
> > +	 * Don't enable suspend mode if regulator is already disabled because
> > +	 * this would effectively for a short time turn on the regulator after
> > +	 * resuming.
> > +	 */
> > +	if (!(data & rdev->desc->enable_mask))
> > +		return 0;
> > +
> > +	return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
> > +			rdev->desc->enable_mask, S2MPS14_ENABLE_SUSPEND);
> > +}
> 
> What happens if the regulator gets enabled between this being called
> and the device suspending?  I'd expect this to be storing the state and
> then changing what gets written during enable and disable operations (if
> the hardware does what I think it does).

It seems that none of the regulators implementing set_suspend_disable()
work that way. They just write the suspend value to device. Of course
this is not an issue - the S2MPS14 may be the first :).

However in that case the driver won't be able later to change that value
back to "normal enable" (enable_mask). Consider such flow:
1. System is going to suspend.
2. Some regulator has "rstate->disabled" so set_suspend_disable() is
called on it.
3. The "suspend" value is written to the device for given regulator and
it is stored as "enable" value.
4. If regulator is enabled during here then the same "suspend" value
will be written.
5. System is suspended.
6. After resuming regulator_suspend_finish() calls
_regulator_do_enable() on the regulator... which will write the
"suspend" value because the driver cannot differentiate between this
enable and previous.

I assume that this may not be a problem because:
1. Regulator will be still turned on (the "suspend" value tells PMIC to
enable the regulator when SoC enables power).
2. The first disable of regulator may bring back "enable" value back to
normal mode.

Am I thinking here correctly? 


Best regards,
Krzysztof



  parent reply	other threads:[~2014-03-06 14:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05  9:22 [PATCH 0/3] regulator: s2mps11: Add support for S2MPS14 regulators Krzysztof Kozlowski
2014-03-05  9:22 ` [PATCH 1/3] " Krzysztof Kozlowski
2014-03-05  9:22 ` [PATCH 2/3] regulator: s2mps11: Add set_suspend_disable for S2MPS14 Krzysztof Kozlowski
2014-03-05  9:55   ` Lee Jones
2014-03-06  9:38   ` Mark Brown
2014-03-06  9:48     ` Krzysztof Kozlowski
2014-03-07  1:51       ` Mark Brown
2014-03-07  7:28         ` Krzysztof Kozlowski
2014-03-10  9:47           ` Lee Jones
2014-03-06 14:42     ` Krzysztof Kozlowski [this message]
2014-03-07  2:37       ` Mark Brown
2014-03-07 10:15         ` Krzysztof Kozlowski
2014-03-05  9:22 ` [PATCH 3/3] Documentation: mfd: s2mps11: Document support " Krzysztof Kozlowski
2014-03-05 10:04   ` Sachin Kamat

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=1394116942.25853.14.camel@AMDC1943 \
    --to=k.kozlowski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=broonie@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=sachin.kamat@linaro.org \
    --cc=sameo@linux.intel.com \
    --cc=sbkim73@samsung.com \
    --cc=t.figa@samsung.com \
    --cc=yadi.brar@samsung.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