CoreSight

coresight@lists.linaro.org

2 participants
2382 discussions

Re: [PATCH v3 7/8] dt-bindings: arm: Add support for TPDM CMB MSR register

by Suzuki K Poulose

Tao Zhang, On 21/11/2023 07:24, Krzysztof Kozlowski wrote: > On 21/11/2023 03:24, Tao Zhang wrote: >> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select register) >> for TPDM. It specifies the number of CMB MSR registers supported by >> the TDPM. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- > > I prefer not to take any new Qualcomm Coresight bindings or Qualcomm SoC > DTS nodes with Coresight till we fix all existing warnings. I don't know > how to fix them, so I need help with them. No such fixing happened so > far from Qcom, so pushback is my only way to get any attention. > > I already commented on this in other email thread. Are you addressing this ? Suzuki > > Best regards, > Krzysztof >

1 year, 6 months

Re: [PATCH v3 1/8] dt-bindings: arm: Add support for CMB element size

by Tao Zhang

On 11/21/2023 3:24 PM, Krzysztof Kozlowski wrote: > On 21/11/2023 03:24, Tao Zhang wrote: >> Add property "qcom,cmb-elem-size" to support CMB(Continuous >> Multi-Bit) element for TPDM. The associated aggregator will read >> this size before it is enabled. CMB element size currently only >> supports 32-bit and 64-bit. > >> qcom,dsb-msrs-num: >> description: >> Specifies the number of DSB(Discrete Single Bit) MSR(mux select register) >> @@ -110,4 +119,23 @@ examples: >> }; >> }; >> >> + tpdm@6c29000 { >> + compatible = "qcom,coresight-tpdm", "arm,primecell"; >> + reg = <0x06c29000 0x1000>; >> + reg-names = "tpdm-base"; >> + >> + qcom,cmb-element-size = /bits/ 8 <64>; > One new property usually does not justify new example. Why it cannot be > added to existing example? Because the existing example tpdm "tpdm@684c000" which only supports dsb sub-unit. Most TPDMs only support one type of sub-unit. > > Anyway, I prefer not to take any new Qualcomm Coresight bindings or > Qualcomm SoC DTS nodes with Coresight till we fix all existing warnings. > I don't know how to fix them, so I need help with them. No such fixing > happened so far from Qcom, so pushback is my only way to get any attention. > > I already commented on this in other email thread. Jinlong has fixed the warnings from coresight bindings. I will prepare my next patch series soon. Best, Tao > > Best regards, > Krzysztof >

1 year, 6 months

[GIT PULL] coresight: Updates for linux v6.8

by Suzuki K Poulose

Hi Greg Please find the updates for coresight and hwtracing subsystems targeting Linux v6.8. Please note that the branch is based on the stable tag, "coresight-fixes-for-v6.7-rc1" (which was merged in v6.7-rc5, on v6.7-rc1). i.e, coresight-next-v6.8....coresight-fixes-for-v6.7-rc1...v6.7-rc1 Kindly pull Suzuki The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.8 for you to fetch changes up to 60e5f23dc5d68ec01e6dae8f4311230c7d2ccb8a: coresight: ultrasoc-smb: Use guards to cleanup (2023-11-21 11:21:59 +0000) ---------------------------------------------------------------- coresight: Updates for Linux v6.8 Updates for the hwtracing subsystem includes : - Support for CoreSight TPDM DSB set - Support for tuning Cycle count Threshold for CoreSight ETM via perf - Support for TRBE on ACPI based systems - Support for choosing buffer mode in ETR for sysfs mode - Improvements to HiSilicon PTT driver - Cleanups to Ultrasoc SMB driver - Cleanup .remove callback for various Coresight platform drivers - Remove Leo Yan from Reviewers Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- Anshuman Khandual (6): coresight: trbe: Add a representative coresight_platform_data for TRBE coresight: trbe: Enable ACPI based TRBE devices coresight: etm: Override TRCIDR3.CCITMIN on errata affected cpus coresight: etm: Make cycle count threshold user configurable Documentation: coresight: Add cc_threshold tunable coresight: tmc: Make etr buffer mode user configurable from sysfs Bagas Sanjaya (1): Documentation: ABI: coresight-tpdm: Fix Bit[3] description indentation James Clark (2): coresight: Fix crash when Perf and sysfs modes are used concurrently coresight: etm4x: Fix width of CCITMIN field Junhao He (5): hwtracing: hisi_ptt: Add dummy callback pmu::read() coresight: ultrasoc-smb: Fix sleep while close preempt in enable_smb coresight: ultrasoc-smb: Config SMB buffer before register sink coresight: ultrasoc-smb: Fix uninitialized before use buf_hw_base coresight: ultrasoc-smb: Use guards to cleanup Leo Yan (1): MAINTAINERS: Remove myself as a Arm CoreSight reviewer Tao Zhang (14): coresight-tpdm: Remove the unnecessary lock dt-bindings: arm: Add support for DSB element size coresight-tpdm: Introduce TPDM subtype to TPDM driver 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 coresight-tpdm: Correct the property name of MSR number Uwe Kleine-König (7): coresight: etm4x: Remove bogous __exit annotation for some functions coresight: dummy: Convert to platform remove callback returning void coresight: etm4x: Convert to platform remove callback returning void coresight: funnel: Convert to platform remove callback returning void coresight: replicator: Convert to platform remove callback returning void coresight: trbe: Convert to platform remove callback returning void coresight: ultrasoc-smb: Convert to platform remove callback returning void Vegard Nossum (1): Documentation: coresight: fix `make refcheckdocs` warning Yicong Yang (4): hwtracing: hisi_ptt: Handle the interrupt in hardirq context hwtracing: hisi_ptt: Don't try to attach a task hwtracing: hisi_ptt: Disable interrupt after trace end hwtracing: hisi_ptt: Optimize the trace data committing .../ABI/testing/sysfs-bus-coresight-devices-tmc | 16 + .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 159 +++++ Documentation/arch/arm64/silicon-errata.rst | 10 + .../bindings/arm/qcom,coresight-tpdm.yaml | 20 + Documentation/trace/coresight/coresight.rst | 6 +- MAINTAINERS | 1 - drivers/hwtracing/coresight/coresight-core.c | 3 + drivers/hwtracing/coresight/coresight-dummy.c | 5 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 6 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 56 +- drivers/hwtracing/coresight/coresight-etm4x.h | 2 +- drivers/hwtracing/coresight/coresight-funnel.c | 5 +- drivers/hwtracing/coresight/coresight-replicator.c | 5 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 15 +- drivers/hwtracing/coresight/coresight-tmc-etr.c | 111 +++- drivers/hwtracing/coresight/coresight-tmc.h | 3 + drivers/hwtracing/coresight/coresight-tpda.c | 126 +++- drivers/hwtracing/coresight/coresight-tpda.h | 2 + drivers/hwtracing/coresight/coresight-tpdm.c | 718 ++++++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 161 +++++ drivers/hwtracing/coresight/coresight-trbe.c | 28 +- drivers/hwtracing/coresight/coresight-trbe.h | 2 + drivers/hwtracing/coresight/ultrasoc-smb.c | 118 ++-- drivers/hwtracing/coresight/ultrasoc-smb.h | 6 +- drivers/hwtracing/ptt/hisi_ptt.c | 33 +- drivers/hwtracing/ptt/hisi_ptt.h | 1 + include/linux/coresight.h | 1 + 27 files changed, 1463 insertions(+), 156 deletions(-)

1 year, 6 months

[PATCH V3 00/10] coresight: Move remaining AMBA ACPI devices into platform driver

by Anshuman Khandual

This moves remaining AMBA ACPI devices into respective platform drivers for enabling ACPI based power management support. This series applies on latest coresight/next branch. This series has been built, and boot tested on a DT based coresight platform. Although this still requires some more testing on ACPI based coresight platforms. https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v3) Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: Sudeep Holla <sudeep.holla(a)arm.com> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com> Cc: linux-acpi(a)vger.kernel.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: coresight(a)lists.linaro.org Cc: linux-stm32(a)st-md-mailman.stormreply.com Changes in V3: - Split coresight_init_driver/remove_driver() helpers into a separate patch - Added 'drvdata->pclk' comments in replicator, funnel, tpiu, tmc, and stm devices - Updated funnel, and replicator drivers to use these new helpers - Check for drvdata instead of drvdata->pclk in suspend and resume paths in catu, tmc and debug devices - Added patch to extract device name from AMBA pid based table lookup for stm - Added patch to extract device properties from AMBA pid based table look for tmc - Dropped pm_runtime_put() from common __probe() functions - Handled pm_runtime_put() in AMBA driver in success path - Handled pm_runtime_put() in platform driver in both success and error paths Changes in V2: https://lore.kernel.org/all/20231201062053.1268492-1-anshuman.khandual@arm.… - Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe() - Defined coresight_[init|remove]_driver() for both AMBA/platform drivers - Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new helpers avoiding build issues arising from module_amba_driver(), and module_platform_driver() being on the same file Changes in V1: https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual@arm.… - Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki Changes in RFC: https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual@arm.… Anshuman Khandual (10): coresight: stm: Extract device name from AMBA pid based table lookup coresight: tmc: Extract device properties from AMBA pid based table lookup coresight: Add helpers registering/removing both AMBA and platform drivers coresight: replicator: Move ACPI support from AMBA driver to platform driver coresight: funnel: Move ACPI support from AMBA driver to platform driver coresight: catu: Move ACPI support from AMBA driver to platform driver coresight: tpiu: Move ACPI support from AMBA driver to platform driver coresight: tmc: Move ACPI support from AMBA driver to platform driver coresight: stm: Move ACPI support from AMBA driver to platform driver coresight: debug: Move ACPI support from AMBA driver to platform driver drivers/acpi/arm64/amba.c | 8 - drivers/hwtracing/coresight/coresight-catu.c | 140 +++++++++++++--- drivers/hwtracing/coresight/coresight-catu.h | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 ++++ .../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++-- .../hwtracing/coresight/coresight-funnel.c | 87 +++++----- drivers/hwtracing/coresight/coresight-priv.h | 10 ++ .../coresight/coresight-replicator.c | 81 ++++----- drivers/hwtracing/coresight/coresight-stm.c | 115 +++++++++++-- .../hwtracing/coresight/coresight-tmc-core.c | 156 +++++++++++++++--- drivers/hwtracing/coresight/coresight-tmc.h | 2 + drivers/hwtracing/coresight/coresight-tpiu.c | 99 +++++++++-- include/linux/coresight.h | 7 + 13 files changed, 713 insertions(+), 163 deletions(-) -- 2.25.1

1 year, 6 months

Re: [PATCH V2] coresight: tmc: Make etr buffer mode user configurable from sysfs

by Suzuki K Poulose

Hi Steve On 04/12/2023 21:41, Steve Clevenger wrote: > > Hi Suzuki, > > On 9/7/2023 2:31 PM, Steve Clevenger wrote: >> >> Hi Suzuki, >> >> On 9/1/2023 5:22 AM, Suzuki K Poulose wrote: >>> Hi Steve >>> >>> On 30/08/2023 17:04, Suzuki K Poulose wrote: >>>> Cc: Sudeep >>>> >>>> Hi Steve >>>> >>>> On 28/08/2023 17:35, Steve Clevenger wrote: >>>>> >>>>> Hi Suzuki, >>>>> >>>>> On 8/27/2023 2:35 PM, Suzuki K Poulose wrote: >>>>>> Hi Steve >>>>>> >>>>>> On 26/08/2023 01:14, Steve Clevenger wrote: >>>>>>> >>>>>>> Unfortunately, I tested with the original patch not [PATCH V2]. I've >>>>>>> remedied this. My results below: >>>>>>> >>>>>>> [root@sut01sys-b212 linux]# cat >>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_modes_available >>>>>>> auto flat catu >>>>>>> [root@sut01sys-b212 linux]# cat >>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred >>>>>>> auto >>>>>>> [root@sut01sys-b212 linux]# echo "catu" > >>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred >>>>>>> [root@sut01sys-b212 linux]# cat >>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred >>>>>>> catu >>>>>>> >>>>>>> As with the V1 patch, auto defaults to catu. >>>>>>> >>>>>>> I expected to see tmc-sg (former default) as an available mode, but do >>>>>>> not. As I recall, the buffer mode defaulted to ETR scatter-gather >>>>>>> prior >>>>>>> to this patch. Must this capability now be explicitly advertised? I've >>>>>>> seen this done as "arm,scatter-gather" in device trees, but not >>>>>>> used by >>>>>>> Ampere. Perhaps someone can enlighten me. >>>>>> >>>>>> Yes, you must add that property to the TMC-ETR node (for both DT and >>>>>> ACPI). In the past, almost all of the TMC-ETRs (except Juno board) >>>>>> locked up the system while using the SG mode (due to the interconnect >>>>>> issues, something to do with the transaction). Thus, we decided to >>>>>> add a property explicitly enabling this for a given platform. >>>>>> >>>>>> When you mentioned, it was using TMC-ETR SG mode, how did you verify >>>>>> this ? Please be aware that the table allocation code etc are shared >>>>>> by both TMC-SG and CATU. >>>>>> >>>>> >>>>> You might recall how this started. I had no way to test the CATU due to >>>>> the order the ETR modes defaulted (Flat, ETR-SG, CATU). For test >>>>> purposes, I programmatically swapped the ETR-SG/CATU order and could >>>>> then verify CATU operation by the driver calling into CATU code. This >>>> >>>> So, were you using the DT based boot for the above runs ? >>>> >>>>> suggests Flat mode was bypassed, and the driver defaulted to ETR-SG >>>>> prior to this hack. This didn't offer the user any control, hence my >>>>> feature request. Note that most of the early Ampere self-hosted trace >>>>> collection used ETR-SG. Now I can't select it. >>>> >>>> >>>>> >>>>> How is this property described in the ACPI? The "ACPI for CoreSight™ 1.1 >>>>> Platform Design Document" (DEN0067) doesn't describe this. >>>> >>>> This is not specified in the ACPI platform design document. I can get >>>> it fixed. Ideally we need a property describing that the scatter-gather >>>> mode is safe to use. >>> >>> Looks like this is not straight forward copying of DT property. We are >>> investigating this on our side and will get back to you. > > I noticed this work is queued for 6.7 (coresight-next-6.7). Do you have > an update to the ACPI platform design document Ampere can use to base an > update so the scatter-gather mode can be used? I have chased this with the specification team, and we should have something published soon. Apologies for the delay. Suzuki > > Thanks, > Steve > >>> >> >> The intent behind my request was to have a way to SysFS configure the >> (available) ETR mode. Unless there's a change to the ACPI, the CATU is >> the only SG option for Ampere in the near term. >> >> Thanks, >> Steve >> >> >>> Suzuki >>> >>> >>>> >>>> DT uses "arm,scatter-gather" property [0] and this is what we now expect >>>> in the ACPI based systems too. >>>> >>>> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bin… >>>> >>>> Does it sound fine ? >>>> >>>> Suzuki >>>> >>>>> >>>>> Thanks, >>>>> Steve >>>>> >>>>> >>>>>> Kind regards >>>>>> Suzuki >>>>>> >>>>>>> >>>>>>> Steve C. >>>>>>> >>>>>>> On 8/23/2023 4:10 PM, Steve Clevenger wrote: >>>>>>>> >>>>>>>> Here's some quick feedback. My system shows two modes available; auto >>>>>>>> catu >>>>>>>> >>>>>>>> etr_buf_mode_current is writable. I expected to see tmc-sg (former >>>>>>>> default) listed in etr_buf_modes_available but it doesn't show up. >>>>>>>> >>>>>>>> Note that both the auto and catu etr_buf_mode_current settings >>>>>>>> default >>>>>>>> to catu. My understanding is auto should revert to the default >>>>>>>> behavior. >>>>>>>> On my system the default was tmc-sg. >>>>>>>> >>>>>>>> More later. >>>>>>>> >>>>>>>> [root@sut01sys-b212 kernel]# cat >>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_modes_available >>>>>>>> >>>>>>>> auto catu >>>>>>>> [root@sut01sys-b212 kernel]# cat >>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current >>>>>>>> catu >>>>>>>> [root@sut01sys-b212 kernel]# echo "catu" > >>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current >>>>>>>> [root@sut01sys-b212 kernel]# cat >>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current >>>>>>>> catu >>>>>>>> >>>>>>>> Steve C. >>>>>>>> >>>>>>>> >>>>>>>> On 8/21/2023 12:40 PM, Steve Clevenger wrote: >>>>>>>>> >>>>>>>>> Hi Suzuki, >>>>>>>>> >>>>>>>>> I may be able to test it this week. You've already pointed me at the >>>>>>>>> patch thread(s). The main holdup is I need to merge the 6.6 pending >>>>>>>>> platform work in order to use the Ampere ACPI. I couldn't get these >>>>>>>>> patches to apply directly to 6.4 last I tried. >>>>>>>>> >>>>>>>>> Steve C. >>>>>>>>> >>>>>>>>> On 8/18/2023 2:39 AM, Suzuki K Poulose wrote: >>>>>>>>>> Cc: Steve >>>>>>>>>> >>>>>>>>>> Steve, >>>>>>>>>> >>>>>>>>>> Are you able to test this with CATU ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 18/08/2023 09:21, Anshuman Khandual wrote: >>>>>>>>>>> Currently TMC-ETR automatically selects the buffer mode from all >>>>>>>>>>> available >>>>>>>>>>> methods in the following sequentially fallback manner - also in >>>>>>>>>>> that >>>>>>>>>>> order. >>>>>>>>>>> >>>>>>>>>>> 1. FLAT mode with or without IOMMU >>>>>>>>>>> 2. TMC-ETR-SG (scatter gather) mode when available >>>>>>>>>>> 3. CATU mode when available >>>>>>>>>>> >>>>>>>>>>> But this order might not be ideal for all situations. For >>>>>>>>>>> example if >>>>>>>>>>> there >>>>>>>>>>> is a CATU connected to ETR, it may be better to use TMC-ETR >>>>>>>>>>> scatter >>>>>>>>>>> gather >>>>>>>>>>> method, rather than CATU. But hard coding such order changes will >>>>>>>>>>> prevent >>>>>>>>>>> us from testing or using a particular mode. This change provides >>>>>>>>>>> following >>>>>>>>>>> new sysfs tunables for the user to control TMC-ETR buffer mode >>>>>>>>>>> explicitly, >>>>>>>>>>> if required. This adds following new sysfs files for buffer mode >>>>>>>>>>> selection >>>>>>>>>>> purpose explicitly in the user space. >>>>>>>>>>> >>>>>>>>>>> /sys/bus/coresight/devices/tmc_etr<N>/buf_modes_available >>>>>>>>>>> /sys/bus/coresight/devices/tmc_etr<N>/buf_mode_preferred >>>>>>>>>>> >>>>>>>>>>> $ cat buf_modes_available >>>>>>>>>>> auto flat tmc-sg catu ------------------> Supported TMC-ETR >>>>>>>>>>> buffer >>>>>>>>>>> modes >>>>>>>>>>> >>>>>>>>>>> $ echo catu > buf_mode_preferred -------> Explicit buffer mode >>>>>>>>>>> request >>>>>>>>>>> >>>>>>>>>>> But explicit user request has to be within supported ETR buffer >>>>>>>>>>> modes >>>>>>>>>>> only. >>>>>>>>>>> These sysfs interface files are exclussive to ETR, and hence these >>>>>>>>>>> are >>>>>>>>>>> not >>>>>>>>>>> available for other TMC devices such as ETB or ETF etc. >>>>>>>>>>> >>>>>>>>>>> A new auto' mode (i.e ETR_MODE_AUTO) has been added to help >>>>>>>>>>> fallback >>>>>>>>>>> to the >>>>>>>>>>> existing default behaviour, when user provided preferred buffer >>>>>>>>>>> mode >>>>>>>>>>> fails. >>>>>>>>>>> ETR_MODE_FLAT and ETR_MODE_AUTO are always available as preferred >>>>>>>>>>> modes. >>>>>>>>>>> >>>>>>>>>>> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> >>>>>>>>>>> Cc: Mike Leach <mike.leach(a)linaro.org> >>>>>>>>>>> Cc: James Clark <james.clark(a)arm.com> >>>>>>>>>>> Cc: Leo Yan <leo.yan(a)linaro.org> >>>>>>>>>>> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> >>>>>>>>>>> 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> >>>>>>>>>>> --- >>>>>>>>>>> This applies on v6.5-rc6 >>>>>>>>>>> >>>>>>>>>>> Changes in V2: >>>>>>>>>>> >>>>>>>>>>> - Renamed sysfs file etr_buf_modes_available as >>>>>>>>>>> buf_modes_available >>>>>>>>>>> - Renamed sysfs file buf_mode_current as buf_mode_preferred >>>>>>>>>>> - Renamed etr_supports_flat_mode() as etr_can_use_flat_mode() >>>>>>>>>>> - Renamed coresight_tmc_groups[] as coresight_etf_groups[] >>>>>>>>>>> - Reused coresight_tmc_group[] for trigger_cntr and buffer_size >>>>>>>>>>> - Fallback trying ETR_MODE_AUTO when user preferred mode fails >>>>>>>>>>> - Moved ETR sysfs details into coresight-tmc-etr.c >>>>>>>>>>> - Dropped etr_can_use_flat_mode() check while offering >>>>>>>>>>> ETR_MODE_FLAT >>>>>>>>>>> in sysfs >>>>>>>>>>> - Moved struct etr_buf_hw inside coresight-tmc-etr.c >>>>>>>>>>> - Moved get_etr_buf_hw() and etr_can_use_flat_mode() inside >>>>>>>>>>> coresight-tmc-etr.c >>>>>>>>>>> - Updated month in >>>>>>>>>>> Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc >>>>>>>>>>> >>>>>>>>>>> Changes in V1: >>>>>>>>>>> >>>>>>>>>>> https://lore.kernel.org/all/20230728084837.276551-1-anshuman.khandual@arm.c… >>>>>>>>>>> >>>>>>>>>>> .../testing/sysfs-bus-coresight-devices-tmc | 16 +++ >>>>>>>>>>> .../hwtracing/coresight/coresight-tmc-core.c | 15 ++- >>>>>>>>>>> .../hwtracing/coresight/coresight-tmc-etr.c | 111 >>>>>>>>>>> ++++++++++++++++-- >>>>>>>>>>> drivers/hwtracing/coresight/coresight-tmc.h | 3 + >>>>>>>>>>> 4 files changed, 131 insertions(+), 14 deletions(-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Looks good to me. >>>>>>>>>> >>>>>>>>>> Suzuki >>>>>>>>>> >>>>>>>>>> >>>>>> >>>> >>>

