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>
Subject: Re: [PATCH] PCAP regulator driver (for 2.6.32).
Date: Fri, 26 Jun 2009 09:26:32 -0300	[thread overview]
Message-ID: <1246019192.10360.202.camel@brutus> (raw)
In-Reply-To: <20090626105550.GE5415@sirena.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

Em Sex, 2009-06-26 às 11:55 +0100, Mark Brown escreveu:
> On Fri, Jun 26, 2009 at 03:04:23AM -0300, Daniel Ribeiro wrote:
> > So, the regulator is enabled at boot, but it can't be disabled because
> > use_count is 0. This is the same issue as twl4030-mmc, but instead of a
> > enable/disable pair on pxamci.c i opted to disable it at pcap's
> 
> At the minute you need to use the enable/disable pair since (as we've
> previously discussed) the API needs to support regulators which are
> shared between multiple users (potentially including multiple users from
> the same consumer).

> You need to either do that or add an API allowing consumers to claim a
> regulator for exclusive use.  If the regulator is claimed for exclusive
> use then other consumers wouldn't be able to access it and there would
> be no issue with interfering with other users.

I'm not proposing an API for exclusive use. Allowing the enable bit to
be turn off case use_count is 0 shouldn't break regulator sharing for
other consumers, as far as the regulator framework is concerned there
are no other consumers.

What about increasing use_count at regulator_get() if the regulator is
already on and use_count == 0? If a consumer requests a regulator that
was previously ON, then there is no reason for it to enable/disable it.
If it is requested, and its already ON, then the regulator framework can
assume it is already being used.

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?

-- 
Daniel Ribeiro

[-- Attachment #2: Esta é uma parte de mensagem assinada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2009-06-26 12:26 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 [this message]
2009-06-26 15:08         ` Mark Brown
2009-06-26 22:26           ` Daniel Ribeiro
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=1246019192.10360.202.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=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.