Re: [RFC PATCH] regulator: virtual: Introduce a new virtual locker regulator type

[Doug Anderson]

Mark,

On Wed, Apr 30, 2014 at 6:28 PM, Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Wed, Apr 30, 2014 at 11:56:08AM -0700, Doug Anderson wrote:
>
>> I cornered Rob and Mark Rutland a little bit about this at ELC today
>> (sorry!).  Neither of them was a huge ran of adding a pseudo device.
>> Rob suggested that Mark Brown might be the best person to give
>> direction here.  Mark Brown: any thoughts?
>
> I glanced at this briefly and couldn't really understand what it was
> supposed to do from a quick glance but I do tend to agree that it's too
> complex and confusing.  Quite what the virtual regulator is supposed to
> represent or how it is used is distinctly non-obvious.

>From my understanding, there are parts internal to the SoC where
something powered by the INT rail looks at an signal based on the ARM
rail, or vice versa.  If the two voltages are too vastly different
then you get into trouble.

To put numbers imagine the ARM rail at 1300 mV and the INT rail at 875
mV.  Something powered by the ARM rail will be looking at a signal,
and perhaps it decides that signals that are >= 1000 mV are high and
signals that are < 1000 mV are low.  If the INT rail is 875 mV then it
will never be able to signal a high.

The ARM and INT rails scale independently of each other.  The ARM rail
increases when the CPU frequency need to be fast.  The INT rail
increases when some internal peripherals on the system need to run
fast.  Imagine you're doing hardware assisted video decoding: you'd
want INT high and ARM low.  Imagine that you're running a
CPU-intensive game: you want INT low and ARM high.

The "solution" to the above (without redoing the SoC) is to make sure
that the INT and ARM rails are always within 300mV of each other.


>> Potentially we could also make this type of thing a core regulator property:
>
> Yes, that seems like the obvious solution if it's in the core.  Someone
> would need to write the code of course.

OK.  Inderpal: is this something you're willing to do?  I'd imagine
that all of the core code should remain the same, it's just a matter
of hooking it up properly.

Mark Brown: did the bindings above seem sane to you?  I can clean them
up a bit and explain more:

  buck2_reg: BUCK2 {
          regulator-name = "vdd_arm";
          regulator-min-microvolt = <800000>;
          regulator-max-microvolt = <1500000>;
          regulator-always-on;
          regulator-boot-on;
          regulator-op-mode = <1>;
          regulator-ramp-delay = <12500>;
          regulator-lock-to = <&buck3_reg>;
          regulator-lock-within-microvolt = <300000>;
 };
  buck3_reg: BUCK3 {
          regulator-name = "vdd_int";
          regulator-min-microvolt = <800000>;
          regulator-max-microvolt = <1400000>;
          regulator-always-on;
          regulator-boot-on;
          regulator-op-mode = <1>;
          regulator-ramp-delay = <12500>;
          regulator-lock-to = <&buck2_reg>, <&buck9_reg>;
          regulator-lock-within-microvolt = <300000>, <200000>;
  };

- regulator-lock-to: A list of regulators to monitor.  If they ever
are greater than our voltage + the corresponding "lock-within" then we
should bump up our voltage.  We'll bump back down if/when the
monitored regulator falls again.

- regulator-lock-within-microvolt: A list of microvolt values that
correspond to a phandle in the "regulator-lock-to" list.

Note that the above specification makes the locking a single
direction.  If it needs to be bidirectional you specify it in both
regulators.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/