On Fri, Sep 22, 2017 at 3:20 PM, Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote: >> 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. > 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. > 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.) > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
