From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 537ADEB64DA for ; Wed, 19 Jul 2023 08:28:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7FCq5dvXjfxrIfABSs4nowP9uFSzVIW7RQ68ciJhCog=; b=dCkmBPzO1txSf4 p9Tk8y1hrjCw1PaLPVMOvF+LU9syra8EaSEBQ+NrmrSMa7ceecOtMlDhViVXYhhxXPZmJ+ABhIL95 uq96CMt4D/5ymQRhF7mbH4Xo02vMHzOvWrm+6WBJYX7LAbnGZPJLNm3no7I0aPy0oP94g4RfFLuZr RNpmCQzt/BjmZU1neO4307QqWC0C0WIR/fzzQxvuW8k2Rk7WoaALJjo9OD+zUgFjUhaHbIGXW3DXA O16czdmien2pAJTySIhirvuU9759G9sfoTpTHmBcmTvFGjlk/QUXtNtkeWl3ESRXn4U6nWAoAh5Rb jRMtsIedKbxm+p6hcunQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qM2XK-006LZU-2x; Wed, 19 Jul 2023 08:27:54 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qM2XJ-006LZ4-1j for linux-arm-kernel@bombadil.infradead.org; Wed, 19 Jul 2023 08:27:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=l1PKh77MEb3VKKOh2j/cZHG28JxYnAzhcOMEtBtn5Ns=; b=L0Uo8tURNz9tDEOPD5zKMTq5+D istGgvFKpVlizkjkKYSWFwcU25UYDvkqS9rkY9Vatigf0PFMC/28KadpRulldlHSOsTLUkNYAgF2V ZDIE6h8+Z7qVFDMyviKC1LIw0UaKCU+LyHMCxeGaWKW22sZE4Ehn5C9dmqTxZslG/SErk2fQn9xkj IGeCaaD5/0EWd3L+7slBBWZbHmYuqnGhphPVsXDQ4rJ7pwXlsZfW3eJT6G9ntxya5zfMlUJj+ajpx Poe4U0VJCEda9CGXVO9tluGBAaWzA6UqMIEe9CeEBZBOKVQIxwMTSoH7wqN+R8NPoJ9k8ETHldqXK ILKVyuYg==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qLkof-00BZwG-39 for linux-arm-kernel@lists.infradead.org; Tue, 18 Jul 2023 13:32:41 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AA7432F4; Tue, 18 Jul 2023 06:32:48 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B62063F6C4; Tue, 18 Jul 2023 06:32:03 -0700 (PDT) Date: Tue, 18 Jul 2023 14:32:01 +0100 From: Sudeep Holla To: Oza Pawandeep Cc: Catalin Marinas , Will Deacon , Sudeep Holla , "Rafael J . Wysocki" , Len Brown , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, jiles@qti.qualcomm.com Subject: Re: [PATCH] cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer Message-ID: <20230718133201.qsulwupte6l6bmdm@bogus> References: <20230712172458.2507434-1-quic_poza@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230712172458.2507434-1-quic_poza@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230718_143239_249316_27CF72C5 X-CRM114-Status: GOOD ( 28.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 12, 2023 at 10:24:58AM -0700, Oza Pawandeep wrote: > Arm=AE Functional Fixed Hardware Specification defines LPI states, > which provides 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. > = > Signed-off-by: Oza Pawandeep > = > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h > index bd68e1b7f29f..9c335968316c 100644 > --- a/arch/arm64/include/asm/acpi.h > +++ b/arch/arm64/include/asm/acpi.h > @@ -42,6 +42,24 @@ > #define ACPI_MADT_GICC_SPE (offsetof(struct acpi_madt_generic_interrupt= , \ > spe_interrupt) + sizeof(u16)) > = > +/* > + * Arm=AE Functional Fixed Hardware Specification Version 1.2. > + * Table 2: Arm Architecture context loss flags > + */ > +#define CPUIDLE_CORE_CTXT BIT(0) /* Core context Lost */ > + > +#ifndef arch_acpi_lpi_timer_stopped > +static __always_inline bool arch_acpi_lpi_timer_stopped(u32 arch_flags) As mentioned by you above, the core context is not just timer context, so calling this function so is misleading. > +{ > + return arch_flags & CPUIDLE_CORE_CTXT; > +} > +#define arch_acpi_lpi_timer_stopped arch_acpi_lpi_timer_stopped > +#endif > + > +#define CPUIDLE_TRACE_CTXT BIT(1) /* Trace context loss */ > +#define CPUIDLE_GICR_CTXT BIT(2) /* GICR */ > +#define CPUIDLE_GICD_CTXT BIT(3) /* GICD */ > + Do we really need to define these unused bitfields ? DO you have plans to use them ? > /* Basic configuration for ACPI */ > #ifdef CONFIG_ACPI > pgprot_t __acpi_get_mem_attribute(phys_addr_t addr); > diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c > index 9718d07cc2a2..8ea1f2b3bf96 100644 > --- a/drivers/acpi/processor_idle.c > +++ b/drivers/acpi/processor_idle.c > @@ -1221,7 +1221,7 @@ static int acpi_processor_setup_lpi_states(struct a= cpi_processor *pr) > strscpy(state->desc, lpi->desc, CPUIDLE_DESC_LEN); > state->exit_latency =3D lpi->wake_latency; > state->target_residency =3D lpi->min_residency; > - if (lpi->arch_flags) > + if (arch_acpi_lpi_timer_stopped(lpi->arch_flags)) While setting CPUIDLE_FLAG_TIMER_STOP if any flags set is already questionable, checking for arch specific flag in the generic code is even more questionable now. I wonder if it makes more sense to have a arch specific helper to update the state->flags based on how arch specific interpretation of lpi->arch_flags ? > state->flags |=3D CPUIDLE_FLAG_TIMER_STOP; > if (i !=3D 0 && lpi->entry_method =3D=3D ACPI_CSTATE_FFH) > state->flags |=3D CPUIDLE_FLAG_RCU_IDLE; > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index d584f94409e1..b24f1cd1cebb 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -1471,6 +1471,14 @@ static inline int lpit_read_residency_count_addres= s(u64 *address) > } > #endif > = > +#ifndef arch_acpi_lpi_timer_stopped > +static __always_inline bool arch_acpi_lpi_timer_stopped(u32 arch_flags) > +{ > + return (arch_flags !=3D 0); > +} > +#define arch_acpi_lpi_timer_stopped arch_acpi_lpi_timer_stopped > +#endif > + This looks ugly and main reason for my above comment. I am thinking of arch_update_idle_state_flags(lpi->arch_flags, &state->flags) and make it do nothing on non arm platforms. I don't think we will be breaking anything(i.e. no need to check arch_flags !=3D 0. It is incorrect strictly speaking but there are no non-arm users ATM, but that doesn't mean we can trickle the arch specific LPI FFH details into the generic code. -- = Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel