Re: [PATCH 1/4] devicetree: add a binding for a regulator that constrains its supply

[Alban Bedel]

On Mon, 24 Nov 2014 15:15:27 +0000
Mark Brown <broonie@xxxxxxxxxx> wrote:

> On Mon, Nov 24, 2014 at 02:02:00PM +0100, Alban Bedel wrote:
> 
> > +Constrained Supply Regulator
> > +
> > +This binding allow creating a virtual regulator that constrain its
> > +supply to provides the requested voltage. This is to allow using
> > +simple drivers that don't explicitly request a voltage on boards
> > +that have adjustable hardware regulators.
> > +
> > +Required properties:
> > +- compatible : Must be "regulator-constrained-supply".
> > +- vin-supply : phandle to the parent supply/regulator node
> 
> Reading this description I'm at a loss to explain what this is intended
> to achieve - it's obviously not describing hardware which is a rather
> large alarm bell and I don't really understand why the constraints
> wouldn't be set on the parent regulator.

Yes, it is not real hardware. The use case is a generic base board with
one regulator for add-on boards that has a settable voltage output. In
the base board DTS the regulator constraints represent the whole range
that the regulator is capable of, for example 1V to 12V.

Using this driver the DTS for the add-on board can further constrain
this supply to get the voltage it need, for example 3.3V. I understand
that normally the drivers for the consumers on the add-on board should
do this, however I don't really see how that is possible with generic
drivers like simple-panel. Such driver target a large range of
hardware, so just setting an  arbitrary voltage doesn't make much sense.
Furthermore even driver that target a specific hardware usually don't
set a voltage and in many case they couldn't do it without some
knowledge of the board design.

I saw 3 ways to solve this problem:

1) This, use a "filter" regulator
2) Extend each and every driver that use a voltage regulator to
   optionally set the voltage
3) Include the required range in the phandle reference

#1 was the easiest :) #2 doesn't seems practical to me, #3 seems pretty
good but I'm really not sure if that would be acceptable.

Alban

Attachment: signature.asc
Description: PGP signature