linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: move regulator handling to core
Date: Sun, 29 Aug 2010 14:27:12 +0100	[thread overview]
Message-ID: <20100829132711.GB10233@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <AANLkTi=20KrUy334JRmMYwK7rbaVYrYCqW-BHZYGPrwT@mail.gmail.com>

On Sat, Aug 28, 2010 at 04:48:58PM +0200, Linus Walleij wrote:
> 2010/8/27 Chris Ball <cjb@laptop.org>:

> > Looks like this patch got dropped because of the missing modifications
> > to arch/arm/mach-omap2/mmc-twl4030.c. ?Are we still interested in the
> > patch otherwise, and can anyone help with that?

> Actually just before the summer I submitted something not quite similar:
> I moved all regulator handling *out* of the MMC core because I didn't
> trust the way reference counting was being handled.

This seems like the wrong approach; if there's a problem it'd seem much
better to fix the core code that everything is sharing rather than
factor it out - the location of the code is orthogonal to its
helpfulness.

> There is something very disturbing about this code from
> regulator/core/core.c mmc_regulator_set_ocr():

The MMC code in the core was last time I looked explicitly reliant on
the regulators not being shared - it wants the regulators to be grebbed
with regulator_get_exclusive() which guarantees that.  When the code was
added there was a strong insistance that shared supplies could not be
used with MMC so this was fine.

> So it looks to me like it is possible for one slot to enable the
> regulator and race with another slot which disables it at the
> same time and end up with the regulator disabled :-(

It's not really a race, it's just a simple inability to cope with
something else sharing the same regulator - at the minute it'll do
things like turn off the regulator when one port is done even if the
other port still needs it.

> My solution would still be to move the enable/disable out
> of the core, so I need to follow up on that.

The code needs to be changed so that the port remembers internally if
it itself needs the regulator enabled or disabled rather than inspecting
the current hardware state since that may differ as a result of being
forced by the system or the activity of other ports.

  reply	other threads:[~2010-08-29 13:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-03 12:46 [PATCH] mmc: move regulator handling to core Daniel Mack
2009-12-03 13:06 ` Mark Brown
2009-12-03 13:14   ` Daniel Mack
2009-12-03 13:22     ` Mark Brown
2009-12-03 13:32       ` Daniel Mack
2009-12-03 13:40         ` Mark Brown
2009-12-03 13:43           ` Daniel Mack
2009-12-03 14:58       ` Russell King - ARM Linux
2009-12-03 15:09         ` Mark Brown
2009-12-03 14:27 ` Adrian Hunter
2009-12-03 19:20   ` Daniel Mack
2009-12-03 20:12     ` Adrian Hunter
2009-12-04 11:58       ` Daniel Mack
2009-12-12  0:58         ` Daniel Mack
2009-12-14 17:43           ` Madhusudhan
2009-12-15  5:44         ` David Brownell
2010-08-27 19:03 ` Chris Ball
2010-08-28 14:48   ` Linus Walleij
2010-08-29 13:27     ` Mark Brown [this message]
2010-08-29 15:30       ` Linus Walleij
2010-08-31 11:07         ` Mark Brown
2010-08-31 12:15           ` Linus Walleij

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=20100829132711.GB10233@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).