Re: coresight: cpu-debug: PC sampling via PMPCSR (FEAT_PCSRv8p2)?

[Leo Yan <leo.yan@arm.com>]

Hi,

On Fri, Nov 13, 2026 at 07:46:41AM +0200, Igor Velkov wrote:
> Hi,
> 
> Cortex-A55 (Amlogic S905X3) reports EDDEVID.PCSample = 0, so
> coresight-cpu-debug cannot use it. The PC is available through PMPCSR
> in the external PMU frame (debug frame + 0x20000, PMDEVID.PCSample = 1).
> A lab module reading PMPCSR caught the PC of a CPU stuck on a PCIe bus
> access with IRQs off; on this GICv2 SoC the stop IPI never reaches it.
> 
> Two observations:
> - A panic notifier samples too late: the other CPUs are stopped by
>   then, and on this SoC reading the PMU frame of a stopped CPU raises a
>   synchronous external abort. Sampling on entry to smp_send_stop()
>   works.

Arm ARM, section I5.3.48 PMPCSR mentions "PMPCSR is in the Core power
domain". The challenge is ensuring that the target core remains powered
_throughout_ the access; checking its power state beforehand still
leaves a race.

For example, with CPUidle enabled, a CPU can be powered off any time so
it still race even move sampling in smp_send_stop().

This seems to be the main challenge. I'll check a bit if any guidance
for safely accessing PMPCSR.

> - Marvell has an out-of-tree patch, "coresight: cpu-debug: Add support
>   to dump PMPCSR" (2023, carried in linux-yocto); I could not find it
>   on the lists.
> 
> Is PMPCSR support in coresight-cpu-debug planned or welcome? And how
> should such a PMU frame be described in DT: arm,coresight-cpu-debug or
> a new compatible?

Would it make sense to describe external PMU frames in the PMU node
and have cpu-debug reference its phandle? As Suzuki mentioned, this
can be reviewed on patch.

Thanks,
Leo