[PATCH v3 00/31] CoreSight: Address CPU Power Management Issues

James Clark james.clark at linaro.org
Tue Oct 7 06:03:34 PDT 2025



On 15/09/2025 11:33 am, Leo Yan wrote:
> This series addresses CPU power management issues in the CoreSight
> drivers. For easier review, the patches are organized into two
> categories:
> 
> o Patches 01 ~ 10 focus on CPU power management within the ETM drivers.
>    These patches fix SMP-safe access to the mode, correct context
>    synchronization, and refactor the CPU suspend/resume flows.
> 
> o Patches 11 ~ 31 extend CPU power management to cover activated paths,
>    including helpers, links, and sinks. These changes move CPU PM and
>    hotplug notifiers from the ETMv4 driver into the CoreSight core layer.
> 
> Summary:
> 
> - Patches 01 ~ 03: Fix device mode access in the SMP mode.
> - Patch 04       : A minor fix for polling bit.
> - Patches 05 ~ 07: Improve the context synchronization based on the ETM
>                     specification (IHI0064H.b) and Arm ARM (ARM DDI 0487
>                     L.a).
> - Patches 08 ~ 10: Refactor the context save/restore flow in the ETMv4
>                     driver, in the end, the CPU PM callbacks reuse the
>                     normal enabling and disabling flows.
> - Patches 11 ~ 17: Move CPU PM code from ETMv4 driver to the core layer.
> - Patches 18 ~ 23: Enhance the CTI driver for preparation dynamically
>                     controlling CTI devices in PM flows. This includes
>                     device mode handling in the CTI driver and
>                     distinguishing trace modes (Perf or SysFS). Refactor
>                     the PM notifier and improve locking usage (including
>                     for syscfg).
> - Patches 24 ~ 31: Support save and restore context for TRBE and
>                     manages activated paths during CPU idle and
>                     CPU hotplug.
> 
> Verification:
> 
> This series has been verified on Juno-r0 and r2 platform.
> 
>    Stress test script:
> 
>    #!/usr/bin/bash
> 
>    echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
> 
>    while true; do
>            echo 0 > /sys/devices/system/cpu/cpu2/online;
>            echo 1 > /sys/devices/system/cpu/cpu2/online;
>    done &
> 
>    while true; do
>            echo 1 > /sys/bus/coresight/devices/etm2/enable_source;
>            echo 0 > /sys/bus/coresight/devices/etm2/enable_source;
>    done &
> 
>    Test script with kernel module insmod / rmmod:
> 
>    #!/bin/bash
> 
>    modules=(
>            "coresight"
>            "coresight_dummy"
>            "coresight_replicator"
>            "coresight_tpiu"
>            "coresight_cpu_debug"
>            "coresight_etb10"
>            "coresight_stm"
>            "coresight_trbe"
>            "coresight_tmc"
>            "coresight_ctcu"
>            "coresight_catu"
>            "coresight_etm4x"
>            "coresight_cti"
>            "coresight_funnel"
>            "coresight_tnoc"
>    )
>    module_dir="/mnt/build/drivers/hwtracing/coresight/"
> 
>    if [[ "$1" == "in" ]]; then
>            echo "Inserting modules..."
>            for mod in "${modules[@]}"; do
>                    modprobe $mod && echo "Loaded $mod" || echo "Failed to load $mod"
>            done
>    elif [[ "$1" == "rm" ]]; then
>            echo "Removing modules..."
>            # Remove in reverse order to respect dependencies
>            for (( idx=${#modules[@]}-1 ; idx>=0 ; idx-- )); do
>                    mod="${modules[$idx]}"
>                    echo "Removing $mod..."
>                    rmmod "$mod" && echo "Removed $mod" || echo "Failed to remove $mod"
>            done
>    fi
> 
> ---
> Changes in v3:
> - Fixed building failure in ETMv3 driver (kernel test robot).
> - Refactoring ETMv3 change for checking CPU ID (Levi).
> - Fixed NULL pointer issue during CPU idle (James).
> - Fixed lockdep complaint for HARDIRQ-safe and HARDIRA-unsafe (James).
> - Fixed acquiring mutex in atomic context (James).

I did still see some lockdep issues, but only when the CTI driver is 
loaded. With it unloaded I didn't see any anymore.

I couldn't stress test concurrent sysfs and Perf mode because it's not 
working in coresight-next to begin with. When sysfs mode fails to enable 
a source, it will disable the sink even if Perf is using it and then a 
load of WARN()s get hit.

I also managed to make rmmod explode by running it while the sysfs 
stress test was running, but I don't think this is related to these 
changes either.

All in all, difficult to test given the current state of locking and 
concurrency:

Tested-by: James Clark <james.clark at linaro.org>




More information about the linux-arm-kernel mailing list