On Friday 30 September 2011 05:48 PM, Mark Brown wrote:
On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:

The "regulator-supplies" is used to specific the regulator *parent*.
Same as what was earlier passed by using the
"supply_regulator" field of regulator_init_data structure.
Grant wanted the bindings to support specifying multiple parents
and hence I was thinking of either a list of names *or*
a list of phandles to specify multiple parents to a regulator.

So, as I'm fairly sure I said last time these are just standard
supplies.  It just happens to be that the consumer is a regulator.  The
fact that Linux chooses to have core framework handling for this is an
implementation detail of Linux (and indeed many devices ignore this for
their on board regulators).

Yes, the implementation details of linux is what is making me using
these bindings difficult, and maybe you can help me how I can work
around the framework. The binding themselves, I agree should not care
if the consumer is a device/IP or a regulator itself.

So here's my problem:

I use the <name-supply> = <&reg_phandle> binding to define
a device/IP using one/more regulators on one/more rails.

device mmc {
        ...
        ...
        vmmc-supply = <&vmmc>;
        vpll-supply = <&vpll>;
};

The parsing of the "vmmc-supply" or the "vpll-supply" property
happens only when a mmc drivers makes a call to
regulator_get() passing the supply-name as "vmmc" or "vpll".
For ex:
regulator_get(dev, "vmmc"); or regulator_get(dev, "vpll");

Its easy to just append the "-supply" to a "vmmc" or "vpll"
and derive a property name like "vmm-supply" or "vpll-supply".

Now lets take the case of a regulator as a consumer:

regulator vmmc {
        ...
        ...
        vin-supply = <&vin>;
};

Now I need to parse the "vin-supply" property during a
regulator_register(), so I could do a set_supply() and
create the parent/child relationship between a vin and
vmmc.
The problem is I don't know if the property in the regulator dt
node is called "vin-supply" or "vxyz-supply" and hence I
can parse the property based on a substring alone, which is
"-supply" because all I know is the property name is expected
to end with a "-supply".

I can always add a new of_find_property_substr() which finds
me property based on a substring value passed rather than the
exact property-name string.
However I don;t know if this is the best way to handle it.
Any thoughts?



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to