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

[Anup Patel]

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