From: Michael Bohan <mbohan@codeaurora.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: rnayak@ti.com, lrg@ti.com, LKML <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org
Subject: Re: Regulator supplies when using Device Tree
Date: Mon, 02 Apr 2012 10:35:22 -0700 [thread overview]
Message-ID: <4F79E35A.5040908@codeaurora.org> (raw)
In-Reply-To: <20120330103602.GE21950@opensource.wolfsonmicro.com>
On 3/30/2012 3:36 AM, Mark Brown wrote:
> On Thu, Mar 29, 2012 at 06:18:44PM -0700, Michael Bohan wrote:
>> Can you please elaborate on why this is a bad design? We have always
>> used this model in the past, and the regulator framework is happy to
>> support it.
>
> The support for regulator-regulator supplies has always been problematic
> and infrequently used -
Hmm, I'd be interested to know the history there.
> Please be more specific about what you're actually trying to physically
> accomplish here. It would be *extremely* unusual to see a regulator
> which was able to do something useful without any input power and if you
> genuinely have this need whatever you're doing probably needs the
> framework to actually be aware of what's going on. However...
Some of our regulators take inputs from other regulators. Some
regulators take their input from the battery. We support both types in
the same driver, since the hardware is the same. Thus this supply
configuration is natural and matches our hardware closely. The actual
connections of our regulators varies between different board designs.
If you're interested, you can checkout some sample driver code:
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/regulator/pm8xxx-regulator.c;h=fd691f051428158d3543dd7562e4f5e26e905962;hb=msm-3.0
And see how we pass the supply names and other parameters here:
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/board-8960-regulator.c;h=23e3e690ff0e582fd947553a51015f5059750cdf;hb=msm-3.0
We have a table of devices with associated data attributes -- one of
them being supplies. For devices with supplies, the name is specified.
For devices without supplies, nothing is specified. This works well
since then the driver doesn't need to check whether there exists a
supply or not.
>> I was hoping that we could continue to treat regulator supplies as
>> normal supplies, but somehow allow the framework to determine
>> whether a regulator supply exists or not in the Device Tree
>> configuration so the driver doesn't have to.
>
> ...this doesn't really make any sense - the new scheme makes regulator
> supplies *more* like normal supplies, not less, since they're now
> specified in exactly the same way as other supplies and are just assumed
> to be provided by the leaf driver.
I don't disagree that the new scheme makes supplies more like normal
supplies. I'm just pointing out the solution doesn't appear perfect
since extraneous code is put in the driver in this case.
Thanks,
Mike
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2012-04-02 17:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 1:17 Regulator supplies when using Device Tree Michael Bohan
2012-03-26 13:00 ` Mark Brown
2012-03-28 1:38 ` Michael Bohan
2012-03-28 10:09 ` Mark Brown
2012-03-28 19:19 ` Michael Bohan
2012-03-28 19:33 ` Mark Brown
2012-03-29 0:06 ` Michael Bohan
2012-03-29 4:44 ` Rajendra Nayak
2012-03-29 11:08 ` Mark Brown
2012-03-29 11:11 ` Mark Brown
2012-03-30 1:18 ` Michael Bohan
2012-03-30 10:36 ` Mark Brown
2012-04-02 17:35 ` Michael Bohan [this message]
2012-04-02 21:22 ` Mark Brown
2012-04-03 1:53 ` Michael Bohan
2012-04-03 12:25 ` 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=4F79E35A.5040908@codeaurora.org \
--to=mbohan@codeaurora.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=rnayak@ti.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;
as well as URLs for NNTP newsgroup(s).