[PATCH 2/3] arm64: smp: Implement cpus_has_pending_ipi()
Ulf Hansson
ulf.hansson at linaro.org
Fri Oct 10 01:03:47 PDT 2025
On Mon, 6 Oct 2025 at 16:41, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> On Mon, Oct 06, 2025 at 02:22:49PM +0200, Ulf Hansson wrote:
> > On Mon, 6 Oct 2025 at 12:54, Sudeep Holla <sudeep.holla at arm.com> wrote:
> > >
> > > 2. I understand this is intended for the DragonBoard 410c, where the firmware
> > > can’t be updated. However, ideally, the PSCI firmware should handle checking
> > > for pending IPIs if that’s important for the platform. The firmware could
> > > perform this check at the CPU PPU/HW level and prevent entering the
> > > state if needed.
> >
> > I think this is exactly what is happening on Dragonboard 410c (see the
> > stats I shared in the commit message in patch3).
> >
> > The PSCI FW refuses to enter the suggested idlestate and the call fails.
> >
>
> Ah OK, the PSCI FW is doing the job correctly, we are just attempting to
> reduce the failures by catching few cases earlier in the OSPM itself ?
Correct!
> Sure it only reduces the failures but it can't eliminate those as IPI might
> be issued after this check in the OSPM. I understand the call to firmware
> can be prevented.
Yes!
Although, it seems we are ending up doing a ping-pong game with the
FW. Note that, if the FW responds with an error because we have tried
to enter an idlestate for a group of CPUs, nothing prevents idling the
CPU again and hence we might re-try with the same idlestate (at least
until the pending IPI gets delivered).
My point is, this problem seems not negligible, as you can see from
the stats I have shared in the commit message of patch3.
Kind regards
Uffe
More information about the linux-arm-kernel
mailing list