From: Felipe Balbi <balbi@ti.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Felipe Balbi <balbi@ti.com>, Liam Girdwood <lrg@kernel.org>,
Graeme Gregory <gg@slimlogic.co.uk>,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
sameo@linux.intel.com
Subject: Re: [PATCH 4/4] USB: TWL6025 allow different regulator name
Date: Mon, 9 May 2011 16:07:07 +0300 [thread overview]
Message-ID: <20110509130703.GM1254@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <20110509122941.GA3225@opensource.wolfsonmicro.com>
Hi,
On Mon, May 09, 2011 at 02:29:41PM +0200, Mark Brown wrote:
> On Mon, May 09, 2011 at 03:16:03PM +0300, Felipe Balbi wrote:
> > On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote:
>
> > > I think it's the lesser evil though, especially for device integrators.
> > > They will just match the regulator name from the schematics together
> > > with the TRM name when creating their regulator constraints and having
> > > different names here will definitely cause confusion.
>
> > Any chance Device Tree could be used to pass that data to kernel
> > instead, together with regulator names and all needed data for each one
> > of them ?
>
> I'm pretty sure that as soon as we have viable device tree support for
> relevant platforms in mainline we'll have regulator support, though I'm
> not sure that this will help too much with the naming as you'll still
> have to figure out what the consumer requests. We shouldn't be passing
> in the consumer supply names from device tree (at least not a board
> specific one) as this breaks the model that the supply names correspond
> to the chip pins.
The thing is. We already had problems in the past with the Clock FW
because drivers were passing clock names on platform_data and I really
want to avoid the same on regulators. We need something clever.
We pass in the data of how regulators are wired at the board level and
drivers would regulator_get(my_dev->dev, "whatever fancy name I want as
it doesn't matter at all");
If a driver has >1 regulator, you can distinguish them by which
functionality they provide, no matter the name, they will be connected
to a particular ball on the IC package which has a certain definition
on the TRM. In other words, we should match on the functionality they
provide, not on the name.
Let's try to thing some 5 - 6 years ahead. With the current trend, we
will be working on support for the PMIC on OMAP10, imagine if each one
of those revisions decide to change the name of the regulator, because
this new HW engineer working on the PMIC design doesn't like the old
name. We will have X regulator pointers and X regulator name pointers in
our platform_data. It will be really cumbersome and prone to errors if
people continue on copy&pasting old code to "generate" a new driver.
What I was expecting to see, was a mechanism where we define how those
things are wired (it doesn't matter if the data uses DeviceTree or what)
at the HW level and we ask the framework to give us the regulator
connected to device X which provides a certain functionality. Just like
clkdev has managed to get close to. Currently drivers will:
clk_get(dev, "ick");
clk_get(dev, "fck");
etc...
and the name really doesn't matter. Clkdev still isn't perfect as it
uses device names, then when we want/need to change the device/driver
name (due to some re-factoring for example) we end up breaking things.
IMHO, struct device should point to its dependencies, be it a clock, be
it a regulator.
--
balbi
next prev parent reply other threads:[~2011-05-09 13:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-27 9:39 [PATCH 0/4] Add support for twl6025 PMIC Graeme Gregory
2011-04-27 9:39 ` [PATCH 1/4] MFD: TWL6025: add phoenix lite support to twl6030 Graeme Gregory
2011-04-27 10:40 ` Felipe Balbi
2011-05-08 20:32 ` Liam Girdwood
2011-04-27 9:39 ` [PATCH 2/4] MFD: TWL6030: fix irq definitions Graeme Gregory
2011-04-27 9:39 ` [PATCH 3/4] REGULATOR: TWL6025: add support to twl-regulator Graeme Gregory
2011-04-27 10:43 ` Felipe Balbi
2011-04-27 11:08 ` Mark Brown
2011-04-27 9:39 ` [PATCH 4/4] USB: TWL6025 allow different regulator name Graeme Gregory
2011-04-27 10:45 ` Felipe Balbi
2011-05-08 15:08 ` Liam Girdwood
2011-05-09 9:03 ` Felipe Balbi
2011-05-09 11:43 ` Liam Girdwood
2011-05-09 12:16 ` Felipe Balbi
2011-05-09 12:29 ` Mark Brown
2011-05-09 13:07 ` Felipe Balbi [this message]
2011-05-09 13:35 ` Mark Brown
2011-05-09 13:51 ` Felipe Balbi
2011-05-09 15:17 ` Mark Brown
2011-05-09 13:11 ` Liam Girdwood
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=20110509130703.GM1254@legolas.emea.dhcp.ti.com \
--to=balbi@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=gg@slimlogic.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@kernel.org \
--cc=sameo@linux.intel.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
all inboxes | Powered by JetHome®