CoreSight

coresight@lists.linaro.org

1 participants
2837 discussions

Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain

by Leo Yan

On Tue, Jun 30, 2026 at 04:57:34PM -0700, Namhyung Kim wrote: [...] > Hmm.. it's not applying anymore.. Please rebase. Thanks for reminding. I'll rebase it and resend today.

2 months, 1 week

Re: [PATCH 1/2] coresight: Fix clock refcount imbalance on platform remove

by Leo Yan

On Thu, Jul 02, 2026 at 09:56:05AM +0800, Jie Gan wrote: > static void funnel_platform_remove(struct platform_device *pdev) > { > struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev); > > if (WARN_ON(!drvdata)) > return; > > - funnel_remove(&pdev->dev); > + /* > + * Resume the device so its clocks are enabled again, balancing the > + * clk_disable_unprepare() that devm runs when the driver detaches. > + * Then mark it suspended and drop the usage count taken here. > + */ > pm_runtime_get_sync(&pdev->dev); > + funnel_remove(&pdev->dev); > pm_runtime_disable(&pdev->dev); > + pm_runtime_set_suspended(&pdev->dev); > + pm_runtime_put_noidle(&pdev->dev); LGTM. Thanks for writing up the comment. Please proceed.

2 months, 1 week

Re: [PATCH 1/2] coresight: Fix clock refcount imbalance on platform remove

by Leo Yan

On Wed, Jul 01, 2026 at 02:05:02PM +0800, Jie Gan wrote: > After probe, pm_runtime_put() allows the device to suspend and the > runtime suspend callback disables the same clocks. During remove the > device is left runtime suspended, so pm_runtime_disable() freezes it > with the clocks already disabled. The devm cleanup that runs afterwards > calls clk_disable_unprepare() a second time, underflowing the clock > enable refcount. Thanks for fixing the issue. The problem is that if the device has already been runtime suspended and its clock has been disabled, afterwards when remove the device, the devm cleanup disables the clock again, resulting in clock count underflow. > diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c > index 0abc11f0690c..4c5b94640e6a 100644 > --- a/drivers/hwtracing/coresight/coresight-funnel.c > +++ b/drivers/hwtracing/coresight/coresight-funnel.c > @@ -334,6 +334,7 @@ static void funnel_platform_remove(struct platform_device *pdev) > return; > > funnel_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); Let's use the funnel driver for the discussion. Once we agree on the approach, we can apply the same change to the other CoreSight platform drivers. How about the following teardown? static void funnel_platform_remove(struct platform_device *pdev) { struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev); + int ret; if (WARN_ON(!drvdata)) return; + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) + dev_warn(&pdev->dev, "failed to resume before remove: %d\n", ret); + funnel_remove(&pdev->dev); + pm_runtime_disable(&pdev->dev); + pm_runtime_set_suspended(&pdev->dev); + pm_runtime_put_noidle(&pdev->dev); } The idea is to first resume the device with pm_runtime_get_sync(), then perform the remove (which is safe if they need to access or clean up hardware state), and finally clean up the runtime PM states. I mainly referred to drivers/iio/adc/stm32-adc.c. Thanks, Leo

2 months, 1 week

Re: [PATCH 1/2] coresight: Fix clock refcount imbalance on platform remove

by Yeoreum Yun

Reviewed-by: Yeoreum Yun <yeoreum.yun(a)arm.com> On Wed, Jul 01, 2026 at 02:05:02PM +0800, Jie Gan wrote: > coresight_get_enable_clocks() enables the programming clock and the > optional AT clock through devm_clk_get_optional_enabled(), which also > registers a devm action to call clk_disable_unprepare() when the driver > detaches. > > After probe, pm_runtime_put() allows the device to suspend and the > runtime suspend callback disables the same clocks. During remove the > device is left runtime suspended, so pm_runtime_disable() freezes it > with the clocks already disabled. The devm cleanup that runs afterwards > calls clk_disable_unprepare() a second time, underflowing the clock > enable refcount. > > Resume the device with pm_runtime_get_sync() before pm_runtime_disable() > so the clocks are enabled again and balance the devm-managed disable. > > This affects all CoreSight platform drivers that obtain their clocks > through coresight_get_enable_clocks(): catu, cpu-debug, ctcu, etm4x, > funnel, replicator, stm, tmc and tpiu. > > Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks") > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > drivers/hwtracing/coresight/coresight-catu.c | 1 + > drivers/hwtracing/coresight/coresight-cpu-debug.c | 1 + > drivers/hwtracing/coresight/coresight-ctcu-core.c | 1 + > drivers/hwtracing/coresight/coresight-etm4x-core.c | 1 + > drivers/hwtracing/coresight/coresight-funnel.c | 1 + > drivers/hwtracing/coresight/coresight-replicator.c | 1 + > drivers/hwtracing/coresight/coresight-stm.c | 1 + > drivers/hwtracing/coresight/coresight-tmc-core.c | 1 + > drivers/hwtracing/coresight/coresight-tpiu.c | 1 + > 9 files changed, 9 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c > index ad8dafea7d2f..f7e501e6cbd7 100644 > --- a/drivers/hwtracing/coresight/coresight-catu.c > +++ b/drivers/hwtracing/coresight/coresight-catu.c > @@ -647,6 +647,7 @@ static void catu_platform_remove(struct platform_device *pdev) > return; > > __catu_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c > index 3a806c1d50ea..f7efae5b5ce5 100644 > --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c > @@ -711,6 +711,7 @@ static void debug_platform_remove(struct platform_device *pdev) > return; > > __debug_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c > index 9043cad42f01..9b6da29d9735 100644 > --- a/drivers/hwtracing/coresight/coresight-ctcu-core.c > +++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c > @@ -266,6 +266,7 @@ static void ctcu_platform_remove(struct platform_device *pdev) > return; > > ctcu_remove(pdev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 14bb31bd6a0b..147761024c0f 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -2416,6 +2416,7 @@ static void etm4_remove_platform_dev(struct platform_device *pdev) > > if (drvdata) > etm4_remove_dev(drvdata); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c > index 0abc11f0690c..4c5b94640e6a 100644 > --- a/drivers/hwtracing/coresight/coresight-funnel.c > +++ b/drivers/hwtracing/coresight/coresight-funnel.c > @@ -334,6 +334,7 @@ static void funnel_platform_remove(struct platform_device *pdev) > return; > > funnel_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c > index 2f382de357ee..2d765f1f73b3 100644 > --- a/drivers/hwtracing/coresight/coresight-replicator.c > +++ b/drivers/hwtracing/coresight/coresight-replicator.c > @@ -313,6 +313,7 @@ static void replicator_platform_remove(struct platform_device *pdev) > return; > > replicator_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c > index 4e860519a73f..a653f1eebeca 100644 > --- a/drivers/hwtracing/coresight/coresight-stm.c > +++ b/drivers/hwtracing/coresight/coresight-stm.c > @@ -1026,6 +1026,7 @@ static void stm_platform_remove(struct platform_device *pdev) > return; > > __stm_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c > index bc5a133ada3e..c9cf486873e2 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-core.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c > @@ -989,6 +989,7 @@ static void tmc_platform_remove(struct platform_device *pdev) > return; > > __tmc_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c > index 7b029d2eb389..72ac93749be1 100644 > --- a/drivers/hwtracing/coresight/coresight-tpiu.c > +++ b/drivers/hwtracing/coresight/coresight-tpiu.c > @@ -286,6 +286,7 @@ static void tpiu_platform_remove(struct platform_device *pdev) > return; > > __tpiu_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); > } > > > -- > 2.34.1 > -- Sincerely, Yeoreum Yun

2 months, 1 week

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

by Leo Yan

On Tue, Jun 30, 2026 at 04:42:39PM +0800, Jie Gan wrote: [...] > As Suzuki mentioned in the other thread, I think it would be better to add > separate compatibles in the of_match_table to distinguish between Aggregator > TraceNoC and Interconnect TraceNoC when probing with the platform driver. > This would allow us to allocate an ATID only for Aggregator TraceNoC during > probe, which is consistent with our original design. Makes sense for me!

2 months, 1 week

Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain

by Leo Yan

Hi Namhyung, On Mon, Jun 29, 2026 at 05:36:48PM -0700, Namhyung Kim wrote: [...] > Will you send a new version or want to merge this? It seems there are > some remaining comments from Sashiko. I prefer to merge this series. Sashiko reported several critical issues in the common code, they are on my to-do list. Thanks, Leo

2 months, 1 week

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

by Suzuki K Poulose

On 30/06/2026 02:03, Jie Gan wrote: > > > On 6/29/2026 10:28 PM, Leo Yan wrote: >> On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote: >> >> [...] >> >>> Can I fix the issue by adding "arm,primecell-periphid" property. That's >>> would be the best temp solution as it avoids breaking the original >>> design of >>> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver. >> >> Before proceeding with the "arm,primecell-periphid" property, could you >> clarify a bit: >> >> - For an interconnect TraceNoC, what would be the consequence of >> enabling ATID? Would it simply be a no-op, or are there any side >> effects? Or is the concern that the trace IDs could be exhausted? >> > > TPDM0(or ATB source) -> interconnect TraceNoC0 -> Aggregator TraceNoc -> > sink > TPDM1(or ATB source) -> interconnect TraceNoC1 -> Aggregator TraceNoc -> > sink > > We only have one Aggregator TraceNoC and many interconnect TraceNoC > devices for one platform. All interconnect TraceNoC devices are > connected to Aggregator TraceNoC devices in the topology, so the itnoc > doesnt need an ATID. > > That's the design purpose from hardware perspective. > > >> - How can you guarantee that a interconnect TraceNoC will never >> require ATID in the future? >> > > The interconnect TraceNoC is primarily introduced to reduce routing > complexity in the hardware design. It is typically deployed as an > intermediate TraceNoC that connects to an Aggregator TraceNoC (AG > TraceNoC). You can always distinguish one from the other by checking the "compatibles" or even add a custom data field to the of_device_id table for the platform driver. Personally, I think it is better to keep things away from AMBA framework, when we get everything from platform driver. Cheers Suzuki > > For example, a modem subsystem may contain many TPDM devices. Directly > connecting every TPDM to the AG TraceNoC would result in significant > wiring complexity. Instead, an itnoc is placed within the modem > subsystem to locally aggregate the TPDM connections. All TPDMs first > connect to the itnoc, and the itnoc then connects to the system-level AG > TraceNoC. > > From a hardware perspective, there is no fundamental difference between > an itnoc and an AG TraceNoC. They use the same TraceNoC hardware > implementation and share the same AMBA bus type. The distinction is > purely functional: an itnoc is used for local trace aggregation within a > subsystem, whereas an AG TraceNoC serves as the top-level aggregation > point for the SoC. > > Thanks, > Jie > >>> The TraceNoC device here must be treated as an AMBA device and I am >>> continuing to investigate the issue with our hardware team. >> >>> We aim to fix it from hardware perspetive for existing platforms if >>> possible >>> and ensure it is fixed in future platforms. >> >> I'm concerned that all of use end up repeatedly fixing similar issues >> whenever hardware configurations change or modules are reused in >> different topologies. >> >> For example, if future platforms may require ATID support for an >> interconnect TraceNoC, then the issue will pop up again. >> >> Thanks, >> Leo >

2 months, 1 week

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

by Leo Yan

