From: Eric Miao <eric.y.miao@gmail.com>
To: Daniel Ribeiro <drwyrm@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.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: Mon, 29 Jun 2009 11:00:38 +0800 [thread overview]
Message-ID: <4A482E56.1070604@gmail.com> (raw)
In-Reply-To: <1246071323.10360.386.camel@brutus>
Daniel Ribeiro wrote:
> Em Sáb, 2009-06-27 às 01:48 +0100, Mark Brown escreveu:
>>> + /*
>>> + * When the bootloader leaves a supply active, it's
>>> + * initialized with zero usecount ... and we can't
>>> + * disable it without first enabling it. Until the
>>> + * framework is fixed, we need a workaround like this
>>> + * (which is safe for MMC, but not in general).
>> This also needs to explain the actual situation, especially the
>> exclusivity reqirement of the MMC core. It might be worth providing a
>> helper in the MMC core, everything is going to need to be updated to use
>> exclusive get whenever someone implements it.
>
> Heh, this patch was copy-n-paste from twl code. I really can't put much
> time on this. :(
>
>> As discussed at some length the regulator API is not going to be changed
>> in the way you demand. This is not something that it should be easy for
>> standard consumers to do since for standard consumers it normally points
>> out a programming error.
>
> Ok, so I will "fix it" hacking the bootloader to power off the voltage
> regulator before giving control to kernel. Lets hope that the next
> developer that tries to use the regulator framework with a mmc card and
> stumbles on the "regulator already enabled" case has more time to fix it
> properly. :)
>
This looks to be running into the same issue as clocks - where for power
savings the clocks are assumed to be off as many as possible, leaving only
those essential ones enabled, yet the assumption of the boot loader does
this correctly is always a big problem, putting this into the kernel,
however, is ugly.
next prev parent reply other threads:[~2009-06-29 3:00 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 [this message]
2009-06-29 9:43 ` Mark Brown
2009-07-01 2:36 ` David Brownell
2009-07-01 11:46 ` Mark Brown
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=4A482E56.1070604@gmail.com \
--to=eric.y.miao@gmail.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dbrownell@users.sourceforge.net \
--cc=drwyrm@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