[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9a7VhmHooDpht-gU7eAA5O028Tn=CVmCNHU6Qg+UYXp6kUQg@mail.gmail.com>
Date: Fri, 11 Jul 2025 14:29:14 +0100
From: Mike Leach <mike.leach@...aro.org>
To: Mao Jinlong <quic_jinlmao@...cinc.com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>, 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>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/5] coresight: Add remote etm support
Hi,
The majority of this code should not be in the coresight drivers
directory as it is not actually coresight.
This seems to be a communications bus system for various SoC
components - one of which happens to be a remote etm. It really needs
to be in a qcom-qmi subdirectory - which would also remove your
reliance on the coresight maintainers for getting all the qmi drivers
upstreamed. I note that there is a CONFIG dependency of
QCOM_QMI_HELPERS, which implies there is already a set of QMI
functionality not in the coresight directory.
We already have a dummy coresight driver to cover these cases where
the actual etm source or sink might be in a different subsystem. This
could be extended in a generic manner to have an associated driver /
component, with the dummy source then forwarding the enable / disable
commands and acting as the coresight device for the purposes of
enabling the trace path from source to sink.
Thus the "coresight-remote-etm" driver becomes "qmi-node-etm" driver,
with the proprietary comms info, instance IDs etc encapsulated away
from any generic coresight information, and has an associated
coresight-dummy-source to handle the connection to the coresight trace
framework. I imagine the association could easily be modeled in device
tree using a phandle reference.
This would not change your usage model, but would give better
separation between what is clearly the QMI comms subsystem, and what
is needed to handle coresight connectivity.
Moreover, having the generic coresight dummy driver extended in this
way would allow other underlying communication systems to be used on
other devices in future.
Best Regards
Mike
On Fri, 11 Jul 2025 at 10:40, Mao Jinlong <quic_jinlmao@...cinc.com> wrote:
>
> The system on chip (SoC) consists of main APSS(Applications processor
> subsytem) and additional processors like modem, lpass. There is
> coresight-etm driver for etm trace of APSS. Coresight remote etm driver
> is for enabling and disabling the etm trace of remote processors.
> It uses QMI interface to communicate with remote processors' software
> and uses coresight framework to configure the connection from remote
> etm source to TMC sinks.
>
> Example to capture the remote etm trace:
>
> Enable source:
> echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> echo 1 > /sys/bus/coresight/devices/remote_etm0/enable_source
>
> Capture the trace:
> cat /dev/tmc_etf0 > /data/remote_etm.bin
>
> Disable source:
> echo 0 > /sys/bus/coresight/devices/remote_etm0/enable_source
>
> Changes since V5:
> 1. Fix the warning and error when compile.
> 2. Add traceid for remote etm.
> 3. Change qcom,qmi-id tp qcom,qmi-instance-id.
>
> Changes since V4:
> 1. Add coresight QMI driver
> 2. Add coresight qmi node and qcom,qmi-id of modem-etm in msm8996 dtsi
> V5: https://lwn.net/ml/all/20250424115854.2328190-1-quic_jinlmao@quicinc.com/
>
> Changes since V3:
> 1. Use different compatible for different remote etms in dt.
> 2. Get qmi instance id from the match table data in driver.
>
> Change since V2:
> 1. Change qcom,inst-id to qcom,qmi-id
> 2. Fix the error in code for type of remote_etm_remove
> 3. Depend on QMI helper in Kconfig
>
> Changes since V1:
> 1. Remove unused content
> 2. Use CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS as remote etm source type.
> 3. Use enabled instead of enable in driver data.
> 4. Validate instance id value where it's read from the DT.
>
> Mao Jinlong (5):
> dt-bindings: arm: Add CoreSight QMI component description
> coresight: Add coresight QMI driver
> dt-bindings: arm: Add qcom,qmi-id for remote etm
> coresight: Add remote etm support
> arm64: dts: qcom: msm8996: Add coresight qmi node
>
> .../bindings/arm/qcom,coresight-qmi.yaml | 65 +++++
> .../arm/qcom,coresight-remote-etm.yaml | 9 +
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 11 +
> drivers/hwtracing/coresight/Kconfig | 23 ++
> drivers/hwtracing/coresight/Makefile | 2 +
> drivers/hwtracing/coresight/coresight-qmi.c | 198 +++++++++++++
> drivers/hwtracing/coresight/coresight-qmi.h | 101 +++++++
> .../coresight/coresight-remote-etm.c | 262 ++++++++++++++++++
> 8 files changed, 671 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-qmi.yaml
> create mode 100644 drivers/hwtracing/coresight/coresight-qmi.c
> create mode 100644 drivers/hwtracing/coresight/coresight-qmi.h
> create mode 100644 drivers/hwtracing/coresight/coresight-remote-etm.c
>
> --
> 2.25.1
>
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Powered by blists - more mailing lists