[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180912140102.GJ5662@atomide.com>
Date: Wed, 12 Sep 2018 07:01:02 -0700
From: Tony Lindgren <tony@...mide.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Keerthy <j-keerthy@...com>, mark.rutland@....com,
robh+dt@...nel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
t-kristo@...com
Subject: Re: [PATCH] dt-bindings: power: Introduce suspend states supported
properties
* Sudeep Holla <sudeep.holla@....com> [180912 13:47]:
>
>
> On 12/09/18 14:32, Tony Lindgren wrote:
> > * Sudeep Holla <sudeep.holla@....com> [180912 11:41]:
> >> On 12/09/18 12:19, Keerthy wrote:
> >>> suspend to mem and suspend to disk are pretty generic states and i agree
> >>> implementation is platform dependent so why not have properties that
> >>> convey if they are supported?
> >>>
> >>
> >> We already have power domains and idle states for that. If you need to
> >> restrict few states on some platform for whatever reasons, just disable
> >> those states. I don't see the need to add any more bindings for the same.
> >
> > Oh do you mean the "domain-idle-states" property as mentioned in the
> > Documentation/devicetree/bindings/power/power_domain.txt?
> >
>
> Yes, exactly that.
OK
> > Yeah that should do and the DOMAIN_PWR_DN and DOMAIN_RET can be SoC
> > specific and then the board can select which ones to use depending on
> > how things are wired for GPIOs, memory, PMIC and so on.
> >
>
> All the idle-states are platform specific. DOMAIN_RET and DOMAIN_PWR_DN
> are just examples used in the bindings.
>
> > Hmm I don't see any users for this binding though?
> >
>
> It was added specifically to deal with such SoC idles states or
> hierarchical CPU power domains states, no users in upstream yet. But IMO
> it fits what $subject is trying to address.
OK great thanks for confirming that.
Regards,
Tony
Powered by blists - more mailing lists