[PATCH v4 02/12] rvtrace: Initial implementation of driver framework

[Mark Zhuang]

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:
>>>> On Thu, Jul 02, 2026 at 04:19:53PM +0800, Zane Leung wrote:
>>>>> Hi,
>>>>>
>>>>> 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.
>>>> That is very vague.  Please provide specific examples.
>>> According to the /trace control interface/ [1] spec: "The ATB Bridge allows sending RISC-V trace to Arm CoreSight
>>>
>>> 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@linux.spacemit.com/
>> So, what specifically does this mean?  Please provide review comments
>> 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@linux.spacemit.com/

> 
> 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv