Re: [PATCH v14 0/9] Coresight: Add support for TPDM and TPDA

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 08/11/2022 09:37, Suzuki K Poulose wrote:
> On 08/11/2022 05:54, Jinlong Mao wrote:
>>
>> On 11/8/2022 2:38 AM, Suzuki K Poulose wrote:
>>> On 02/11/2022 09:19, Mao Jinlong wrote:
>>>> This series adds support for the trace performance monitoring and
>>>> diagnostics hardware (TPDM and TPDA). It is composed of two major
>>>> elements.
>>>> a) Changes for original coresight framework to support for TPDM and 
>>>> TPDA.
>>>> b) Add driver code for TPDM and TPDA.
>>>>
>>>> Introduction of changes for original coresight framework
>>>> Support TPDM as new coresight source.
>>>> Since only STM and ETM are supported as coresight source originally.
>>>> TPDM is a newly added coresight source. We need to change
>>>> the original way of saving coresight path to support more types source
>>>> for coresight driver.
>>>> The following patch is to add support more coresight sources.
>>>>      coresight: core: Use IDR for non-cpu bound sources' paths.
>>>>
>>> ---8>---
>>>
>>>> Introduction of TPDM and TPDA
>>>> TPDM - The trace performance monitoring and diagnostics monitor or 
>>>> TPDM in
>>>> short serves as data collection component for various dataset types
>>>> specified in the QPMDA(Qualcomm performance monitoring and diagnostics
>>>> architecture) spec. The primary use case of the TPDM is to collect data
>>>> from different data sources and send it to a TPDA for packetization,
>>>> timestamping and funneling.
>>>>       Coresight: Add coresight TPDM source driver
>>>>       dt-bindings: arm: Adds CoreSight TPDM hardware definitions
>>>>       coresight-tpdm: Add DSB dataset support
>>>>       coresight-tpdm: Add integration test support
>>>>       docs: sysfs: coresight: Add sysfs ABI documentation for TPDM
>>>>
>>>> TPDA - The trace performance monitoring and diagnostics aggregator or
>>>> TPDA in short serves as an arbitration and packetization engine for the
>>>> performance monitoring and diagnostics network as specified in the 
>>>> QPMDA
>>>> (Qualcomm performance monitoring and diagnostics architecture)
>>>> specification. The primary use case of the TPDA is to provide
>>>> packetization, funneling and timestamping of Monitor data as specified
>>>> in the QPMDA specification.
>>>> The following patch is to add driver for TPDA.
>>>>       Coresight: Add TPDA link driver
>>>>       dt-bindings: arm: Adds CoreSight TPDA hardware definitions
>>>>
>>>> The last patch of this series is a device tree modification, which add
>>>> the TPDM and TPDA configuration to device tree for validating.
>>>>      ARM: dts: msm: Add coresight components for SM8250
>>>>      ARM: dts: msm: Add tpdm mm/prng for sm8250
>>>>
>>>> Once this series patches are applied properly, the tpdm and tpda nodes
>>>> should be observed at the coresight path /sys/bus/coresight/devices
>>>> e.g.
>>>> /sys/bus/coresight/devices # ls -l | grep tpd
>>>> tpda0 -> ../../../devices/platform/soc@0/6004000.tpda/tpda0
>>>> tpdm0 -> ../../../devices/platform/soc@0/6c08000.mm.tpdm/tpdm0
>>>>
>>>> We can use the commands are similar to the below to validate TPDMs.
>>>> Enable coresight sink first.
>>>>
>>>> echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
>>>> echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
>>>> echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test
>>>> echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test
>>>> The test data will be collected in the coresight sink which is enabled.
>>>> If rwp register of the sink is keeping updating when do
>>>> integration_test (by cat tmc_etf0/mgmt/rwp), it means there is data
>>>> generated from TPDM to sink.
>>>>
>>>> There must be a tpda between tpdm and the sink. When there are some
>>>> other trace event hw components in the same HW block with tpdm, tpdm
>>>> and these hw components will connect to the coresight funnel. When
>>>> there is only tpdm trace hw in the HW block, tpdm will connect to
>>>> tpda directly.
>>>>         +---------------+                +-------------+
>>>>      |  tpdm@6c08000 |                |tpdm@684C000 |
>>>>      +-------|-------+                +------|------+
>>>>              |                               |
>>>>      +-------|-------+                       |
>>>>      | funnel@6c0b000|                       |
>>>>      +-------|-------+                       |
>>>>              |                               |
>>>>      +-------|-------+                       |
>>>>      |funnel@6c2d000 |                       |
>>>>      +-------|-------+                       |
>>>>              |                               |
>>>>              |    +---------------+          |
>>>>              +----- tpda@6004000  -----------+
>>>>                   +-------|-------+
>>>>                           |
>>>>                   +-------|-------+
>>>>                   |funnel@6005000 |
>>>>                   +---------------+
>>>>
>>>
>>> --8<--
>>>
>>> Please could you add the above to a Documentation file (Of course
>>> skip the description of patches).
>> Sure. I will add them to the Documentation file.
>>>
>>>
>>>> This patch series depends on patch series:
>>>> "[v5,00/14] coresight: Add new API to allocate trace source ID values"
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/cover/20221101163103.17921-1-mike.leach@linaro.org/
>>>
>>> So, is there a strict binding between a TPDM and a TPDA ?
>>> i.e., Multiple TPDMs could never end up reaching the sam
>>> TPDA ? I see that the TPDMs could be connected to funnels
>>> and thus other TPDMs could be connected to the same funnels
>>> and thus reach the same TPDA.
>> There is no strict binding between TPDM and TPDA.
>> TPDA can have multiple TPDMs connect to it.
>> But There must be only one TPDA in the path from the TPDM source to 
>> TMC sink.
>> TPDM can directly connect to TPDA's inport
>> or connect to funnel which will connect to TPDA's inport.
>>>
>>> Also, the trace-id is bound to TPDA and not TPDM. So, if
>>> we have multiple TPDMs, trace decoding is going to be
>>> impossible.
>> The TPDMs which are connected to same TPDA shares the same
>> trace-id. When TPDA does packetization, different port will have
>> unique channel number for decoding.

So this assumes that nobody connects two TPDMs to a funnel, which
then connects to a TPDA ? (i.e. tpdm@684C000 above must not be
connected to funnel@6c0b000 or funnel@6c2d000).
In which case, two of them end up in the same port of the TPDA.

Suzuki



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel