CoreSight

coresight@lists.linaro.org

1 participants
2095 discussions

Re: [PATCH V2 3/5] coresight: etm4x: Drop pid argument from etm4_probe()

by Suzuki K Poulose

On 31/03/2023 22:24, Steve Clevenger wrote: > > > On 3/31/2023 4:06 AM, Suzuki K Poulose wrote: >> On 27/03/2023 06:05, Anshuman Khandual wrote: >>> Coresight device pid can be retrieved from its iomem base address, >>> which is >>> stored in 'struct etm4x_drvdata'. This drops pid argument from >>> etm4_probe() >>> and 'struct etm4_init_arg'. Instead etm4_check_arch_features() derives >>> the >>> coresight device pid with a new helper coresight_get_pid(), right >>> before it >>> is consumed in etm4_hisi_match_pid(). >>> >>> 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: Leo Yan <leo.yan(a)linaro.org> >>> Cc: coresight(a)lists.linaro.org >>> Cc: linux-arm-kernel(a)lists.infradead.org >>> Cc: linux-kernel(a)vger.kernel.org >>> Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com> >>> --- >>> .../coresight/coresight-etm4x-core.c | 21 +++++++------------ >>> include/linux/coresight.h | 12 +++++++++++ >>> 2 files changed, 20 insertions(+), 13 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> index 5d77571a8df9..3521838ab4fb 100644 >>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> @@ -66,7 +66,6 @@ static u64 etm4_get_access_type(struct etmv4_config >>> *config); >>> static enum cpuhp_state hp_online; >>> struct etm4_init_arg { >>> - unsigned int pid; >>> struct device *dev; >>> struct csdev_access *csa; >>> }; >>> @@ -370,8 +369,10 @@ static void etm4_disable_arch_specific(struct >>> etmv4_drvdata *drvdata) >>> } >>> static void etm4_check_arch_features(struct etmv4_drvdata *drvdata, >>> - unsigned int id) >>> + struct csdev_access *csa) >>> { >>> + unsigned int id = coresight_get_pid(csa); >>> + >> >> This throws up the following error on an ETE. >> >> ete: trying to read unsupported register @fe0 >> >> So, I guess this must be performed only for iomem based >> devices. System instruction based device must be identified >> by MIDR_EL1/REVIDR_EL1 if needed for specific erratum. >> This is not required now. So, we could bail out early >> if we are system instruction based device. > > Besides this, the PID is limited to (I think) 4 bits of ID. TRCIDRs > offer revision information, but nothing manufacturer specific save for > the designer. Register fields like MIDR_EL1 Variant + PartNum + Revision > and TRCPIDR3 REVAND offer help. It may be a combination of registers are > needed for a manufacturer to adequately ID a part to apply an erratum. > Perhaps you could at least cache MIDR_EL1 for possible future use? Like I said, if we ever need them, we could add it. I don't see a point in storing it right now, if we don't use it. Suzuki

1 year, 7 months

[PATCH v3 0/11] Add support to configure TPDM DSB subunit

by Tao Zhang

Introduction of TPDM DSB subunit DSB 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 DSB subunit must be configured prior to enablement. This series adds support for TPDM to configure the configure DSB 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 DSB subunit. e.g. /sys/devices/platform/soc(a)0/69d0000.tpdm/tpdm0#ls -l | grep dsb -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_edge_ctrl -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_edge_ctrl_mask -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_mode -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_mask -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_ts -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_type -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_val -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_patt_mask -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_patt_val -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_ts -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_type We can use the commands are similar to the below to configure the TPDMs which support DSB subunit. Enable coresight sink first. echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/tpdm0/reset echo 0x3 0x3 0x1 > /sys/bus/coresight/devices/tpdm0/dsb_edge_ctrl_mask echo 0x6d 0x6d 0 > /sys/bus/coresight/devices/tpdm0/dsb_edge_ctrl echo 1 > /sys/bus/coresight/devices/tpdm0/dsb_patt_ts echo 1 > /sys/bus/coresight/devices/tpdm0/dsb_patt_type echo 0 > /sys/bus/coresight/devices/tpdm0/dsb_trig_ts echo 0 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/dsb_patt_mask echo 0 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/dsb_trig_patt_val This patch series depends on patch series "[PATCH v2 0/9] coresight: Fix CTI module refcount leak by making it a helper device" https://patchwork.kernel.org/project/linux-arm-kernel/cover/20230310160610.… TPDM_DSB commit tree: https://git.codelinaro.org/clo/linux-kernel/coresight/-/tree/tpdm-dsb-v3 https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-dsb-v3 Changes in V3: 1. Move the property "qcom,dsb-element-size" to TPDM devicetree and update the TPDM yaml file for this item. -- Suzuki K Poulose 2. Add the error message when the DSB element size is not set to 32-bit or 64-bit. -- Suzuki K Poulose 3. Add more information to the comments of patch #3 -- Suzuki K Poulose 4. Combine the value updates to the TPDM_DSB_CR for TPDM. -- Suzuki K Poulose 5. Remove the function "tpdm_datasets_alloc", and fold its code to a new function "tpdm_init_datasets". It will complete the initialization of TPDM. -- Suzuki K Poulose 6. Change the method of qualifying input values. -- Suzuki K Poulose 7. Add the documentation of the new sysfs handles. -- Suzuki K Poulose 8. Provide the separate handles for the "mode bits". -- Suzuki K Poulose Changes in V2: 1. Change the name of the property "qcom,dsb-elem-size" to "qcom,dsb-element-size" -- Suzuki K Poulose 2. Update the TPDA yaml file for the item "qcom,dsb-elem-size". -- Krzysztof Kozlowski 3. Add the full name of DSB in the description of the item "qcom,dsb-elem-size". -- Rob Herring Changes in V1: 1. Change the definition of the property "qcom,dsb-elem-size" from "uint32-array" to "uint32-matrix". -- Krzysztof Kozlowski 2. Add the full name of DSB. -- Rob Herring 3. Deal with 2 entries in an iteration in TPDA driver. -- Suzuki K Poulose 4. Divide the function "tpdm_datasets_alloc" into two functions, "tpdm_datasets_setup" and "tpdm_datasets_alloc". 5. Detecte the input string with the conventional semantics automatically, and constrain the size of the input value. -- Suzuki K Poulose 6. Use the hook function "is_visible()" to hide the DSB related knobs if the data sets are missing. -- Suzuki K Poulose 7. Use the macros "FIELD_GET" and "FIELD_PREP" to set the values. -- Suzuki K Poulose 8. Update the definition of the macros in TPDM driver. 9. Update the comments of the values for the nodes which are for DSB element creation and onfigure pattern match output. -- Suzuki K Poulose 10. Use API "sysfs_emit" to "replace scnprintf". -- Suzuki K Poulose Tao Zhang (10): dt-bindings: arm: Add support for DSB element size coresight-tpda: Add DSB dataset support coresight-tpdm: Initialize DSB subunit configuration coresight-tpdm: Add reset node to TPDM node coresight-tpdm: Add nodes to set trigger timestamp and type coresight-tpdm: Add node to set dsb programming mode coresight-tpdm: Add nodes for dsb edge control coresight-tpdm: Add nodes to configure pattern match output coresight-tpdm: Add nodes for timestamp request dt-bindings: arm: Add support for DSB MSR register coresight-tpdm: Add nodes for dsb msr support .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 144 +++++ .../bindings/arm/qcom,coresight-tpdm.yaml | 21 + drivers/hwtracing/coresight/coresight-tpda.c | 58 ++ drivers/hwtracing/coresight/coresight-tpda.h | 4 + drivers/hwtracing/coresight/coresight-tpdm.c | 694 ++++++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 69 ++ 6 files changed, 984 insertions(+), 6 deletions(-) -- 2.7.4

1 year, 7 months

[PATCH v9 0/3] perf: cs-etm: Update perf to handle new Coresight Trace ID

by Mike Leach

The original method for allocating trace source ID values to sources was to use a fixed algorithm for CPU based sources of (cpu_num * 2 + 0x10). The STM was allocated ID 0x1. This mechanism is broken for systems with more than 47 cores. The kernel related patches the provide a fixed Trace ID allocation mechanism are now upstreamed. This patchset updates the perf code to handle the changes to the trace ID notification mechanism that now uses the PERF_RECORD_AUX_OUTPUT_HW_ID packet to set Trace ID in the perf ETM decoders. Applies and test oo perf/core Changes since v8: 1. Fix build issues 2. Fix implicit function problem Changes since v7: Split from original patchset [1] to be sent separately as kernel related patches are now upstream. [1] https://lore.kernel.org/linux-arm-kernel/20230116124928.5440-1-mike.leach@l… Mike Leach (3): perf: cs-etm: Move mapping of Trace ID and cpu into helper function perf: cs-etm: Update record event to use new Trace ID protocol perf: cs-etm: Handle PERF_RECORD_AUX_OUTPUT_HW_ID packet tools/include/linux/coresight-pmu.h | 47 ++- tools/perf/arch/arm/util/cs-etm.c | 27 +- tools/perf/util/cs-etm-base.c | 3 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 7 + tools/perf/util/cs-etm.c | 326 +++++++++++++++--- tools/perf/util/cs-etm.h | 14 +- 6 files changed, 356 insertions(+), 68 deletions(-) -- 2.17.1

1 year, 7 months

[PATCH v8 0/3] perf: cs-etm: Update perf to handle new Coresight Trace ID

by Mike Leach

The original method for allocating trace source ID values to sources was to use a fixed algorithm for CPU based sources of (cpu_num * 2 + 0x10). The STM was allocated ID 0x1. This mechanism is broken for systems with more than 47 cores. The kernel related patches the provide a fixed Trace ID allocation mechanism are now upstreamed. This patchset updates the perf code to handle the changes to the trace ID notification mechanism that now uses the PERF_RECORD_AUX_OUTPUT_HW_ID packet to set Trace ID in the perf ETM decoders. Applies to perf/core Changes since v7: Split from original patchset [1] to be sent separately as kernel related patches are now upstream. [1] https://lore.kernel.org/linux-arm-kernel/20230116124928.5440-1-mike.leach@l… Mike Leach (3): perf: cs-etm: Move mapping of Trace ID and cpu into helper function perf: cs-etm: Update record event to use new Trace ID protocol perf: cs-etm: Handle PERF_RECORD_AUX_OUTPUT_HW_ID packet tools/include/linux/coresight-pmu.h | 47 ++- tools/perf/arch/arm/util/cs-etm.c | 21 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 7 + tools/perf/util/cs-etm.c | 326 +++++++++++++++--- tools/perf/util/cs-etm.h | 14 +- 5 files changed, 350 insertions(+), 65 deletions(-) -- 2.32.0

1 year, 7 months

Re: [BUG] perf: No samples found when using kcore + coresight

by Leo Yan

On Mon, Mar 13, 2023 at 11:15:44AM -0700, Yang Shi wrote: [...] > > Just a quick summary, here we have two issues: > > > > - With command: > > perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \ > > -- taskset --cpu-list 1 uname", > > > > perf doesn't enable "text poke" attribution. > > No, it enables "text poke" and perf fails to decode coresight trace > data too. It doesn't matter whether "--kcore" is after or before "-e > cs/etm/@tmc_etf63/k". Understand now. Thanks for correction, if so we can ignore this one. Leo

1 year, 7 months

Re: [BUG] perf: No samples found when using kcore + coresight

by James Clark

On 30/03/2023 00:25, Yang Shi wrote: > On Wed, Mar 29, 2023 at 9:08 AM James Clark <james.clark(a)arm.com> wrote: >> >> >> >> On 14/03/2023 00:36, Leo Yan wrote: >>> On Mon, Mar 13, 2023 at 11:15:44AM -0700, Yang Shi wrote: >>> >>> [...] >>> >>>>> Just a quick summary, here we have two issues: >>>>> >>>>> - With command: >>>>> perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \ >>>>> -- taskset --cpu-list 1 uname", >>>>> >>>>> perf doesn't enable "text poke" attribution. >>>> >>>> No, it enables "text poke" and perf fails to decode coresight trace >>>> data too. It doesn't matter whether "--kcore" is after or before "-e >>>> cs/etm/@tmc_etf63/k". >>> >>> Understand now. Thanks for correction, if so we can ignore this one. >>> >>> Leo >> >> To me it looks like it's only --per-thread and --kcore together that >> cause the issue. I can't see if that was mentioned previously in this >> thread. > > If "--pre-thread" is not passed in, perf record failed with "failed to > mmap with 12 (Cannot allocate memory)". Sorry for not mentioning this > in the first place. I was quite focused on --kcore and didn't realize > they may be related. That's unrelated. That's because you have specified a sink and without --per-thread it tries to open the event on all cores. If the sink can't be reached from all cores it will fail to open. You can make it work without --per-thread if you limit it to a valid core like this, although I don't know which ones exactly would be valid for your system: perf record -e cs_etm/@tmc_etf63/k --kcore -C 0 \ -- taskset --cpu-list 1 uname > >> >> If it is --per-thread that's causing the issue then I think I have an >> idea why it might be. There are some assumptions and different paths >> taken in decoding in that mode that aren't correct. It causes some other >> issues to do with ordering and timestamps as well and I wanted to fix it >> previously. I wouldn't say that the text-poke change has caused a >> regression, as decoding in this mode was always a bit buggy. >> >> Maybe this is another reason to fix it properly.

1 year, 7 months

[PATCH v2 0/9] coresight: Fix CTI module refcount leak by making it a helper device

by James Clark

Changes since v1: * Don't dereference handle in tmc_etr_get_buffer() when not in perf mode. * Fix some W=1 warnings * Add a commit to rename child/output in terms of local/remote ------------------- Currently there is a refcount leak in CTI when using system wide mode or tracing multithreaded applications. See the last commit for a reproducer. This prevents the module from being unloaded. Historically there have been a few issues and fixes attempted around here which have resulted in some extra logic and a member to keep track of CTI being enabled 'struct coresight_device->ect_enabled'. The fix in commit 665c157e0204 ("coresight: cti: Fix hang in cti_disable_hw()") was also related to CTI having its own enable/disable path which came later than other devices. If we make CTI a helper device and enable helper devices adjacent to the path we get very similar enable/disable behavior to now, but with more reuse of the existing reference counting logic in the coresight core code. This also affects CATU which can have a little bit of its hard coded enable/disable code removed. Enabling CATU on the generic path does require that input connections are tracked so that it can get its associated ETR buffer. Applies to coresight/next (669c4614236a7) but also requires the realloc_array patch here [1]. Also available in full here [2]. [1]: https://lore.kernel.org/linux-arm-kernel/20230306152723.3090195-1-james.cla… [2]: https://gitlab.arm.com/linux-arm/linux-jc/-/tree/james-cs-cti-module-refcou… James Clark (9): coresight: Use enum type for cs_mode wherever possible coresight: Change name of pdata->conns coresight: Rename nr_outports to nr_outconns coresight: Rename connection members to allow for input connections coresight: Dynamically add connections coresight: Store in-connections as well as out-connections coresight: Refactor out buffer allocation function for ETR coresight: Enable and disable helper devices adjacent to the path coresight: Fix CTI module refcount leak by making it a helper device drivers/hwtracing/coresight/coresight-catu.c | 34 +- drivers/hwtracing/coresight/coresight-core.c | 312 +++++++++++------- .../hwtracing/coresight/coresight-cti-core.c | 56 ++-- .../hwtracing/coresight/coresight-cti-sysfs.c | 4 +- drivers/hwtracing/coresight/coresight-cti.h | 4 +- drivers/hwtracing/coresight/coresight-etb10.c | 3 +- .../coresight/coresight-etm3x-core.c | 6 +- .../coresight/coresight-etm4x-core.c | 6 +- .../hwtracing/coresight/coresight-platform.c | 178 +++++++--- drivers/hwtracing/coresight/coresight-priv.h | 9 +- drivers/hwtracing/coresight/coresight-stm.c | 6 +- drivers/hwtracing/coresight/coresight-sysfs.c | 9 +- .../hwtracing/coresight/coresight-tmc-etf.c | 2 +- .../hwtracing/coresight/coresight-tmc-etr.c | 89 ++--- drivers/hwtracing/coresight/coresight-tmc.h | 2 + drivers/hwtracing/coresight/coresight-tpdm.c | 4 +- drivers/hwtracing/coresight/coresight-tpiu.c | 3 +- drivers/hwtracing/coresight/coresight-trbe.c | 3 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 3 +- drivers/hwtracing/coresight/ultrasoc-smb.h | 2 +- include/linux/coresight.h | 109 +++--- 21 files changed, 530 insertions(+), 314 deletions(-) -- 2.34.1

1 year, 7 months

[PATCH v1 0/8] Add cmb dataset support for TPDM

by Mao Jinlong

Continuous multi-bit (CMB) is responsible for collection of CMB data sets. It monitors a bus of related signals (eg, a counter value) and an associated valid signal. This patch series adds support to config of CMB registers. Element Creation: CMB_CR.mode : Continuous mode or Trace on Change mode(cmb_mode) Pattern Match Output (usually to CTI): CMB_XPR : Trigger pattern register value(cmb_trig_patt_val) CMB_XPMR : Trigger pattern mask register value(cmb_trig_patt_mask) Timestamp Request Based on Input Pattern Match: CMB_TPR : Timestamp pattern register value(cmb_patt_val) CMB_TPMR : Timestamp pattern mask register value(cmb_patt_mask) CMB_TIER.patt_tsenab : Timestamps are requested upon CMB interface pattern match via setting this bit to 1(cmb_patt_ts) Timestamp Request Based on Input (usually from CTI): CMB_TIER.xtrig_tsenab : Timestamps are requested upon CMB cross trigger interface timestamp request via setting this bit to 1(cmb_trig_ts) Mux Select Registers: CMB_MSR : Configure Mux select registers(cmb_msr) Once this series patches are applied properly, the new tpdm nodes should be observed at the tpdm path. e.g. /sys/devices/platform/soc(a)0/10c29000.tpdm/tpdm1 # ls -l | grep cmb -rw-r--r-- 1 root 0 4096 Jan 1 00:00 cmb_mode -rw-r--r-- 1 root 0 4096 Jan 1 00:00 cmb_msr -rw-r--r-- 1 root 0 4096 Jan 1 00:00 cmb_patt_mask -rw-r--r-- 1 root 0 4096 Jan 1 00:00 cmb_patt_ts -rw-r--r-- 1 root 0 4096 Jan 1 00:22 cmb_patt_val -rw-r--r-- 1 root 0 4096 Jan 1 00:59 cmb_trig_patt_mask -rw-r--r-- 1 root 0 4096 Jan 1 00:57 cmb_trig_patt_val -rw-r--r-- 1 root 0 4096 Jan 1 00:00 cmb_trig_ts -rw-r--r-- 1 root 0 4096 Jan 1 00:58 cmb_ts_all This patch series depends on: [v3,0/11] Add support to configure TPDM DSB subunit https://patchwork.kernel.org/project/linux-arm-kernel/cover/1679551448-1916… Codelinaro link: https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-cmb-v1 Mao Jinlong (8): coresight-tpdm: Add CMB dataset support coresight-tpdm: Add support to configure CMB collection mode coresight-tpdm: Add pattern registers support for CMB data set coresight-tpdm: Add timestamp control register support for the CMB coresight-tpdm: Add msr register support for CMB dt-bindings: arm: Add support for TPDM CMB MSR register coresight-tpda: Add support to configure CMB element size dt-bindings: arm: Add support for TPDM CMB element size .../testing/sysfs-bus-coresight-devices-tpdm | 63 +++ .../bindings/arm/qcom,coresight-tpdm.yaml | 26 + drivers/hwtracing/coresight/coresight-tpda.c | 33 +- drivers/hwtracing/coresight/coresight-tpda.h | 4 + drivers/hwtracing/coresight/coresight-tpdm.c | 447 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 60 +++ 6 files changed, 626 insertions(+), 7 deletions(-) -- 2.39.0

1 year, 7 months

Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver

by Suzuki K Poulose

On 28/03/2023 12:25, Hao Zhang wrote: > Hi Mike, > > On 3/28/2023 6:06 PM, Mike Leach wrote: >> Hi, >> >> A few additional comments.... >> >> On Tue, 28 Mar 2023 at 10:24, Hao Zhang <quic_hazha(a)quicinc.com> wrote: >>> >>> Hi Suzuki, >>> >>> On 3/28/2023 4:35 PM, Suzuki K Poulose wrote: >>>> On 28/03/2023 08:22, Hao Zhang wrote: >>>>> Hi Mike, >>>>> >>>>> On 3/27/2023 11:58 PM, Mike Leach wrote: >>>>>> Hi, >>>>>> >>>>>> On Fri, 24 Mar 2023 at 06:16, Hao Zhang <quic_hazha(a)quicinc.com> >>>>>> wrote: >>>>>>> >>>>>>> Some Coresight devices that HLOS don't have permission to access >>>>>>> or configure. Such as Coresight sink EUD, some TPDMs etc. So there >>>>>>> need driver to register dummy devices as Coresight devices. Provide >>>>>>> Coresight API for dummy device operations, such as enabling and >>>>>>> disabling dummy devices. Build the Coresight path for dummy sink or >>>>>>> dummy source for debugging. >>>>>>> >>>>>>> Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> >>>>>>> --- >>>>>>> drivers/hwtracing/coresight/Kconfig | 11 ++ >>>>>>> drivers/hwtracing/coresight/Makefile | 1 + >>>>>>> drivers/hwtracing/coresight/coresight-dummy.c | 176 >>>>>>> ++++++++++++++++++ >>>>>>> 3 files changed, 188 insertions(+) >>>>>>> create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> >>>>>>> diff --git a/drivers/hwtracing/coresight/Kconfig >>>>>>> b/drivers/hwtracing/coresight/Kconfig >>>>>>> index 2b5bbfffbc4f..06f0a7594169 100644 >>>>>>> --- a/drivers/hwtracing/coresight/Kconfig >>>>>>> +++ b/drivers/hwtracing/coresight/Kconfig >>>>>>> @@ -236,4 +236,15 @@ config CORESIGHT_TPDA >>>>>>> >>>>>>> To compile this driver as a module, choose M here: the >>>>>>> module will be >>>>>>> called coresight-tpda. >>>>>>> + >>>>>>> +config CORESIGHT_DUMMY >>>>>>> + tristate "Dummy driver support" >>>>>>> + help >>>>>>> + Enables support for dummy driver. Dummy driver can be used >>>>>>> for >>>>>>> + CoreSight sources/sinks that are owned and configured >>>>>>> by some >>>>>>> + other subsystem and use Linux drivers to configure rest of >>>>>>> trace >>>>>>> + path. >>>>>>> + >>>>>>> + To compile this driver as a module, choose M here: the >>>>>>> module will be >>>>>>> + called coresight-dummy. >>>>>>> endif >>>>>>> diff --git a/drivers/hwtracing/coresight/Makefile >>>>>>> b/drivers/hwtracing/coresight/Makefile >>>>>>> index 33bcc3f7b8ae..995d3b2c76df 100644 >>>>>>> --- a/drivers/hwtracing/coresight/Makefile >>>>>>> +++ b/drivers/hwtracing/coresight/Makefile >>>>>>> @@ -30,3 +30,4 @@ obj-$(CONFIG_CORESIGHT_TPDA) += coresight-tpda.o >>>>>>> coresight-cti-y := coresight-cti-core.o >>>>>>> coresight-cti-platform.o \ >>>>>>> coresight-cti-sysfs.o >>>>>>> obj-$(CONFIG_ULTRASOC_SMB) += ultrasoc-smb.o >>>>>>> +obj-$(CONFIG_CORESIGHT_DUMMY) += coresight-dummy.o >>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> b/drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> new file mode 100644 >>>>>>> index 000000000000..2d4eb3e546eb >>>>>>> --- /dev/null >>>>>>> +++ b/drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> @@ -0,0 +1,176 @@ >>>>>>> +// SPDX-License-Identifier: GPL-2.0 >>>>>>> +/* >>>>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights >>>>>>> reserved. >>>>>>> + */ >>>>>>> + >>>>>>> +#include <linux/kernel.h> >>>>>>> +#include <linux/module.h> >>>>>>> +#include <linux/platform_device.h> >>>>>>> +#include <linux/coresight.h> >>>>>>> +#include <linux/of.h> >>>>>>> +#include <linux/pm_runtime.h> >>>>>>> + >>>>>>> +#include "coresight-priv.h" >>>>>>> +#include "coresight-trace-id.h" >>>>>>> + >>>>>>> +struct dummy_drvdata { >>>>>>> + struct device *dev; >>>>>>> + struct coresight_device *csdev; >>>>>>> + int traceid; >>>>>>> +}; >>>>>>> + >>>>>>> +DEFINE_CORESIGHT_DEVLIST(dummy_devs, "dummy"); >>>>>>> + >> >> minor nit: can we have dummy_source and dummy_sink as the device names >> to make it clear at the first level what these are without having to >> look at the attributes? >> > > This is a good advice, dummy_source and dummy_sink are two different > components, so it's better to separate it at the first level. I will > take your advice in the next version of patch. > >>>>>>> +static int dummy_source_enable(struct coresight_device *csdev, >>>>>>> + struct perf_event *event, u32 mode) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy source enabled\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static void dummy_source_disable(struct coresight_device *csdev, >>>>>>> + struct perf_event *event) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy source disabled\n"); >>>>>>> +} >>>>>>> + >>>>>>> +static int dummy_sink_enable(struct coresight_device *csdev, u32 >>>>>>> mode, >>>>>>> + void *data) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy sink enabled\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static int dummy_sink_disable(struct coresight_device *csdev) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy sink disabled\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static const struct coresight_ops_source dummy_source_ops = { >>>>>>> + .enable = dummy_source_enable, >>>>>>> + .disable = dummy_source_disable, >>>>>>> +}; >>>>>>> + >>>>>>> +static const struct coresight_ops_sink dummy_sink_ops = { >>>>>>> + .enable = dummy_sink_enable, >>>>>>> + .disable = dummy_sink_disable, >>>>>>> +}; >>>>>>> + >>>>>>> +static const struct coresight_ops dummy_cs_ops = { >>>>>>> + .source_ops = &dummy_source_ops, >>>>>>> + .sink_ops = &dummy_sink_ops, >>>>>>> +}; >>>>>>> + >>>>>>> +static int dummy_probe(struct platform_device *pdev) >>>>>>> +{ >>>>>>> + int ret, trace_id; >>>>>>> + struct device *dev = &pdev->dev; >>>>>>> + struct coresight_platform_data *pdata; >>>>>>> + struct dummy_drvdata *drvdata; >>>>>>> + struct coresight_desc desc = { 0 }; >>>>>>> + >>>>>>> + desc.name = coresight_alloc_device_name(&dummy_devs, dev); >>>>>>> + if (!desc.name) >>>>>>> + return -ENOMEM; >>>>>>> + >>>>>>> + pdata = coresight_get_platform_data(dev); >>>>>>> + if (IS_ERR(pdata)) >>>>>>> + return PTR_ERR(pdata); >>>>>>> + pdev->dev.platform_data = pdata; >>>>>>> + >>>>>>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); >>>>>>> + if (!drvdata) >>>>>>> + return -ENOMEM; >>>>>>> + >>>>>>> + drvdata->dev = &pdev->dev; >>>>>>> + platform_set_drvdata(pdev, drvdata); >>>>>>> + >>>>>>> + if (of_property_read_bool(pdev->dev.of_node, >>>>>>> "qcom,dummy-source")) { >>>>>>> + desc.type = CORESIGHT_DEV_TYPE_SOURCE; >>>>>>> + desc.subtype.source_subtype = >>>>>>> + CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS; >>>>>>> + } else if (of_property_read_bool(pdev->dev.of_node, >>>>>>> + "qcom,dummy-sink")) { >> >> It would simplify things if the compatibles were >> arm,coresight-dummy-source and arm,coresight-dummy-sink - and drop the >> two additional attributes, using of_device_is_compatible() here. >> > > Yes, I will update it in the next version of patch. > >>>>>>> + desc.type = CORESIGHT_DEV_TYPE_SINK; >>>>>>> + desc.subtype.sink_subtype = >>>>>>> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER; >>>>>> >>>>>> This will break the automatic sink selection on a system where >>>>>> perf is >>>>>> looking for a default sink and the dummy sink is closest / first >>>>>> discovered. >>>>>> >>>>>> i.e. when perf record -e cs_etm// <options> >>>>>> is used to trace a program in linux, a dummy sink appearing in the >>>>>> coresight tree with this designation may be selected. >>>>>> >>>>>> This needs to be corrected, probably with a unique sub-type that >>>>>> appears before the CORESIGHT_DEV_SUBTYPE_SINK_BUFFER value in the >>>>>> enum >>>>>> as the selection is based on >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER. >>>>>> >>>> >>>> Good point Mike. >>>> >>>>>> By implication adding a new value - will possibly affect other code >>>>>> using the enum values so will need to be checked >>>>>> >>>>>> Regards >>>>>> >>>>>> Mike >>>>>> >>>>> >>>>> Thanks for your comments, I will add a new sub-type for dummy sink and >>>>> check the impact of it. >>>> >>>> Please keep this as the lowest priority, something like: >>>> >>>> enum coresight_dev_subtype_sink { >>>> + CORESIGHT_DEV_SUBTYPE_SINK_DUMMY, >>>> CORESIGHT_DEV_SUBTYPE_SINK_PORT, >>>> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER, >>>> CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM, >>>> CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM, >>>> }; >>>> >>>> This should be fine without any impact on the existing code, as we >>>> expect the driver modules to be updated with the new core module. >>>> >>>> Suzuki >>>> >>> >>> Sure, I will take your advice in the next version of patch. >>> >>> Thanks, >>> Hao >>> >>>> >>>>> >>>>> Thanks, >>>>> Hao >>>>> >>>>>> >>>>>>> + } else { >>>>>>> + dev_info(dev, "Device type not set\n"); >>>>>>> + return -EINVAL; >>>>>>> + } >>>>>>> + >>>>>>> + desc.ops = &dummy_cs_ops; >>>>>>> + desc.pdata = pdev->dev.platform_data; >>>>>>> + desc.dev = &pdev->dev; >>>>>>> + drvdata->csdev = coresight_register(&desc); >>>>>>> + if (IS_ERR(drvdata->csdev)) >>>>>>> + return PTR_ERR(drvdata->csdev); >>>>>>> + >>>>>>> + trace_id = coresight_trace_id_get_system_id(); >>>>>>> + if (trace_id < 0) { >>>>>>> + ret = trace_id; >>>>>>> + goto cs_unregister; >>>>>>> + } >>>>>>> + drvdata->traceid = (u8)trace_id; >>>>>>> + >> >> Number of issues here:- >> 1) Why are sinks being given a trace ID? - they do not need them. >> 2) how is the trace ID communicated to the underlying hardware system? >> - there appears to be no way of doing this here. Without this you >> cannot guarantee that there will not be clashes. >> Although your use case may mitigate against this - for this to be a >> generic module there must be a way to ensure the IDs can be discovered >> externally. >> 3) Trace IDs are a limited resource - most sources allocate on enable, >> release on disable / reset - this would be preferable. >> >> >> Regards >> >> Mike Good points Mike. > > 1. It should not be given a trace ID for sink, I will correct it in the > next version of patch. > 2. There are other patches to transmit the trace ID to sub-processor. > But We have an upstream dependency on QMI project. We will sync with > them for the other related patches. > 3. The trace ID of dummy source need to be communicated to the > sub-processor, it's better to be allocated on probe, that would reduce > communications costs. On the other hand, there will be few dummy > sources. I'd perfer to allocate it on probe function. Could that be delayed to dynamic allocation when the device is enabled ? Also, do we need a property for the dummy-source to "allocate" a traceID? i.e., add a "property" (not compatible) "arm,coresight-dummy-source-traceid" ? Suzuki > > Thanks, > Hao > >> >>>>>>> + pm_runtime_enable(dev); >>>>>>> + dev_info(dev, "Dummy device initialized\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> + >>>>>>> +cs_unregister: >>>>>>> + coresight_unregister(drvdata->csdev); >>>>>>> + >>>>>>> + return ret; >>>>>>> +} >>>>>>> + >>>>>>> +static int dummy_remove(struct platform_device *pdev) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = platform_get_drvdata(pdev); >>>>>>> + struct device *dev = &pdev->dev; >>>>>>> + >>>>>>> + coresight_trace_id_put_system_id(drvdata->traceid); >>>>>>> + pm_runtime_disable(dev); >>>>>>> + coresight_unregister(drvdata->csdev); >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static const struct of_device_id dummy_match[] = { >>>>>>> + {.compatible = "qcom,coresight-dummy"}, >>>>>>> + {}, >>>>>>> +}; >>>>>>> + >>>>>>> +static struct platform_driver dummy_driver = { >>>>>>> + .probe = dummy_probe, >>>>>>> + .remove = dummy_remove, >>>>>>> + .driver = { >>>>>>> + .name = "coresight-dummy", >>>>>>> + .of_match_table = dummy_match, >>>>>>> + }, >>>>>>> +}; >>>>>>> + >>>>>>> +static int __init dummy_init(void) >>>>>>> +{ >>>>>>> + return platform_driver_register(&dummy_driver); >>>>>>> +} >>>>>>> +module_init(dummy_init); >>>>>>> + >>>>>>> +static void __exit dummy_exit(void) >>>>>>> +{ >>>>>>> + platform_driver_unregister(&dummy_driver); >>>>>>> +} >>>>>>> +module_exit(dummy_exit); >>>>>>> + >>>>>>> +MODULE_LICENSE("GPL"); >>>>>>> +MODULE_DESCRIPTION("CoreSight dummy source driver"); >>>>>>> -- >>>>>>> 2.17.1 >>>>>>> >>>>>> >>>>>> >>>> >> >> >>

1 year, 7 months

Re: [PATCH v3 01/11] dt-bindings: arm: Add support for DSB element size

by Tao Zhang

Hi Krzysztof, On 3/25/2023 7:35 PM, Krzysztof Kozlowski wrote: > On 24/03/2023 10:15, Tao Zhang wrote: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + minimum: 32 >>>>> + maximum: 64 >>>> Shouldn't this be something like oneOf ? It is not a range, but one of >>>> those two specific values ? >>> Yes, "qcom,dsb-element-size" should be an optional option required in >>> TPDM >>> >>> devicetree. Other properties like "qcom,cmb-element-size", >>> "qcom,tc-element-size" >>> >>> and etc. will be added in a later patch series. >>> >>> I will update this doc according to your advice in the next version of >>> the patch. >>> >>> Tao >>> >> Correct my misunderstanding in the mail above. >> >> You are right, DSB element size should be 32-bit or 64-bit. I will >> update this in the next > Then 'enum', not 'oneOf'. Got it. Tao > > Best regards, > Krzysztof >

1 year, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight