From: Jie Gan <jie.gan@oss.qualcomm.com>
To: Leo Yan <leo.yan@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@arm.com>,
James Clark <james.clark@linaro.org>
Cc: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Tingwei Zhang <tingwei.zhang@oss.qualcomm.com>,
Jingyi Wang <jingyi.wang@oss.qualcomm.com>,
Abel Vesa <abel.vesa@oss.qualcomm.com>,
Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, coresight@lists.linaro.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
Date: Tue, 30 Jun 2026 16:42:39 +0800 [thread overview]
Message-ID: <37017aa2-e18c-4568-a37c-d13964cbb418@oss.qualcomm.com> (raw)
In-Reply-To: <20260630081021.GD1812158@e132581.arm.com>
Hi Leo,
On 6/30/2026 4:10 PM, Leo Yan wrote:
> Hi Jie,
>
> On Tue, Jun 30, 2026 at 09:03:52AM +0800, Jie Gan wrote:
>
> [...]
>
>>> - How can you guarantee that a interconnect TraceNoC will never
>>> require ATID in the future?
>
>> From a hardware perspective, there is no fundamental difference between an
>> itnoc and an AG TraceNoC. They use the same TraceNoC hardware implementation
>> and share the same AMBA bus type. The distinction is purely functional: an
>> itnoc is used for local trace aggregation within a subsystem, whereas an AG
>> TraceNoC serves as the top-level aggregation point for the SoC.
>
> I'm still not convinced that adding "arm,primecell-periphid" is the
> right approach.
>
I agree we shouldn't need to add arm,primecell-periphid for the AMBA
bus, as the hardware provides the necessary registers to read the
peripheral ID. I used it as a temporary workaround to resolve the issue,
but I believe that solution is not correct.
> From the description above, I'd expect either the hardware to expose
> bits in a register to distinguish these two module types, or as I
> suggested earlier, to use a DT property to indicate the module type (or
> whether ATID is required).
>
I wanna distinguish the aggregator traceNoC and interconnect traceNoC,
even probe with platform driver, but the existing compatible is too
specific to the interconnect traceNoC device(coresight-itnoc), that's
why I didnt try the DT property proposal.
> Or have you tried to detect the last tnoc on a path and allocate ID for
> it? (You can retrieve csdev->path).
As Suzuki mentioned in the other thread, I think it would be better to
add separate compatibles in the of_match_table to distinguish between
Aggregator TraceNoC and Interconnect TraceNoC when probing with the
platform driver. This would allow us to allocate an ATID only for
Aggregator TraceNoC during probe, which is consistent with our original
design.
Thanks,
Jie
>
> Thanks,
> Leo
next prev parent reply other threads:[~2026-06-30 8:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 9:49 [PATCH v2 0/2] Fix traceNoC probe issue on Kaanapali Jie Gan
2026-06-24 9:49 ` [PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid Jie Gan
2026-06-25 7:24 ` Krzysztof Kozlowski
2026-06-25 7:36 ` Jie Gan
2026-06-24 9:49 ` [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue Jie Gan
2026-06-24 13:27 ` Konrad Dybcio
2026-06-24 13:48 ` Jie Gan
2026-06-24 13:51 ` Suzuki K Poulose
2026-06-24 15:08 ` Jie Gan
2026-06-24 15:16 ` Leo Yan
2026-06-25 1:01 ` Jie Gan
2026-06-25 8:56 ` Leo Yan
2026-06-26 2:03 ` Jie Gan
2026-06-26 10:30 ` Leo Yan
2026-06-26 12:09 ` Jie Gan
2026-06-26 15:49 ` Leo Yan
2026-06-29 2:08 ` Jie Gan
2026-06-29 14:28 ` Leo Yan
2026-06-30 1:03 ` Jie Gan
2026-06-30 8:10 ` Leo Yan
2026-06-30 8:42 ` Jie Gan [this message]
2026-06-30 10:01 ` Leo Yan
2026-06-30 8:21 ` Suzuki K Poulose
2026-06-24 14:25 ` Leo Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37017aa2-e18c-4568-a37c-d13964cbb418@oss.qualcomm.com \
--to=jie.gan@oss.qualcomm.com \
--cc=abel.vesa@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=coresight@lists.linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=james.clark@linaro.org \
--cc=jingyi.wang@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=leo.yan@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.leach@arm.com \
--cc=robh@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tingwei.zhang@oss.qualcomm.com \
--cc=yuanfang.zhang@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox