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>,
David Brownell <dbrownell@users.sourceforge.net>,
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: Wed, 1 Jul 2009 12:46:04 +0100 [thread overview]
Message-ID: <20090701114603.GA22063@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <200906301936.20818.david-b@pacbell.net>
On Tue, Jun 30, 2009 at 07:36:20PM -0700, David Brownell wrote:
> On Monday 29 June 2009, Mark Brown wrote:
> > At the minute the regulator API actually copes pretty well with this -
> > the only problem I'm aware of is with drivers like the MMC driver which
> > require exclusive control of the regulator.
> Which is a fairly typical situation for power-aware drivers.
As has been mentioned a number of times in previous discussions of this
there is a very large class of devices which do not *require* any power
control at all but which can usefully switch their supplies on and off.
> Which belies your claim that the regulator API "copes pretty well".
> It'd be more accurate to say "broken-as-designed", since you have
> rejected numerous attempts to fix this, yet not fixed it yourself.
You've suggested variations of essentially one approach, forcing the
regulator to be off while the use count is zero. In response to this
you've not only been given explanations of the problems this causes but
also several suggestions for alternative approaches such as adding a way
to request exclusive use of the regulator or adding something in
constraints to turn off the regulator at startup.
I have previously had to ask you to try to approach discussions on the
regulator API in a more constructive fashion, please let me renew that
request. Doing so would be much less time consuming and for that reason
if nothing else would be very helpful in progressing things.
next prev parent reply other threads:[~2009-07-01 11:46 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 [this message]
2009-07-22 21:03 ` David Brownell
2009-07-24 14:35 ` 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=20090701114603.GA22063@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=david-b@pacbell.net \
--cc=dbrownell@users.sourceforge.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