[PATCH v6 0/3] arm64: topology: Handle AMU FIE setup on CPU hotplug

Beata Michalska beata.michalska at arm.com
Mon Dec 29 14:12:06 PST 2025


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 at arm.com>

---
BR
Beata
> > 
> > Will
> > 
> 



More information about the linux-arm-kernel mailing list