Message-ID: <20110509130703.GM1254@legolas.emea.dhcp.ti.com>
Date:	Mon, 9 May 2011 16:07:07 +0300
From:	Felipe Balbi <balbi@...com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Felipe Balbi <balbi@...com>, Liam Girdwood <lrg@...nel.org>,
	Graeme Gregory <gg@...mlogic.co.uk>,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	sameo@...ux.intel.com
Subject: Re: [PATCH 4/4] USB: TWL6025 allow different regulator name

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists