Re: [PATCH v4 02/12] rvtrace: Initial implementation of driver framework
From: Mark Zhuang
Date: Fri Jul 03 2026 - 06:06:08 EST
On 03/07/2026 17:00, Zane Leung wrote:
On 7/3/2026 3:41 PM, Greg KH wrote:
On Fri, Jul 03, 2026 at 03:32:50PM +0800, Zane Leung wrote:
On 7/3/2026 1:41 PM, Greg KH wrote:So, what specifically does this mean? Please provide review comments
On Thu, Jul 02, 2026 at 04:19:53PM +0800, Zane Leung wrote:According to the /trace control interface/ [1] spec: "The ATB Bridge allows sending RISC-V trace to Arm CoreSight
Hi,That is very vague. Please provide specific examples.
Based on the current framework, I am concerned about how to support RISC-V ATB and reuse the Coresight component (ETB/tmc/TPIU) in the future.
infrastructure (instead of RISC-V compliant sink defined in this document) as an ATB initiator. ATB Bridge is not
needed for RISC-V only systems."
For ATB Bridge, read trace using Coresight components (ETB/TMC/TPIU), so we need also ARM coresight driver in
RISC-V trace systems. Current framework seems to only be applicable to RISC-V only systems, and does not support
ATB and ARM coresight use case like the K3 (K3 SoC contains RISC-V Encoder, Funnel, ATB, CoreSight Funnel, and
CoreSight TMC components). For more discussion, please refer to [2].
[1]: https://docs.riscv.org/reference/trace-control-interface/v1.0/tci_system_overview.html#atb-bridge
[2]: https://lore.kernel.org/all/20260414034153.3272485-1-liangzhen@xxxxxxxxxxxxxxxxxx/
for the code itself.
The issue I pointed out is not about specific lines of code, but about the entire Riscv trace driver registration and building a path from source ->
sink did not take into account the application of arm_comesight. the current patch set assumes a rigid, homogeneous RISC-V-only topology.
Specifically, if we have ARM coresight components, how can we reuse them like, funnel (drivers/hwtracing/coresight/coresight-funnel.c) ,
TMC (drivers/hwtracing/coresight/coresight-funnel.c) , TPIU (drivers/hwtracing/coresight/coresight-tpiu.c) and so on based on the current
framework.
We write code for stuff we have now, today. If future needs change, we
change the code to handle that then.
SpacemiT K3 is a concrete, shipping example of exactly this topology: its RISC‑V trace encoders generate N‑Trace messages, which are then forwarded to Arm CoreSight components via an ATB bridge.
Documentation: [1]
Given that K3 is a commercially available RISC‑V SoC today, I believe it qualifies as "stuff we have now, today" rather than a hypothetical future case.
It would be ideal if we could reconcile this series with Zane's patchset[2], so that trace works on both QEMU and real hardware such as the K3.
The main friction point at present appears to be CoreSight compatibility.
[1]https://github.com/spacemit-com/docs-tool/blob/main/en/user_guide/trace_user_guide.md
[2]https://lore.kernel.org/all/20260414034153.3272485-1-liangzhen@xxxxxxxxxxxxxxxxxx/
I believe that if the basic framework for RISC-V does not consider compatibility with ARM Coresight, once the framework is fixed, there will be greater resistance to future modifications.
The only problem is with user/kernel apis, those need to be nailed down
so that they don't change. I can't tell here if you are only referring
to the in-kernel stuff, or user/kernel apis, sorry.
thanks,
greg k-h
I believe that RISC-V tracing is coresight-alike, where have encoders/funnel/sink/bridge+coresight_comp.
I think we should abstract some of CoreSight's core logic so that it can Both coresight and rvtrace can be reused.
General logic for building paths from source -> Sink and perf_pmu should be universal in coresight/rvtrace and
future architectures.
thanks,
Zane
_______________________________________________
linux-riscv mailing list
linux-riscv@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-riscv