[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGAzgso=NqNmJtRHWxzxjtiXRtT7aBYcwGHMxGmEirMY5DkhJw@mail.gmail.com>
Date: Wed, 7 Feb 2018 18:59:38 -0800
From: "dbasehore ." <dbasehore@...omium.org>
To: Marc Zyngier <marc.zyngier@....com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Soby Mathew <Soby.Mathew@....com>,
Sudeep Holla <sudeep.holla@....com>,
devicetree@...r.kernel.org, robh+dt@...nel.org,
Mark Rutland <mark.rutland@....com>,
Linux-pm mailing list <linux-pm@...r.kernel.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Brian Norris <briannorris@...omium.org>
Subject: Re: [PATCH v5 3/4] DT/arm,gic-v3-its: add reset-on-suspend property
On Wed, Feb 7, 2018 at 1:21 AM, Marc Zyngier <marc.zyngier@....com> wrote:
> On 07/02/18 01:41, Derek Basehore wrote:
>> This adds documentation for the new reset-on-suspend property. This
>> property enables saving and restoring the ITS for when it loses state
>> in system suspend.
>>
>> Signed-off-by: Derek Basehore <dbasehore@...omium.org>
>> ---
>> Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
>> index 0a57f2f4167d..a470147d4f14 100644
>> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
>> @@ -78,6 +78,9 @@ These nodes must have the following properties:
>> Optional:
>> - socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated
>> address and size of the pre-ITS window.
>> +- reset-on-suspend: Boolean property. Indicates that the ITS state is
>> + reset on suspend. The state is then saved on suspend and restored on
>> + resume.
>
> By whom? It is important to be clear about the respective
> responsibilities, as this forms a binding contract between firmware and OS.
>
> Mark: Can you have a look at how to formulate this? I'm not sure we have
> other instances of a non-architected behaviour involving FW
> participation, aside from PSCI.
I'll wait for Mark's reply to reword this.
>
>>
>> The main GIC node must contain the appropriate #address-cells,
>> #size-cells and ranges properties for the reg property of all ITS
>>
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists