CoreSight

coresight@lists.linaro.org

7 participants
2442 discussions

Re: [PATCH v2 2/2] arm64: dts: qcom: sm8250: Add Coresight support

by Anshuman Khandual

On 9/24/21 15:36, Tao Zhang wrote: > Add the basic coresight components found on Qualcomm SM8250 Soc. The > basic coresight components include ETF, ETMs,STM and the related > funnels. Hello, Seems like this patch never merged mainline, what happened ? This change is required to enable coresight devices on RB5 platform. - Anshuman > > Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> > --- > arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 439 +++++++++++++++++++++++++++++++ > 1 file changed, 439 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts > index 5f41de2..1e1579a 100644 > --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts > +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts > @@ -223,6 +223,445 @@ > regulator-max-microvolt = <1800000>; > regulator-always-on; > }; > + > + stm@6002000 { > + compatible = "arm,coresight-stm", "arm,primecell"; > + reg = <0 0x06002000 0 0x1000>, > + <0 0x16280000 0 0x180000>; > + reg-names = "stm-base", "stm-stimulus-base"; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + stm_out: endpoint { > + remote-endpoint = > + <&funnel0_in7>; > + }; > + }; > + }; > + }; > + > + funnel@6041000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0 0x06041000 0 0x1000>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + funnel0_out: endpoint { > + remote-endpoint = > + <&merge_funnel_in0>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@7 { > + reg = <7>; > + funnel0_in7: endpoint { > + remote-endpoint = <&stm_out>; > + }; > + }; > + }; > + }; > + > + funnel@6042000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0 0x06042000 0 0x1000>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + funnel2_out: endpoint { > + remote-endpoint = > + <&merge_funnel_in2>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@4 { > + reg = <4>; > + funnel2_in5: endpoint { > + remote-endpoint = > + <&apss_merge_funnel_out>; > + }; > + }; > + }; > + }; > + > + funnel@6b04000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + arm,primecell-periphid = <0x000bb908>; > + > + reg = <0 0x6b04000 0 0x1000>; > + reg-names = "funnel-base"; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + merge_funnel_out: endpoint { > + remote-endpoint = > + <&etf_in>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@7 { > + reg = <7>; > + swao_funnel_in7: endpoint { > + slave-mode; > + remote-endpoint= > + <&merg_funnel_out>; > + }; > + }; > + }; > + > + }; > + > + funnel@6045000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0 0x06045000 0 0x1000>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + merg_funnel_out: endpoint { > + remote-endpoint = <&swao_funnel_in7>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + merge_funnel_in0: endpoint { > + remote-endpoint = > + <&funnel0_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + merge_funnel_in2: endpoint { > + remote-endpoint = > + <&funnel2_out>; > + }; > + }; > + }; > + }; > + > + etf@6b05000 { > + compatible = "arm,coresight-tmc", "arm,primecell"; > + reg = <0 0x06b05000 0 0x1000>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + in-ports { > + port { > + etf_in: endpoint { > + remote-endpoint = > + <&merge_funnel_out>; > + }; > + }; > + }; > + }; > + > + etm@7040000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07040000 0 0x1000>; > + > + cpu = <&CPU0>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm0_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in0>; > + }; > + }; > + }; > + }; > + > + etm@7140000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07140000 0 0x1000>; > + > + cpu = <&CPU1>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm1_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in1>; > + }; > + }; > + }; > + }; > + > + etm@7240000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07240000 0 0x1000>; > + > + cpu = <&CPU2>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm2_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in2>; > + }; > + }; > + }; > + }; > + > + etm@7340000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07340000 0 0x1000>; > + > + cpu = <&CPU3>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm3_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in3>; > + }; > + }; > + }; > + }; > + > + etm@7440000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07440000 0 0x1000>; > + > + cpu = <&CPU4>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm4_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in4>; > + }; > + }; > + }; > + }; > + > + etm@7540000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07540000 0 0x1000>; > + > + cpu = <&CPU5>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm5_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in5>; > + }; > + }; > + }; > + }; > + > + etm@7640000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07640000 0 0x1000>; > + > + cpu = <&CPU6>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm6_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in6>; > + }; > + }; > + }; > + }; > + > + etm@7740000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0 0x07740000 0 0x1000>; > + > + cpu = <&CPU7>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + arm,coresight-loses-context-with-cpu; > + > + out-ports { > + port { > + etm7_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in7>; > + }; > + }; > + }; > + }; > + > + funnel@7800000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0 0x07800000 0 0x1000>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + apss_funnel_out: endpoint { > + remote-endpoint = > + <&apss_merge_funnel_in>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + apss_funnel_in0: endpoint { > + remote-endpoint = > + <&etm0_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + apss_funnel_in1: endpoint { > + remote-endpoint = > + <&etm1_out>; > + }; > + }; > + > + port@2 { > + reg = <2>; > + apss_funnel_in2: endpoint { > + remote-endpoint = > + <&etm2_out>; > + }; > + }; > + > + port@3 { > + reg = <3>; > + apss_funnel_in3: endpoint { > + remote-endpoint = > + <&etm3_out>; > + }; > + }; > + > + port@4 { > + reg = <4>; > + apss_funnel_in4: endpoint { > + remote-endpoint = > + <&etm4_out>; > + }; > + }; > + > + port@5 { > + reg = <5>; > + apss_funnel_in5: endpoint { > + remote-endpoint = > + <&etm5_out>; > + }; > + }; > + > + port@6 { > + reg = <6>; > + apss_funnel_in6: endpoint { > + remote-endpoint = > + <&etm6_out>; > + }; > + }; > + > + port@7 { > + reg = <7>; > + apss_funnel_in7: endpoint { > + remote-endpoint = > + <&etm7_out>; > + }; > + }; > + }; > + }; > + > + funnel@7810000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0 0x07810000 0 0x1000>; > + > + clocks = <&aoss_qmp>; > + clock-names = "apb_pclk"; > + > + out-ports { > + port { > + apss_merge_funnel_out: endpoint { > + remote-endpoint = > + <&funnel2_in5>; > + }; > + }; > + }; > + > + in-ports { > + port { > + apss_merge_funnel_in: endpoint { > + remote-endpoint = > + <&apss_funnel_out>; > + }; > + }; > + }; > + }; > }; > > &adsp {

3 years

Re: [PATCH v4 7/7] configfs: Fix LOCKDEP nesting issues with fragment semaphores

by Mike Leach

Hi Christoph. [adding in Suzuki and Mathieu who maintain the coresight subsystem & lists] You are correct - in this patchset we are adding the use of a binary attribute to load and unload Coresight configurations and features - which action has a side effect of adding and removing entries in particular sub-directories in our configfs sub-system. Our use case for configfs is somewhat more complex than the other existing usages - such as ACPI, where the format of the directory structure and attributes is static, and known ahead of time. The CoreSight configurations have variable numbers of attributes appearing in the configfs directories - so the attribute arrays are built dynamically at load time. The load process and also result in elements appearing in both the cs-syscfg/configurations and the cs-syscfg/features sub directories. This dynamic nature and split elements means that the traditional mkdir/rmdir configfs paradigm cannot be made to work. We currently have two methods upstreamed for loading configurations, 1 is a configuration directly built into the coresight core code, and the other is to allow configurations to be loaded as kernel loadable modules. However these 2 are dependent on compile time operations, and have kernel dependencies. Hence we have introduced the direct load via configfs binary attribute - which is more portable, flexible and convenient for the end user. I appreciate that this may not be a usage you anticipated for configfs, but it does serve our purposes very well, and as far a I can tell from examination of configfs code and considerable testing, works fine and does not have any operational issues, other than the lockdep warnings on unload, which are caused be the fragment locks (lockdep being confused by holding the fragment for the initial cs-syscfg root system, and the one for the sub-directory we want to unload). I am open to suggestions for a different way of doing this within the established directory structure we need to maintain. Thanks and Regards Mike On Fri, 29 Jul 2022 at 14:24, Christoph Hellwig <hch(a)lst.de> wrote: > > On Fri, Jul 29, 2022 at 07:41:00AM +0100, Mike Leach wrote: > > Sure - see below > > > > Happens during the unload process of the coresight configuration. > > Hmm. It seems like youre bin_attr ->write handler (which gets called > from configfs_release_bin_file) tries to unregister a group. That's > not really how the configfs API is supposed to be used. -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

3 years

Longer traces with limited buffer

by finn.burmester＠student.uni-luebeck.de

Hi all, I have a system that only has an ETF as a trace sink, so I only have 8 kB of memory available for my trace, which limits me to quite small programs. What would be the go-to solution for longer trace-runs, when I want to do on-device-trace-capturing? Is it possible at all with my setup? It is important that I don't loose any trace, I need a trace of the whole execution. For tracing I use CSAL. Best regards, Finn

3 years

Re: [PATCH] coresight: etm4x: Fix crash observed on Qcom ETM parts with 'Low power override'

by Suzuki K Poulose

Hi Bhupesh, On 03/08/2022 20:12, Bhupesh Sharma wrote: > Some Qualcomm ETM implementations require skipping powering up > the trace unit, as the ETMs are in the same power domain as > their CPU cores. > > Via commit 5214b563588e ("coresight: etm4x: Add support for > sysreg only devices"), the setting of 'skip_power_up' flag was > moved after the 'etm4_init_arch_data' function is called, whereas > the flag value is itself used inside the function. This causes > a crash when ETM mode 'Low-power state behavior override' is set > on some Qualcomm parts. > > Fix the same. > Thanks for the patch. The patch is correct. But please see my comment below. > Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices") > Cc: Mike Leach <mike.leach(a)linaro.org> > Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma(a)linaro.org> > --- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index d39660a3e50c..cf6254b87fd5 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -1943,6 +1943,16 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > init_arg.csa = &desc.access; > init_arg.pid = etm_pid; > > + /* > + * Some Qualcomm implementations require skipping powering up the trace unit, > + * as the ETMs are in the same power domain as their CPU cores. > + * > + * Since the 'skip_power_up' flag is used inside 'etm4_init_arch_data' function, > + * initialize it before the function is called. > + */ > + if (fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) > + drvdata->skip_power_up = true; > + > if (smp_call_function_single(drvdata->cpu, > etm4_init_arch_data, &init_arg, 1)) > dev_err(dev, "ETM arch init failed\n"); > @@ -1951,8 +1961,7 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > return -EINVAL; > > /* TRCPDCR is not accessible with system instructions. */ > - if (!desc.access.io_mem || > - fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) > + if (!desc.access.io_mem) > drvdata->skip_power_up = true; > Please could you move this setting into "etm4_init_sysreg_access()" ? It looks a bit odd to split the check in the same function. Moving this to the sysreg_access() makes it explicit. Suzuki > major = ETM_ARCH_MAJOR_VERSION(drvdata->arch);

3 years

A patch series improving data quality of perf test for CoreSight

by carsten.haitzler＠foss.arm.com

This is a prelude to adding more tests to shell tests and in order to support putting those tests into subdirectories, I need to change the test code that scans/finds and runs them. To support subdirs I have to recurse so it's time to refactor the code to allow this and centralize the shell script finding into one location and only one single scan that builds a list of all the found tests in memory instead of it being duplicated in 3 places. This code also optimizes things like knowing the max width of desciption strings (as we can do that while we scan instead of a whole new pass of opening files). It also more cleanly filters scripts to see only *.sh files thus skipping random other files in directories like *~ backup files, other random junk/data files that may appear and the scripts must be executable to make the cut (this ensures the script lib dir is not seen as scripts to run). This avoids perf test running previous older versions of test scripts that are editor backup files as well as skipping perf.data files that may appear and so on. Signed-off-by: Carsten Haitzler <carsten.haitzler(a)arm.com>

3 years

Re: [PATCH] coresight: docs: Fix a broken reference

by James Clark

On 31/07/2022 08:06, Christophe JAILLET wrote: > Since the commit in Fixes: tag, "coresight-cpu-debug.txt" has been turned > into "arm,coresight-cpu-debug.yaml". > > Update the doc accordingly to avoid a 'make htmldocs' warning > > Fixes: 66d052047ca8 ("dt-bindings: arm: Convert CoreSight CPU debug to DT schema") > Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> > --- > Documentation/trace/coresight/coresight-cpu-debug.rst | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/trace/coresight/coresight-cpu-debug.rst b/Documentation/trace/coresight/coresight-cpu-debug.rst > index 993dd294b81b..836b35532667 100644 > --- a/Documentation/trace/coresight/coresight-cpu-debug.rst > +++ b/Documentation/trace/coresight/coresight-cpu-debug.rst > @@ -117,7 +117,8 @@ divide into below cases: > Device Tree Bindings > -------------------- > > -See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details. > +See Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml for > +details. LGTM, thanks Reviewed-by: James Clark <james.clark(a)arm.com> > > > How to use the module

3 years

Re: [PATCH v12 0/9] Coresight: Add support for TPDM and TPDA

by Suzuki K Poulose

On 02/08/2022 19:09, Trilok Soni wrote: > Hi Suzuki, > > On 8/2/2022 10:43 AM, Suzuki K Poulose wrote: >> Hi Trilok, >> >> On 02/08/2022 18:33, Trilok Soni wrote: >>> >>> >>> On 8/2/2022 7:43 AM, Jinlong Mao wrote: >>>> Hi Reviewers, >>>> >>>> Please help to review V12 series of TPDM/TPDA patches. >>>> >>>> Thanks >>>> >>> >>> Suzuki and Mathieu, we are almost there it seems in getting the >>> acceptance of these patches, so I hope you find the time to review >>> these patches. I guess it is almost a year now for these patches and >>> had a good amount of reviews and revisions :) >> >> This series has been reviewed for the previous versions (which is why >> we have it in v12) and this one depends on a series worked on by Mike >> Leach. We cannot push this without the dynamic Trace ID allocation >> scheme, which is clearly mentioned in the cover letter for this >> series. >> >> As such this series is in a good shape, assuming all the comments >> in the previous version has been addressed. So, we would rather >> get Mike's work priority and pull that in, so that we can eventually >> get this upstream. >> >> > > I believe we have addressed all the comments in v12. Are you ok, if we > post additional features series (around ~2k to ~3k SLOC)? I just want to > make sure we are not creating flood of patches w/ features. You are free to post the patches, as long as you clearly mention the dependencies in the cover letter. Please be mindful about the merge window. Suzuki

3 years

Re: [PATCH v12 0/9] Coresight: Add support for TPDM and TPDA

by Suzuki K Poulose

Hi Trilok, On 02/08/2022 18:33, Trilok Soni wrote: > > > On 8/2/2022 7:43 AM, Jinlong Mao wrote: >> Hi Reviewers, >> >> Please help to review V12 series of TPDM/TPDA patches. >> >> Thanks >> > > Suzuki and Mathieu, we are almost there it seems in getting the > acceptance of these patches, so I hope you find the time to review these > patches. I guess it is almost a year now for these patches and had a > good amount of reviews and revisions :) This series has been reviewed for the previous versions (which is why we have it in v12) and this one depends on a series worked on by Mike Leach. We cannot push this without the dynamic Trace ID allocation scheme, which is clearly mentioned in the cover letter for this series. As such this series is in a good shape, assuming all the comments in the previous version has been addressed. So, we would rather get Mike's work priority and pull that in, so that we can eventually get this upstream. Kind regards Suzuki > > ---Trilok Soni

3 years

[PATCH v12 0/9] Coresight: Add support for TPDM and TPDA

by Mao Jinlong

This series adds support for the trace performance monitoring and diagnostics hardware (TPDM and TPDA). It is composed of two major elements. a) Changes for original coresight framework to support for TPDM and TPDA. b) Add driver code for TPDM and TPDA. Introduction of changes for original coresight framework Support TPDM as new coresight source. Since only STM and ETM are supported as coresight source originally. TPDM is a newly added coresight source. We need to change the original way of saving coresight path to support more types source for coresight driver. The following patch is to add support more coresight sources. coresight: core: Use IDR for non-cpu bound sources' paths. Introduction of TPDM and TPDA TPDM - The trace performance monitoring and diagnostics monitor or TPDM in short serves as data collection component for various dataset types specified in the QPMDA(Qualcomm performance monitoring and diagnostics architecture) spec. The primary use case of the TPDM is to collect data from different data sources and send it to a TPDA for packetization, timestamping and funneling. Coresight: Add coresight TPDM source driver dt-bindings: arm: Adds CoreSight TPDM hardware definitions coresight-tpdm: Add DSB dataset support coresight-tpdm: Add integration test support docs: sysfs: coresight: Add sysfs ABI documentation for TPDM TPDA - The trace performance monitoring and diagnostics aggregator or TPDA in short serves as an arbitration and packetization engine for the performance monitoring and diagnostics network as specified in the QPMDA (Qualcomm performance monitoring and diagnostics architecture) specification. The primary use case of the TPDA is to provide packetization, funneling and timestamping of Monitor data as specified in the QPMDA specification. The following patch is to add driver for TPDA. Coresight: Add TPDA link driver dt-bindings: arm: Adds CoreSight TPDA hardware definitions The last patch of this series is a device tree modification, which add the TPDM and TPDA configuration to device tree for validating. ARM: dts: msm: Add coresight components for SM8250 ARM: dts: msm: Add tpdm mm/prng for sm8250 Once this series patches are applied properly, the tpdm and tpda nodes should be observed at the coresight path /sys/bus/coresight/devices e.g. /sys/bus/coresight/devices # ls -l | grep tpd tpda0 -> ../../../devices/platform/soc(a)0/6004000.tpda/tpda0 tpdm0 -> ../../../devices/platform/soc(a)0/6c08000.mm.tpdm/tpdm0 We can use the commands are similar to the below to validate TPDMs. Enable coresight sink first. echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test The test data will be collected in the coresight sink which is enabled. If rwp register of the sink is keeping updating when do integration_test (by cat tmc_etf0/mgmt/rwp), it means there is data generated from TPDM to sink. There must be a tpda between tpdm and the sink. When there are some other trace event hw components in the same HW block with tpdm, tpdm and these hw components will connect to the coresight funnel. When there is only tpdm trace hw in the HW block, tpdm will connect to tpda directly. +---------------+ +-------------+ | tpdm@6c08000 | |tpdm@684C000 | +-------|-------+ +------|------+ | | +-------|-------+ | | funnel@6c0b000| | +-------|-------+ | | | +-------|-------+ | |funnel@6c2d000 | | +-------|-------+ | | | | +---------------+ | +----- tpda@6004000 -----------+ +-------|-------+ | +-------|-------+ |funnel@6005000 | +---------------+ This patch series depends on patch series: "[v2,00/13] coresight: Add new API to allocate trace source ID values" https://patchwork.kernel.org/project/linux-arm-kernel/cover/20220704081149.… Changes from V11: 1. Clear bits for atid before setting them and relese atid when tpda remove. -- Suzuki K Poulose <suzuki.poulose(a)arm.com> Mao Jinlong (9): coresight: core: Use IDR for non-cpu bound sources' paths. Coresight: Add coresight TPDM source driver dt-bindings: arm: Adds CoreSight TPDM hardware definitions coresight-tpdm: Add DSB dataset support coresight-tpdm: Add integration test support Coresight: Add TPDA link driver dt-bindings: arm: Adds CoreSight TPDA hardware definitions arm64: dts: qcom: sm8250: Add coresight components arm64: dts: qcom: sm8250: Add tpdm mm/prng .../testing/sysfs-bus-coresight-devices-tpdm | 13 + .../bindings/arm/qcom,coresight-tpda.yaml | 111 +++ .../bindings/arm/qcom,coresight-tpdm.yaml | 93 +++ MAINTAINERS | 2 + arch/arm64/boot/dts/qcom/sm8250.dtsi | 671 ++++++++++++++++++ drivers/hwtracing/coresight/Kconfig | 23 + drivers/hwtracing/coresight/Makefile | 2 + drivers/hwtracing/coresight/coresight-core.c | 42 +- drivers/hwtracing/coresight/coresight-tpda.c | 208 ++++++ drivers/hwtracing/coresight/coresight-tpda.h | 35 + drivers/hwtracing/coresight/coresight-tpdm.c | 259 +++++++ drivers/hwtracing/coresight/coresight-tpdm.h | 62 ++ include/linux/coresight.h | 1 + 13 files changed, 1510 insertions(+), 12 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml create mode 100644 drivers/hwtracing/coresight/coresight-tpda.c create mode 100644 drivers/hwtracing/coresight/coresight-tpda.h create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.c create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.h -- 2.17.1

3 years

Re: [-next] Lockdep warnings

by Leo Yan

On Tue, Jul 26, 2022 at 01:50:06PM +0100, Mark Rutland wrote: > On Tue, Jul 26, 2022 at 01:40:40PM +0100, Mark Rutland wrote: > > [Adding Peter; I suspect this is due to the cpuidle rework] > > Looking again I see the cpuidle rework isn't in next, so evidently not... > > Sorry for the noise! I'd like to loop in Mike.L and CoreSight ML for CTI PM callbacks. Please see below a comment for CTI spinlock usage. > > I'll go give next a spin in a VM, but I suspect I might need real HW to see > > this due to the way PSCI idle states work. > > > > Mark. > > > > On Tue, Jul 26, 2022 at 11:41:34AM +0100, Sudeep Holla wrote: > > > I was seeing the below lockdep warnings on my arm64 Juno development > > > platform almost 2 weeks back with -next. I wanted to check for similar > > > reports before post and forgot. > > > > > > --->8 > > > > > > DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled()) > > > hardirqs last enabled at (46157): cpuidle_enter_state+0x174/0x2b4 > > > WARNING: CPU: 5 PID: 0 at kernel/locking/lockdep.c:5506 check_flags+0x90/0x1e8 > > > hardirqs last disabled at (46158): el1_interrupt+0x2c/0xc8 > > > Modules linked in: > > > softirqs last enabled at (46154): __do_softirq+0x2c0/0x388 > > > softirqs last disabled at (46139): __irq_exit_rcu+0x118/0x18c > > > CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.19.0-rc6-next-20220714 #9 > > > pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > pc : check_flags+0x90/0x1e8 > > > lr : check_flags+0x90/0x1e8 > > > Call trace: > > > check_flags+0x90/0x1e8 > > > lock_is_held_type+0x80/0x164 > > > rcu_read_lock_sched_held+0x40/0x7c > > > trace_rcu_dyntick+0x5c/0x140 > > > ct_kernel_enter+0x78/0xd4 > > > ct_idle_exit+0x1c/0x44 > > > cpu_idle_poll+0x74/0xb8 > > > do_idle+0x90/0x2c4 > > > cpu_startup_entry+0x30/0x34 > > > secondary_start_kernel+0x130/0x144 > > > __secondary_switched+0xb0/0xb4 > > > irq event stamp: 64229 > > > hardirqs last enabled at (64229): cpu_idle_poll+0x40/0xb8 > > > hardirqs last disabled at (64228): do_idle+0xbc/0x2c4 > > > softirqs last enabled at (64190): __do_softirq+0x2c0/0x388 > > > softirqs last disabled at (64185): __irq_exit_rcu+0x118/0x18c > > > ---[ end trace 0000000000000000 ]--- > > > possible reason: unannotated irqs-off. > > > irq event stamp: 64229 > > > hardirqs last enabled at (64229): cpu_idle_poll+0x40/0xb8 > > > hardirqs last disabled at (64228): do_idle+0xbc/0x2c4 > > > softirqs last enabled at (64190): __do_softirq+0x2c0/0x388 > > > softirqs last disabled at (64185): __irq_exit_rcu+0x118/0x18c > > > > > > ---- > > > > > > However I don't see the above warning with the latest -next. When I tried > > > yesterday's -next now, I see a different warning. Not sure if they are > > > related. I haven't tried to bisect. > > > > > > --->8 > > > ============================= > > > [ BUG: Invalid wait context ] > > > 5.19.0-rc8-next-20220725 #38 Not tainted > > > ----------------------------- > > > swapper/0/0 is trying to lock: > > > (&drvdata->spinlock){....}-{3:3}, at: cti_cpu_pm_notify+0x54/0x114 > > > other info that might help us debug this: > > > context-{5:5} > > > 1 lock held by swapper/0/0: > > > #0: (cpu_pm_notifier.lock){....}-{2:2}, at: cpu_pm_enter+0x2c/0x80 > > > stack backtrace: > > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc8-next-20220725-00004-g599e6691ed8c #38 > > > Call trace: > > > dump_backtrace+0xe8/0x108 > > > show_stack+0x18/0x4c > > > dump_stack_lvl+0x90/0xc8 > > > dump_stack+0x18/0x54 > > > __lock_acquire+0xa70/0x32d0 > > > lock_acquire+0x160/0x308 > > > _raw_spin_lock+0x60/0xa0 > > > cti_cpu_pm_notify+0x54/0x114 > > > raw_notifier_call_chain_robust+0x50/0xd4 > > > cpu_pm_enter+0x48/0x80 > > > psci_enter_idle_state+0x34/0x74 > > > cpuidle_enter_state+0x120/0x2a8 > > > cpuidle_enter+0x38/0x50 > > > do_idle+0x1e8/0x2b8 > > > cpu_startup_entry+0x24/0x28 > > > kernel_init+0x0/0x1a0 > > > start_kernel+0x0/0x470 > > > start_kernel+0x34c/0x470 > > > __primary_switched+0xbc/0xc4 If we look into for this callback, we can see the lock sequence is: cti_cpu_pm_notify() `> cpu_pm_notify_robust(): `> raw_spin_lock_irqsave(cpu_pm_notifier.lock, flag) -> a raw spinlock `> cti_cpu_pm_notify() `> spin_lock(&drvdata->spinlock) -> a normal spinlock A raw spinlock is not a sleepable lock, and normal spinlock can be a sleepable lock (e.g. it can be a mutex after enabled PREEMPT_RT). One solution is we can change to a raw spinlock in CTI driver, so this can dismiss the lockdep warning. Actually, I am a bit suspect if it's really necessary to use spinlock in CTI PM callbacks, the reason is in CPU's idle flow, it will run into idle thread context and disable the local IRQ, which means it likely has no race condition with thread context and interrupt handler, so we can remove the locking in PM callbacks. Mike, could you check for this? Thanks! Leo

3 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight