Re: [External] Re: [PATCH v3] arm64: topology: add source check in arch_cpu_idle_enter()

On Thu, Aug 27, 2026 at 05:11:28PM +0800, Xuewen Yan wrote:

On Thu, Aug 27, 2026 at 5:02 PM Beata Michalska [off-list ref] wrote:

quoted

On Mon, Aug 24, 2026 at 05:21:03PM +0800, Xuewen Yan wrote:

quoted

On Thu, Aug 20, 2026 at 3:11 AM Beata Michalska [off-list ref] wrote:

quoted

Should we distinguish between events?

We could although for this particular issue clearing the source is the one that
needs attention. But I do not see why we could not have both.
This was just sharing the idea, not a final patch.

quoted

quoted

---

This is just a rough idea, and needs ironing out the wrinkles, which are there,
but that allows leaving the idle enter as is. I also believe this is the right
approach for the interface itself, although I also see some drawbacks and
potential issues (in its current state), especially that the functionality is
being exposed to modules.
Nevertheless, those are my two cents, untested, just sketched.

As an aside, could we verify the functionality of the AMU's
SYS_AMEVCNTR0_CONST_EL0 in the current CPU before enabling amu_file?
To my knowledge, many chips currently have inaccurate errata in this counter.
Alternatively, could we introduce a command line that allows users to
dynamically disable this feature?

Thanks!

Do you have any particular issue in mind ?
So far, from what I have been able to track, the issues reported are either
handled by existing erratum or by the latest change that reads the counters in
'one go'. Can you share the details of the issue you are facing ?
That would be helpful in potentially finding the right solution.

For example:
There is an A725 errata:
[A725]The CNT_CYCLES event can have a significant increment error due to WFE/WFI
Status
Fault type: Programmer Category B
Fault status: Present in r0p0, r0p1, and r0p2. Open.
......
Workaround
There is no workaround.

Right.
Will be sharing a patch for that one soon.

---
BR
Beata

Thanks!

quoted

---
BR
Beata