On 09/22/2017 06:57 AM, Linus Walleij wrote:

On Fri, Sep 22, 2017 at 3:20 PM, Charles Keepax
[off-list ref] wrote:

quoted

On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:

quoted

quoted

Next point, this commit from Baolin:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt?id=6606bc9dee63ad8cda2cc310d2ad5992673a785a

output-low - set the pin to output mode with low level
output-high - set the pin to output mode with high level
+sleep-hardware-state - indicate this is sleep related state which
will be programmed
+ into the registers for the sleep state.
slew-rate - set the slew rate

This is another thing: here we are defining a state that will be managed
by autonomous hardware. The state settings will be poked into some
special registers that will automatically take effect when the system
goes into sleep.

This is a hardware-induced state: the SLEEP line for the entire SoC
is asserted.

Just to make sure I understand this property is used to specify a
pinctrl state that will be automatically applied by the hardware when
entering suspend?

Yes. It is quite common in SoCs, we just never supported it properly.

This appears to be solving another possible problem/feature with pin
controllers during suspend, which is not exactly what I am after here.

Unless we generalize this into a state of some kind, which would
de-facto force a state transition in pinctrl_select_state() because
p->default != state, then I am not sure this how that is related to the
problem space exposed earlier.

quoted

Kind of an odd one, feels like something you
could just have the software apply as part of the suspend
process.

Not really. It has special registers just for this purpose,
and the driver is completely unaware that sleep is happening,
instead it is driven to the hardware by special hardware sleep
lines inside the SoC. So it needs to be set up when the default
state is programmed.

quoted

Almost would have wondered should this be a driver
specific binding rather than a generic pinctrl one?

No, I've seen it in several hardwares. (The Nomadik pin controller
has this too.)

quoted

I guess from looking at the driver using this I assume that said
hardware also automatically replies the non-sleep settings on
resume?

Yep.

Yours,
Linus Walleij

-- 
Florian