From: Marc Zyngier <marc.zyngier@arm.com>
To: "dbasehore ." <dbasehore@chromium.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
sudeep.holla@arm.com,
Linux-pm mailing list <linux-pm@vger.kernel.org>
Subject: Re: Save and Restore Generic Interrupt Controller for System Sleep on ARM
Date: Wed, 06 Dec 2017 09:48:16 +0000 [thread overview]
Message-ID: <87vahk6vbz.fsf@on-the-bus.cambridge.arm.com> (raw)
In-Reply-To: <CAGAzgspYoDwbmj+cXWQJcUmmGZshQ95-a-8gBNOtxT8L2Qm-VQ@mail.gmail.com> (dbasehore .'s message of "Thu, 30 Nov 2017 17:21:20 -0800")
On Thu, Nov 30 2017 at 5:21:20 pm GMT, "dbasehore ." <dbasehore@chromium.org> wrote:
> On Thu, Nov 30, 2017 at 1:44 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On Wed, Nov 29 2017 at 2:49:18 pm GMT, "dbasehore ."
>> <dbasehore@chromium.org> wrote:
>>> There was some work in ARM Trusted Firmware to support saving and
>>> restoring the Generic Interrupt Controller (GICv3) before and after
>>> sleep, but it seems that the plan is to have this all in the kernel
>>> now. The point of doing this is to save power during sleep. On an
>>> RK3399 system, we save about 15mW by disabling the power rail that the
>>> GIC is on.
>>>
>>> I was looking for whether anyone had anything in progress already or
>>> for preferences on how to do this. Marc suggested using a device tree
>>> entry to indicate the need to save and restore the GIC. There is
>>> another requirement to resend MAPC commands on certain implementations
>>> of the GICv3 which could be indicated by another device tree entry.
>>
>> Let's be precise: This is a GIC-500 requirement, and not something that
>> the GICv3 architecture defines (PM is *not* part of the GICv3
>> architecture).
>>
>
> Just to double check, do the register restores apply to all GICv3
> designs? If so, I can put that code in the gic-v3 code instead of
> breaking it out.
I would keep it GIC-500 specific for the time being. But that code
should live in the GICv3 driver, gated on the IIDR registers and some
form of firmware negotiation.
Again, it will be much easier to comment on this when we see the
code. So far, I feel a bit uneasy talking mostly hypothetically.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
prev parent reply other threads:[~2017-12-06 9:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 22:49 Save and Restore Generic Interrupt Controller for System Sleep on ARM dbasehore .
2017-11-30 9:44 ` Marc Zyngier
2017-12-01 1:21 ` dbasehore .
2017-12-06 9:48 ` Marc Zyngier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vahk6vbz.fsf@on-the-bus.cambridge.arm.com \
--to=marc.zyngier@arm.com \
--cc=dbasehore@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox