CoreSight

coresight@lists.linaro.org

6 participants
2351 discussions

Re: [PATCH 1/3] coresight etm4x: Early clear TRCOSLAR.OSLK prior to TRCIDR1 read

by Suzuki K Poulose

On 02/02/2023 17:12, Steve Clevenger wrote: > Hi Suzuki, > > Commented in-line. > > Steve C. > > On 2/2/2023 3:16 AM, Suzuki K Poulose wrote: >> On 02/02/2023 05:20, Steve Clevenger wrote: >>> >>> Hi Suzuki, >>> >>> I've split out the bug fix (i.e. nr_addr_cmp use) to a separate patch >> >> Thanks for that. >> >>> and added references to the Ampere erratum in silicon-errata.rst. >>> These will be submitted as separate patches. >>> >>> The ETM4.x TRCOSLAR.OSLK early clear has moved to etm4_init_csdev_iomem >>> for all manufacturers. I think this is what you asked for. >>> The no_quad_mmio flag has moved to struct csdev_access, and the split >>> 64-bit read/write logic has been implemented entirely in the header file >>> coresight-etm4x.h is the existing calls. >>> I'd like to retire this patch thread, and submit these as a new thread. >>> Is there an objection? >> >> I would still like to use the system instructions method for the ETM, >> than hacking the MMIO access for something that is obsolete. >> The ACPI document for CoreSight will be published soon for review to >> accommodate the description for ETMs without MMIO and it no longer >> mandates the MemoryResource. >> >> What is the objection to using system instruction access here ? > No objection going forward. For our initial release, we're not in a > position to change the CoreSight DSDT based on a specification which is > incomplete. There is on change to the CoreSight DSDT specification as such. The only change to the "spec" is along the lines of : "MMIO interface is mandatory only if not accessible via system instruction access " > Based on a quick sysreg only build, I didn't collect trace samples. I > haven't had time to chase this, but the reported error is "timeout while > waiting for Trace Idle Status" on a TRCSTATR read. More testing is Are you able to access the other registers ? e.g, $ cat /sys/bus/coresight/devices/etm0/mgmt/trcpidr0 Suzuki > required. If this isn't related to an Ampere sysreg access problem > (doubtful), the next place I'd look is as a synchronization issue. > >> >> Thanks >> Suzuki >> >> >> >>> >>> Thanks, >>> Steve >>> >>> On 1/23/2023 2:51 PM, Suzuki K Poulose wrote: >>>> >>>> Missed the reference, see below. >>>> >>>> On 23/01/2023 22:18, Suzuki K Poulose wrote: >>>>> On 23/01/2023 19:48, Steve Clevenger wrote: >>>>>> >>>>>> >>>>>> On 1/23/2023 9:33 AM, Suzuki K Poulose wrote: >>>>>>> On 23/01/2023 17:22, Steve Clevenger wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 1/23/2023 2:54 AM, Suzuki K Poulose wrote: >>>>>>>>> On 21/01/2023 07:30, Steve Clevenger wrote: >>>>>>>>>> >>>>>>>>>> Hi Suzuki, >>>>>>>>>> >>>>>>>>>> Comments in-line. Please note the approach I attempted while >>>>>>>>>> adding in >>>>>>>>>> the Ampere support was to otherwise not disturb existing driver >>>>>>>>>> code >>>>>>>>>> for >>>>>>>>>> non-Ampere parts. >>>>>>>>>> >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> On 1/20/2023 3:12 AM, Suzuki K Poulose wrote: >>>>>>>>>>> Hi Steve >>>>>>>>>>> >>>>>>>>>>> Thanks for the patches. Have a few comments below. >>>>>>>>>>> >>>>>>>>>>> On 20/01/2023 00:51, Steve Clevenger wrote: >>>>>>>>>>>> Add Ampere early clear of ETM TRCOSLAR.OSLK prior to TRCIDR1 >>>>>>>>>>>> access. >>>>>>>>>>>> Ampere Computing erratum AC03_DEBUG_06 describes an Ampere >>>>>>>>>>>> Computing design decision MMIO reads are considered the same >>>>>>>>>>>> as an >>>>>>>>>>>> external debug access. If TRCOSLAR.OSLK is set, the TRCIDR1 >>>>>>>>>>>> access >>>>>>>>>>>> results in a bus fault followed by a kernel panic. A TRCIDR1 >>>>>>>>>>>> read >>>>>>>>>>>> is valid regardless of TRCOSLAR.OSLK provided MMIO access >>>>>>>>>>>> (now deprecated) is supported. >>>>>>>>>>>> AC03_DEBUG_06 is described in the AmpereOne Developer Errata: >>>>>>>>>>>> https://solutions.amperecomputing.com/customer-connect/products/AmpereOne-d… >>>>>>>>>>> >>>>>>>>>>> Please could you add this erratum to the : >>>>>>>>>>> >>>>>>>>>>> Documentation/arm64/silicon-errata.rst ? >>>>>>>>>>> >>>>>>>>>>> Given the ETM is v4.6, doesn't it support system instructions and >>>>>>>>>>> that is causing this issue of "MMIO access is considered >>>>>>>>>>> external" ? >>>>>>>>>>> If it does, I think we should drop all of this and simply wire >>>>>>>>>>> the >>>>>>>>>>> system instruction access support. >>>>>>>>> >>>>>>>>>> That's not the issue in this case. This MMIO access should've been >>>>>>>>>> allowed by the Ampere ETMv4.6 implementation. Based on comments >>>>>>>>>> I've >>>>>>>>> >>>>>>>>> That doesn't answe the question. Please could you confirm the >>>>>>>>> value of >>>>>>>>> ID_AA64DFR0_EL1 on your system ? >>>>>>>> This ID_AA64DFR0_EL1 value came from a TRACE32 debug session >>>>>>>> connected >>>>>>>> to this part. The ID_AA64DFR0_EL1 value is 0x000F01F210307619. So, >>>>>>>> TraceVer, bits [7:4] are b0001. My understanding is the system >>>>>>>> register >>>>>>>> interface must be implemented on all ETMv4.6 parts. >>>>>>> >>>>>>> So, I don't understand why we are pushing towards enabling the >>>>>>> "obsolete" MMIO interface ? Is this because "ACPI" mandates it ? >>>>>>> Then, please don't. The spec needs an update to reflect the ETMs >>>>>>> with sysreg access and ETEs. >>>>>>> >>>>>>> Why not stick to the system register access* ? >>>>>>> >>>>>>> * PS: The ACPI support for the ETM/ETE needs additional changes to >>>>>>> the >>>>>>> CoreSight driver, *not* the CoreSight ACPI spec. @Anshuman is >>>>>>> working on >>>>>>> this at the moment and will be available soon. >>>>>>> >>>>>>> The hack patch below should be sufficient to give it a try and if it >>>>>>> works. >>>>> >>>>>> I don't understand your postscript. Certainly there's driver work >>>>>> to be >>>>>> done, but I also think the DEN0067 CoreSight ACPI specification needs >>>>> >>>>> The issue is having a single HID for ETMs (which from a spec point of >>>>> view makes sense for) with and without MMIO access. That brings two >>>>> different components in Linux (AMBA hook for ACPI and a platform >>>>> driver) >>>>> compete for the said HID. There are other reasons to disconnect the >>>>> CoreSight from AMBA framework and manage them directly [0]. >>>> >>>> [0] >>>> https://lkml.kernel.org/r/e37e12ab-9701-2883-724a-2a281ad35df2@arm.com >>>> >>>> >>

