Now the instruction flow disasmed by arm-cs-trace-disasm.py is
ambiguous and uncorrect, fix them in one patch set. Please refer to
each patch for details.
Ruidong Tian (3):
perf scripts python: arm-cs-trace-disasm.py: print dso base address
perf scripts python: arm-cs-trace-disasm.py: set start vm addr of
exectable file to 0
perf scripts python: arm-cs-trace-disasm.py: do not ignore disam first
sample
.../scripts/python/arm-cs-trace-disasm.py | 28 +++++++++++--------
1 file changed, 16 insertions(+), 12 deletions(-)
--
2.33.1
On 1/17/2024 3:53 PM, Krzysztof Kozlowski wrote:
> On 17/01/2024 08:49, Jinlong Mao wrote:
>>
>>
>> On 1/17/2024 3:40 PM, Krzysztof Kozlowski wrote:
>>> On 17/01/2024 03:14, Jinlong Mao wrote:
>>>>>> - const: arm,embedded-trace-extension
>>>>>> @@ -55,13 +53,13 @@ examples:
>>>>>> # An ETE node without legacy CoreSight connections
>>>>>> - |
>>>>>> - ete0 {
>>>>>> + ete-0 {
>>>>>
>>>>> Why do we need the number ? why not simply "ete" as Krzysztof suggested ?
>>>>>
>>>>
>>>> Hi Suzuki & Krzysztof ,
>>>>
>>>> If name all the ete nodes' name as 'ete', there will be error below when
>>>> build images.
>>>>
>>>> arch/arm64/boot/dts/qcom/sm8450.dtsi:301.6-312.4: ERROR
>>>
>>> Why are you pasting DTSI for binding? How is it related? Do we talk
>>> about DTSI here? No, this is a binding patch.
>>>
>>
>> Hi Krzysztof,
>>
>> Do you mean the name in DTSI can be different from the name in binding ?
>
> Yes, we do not talk about DTSI here, so I did not suggest anything about
> DTSI.
Ok. I will use 'ete' as the name here.
Thanks
Jinlong Mao
>
> Best regards,
> Krzysztof
>
On 1/17/2024 3:40 PM, Krzysztof Kozlowski wrote:
> On 17/01/2024 03:14, Jinlong Mao wrote:
>>>> - const: arm,embedded-trace-extension
>>>> @@ -55,13 +53,13 @@ examples:
>>>> # An ETE node without legacy CoreSight connections
>>>> - |
>>>> - ete0 {
>>>> + ete-0 {
>>>
>>> Why do we need the number ? why not simply "ete" as Krzysztof suggested ?
>>>
>>
>> Hi Suzuki & Krzysztof ,
>>
>> If name all the ete nodes' name as 'ete', there will be error below when
>> build images.
>>
>> arch/arm64/boot/dts/qcom/sm8450.dtsi:301.6-312.4: ERROR
>
> Why are you pasting DTSI for binding? How is it related? Do we talk
> about DTSI here? No, this is a binding patch.
>
Hi Krzysztof,
Do you mean the name in DTSI can be different from the name in binding ?
Thanks
Jinlong Mao
>
Add coresight components on Qualcomm SM8450 Soc. The components include
TMC ETF/ETR, ETE, STM, TPDM, CTI. And remove the pattern of ete node
name.
Change since V1:
1. Remove the pattern match of ETE node name.
2. Update the tmc-etr node name in DT.
Mao Jinlong (2):
dt-bindings: arm: coresight: Remove pattern match of ETE node name
arm64: dts: qcom: Add coresight nodes for sm8450
.../arm/arm,embedded-trace-extension.yaml | 6 +-
arch/arm64/boot/dts/qcom/sm8450.dtsi | 742 ++++++++++++++++++
2 files changed, 744 insertions(+), 4 deletions(-)
--
2.41.0
With current design, the name of the non-cpu bounded coresight
component is the device type with the number. And with 'ls' command
we can get the register address of the component. But from these
information, we can't know what the HW or system the component belongs
to. Add device-name in DT to support it.
cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0
cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1
tpdm0 -> ../../../devices/platform/soc(a)0/10b0d000.tpdm/tpdm0
tpdm1 -> ../../../devices/platform/soc(a)0/10c28000.tpdm/tpdm1
tpdm2 -> ../../../devices/platform/soc(a)0/10c29000.tpdm/tpdm2
Change since V1:
1. Change coresight-name to device name.
2. Add the device-name in coresight dt bindings.
Mao Jinlong (2):
coresight: core: Add device name support
dt-bindings: arm: Add device-name in the coresight components
.../bindings/arm/arm,coresight-catu.yaml | 5 +++
.../bindings/arm/arm,coresight-cpu-debug.yaml | 5 +++
.../bindings/arm/arm,coresight-cti.yaml | 5 +++
.../arm/arm,coresight-dummy-sink.yaml | 5 +++
.../arm/arm,coresight-dummy-source.yaml | 5 +++
.../arm/arm,coresight-dynamic-funnel.yaml | 5 +++
.../arm/arm,coresight-dynamic-replicator.yaml | 5 +++
.../bindings/arm/arm,coresight-etb10.yaml | 5 +++
.../bindings/arm/arm,coresight-etm.yaml | 5 +++
.../arm/arm,coresight-static-funnel.yaml | 5 +++
.../arm/arm,coresight-static-replicator.yaml | 5 +++
.../bindings/arm/arm,coresight-stm.yaml | 5 +++
.../bindings/arm/arm,coresight-tmc.yaml | 5 +++
.../bindings/arm/arm,coresight-tpiu.yaml | 5 +++
.../bindings/arm/qcom,coresight-tpda.yaml | 5 +++
.../bindings/arm/qcom,coresight-tpdm.yaml | 5 +++
drivers/hwtracing/coresight/coresight-core.c | 33 ++++++++++---------
.../hwtracing/coresight/coresight-platform.c | 31 +++++++++++++++++
include/linux/coresight.h | 1 +
19 files changed, 130 insertions(+), 15 deletions(-)
--
2.41.0
Introduction of TPDM CMB(Continuous Multi Bit) subunit
CMB subunit is responsible for creating a dataset element, and is also
optionally responsible for packing it to fit multiple elements on a
single ATB transfer if possible in the configuration. The TPDM Core
Datapath requests timestamps be stored by the TPDA and then delivering
ATB sized data (depending on ATB width and element size, this could
be smaller or larger than a dataset element) to the ATB Mast FSM.
The CMB makes trace elements in two modes. In �continuous� mode, every
valid data cycle creates an element. In �trace on change� mode, when
valid data changes on the bus, a trace element is created. In
continuous mode, all cycles where this condition is true create trace
elements. In trace on change mode, a data element is only when the
previously sampled input is different from the current sampled input.
The CMB subunit must be configured prior to enablement. This series
adds support for TPDM to configure the configure CMB subunit.
Once this series patches are applied properly, the new tpdm nodes for
should be observed at the tpdm path /sys/bus/coresight/devices/tpdm*
which supports CMB subunit.
e.g.
root@qemuarm64:/sys/devices/platform/soc@0/684c000.tpdm/tpdm0# ls -l
-rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_mode
drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_msr
drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_patt
drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_trig_patt
-rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_trig_ts
-rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_ts_all
drwxr-xr-x 2 root root 0 Jan 1 00:00 connections
drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_edge
drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_msr
drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_patt
drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_trig_patt
-rw-r--r-- 1 root root 4096 Jan 1 00:00 enable_source
--w------- 1 root root 4096 Jan 1 00:00 integration_test
drwxr-xr-x 2 root root 0 Ja? 1 00:00 power
--w------- 1 root root 4096 Jan 1 00:00 reset_dataset
lrwxrwxrwx 1 root root 0 Apr 5 2021 subsystem -> ../../../../../bus/coresight
-rw-r--r-- 1 root root 4096 Apr 5 2021 uevent
-r--r--r-- 1 root root 4096 Jan 1 00:00 waiting_for_supplier
We can use the commands are similar to the below to configure the
TPDMs which support CMB subunit. Enable coresight sink first.
echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
echo 1 > /sys/bus/coresight/devices/tpdm0/reset_dataset
echo 1 > /sys/bus/coresight/devices/tpdm0/cmb_mode
echo 1 > /sys/bus/coresight/devices/tpdm0/cmb_patt/enable_ts
echo 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/cmb_patt/tpmr0
echo 0 > /sys/bus/coresight/devices/tpdm0/cmb_trig_ts
echo 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/cmb_trig_patt/xpr1
echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
codelinaro link:
https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-cmb-v3
Changes in V3:
1. Add 8-bit support to the description in the TPDM devicetree document.
-- Rob Herring
2. Change how the result is produced in "tpdm_read_element_size".
-- James Clark
3. Calling "tpdm_clear_element_size" at the beginning of
"tpda_enable_port".
-- James Clark
4. Use "dsb_esize" and "cmb_esize" to determine whether multiple TPDMs
are detected on a TPDA input port in "tpda_get_element_size".
-- James Clark
5. Modify the judgment logic in "tpda_enable_port".
-- James Clark
6. Add more description of "cmb_mode" to TPDM SysFS document.
-- James Clark
Changes in V2:
1. Optimizate and modify this patch series based on the patch series
"Add support to configure TPDM CMB subunit".
2. Modify the functions that read the element size of DSB/CMB in TPDA driver.
Tao Zhang (8):
dt-bindings: arm: Add support for CMB element size
coresight-tpda: Add support to configure CMB element
coresight-tpdm: Add CMB dataset support
coresight-tpdm: Add support to configure CMB
coresight-tpdm: Add pattern registers support for CMB
coresight-tpdm: Add timestamp control register support for the CMB
dt-bindings: arm: Add support for TPDM CMB MSR register
coresight-tpdm: Add msr register support for CMB
.../testing/sysfs-bus-coresight-devices-tpdm | 87 ++++
.../bindings/arm/qcom,coresight-tpdm.yaml | 38 ++
drivers/hwtracing/coresight/coresight-tpda.c | 117 +++---
drivers/hwtracing/coresight/coresight-tpda.h | 6 +
drivers/hwtracing/coresight/coresight-tpdm.c | 390 +++++++++++++++++-
drivers/hwtracing/coresight/coresight-tpdm.h | 87 ++++
6 files changed, 673 insertions(+), 52 deletions(-)
--
2.17.1
On 15/01/2024 05:05, Randy Dunlap wrote:
> Change an empty line inside of kernel-doc to a " *" (kernel-doc
> blank line) to prevent a kernel-doc warning:
>
> drivers/hwtracing/coresight/coresight-etm3x-core.c:118: warning: bad line:
>
> Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
> Cc: Pratik Patel <pratikp(a)codeaurora.org>
> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Cc: Mike Leach <mike.leach(a)linaro.org>
> Cc: James Clark <james.clark(a)arm.com>
> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
> Cc: coresight(a)lists.linaro.org
> Cc: linux-arm-kernel(a)lists.infradead.org
> ---
> drivers/hwtracing/coresight/coresight-etm3x-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -- a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> --- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
> @@ -115,7 +115,7 @@ static void etm_clr_pwrup(struct etm_drv
> *
> * Basically the same as @coresight_timeout except for the register access
> * method where we have to account for CP14 configurations.
> -
> + *
> * Return: 0 as soon as the bit has taken the desired state or -EAGAIN if
> * TIMEOUT_US has elapsed, which ever happens first.
> */
Duplicate of
https://lore.kernel.org/linux-arm-kernel/20231123120459.287578-3-james.clar…
which should appear in coresight-next soon. But either way, thanks for
the fix.
James
Hi Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
> Sent: Friday, January 5, 2024 3:24 PM
> To: Linu Cherian <lcherian(a)marvell.com>; suzuki.poulose(a)arm.com;
> mike.leach(a)linaro.org; james.clark(a)arm.com; leo.yan(a)linaro.org
> Cc: linux-arm-kernel(a)lists.infradead.org; coresight(a)lists.linaro.org; linux-
> kernel(a)vger.kernel.org; robh+dt(a)kernel.org;
> krzysztof.kozlowski+dt(a)linaro.org; conor+dt(a)kernel.org;
> devicetree(a)vger.kernel.org; Sunil Kovvuri Goutham
> <sgoutham(a)marvell.com>; George Cherian <gcherian(a)marvell.com>; Rob
> Herring <robh(a)kernel.org>
> Subject: [EXT] Re: [PATCH v6 1/7] dt-bindings: arm: coresight-tmc: Add
> "memory-region" property
>
> External Email
>
> ----------------------------------------------------------------------
> On 05/01/2024 06:58, Linu Cherian wrote:
> > memory-region 0: Reserved trace buffer memory
> >
> > TMC ETR: When available, use this reserved memory region for
> > trace data capture. Same region is used for trace data
> > retention after a panic or watchdog reset.
> >
> > TMC ETF: When available, use this reserved memory region for
> > trace data retention synced from internal SRAM after a panic or
> > watchdog reset.
> >
> > memory-region 1: Reserved meta data memory
> >
> > TMC ETR, ETF: When available, use this memory for register
> > snapshot retention synced from hardware registers after a panic
> > or watchdog reset.
> >
> > Reviewed-by: Rob Herring <robh(a)kernel.org>
>
> ...
>
> > + memory-region:
> > + items:
> > + - description: Reserved trace buffer memory for ETR and ETF sinks.
> > + For ETR, this reserved memory region is used for trace data capture.
> > + Same region is used for trace data retention as well after a panic
> > + or watchdog reset.
> > + This reserved memory region is used as trace buffer or used for
> trace
> > + data retention only if specifically selected by the user in sysfs
> > + interface.
> > + The default memory usage models for ETR in sysfs/perf modes are
> > + otherwise unaltered.
> > +
> > + For ETF, this reserved memory region is used by default for
> > + retention of trace data synced from internal SRAM after a panic
> > + or watchdog reset.
> > + - description: Reserved meta data memory. Used for ETR and ETF sinks
> > + for storing metadata.
>
> If there is going to be new version/resend, add a blank line here. Keep the Rb
> tag.
>
Okay. Will take care in next version.
Linu Cherian.
On 1/3/2024 11:32 PM, Rob Herring wrote:
> On Tue, Jan 2, 2024 at 5:05 AM Mike Leach <mike.leach(a)linaro.org> wrote:
>>
>> As James mentions this is clearly a V2 of a previous patch - please
>> mark as such in future.
>>
>> Adding to what James has already said:-
>>
>> 1) Mapping between the canonical names used in the drivers and the
>> information as to the precise device is as easy as running 'ls' on
>> /sys/bus/coresight/devices:-
>>
>> root@linaro-developer:/home/linaro/cs-mods# ls -al /sys/bus/coresight/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Jan 2 11:27 .
>> drwxr-xr-x 4 root root 0 Jan 2 11:27 ..
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu0 ->
>> ../../../devices/platform/soc(a)0/858000.cti/cti_cpu0
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu1 ->
>> ../../../devices/platform/soc(a)0/859000.cti/cti_cpu1
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu2 ->
>> ../../../devices/platform/soc(a)0/85a000.cti/cti_cpu2
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_cpu3 ->
>> ../../../devices/platform/soc(a)0/85b000.cti/cti_cpu3
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_sys0 ->
>> ../../../devices/platform/soc(a)0/810000.cti/cti_sys0
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 cti_sys1 ->
>> ../../../devices/platform/soc(a)0/811000.cti/cti_sys1
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm0 ->
>> ../../../devices/platform/soc(a)0/85c000.etm/etm0
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm1 ->
>> ../../../devices/platform/soc(a)0/85d000.etm/etm1
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm2 ->
>> ../../../devices/platform/soc(a)0/85e000.etm/etm2
>> lrwxrwxrwx 1 root root 0 Jan 2 11:27 etm3 ->
>> ../../../devices/platform/soc(a)0/85f000.etm/etm3
>> lrwxrwxrwx 1 root root 0 Jan 2 11:42 funnel0 ->
>> ../../../devices/platform/soc(a)0/821000.funnel/funnel0
>> lrwxrwxrwx 1 root root 0 Jan 2 11:42 funnel1 ->
>> ../../../devices/platform/soc(a)0/841000.funnel/funnel1
>> lrwxrwxrwx 1 root root 0 Jan 2 11:42 replicator0 ->
>> ../../../devices/platform/soc(a)0/824000.replicator/replicator0
>> lrwxrwxrwx 1 root root 0 Jan 2 11:42 tmc_etf0 ->
>> ../../../devices/platform/soc(a)0/825000.etf/tmc_etf0
>> lrwxrwxrwx 1 root root 0 Jan 2 11:42 tmc_etr0 ->
>> ../../../devices/platform/soc(a)0/826000.etr/tmc_etr0
>>
>>
>> 2) The patch set must contain the usage and specification in the .yaml
>> file(s) of the property used.
>
> For the record, I don't like "coresight-name". I don't have another
> suggestion because "easy" is not sufficient reasoning for why this is
> needed.
For example, if we want to configure the trigger and HW events for
modem, we can't know which cti or TPDM is for modem from current names.
lrwxrwxrwx 1 root 0 0 Jan 1 00:01 cti_sys0 ->
../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0
lrwxrwxrwx 1 root 0 0 Jan 1 00:01 cti_sys1 ->
../../../devices/platform/soc(a)0/13900000.cti/cti_sys1
lrwxrwxrwx 1 root 0 0 Jan 1 00:01 tpdm0 ->
../../../devices/platform/soc(a)0/10b0d000.tpdm/tpdm0
lrwxrwxrwx 1 root 0 0 Jan 1 00:01 tpdm1 ->
../../../devices/platform/soc(a)0/10c28000.tpdm/tpdm1
lrwxrwxrwx 1 root 0 0 Jan 1 00:01 tpdm2 ->
../../../devices/platform/soc(a)0/10c29000.tpdm/tpdm2
Thanks
Jinlong Mao
>
>> However, there was a standard property called 'name' which is
>> deprecated - see
>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetr…
>> section 2.3.11. I do not believe that adding another 'name' property
>> would be accepted by the DT maintainers.
>
> "name" is just the node name for anything in the last 15 years. They
> used to be separate, but would still mostly be the same. The only case
> I found with them different was old PowerPC Macs.
>
>> 3) the 'device_node' structure has a 'name' field that contains the
>> node name in the DT approved "node-name@unit-address" format.
>
> Actually, it is without the unit-address. full_name is with the unit-address.
>
>> This
>> contains whatever node names you used in the dt. Why not use this if
>> a change has to be made and find some conditional to activate it.
>
> Don't go accessing "name" or "full_name" directly. I intend to get rid
> of "name" and generate it from full_name. So use the accessors and
> printk specifiers if you need node names.
>
> Rob