Hi Mark,

On Fri, Feb 05, 2016 at 03:32:58PM +0000, Mark Brown wrote:

On Fri, Feb 05, 2016 at 03:33:28PM +0100, Maxime Ripard wrote:

quoted

On Thu, Jan 21, 2016 at 04:28:02PM +0000, Mark Brown wrote:

quoted

On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote:

quoted

quoted

quoted

Anyway, I'm fine with both approaches, just let me know what you
prefer.

quoted

quoted

Without seeing an implementation of the lists it's hard to say.

quoted

Just to make sure we're on the same page: you want to keep the
regulator, but instead of giving the parent through vinX-supplies
properties, you want to have a single *-supply property, with a list
of regulators, right?

Either that or an explicit regulator describing the merge.  Rob wants
the list I think but I really don't care.

So, I'm reviving this old thread after speaking to you about it at
ELCE and trying to code something up, and getting lost..

To put a bit of context, I'm still trying to tackle the issue of
devices that have two regulators powering them on the same pin for
example when each regulator cannot provide enough current alone to
power the device (all the setups like this one I've seen so far were
for WiFi chips, but it might be different).

I guess we already agreed on the fact that the DT binding should just
be to allow a *-supply property to take multiple regulators, and mark
them as "coupled" (or whatever name we see fit) in such a case.

Since regulator_get returns a struct regulator pointer, it felt
logical to try to add the list of parent regulators to it, especially
as this structure is per-consumer, and different consumers might have
different combinations of regulators.

However, this structure embeds a pointer to a struct regulator_dev,
which seems to model the regulator itself, but will also contain
pointer to the struct regulator, probably to model its parent? I guess
my first question would be do we care about nesting? or having a
regulator with multiple parents?

It also contains the constraints on each regulator, which might or
might not be different for each of the coupled regulators, but I'm
guessing the couple might have contraints of its own too I guess. Is
it something that might happen? Should we care about it?

And finally, my real question is, do we want to aggregate them in
struct regulator, at the consumer level, which might make the more
sense, or do we want to create an intermediate regulator internally?
What is your take on this?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com