2 years, 3 months

Re: [PATCH v2] coresight: tmc: Don't enable TMC when it's not ready.

by Mike Leach

Hi, On Fri, 27 Jan 2023 at 23:10, Yabin Cui <yabinc(a)google.com> wrote: > > If TMC ETR is enabled without being ready, in later use we may > see AXI bus errors caused by accessing invalid addresses. > > Signed-off-by: Yabin Cui <yabinc(a)google.com> > --- > V1 -> V2: Make change to all TMCs instead of just ETR > > .../hwtracing/coresight/coresight-tmc-core.c | 4 +- > .../hwtracing/coresight/coresight-tmc-etf.c | 43 +++++++++++++++---- > .../hwtracing/coresight/coresight-tmc-etr.c | 18 ++++++-- > drivers/hwtracing/coresight/coresight-tmc.h | 2 +- > 4 files changed, 53 insertions(+), 14 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c > index 07abf28ad725..c106d142e632 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-core.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c > @@ -31,7 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(etb_devs, "tmc_etb"); > DEFINE_CORESIGHT_DEVLIST(etf_devs, "tmc_etf"); > DEFINE_CORESIGHT_DEVLIST(etr_devs, "tmc_etr"); > > -void tmc_wait_for_tmcready(struct tmc_drvdata *drvdata) > +int tmc_wait_for_tmcready(struct tmc_drvdata *drvdata) > { > struct coresight_device *csdev = drvdata->csdev; > struct csdev_access *csa = &csdev->access; > @@ -40,7 +40,9 @@ void tmc_wait_for_tmcready(struct tmc_drvdata *drvdata) > if (coresight_timeout(csa, TMC_STS, TMC_STS_TMCREADY_BIT, 1)) { > dev_err(&csdev->dev, > "timeout while waiting for TMC to be Ready\n"); > + return -EBUSY; > } > + return 0; > } > > void tmc_flush_and_stop(struct tmc_drvdata *drvdata) > diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c > index 4c4cbd1f7258..2840227e9135 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c > @@ -16,12 +16,19 @@ > static int tmc_set_etf_buffer(struct coresight_device *csdev, > struct perf_output_handle *handle); > > -static void __tmc_etb_enable_hw(struct tmc_drvdata *drvdata) > +static int __tmc_etb_enable_hw(struct tmc_drvdata *drvdata) > { > + int rc = 0; > + > CS_UNLOCK(drvdata->base); > > /* Wait for TMCSReady bit to be set */ > - tmc_wait_for_tmcready(drvdata); > + rc = tmc_wait_for_tmcready(drvdata); > + if (rc) { > + dev_err(&drvdata->csdev->dev, "fails to enable not ready TMC\n"); > + CS_LOCK(drvdata->base); > + return rc; > + } > > writel_relaxed(TMC_MODE_CIRCULAR_BUFFER, drvdata->base + TMC_MODE); > writel_relaxed(TMC_FFCR_EN_FMT | TMC_FFCR_EN_TI | > @@ -33,6 +40,7 @@ static void __tmc_etb_enable_hw(struct tmc_drvdata *drvdata) > tmc_enable_hw(drvdata); > > CS_LOCK(drvdata->base); > + return rc; > } > > static int tmc_etb_enable_hw(struct tmc_drvdata *drvdata) > @@ -42,8 +50,10 @@ static int tmc_etb_enable_hw(struct tmc_drvdata *drvdata) > if (rc) > return rc; > > - __tmc_etb_enable_hw(drvdata); > - return 0; > + rc = __tmc_etb_enable_hw(drvdata); > + if (rc) > + coresight_disclaim_device(drvdata->csdev); > + return rc; > } > > static void tmc_etb_dump_hw(struct tmc_drvdata *drvdata) > @@ -91,12 +101,19 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata) > coresight_disclaim_device(drvdata->csdev); > } > > -static void __tmc_etf_enable_hw(struct tmc_drvdata *drvdata) > +static int __tmc_etf_enable_hw(struct tmc_drvdata *drvdata) > { > + int rc = 0; > + > CS_UNLOCK(drvdata->base); > > /* Wait for TMCSReady bit to be set */ > - tmc_wait_for_tmcready(drvdata); > + rc = tmc_wait_for_tmcready(drvdata); > + if (rc) { > + dev_err(&drvdata->csdev->dev, "fails to enable not ready TMC\n"); > + CS_LOCK(drvdata->base); > + return rc; > + } > > writel_relaxed(TMC_MODE_HARDWARE_FIFO, drvdata->base + TMC_MODE); > writel_relaxed(TMC_FFCR_EN_FMT | TMC_FFCR_EN_TI, > @@ -105,6 +122,7 @@ static void __tmc_etf_enable_hw(struct tmc_drvdata *drvdata) > tmc_enable_hw(drvdata); > > CS_LOCK(drvdata->base); > + return rc; > } > > static int tmc_etf_enable_hw(struct tmc_drvdata *drvdata) > @@ -114,8 +132,10 @@ static int tmc_etf_enable_hw(struct tmc_drvdata *drvdata) > if (rc) > return rc; > > - __tmc_etf_enable_hw(drvdata); > - return 0; > + rc = __tmc_etf_enable_hw(drvdata); > + if (rc) > + coresight_disclaim_device(drvdata->csdev); > + return rc; > } > > static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata) > @@ -639,6 +659,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata) > char *buf = NULL; > enum tmc_mode mode; > unsigned long flags; > + int rc = 0; > > /* config types are set a boot time and never change */ > if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB && > @@ -664,7 +685,11 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata) > * can't be NULL. > */ > memset(drvdata->buf, 0, drvdata->size); > - __tmc_etb_enable_hw(drvdata); > + rc = __tmc_etb_enable_hw(drvdata); > + if (rc) { > + spin_unlock_irqrestore(&drvdata->spinlock, flags); > + return rc; > + } There is a similar unprepare function in ETR - this should have similar updates. > } else { > /* > * The ETB/ETF is not tracing and the buffer was just read. > diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c > index 867ad8bb9b0c..0811cb44588b 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c > @@ -983,15 +983,21 @@ static void tmc_sync_etr_buf(struct tmc_drvdata *drvdata) > etr_buf->ops->sync(etr_buf, rrp, rwp); > } > > -static void __tmc_etr_enable_hw(struct tmc_drvdata *drvdata) > +static int __tmc_etr_enable_hw(struct tmc_drvdata *drvdata) > { > u32 axictl, sts; > struct etr_buf *etr_buf = drvdata->etr_buf; > + int rc = 0; > > CS_UNLOCK(drvdata->base); > > /* Wait for TMCSReady bit to be set */ > - tmc_wait_for_tmcready(drvdata); > + rc = tmc_wait_for_tmcready(drvdata); > + if (rc) { > + dev_err(&drvdata->csdev->dev, "fails to enable not ready TMC\n"); > + CS_LOCK(drvdata->base); > + return rc; > + } > > writel_relaxed(etr_buf->size / 4, drvdata->base + TMC_RSZ); > writel_relaxed(TMC_MODE_CIRCULAR_BUFFER, drvdata->base + TMC_MODE); > @@ -1032,6 +1038,7 @@ static void __tmc_etr_enable_hw(struct tmc_drvdata *drvdata) > tmc_enable_hw(drvdata); > > CS_LOCK(drvdata->base); > + return rc; > } > > static int tmc_etr_enable_hw(struct tmc_drvdata *drvdata, > @@ -1060,7 +1067,12 @@ static int tmc_etr_enable_hw(struct tmc_drvdata *drvdata, > rc = coresight_claim_device(drvdata->csdev); > if (!rc) { > drvdata->etr_buf = etr_buf; > - __tmc_etr_enable_hw(drvdata); > + rc = __tmc_etr_enable_hw(drvdata); > + if (rc) { > + drvdata->etr_buf = NULL; > + coresight_disclaim_device(drvdata->csdev); > + tmc_etr_disable_catu(drvdata); > + } > } > > return rc; > diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h > index 66959557cf39..01c0382a29c0 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc.h > +++ b/drivers/hwtracing/coresight/coresight-tmc.h > @@ -255,7 +255,7 @@ struct tmc_sg_table { > }; > > /* Generic functions */ > -void tmc_wait_for_tmcready(struct tmc_drvdata *drvdata); > +int tmc_wait_for_tmcready(struct tmc_drvdata *drvdata); > void tmc_flush_and_stop(struct tmc_drvdata *drvdata); > void tmc_enable_hw(struct tmc_drvdata *drvdata); > void tmc_disable_hw(struct tmc_drvdata *drvdata); > -- > 2.39.1.456.gfc5497dd1b-goog > The tmc_flush_and_stop() function also calls tmc_wait_for_tmcready(). The etb/etf_prepare_read operations disable the etb /etf before a read commences. For consistency if this fails due to TMC not being ready do we also need to fail the read prepare operations? Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

