Re: [PATCHv3 2/2] dt-bindings: regulator: Add regulator suspend state for PM state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, Aug 14, 2014 at 09:40:14AM +0900, Chanwoo Choi wrote:

> +- regulator-initial-state: initial state for suspend state, cnd set initial
> +  state among following defined suspend states:
> +  <2>: PM_SUSPEND_STANDBY - Setup regulator according to regulator-state-standby
> +  <3>: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem
> +  <4>: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk
> +- regulator-state-standby sub-root node for Standby mode
> +  : the device is in a power-saving state, but can also receive certain events,
> +  specific behavior depends on the specific device.

These are all Linux internal descriptions of the states but the device
tree is supposed to be OS neutral.  For suspend to memory and suspend to
disk that's probably adequately clear but _STANDBY is really unclear.
I would suggest just dropping this without a clearer defintion, it's
something that I'd expect to emerge organically from low power modes
rather than having a specific definition anyway.

> +- regulator-state-[standby/mem/disk] node has following common properties:
> +	- regulator-volt: voltage consumers may set in suspend state.
> +	- regulator-mode: voltage mode in suspend state, can set mode among
> +	following defined regulator modes:
> +	0x1: REGULATOR_MODE_FAST, Regulator can handle fast changes.
> +	0x2: REGULATOR_MODE_NORMAL, Normal regulator power supply mode.
> +	0x4: REGULATOR_MODE_IDLE, Regulator runs in a more efficient mode.
> +	0x8: REGULATOR_MODE_STANDBY, Regulator runs in the most efficient mode.
> +	- regulator-on-in-suspend: regulator should be on in suspend state.
> +	- regulator-off-in-suspend: regulator should be off in suspend state.
> +	If node don't include regulator-[on/off]-in-suspend, can't change
> +	regulator state in suspend mode and only should sustain the regulator
> +	state of normal state.

Modes are a similarly problematic thing - their definition is really
unclear even within Linux and we don't support them at all at present.
I'd just drop them initially and then add them in as a part of adding
mode support in general.

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux