lkml.org 
[lkml]   [2017]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a state
From
Date
On 09/22/2017 06:57 AM, Linus Walleij wrote:
> On Fri, Sep 22, 2017 at 3:20 PM, Charles Keepax
> <ckeepax@opensource.cirrus.com> 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

\
 
 \ /
  Last update: 2017-09-25 21:20    [W:0.110 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site