From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: "Balbi, Felipe" <balbi@ti.com>,
linux-omap@vger.kernel.org, "Girdwood, Liam" <lrg@ti.com>
Subject: Re: [RFC 0/4] TWL external controller support
Date: Mon, 11 Jul 2011 21:11:14 +0900 [thread overview]
Message-ID: <20110711121111.GL5092@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1310381339.4331.45.camel@sokoban>
On Mon, Jul 11, 2011 at 01:48:59PM +0300, Tero Kristo wrote:
> On Mon, 2011-07-11 at 12:05 +0200, Mark Brown wrote:
> > No. Why do you want these regulators to have anything to do with the
> > TWL4030?
> So, a completely new driver should be made for these? The reason I
> wanted to put them within TWL4030 code is that they reside inside
> TWL4030, and there is already some code for accessing these regulators
> (in the standard I2C access method) from the twl-regulator.c.
Well, if they're not perceptibly part of the same chip from a control
point of view and need you to provide board specific callbacks it would
seem logical...
> > > configured from the TWL side. The voltage processor support is currently
> > > provided by the omap platform code, and regulator code knows nothing
> > > about this. It might also be possible to do compile time switch for the
> > > interface here if that is acceptable, however a runtime interface for
> > > doing this would provide more flexibility.
> > This isn't making much sense to me, what is the relationship between
> > this and the other regulators you're adding these bodge interfaces for?
> > Why would you want to switch between the two modes at runtime and how
> > would anyone take the decision to do so?
> Runtime switching would mostly be useful as a testing feature. In
> typical setup the configuration is just selected during boot time, and
> thats it. And normally we would just want to use the voltage processor
> interfaces to control these regulators.
It doesn't seem like a good idea to support that, then. If there's no
benefit to switching dynamically we're just adding complexity to the
system which people will then spend time tweaking and making work
dealing with any robustness issues from managing the transitions.
> > If some of the TWL4030 regulators are controlled by something other than
> > the CPU in your system then the TWL4030 driver shouldn't be configured
> > to do anything with them except possibly provide read only access.
> I think this part I have not been too clear about... CPU is controlling
> the voltage level for these regulators, but the used hardware interface
> is different... and the CPU is giving a guideline that we should be
> using the nominal voltage level based on cpufreq setup, but the actual
> voltage set on the TWL chip is usually different.
Right, but from a software point of view the fact that we end up with
the same physical regulator is immaterial as you have to try *really*
hard to notice.
next prev parent reply other threads:[~2011-07-11 12:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 15:56 [RFC 0/4] TWL external controller support Tero Kristo
2011-07-08 15:56 ` [RFC 1/4] twl-regulator: extend for SMPS regulators and external controllers Tero Kristo
2011-07-08 18:26 ` Liam Girdwood
2011-07-09 1:21 ` Mark Brown
2011-07-08 15:56 ` [RFC 2/4] omap3beagle: Instantiate VDD1 and VDD2 regulators Tero Kristo
2011-07-08 16:22 ` Felipe Balbi
2011-07-08 15:56 ` [RFC 3/4] omap: attach external controller to VDD1/VDD2 Tero Kristo
2011-07-08 16:23 ` Felipe Balbi
2011-07-08 15:56 ` [RFC 4/4] OMAP3: beagle rev-c4: enable OPP6 Tero Kristo
2011-07-08 16:23 ` Koen Kooi
2011-07-08 16:25 ` [RFC 0/4] TWL external controller support Felipe Balbi
2011-07-09 1:24 ` Mark Brown
2011-07-09 10:40 ` Felipe Balbi
2011-07-09 10:56 ` Mark Brown
2011-07-11 8:23 ` Tero Kristo
2011-07-11 10:05 ` Mark Brown
2011-07-11 10:48 ` Tero Kristo
2011-07-11 12:11 ` Mark Brown [this message]
2011-07-11 13:06 ` Tero Kristo
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=20110711121111.GL5092@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=balbi@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@ti.com \
--cc=t-kristo@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