From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: David Brownell <david-b@pacbell.net>
Cc: Eric Miao <eric.y.miao@gmail.com>,
Daniel Ribeiro <drwyrm@gmail.com>,
Pierre Ossman <pierre@ossman.eu>,
linux-kernel <linux-kernel@vger.kernel.org>,
openezx-devel <openezx-devel@lists.openezx.org>,
Liam Girdwood <lrg@slimlogic.co.uk>,
linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs
Date: Fri, 24 Jul 2009 15:35:47 +0100 [thread overview]
Message-ID: <20090724143547.GC28228@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <200907221403.07985.david-b@pacbell.net>
On Wed, Jul 22, 2009 at 02:03:07PM -0700, David Brownell wrote:
> /* that this simple idiom would finally work */
> if (regulator_is_enabled(r))
> regulator_disable(r);
For the avoidance of future disappointment please note that an exclusive
access request does not remove the reference counting on the regulator,
it only changes the way in which it is intialised. This means that the
above code is only guaranteed to cause the regulator to be disabled so
long as the consumer never calls enable() twice without a matching
disable(). It will, however, not return an error due to unbalanced
enables and disables which I believe is your primary requirement here.
> of which were within (d) an ever-increasing number of constraints
> you grew with each new iteration. I had to try so many different
> approaches since nothing seemed to be getting through. The lack
For clarity and in the hope that this helps to avoid future issues
let me list the three major constraints in this area:
- The API supports shared regulators.
- Regulator enabling by software is reference counted.
- Changing the state of regulators before drivers have had a chance to
take control of the devices is very disruptive to the system and
needs to be avoided as a result.
Everything else flows from those, in conjunction with the standard
considerations about making sure that any transitions are managed in as
graceful a fashion as possible.
I'm leaving the rest of your mail because I don't think discussing that
further here is going to get us anywhere.
prev parent reply other threads:[~2009-07-24 14:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-26 23:07 [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs Daniel Ribeiro
2009-06-27 0:48 ` Mark Brown
2009-06-27 2:55 ` Daniel Ribeiro
2009-06-29 3:00 ` Eric Miao
2009-06-29 9:43 ` Mark Brown
2009-07-01 2:36 ` David Brownell
2009-07-01 11:46 ` Mark Brown
2009-07-22 21:03 ` David Brownell
2009-07-24 14:35 ` Mark Brown [this message]
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=20090724143547.GC28228@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=david-b@pacbell.net \
--cc=drwyrm@gmail.com \
--cc=eric.y.miao@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=openezx-devel@lists.openezx.org \
--cc=pierre@ossman.eu \
/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