From: Beata Michalska <beata.michalska@arm.com>
To: "zhenglifeng (A)" <zhenglifeng1@huawei.com>
Cc: Will Deacon <will@kernel.org>,
catalin.marinas@arm.com, rafael@kernel.org,
viresh.kumar@linaro.org, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, dakr@kernel.org,
ionela.voinescu@arm.com, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org, linuxarm@huawei.com,
jonathan.cameron@huawei.com, vincent.guittot@linaro.org,
zhanjie9@hisilicon.com, lihuisong@huawei.com,
yubowen8@huawei.com, zhangpengjie2@huawei.com,
wangzhi12@huawei.com, linhongye@h-partners.com
Subject: Re: [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug
Date: Mon, 29 Dec 2025 23:12:06 +0100 [thread overview]
Message-ID: <aVL8tp7k1ne9DWSX@arm.com> (raw)
In-Reply-To: <62ad0257-aa50-4ab6-bd46-64c3963e4b94@huawei.com>
On Sat, Dec 20, 2025 at 05:09:52PM +0800, zhenglifeng (A) wrote:
> On 2025/12/13 4:08, Will Deacon wrote:
> > On Fri, Dec 12, 2025 at 05:27:09PM +0800, zhenglifeng (A) wrote:
> >> On 2025/12/2 23:31, Beata Michalska wrote:
> >>> On Tue, Dec 02, 2025 at 11:05:25AM +0800, zhenglifeng (A) wrote:
> >>>> On 2025/12/1 23:27, Beata Michalska wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Apologies for the delay in reviewing this - currently in progress....
> >>>>> Out of curiosity: what's the cpufreq driver used for testing this series ?
> >>>>
> >>>> I used cppc_cpufreq for testing this. But with some modifications in
> >>>> processor_driver.c, or you'll find that the driver will fail to load with
> >>>> maxcpus set. The modification below is only a temporary solution. I'm still
> >>>> working on that.
> >>>>
> >>> Right, so overall the implementation looks good - thanks for that.
> >>> There are two issues though with the cppc cpufreq driver.
> >>>
> >>> One: as you have already noticed - it fails to register when
> >>> cpumask_present != cpumask_online.
> >>>
> >>> Second: it will mix the sources of the freq scale if not all CPUs within the
> >>> policy have AMUs enabled/valid. This is due to the fact that at the time of
> >>> registering the driver and initializing the FIE support policy->cpus ==
> >>> policy->related_cpus. Assuming scenario when there are two CPUs within the
> >>> policy, one being offline and missing valid AMU counters,
> >>> the topology_set_scale_freq_source from cppc cpufreq driver will register
> >>> the tick handler for both CPUs, whereas AMU support will (rightly so) register
> >>> only for the firs one. When the second CPU comes online, the mismatch will be
> >>> detected and the arch callback will get cleared for the first CPU, but the
> >>> second one will remain unchanged.
> >>>
> >>> That said, I do not think any of those issues is a blocker for this series.
> >>> But both would need fixing.
> >>
> >> I believe Beata is OK with this series. So I think we can move ahead with it
> >> now.
> >
> > Please repost at -rc1. It would be nice to have an Ack from Beata...
>
> Hi Beata,
>
> It would be nice if you could give this patch an Ack.
>
> Thanks.
>
Apologies, 've been away.
Acked-by: Beata Michalska <beata.michalska@arm.com>
---
BR
Beata
> >
> > Will
> >
>
prev parent reply other threads:[~2025-12-29 22:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 8:13 [PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug Lifeng Zheng
2025-11-19 8:13 ` [PATCH v6 1/3] arm64: topology: Skip already covered CPUs when setting freq source Lifeng Zheng
2025-11-19 8:13 ` [PATCH v6 2/3] cpufreq: Add new helper function returning cpufreq policy Lifeng Zheng
2025-11-19 8:13 ` [PATCH v6 3/3] arm64: topology: Handle AMU FIE setup on CPU hotplug Lifeng Zheng
2025-11-25 18:29 ` [PATCH v6 0/3] " Catalin Marinas
2025-11-28 15:49 ` Catalin Marinas
2025-12-01 15:27 ` Beata Michalska
2025-12-02 3:05 ` zhenglifeng (A)
2025-12-02 3:08 ` zhenglifeng (A)
2025-12-02 15:31 ` Beata Michalska
2025-12-03 9:44 ` zhenglifeng (A)
2025-12-12 9:27 ` zhenglifeng (A)
2025-12-12 20:08 ` Will Deacon
2025-12-20 9:09 ` zhenglifeng (A)
2025-12-29 22:12 ` Beata Michalska [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aVL8tp7k1ne9DWSX@arm.com \
--to=beata.michalska@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dakr@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=ionela.voinescu@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=lihuisong@huawei.com \
--cc=linhongye@h-partners.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=rafael@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=wangzhi12@huawei.com \
--cc=will@kernel.org \
--cc=yubowen8@huawei.com \
--cc=zhangpengjie2@huawei.com \
--cc=zhanjie9@hisilicon.com \
--cc=zhenglifeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).