2 years, 3 months

Re: [PATCH 1/3] coresight etm4x: Early clear TRCOSLAR.OSLK prior to TRCIDR1 read

by Suzuki K Poulose

On 02/02/2023 05:20, Steve Clevenger wrote: > > Hi Suzuki, > > I've split out the bug fix (i.e. nr_addr_cmp use) to a separate patch Thanks for that. > and added references to the Ampere erratum in silicon-errata.rst. > These will be submitted as separate patches. > > The ETM4.x TRCOSLAR.OSLK early clear has moved to etm4_init_csdev_iomem > for all manufacturers. I think this is what you asked for. > The no_quad_mmio flag has moved to struct csdev_access, and the split > 64-bit read/write logic has been implemented entirely in the header file > coresight-etm4x.h is the existing calls. > I'd like to retire this patch thread, and submit these as a new thread. > Is there an objection? I would still like to use the system instructions method for the ETM, than hacking the MMIO access for something that is obsolete. The ACPI document for CoreSight will be published soon for review to accommodate the description for ETMs without MMIO and it no longer mandates the MemoryResource. What is the objection to using system instruction access here ? Thanks Suzuki > > Thanks, > Steve > > On 1/23/2023 2:51 PM, Suzuki K Poulose wrote: >> >> Missed the reference, see below. >> >> On 23/01/2023 22:18, Suzuki K Poulose wrote: >>> On 23/01/2023 19:48, Steve Clevenger wrote: >>>> >>>> >>>> On 1/23/2023 9:33 AM, Suzuki K Poulose wrote: >>>>> On 23/01/2023 17:22, Steve Clevenger wrote: >>>>>> >>>>>> >>>>>> On 1/23/2023 2:54 AM, Suzuki K Poulose wrote: >>>>>>> On 21/01/2023 07:30, Steve Clevenger wrote: >>>>>>>> >>>>>>>> Hi Suzuki, >>>>>>>> >>>>>>>> Comments in-line. Please note the approach I attempted while >>>>>>>> adding in >>>>>>>> the Ampere support was to otherwise not disturb existing driver code >>>>>>>> for >>>>>>>> non-Ampere parts. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> On 1/20/2023 3:12 AM, Suzuki K Poulose wrote: >>>>>>>>> Hi Steve >>>>>>>>> >>>>>>>>> Thanks for the patches. Have a few comments below. >>>>>>>>> >>>>>>>>> On 20/01/2023 00:51, Steve Clevenger wrote: >>>>>>>>>> Add Ampere early clear of ETM TRCOSLAR.OSLK prior to TRCIDR1 >>>>>>>>>> access. >>>>>>>>>> Ampere Computing erratum AC03_DEBUG_06 describes an Ampere >>>>>>>>>> Computing design decision MMIO reads are considered the same as an >>>>>>>>>> external debug access. If TRCOSLAR.OSLK is set, the TRCIDR1 access >>>>>>>>>> results in a bus fault followed by a kernel panic. A TRCIDR1 read >>>>>>>>>> is valid regardless of TRCOSLAR.OSLK provided MMIO access >>>>>>>>>> (now deprecated) is supported. >>>>>>>>>> AC03_DEBUG_06 is described in the AmpereOne Developer Errata: >>>>>>>>>> https://solutions.amperecomputing.com/customer-connect/products/AmpereOne-d… >>>>>>>>> >>>>>>>>> Please could you add this erratum to the : >>>>>>>>> >>>>>>>>> Documentation/arm64/silicon-errata.rst ? >>>>>>>>> >>>>>>>>> Given the ETM is v4.6, doesn't it support system instructions and >>>>>>>>> that is causing this issue of "MMIO access is considered >>>>>>>>> external" ? >>>>>>>>> If it does, I think we should drop all of this and simply wire the >>>>>>>>> system instruction access support. >>>>>>> >>>>>>>> That's not the issue in this case. This MMIO access should've been >>>>>>>> allowed by the Ampere ETMv4.6 implementation. Based on comments >>>>>>>> I've >>>>>>> >>>>>>> That doesn't answe the question. Please could you confirm the >>>>>>> value of >>>>>>> ID_AA64DFR0_EL1 on your system ? >>>>>> This ID_AA64DFR0_EL1 value came from a TRACE32 debug session connected >>>>>> to this part. The ID_AA64DFR0_EL1 value is 0x000F01F210307619. So, >>>>>> TraceVer, bits [7:4] are b0001. My understanding is the system >>>>>> register >>>>>> interface must be implemented on all ETMv4.6 parts. >>>>> >>>>> So, I don't understand why we are pushing towards enabling the >>>>> "obsolete" MMIO interface ? Is this because "ACPI" mandates it ? >>>>> Then, please don't. The spec needs an update to reflect the ETMs >>>>> with sysreg access and ETEs. >>>>> >>>>> Why not stick to the system register access* ? >>>>> >>>>> * PS: The ACPI support for the ETM/ETE needs additional changes to the >>>>> CoreSight driver, *not* the CoreSight ACPI spec. @Anshuman is >>>>> working on >>>>> this at the moment and will be available soon. >>>>> >>>>> The hack patch below should be sufficient to give it a try and if it >>>>> works. >>> >>>> I don't understand your postscript. Certainly there's driver work to be >>>> done, but I also think the DEN0067 CoreSight ACPI specification needs >>> >>> The issue is having a single HID for ETMs (which from a spec point of >>> view makes sense for) with and without MMIO access. That brings two >>> different components in Linux (AMBA hook for ACPI and a platform driver) >>> compete for the said HID. There are other reasons to disconnect the >>> CoreSight from AMBA framework and manage them directly [0]. >> >> [0] https://lkml.kernel.org/r/e37e12ab-9701-2883-724a-2a281ad35df2@arm.com >> >>

