All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.