Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

[Doug Anderson <dianders@chromium.org>]

Hi,

On Wed, May 30, 2018 at 8:02 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 07:46:50AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 2:37 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> >> Linux vote for the lowest voltage it's comfortable with.  Linux keeps
>> >> track of the true voltage that the driver wants and will always change
>> >> its vote back to that before enabling.  Thus (assuming Linux is OK
>> >> with 1.2 V - 1.4 V for a rail):
>
>> > That's pretty much what it should do anyway with normally designed
>> > hardware.
>
>> I guess the question is: do we insist that the driver include this
>> workaround, or are we OK with letting the hardware behave as the
>> hardware does?
>
> What you're describing sounds like what we should be doing normally, if
> we're not doing that we should probably be fixing the core.

I'm not convinced that this behavior makes sense to move to the core.
On most regulators I'd expect that when the regulator driver says to
turn them off that they will output no voltage.  The reason RPMh is
special is that there's an aggregation outside of Linux.  Specifically
I like to make it concrete use the example where both Linux and "the
modem" make requests for the same regulator and RPMh aggregates these
requests.  This aggregation happens separately for "enabled" and
"voltage".

Thus if you consider:
Modem: vote for 1.3V and enabled=true
Linux: vote for 1.4V and enabled=false

The aggregated voltage is 1.4V and the aggregated enabled is true.
Said another way: Linux's vote for the voltage affected the state of
the rail even though Linux wanted the rail disabled.

In any other system when Linux disabled the regulator it wouldn't
matter that you left it set at 1.4V.  Thus RPMh is special and IMO the
workaround belongs there.


-Doug