Re: [GICv3 ITS]S2IDLE framework does not invoke syscore_ops in GICv3 ITS driver

[Marc Zyngier <maz@kernel.org>]

On Wed, 02 Apr 2025 11:57:31 +0100,
Ulf Hansson <ulf.hansson@linaro.org> wrote:
> 
> On Tue, 1 Apr 2025 at 15:11, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 01 Apr 2025 13:45:43 +0100,
> > Ulf Hansson <ulf.hansson@linaro.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.