CoreSight

coresight@lists.linaro.org

5 participants
2501 discussions

Re: [PATCH v1 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Tao Zhang

On 7/5/2024 5:02 PM, Krzysztof Kozlowski wrote: > On 05/07/2024 10:51, Tao Zhang wrote: >> Add a new property "filter_src" to label the source corresponding >> to the output connection for a static replicator. By combining >> a funnel and a static replicator in devicetree, a new device that >> supports multi-port input and multi-port output is implemented. >> In order to match the output port with the input port and >> successfully build the trace path, add this new property to >> indicate the data source corresponding to this output port. >> >> Signed-off-by: Tao Zhang<quic_taozha(a)quicinc.com> >> --- >> .../arm/arm,coresight-static-replicator.yaml | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> index 1892a091ac35..d9538563f9c6 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> @@ -45,7 +45,21 @@ properties: >> patternProperties: >> '^port@[01]$': >> description: Output connections to CoreSight Trace bus >> - $ref: /schemas/graph.yaml#/properties/port >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + >> + properties: >> + endpoint: >> + $ref: /schemas/media/video-interfaces.yaml# > Ehm? How is this video interface? I referred to other bindings which are done to add properties on endpoint node. How should I add "$ref" here if this video interface is incorrect? > >> + >> + properties: >> + filter_src: > There are no properties with underscores... Sure, I will change it to "filter-src" > >> + $ref: /schemas/types.yaml#/definitions/phandle >> + description: >> + defines a phandle reference to an associated CoreSight trace device. >> + When the associated trace device is enabled, then the respective >> + trace path will be built and enabled. > How does it differ from remote endpoint? What is "respective trace path"? "filter-src" is not the remote endpoint which connect to the current device. It indicate the source device reference of the trace path. Since our new funnel device fixes the correspondence between the output port and the input port by connecting a static replicator. Adding this property allows the driver to find the correct path for the output port in building the path. Best, Tao > > <form letter> > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC (and consider --no-git-fallback argument). It might > happen, that command when run on an older kernel, gives you outdated > entries. Therefore please be sure you base your patches on recent Linux > kernel. > > Tools like b4 or scripts/get_maintainer.pl provide you proper list of > people, so fix your workflow. Tools might also fail if you work on some > ancient tree (don't, instead use mainline) or work on fork of kernel > (don't, instead use mainline). Just use b4 and everything should be > fine, although remember about `b4 prep --auto-to-cc` if you added new > patches to the patchset. > </form letter> > > > Best regards, > Krzysztof >

1 year, 3 months

[GIT PULL] coresight: Updates for v6.11

by Suzuki K Poulose

Hi Greg, Please find the updates for coresight/hwtracing subsystem targeting v6.11. This is relatively smaller set of cleanups and a fix this time. Kindly pull Suzuki The following changes since commit c3f38fa61af77b49866b006939479069cd451173: Linux 6.10-rc2 (2024-06-02 15:44:56 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.11 for you to fetch changes up to 2e5657aa59669698f0f3bf7742d83577a18eb830: hwtracing: use for_each_endpoint_of_node() (2024-07-01 10:12:35 +0100) ---------------------------------------------------------------- coresight: Updates for v6.11 Coresight/hwtracing subsystem updates targeting v6.11 includes a few minor fixes and cleanups Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- James Clark (1): coresight: Fix ref leak when of_coresight_parse_endpoint() fails Kuninori Morimoto (1): hwtracing: use for_each_endpoint_of_node() Ricardo B. Marliere (1): coresight: constify the struct device_type usage Yang Li (1): coresight: tmc: Remove duplicated include in coresight-tmc-core.c drivers/hwtracing/coresight/coresight-platform.c | 8 +++++--- drivers/hwtracing/coresight/coresight-priv.h | 2 +- drivers/hwtracing/coresight/coresight-sysfs.c | 2 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 1 - 4 files changed, 7 insertions(+), 6 deletions(-)

1 year, 3 months

[PATCH v4 00/17] coresight: Use per-sink trace ID maps for Perf sessions

by James Clark

This will allow sessions with more than CORESIGHT_TRACE_IDS_MAX ETMs as long as there are fewer than that many ETMs connected to each sink. Each sink owns its own trace ID map, and any Perf session connecting to that sink will allocate from it, even if the sink is currently in use by other users. This is similar to the existing behavior where the dynamic trace IDs are constant as long as there is any concurrent Perf session active. It's not completely optimal because slightly more IDs will be used than necessary, but the optimal solution involves tracking the PIDs of each session and allocating ID maps based on the session owner. This is difficult to do with the combination of per-thread and per-cpu modes and some scheduling issues. The complexity of this isn't likely to worth it because even with multiple users they'd just see a difference in the ordering of ID allocations rather than hitting any limits (unless the hardware does have too many ETMs connected to one sink). Per-thread mode works but only until there are any overlapping IDs, at which point Perf will error out. Both per-thread mode and sysfs mode are left to future changes, but both can be added on top of this initial implementation and only sysfs mode requires further driver changes. The HW_ID version field hasn't been bumped in order to not break Perf which already has an error condition for other values of that field. Instead a new minor version has been added which signifies that there are new fields but the old fields are backwards compatible. Changes since v3: * Fix issue where trace IDs were overwritten by possibly invalid ones by Perf in unformatted mode. Now the HW_IDs are also used for unformatted mode unless the kernel didn't emit any. * Add a commit to check the OpenCSD version. * Add a commit to not save invalid IDs in the Perf header. * Replace cs_etm_queue's formatted and formatted_set members with a single enum which is easier to use. * Drop CORESIGHT_TRACE_ID_UNUSED_FLAG as it's no longer needed. * Add a commit to print the queue number in the raw dump. * Don't assert on the number of unformatted decoders if decoders == 0. Changes since v2: * Rebase on coresight-next 6.10-rc2 (b9b25c8496). * Fix double free of csdev if device registration fails. * Fix leak of coresight_trace_id_perf_start() if trace ID allocation fails. * Don't resend HW_ID for sink changes in per-thread mode. The existing CPU field on AUX records can be used to track this instead. * Tidy function doc for coresight_trace_id_release_all() * Drop first two commits now that they are in coresight-next * Add a commit to make the trace ID spinlock local to the map Changes since V1: * Rename coresight_device.perf_id_map to perf_sink_id_map. * Instead of outputting a HW_ID for each reachable ETM, output the sink ID and continue to output only the HW_ID once for each mapping. * Keep the first two Perf patches so that it applies cleanly on coresight-next, although they have been applied on perf-tools-next * Add new *_map() functions to the trace ID public API instead of modifying existing ones. * Collapse "coresight: Pass trace ID map into source enable" into "coresight: Use per-sink trace ID maps for Perf sessions" because the first commit relied on the default map being accessible which is no longer necessary due to the previous bullet point. James Clark (17): perf: cs-etm: Create decoders after both AUX and HW_ID search passes perf: cs-etm: Allocate queues for all CPUs perf: cs-etm: Move traceid_list to each queue perf: cs-etm: Create decoders based on the trace ID mappings perf: cs-etm: Only save valid trace IDs into files perf: cs-etm: Support version 0.1 of HW_ID packets perf: cs-etm: Print queue number in raw trace dump perf: cs-etm: Add runtime version check for OpenCSD coresight: Remove unused ETM Perf stubs coresight: Clarify comments around the PID of the sink owner coresight: Move struct coresight_trace_id_map to common header coresight: Expose map arguments in trace ID API coresight: Make CPU id map a property of a trace ID map coresight: Use per-sink trace ID maps for Perf sessions coresight: Remove pending trace ID release mechanism coresight: Emit sink ID in the HW_ID packets coresight: Make trace ID map spinlock local to the map drivers/hwtracing/coresight/coresight-core.c | 37 +- drivers/hwtracing/coresight/coresight-dummy.c | 3 +- .../hwtracing/coresight/coresight-etm-perf.c | 36 +- .../hwtracing/coresight/coresight-etm-perf.h | 18 - .../coresight/coresight-etm3x-core.c | 9 +- .../coresight/coresight-etm4x-core.c | 9 +- drivers/hwtracing/coresight/coresight-priv.h | 1 + drivers/hwtracing/coresight/coresight-stm.c | 3 +- drivers/hwtracing/coresight/coresight-sysfs.c | 3 +- .../hwtracing/coresight/coresight-tmc-etr.c | 5 +- drivers/hwtracing/coresight/coresight-tmc.h | 5 +- drivers/hwtracing/coresight/coresight-tpdm.c | 3 +- .../hwtracing/coresight/coresight-trace-id.c | 133 ++-- .../hwtracing/coresight/coresight-trace-id.h | 70 +- include/linux/coresight-pmu.h | 17 +- include/linux/coresight.h | 21 +- tools/build/feature/test-libopencsd.c | 4 +- tools/include/linux/coresight-pmu.h | 17 +- tools/perf/Makefile.config | 2 +- tools/perf/arch/arm/util/cs-etm.c | 11 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 49 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 3 +- .../util/cs-etm-decoder/cs-etm-min-version.h | 13 + tools/perf/util/cs-etm.c | 625 +++++++++++------- tools/perf/util/cs-etm.h | 12 +- 25 files changed, 636 insertions(+), 473 deletions(-) create mode 100644 tools/perf/util/cs-etm-decoder/cs-etm-min-version.h -- 2.34.1

1 year, 3 months

Re: [PATCH v5 3/7] hwtracing: use for_each_endpoint_of_node()

by Suzuki K Poulose

On 01/07/2024 03:32, Kuninori Morimoto wrote: > We already have for_each_endpoint_of_node(), don't use > of_graph_get_next_endpoint() directly. Replace it. > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> > Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> > Reviewed-by: James Clark <james.clark(a)arm.com> > --- > drivers/hwtracing/coresight/coresight-platform.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c > index 57a009552cc5..64e171eaad82 100644 > --- a/drivers/hwtracing/coresight/coresight-platform.c > +++ b/drivers/hwtracing/coresight/coresight-platform.c > @@ -275,7 +275,7 @@ static int of_get_coresight_platform_data(struct device *dev, > */ > if (!parent) { > /* > - * Avoid warnings in of_graph_get_next_endpoint() > + * Avoid warnings in for_each_endpoint_of_node() > * if the device doesn't have any graph connections > */ > if (!of_graph_is_present(node)) > @@ -286,7 +286,7 @@ static int of_get_coresight_platform_data(struct device *dev, > } > > /* Iterate through each output port to discover topology */ > - while ((ep = of_graph_get_next_endpoint(parent, ep))) { > + for_each_endpoint_of_node(parent, ep) { > /* > * Legacy binding mixes input/output ports under the > * same parent. So, skip the input ports if we are dealing Applied to coresight next https://git.kernel.org/coresight/c/2e5657aa5966 Thanks Suzuki

1 year, 3 months

Re: [PATCH] Coresight: Set correct cs_mode for TPDM to fix disable issue

by Suzuki K Poulose

On 25/06/2024 03:12, Jie Gan wrote: > The coresight_disable_source_sysfs function should verify the > mode of the coresight device before disabling the source. > However, the mode for the TPDM device is always set to > CS_MODE_DISABLED, resulting in the check consistently failing. > As a result, TPDM cannot be properly disabled. > > To fix the issue: > Configure CS_MODE_SYSFS/CS_MODE_PERF during the enablement of TPDM. > Configure CS_MODE_DISABLED during the disablement of TPDM. > > Fixes: 1f5149c7751c("coresight: Move all sysfs code to sysfs file") That looks like the wrong commit. This was a problem since the original TPDM driver. I would say : Fixes: b3c71626a933 ("Coresight: Add coresight TPDM source driver") > Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> Otherwise, the patch looks good to me. Please could you also fixup "dummy" source driver in a separate patch. Suzuki

1 year, 3 months

Re: [PATCH v1 0/2] perf mem: Support multiple Arm SPE PMUs

by James Clark

On 23/06/2024 14:34, Leo Yan wrote: > This patch series is to enable multiple Arm SPE PMUs. > > The patch 01 is to enable multiple Arm SPE PMUs. The second patch is to > print out warning if not all CPUs support memory events, this can give > users a hint that the memory profiling is absent on some CPUs. > > > Leo Yan (2): > perf arm-spe: Support multiple Arm SPE PMUs > perf mem: Warn if memory events are not supported on all CPUs > > tools/perf/arch/arm/util/pmu.c | 2 +- > tools/perf/util/mem-events.c | 14 ++++++++++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > Reviewed-by: James Clark <james.clark(a)arm.com>

1 year, 3 months

Re: [PATCH] coresight: constify the struct device_type usage

by Suzuki K Poulose

On Mon, 19 Feb 2024 10:43:05 -0300, Ricardo B. Marliere wrote: > Since commit aed65af1cc2f ("drivers: make device_type const"), the driver > core can properly handle constant struct device_type. Move the > coresight_dev_type variable to be a constant structure as well, placing it > into read-only memory which can not be modified at runtime. > > Applied, thanks! [1/1] coresight: constify the struct device_type usage https://git.kernel.org/coresight/c/4dcc0f95ca2a9738e5e4e3bd7571fd95a9cbf272 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

1 year, 3 months

Re: [PATCH v1 1/3] dt-bindings: arm: Add binding document for Coresight Slave Register device.

by Suzuki K Poulose

On 18/06/2024 08:27, Jie Gan wrote: > Add binding document for Coresight Slave Register device. Is this a made up name of the driver ? CoreSight Slave Register device sounds nowhere near to what it does. If you have a proper name for the "IP" please use that. > > Add a new property to TMC, qcom,csr-atid-offset, to indicate which > ATID registers will be used by the TMC ETR. Each TMC ETR device is > associated with four ATID registers that are continuous in address. > > Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> > --- > .../bindings/arm/arm,coresight-tmc.yaml | 8 ++ > .../bindings/arm/qcom,coresight-csr.yaml | 76 +++++++++++++++++++ > 2 files changed, 84 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > index cb8dceaca70e..295641a96c21 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > @@ -82,6 +82,14 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > maximum: 15 > > + qcom,csr-atid-offset: > + description: > + Offset to the coresight slave register component's ATID register > + that is used by specific TMC ETR. The ATID register can be programed according > + to the trace id to filter out specific trace data which gets through the ETR > + to the downstream components. > + $ref: /schemas/types.yaml#/definitions/uint32 Why do we need this ? Could this not be inferred from the "input port" to which this ETR is connected on the CSR ? e.g., input-0 : Offset 0 input-1 : Offset for Bank1 > + > in-ports: > $ref: /schemas/graph.yaml#/properties/ports > additionalProperties: false > diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > new file mode 100644 > index 000000000000..16f97cbe3d4b > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > @@ -0,0 +1,76 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/qcom,coresight-csr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: CoreSight Slave Register > + > +maintainers: > + - Yuanfang Zhang <quic_yuanfang(a)quicinc.com> > + - Mao Jinlong <quic_jinlmao(a)quicinc.com> > + - Jie Gan <quic_jiegan(a)quicinc.com> > + > +description: > + The Coresight Slave Register controls various Coresight behaviors. > + Used to enable/disable ETR’s data filter function based on trace ID. > + > +properties: > + compatible: > + const: qcom,coresight-csr > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + clock-names: > + maxItems: 1 > + items: > + - const: apb_pclk > + > + reg-names: > + items: > + - const: csr-base > + > + in-ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + patternProperties: > + '^port(@[0-7])?$': > + description: Input connections from CoreSight Trace bus > + $ref: /schemas/graph.yaml#/properties/port > + > +required: > + - compatible > + - reg > + - in-ports > + > +additionalProperties: false > + > +examples: > + - | > + syscon@10001000 { > + compatible = "qcom,coresight-csr"; > + reg = <0x0 0x10001000 0x0 0x1000>; > + reg-names = "csr-base"; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + csr_in_port0: endpoint { > + remote-endpoint = <&etr0_out_port>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + csr_in_port1: endpoint { > + remote-endpoint = <&etr1_out_port>; > + }; > + }; > + }; > + };

1 year, 4 months

Re: [PATCH v1 0/3] Add coresight slave register driver to support data filter function

by Suzuki K Poulose

On 18/06/2024 08:27, Jie Gan wrote: > The Coresight Slave Register(CSR) device hosts miscellaneous configuration > registers to control various features related to TMC ETR device. > > The CSR device works as a helper device physically connected to the TMC ETR device. > --------------------------------------------------------- > |ETR0| |ETR1| > . \ / . > . \ / . > . \ / . > . \ / . > --------------------------------------------------- > ETR0ATID0-ETR0ATID3 CSR ETR1ATID0-ETR1ATID3 > --------------------------------------------------- > Each ETR has four ATID registers with 128 bits long in total. > e.g. ETR0ATID0-ETR0ATID3 registers are used by ETR0 device. What is the maximum number of connections possible for CSR ? 2 ETRs ? > > Based on the trace id which is programed in CSR ATID register of > specific ETR, trace data with that trace id can get into ETR's buffer How do you handle cases where there are multiple TraceIDs in a the stream ? e.g., perf tracing a multi-threaded app ? Each ETM will have a distinct traceid. Is there way to disable filtering by CSR ? Side note, with James's trace id allocation per sink series makes this easier for the ETR to know the trace ids allocated for the current session. Works only for perf though. > while other trace data gets ignored. CSR may contain several ATID registers. > Each ATID register is associated with an ETR device. > > To achieve this function, the trace id is obtained and stored in the related > ETR device's driver data just before enabling the CSR. Then, the CSR > device can easily obtain the trace ID from the ETR's driver data because the > ETR's driver data is passed to the CSR's enable/disable functions. > > Ensure that every source device has already allocated a trace ID in its probe > session because the sink device should always be the first device to How is that possible ? We are going backwards in the trace id allocation with your proposal. What is the purpose of this hardware when you could use a replicator with trace filtering based on masks ? > enable when operating coresight_enable_path function. As a helper device of the > ETR, the CSR device will program the ATID register of a specific ETR according to > the trace id to enable data filter function at a very early stage. Without the > correct trace ID, the enablement session will not work. > > Each CSR's enable session will set one bit in the ATID register. So is this a bitmap of "enable/disable" ATID ? I really don't see the usecase of the CSR "device" yet. Please could you share "usecase" ? Suzuki > Every CSR's disbale seesion will reset all bits of the ATID register. > > This patch only supports sysfs mode. I will send the perf mode part patch > once it is ready. > > Looking forward to receiving comments as this is a new driver. > > Thanks! > > Jie Gan (3): > dt-bindings: arm: Add binding document for Coresight Slave Register > device. > coresight: Add coresight slave register driver to support data filter > function in sysfs mode > arm64: dts: qcom: Add CSR and ETR nodes for SA8775p > > .../bindings/arm/arm,coresight-tmc.yaml | 8 + > .../bindings/arm/qcom,coresight-csr.yaml | 49 +++ > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 167 ++++++++++ > drivers/hwtracing/coresight/Kconfig | 6 + > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-core.c | 6 +- > drivers/hwtracing/coresight/coresight-csr.c | 315 ++++++++++++++++++ > drivers/hwtracing/coresight/coresight-csr.h | 24 ++ > .../coresight/coresight-etm4x-core.c | 1 + > drivers/hwtracing/coresight/coresight-stm.c | 50 --- > drivers/hwtracing/coresight/coresight-sysfs.c | 45 ++- > .../hwtracing/coresight/coresight-tmc-core.c | 1 + > drivers/hwtracing/coresight/coresight-tmc.h | 2 + > include/linux/coresight-stm.h | 44 +++ > 14 files changed, 665 insertions(+), 54 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > create mode 100644 drivers/hwtracing/coresight/coresight-csr.c > create mode 100644 drivers/hwtracing/coresight/coresight-csr.h >

1 year, 4 months

[PATCH v3 00/14] coresight: Use per-sink trace ID maps for Perf sessions

by James Clark

This will allow sessions with more than CORESIGHT_TRACE_IDS_MAX ETMs as long as there are fewer than that many ETMs connected to each sink. Each sink owns its own trace ID map, and any Perf session connecting to that sink will allocate from it, even if the sink is currently in use by other users. This is similar to the existing behavior where the dynamic trace IDs are constant as long as there is any concurrent Perf session active. It's not completely optimal because slightly more IDs will be used than necessary, but the optimal solution involves tracking the PIDs of each session and allocating ID maps based on the session owner. This is difficult to do with the combination of per-thread and per-cpu modes and some scheduling issues. The complexity of this isn't likely to worth it because even with multiple users they'd just see a difference in the ordering of ID allocations rather than hitting any limits (unless the hardware does have too many ETMs connected to one sink). Per-thread mode works but only until there are any overlapping IDs, at which point Perf will error out. Both per-thread mode and sysfs mode are left to future changes, but both can be added on top of this initial implementation and only sysfs mode requires further driver changes. The HW_ID version field hasn't been bumped in order to not break Perf which already has an error condition for other values of that field. Instead a new minor version has been added which signifies that there are new fields but the old fields are backwards compatible. Changes since v2: * Rebase on coresight-next 6.10-rc2 (b9b25c8496). * Fix double free of csdev if device registration fails. * Fix leak of coresight_trace_id_perf_start() if trace ID allocation fails. * Don't resend HW_ID for sink changes in per-thread mode. The existing CPU field on AUX records can be used to track this instead. * Tidy function doc for coresight_trace_id_release_all() * Drop first two commits now that they are in coresight-next * Add a commit to make the trace ID spinlock local to the map Changes since V1: * Rename coresight_device.perf_id_map to perf_sink_id_map. * Instead of outputting a HW_ID for each reachable ETM, output the sink ID and continue to output only the HW_ID once for each mapping. * Keep the first two Perf patches so that it applies cleanly on coresight-next, although they have been applied on perf-tools-next * Add new *_map() functions to the trace ID public API instead of modifying existing ones. * Collapse "coresight: Pass trace ID map into source enable" into "coresight: Use per-sink trace ID maps for Perf sessions" because the first commit relied on the default map being accessible which is no longer necessary due to the previous bullet point. James Clark (14): perf: cs-etm: Create decoders after both AUX and HW_ID search passes perf: cs-etm: Allocate queues for all CPUs perf: cs-etm: Move traceid_list to each queue perf: cs-etm: Create decoders based on the trace ID mappings perf: cs-etm: Support version 0.1 of HW_ID packets coresight: Remove unused ETM Perf stubs coresight: Clarify comments around the PID of the sink owner coresight: Move struct coresight_trace_id_map to common header coresight: Expose map arguments in trace ID API coresight: Make CPU id map a property of a trace ID map coresight: Use per-sink trace ID maps for Perf sessions coresight: Remove pending trace ID release mechanism coresight: Emit sink ID in the HW_ID packets coresight: Make trace ID map spinlock local to the map drivers/hwtracing/coresight/coresight-core.c | 37 +- drivers/hwtracing/coresight/coresight-dummy.c | 3 +- .../hwtracing/coresight/coresight-etm-perf.c | 36 +- .../hwtracing/coresight/coresight-etm-perf.h | 18 - .../coresight/coresight-etm3x-core.c | 9 +- .../coresight/coresight-etm4x-core.c | 9 +- drivers/hwtracing/coresight/coresight-priv.h | 1 + drivers/hwtracing/coresight/coresight-stm.c | 3 +- drivers/hwtracing/coresight/coresight-sysfs.c | 3 +- .../hwtracing/coresight/coresight-tmc-etr.c | 5 +- drivers/hwtracing/coresight/coresight-tmc.h | 5 +- drivers/hwtracing/coresight/coresight-tpdm.c | 3 +- .../hwtracing/coresight/coresight-trace-id.c | 133 ++-- .../hwtracing/coresight/coresight-trace-id.h | 70 +- include/linux/coresight-pmu.h | 17 +- include/linux/coresight.h | 21 +- tools/include/linux/coresight-pmu.h | 17 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 28 +- tools/perf/util/cs-etm.c | 600 +++++++++++------- tools/perf/util/cs-etm.h | 2 +- 20 files changed, 614 insertions(+), 406 deletions(-) -- 2.34.1

1 year, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight