[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230913105148.xntz3qeascibvuxx@bogus>
Date: Wed, 13 Sep 2023 11:51:48 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Will Deacon <will@...nel.org>
Cc: Oza Pawandeep <quic_poza@...cinc.com>, catalin.marinas@....com,
Sudeep Holla <sudeep.holla@....com>, 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 v5] cpuidle, ACPI: Evaluate LPI arch_flags for broadcast
timer
On Wed, Sep 13, 2023 at 11:27:21AM +0100, Will Deacon wrote:
> On Wed, Sep 13, 2023 at 09:43:01AM +0100, Sudeep Holla wrote:
> > On Tue, Sep 12, 2023 at 10:29:33AM -0700, 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.
> > >
> > > The patch fixes the evaluation of cpuidle arch_flags, and moves only to
> > > broadcast timer if core context lost is defined in ACPI LPI.
> > >
> > > Reviewed-by: Sudeep Holla <sudeep.holla@....com>
> >
> > IIRC, Rafael had acked this, perhaps missing the tag ?
> > Also just add a note to Will/Catalin that Rafael has acked and prefer to
> > take it via arm64 tree.
>
> Is this a fix? If so, please can I have a "Fixes:" tag (and does it need to
> go into stable?)
>
Well, most platform today have CPUIDLE_CORE_CTXT set so the existing code
works as expected. It is this Qcom platform that doesn't set it and need
different behaviour. So based on their requirement for running stable
tree, the fixes tag can be added. In short yes it can be seen as a fix
if this new requirement is considered.
Sorry the main reason for trying to avoid is there are multiple patches
adding the initial support and there has been some code restructuring
around this. So it may need proper backporting based on the version.
I just want to avoid if there is no real requirement for that.
--
Regards,
Sudeep
Powered by blists - more mailing lists