On 11.01.2019 14:39, Mark Brown wrote:
> On Thu, Jan 10, 2019 at 10:24:26AM +0000, claudiu.bez...@microchip.com wrote:
>> On 09.01.2019 18:57, Mark Brown wrote:
>
>>> regulator state which feels fragile. But based on the cover letter
>>> that's kind of like what the initial proposal about target states was so
>>> perhaps this is the way we end up going...
>
>> Are you talking about [1] ?
>
> I can't follow that link right now, I'm working offline.
>
>> I can get rid of this patch, take advantage of [3] and [4] and introduce
>> also the regulator standby states. In this case, no matter the mapping b/w
>> Linux power saving modes and AT91 SoC's power saving modes, we will be
>> covered on misconfiguration (at least on SAMA5D2 Xplained board).
>
>> And in patch 3/3 I could get rid of regulator checks and rely on DT (bad
>> thing would be that in case of no input for regulator's state in
>> mem/standby the board could not properly suspended/resumed), if any.
>
>> What do you think about this?
>
> Like I say I'm working offline so I can't check the links but it sounds
> like you're saying that the existing suspend mode configuration features
> are enough for your systems?
Yes, if we rely on the fact that core's regulator device tree bindings for
suspend-to-mem/suspend-to-standby were filled correctly.
The function I added here was to double check that core's regulator will be
off in suspend/standby based on what was parsed from DT.
Thank you,
Claudiu Beznea
> so that's great - certainly what you're
> saying above sounds sensible to me but it's possible I misunderstood
> something based on not having the links.
>