Hi Jie, On Tue, Jun 30, 2026 at 09:03:52AM +0800, Jie Gan wrote: [...] > > - How can you guarantee that a interconnect TraceNoC will never > > require ATID in the future? > From a hardware perspective, there is no fundamental difference between an > itnoc and an AG TraceNoC. They use the same TraceNoC hardware implementation > and share the same AMBA bus type. The distinction is purely functional: an > itnoc is used for local trace aggregation within a subsystem, whereas an AG > TraceNoC serves as the top-level aggregation point for the SoC. I'm still not convinced that adding "arm,primecell-periphid" is the right approach. From the description above, I'd expect either the hardware to expose bits in a register to distinguish these two module types, or as I suggested earlier, to use a DT property to indicate the module type (or whether ATID is required). Or have you tried to detect the last tnoc on a path and allocate ID for it? (You can retrieve csdev->path). Thanks, Leo

2 months, 1 week

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

by Leo Yan

On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote: [...] > Can I fix the issue by adding "arm,primecell-periphid" property. That's > would be the best temp solution as it avoids breaking the original design of > both the TraceNoC AMBA driver and interconnect TraceNoC platform driver. Before proceeding with the "arm,primecell-periphid" property, could you clarify a bit: - For an interconnect TraceNoC, what would be the consequence of enabling ATID? Would it simply be a no-op, or are there any side effects? Or is the concern that the trace IDs could be exhausted? - How can you guarantee that a interconnect TraceNoC will never require ATID in the future? > The TraceNoC device here must be treated as an AMBA device and I am > continuing to investigate the issue with our hardware team. > We aim to fix it from hardware perspetive for existing platforms if possible > and ensure it is fixed in future platforms. I'm concerned that all of use end up repeatedly fixing similar issues whenever hardware configurations change or modules are reused in different topologies. For example, if future platforms may require ATID support for an interconnect TraceNoC, then the issue will pop up again. Thanks, Leo

2 months, 1 week

Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit

by Suzuki K Poulose

Hello, On 29/06/2026 11:17, Songwei.Chai wrote: > > On 6/29/2026 12:22 PM, Greg KH wrote: >> On Mon, Jun 29, 2026 at 11:03:33AM +0800, Songwei.Chai wrote: >>> Hi Greg & Alexander, >>> >>> Apologies for interrupting again. >>> >>> As the TGU hardware plays an important role in Qualcomm tracing >>> design, I >>> would greatly appreciate it if you could kindly take some time to review >>> this at your earliest convenience. >> The merge window _just_ closed, please give us a chance to catch up. >> >> Also, why us? Surely you have other reviewers for this code, right? > > Hi Greg, > > Understood, thanks for letting us know. > > Regarding your question: since this introduces a new drivers/hwtracing/ > qcom directory, there is no existing maintainer for it. > Given your scope (and Alexander's), we believe you are the most relevant > reviewers. > > The reason for creating the qcom directory is as follows: > > /We previously tried to upstream this driver under drivers/hwtracing/ > coresight,/ > /but it was not accepted as it is considered Qualcomm-specific and not > tightly/ > /coupled with the CoreSight subsystem. Based on this feedback, we are Some clarification here: This device is not CoreSight so we denied keeping this under drivers/hwtracing/coresight/ - Not because it is Qualcomm specific. We have TPDM, TPDA, TnoC devices under the coresight subsystem, which are all Qualcomm specific for e.g. That said, there are other drivers in drivers/hwtracing/ which I usually merge and push to Greg, after some reviews/acks from the respective people (e.g., PTT HiSilicon PCIe Tune and Trace). But, your proposal was that there were other maintainers for your new subtree and you were going to push this via ,linux-arm-msm ? to which I didn't have any objections. That said, I am fine with pushing this to Greg via the CoreSight pull requests (similar to Hisilicon PTT driver), but would need someone to Maintain/Review the driver (with entries in MAINTAINERS, similar to PTT). Thoughts ? Kind regards Suzuki > exploring/ > /a dedicated drivers/hwtracing/qcom directory, similar to intel_th, to > better/ > /support this and future Qualcomm hwtracing drivers./ > > More details can be found in “[PATCH v14 0/7] -- Why we are proposing > this”. > > Thanks, > Songwei > >> >> thanks, >> >> greg k-h

2 months, 1 week

← Newer
1
2
3
4
5
6
7
8
9
...
284
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight