Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 16, 2011 at 12:54:18PM +0530, Rajendra Nayak wrote:
> On Friday 16 September 2011 03:42 AM, Grant Likely wrote:

> >However, I can imagine it possible for a regulator to have multiple
> >parents.  It may just be better to go with something like the gpio
> >scheme of<phandle gpio-specifier>  list of entries.  Or maybe just a
> >list of phandles would be sufficient.

> Ok, I can use phandles instead of the name, and have a list to specify
> multiple parents.
> The linux regulator framework though limits to just one parent I guess.

I think if we've got multiple parents they should be listed as named
supplies rather than as parents since it's probably important which is
which.  In fact we probably want to list all parents as supplies since
that's what they are, they just have special handling in the code due to
the recursion.

> >These map 1:1 to how Linux currently implements regulators; which
> >isn't exactly bad, but it means that even if Linux changes, we're
> >still have to support this binding.  Does this represent the best
> >layout for high level description of regulators?

> I guess, except for some like apply-uV, which like Mark pointed
> out are very linux/runtime policy specific.
> Mark, what do you think?

Yes, overall this feels far too direct.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux