[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875xjlzpe7.wl-maz@kernel.org>
Date: Thu, 03 Apr 2025 08:16:00 +0100
From: Marc Zyngier <maz@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Youngmin Nam <youngmin.nam@...sung.com>,
Thomas Gleixner <tglx@...utronix.de>,
Saravana Kannan <saravanak@...gle.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
kernel-team@...roid.com,
hajun.sung@...sung.com,
d7271.choe@...sung.com,
joonki.min@...sung.com
Subject: Re: [GICv3 ITS]S2IDLE framework does not invoke syscore_ops in GICv3 ITS driver
On Wed, 02 Apr 2025 11:57:31 +0100,
Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Tue, 1 Apr 2025 at 15:11, Marc Zyngier <maz@...nel.org> wrote:
> >
> > On Tue, 01 Apr 2025 13:45:43 +0100,
> > Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > >
> > > Assuming we can make the code for saving/restoring generic (not in FW)
> > > and that we are able to make sure the code is only executed for those
> > > platforms and states that really need it. Do you think there would
> > > there be any other drawback for doing this?
> >
> > Yes. We'd end-up having to implement all sort of split PM schemes
> > depending on the GIC implementation, what the firmware does, the
> > various braindead assumptions that the integration makes, and other
> > parameters I don't even want to consider.
>
> I don't think it needs to be that complicated, at all. But let's not
> discuss the solution at this point, at least for me, that's too early.
>
> However, I do understand your concerns and share them.
>
> >
> > The GIC power management is, for better or worse, *outside* of the
> > scope of the architecture. Most of it is implementation defined,
> > because each and every implementer/vendor sees it as added value to
> > invent their own particular flavour of crap. For example, there is no
> > provision for wake-up interrupts, because nobody can agree on how
> > that's supposed to work.
>
> Right. I guess it falls in the SoC specific area and we need to live
> with it, for now.
>
> Anyway, the main reason why I joined the discussion is exactly because
> of this. I have been working on enabling the same deep state for
> s2idle as the one that corresponds to s2ram for some legacy arm64
> platforms. To allow the system to wake up properly from this deep
> state, I needed to save/restore these types of GIC registers.
Or not. I will *NOT* entertain SoC-specific code in the GIC drivers
for anything that isn't a workaround for a functional erratum.
>
> I intend to post a complete series for this soonish. It should show
> what is needed for a particular SoC in this regard. I will keep you
> posted.
>
> >
> > Do we want to deal with this in the various GIC drivers? No. It is the
> > job of firmware to manage this mess, because this clearly delineates
> > where the responsibilities lie.
>
> The FW could deal with this, but that would only work for platforms
> with new or upgrade-able FW, which is not the case for these legacy
> platforms that I am working on.
Then these platforms can die and be pruned from the tree, or live with
a sub-par power management.
> Moreover, we already implement the save/restore for some GIC variants
> - and in some cases using different ways to do it. In my opinion it
> would be nice to have a common solution that would only be enabled for
> the states/platforms that really need it. In the series above I will
> try to implement this, let's see if I can make it.
The solution is firmware. It's been advertised as such for over 10
years, and GICv5 doesn't change this. We spent years *removing* that
crap from the irqchip subsystem so that we could have something
manageable. I'm not going to go back in time for the sake of shit HW.
M.
--
Jazz isn't dead. It just smells funny.
Powered by blists - more mailing lists