From: Mark Brown <broonie@sirena.org.uk>
To: David Brownell <david-b@pacbell.net>
Cc: Tony Lindgren <tony@atomide.com>,
linux-omap@vger.kernel.org, lrg@slimlogic.co.uk
Subject: Re: [PATCH] OMAP: Don't warn user about expected behaviour in mmc-twl4030
Date: Mon, 6 Apr 2009 16:56:10 +0100 [thread overview]
Message-ID: <20090406155609.GD4057@sirena.org.uk> (raw)
In-Reply-To: <200904031803.33648.david-b@pacbell.net>
On Fri, Apr 03, 2009 at 06:03:33PM -0700, David Brownell wrote:
> On Tuesday 31 March 2009, Mark Brown wrote:
> > The documention should not be changed to say that since only consumers
> > that need the regulator to be off at startup should do this, and then
> > probably only if they find that it is already enabled.
> "Probably" shows you still don't have a good answer...
No, it means that I can't think of any reason why they'd want to bounce
the supply but I'm open to the possibility that there could be one.
> I see that mainline now has ca7255614e0861e36480103f4a402a115803d7b5
> which is a variant of the first late-fixup patch I sent. The isssue
> with that approach is that it leaves a huge window between regulator
> init and its late fixup ... during which driver probe() calls suffer
> the bad effects of the current self-inconsistent initialization. So
> it doesn't really address the MMC cases.
That change was not intended to do anything for MMC, it's there for
other users like shared regulators and situations where no consumer
driver instantiates.
It is really important that you engage with the feedback you are
getting. At this point we are all quite familiar with your views and we
do understand them, restating them is not what's needed. Changes have
to be made with an understanding of the existing interface and how it
supports the use cases the API has, including users other than MMC.
Changes also need to be made with consideration given to merge issues.
> And in fact, that's exactly what I think folk should be doing with
> the recent additions to twl4030-power supporting explicit init of
> all the power resources ... as done with e.g. Beagle. The benefit
...
> So there's an OMAP-specific workaround now in place, albeit not
> yet headed towards mainline.
With Jonathan's patch there will be support in the regulator API for
doing this with all regulators.
next prev parent reply other threads:[~2009-04-06 15:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 19:15 [PATCH] OMAP: Don't warn user about expected behaviour in mmc-twl4030 Mark Brown
2009-03-30 20:53 ` David Brownell
2009-03-31 21:00 ` Mark Brown
2009-04-04 0:26 ` Tony Lindgren
2009-04-04 0:40 ` Mark Brown
2009-04-04 1:03 ` David Brownell
2009-04-06 15:56 ` Mark Brown [this message]
2009-04-04 0:24 ` [APPLIED] [PATCH] OMAP: Don't warn user about expected behaviour in Tony Lindgren
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=20090406155609.GD4057@sirena.org.uk \
--to=broonie@sirena.org.uk \
--cc=david-b@pacbell.net \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=tony@atomide.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