2 years, 3 months

[GIT PULL] coresight: Updates for v6.3

by Suzuki K Poulose

Hi Greg, Please find the updates for CoreSight and hwtracing subsystem for inclusion in v6.3. fyi, there is a patch to export perf_report_aux_output_id(), a perf generic helper for emitting AUX packet. This has been Acked by Peter and is used by the CoreSight dynamic trace id allocation scheme. Hence routing via the coresight tree. Kindly consider pulling. Suzuki The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98: Linux 6.2-rc2 (2023-01-01 13:53:16 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.3 for you to fetch changes up to 669c4614236a7f78a2b693d0024cbdfa8536eb5a: coresight: tmc: Don't enable TMC when it's not ready. (2023-01-30 11:45:32 +0000) ---------------------------------------------------------------- coresight: Updates for v6.3 - Dynamic TraceID allocation scheme for CoreSight trace source. Allows systems with > 44 CPUs to use the ETMs. TraceID is advertised via AUX_OUTPUT_HWID packets in perf.data. Also allows allocating trace-ids for non-CPU bound trace components (e.g., Qualcomm TPDA). - Support for Qualcomm TPDA and TPDM CoreSight devices. - Support for Ultrasoc SMB CoreSight Sink buffer. - Fixes for HiSilicon PTT driver - MAINTAINERS update: Add Reviewer for HiSilicon PTT driver - Bug fixes for CTI power management and sysfs mode - Fix CoreSight ETM4x TRCSEQRSTEVRn access Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- Arnd Bergmann (1): Coresight: tpda/tpdm: remove incorrect __exit annotation Bagas Sanjaya (2): Documentation: coresight: Extend title heading syntax in TPDM and TPDA documentation Documentation: coresight: tpdm: Add dummy comment after sysfs list James Clark (2): coresight: cti: Prevent negative values of enable count coresight: cti: Remove atomic type from enable_req_count Junhao He (1): coresight: etm4x: Fix accesses to TRCSEQRSTEVR and TRCSEQSTR Mao Jinlong (9): coresight: cti: Add PM runtime call in enable_store coresight: core: Use IDR for non-cpu bound sources' paths. Coresight: Add coresight TPDM source driver dt-bindings: arm: Add CoreSight TPDM hardware 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 Documentation: trace: Add documentation for TPDM and TPDA Mike Leach (11): coresight: trace-id: Add API to dynamically assign Trace ID values coresight: Remove obsolete Trace ID unniqueness checks coresight: perf: traceid: Add perf ID allocation and notifiers coresight: stm: Update STM driver to use Trace ID API coresight: etm4x: Update ETM4 driver to use Trace ID API coresight: etm3x: Update ETM3 driver to use Trace ID API coresight: etmX.X: stm: Remove trace_id() callback coresight: trace id: Remove legacy get trace ID function. kernel: events: Export perf_report_aux_output_id() coresight: events: PERF_RECORD_AUX_OUTPUT_HW_ID used for Trace ID coresight: trace-id: Add debug & test macros to Trace ID allocation Qi Liu (2): drivers/coresight: Add UltraSoc System Memory Buffer driver Documentation: Add document for UltraSoc SMB driver Suzuki K Poulose (2): coresight: Fix uninitialised variable use in coresight_disable coresight: perf: Output trace id only once Yabin Cui (1): coresight: tmc: Don't enable TMC when it's not ready. Yang Yingliang (2): coresight: ultrasoc-smb: fix return value check in smb_init_data_buffer() coresight: tpda: fix return value check in tpda_probe() Yicong Yang (2): hwtracing: hisi_ptt: Only add the supported devices to the filters list MAINTAINERS: Update the entries for HiSilicon PTT device driver .../ABI/testing/sysfs-bus-coresight-devices-etm3x | 2 +- .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 13 + .../testing/sysfs-bus-coresight-devices-ultra_smb | 31 + .../bindings/arm/qcom,coresight-tpda.yaml | 129 ++++ .../bindings/arm/qcom,coresight-tpdm.yaml | 93 +++ Documentation/trace/coresight/coresight-tpda.rst | 52 ++ Documentation/trace/coresight/coresight-tpdm.rst | 45 ++ Documentation/trace/coresight/ultrasoc-smb.rst | 83 +++ MAINTAINERS | 5 + drivers/hwtracing/coresight/Kconfig | 35 ++ drivers/hwtracing/coresight/Makefile | 5 +- drivers/hwtracing/coresight/coresight-core.c | 87 +-- drivers/hwtracing/coresight/coresight-cti-core.c | 23 +- drivers/hwtracing/coresight/coresight-cti-sysfs.c | 15 +- drivers/hwtracing/coresight/coresight-cti.h | 2 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 31 + drivers/hwtracing/coresight/coresight-etm-perf.h | 2 + drivers/hwtracing/coresight/coresight-etm.h | 3 +- drivers/hwtracing/coresight/coresight-etm3x-core.c | 95 +-- .../hwtracing/coresight/coresight-etm3x-sysfs.c | 27 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 91 ++- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 27 +- drivers/hwtracing/coresight/coresight-etm4x.h | 3 + drivers/hwtracing/coresight/coresight-stm.c | 49 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 4 +- drivers/hwtracing/coresight/coresight-tmc-etf.c | 45 +- drivers/hwtracing/coresight/coresight-tmc-etr.c | 19 +- drivers/hwtracing/coresight/coresight-tmc.h | 2 +- drivers/hwtracing/coresight/coresight-tpda.c | 211 +++++++ drivers/hwtracing/coresight/coresight-tpda.h | 35 ++ drivers/hwtracing/coresight/coresight-tpdm.c | 259 ++++++++ drivers/hwtracing/coresight/coresight-tpdm.h | 62 ++ drivers/hwtracing/coresight/coresight-trace-id.c | 297 ++++++++++ drivers/hwtracing/coresight/coresight-trace-id.h | 156 +++++ drivers/hwtracing/coresight/ultrasoc-smb.c | 648 +++++++++++++++++++++ drivers/hwtracing/coresight/ultrasoc-smb.h | 125 ++++ drivers/hwtracing/ptt/hisi_ptt.c | 10 + include/linux/coresight-pmu.h | 34 +- include/linux/coresight.h | 4 +- kernel/events/core.c | 1 + 40 files changed, 2649 insertions(+), 211 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb 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 Documentation/trace/coresight/coresight-tpda.rst create mode 100644 Documentation/trace/coresight/coresight-tpdm.rst create mode 100644 Documentation/trace/coresight/ultrasoc-smb.rst 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 create mode 100644 drivers/hwtracing/coresight/coresight-trace-id.c create mode 100644 drivers/hwtracing/coresight/coresight-trace-id.h create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h

2 years, 3 months

Re: [PATCH 31/35] Documentation: trace: correct spelling

by Suzuki K Poulose

On 27/01/2023 06:40, Randy Dunlap wrote: > Correct spelling problems for Documentation/trace/ as reported > by codespell. > > Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> > Cc: Steven Rostedt <rostedt(a)goodmis.org> > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > Cc: Daniel Bristot de Oliveira <bristot(a)kernel.org> > Cc: linux-trace-kernel(a)vger.kernel.org > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Cc: coresight(a)lists.linaro.org > Cc: linux-arm-kernel(a)lists.infradead.org > Cc: Jonathan Corbet <corbet(a)lwn.net> > Cc: linux-doc(a)vger.kernel.org > --- > Documentation/trace/coresight/coresight-etm4x-reference.rst | 2 +- > Documentation/trace/events.rst | 6 +++--- > Documentation/trace/fprobe.rst | 2 +- > Documentation/trace/ftrace-uses.rst | 2 +- > Documentation/trace/hwlat_detector.rst | 2 +- > Documentation/trace/rv/runtime-verification.rst | 2 +- > Documentation/trace/uprobetracer.rst | 2 +- > 7 files changed, 9 insertions(+), 9 deletions(-) > > diff -- a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst > --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst > +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst > @@ -675,7 +675,7 @@ Bit assignments shown below:- > reconstructed using only conditional branches. > > There is currently no support in Perf for supplying modified binaries to the decoder, so this > - feature is only inteded to be used for debugging purposes or with a 3rd party tool. > + feature is only intended to be used for debugging purposes or with a 3rd party tool. > > Choosing this option will result in a significant increase in the amount of trace generated - > possible danger of overflows, or fewer instructions covered. Note, that this option also For the above: Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Thanks Suzuki

2 years, 3 months

Re: [PATCH v2 1/9] dt-bindings: arm: Add support for DSB element

by Tao Zhang

Hi Krzysztof, On 1/19/2023 6:44 PM, Krzysztof Kozlowski wrote: > On 19/01/2023 08:41, Tao Zhang wrote: >> Add property "qcom,dsb-elem-size" to support DSB(Discrete Single >> Bit) element for TPDA. Specifies the DSB element size supported >> by each monitor connected to the aggregator on each port. Should >> be specified in pairs (port, dsb element size). >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> Signed-off-by: Tao Zhang <taozha(a)qti.qualcomm.com> > You are the same person and it is still the same organization > (Qualcomm), right? Only one SoB. I will change and update this in the next patch series. > >> --- >> .../bindings/arm/qcom,coresight-tpda.yaml | 22 ++++++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml >> index 2ec9b5b..298db7f 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml >> @@ -58,6 +58,26 @@ properties: >> minItems: 1 >> maxItems: 2 >> >> + qcom,dsb-element-size: >> + description: | >> + Specifies the DSB(Discrete Single Bit) element size supported by >> + each monitor connected to the aggregator on each port. Should be >> + specified in pairs <port, dsb element size>. > s/port/port number/ It should be "port number" here. I will change "<port, dsb element size>" to "<port number, DSB element size>" in the next patch series. >> + >> + Note: The maximum value of the port number depends on how many >> + input ports the current TPDA has. DSB element size currently only >> + supports 32-bit and 64-bit. >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >> + items: > Are some reasonable maxItems known? This is related to hardware design, depending on how many input ports the TPDA has. We cannot limit it to a reasonable maximum value from the software. According to the existing hardware design, TPDA with the most input ports has about 30 input ports. But there may be TPDA with more input ports. > >> + items: >> + - description: | >> + "port" indicates TPDA input port number > What is "port"? You quoted it like it was some name of variable or > property. Where is then? The "port" here refers to the port number of other Coresight devices connected to the TPDA input port. I will change and update it in the next patch series. >> + minimum: 0 >> + - description: | >> + "dsb element size" indicates dsb element size > "A" indicates A. This sentence does not make sense. > > Also missing units. > > s/dsb/DSB/ "DSB element size" indicate the size of the element in DSB. DSB(Discrete Single Bit) is a data collection unit. I will change and update it in the next patch series. > >> + minimum: 0 >> + maximum: 64 >> + >> clocks: >> maxItems: 1 >> >> @@ -100,6 +120,8 @@ examples: >> compatible = "qcom,coresight-tpda", "arm,primecell"; >> reg = <0x6004000 0x1000>; >> >> + qcom,dsb-element-size = <0 32>; >> + >> clocks = <&aoss_qmp>; >> clock-names = "apb_pclk"; >> > Best regards, > Krzysztof Best, Tao

2 years, 3 months

Re: [PATCH] perf: cs-etm: Update decoder code for OpenCSD version 1.4

by James Clark

On 24/01/2023 21:50, Ian Rogers wrote: > On Fri, Jan 20, 2023 at 7:47 AM James Clark <james.clark(a)arm.com> wrote: >> >> >> >> On 20/01/2023 15:37, Mike Leach wrote: >>> OpenCSD version 1.4 is released with support for FEAT_ITE. >>> This adds a new packet type, with associated output element ID in >>> the packet type enum - OCSD_GEN_TRC_ELEM_INSTRUMENTATION. >>> >>> As we just ignore this packet in perf, add to the switch statement >>> to avoid the "enum not handled in switch error", but conditionally >>> so as not to break the perf build for older OpenCSD installations. >>> >>> Signed-off-by: Mike Leach <mike.leach(a)linaro.org> >>> --- >>> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >>> index fa3aa9c0fb2e..48e7121880a9 100644 >>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >>> @@ -604,6 +604,9 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer( >>> case OCSD_GEN_TRC_ELEM_CUSTOM: >>> case OCSD_GEN_TRC_ELEM_SYNC_MARKER: >>> case OCSD_GEN_TRC_ELEM_MEMTRANS: >>> +#if (OCSD_VER_NUM >= 0x010400) >>> + case OCSD_GEN_TRC_ELEM_INSTRUMENTATION: >>> +#endif >>> default: >>> break; >>> } >> >> Checked the build with both old and new versions of OpenCSD and it's ok: >> >> Reviewed-by: James Clark <james.clark(a)arm.com> > > Acked-by: Ian Rogers <irogers(a)google.com> > > Thanks, > Ian Hi Arnaldo, Is it ok to merge this change? If anyone is building with the latest OpenCSD they will get a build error on the unhandled switch case, and we just got it in our CI too. I suppose we could disable the warning around this switch, but it's pretty rare to add new packets so might be best to leave it. Thanks James

2 years, 3 months

Re: [PATCH -next] coresight: tpda: fix return value check in tpda_probe()

by Suzuki K Poulose

On 29/01/2023 08:42, Yang Yingliang wrote: > devm_ioremap_resource() never returns NULL pointer, it > will return ERR_PTR() when it fails, so replace the check > with IS_ERR(). Thanks for the patch. > > Fixes: 5b7916625c01 ("Coresight: Add TPDA link driver") > Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> > --- > drivers/hwtracing/coresight/coresight-tpda.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c > index 19c25c9f6157..6313b12880e0 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.c > +++ b/drivers/hwtracing/coresight/coresight-tpda.c > @@ -145,7 +145,7 @@ static int tpda_probe(struct amba_device *adev, const struct amba_id *id) > dev_set_drvdata(dev, drvdata); > > base = devm_ioremap_resource(dev, &adev->res); > - if (!base) > + if (IS_ERR(base)) > return -ENOMEM; I have fixed this up to : return PTR_ERR(base); for consistency. Thanks Suzuki

2 years, 3 months

Re: [PATCH] Coresight: tpda/tpdm: remove incorrect __exit annotation

by Suzuki K Poulose

On 27/01/2023 17:00, Arnd Bergmann wrote: > On Fri, Jan 27, 2023, at 17:46, Suzuki K Poulose wrote: >> On 26/01/2023 20:37, Arnd Bergmann wrote: >>> On Thu, Jan 26, 2023, at 19:02, Suzuki K Poulose wrote: >>>> On 26/01/2023 16:35, Arnd Bergmann wrote: >>>>> From: Arnd Bergmann <arnd(a)arndb.de> >>>> Thanks for the fix, I will queue this. Btw, I did try to >>>> reproduce it locally, but couldn't trigger the warnings, >>>> even with >>>> >>>> CONFIG_WERROR=y >>>> >>>> and all CORESIGHT configs builtin. I see other drivers doing the >>>> same outside coresight too. Just curious to know why is this >>>> any different. Is it specific to "bus" driver (e.g. AMBA) ? >>> >>> The warning comes from postprocessing the object file, it's got >>> nothing to do with the bus type, only with a symbol in .data >>> referencing a symbol in .init.text. Maybe there are some >>> config options that keep the section from getting discarded? >>> Or possibly you only built the files in this directory, but did >>> not get to the final link? >> >> I did a full kernel build. Also, I see a similar issue with the >> coresight-etm4x (by code inspection) driver. Did you not hit that ? >> >> May be there is a config option that is masking it on my end. But >> the case of etm4x driver is puzzling. >> >> $ git grep etm4_remove_amba >> drivers/hwtracing/coresight/coresight-etm4x-core.c >> drivers/hwtracing/coresight/coresight-etm4x-core.c:static void __exit >> etm4_remove_amba(struct amba_device *adev) >> drivers/hwtracing/coresight/coresight-etm4x-core.c: .remove >> = etm4_remove_amba, > > Indeed, that one clearly has the same but, but I have never > observed a warning for it. > > I checked one more thing and found that I only get the warning > for 32-bit Arm builds, but not arm64. Since the etm4x driver > 'depends on ARM64' for its use of asm/sysreg.h, > I never test-built it on 32-bit arm. > > From the git history of arch/arm64/kernel/vmlinux.lds.S, > I can see that arm64 never discards the .exit section, see > commit 07c802bd7c39 ("arm64: vmlinux.lds.S: don't discard > .exit.* sections at link-time"). That makes sense, thanks for getting to the bottom of this. I have pushed it to coresight next. https://git.kernel.org/coresight/c/0c1ccc158bbc Kind regards Suzuki > > Arnd

2 years, 3 months

Re: [PATCH] Coresight: tpda/tpdm: remove incorrect __exit annotation

by Suzuki K Poulose

On 26/01/2023 20:37, Arnd Bergmann wrote: > On Thu, Jan 26, 2023, at 19:02, Suzuki K Poulose wrote: >> On 26/01/2023 16:35, Arnd Bergmann wrote: >>> From: Arnd Bergmann <arnd(a)arndb.de> >> Thanks for the fix, I will queue this. Btw, I did try to >> reproduce it locally, but couldn't trigger the warnings, >> even with >> >> CONFIG_WERROR=y >> >> and all CORESIGHT configs builtin. I see other drivers doing the >> same outside coresight too. Just curious to know why is this >> any different. Is it specific to "bus" driver (e.g. AMBA) ? > > The warning comes from postprocessing the object file, it's got > nothing to do with the bus type, only with a symbol in .data > referencing a symbol in .init.text. Maybe there are some > config options that keep the section from getting discarded? > Or possibly you only built the files in this directory, but did > not get to the final link? I did a full kernel build. Also, I see a similar issue with the coresight-etm4x (by code inspection) driver. Did you not hit that ? May be there is a config option that is masking it on my end. But the case of etm4x driver is puzzling. $ git grep etm4_remove_amba drivers/hwtracing/coresight/coresight-etm4x-core.c drivers/hwtracing/coresight/coresight-etm4x-core.c:static void __exit etm4_remove_amba(struct amba_device *adev) drivers/hwtracing/coresight/coresight-etm4x-core.c: .remove = etm4_remove_amba, Suzuki > > Arnd

2 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight