Messages in this thread | | | Date | Tue, 8 Nov 2022 09:40:54 +0000 | Subject | Re: [PATCH v14 0/9] Coresight: Add support for TPDM and TPDA | From | Suzuki K Poulose <> |
| |
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
| |