1 year, 6 months

Re: [GIT PULL] coresight: Fixes for v6.7-rc1

by Suzuki K Poulose

On 06/12/2023 03:14, Greg KH wrote: > On Thu, Nov 16, 2023 at 05:01:19PM +0000, Suzuki K Poulose wrote: >> Hi Greg >> >> Please find fixes for hwtracing/coresight subsystem, targetting Linux v6.7. > > Sorry for the delay, now pulled and pushed out. Thank you, Greg! Suzuki

1 year, 6 months

[PATCH V2 0/7] coresight: Move remaining AMBA ACPI devices into platform driver

by Anshuman Khandual

This moves remaining AMBA ACPI devices into respective platform drivers for enabling ACPI based power management support. This series applies on latest coresight/next branch. This series has been built, and boot tested on a DT based coresight platform. Although this still requires some more testing on ACPI based coresight platforms. https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v2) Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: Sudeep Holla <sudeep.holla(a)arm.com> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com> Cc: linux-acpi(a)vger.kernel.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: coresight(a)lists.linaro.org Cc: linux-stm32(a)st-md-mailman.stormreply.com Changes in V2: - Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe() - Defined coresight_[init|remove]_driver() for both AMBA/platform drivers - Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new helpers avoiding build issues arising from module_amba_driver(), and module_platform_driver() being on the same file Changes in V1: https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual@arm.… - Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki Changes in RFC: https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual@arm.… Anshuman Khandual (7): coresight: replicator: Move ACPI support from AMBA driver to platform driver coresight: funnel: Move ACPI support from AMBA driver to platform driver coresight: catu: Move ACPI support from AMBA driver to platform driver coresight: tpiu: Move ACPI support from AMBA driver to platform driver coresight: tmc: Move ACPI support from AMBA driver to platform driver coresight: stm: Move ACPI support from AMBA driver to platform driver coresight: debug: Move ACPI support from AMBA driver to platform driver drivers/acpi/arm64/amba.c | 8 - drivers/hwtracing/coresight/coresight-catu.c | 130 +++++++++++++--- drivers/hwtracing/coresight/coresight-catu.h | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 ++++ .../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++++-- .../hwtracing/coresight/coresight-funnel.c | 49 +++--- .../coresight/coresight-replicator.c | 44 +++--- drivers/hwtracing/coresight/coresight-stm.c | 91 +++++++++-- .../hwtracing/coresight/coresight-tmc-core.c | 130 ++++++++++++++-- drivers/hwtracing/coresight/coresight-tmc.h | 1 + drivers/hwtracing/coresight/coresight-tpiu.c | 87 ++++++++++- include/linux/coresight.h | 7 + 12 files changed, 608 insertions(+), 110 deletions(-) -- 2.25.1

1 year, 6 months

Re: [PATCH v3 3/6] arm64: KVM: Add iflag for FEAT_TRF

by Suzuki K Poulose

On 04/12/2023 09:48, Marc Zyngier wrote: > On Thu, 19 Oct 2023 17:55:01 +0100, > James Clark <james.clark(a)arm.com> wrote: >> >> Add an extra iflag to signify if the TRFCR register is accessible. >> Because TRBE requires FEAT_TRF, DEBUG_STATE_SAVE_TRBE still has the same >> behavior even though it's only set when FEAT_TRF is present. >> >> The following holes are left in struct kvm_vcpu_arch, but there aren't >> enough other 8 bit fields to rearrange it to leave any hole smaller than >> 7 bytes: >> >> u8 cflags; /* 2292 1 */ >> /* XXX 1 byte hole, try to pack */ >> u16 iflags; /* 2294 2 */ >> u8 sflags; /* 2296 1 */ >> bool pause; /* 2297 1 */ >> /* XXX 6 bytes hole, try to pack */ >> >> Signed-off-by: James Clark <james.clark(a)arm.com> >> --- >> arch/arm64/include/asm/kvm_host.h | 4 +++- >> arch/arm64/kvm/debug.c | 22 ++++++++++++++++++---- >> 2 files changed, 21 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >> index 7c82927ddaf2..0f0bf8e641bd 100644 >> --- a/arch/arm64/include/asm/kvm_host.h >> +++ b/arch/arm64/include/asm/kvm_host.h >> @@ -535,7 +535,7 @@ struct kvm_vcpu_arch { >> u8 cflags; >> >> /* Input flags to the hypervisor code, potentially cleared after use */ >> - u8 iflags; >> + u16 iflags; >> >> /* State flags for kernel bookkeeping, unused by the hypervisor code */ >> u8 sflags; >> @@ -741,6 +741,8 @@ struct kvm_vcpu_arch { >> #define DEBUG_STATE_SAVE_TRBE __vcpu_single_flag(iflags, BIT(6)) >> /* vcpu running in HYP context */ >> #define VCPU_HYP_CONTEXT __vcpu_single_flag(iflags, BIT(7)) >> +/* Save trace filter controls */ >> +#define DEBUG_STATE_SAVE_TRFCR __vcpu_single_flag(iflags, BIT(8)) >> >> /* SVE enabled for host EL0 */ >> #define HOST_SVE_ENABLED __vcpu_single_flag(sflags, BIT(0)) >> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c >> index 8725291cb00a..20cdd40b3c42 100644 >> --- a/arch/arm64/kvm/debug.c >> +++ b/arch/arm64/kvm/debug.c >> @@ -331,14 +331,28 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu) >> !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(PMBIDR_EL1_P_SHIFT))) >> vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_SPE); >> >> - /* Check if we have TRBE implemented and available at the host */ >> - if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) && >> - !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P)) >> - vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE); >> + /* >> + * Save TRFCR on nVHE if FEAT_TRF (TraceFilt) exists. This will be >> + * done in cases where use of TRBE doesn't completely disable trace and >> + * handles the exclude_host/exclude_guest rules of the trace session. > > This comment provides zero information. What will be done? Under which > conditions? What are the rules? > >> + */ >> + if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceFilt_SHIFT)) { >> + vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRFCR); >> + /* >> + * Check if we have TRBE implemented and available at the host. If it's >> + * in use at the time of guest switch it will need to be disabled and >> + * then restored. The architecture mandates FEAT_TRF with TRBE, so we >> + * only need to check for TRBE after TRF. >> + */ >> + if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) && >> + !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P)) >> + vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE); >> + } > > Multiple questions: > > - Why is it safe to trust the local CPU's capability rather than the > consolidated view from the cpufeature infrastructure? The coresight driver is capable of handling heterogeneous systems. i.e., some CPUs may not have FEAT_TRF or FEAT_TRBE. This could be for various reasons (e.g., CPU Erratum disabling TRBE, though not used now). It already needs to treat each CPU differently (due to the capabilities of the ETM). That said, we could reject events with exclude_guest/exclude_host flags on CPUs that do not support FEAT_TRF. But that doesn't solve checking the local capability. Suzuki > > - Why defer the saving of the registers if there are no changes made > to them in the interval? > > Thanks, > > M. >

1 year, 6 months

Re: [PATCH v3 4/6] arm64: KVM: Add interface to set guest value for TRFCR register

by James Clark

On 04/12/2023 09:59, Marc Zyngier wrote: > On Thu, 19 Oct 2023 17:55:02 +0100, > James Clark <james.clark(a)arm.com> wrote: >> >> Add an interface for the Coresight driver to use to set the value of the >> TRFCR register for the guest. This register controls the exclude >> settings for trace at different exception levels, and is used to honor >> the exclude_host and exclude_guest parameters from the Perf session. >> This will be used to later write TRFCR_EL1 on nVHE at guest switch. For >> VHE, the host trace is controlled by TRFCR_EL2 and thus we can write to >> the TRFCR_EL1 immediately. Because guest writes to the register are >> trapped, the value will persist and can't be modified. >> >> The settings must be copied to the vCPU before each run in the same >> way that PMU events are, because the per-cpu struct isn't accessible in >> protected mode. > > Then maybe we should look at a better way of sharing global data > between EL1 and EL2 instead of copying stuff ad-nauseam? > That probably makes sense, I can have a look into that. >> >> Signed-off-by: James Clark <james.clark(a)arm.com> >> --- >> arch/arm64/include/asm/kvm_host.h | 3 +++ >> arch/arm64/kvm/arm.c | 1 + >> arch/arm64/kvm/debug.c | 26 ++++++++++++++++++++++++++ >> 3 files changed, 30 insertions(+) >> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >> index 0f0bf8e641bd..e1852102550d 100644 >> --- a/arch/arm64/include/asm/kvm_host.h >> +++ b/arch/arm64/include/asm/kvm_host.h >> @@ -1125,6 +1125,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu); >> void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr); >> void kvm_clr_pmu_events(u32 clr); >> bool kvm_set_pmuserenr(u64 val); >> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest); >> +void kvm_etm_update_vcpu_events(struct kvm_vcpu *vcpu); >> #else >> static inline void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) {} >> static inline void kvm_clr_pmu_events(u32 clr) {} >> @@ -1132,6 +1134,7 @@ static inline bool kvm_set_pmuserenr(u64 val) >> { >> return false; >> } >> +static inline void kvm_etm_set_guest_trfcr(u64 trfcr_guest) {} >> #endif >> >> void kvm_vcpu_load_sysregs_vhe(struct kvm_vcpu *vcpu); >> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c >> index 0f717b6a9151..e4d846f2f665 100644 >> --- a/arch/arm64/kvm/arm.c >> +++ b/arch/arm64/kvm/arm.c >> @@ -1015,6 +1015,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) >> kvm_vgic_flush_hwstate(vcpu); >> >> kvm_pmu_update_vcpu_events(vcpu); >> + kvm_etm_update_vcpu_events(vcpu); >> >> /* >> * Ensure we set mode to IN_GUEST_MODE after we disable >> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c >> index 20cdd40b3c42..2ab41b954512 100644 >> --- a/arch/arm64/kvm/debug.c >> +++ b/arch/arm64/kvm/debug.c >> @@ -23,6 +23,12 @@ >> >> static DEFINE_PER_CPU(u64, mdcr_el2); >> >> +/* >> + * Per CPU value for TRFCR that should be applied to any guest vcpu that may >> + * run on that core in the future. >> + */ >> +static DEFINE_PER_CPU(u64, guest_trfcr); >> + >> /** >> * save/restore_guest_debug_regs >> * >> @@ -356,3 +362,23 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu) >> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE); >> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR); >> } >> + >> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest) >> +{ >> + if (has_vhe()) >> + write_sysreg_s(trfcr_guest, SYS_TRFCR_EL12); >> + else >> + *this_cpu_ptr(&guest_trfcr) = trfcr_guest; >> +} >> +EXPORT_SYMBOL_GPL(kvm_etm_set_guest_trfcr); > > How does the ETM code know what guests it impacts? Don't you have some > per-process context already? > It doesn't know what guests it impacts, it just does it blindly based on host CPU and whatever guest might run on the CPU in the future. PMU events are the same. We do have per-process context for per-process sessions, so if that was the VM process we might have been able to do something with that info. But we also have per-cpu sessions that would trace anything that runs on that CPU, so to be able to support that mode I think it has to be done without knowing about any guest. >> + >> +/* >> + * Updates the vcpu's view of the etm events for this cpu. Must be >> + * called before every vcpu run after disabling interrupts, to ensure >> + * that an interrupt cannot fire and update the structure. >> + */ >> +void kvm_etm_update_vcpu_events(struct kvm_vcpu *vcpu) >> +{ >> + if (!has_vhe() && vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRFCR)) >> + ctxt_sys_reg(&vcpu->arch.ctxt, TRFCR_EL1) = *this_cpu_ptr(&guest_trfcr); >> +} > > Why this requirement of updating it at all times? Why can't this be > done in a more lazy way, using the flags to instruct the hypervisor > what and when to load it? > > M. > I could probably add a flag that gets set if the guest value should be different to the host value. I was just trying to keep it simple and in terms of just what the registers should be. The PMU one has something similar where it doesn't write anything if kvm_pmu_switch_needed() is false, but that's only on the path where the host sets the events, it still always does the copy in kvm_pmu_update_vcpu_events() before the guest switch. I suppose if I make the change to have the shared global data then the copy isn't needed and this function and kvm_pmu_update_vcpu_events() will just get deleted. Thanks James

