From: Daniel Ribeiro <drwyrm@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
linux-kernel <linux-kernel@vger.kernel.org>,
openezx-devel <openezx-devel@lists.openezx.org>,
Samuel Ortiz <sameo@linux.intel.com>,
David Brownell <dbrownell@users.sourceforge.net>,
Pierre Ossman <pierre@ossman.eu>
Subject: Re: [PATCH] PCAP regulator driver (for 2.6.32).
Date: Fri, 26 Jun 2009 19:26:55 -0300 [thread overview]
Message-ID: <1246055215.10360.273.camel@brutus> (raw)
In-Reply-To: <20090626150849.GA5504@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]
Em Sex, 2009-06-26 às 16:08 +0100, Mark Brown escreveu:
> > If the above is not possible, then regulator_is_enabled() doesn't match
> > regulator_enable()/regulator_disable() pair. Maybe the API should make
> > this clear?
>
> Frankly I'm not sure how much any documentation is going to help here.
> There's already a note about the fact that the regulator might've been
> enabled elsewhere, it could be strengthened a bit but it still relies on
> people reading it.
I wasn't talking about documentation.
> Fundamentally, if your consumer is trying to explicitly force the
> regulator off then it's not able to cope with the regulator being
> shared. I suspect that if someone does add a non-shared API then the
> problem will go away, half the problem is with consumers thinking they
> have exclusive use of the regulator.
The consumer (pxamci.c with the logic implemented on mmc/core.c) is not
trying to explicitly force the regulator off. It is trying to know if
itself has previously enabled the regulator.
The problem is that regulator_is_enabled returns the regulator
_hardware_ state, and regulator_enable/regulator_disable are used to
update the use_count. This is an API inconsistency as the consumer
should keep an internal use_count and _not_ rely on
regulator_is_enabled.
I see no point in exporting regulator_is_enabled() as it is now. There
is no use in a consumer driver to know if the regulator _hardware_ is
enabled (as it may be shared).
So, if the regulator framework has no bugs regarding regulators left on
by the bootloader, then maybe the buggy code is mmc/core.c?
int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit)
{
...
int enabled;
enabled = regulator_is_enabled(supply);
...
if (vdd_bit) {
...
if (result == 0 && !enabled)
result = regulator_enable(supply);
} else if (enabled) {
result = regulator_disable(supply);
}
return result;
}
Anyway, I don't have more time to spend on this issue, so i will just do
as you request, remove the workaround from pcap_regulator.c and put it
on pxamci.c, even if I think that this is the ugliest solution so far.
--
Daniel Ribeiro
[-- Attachment #2: Esta é uma parte de mensagem assinada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-06-26 22:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-25 20:29 [PATCH] PCAP regulator driver (for 2.6.32) Daniel Ribeiro
2009-06-25 23:37 ` Mark Brown
2009-06-26 6:04 ` Daniel Ribeiro
2009-06-26 10:55 ` Mark Brown
2009-06-26 12:26 ` Daniel Ribeiro
2009-06-26 15:08 ` Mark Brown
2009-06-26 22:26 ` Daniel Ribeiro [this message]
2009-06-27 0:20 ` 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=1246055215.10360.273.camel@brutus \
--to=drwyrm@gmail.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dbrownell@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=openezx-devel@lists.openezx.org \
--cc=pierre@ossman.eu \
--cc=sameo@linux.intel.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