I haven't done any meaningful work for a long while on Arm CoreSight and
it's unlikely I'll be able to do related work in the future.
Remove myself from the Arm CoreSight "Reviewers" list.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e0ad886d3163..342b8a3e19e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2102,7 +2102,6 @@ N: digicolor
ARM/CORESIGHT FRAMEWORK AND DRIVERS
M: Suzuki K Poulose <suzuki.poulose(a)arm.com>
R: Mike Leach <mike.leach(a)linaro.org>
-R: Leo Yan <leo.yan(a)linaro.org>
L: coresight(a)lists.linaro.org (moderated for non-subscribers)
L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers)
S: Maintained
--
2.39.2
This patch series is to add support for a streaming interface for
TMC ETR to allow for continuous log collection to secondary storage.
An interrupt based mechanism is used to stream out the data from the device.
QDSS_CS_QDSSCSR_ETRIRQCTRL register is used to set the IRQ byte counter
value. The value of this registers defines the number of bytes that when moved by
the ETR AXI interface. It will casues an interrupt which can be used by an
userspace program to know how much data is present in memory requiring copy to some
other location. A zero setting disables the interrupt.A one setting
means 8 bytes, two 16 bytes, etc. In other words, the value in this
register is the interrupt threshold times 8 bytes. ETR must be enabled
when use this interrupt function.
Sample:
echo 4096 > /sys/bus/coresight/devices/tmc_etr0/block_size
echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
echo 1 > /sys/bus/coresight/devices/stm0/enabl_source
cat /dev/byte-cntr > /data/qdss_etr.bin &
The log collection will stop after disabling the ETR.
Commit link:
https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/coresight-b…
Mao Jinlong (3):
Coresight: Add driver to support for CSR
coresight-tmc: byte-cntr: Add support for streaming interface for ETR
dt-bindings: arm: Adds CoreSight CSR hardware definitions
.../testing/sysfs-bus-coresight-devices-tmc | 7 +
.../bindings/arm/qcom,coresight-csr.yaml | 62 ++++
drivers/hwtracing/coresight/Kconfig | 12 +
drivers/hwtracing/coresight/Makefile | 3 +-
.../hwtracing/coresight/coresight-byte-cntr.c | 304 ++++++++++++++++++
.../hwtracing/coresight/coresight-byte-cntr.h | 49 +++
drivers/hwtracing/coresight/coresight-csr.c | 168 ++++++++++
drivers/hwtracing/coresight/coresight-csr.h | 59 ++++
.../hwtracing/coresight/coresight-tmc-core.c | 66 ++++
.../hwtracing/coresight/coresight-tmc-etr.c | 8 +-
drivers/hwtracing/coresight/coresight-tmc.h | 12 +-
11 files changed, 745 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml
create mode 100644 drivers/hwtracing/coresight/coresight-byte-cntr.c
create mode 100644 drivers/hwtracing/coresight/coresight-byte-cntr.h
create mode 100644 drivers/hwtracing/coresight/coresight-csr.c
create mode 100644 drivers/hwtracing/coresight/coresight-csr.h
--
2.17.1
CoreSight ETM4x devices could be accessed either via MMIO (handled via
amba_driver) or CPU system instructions (handled via platform driver). But
this has the following issues :
- Each new CPU comes up with its own PID and thus we need to keep on
adding the "known" PIDs to get it working with AMBA driver. While
the ETM4 architecture (and CoreSight architecture) defines way to
identify a device as ETM4. Thus older kernels won't be able to
"discover" a newer CPU, unless we add the PIDs.
- With ACPI, the ETM4x devices have the same HID to identify the device
irrespective of the mode of access. This creates a problem where two
different drivers (both AMBA based driver and platform driver) would
hook into the "HID" and could conflict. e.g., if AMBA driver gets
hold of a non-MMIO device, the probe fails. If we have single driver
hooked into the given "HID", we could handle them seamlessly,
irrespective of the mode of access.
- CoreSight is heavily dependent on the runtime power management. With
ACPI, amba_driver doesn't get us anywhere with handling the power
and thus one need to always turn the power ON to use them. Moving to
platform driver gives us the power management for free.
Due to all of the above, we are moving ACPI MMIO based etm4x devices to be
supported via tha platform driver. The series makes the existing platform
driver generic to handle both type of the access modes. Although existing
AMBA driver would still continue to support DT based etm4x MMIO devices.
Although some problems still remain, such as manually adding PIDs for all
new AMBA DT based devices.
The series applies on 6.4-rc4.
Changes in V5:
- Updated the comment for apb clock in drvdata structure
- Updated conditional check in etm4_runtime_suspend/resume()
- Asserted that the APB clock is present and also enabled
Changes in V4:
https://lore.kernel.org/all/20230523044553.1525048-1-anshuman.khandual@arm.…
- Changed in-code comment in etm4_check_arch_features()
- Re-ordered pm_runtime_disable() in etm4_remove_platform_dev()
- Renamed back etm4_match as etm4_sysreg_match
- Moved back [PATCH 6/6] as [PATCH 5/6]
Changes in V3:
https://lore.kernel.org/all/20230519052149.1367814-1-anshuman.khandual@arm.…
- Returned from etm4_check_arch_features() for non iomem devices
- Renamed ETM_DEVTYPE_ETMv4x_ARCH as CS_DEVTYPE_PE_TRACE
- Renamed is_etm4x_devtype() as is_devtype_cpu_trace()
- Added a patch to ignore the absence of graph connections
Changes in V2:
https://lore.kernel.org/all/20230327050537.30861-1-anshuman.khandual@arm.co…
- Enables ACPI etm4x device support in the existing platform driver
- Dropped last two patches from the series
- Dropped redundant 'devarch' checking from is_etm4x_device()
- Renamed updated is_etm4x_device() as is_etm4x_devtype()
- Fixed arguments in fallback stub for etm4_check_arch_features()
- Tagged etm4_dev_pm_ops with etm4_platform_driver
- Updated the comment for coresight_get_enable_apb_pclk() helper
- Updated the comment for new 'pclk' element in struct etm4_drvdata
- Dropped the clock when devm_ioremap_resource() fails
- Convert IS_ERR() into a direct pointer check in etm4_remove_platform_dev()
- Dropped "arm,coresight-etm4x" compatible property from etm4_match[]
Changes in V1:
https://lore.kernel.org/all/20230317030501.1811905-1-anshuman.khandual@arm.…
Cc: Ganapatrao Kulkarni <gankulkarni(a)os.amperecomputing.com>
Cc: Steve Clevenger <scclevenger(a)os.amperecomputing.com>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Frank Rowand <frowand.list(a)gmail.com>
Cc: Russell King (Oracle) <linux(a)armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael(a)kernel.org>
Cc: Len Brown <lenb(a)kernel.org>
Cc: Sudeep Holla <sudeep.holla(a)arm.com>
Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.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: Leo Yan <leo.yan(a)linaro.org>
Cc: devicetree(a)vger.kernel.org
Cc: linux-acpi(a)vger.kernel.org
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Anshuman Khandual (4):
coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier
coresight: etm4x: Drop iomem 'base' argument from etm4_probe()
coresight: etm4x: Drop pid argument from etm4_probe()
coresight: etm4x: Change etm4_platform_driver driver for MMIO devices
Suzuki K Poulose (2):
coresight: platform: acpi: Ignore the absence of graph
coresight: etm4x: Add ACPI support in platform driver
drivers/acpi/acpi_amba.c | 1 -
.../coresight/coresight-etm4x-core.c | 117 ++++++++++++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 4 +
.../hwtracing/coresight/coresight-platform.c | 6 +-
include/linux/coresight.h | 59 +++++++++
5 files changed, 163 insertions(+), 24 deletions(-)
--
2.25.1
Hi,
Sharing here the design notes and work in progress patches to get some
early feedback on the implementation approach.
Introduction
============
This RFC is about extending Linux coresight driver support to address
kernel panic and watchdog reset scenarios. This would help coresight
users to debug kernel panic and watchdog reset with the help of coresight
trace data.
For simplicity, watchdog and kernel panic are addressed in separate
sections.
Coresight trace capture: Kernel panic
-------------------------------------
From the coresight driver point of view, addressing the kernel panic
situation has four main requirements.
a. Support for allocation of trace buffer pages from reserved memory area.
Platform can advertise this using a new device tree property added to
relevant coresight nodes.
b. Support for stopping coresight blocks at the time of panic
c. Saving required metadata in the specified format
d. Support for reading trace data captured at the time of panic
Allocation of trace buffer pages from reserved RAM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A new optional device tree property "memory-region" will be added to the
ETR/ETF device nodes, that would give the base address and size of trace
buffer.
Static allocation of trace buffers would ensure that both IOMMU enabled
and disabled cases are handled. Also, platforms that support persistent
RAM will allow users to read trace data in the subsequent boot without
booting the crashdump kernel.
Note:
For ETR sink devices, this reserved region will be used for both trace
capture and trace data retrieval.
For ETF sink devices, internal SRAM would be used for trace capture,
and they would be synced to reserved region for retrieval.
Disabling coresight blocks at the time of panic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to avoid the situation of losing relevant trace data after a
kernel panic, it would be desirable to stop the coresight blocks at the
time of panic.
This can be achieved by configuring the comparator, CTI and sink
devices as below,
Comparator(triggers on kernel panic) --->External out --->CTI --
|
ETR/ETF stop <------External In <--------------
Note: No supporting patches are shared for this, since we are planning to
make use of the System configuration manager to achieve the required
configuration. This is a work in progress.
Saving metadata at the time of kernel panic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Coresight metadata involves all additional data that are required for a
successful trace decode in addition to the trace data. This involves
ETR/ETF, ETE register snapshot etc.
A new optional device property "memory-region" will be added to
the ETR/ETF/ETE device nodes for this.
Reading trace data captured at the time of panic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trace data captured at the time of panic, can be read from rebooted kernel
or from crashdump kernel using the below mentioned interface.
Steps for reading trace data captured in previous boot
++++++++++++++++++++++++++++++++++++++++++++++++++++++
1. cd /sys/bus/coresight/devices/tmc_etrXX/
2. Change to special mode called, read_prevboot.
#echo 1 > read_prevboot
3. Dump trace buffer data to a file,
#dd if=/dev/tmc_etrXX of=~/cstrace.bin
4. Reset back to normal mode
#echo 0 > read_prevboot
General flow of trace capture and decode incase of kernel panic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Enable source and sink on all the cores using the sysfs interface.
ETR sink will have trace buffers allocated from reserved memory.
2. Run relevant tests.
3. On a kernel panic, all coresight blocks are disabled, necessary
metadata is synced by kernel panic handler.
System would eventually reboot or boot a crashdump kernel.
4. For platforms that supports crashdump kernel, raw trace data can be
dumped using the coresight sysfs interface from the crashdump kernel
itself. Persistent RAM is not a requirement in this case.
5. For platforms that supports persistent RAM, trace data can be dumped
using the the coresight sysfs interface in the subsequent Linux boot.
Crashdump kernel is not a requirement in this case. Persistent RAM
ensures that trace data is intact across reboot.
Coresight trace capture: Watchdog reset
---------------------------------------
The main difference between addressing the watchdog reset and kernel panic
case are below,
a. Saving coresight metadata need to be taken care by the
SCP(system control processor) firmware in the specified format,
instead of kernel.
b. Reserved memory region given by firmware for trace buffer and metadata
has to be in persistent RAM.
Note: This is a requirement for watchdog reset case but optional
in kernel panic case.
Watchdog reset can be supported only on platforms that meet the above
two requirements.
Testing so far:
---------------
Watchdog reset has been tested on Marvell SOCs using the above approach
on 5.x kernel version with sysfs method.
Linu Cherian (5):
dt-bindings: arm: coresight-tmc: Add "memory-region" property
ccoresight: tmc-etr: Add support to use reserved trace memory
coresight: core: Add provision for panic callbacks
coresight: tmc: Add support for panic sync handling
coresight: tmc: Add support for reading tracedata from previous boot
.../bindings/arm/arm,coresight-tmc.yaml | 9 ++
drivers/hwtracing/coresight/coresight-core.c | 31 +++++
drivers/hwtracing/coresight/coresight-priv.h | 1 +
.../hwtracing/coresight/coresight-tmc-core.c | 112 ++++++++++++++++++
.../hwtracing/coresight/coresight-tmc-etf.c | 69 +++++++++++
.../hwtracing/coresight/coresight-tmc-etr.c | 98 ++++++++++++++-
drivers/hwtracing/coresight/coresight-tmc.h | 32 +++++
include/linux/coresight.h | 11 ++
8 files changed, 362 insertions(+), 1 deletion(-)
--
2.31.1
Some fixes to support an issue reported by Denis Nikitin where decoding
trace that contains different EL1 and EL2 kernels can crash or go into
an infinite loop because the wrong kernel maps are used for the decode.
This still doesn't support distinguishing guest and host userspace,
we'd still have to fix the timestamps and do a bit more work to
correlate that. And I've removed PERF_RECORD_MISC_HYPERVISOR as a
possible outcome of cs_etm__cpu_mode(). As far as I know this could
never have been returned anyway because machine__is_host(machine) was
always true due to session.machines.host being hard coded. And I'm not
sure of the relevance of the difference between PERF_RECORD_MISC_KERNEL
and PERF_RECORD_MISC_HYPERVISOR in this scenario.
The first commit is a tidy up, second fixes a bug that I found when
comparing the exception level and thread of branch records, the third
is the main fix, and the last commit is some extra error checking.
Applies to acme/perf-tools (4e111f0cf0)
James Clark (4):
perf cs-etm: Only track threads instead of PID and TIDs
perf cs-etm: Use previous thread for branch sample source IP
perf cs-etm: Track exception level
perf cs-etm: Add exception level consistency check
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 13 +-
.../perf/util/cs-etm-decoder/cs-etm-decoder.h | 4 +-
tools/perf/util/cs-etm.c | 220 +++++++++---------
tools/perf/util/cs-etm.h | 5 +-
4 files changed, 126 insertions(+), 116 deletions(-)
--
2.34.1
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/patch/20230425143542.…
TPDM_DSB commit tree:
https://git.codelinaro.org/clo/linux-kernel/coresight/-/tree/tpdm-dsb-v4https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-dsb-v4
Changes in V4:
1. Change the range of the property "qcom,dsb-element-size", and
change the type to enumeration.
-- Suzuki K Poulose, Krzysztof Kozlowski
2. Change dsb_esize from 32 bits to 8 bits.
-- Suzuki K Poulose
3. Update the function tpda_set_element_size since James has
updated the dependency series. Meanwhile, it will send out a
warning if it detects more than one TPDM from the same TPDA
input port.
-- Suzuki K Poulose
4. Add a source_sub_type for TPDM to distinguish TPDM from
the other coresight source.
-- Suzuki K Poulose
5. Return error if the element size is not configured on
devicetree in TPDA enablement.
-- Suzuki K Poulose
6. Move memory allocation from "tpdm_init_datasets" to
"tpdm_datasets_setup". Rename "tpdm_init_datasets" as
"tpdm_reset_datasets".
-- Suzuki K Poulose
7. Replace "coresight_disable" with "coresight_disable_source"
to disable the TPDM in resetting.
-- Suzuki K Poulose
8. Make sure "drvdata" is not NULL pointer before using it.
-- Suzuki K Poulose
9. Change "set_dsb_cycacc_mode" to "set_dsb_test_mode" since
cycle accurate mode is not supported on the current targets.
It is replaced by test mode.
10. Document the value of "dsb_mode".
-- Suzuki K Poulose
11. Macros are used to replace the formulas on dsb edge control
nodes.
-- Suzuki K Poulose
12. Document the values of "dsb_trig_patt_val" and
"dsb_trig_patt_mask".
-- Suzuki K Poulose
13. Combine two pattern related loops to one. And move DSB TIER
register configurations to the new function "set_dsb_tier".
-- Suzuki K Poulose
14. Rename the property "qcom,dsb_msr_num" to "qcom,dsb-msrs-num".
-- Suzuki K Poulose, Krzysztof Kozlowski
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 (11):
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 | 174 ++++++
.../bindings/arm/qcom,coresight-tpdm.yaml | 19 +
drivers/hwtracing/coresight/coresight-core.c | 1 +
drivers/hwtracing/coresight/coresight-tpda.c | 92 ++-
drivers/hwtracing/coresight/coresight-tpda.h | 4 +
drivers/hwtracing/coresight/coresight-tpdm.c | 691 ++++++++++++++++++++-
drivers/hwtracing/coresight/coresight-tpdm.h | 79 +++
include/linux/coresight.h | 1 +
8 files changed, 1045 insertions(+), 16 deletions(-)
--
2.7.4
Changes since v5:
* Formatting fixes
* helper->type != CORESIGHT_DEV_TYPE_HELPER -> !coresight_is_helper()
* Remove ect from coresight_dev_type and add a static assert so that
it stays in sync with the enum
------------------
Changes since v4:
* Update commit message on patch 1
* Drop previous change that added lockdep checks to coresight_add_helper()
because they are already in mutex_lock(). But keep extra comment.
* Check for allocation failure in coresight_add_out_conn()
------------------
Changes since v3:
* Put connection loss fix at the beginning so that it can be backported
* Replace coresight_find_link_{x}() with coresight_find_out_connection()
* Reorder coresight_enable_source() arguments for consistency
* Add source and destination reference counts so that two link devices
connected together don't clash
* Add coresight_is_helper()
* Fix overwriting csdev bug in coresight_orphan_match()
* Don't clear conns[i]->dest_fwnode in coresight_remove_conns() in case
it's used again
* Use dev instead of adev->dev for devmem allocation in
acpi_coresight_parse_graph() so that it's consistent with DT mode and
doesn't cause a warning on free.
* Rename coresight_add_helper_mutex() -> coresight_add_helper()
* Ensure coresight_mutex isn't already held in coresight_add_helper()
* Return new connection from coresight_add_out_conn()
* Comment and formatting improvements
------------------
Changes since v2:
* Make out_conns array contiguous instead of sparse which simplifies
filling and using it. New connections are always added to the end
* Store pointers to individual connection objects so that they can be
shared between inputs and outputs
* Fix an existing bug where connection info was lost when unloading a
device
* Simplify connection fixup functions. Now the orphan mechanism is used
for inputs in the same way as outputs to guarantee that all
connections have both an input and an output set
* Use input connections to disconnect devices on unload instead of
iterating through them all
* Make refcount a property of the connection rather than use it's own
array based on the number of inputs and outputs
* Fix a bug in v2 where helpers attached to the source device weren't
disabled because coresight-etm-perf.c was making a raw call to
disable rather than using a helper.
* Change names of connection members to make direction explicit now
that the connection is shared between input and outputs
------------------
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 (18996a113f256) but everything except the
first fixes commit requires the realloc_array patch here [1].
Also available in full here [2].
[1]: https://lore.kernel.org/linux-arm-kernel/20230320145710.1120469-1-james.cla…
[2]: https://gitlab.arm.com/linux-arm/linux-jc/-/tree/james-cs-cti-module-refcou…
James Clark (13):
coresight: Fix loss of connection info when a module is unloaded
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 make the direction explicit
coresight: Dynamically add connections
coresight: Store pointers to connections rather than an array of them
coresight: Simplify connection fixup mechanism
coresight: Store in-connections as well as out-connections
coresight: Make refcount a property of the connection
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 | 21 +-
drivers/hwtracing/coresight/coresight-core.c | 605 +++++++++---------
.../hwtracing/coresight/coresight-cti-core.c | 52 +-
.../hwtracing/coresight/coresight-cti-sysfs.c | 4 +-
drivers/hwtracing/coresight/coresight-cti.h | 4 +-
drivers/hwtracing/coresight/coresight-etb10.c | 13 +-
.../hwtracing/coresight/coresight-etm-perf.c | 4 +-
.../coresight/coresight-etm3x-core.c | 6 +-
.../coresight/coresight-etm4x-core.c | 6 +-
.../hwtracing/coresight/coresight-funnel.c | 26 +-
.../hwtracing/coresight/coresight-platform.c | 269 +++-----
drivers/hwtracing/coresight/coresight-priv.h | 17 +-
.../coresight/coresight-replicator.c | 23 +-
drivers/hwtracing/coresight/coresight-stm.c | 6 +-
drivers/hwtracing/coresight/coresight-sysfs.c | 17 +-
.../hwtracing/coresight/coresight-tmc-etf.c | 26 +-
.../hwtracing/coresight/coresight-tmc-etr.c | 110 ++--
drivers/hwtracing/coresight/coresight-tmc.h | 2 +
drivers/hwtracing/coresight/coresight-tpda.c | 23 +-
drivers/hwtracing/coresight/coresight-tpdm.c | 4 +-
drivers/hwtracing/coresight/coresight-tpiu.c | 7 +-
drivers/hwtracing/coresight/coresight-trbe.c | 3 +-
drivers/hwtracing/coresight/ultrasoc-smb.c | 11 +-
drivers/hwtracing/coresight/ultrasoc-smb.h | 2 +-
include/linux/coresight.h | 126 ++--
25 files changed, 714 insertions(+), 673 deletions(-)
--
2.34.1
All,
This is an RFC patch to allow all ETM4 instances to be detected via AMBA driver
without having to add the PIDs to the list. The AMBA driver already supports
checking the DEVTYPE and DEVARCH registers for CoreSight components. This patch
adds a pid,mask value that is bound to match all PIDs (with PIDR2.JEDEC field
mandated to be RA0).
With this patch, we wouldn't need to add the PIDs for newer CPUs to be able to
use them. An entry in the device tree is all we need. The only side effect of
this patch is :
If a DT description exists for an ETM and the CPU ETM has an erratum, the
driver may still probe it and use it. But then the DT shouldn't have
described it in the first place.
Thoughts?
Suzuki
---8>---
coresight: etm4x: Match all ETM4 instances based on DEVARCH
Instead of adding the PIDs forever to the list for the new CPUs, let us detect
a component to be ETMv4 based on the CoreSight CID, DEVTYPE=PE_TRACE and
DEVARCH=ETMv4. This is already done for some of the ETMs. We can extend the PID
matching to match the PIDR2:JEDEC, BIT[3], which must be 1 (RA0) always.
Link: https://lkml.kernel.org/r/20230317030501.1811905-1-anshuman.khandual@arm.com
Cc: Anshuman Khandual <anshuman.khandual(a)arm.com>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: frowand.list(a)gmail.com
Cc: linux(a)armlinux.org.uk
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
---
.../coresight/coresight-etm4x-core.c | 5 +++++
drivers/hwtracing/coresight/coresight-priv.h | 19 +++++++++++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 4c15fae534f3..8a2e24d5686a 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2260,6 +2260,11 @@ static const struct amba_id etm4_ids[] = {
CS_AMBA_UCI_ID(0x000cc0af, uci_id_etm4),/* Marvell ThunderX2 */
CS_AMBA_UCI_ID(0x000b6d01, uci_id_etm4),/* HiSilicon-Hip08 */
CS_AMBA_UCI_ID(0x000b6d02, uci_id_etm4),/* HiSilicon-Hip09 */
+ /*
+ * Match all PIDs with ETM4 DEVARCH. No need for adding any of the new
+ * CPUs to the list here.
+ */
+ CS_AMBA_MATCH_ALL_UCI(uci_id_etm4),
{},
};
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 595ce5862056..72ec36c9232c 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -193,12 +193,27 @@ extern void coresight_remove_cti_ops(void);
}
/* coresight AMBA ID, full UCI structure: id table entry. */
-#define CS_AMBA_UCI_ID(pid, uci_ptr) \
+#define __CS_AMBA_UCI_ID(pid, m, uci_ptr) \
{ \
.id = pid, \
- .mask = 0x000fffff, \
+ .mask = m, \
.data = (void *)uci_ptr \
}
+#define CS_AMBA_UCI_ID(pid, uci) __CS_AMBA_UCI_ID(pid, 0x000fffff, uci)
+/*
+ * PIDR2[JEDEC], BIT(3) must be 1 (Read As One) to indicate that rest of the
+ * PIDR1, PIDR2 DES_* fields follow JEDEC encoding for the designer. Use that
+ * as a match value for blanket matching all devices in the given CoreSight
+ * device type and architecture.
+ */
+#define PIDR2_JEDEC BIT(3)
+#define PID_PIDR2_JEDEC (PIDR2_JEDEC << 16)
+/*
+ * Match all PIDs in a given CoreSight device type and architecture, defined
+ * by the uci.
+ */
+#define CS_AMBA_MATCH_ALL_UCI(uci) \
+ __CS_AMBA_UCI_ID(PID_PIDR2_JEDEC, PID_PIDR2_JEDEC, uci)
/* extract the data value from a UCI structure given amba_id pointer. */
static inline void *coresight_get_uci_data(const struct amba_id *id)
--
2.34.1
(Removed irrelevant recipients), +Cc: coresight ml
Hi Greg,
On 15/05/2023 12:55, Greg KH wrote:
> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>
>>
>> On 13/05/2023 12:04, Greg KH wrote:
>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>> do their own multiplication overflow check so provide one.
>>>>
>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
>>>> Signed-off-by: James Clark <james.clark(a)arm.com>
>>>> ---
>>>> Documentation/driver-api/driver-model/devres.rst | 1 +
>>>> include/linux/device.h | 11 +++++++++++
>>>> 2 files changed, 12 insertions(+)
...
>> Maybe something could be done with some macro magic, but it would
>> probably end up being worse than just copying them and would affect the
>> real ones as well. So yeah I can't think of any easy gains either.
>
> Ok, that's good. Given a lack of objections from others, I'll just take
> this through my driver core tree in a few days.
Apologies for hijacking the thread. We have a series for CoreSight[1]
that depends on this series, which I see that, is queued in your
driver-core-next.
I would like to queue [1] for the next version (as there are other
work that depend on this, e.g., [2]). Do you have any
recommendations/comments on the proposal ? Are you able to share a
stable branch which can be merged to coresight/next and queue the
series ontop ? (PS: I haven't queued anything for coresight/next yet).
Kind regards
Suzuki