1 year, 6 months

Re: [PATCH v2] coresight: Make current W=1 warnings default

by James Clark

On 04/12/2023 18:37, kernel test robot wrote: > Hi James, > > kernel test robot noticed the following build warnings: > > [auto build test WARNING on atorgue-stm32/stm32-next] > [also build test WARNING on linus/master v6.7-rc4 next-20231204] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/James-Clark/coresight-Make-c… > base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next > patch link: https://lore.kernel.org/r/20231115162834.355598-1-james.clark%40arm.com > patch subject: [PATCH v2] coresight: Make current W=1 warnings default > config: arm-randconfig-r131-20231117 (https://download.01.org/0day-ci/archive/20231205/202312050158.FKpxuafP-lkp@…) > compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0 > reproduce: (https://download.01.org/0day-ci/archive/20231205/202312050158.FKpxuafP-lkp@…) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp(a)intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202312050158.FKpxuafP-lkp@intel.com/ > > sparse warnings: (new ones prefixed by >>) >>> drivers/hwtracing/coresight/coresight-etb10.c:840:17: sparse: sparse: Using plain integer as NULL pointer > drivers/hwtracing/coresight/coresight-etb10.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...): > include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false > -- >>> drivers/hwtracing/coresight/coresight-funnel.c:395:17: sparse: sparse: Using plain integer as NULL pointer > drivers/hwtracing/coresight/coresight-funnel.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h, ...): > include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false > -- >>> drivers/hwtracing/coresight/coresight-tpdm.c:242:17: sparse: sparse: Using plain integer as NULL pointer > drivers/hwtracing/coresight/coresight-tpdm.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...): > include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false > > vim +840 drivers/hwtracing/coresight/coresight-etb10.c > > 834 > 835 static const struct amba_id etb_ids[] = { > 836 { > 837 .id = 0x000bb907, > 838 .mask = 0x000fffff, > 839 }, > > 840 { 0, 0, 0 }, > 841 }; > 842 > This should already be fixed in V3 here: https://lore.kernel.org/linux-arm-kernel/20231123120459.287578-1-james.clar…

1 year, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight