The regulators state during a system wide low power state can currently
only be described in platform data. Add the option to configure them
from the device tree.
Signed-off-by: Vincent Palatin <[email protected]>
---
.../devicetree/bindings/regulator/regulator.txt | 6 +++++
drivers/regulator/of_regulator.c | 31 ++++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 48a3b8e..e259b43 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -10,6 +10,12 @@ Optional properties:
- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator
- regulator-allow-bypass: allow the regulator to go into bypass mode
+- regulator-suspend-disk-microvolt: voltage applied when entering S2D
+- regulator-suspend-disk-disabled: turn off when entering S2D
+- regulator-suspend-mem-microvolt: voltage applied when entering S2M
+- regulator-suspend-mem-disabled: turn off when entering S2M
+- regulator-suspend-standby-microvolt: voltage applied when entering standby
+- regulator-suspend-standby-disabled: turn off when entering standby
- <name>-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index f3c8f8f..4abc18c 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -21,6 +21,7 @@ static void of_get_regulation_constraints(struct device_node *np,
{
const __be32 *min_uV, *max_uV, *uV_offset;
const __be32 *min_uA, *max_uA, *ramp_delay;
+ const __be32 *state_disk_uV, *state_mem_uV, *state_standby_uV;
struct regulation_constraints *constraints = &(*init_data)->constraints;
constraints->name = of_get_property(np, "regulator-name", NULL);
@@ -67,6 +68,36 @@ static void of_get_regulation_constraints(struct device_node *np,
ramp_delay = of_get_property(np, "regulator-ramp-delay", NULL);
if (ramp_delay)
constraints->ramp_delay = be32_to_cpu(*ramp_delay);
+
+ /* regulator state for suspend to disk */
+ state_disk_uV = of_get_property(np, "regulator-suspend-disk-microvolt",
+ NULL);
+ if (state_disk_uV) {
+ constraints->state_disk.uV = be32_to_cpu(*state_disk_uV);
+ constraints->state_disk.enabled = true;
+ }
+ if (of_find_property(np, "regulator-suspend-disk-disabled", NULL))
+ constraints->state_disk.disabled = true;
+
+ /* regulator state for suspend to RAM */
+ state_mem_uV = of_get_property(np, "regulator-suspend-mem-microvolt",
+ NULL);
+ if (state_mem_uV) {
+ constraints->state_mem.uV = be32_to_cpu(*state_mem_uV);
+ constraints->state_mem.enabled = true;
+ }
+ if (of_find_property(np, "regulator-suspend-mem-disabled", NULL))
+ constraints->state_mem.disabled = true;
+
+ /* regulator state for standby */
+ state_standby_uV = of_get_property(np,
+ "regulator-suspend-standby-microvolt", NULL);
+ if (state_standby_uV) {
+ constraints->state_standby.uV = be32_to_cpu(*state_standby_uV);
+ constraints->state_standby.enabled = true;
+ }
+ if (of_find_property(np, "regulator-suspend-standby-disabled", NULL))
+ constraints->state_standby.disabled = true;
}
/**
--
1.8.3
On Thu, Jul 25, 2013 at 12:42:00PM -0700, Vincent Palatin wrote:
> +- regulator-suspend-disk-microvolt: voltage applied when entering S2D
> +- regulator-suspend-disk-disabled: turn off when entering S2D
> +- regulator-suspend-mem-microvolt: voltage applied when entering S2M
> +- regulator-suspend-mem-disabled: turn off when entering S2M
> +- regulator-suspend-standby-microvolt: voltage applied when entering standby
> +- regulator-suspend-standby-disabled: turn off when entering standby
The reason this isn't in device tree at the minute is that suspend to
disk and suspend to RAM are somewhat Linux specific concepts and the
whole thing gets more and more dynamic as time moves forwards with the
suspend state for practical systems depending on the instantaneous
device state prior to entering suspend and the bits that are fixed often
involving sequencing elements and so on which get fixed in hardware
and/or bootloader. Do you have practical systems where this is needed?
It's also not clear to me hat the -disabled properties make sense; if we
have properties for the state when enabled I'd expect them to allow
things to be marked as enabled or disabled (with don't touch as the
default).
On Thu, Jul 25, 2013 at 1:03 PM, Mark Brown <[email protected]> wrote:
> On Thu, Jul 25, 2013 at 12:42:00PM -0700, Vincent Palatin wrote:
>
>> +- regulator-suspend-disk-microvolt: voltage applied when entering S2D
>> +- regulator-suspend-disk-disabled: turn off when entering S2D
>> +- regulator-suspend-mem-microvolt: voltage applied when entering S2M
>> +- regulator-suspend-mem-disabled: turn off when entering S2M
>> +- regulator-suspend-standby-microvolt: voltage applied when entering standby
>> +- regulator-suspend-standby-disabled: turn off when entering standby
>
> The reason this isn't in device tree at the minute is that suspend to
> disk and suspend to RAM are somewhat Linux specific concepts and the
> whole thing gets more and more dynamic as time moves forwards with the
> suspend state for practical systems depending on the instantaneous
> device state prior to entering suspend and the bits that are fixed often
> involving sequencing elements and so on which get fixed in hardware
> and/or bootloader. Do you have practical systems where this is needed?
Yes, on a Chromebook machine, an internal USB device power rail is
connected to one of the FET of a TPS65090,
the device is leaking power in suspend-to-RAM, it would be nice to cut
the FET during suspend.
> It's also not clear to me hat the -disabled properties make sense; if we
> have properties for the state when enabled I'd expect them to allow
> things to be marked as enabled or disabled (with don't touch as the
> default).
you mean declaring an optional (string) property such as :
regulator-suspend-mem-state
which can take the value "enabled" or "disabled"
e.g.
power-regulator {
compatible = "ti,tps65090";
reg = <0x48>;
voltage-regulators {
VFET4 {
regulator-name = "usb_leaker";
regulator-suspend-mem-state = "disabled";
};
};
};
On Fri, Jul 26, 2013 at 09:06:56AM -0700, Vincent Palatin wrote:
> > The reason this isn't in device tree at the minute is that suspend to
> > disk and suspend to RAM are somewhat Linux specific concepts and the
> > whole thing gets more and more dynamic as time moves forwards with the
> > suspend state for practical systems depending on the instantaneous
> > device state prior to entering suspend and the bits that are fixed often
> > involving sequencing elements and so on which get fixed in hardware
> > and/or bootloader. Do you have practical systems where this is needed?
> Yes, on a Chromebook machine, an internal USB device power rail is
> connected to one of the FET of a TPS65090,
> the device is leaking power in suspend-to-RAM, it would be nice to cut
> the FET during suspend.
So this isn't powered off through a combination of the normal suspend
process and strap/bootloader configuration of the PMIC?
> you mean declaring an optional (string) property such as :
> regulator-suspend-mem-state
> which can take the value "enabled" or "disabled"
I'd probably go with an optional boolean property but yes. Suspend to
disk is relatively clear but I'm rather nervous about suspend to RAM
here.
On Thursday 25 of July 2013 21:03:43 Mark Brown wrote:
> On Thu, Jul 25, 2013 at 12:42:00PM -0700, Vincent Palatin wrote:
> > +- regulator-suspend-disk-microvolt: voltage applied when entering S2D
> > +- regulator-suspend-disk-disabled: turn off when entering S2D
> > +- regulator-suspend-mem-microvolt: voltage applied when entering S2M
> > +- regulator-suspend-mem-disabled: turn off when entering S2M
> > +- regulator-suspend-standby-microvolt: voltage applied when entering
> > standby +- regulator-suspend-standby-disabled: turn off when entering
> > standby
> The reason this isn't in device tree at the minute is that suspend to
> disk and suspend to RAM are somewhat Linux specific concepts and the
> whole thing gets more and more dynamic as time moves forwards with the
> suspend state for practical systems depending on the instantaneous
> device state prior to entering suspend and the bits that are fixed often
> involving sequencing elements and so on which get fixed in hardware
> and/or bootloader. Do you have practical systems where this is needed?
We do have such boards at Samsung. Actually I made a similar patch for our
internal tree.
> It's also not clear to me hat the -disabled properties make sense; if we
> have properties for the state when enabled I'd expect them to allow
> things to be marked as enabled or disabled (with don't touch as the
> default).
+1
Best regards,
Tomasz
On Fri, Jul 26, 2013 at 10:54:10PM +0200, Tomasz Figa wrote:
> > The reason this isn't in device tree at the minute is that suspend to
> > disk and suspend to RAM are somewhat Linux specific concepts and the
> > whole thing gets more and more dynamic as time moves forwards with the
> > suspend state for practical systems depending on the instantaneous
> > device state prior to entering suspend and the bits that are fixed often
> > involving sequencing elements and so on which get fixed in hardware
> > and/or bootloader. Do you have practical systems where this is needed?
> We do have such boards at Samsung. Actually I made a similar patch for our
> internal tree.
Do you have more details on what exactly is happening with this stuff
and why it isn't dynamic. Like I say suspend to disk seems relatively
easy but suspend to RAM gets a bit tricky these days.