[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4811a5e1df589573a27771749a68d34@kernel.org>
Date: Wed, 30 Aug 2023 15:07:35 +0100
From: Marc Zyngier <maz@...nel.org>
To: Oza Pawandeep <quic_poza@...cinc.com>
Cc: sudeep.holla@....com, catalin.marinas@....com, will@...nel.org,
rafael@...nel.org, lenb@...nel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org
Subject: Re: [PATCH v3] cpuidle, ACPI: Evaluate LPI arch_flags for broadcast
timer
On 2023-08-29 21:11, Oza Pawandeep wrote:
> ArmĀ® Functional Fixed Hardware Specification defines LPI states,
> which provide an architectural context loss flags field that can
> be used to describe the context that might be lost when an LPI
> state is entered.
>
> - Core context Lost
> - General purpose registers.
> - Floating point and SIMD registers.
> - System registers, include the System register based
> - generic timer for the core.
> - Debug register in the core power domain.
> - PMU registers in the core power domain.
> - Trace register in the core power domain.
> - Trace context loss
> - GICR
> - GICD
>
> Qualcomm's custom CPUs preserves the architectural state,
> including keeping the power domain for local timers active.
> when core is power gated, the local timers are sufficient to
> wake the core up without needing broadcast timer.
Isn't that what should be exposed by GTDT when ACPI_GTDT_ALWAYS_ON
is set on the relevant interrupt and EL? The arch timer already
deals with that.
Why do we need anything else?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists