[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250523085655.GD2566836@e132581.arm.com>
Date: Fri, 23 May 2025 09:56:55 +0100
From: Leo Yan <leo.yan@....com>
To: Yuanfang Zhang <quic_yuanfang@...cinc.com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>,
James Clark <james.clark@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
kernel@....qualcomm.com, linux-arm-msm@...r.kernel.org,
coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/2] coresight: add coresight Trace Network On Chip
driver
On Fri, May 23, 2025 at 04:08:58PM +0800, Yuanfang Zhang wrote:
[...]
> >> +static int trace_noc_init_default_data(struct trace_noc_drvdata *drvdata)
> >> +{
> >> + int atid;
> >> +
> >> + atid = coresight_trace_id_get_system_id();
> >> + if (atid < 0)
> >> + return atid;
> >> +
> >> + drvdata->atid = atid;
> >
> > Do you need to expose this via sysfs ? Otherwise, how can you map
> > a trace to a TNOC at decoding ?
>
> yes, need to expose the atid via sysfs, but it better to expose it on source driver which connect with
> this TNOC. so dont expose it on this driver.
If so, why the ID is not maintained in coresight_path::trace_id?
A source device allocates ID and maintains in coresight path, then
this ID is passed (when enabling the link) to TNOC driver to consume it.
Thanks,
Leo
Powered by blists - more mailing lists