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
