On Tue, Oct 25, 2011 at 12:43:55PM +0530, Rajendra Nayak wrote:
> On Tuesday 25 October 2011 12:50 PM, Shawn Guo wrote:
> >On Tue, Oct 25, 2011 at 12:26:01PM +0530, Rajendra Nayak wrote:
> >>On Tuesday 25 October 2011 12:22 PM, Shawn Guo wrote:
> >>>On Tue, Oct 25, 2011 at 11:30:19AM +0530, Rajendr
On Tue, Oct 25, 2011 at 12:31:51PM +0530, Rajendra Nayak wrote:
> On Tuesday 25 October 2011 12:38 PM, Shawn Guo wrote:
> >On Tue, Oct 25, 2011 at 11:40:34AM +0530, Rajendra Nayak wrote:
> >>On Monday 24 October 2011 09:21 PM, Shawn Guo wrote:
> >>>On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Li
On Tuesday 25 October 2011 12:50 PM, Shawn Guo wrote:
On Tue, Oct 25, 2011 at 12:26:01PM +0530, Rajendra Nayak wrote:
On Tuesday 25 October 2011 12:22 PM, Shawn Guo wrote:
On Tue, Oct 25, 2011 at 11:30:19AM +0530, Rajendra Nayak wrote:
[...]
Thats what we did for OMAP, and hence we always hav
On Mon, Oct 24, 2011 at 10:47:17PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> > Might be best to just
> > search within dev and get drivers to pass the "real" device in when
> > registering the regulator rather than the virtual device.
> It should also
On Tue, Oct 25, 2011 at 12:26:01PM +0530, Rajendra Nayak wrote:
> On Tuesday 25 October 2011 12:22 PM, Shawn Guo wrote:
> >On Tue, Oct 25, 2011 at 11:30:19AM +0530, Rajendra Nayak wrote:
[...]
> >>Thats what we did for OMAP, and hence we always have the of_node
> >>populated when the regulator devi
On Tuesday 25 October 2011 12:38 PM, Shawn Guo wrote:
On Tue, Oct 25, 2011 at 11:40:34AM +0530, Rajendra Nayak wrote:
On Monday 24 October 2011 09:21 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Likely wrote:
[...]
It is always better to attach the of_node at struct de
On Tue, Oct 25, 2011 at 11:40:34AM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 09:21 PM, Shawn Guo wrote:
> >On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Likely wrote:
[...]
> >>It is always better to attach the of_node at struct device
> >>registration time instead of searching the
On Tuesday 25 October 2011 12:22 PM, Shawn Guo wrote:
On Tue, Oct 25, 2011 at 11:30:19AM +0530, Rajendra Nayak wrote:
On Monday 24 October 2011 07:17 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
Case 2:
One device for all regulators:
DT nodes look somet
On Tue, Oct 25, 2011 at 11:30:19AM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 07:17 PM, Shawn Guo wrote:
> >On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
> >>Case 2:
> >>One device for all regulators:
> >>
> >>DT nodes look something like this
> >>
> >>regulators {
>
On Tuesday 25 October 2011 11:30 AM, Rajendra Nayak wrote:
In that case should you not be first converting the mfd driver to
register regulator devices using DT?
Thats what we did for OMAP, and hence we always have the of_node
populated when the regulator devices are probed.
See this patch from
On Monday 24 October 2011 09:21 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Likely wrote:
On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
On Monday 24 October 2011 07:17 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
Case 2:
One device for all regulators:
DT nodes look something like this
regulators {
reg1: reg@1 {
...
...
};
On Mon, Oct 24, 2011 at 11:51:33PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Likely wrote:
> > On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> > > On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > > > On Mon, Oct 24, 2011 at 09:40:26PM +0
On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > > On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > > > diff --git a/drivers/regulator/core.c
On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > > index 8fe132d..29dcf90 100644
> > >
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > >
> > > > If we can attach the device_node
On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
>
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct
> > regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOT
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> >
> > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > when calling regulator_regis
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct
> regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
> Case 2:
> One device for all regulators:
>
> DT nodes look something like this
>
> regulators {
> reg1: reg@1 {
> ...
> ...
> };
>
> reg2: reg@2 {
>
On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
>
> > If we can attach the device_node of 'regulators' node to dev->of_node
> > when calling regulator_register(regulator_desc, dev, ...) from
> > regulator driver, the regulato
On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> If we can attach the device_node of 'regulators' node to dev->of_node
> when calling regulator_register(regulator_desc, dev, ...) from
> regulator driver, the regulator core will be able to find all nodes under
> 'regulators' using for_e
On Mon, Oct 24, 2011 at 11:24:11AM +0200, Grant Likely wrote:
> On Fri, Oct 21, 2011 at 04:23:12PM +0800, Shawn Guo wrote:
> > On Thu, Oct 20, 2011 at 05:39:32PM +0530, Rajendra Nayak wrote:
> > > On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
> > > >On Thu, Oct 20, 2011 at 10:48:58AM +0530
On Mon, Oct 24, 2011 at 05:11:58PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
> > On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
> > >Okay, it's wrong then since so many people say it's wrong :) I guess
> > >a quick fix would be adding one prope
On Monday 24 October 2011 02:49 PM, Mark Brown wrote:
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
How about the driver passing the of_node to be associated with the
regulator, as part of regulator_desc, to the regulator core,
instead of this complete DT search and the restri
On Mon, Oct 24, 2011 at 11:24:11AM +0200, Grant Likely wrote:
> To follow up from my earlier comment, this .dts structure looks fine
> and reasonable to me, and it would also be fine for the mc13892 driver
> to use for_each_child_of_node() to find all the children of the
> regulators node. Even f
On Fri, Oct 21, 2011 at 04:23:12PM +0800, Shawn Guo wrote:
> On Thu, Oct 20, 2011 at 05:39:32PM +0530, Rajendra Nayak wrote:
> > On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
> > >On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> > >>>Let's look at mc13892-regulator driver.
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
> How about the driver passing the of_node to be associated with the
> regulator, as part of regulator_desc, to the regulator core,
> instead of this complete DT search and the restriction of having
> to match DT node names with names
On Monday 24 October 2011 02:41 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
Okay, it's wrong then since so many people say it's wrong :) I guess
a quick fix would be adding one property in device tree
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 01:47 PM, Grant Likely wrote:
> >On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> >>On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >>>On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajend
On Thu, Oct 20, 2011 at 10:22:19AM -0700, Tony Lindgren wrote:
> * Tony Lindgren [111020 09:31]:
> >
> > That's where a DT entry specific configuration string might be the best
> > option as it still allows describing the hardware using DT standards,
> > while also allowing board specific configu
On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
> >Okay, it's wrong then since so many people say it's wrong :) I guess
> >a quick fix would be adding one property in device tree node for
> >matching some unique field in regula
On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 10:17:06AM +0200, Grant Likely wrote:
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote
On Monday 24 October 2011 01:47 PM, Grant Likely wrote:
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
[...]
+ /* find device_node and attach it */
+
On Mon, Oct 24, 2011 at 10:17:06AM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> > On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> > >On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
> > >[...]
> > >>>+ /* find device_node
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
> >[...]
> >>>+ /* find device_node and attach it */
> >>>+ rdev->dev.of_node = of_find_node_by_name(
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >Driver name does not matter. The key for this search to work is having
> >regulator's name (regulator_desc->name) match device tree node's name,
> >case ignored.
> Mark, what
On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
[...]
+ /* find device_node and attach it */
+ rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
so would this do a complete dt search for every
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
[...]
> >+ /* find device_node and attach it */
> >+ rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> so would this do a complete dt search for every regulator?
Yes, with the first param being NUL
Do you have any RFC patch/code which could explain better what you are
suggesting we do here?
Here is what I changed based on your patches. It only changes
drivers/regulator/core.c.
---8<---
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 9a5ebbe..8fe132d 100644
--
On Thu, Oct 20, 2011 at 05:39:32PM +0530, Rajendra Nayak wrote:
> On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
> >On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> >>>Let's look at mc13892-regulator driver. There are 23 regulators defined
> >>>in array mc13892_regulators.
* Mark Brown [111020 14:08]:
> On Thu, Oct 20, 2011 at 01:10:55PM -0700, Tony Lindgren wrote:
>
> > We still need to figure out how to get the above board specific
> > data to the device driver probe in a way where we can avoid having
> > platform glue code. Any thoughts on that?
>
> I think we
On Thu, Oct 20, 2011 at 01:10:55PM -0700, Tony Lindgren wrote:
> * Mark Brown [111020 12:23]:
> > I don't understand what an "arch independent DT node" would be?
> Well that's the standard non-Linux specific parts. Basically what's
> in the $Subject patch minus what you commented on earlier:
Oh
* Mark Brown [111020 12:23]:
> On Thu, Oct 20, 2011 at 10:22:19AM -0700, Tony Lindgren wrote:
>
> > Hmm, actually, can't we just pass the board specific configuration in
> > the board specific .dts file and then it gets merged in with the
> > arch independent DT node?
>
> I don't understand what
On Thu, Oct 20, 2011 at 10:22:19AM -0700, Tony Lindgren wrote:
> Hmm, actually, can't we just pass the board specific configuration in
> the board specific .dts file and then it gets merged in with the
> arch independent DT node?
I don't understand what an "arch independent DT node" would be?
--
On Thu, Oct 20, 2011 at 10:05:34AM -0700, Tony Lindgren wrote:
> Right, but in addition the board specific integration variables still
> need to be passed somehow to the driver.
I'm not sure you're aware of what the regulator bindings that are being
discussed are - they're entirely board specific
* Tony Lindgren [111020 09:31]:
>
> That's where a DT entry specific configuration string might be the best
> option as it still allows describing the hardware using DT standards,
> while also allowing board specific configuration too.
Hmm, actually, can't we just pass the board specific configu
* Mark Brown [111020 09:05]:
> On Thu, Oct 20, 2011 at 09:27:43AM -0700, Tony Lindgren wrote:
> > * Mark Brown [111020 02:07]:
>
> > > We can always start off just completely omitting the data and then see
> > > how we go from there. If we only cover 50% of users that's still 50%
> > > more tha
On Thu, Oct 20, 2011 at 09:27:43AM -0700, Tony Lindgren wrote:
> * Mark Brown [111020 02:07]:
> > We can always start off just completely omitting the data and then see
> > how we go from there. If we only cover 50% of users that's still 50%
> > more than are currently covered with device tree r
* Mark Brown [111020 02:07]:
> On Thu, Oct 20, 2011 at 09:12:10AM +0530, Rajendra Nayak wrote:
> > On Wednesday 19 October 2011 08:40 PM, Mark Brown wrote:
>
> > >I don't see any issue with leaving some things out of the DT bindings;
> > >you were the one raising that as a concern.
>
> > The pro
We can always start off just completely omitting the data and then see
how we go from there. If we only cover 50% of users that's still 50%
more than are currently covered with device tree right now and it means
we can then spin round and look at the bits that are hard again without
review fatig
On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
Let's look at mc13892-regulator driver. There are 23 regulators defined
in array mc13892_regulators. Needless to say, there is a dev behind
mc13892-regulator driver. And when
On Thu, Oct 20, 2011 at 09:12:10AM +0530, Rajendra Nayak wrote:
> On Wednesday 19 October 2011 08:40 PM, Mark Brown wrote:
> >I don't see any issue with leaving some things out of the DT bindings;
> >you were the one raising that as a concern.
> The problem is, that there doesn't seem to be a cle
On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> >Let's look at mc13892-regulator driver. There are 23 regulators defined
> >in array mc13892_regulators. Needless to say, there is a dev behind
> >mc13892-regulator driver. And when getting probed, this driver will
> >call regulat
I'm not sure why twl works in that way. Is it a sign that those
configuration peeked by twl regulator driver should be encoded in twl
regulator driver itself instead of being passed from the board? Or
No, the driver is just trying to make sure that nothing invalid (not
supported by hardware)
On Wednesday 19 October 2011 08:40 PM, Mark Brown wrote:
The problem is that the DT is supposed to be separate to the kernel and
the decisions can depend on what the kernel is currently capable of.
When the data is embedded in the kernel it's not an issue as the data is
attached to the rest of th
On Wed, Oct 19, 2011 at 11:04:49PM +0800, Shawn Guo wrote:
> On Wed, Oct 19, 2011 at 03:47:34PM +0100, Mark Brown wrote:
> > Only the board can come to a final decision.
> The dts is very capable and suitable to describe the board's decision.
> But you disagree that we put all constraints descrip
On Wed, Oct 19, 2011 at 03:47:34PM +0100, Mark Brown wrote:
> On Wed, Oct 19, 2011 at 01:33:55PM +0800, Shawn Guo wrote:
> > On Tue, Oct 18, 2011 at 05:00:46PM +0100, Mark Brown wrote:
>
> > > It's not just Linux-specific stuff, some of this is even specific to
> > > what current Linux drivers can
On Wed, Oct 19, 2011 at 10:42:16PM +0800, Shawn Guo wrote:
*Please* delete irrelevant quotes from mails.
> On Wed, Oct 19, 2011 at 05:05:56PM +0530, Rajendra Nayak wrote:
> > Yes, it seems like a good idea given that most drivers seem to blindly
> > pass the regulator_init_data onto regulator_re
On Wed, Oct 19, 2011 at 01:33:55PM +0800, Shawn Guo wrote:
> On Tue, Oct 18, 2011 at 05:00:46PM +0100, Mark Brown wrote:
> > It's not just Linux-specific stuff, some of this is even specific to
> > what current Linux drivers can do - updating the kernel could mean a
> > different set of constraint
On Wed, Oct 19, 2011 at 05:05:56PM +0530, Rajendra Nayak wrote:
> On Tuesday 18 October 2011 06:50 PM, Shawn Guo wrote:
> >On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> >>The helper routine is meant to be used by regulator drivers
> >>to extract the regulator_init_data structure
On Tuesday 18 October 2011 06:50 PM, Shawn Guo wrote:
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which
On Tue, Oct 18, 2011 at 05:00:46PM +0100, Mark Brown wrote:
> On Tue, Oct 18, 2011 at 07:58:37PM +0800, Shawn Guo wrote:
>
> > I understand that ideally device tree is supposed to describe pure
> > hardware configurations. But practically, when migrating a driver
> > to device tree probe, we are
On Tue, Oct 18, 2011 at 07:58:37PM +0800, Shawn Guo wrote:
> I understand that ideally device tree is supposed to describe pure
> hardware configurations. But practically, when migrating a driver
> to device tree probe, we are trying to move the configurations
> described by platform_data into de
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> The helper routine is meant to be used by regulator drivers
> to extract the regulator_init_data structure from the data
> that is passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
>
On Mon, Oct 17, 2011 at 09:47:17AM +0530, Rajendra Nayak wrote:
>
> >I do not see that of_get_regulation_constraints() covers the following
> >fields. We do not support them for DT probe?
>
> I left these out as I wasn't sure how such (if at all) Linux
> specific params should be passed through
I do not see that of_get_regulation_constraints() covers the following
fields. We do not support them for DT probe?
I left these out as I wasn't sure how such (if at all) Linux specific
params should be passed through dt, and I am still not quite sure :(
struct regulation_constraints {
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> The helper routine is meant to be used by regulator drivers
> to extract the regulator_init_data structure from the data
> that is passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
>
On Thu, Oct 13, 2011 at 12:38:21PM -0600, Grant Likely wrote:
> These *sound* like flags that the driver would set based on its own
> capabilities; in which case it is something that would be encoded
> directly into the driver.
They're almost entirely a combination of system specifics and softwar
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> The helper routine is meant to be used by regulator drivers
> to extract the regulator_init_data structure from the data
> that is passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
>
On Tue, Oct 11, 2011 at 11:29:29AM +0530, Rajendra Nayak wrote:
> On Monday 10 October 2011 10:52 PM, Mark Brown wrote:
> >On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> >
> >>+- regulator-change-voltage: boolean, Output voltage can be changed by
> >>software
> >>+- regulator-ch
On Monday 10 October 2011 10:52 PM, Mark Brown wrote:
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator-chan
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> +- regulator-change-voltage: boolean, Output voltage can be changed by
> software
> +- regulator-change-current: boolean, Output current can be chnaged by
> software
> +- regulator-change-mode: boolean, Operating mode can be chang
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
imp
74 matches
Mail list logo
