TRBE currently stops trace collection at each buffer limit, so interrupt
latency can cause trace loss. This series adds trigger-based maintenance
and WRAP mode to reduce these gaps, while protecting unconsumed data and
retaining limit-based handling where required by errata.
The perf changes preserve decoder state across contiguous indexed AUX
fragments, with resets when continuity cannot be established. Thread
stacks still flush at each data block boundary. For normal recording, a
quarter-buffer watermark wakes userspace earlier.
The 11 patches cover:
Patches 01-02: Next-buffer computation cleanup and refactoring.
Patches 03-07: Trigger support, headroom, save/restore, and KUnit tests.
Patches 08-11: Decoder continuity and earlier userspace wakeups.
This series is based on coresight-next and requires
"coresight: trbe: Refactor buffer and IRQ handling" [1] to be applied first.
This series has been tested on the Orion6 board with TRBE and the
Juno-r2 board with ETR using the following commands:
perf record -e cs_etm// -a -- bash -c 'for i in {1..5}; do timeout 0.1 yes > /dev/null; sleep 0.1; done'
perf script --itrace=i1000iTZ
[1] https://lore.kernel.org/linux-arm-kernel/20261016-trbe_enable_disable_irq_h…
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
Changes in v2:
- Split the enable/disable, perf-handle lifecycle, and IRQ handling fixes
into the separate prerequisite series, leaving 11 patches here.
- Restrict KUnit buffer and padding stubs to the synthetic test handle,
preserving normal buffer lookup and AUX accounting for real perf IRQs.
- Centralize decoder-reset decisions in cs_etm__get_trace(), while
retaining thread-stack flushing at every data block boundary.
- Reset per-thread decoders for unknown or changed CPUs, preserve CPU
metadata on all split pieces, and retain resets through empty fragments.
- Reset the decoder on logical AUX offset discontinuities, including
clipped snapshots and missing AUX records, while preserving continuity
across internal buffer splits.
- Link to v1: https://lore.kernel.org/r/20251201-trbe_buffer_refactor_v1-1-v1-0-7da32b076…
---
Leo Yan (11):
coresight: trbe: Remove misleading comment
coresight: trbe: Refactor next buffer computation
coresight: trbe: Track trigger count support per CPU
coresight: trbe: Use trigger mode for buffer maintenance
coresight: trbe: Leave headroom for stop-on-trigger mode
coresight: trbe: Save and restore trigger counter
coresight: trbe: Add KUnit tests for compute normal buffer
perf cs-etm: Reset decoder on COLLISION flag
perf cs-etm: Reset per-thread decoder on CPU migration
perf cs-etm: Reset decoder on AUX offset discontinuity
perf cs-etm: Set watermark for AUX trace
drivers/hwtracing/coresight/Kconfig | 15 +
.../coresight/coresight-trbe-kunit-tests.c | 644 +++++++++++++++++++++
drivers/hwtracing/coresight/coresight-trbe.c | 342 ++++++++---
drivers/hwtracing/coresight/coresight-trbe.h | 18 +
tools/perf/arch/arm/util/cs-etm.c | 15 +
tools/perf/util/auxtrace.h | 2 +
tools/perf/util/cs-etm.c | 92 ++-
7 files changed, 1029 insertions(+), 99 deletions(-)
---
base-commit: 343cfcbb3ecfdb80aa576a428cfa3b65ad783842
change-id: 20260617-trbe_buffer_refactor_v2-8813e33fde8b
prerequisite-message-id: <20261016-trbe_enable_disable_irq_handle_refactor-v2-0-3f57cf3199b1(a)arm.com>
prerequisite-patch-id: 295f75af9986fc6193b0f3ec0f144096c1194efd
prerequisite-patch-id: 60541bcf6bd25acf076fca2dd2e62ea382541fd5
prerequisite-patch-id: 0a6dbd3a69611c9bdca8ad61ea943d6577251fb8
prerequisite-patch-id: 0f4dc971d1375cd5672a63cd148b6e7f6dfdd9b3
prerequisite-patch-id: b42114d2185bbd15c9095191417aad34137cc5e9
prerequisite-patch-id: fdcdce0d19c611de475c6e9737ef544a9fb19153
prerequisite-patch-id: 948b6aa1254adfc9f89a5aba3ef45e41d891debe
prerequisite-patch-id: ba1cc65a72bcfef9e22fea14f52eeaeeb2c551d3
prerequisite-patch-id: d0efcfbe7d1f7886aaa5c34655c14a979bf55863
prerequisite-patch-id: af045abf5718e35f16a5b98ec7c04213cf24d426
prerequisite-patch-id: d0af1d9f5551622858815d148de5dc3c94cdf564
prerequisite-patch-id: 9d02a95ecafda17debf728ef1098b98030019a10
prerequisite-patch-id: c6251f03223c3bd4bcf43abc292907dd93cad527
prerequisite-patch-id: 690af6c1769b93d8712aa73b322bb4e5f0acdc66
prerequisite-patch-id: 21c3d8dacd550b977ae549a1865e43523ed64f98
prerequisite-patch-id: 0b5666068c0fed73e6906473b38861556881e5b0
prerequisite-patch-id: f5c97c9acc3e691b3612999eae97c3366acf3d97
prerequisite-patch-id: 55846a3b80ca3196062d06522af768ac83751d97
prerequisite-patch-id: 5f5be1d1c925a9c0d945eba516a9075153045292
prerequisite-patch-id: 8e39271308702e557abc4e4e79fc96d0157844a7
prerequisite-patch-id: b99199a58c4a87408c4c2b0b39ee4861f5cd9d80
prerequisite-patch-id: 1bdbfe0417a4a98984b2fbe8d664738657de3032
prerequisite-patch-id: aeab33675e29539d239c8ffdf4bbd4cf861972c6
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
SPE and TRBE write padding into their AUX buffers before advancing
aux_head. Add the missing write barriers so that a userspace reader on
another CPU cannot observe the new head before the padding stores
become visible.
AUX producers must make their data visible before publishing aux_head.
The required synchronization depends on the trace hardware and CPU
memory model, so the barriers belong in the drivers rather than in
perf_aux_output_skip() or perf_aux_output_end(). The TRBE change also
covers padding inserted by the overwrite erratum workaround before
perf_aux_output_end().
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
Leo Yan (2):
perf: arm_spe: Order padding before publishing AUX head
coresight: trbe: Order padding before publishing AUX head
drivers/hwtracing/coresight/coresight-trbe.c | 2 ++
drivers/perf/arm_spe_pmu.c | 5 ++++-
2 files changed, 6 insertions(+), 1 deletion(-)
---
base-commit: 0fcb05b72344f40806cbe810de8872f1698bf053
change-id: 20261015-add_barriers_for_perf_aux_output_skip-70356815b2bd
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
On Tue, Oct 13, 2026 at 07:53:20AM +0200, Michal Simek wrote:
>
>
> On 10/12/26 18:28, Leo Yan wrote:
> > On Mon, Oct 12, 2026 at 02:35:37PM +0200, Michal Simek wrote:
> > >
> > >
> > > On 10/2/26 17:07, Leo Yan wrote:
> > > > Static replicators have no programmable registers and need no APB
> > > > programming clock.
> > > >
> > > > The Zynq clock controller registers dbg_trc and dbg_apb and calls
> > > > clk_prepare_enable() for each gate the bootloader left on.
> > >
> > > That's one bootloader behavior. If there is another bootloader that clocks
> > > can be simply disabled. I don't think there is any reason to depends on
> > > bootloader behavior. If there are clocks which has to be ON I can't see any
> > > reason not to drive them.
> >
> > My reference to zynq_clk_setup() was to explain that this patch leaves
> > the existing management of dbg_trc and dbg_apb unchanged.
> >
> > The CoreSight drivers do not request clocks named "dbg_trc" or "dbg_apb".
>
> And this is the point. DT binding is not describing what Linux driver handles.
> Binding describes HW itself.
I agreed that "Binding describes HW itself".
The question is which hardware clock connections the DT properties
describe. Arm DDI 0314H, Table B-1 [1], lists ATCLK for the replicator,
and ATCLK and PCLKDBG for the trace funnel. The static modules have no
APB programming interface.
> And for proper functionality these 2 clocks need to be handled.
Please point to the Zynq TRM section or clock diagram showing how
dbg_trc and dbg_apb supply the replicator and funnel.
> That Linux driver is not doing it that's different issue.
My understanding is the CoreSight drivers have already followed spec to
support clocks.
[1] https://support.arm.com/documentation/ddi0314/h/CoreSight-Components-and-Cl…
On Mon, Oct 12, 2026 at 02:35:37PM +0200, Michal Simek wrote:
>
>
> On 10/2/26 17:07, Leo Yan wrote:
> > Static replicators have no programmable registers and need no APB
> > programming clock.
> >
> > The Zynq clock controller registers dbg_trc and dbg_apb and calls
> > clk_prepare_enable() for each gate the bootloader left on.
>
> That's one bootloader behavior. If there is another bootloader that clocks
> can be simply disabled. I don't think there is any reason to depends on
> bootloader behavior. If there are clocks which has to be ON I can't see any
> reason not to drive them.
My reference to zynq_clk_setup() was to explain that this patch leaves
the existing management of dbg_trc and dbg_apb unchanged.
The CoreSight drivers do not request clocks named "dbg_trc" or "dbg_apb".
And removing those unused clock properties introduces no additional
dependence on the bootloader. Could you clarify how retaining these
entries addresses the bootloader concern?
> TRM page 741
>
> Trace Port Clock The trace port clock is used to clock the TPIU and trace
> buffer when the MIO interface is chosen and must be twice the frequency of
> the desired TPIU clock. The TPIU clock frequency must be chosen to be fast
> enough to allow the trace port to keep up with the amount of data being
> traced, but slow enough to meet the dynamic characteristics of the data
> output buffers of the TPIU.
The quoted paragraph establishes a trace-clock requirement for the TPIU
and trace buffer, how does it identify the clock inputs of the funnel
and replicator?
Thanks,
Leo
Hi Greg
Please find the updates for coresight self hosted tracing subsystem targeting
Linux v7.4. Apologies for the delay!
Kindly pull.
Suzuki
The following changes since commit df2908090cda368b01ff43709f51890076c56157:
Linux 7.3-rc2 (2026-09-06 15:07:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v7.4
for you to fetch changes up to 343cfcbb3ecfdb80aa576a428cfa3b65ad783842:
coresight: tnoc: Constify amba_id table (2026-10-09 11:32:08 +0100)
----------------------------------------------------------------
coresight: updates for Linux v7.4
CoreSight selfhosted tracing subsystem updates for Linux v7.4, includes:
- Separating the ETM configurations for sysfs and perf to avoid corrupting
each other while in use
- Hide sysfs control for TRBE as it is not supported
- Constify Amba device table for tnoc
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
----------------------------------------------------------------
James Clark (1):
coresight: trbe: Hide enable_sink sysfs file
Krzysztof Kozlowski (1):
coresight: tnoc: Constify amba_id table
Yeoreum Yun (14):
coresight: etm4x: Prohibit TRCSEQSTR modifications while tracing enabled
coresight: etm4x: prohibit modifying cntr_val while session is enabled
coresight: etm3x: Prohibit modifying cntr_val while session is enabled
coresight: etm4x: fix inconsistencies with sysfs configuration
coresight: etm3x: fix inconsistencies with sysfs configuration
coresight: etm3x: remove redundant cpu online check on etm_enable_sysfs()
coresight: etm4x: introduce struct etm4_caps
coresight: etm4x: exclude ss_status from drvdata->config
coresight: etm4x: remove s_ex_level from config
coresight: etm4x: rename local config as curr_config referring drvdata->curr_config
coresight: etm4x: rename drvdata->config to sysfs_config
coresight: etm3x: introduce struct etm_caps
coresight: etm3x: rename local config as curr_config referring drvdata->curr_config
coresight: etm3x: rename drvdata->config to sysfs_config
drivers/hwtracing/coresight/coresight-config.c | 18 +-
drivers/hwtracing/coresight/coresight-config.h | 22 +
drivers/hwtracing/coresight/coresight-core.c | 1 +
drivers/hwtracing/coresight/coresight-etm.h | 48 +-
drivers/hwtracing/coresight/coresight-etm3x-core.c | 196 +++--
.../hwtracing/coresight/coresight-etm3x-sysfs.c | 461 +++++-----
drivers/hwtracing/coresight/coresight-etm4x-cfg.c | 14 +-
drivers/hwtracing/coresight/coresight-etm4x-core.c | 561 ++++++------
.../hwtracing/coresight/coresight-etm4x-sysfs.c | 961 +++++++++++----------
drivers/hwtracing/coresight/coresight-etm4x.h | 199 +++--
drivers/hwtracing/coresight/coresight-sysfs.c | 15 +-
drivers/hwtracing/coresight/coresight-tnoc.c | 2 +-
drivers/hwtracing/coresight/coresight-trbe.c | 7 +
include/linux/coresight.h | 4 +
14 files changed, 1359 insertions(+), 1150 deletions(-)
On Sun, 05 Jul 2026 19:19:35 +0200, Krzysztof Kozlowski wrote:
> Static 'struct amba_id' table is not modified so can be changed to const
> for more safety.
>
>
Applied, thanks!
[1/1] coresight: tnoc: Constify amba_id table
https://git.kernel.org/coresight/c/343cfcbb3ecf
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>
Concurrent per-thread events results in a WARN on N1SDP which leads to
the realization that per-thread events shouldn't have been sharing sinks
in the first place.
This slips through because different per-thread events will have the
same PID if owned by the same process, and we only check the PID and
nothing else. That results in unexpected WARNs because it looks like we
assumed it couldn't happen (although exclusive PMU rules allow it). But
even if it was supported it would result in trace from the wrong thread
in another event's per-thread buffer, so we should disallow it.
Fix it everywhere the same PID checking logic was copy pasted. Then the
PIDs can be dropped from a few structs as they are now unused.
Signed-off-by: James Clark <james.clark(a)linaro.org>
---
Changes in v3:
- Storing and accessing event owners at runtime causes problems due to
various scenarios of: events (and sibling events) exiting, children
inheriting event FDs, PID reuse, CPU affine events that also have a
target process set but different inherit settings. Fix it by creating
a session ID in etm_setup_aux() and holding the references in it for
the duration of the whole session. (Leo)
- Make the ETR buffer allocator consistent with sink sharing rules by
not doing numeric PID comparisons there either.
- Fix up some Sashiko reports that it sees after interacting with cscfg
and taking extra references to tasks and PIDs.
- Link to v2: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v2-0-10ac7…
Changes in v2:
- Fix inherited events by following event->parent
- Link to v1: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v1-0-d384e…
---
James Clark (8):
coresight: tmc-etr: Don't stop Perf cleanup for active sysfs reads
coresight: configfs: Don't assume active until cscfg_mgr is set
coresight: etm-perf: Flush workqueue before unloading module
coresight: tmc-etr: Prevent per-thread events from sharing a sink
coresight: tmc-etr: Use session ID for buffer ownership
coresight: tmc-etf: Prevent per-thread events from sharing a sink
coresight: etb10: Prevent per-thread events from sharing a sink
coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink
drivers/hwtracing/coresight/coresight-core.c | 28 +--
drivers/hwtracing/coresight/coresight-etb10.c | 33 ++--
drivers/hwtracing/coresight/coresight-etm-perf.c | 79 ++++++++-
drivers/hwtracing/coresight/coresight-etm-perf.h | 15 ++
drivers/hwtracing/coresight/coresight-priv.h | 2 -
drivers/hwtracing/coresight/coresight-syscfg.c | 6 +-
drivers/hwtracing/coresight/coresight-tmc-core.c | 6 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 44 ++---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 207 +++++++++++++----------
drivers/hwtracing/coresight/coresight-tmc.h | 30 ++--
drivers/hwtracing/coresight/coresight-trbe.c | 3 +-
drivers/hwtracing/coresight/ultrasoc-smb.c | 25 +--
drivers/hwtracing/coresight/ultrasoc-smb.h | 6 +-
include/linux/coresight.h | 5 +-
14 files changed, 294 insertions(+), 195 deletions(-)
---
base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7
change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734
Best regards,
--
James Clark <james.clark(a)linaro.org>
Hi Amir,
Thanks for the patch. I have a few initial comments below. We may have
further feedback after our internal review.
On Wed, Sep 30, 2026 at 11:37:43PM -0700, Amir Ayupov wrote:
[...]
> #define CS_CFG_MATCH_CLASS_SRC_ALL 0x0001 /* match any source */
> #define CS_CFG_MATCH_CLASS_SRC_ETM4 0x0002 /* match any ETMv4 device */
> +/* ETM external output 1 is countable by the PMU as TRCEXTOUT1 */
> +#define CS_CFG_MATCH_CAP_PMU_EXTOUT1 0x0004
Do we need to tie this capability to TRCEXTOUT1? For example, Neoverse
V2 exposes TRCEXTOUT0 through TRCEXTOUT3 as PMU events.
> /* flags defining device instance matching - used in config match desc data. */
> #define CS_CFG_MATCH_INST_ANY 0x80000000 /* any instance of a class */
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> index e1a59b4345052..2847d2d7f7bed 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> @@ -174,9 +174,14 @@ static int etm4_cfg_load_feature(struct coresight_device *csdev,
>
> int etm4_cscfg_register(struct coresight_device *csdev)
> {
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> struct cscfg_csdev_feat_ops ops;
> + u32 match_flags = CS_CFG_ETM4_MATCH_FLAGS;
>
> ops.load_feat = &etm4_cfg_load_feature;
>
> - return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
> + if (drvdata->pmu_extout1)
> + match_flags |= CS_CFG_MATCH_CAP_PMU_EXTOUT1;
> +
> + return cscfg_register_csdev(csdev, match_flags, &ops);
The current matching logic succeeds if a device and feature share any
flag bit. If the feature sets both CS_CFG_MATCH_CLASS_SRC_ETM4 and
CS_CFG_MATCH_CAP_PMU_EXTOUT1, it will still load on an ETM4 device that
lacks the capability.
Could we check the capability separately when loading the feature,
perhaps in cscfg_load_feat_csdev(), and skip it on unsupported devices?
> +static bool etm4_pmu_has_extout1(struct etmv4_drvdata *drvdata)
> +{
> + int pmuver = read_pmuver();
> +
> + if (!is_midr_in_range_list(etm4_pmu_extout1_cpus))
> + return false;
Based on specific CPU variant, we should already have identified
TRCEXTOUT has supported.
So either we only base on MIDR list or we can figure out a reliable
way to detect the feature dynamically.
> +
> + /* PMCEID0_EL0[63:32] describe events 0x4000-0x401f from PMUv3p1 */
> + if (!pmuv3_implemented(pmuver) || pmuver < ID_AA64DFR0_EL1_PMUVer_V3P1)
> + return false;
> + if (!(read_pmceid0() & BIT_ULL(32 + ARMV8_PMUV3_PERFCTR_TRCEXTOUT1 -
> + ARMV8_PMUV3_EXT_COMMON_EVENT_BASE)))
> + return false;
> +
> + /* nr_event is TRCIDR0.NUMEVENT, the number of events minus one */
> + return drvdata->nr_event >= 1;
> +}
[...]
> @@ -1116,6 +1116,13 @@ int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
>
> if (err)
> cscfg_config_desc_put(config_desc);
> + } else {
> + /*
> + * The configuration is active but was not loaded on this
> + * device, for example because the device lacks a capability
> + * its features require. Fail rather than trace without it.
> + */
> + err = -EINVAL;
> }
This fixes a pre-existing issue. It is worther to put it in a separate
patch with fixes tag:
An early return would also avoid the normal enable path's indentation:
if (!config_csdev_active)
return -EINVAL;
err = cscfg_csdev_enable_config(config_csdev_active, preset);
...
Thanks,
Leo
On Thu, Oct 01, 2026 at 08:16:09AM +0100, Will Deacon wrote:
> On Wed, Sep 30, 2026 at 05:43:11PM +0100, Leo Yan wrote:
> > How about adding a field to struct pmu to specify a preferred maximum
> > page order for the AUX buffer? The perf core could try that order first
> > and fall back to smaller orders if the allocation fails.
>
> I'm not sure that's thr right place for it, really. The driver has no
> clue about whether it makes sense to use large contiguous mappings or
> not, so I'd have thought that decision should be driven from userspace
> (e.g. like MADV_HUGEPAGE) because it really depends on the user's
> preference and isn't a fixed property of the hardware.
Here MADV_HUGEPAGE cannot directly apply on this case: perf allocates
the AUX pages during mmap, while TRBE accesses them through a separate
kernel vmap() mapping.
MADV_HUGEPAGE is applied after mmap, but a preference (or flag) would
need to be specified before the AUX mmap.
> > For example, the Neoverse V2 TRM documents:
> >
> > L1 Trace Buffer Extension (TRBE) TLB: 1 entry
>
> Wow, they really pulled out the stops for that implementation. I bet
> we're supposed to be grateful for that entry!
Yeah, Neoverse V3 was improved to have two entries. Even so, I was told
it still suffers from TLB misses, so still needs a large mapping
granule.
> > Given the single L1 TRBE TLB entry, the TRBE driver could prefer
> > PMD_ORDER (2 MiB with 4 KiB pages) to reduce TLB pressure. This reflects
> > the hardware characteristic.
> >
> > This could be a trade-off instead of using PERF_PMU_CAP_AUX_PREFER_LARGE,
> > avoiding large contiguous allocations that could reintroduce the Android
> > OOM issue. I did a quick test with this approach and the results look
> > positive.
>
> I really don't want the driver to second-guess userspace based on whatever
> information it happens to have hard-coded about the specific CPU it's
> running on.
The kernel already takes the PERF_PMU_CAP_AUX_PREFER_LARGE flag from a
PMU; a preferred maximum order would let the driver give it a bounded
value.
I do not intend to hard-code or guess a preference for a particular CPU
variant. We can map TRBE or SPE buffer at PMD granularity. On a 4
KiB-page system, PMD_ORDER is order 9, or 2 MiB. Requesting a larger
contiguous chunk cannot increase the mapping granule, so I would cap the
preference there. It remains a preference: perf can fall back to smaller
orders when allocation fails.
Exposing the preference to userspace also seems problematic. Users
generally lack the hardware details needed to choose an appropriate
value. Even if tools provide a default, the same policy would need to
be duplicated across perf, simpleperf, and proprietary tools. I don't
think userspace tools are the right place for this policy.
Thanks,
Leo
On Fri, Oct 02, 2026 at 07:05:14PM +0300, Dmitry Baryshkov wrote:
> On Fri, Oct 02, 2026 at 04:33:28PM +0100, Leo Yan wrote:
> > On Fri, Oct 02, 2026 at 06:21:36PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, Oct 02, 2026 at 04:07:24PM +0100, Leo Yan wrote:
> > > > The APQ8064 static replicator has no registers to program, so it
> > > > does not need an APB clock. Remove its RPM_QDSS_CLK reference.
> > > > Other programmable CoreSight devices keep their clock references.
> > >
> > > QDSS clock is not actually the APB one, it's required for the coresight
> > > (or to access some of the regs) if I remember correctly.
> >
> > If so, it might be atclk for clocking the module rather than the
> > register interface. Could you confirm this?
> >
> > The replicator is just a middle component on the data path. I read
> > that it shares the same clock with other CoreSight components, so it
> > should still be safe to remove the clock from the replicator node,
> > as other components on the path will ensure that the clock is enabled.
>
> Unfortunately it might be hard to find info for this platform nowadays.
How about rename RPM_QDSS_CLK on the static replicator as "atclk", the
optional clock name supported by its binding.
replicator {
compatible = "arm,coresight-static-replicator";
clocks = <&rpmcc RPM_QDSS_CLK>;
- clock-names = "apb_pclk";
+ clock-names = "atclk";
I would leave the AMBA CoreSight nodes in the same dtsi unchanged for
now. They need an apb_pclk lookup for register access, and so far we
have no evidence to justify adding the same RPM clock again as atclk.
Please let me know if this works for you.
Thanks,
Leo