On 09/22/2017 06:57 AM, Linus Walleij wrote: > 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. 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. > >> 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 > -- Florian -- 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
