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

[Zane Leung]

On 7/3/2026 8:01 PM, Anup Patel wrote:
> On Fri, Jul 3, 2026 at 2:31 PM Zane Leung <liangzhen at linux.spacemit.com> 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.
>> 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 you are over simplifying the comparison. At high-level only
> the topology of components is similar between RISC-V and ARM but the
> individual components have greater architecture influnce. In fact, we
> upcoming RISC-V self-hosted trace under development where both encoder
> and ramsink are programmed via CPU CSRs.
>
> The only thing which can be shared is a common trace framework (which
> is very small part of this series) but the component drivers, driver
> probing, perf driver etc will be highly architecture specific.
>
>> 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
> My suggestion is to take current rvtrace framework (which is minimal
> enough) and create a simple "gtrace" framework (aka generic trace
> driver framework) which can be enabled by multiple architectures. The
> RISC-V trace drivers can be the first ones to adopt this "gtrace"
> framework. As separate series, the ARM coresight component drivers
> gradually updated to support "gtrace" framework. This way only
> required stuff will be shared will be brought under the common
> "gtrace" framework.
>
> I will update this series as-per above suggestion if there is no objection.
>
> Regards,
> Anup

I generally agree with this approach. Once this series is updated, I will try to update
the ARM CoreSight component drivers to support the "gtrace" framework, based on 
the K3 platform.

Best regards,
Zane