CoreSight

coresight@lists.linaro.org

1 participants
2622 discussions

[PATCH v2 00/12] coresight: Add CPU cluster funnel/replicator/tmc support

by Yuanfang Zhang

This patch series adds support for CoreSight components local to CPU clusters, including funnel, replicator, and TMC, which reside within CPU cluster power domains. These components require special handling due to power domain constraints. Unlike system-level CoreSight devices, these components share the CPU cluster's power domain. When the cluster enters low-power mode (LPM), their registers become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster out of LPM, making standard register access unreliable. To address this, the series introduces: - Identifying cluster-bound devices via a new `qcom,cpu-bound-components` device tree property. - Implementing deferred probing: if associated CPUs are offline during probe, initialization is deferred until a CPU hotplug notifier detects the CPU coming online. - Utilizing `smp_call_function_single()` to ensure register accesses (initialization, enablement, sysfs reads) are always executed on a powered CPU within the target cluster. - Extending the CoreSight link `enable` callback to pass the `cs_mode`. This allows drivers to distinguish between SysFS and Perf modes and apply mode-specific logic. Jie Gan (1): arm64: dts: qcom: hamoa: add Coresight nodes for APSS debug block Yuanfang Zhang (11): dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property coresight: Pass trace mode to link enable callback coresight-funnel: Support CPU cluster funnel initialization coresight-funnel: Defer probe when associated CPUs are offline coresight-replicator: Support CPU cluster replicator initialization coresight-replicator: Defer probe when associated CPUs are offline coresight-replicator: Update management interface for CPU-bound devices coresight-tmc: Support probe and initialization for CPU cluster TMCs coresight-tmc-etf: Refactor enable function for CPU cluster ETF support coresight-tmc: Update management interface for CPU-bound TMCs coresight-tmc: Defer probe when associated CPUs are offline Verification: This series has been verified on sm8750. Test steps for delay probe: 1. limit the system to enable at most 6 CPU cores during boot. 2. echo 1 >/sys/bus/cpu/devices/cpu6/online. 3. check whether ETM6 and ETM7 have been probed. Test steps for sysfs mode: echo 1 >/sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 >/sys/bus/coresight/devices/etm0/enable_source echo 1 >/sys/bus/coresight/devices/etm6/enable_source echo 0 >/sys/bus/coresight/devices/etm0/enable_source echo 0 >/sys/bus/coresight/devicse/etm6/enable_source echo 0 >/sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 >/sys/bus/coresight/devices/tmc_etf1/enable_sink echo 1 >/sys/bus/coresight/devcies/etm0/enable_source cat /dev/tmc_etf1 >/tmp/etf1.bin echo 0 >/sys/bus/coresight/devices/etm0/enable_source echo 0 >/sys/bus/coresight/devices/tmc_etf1/enable_sink echo 1 >/sys/bus/coresight/devices/tmc_etf2/enable_sink echo 1 >/sys/bus/coresight/devices/etm6/enable_source cat /dev/tmc_etf2 >/tmp/etf2.bin echo 0 >/sys/bus/coresight/devices/etm6/enable_source echo 0 >/sys/bus/coresight/devices/tmc_etf2/enable_sink Test steps for sysfs node: cat /sys/bus/coresight/devices/tmc_etf*/mgmt/* cat /sys/bus/coresight/devices/funnel*/funnel_ctrl cat /sys/bus/coresight/devices/replicator*/mgmt/* Test steps for perf mode: perf record -a -e cs_etm//k -- sleep 5 Signed-off-by: Yuanfang Zhang <yuanfang.zhang(a)oss.qualcomm.com> --- Changes in v2: - Use the qcom,cpu-bound-components device tree property to identify devices bound to a cluster. - Refactor commit message. - Introduce a supported_cpus field in the drvdata structure to record the CPUs that belong to the cluster where the local component resides. - Link to v1: https://lore.kernel.org/r/20251027-cpu_cluster_component_pm-v1-0-31355ac588… --- Jie Gan (1): arm64: dts: qcom: hamoa: Add CoreSight nodes for APSS debug block Yuanfang Zhang (11): dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property coresight-funnel: Support CPU cluster funnel initialization coresight-funnel: Defer probe when associated CPUs are offline coresight-replicator: Support CPU cluster replicator initialization coresight-replicator: Defer probe when associated CPUs are offline coresight-replicator: Update management interface for CPU-bound devices coresight-tmc: Support probe and initialization for CPU cluster TMCs coresight-tmc-etf: Refactor enable function for CPU cluster ETF support coresight-tmc: Update management interface for CPU-bound TMCs coresight-tmc: Defer probe when associated CPUs are offline coresight: Pass trace mode to link enable callback .../bindings/arm/arm,coresight-dynamic-funnel.yaml | 5 + .../arm/arm,coresight-dynamic-replicator.yaml | 5 + .../devicetree/bindings/arm/arm,coresight-tmc.yaml | 5 + arch/arm64/boot/dts/qcom/hamoa.dtsi | 926 +++++++++++++++++++++ arch/arm64/boot/dts/qcom/purwa.dtsi | 12 + drivers/hwtracing/coresight/coresight-core.c | 7 +- drivers/hwtracing/coresight/coresight-funnel.c | 258 +++++- drivers/hwtracing/coresight/coresight-replicator.c | 341 +++++++- drivers/hwtracing/coresight/coresight-tmc-core.c | 387 +++++++-- drivers/hwtracing/coresight/coresight-tmc-etf.c | 106 ++- drivers/hwtracing/coresight/coresight-tmc.h | 10 + drivers/hwtracing/coresight/coresight-tnoc.c | 3 +- drivers/hwtracing/coresight/coresight-tpda.c | 3 +- include/linux/coresight.h | 3 +- 14 files changed, 1902 insertions(+), 169 deletions(-) --- base-commit: 008d3547aae5bc86fac3eda317489169c3fda112 change-id: 20251016-cpu_cluster_component_pm-ce518f510433 Best regards, -- Yuanfang Zhang <yuanfang.zhang(a)oss.qualcomm.com>

1 month, 2 weeks

Re: [PATCH v5 3/3] coresight: tpda: add sysfs node to flush specific port

by Suzuki K Poulose

On 19/12/2025 10:04, Jie Gan wrote: > From: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > > Setting bit i in the TPDA_FLUSH_CR register initiates a flush request > for port i, forcing the data to synchronize and be transmitted to the > sink device. > > Signed-off-by: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Co-developed-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > .../ABI/testing/sysfs-bus-coresight-devices-tpda | 7 ++++ > drivers/hwtracing/coresight/coresight-tpda.c | 49 ++++++++++++++++++++++ > drivers/hwtracing/coresight/coresight-tpda.h | 1 + > 3 files changed, 57 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > index a7855922328e..ef2804f87d1e 100644 > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > @@ -41,3 +41,10 @@ Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qu > Description: > (RW) Configure the CMB/MCMB channel mode for all enabled ports. > Value 0 means raw channel mapping mode. Value 1 means channel pair marking mode. > + > +What: /sys/bus/coresight/devices/<tpda-name>/port_flush_req > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Configure the bit i to requests a flush operation of port i on the TPDA. > diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c > index d378ff8ad77d..5b4a9e41b067 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.c > +++ b/drivers/hwtracing/coresight/coresight-tpda.c > @@ -375,6 +375,45 @@ static ssize_t tpda_trig_sysfs_store(struct device *dev, > return ret; > } > > +static ssize_t port_flush_req_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + unsigned long val; > + > + if (!drvdata->csdev->refcnt) > + return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + val = readl_relaxed(drvdata->base + TPDA_FLUSH_CR); > + > + return sysfs_emit(buf, "0x%lx\n", val); > +} > + > +static ssize_t port_flush_req_store(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t size) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + u32 val; > + > + if (kstrtou32(buf, 0, &val)) > + return -EINVAL; > + > + if (!drvdata->csdev->refcnt || !val) > + return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + CS_UNLOCK(drvdata->base); > + writel_relaxed(val, drvdata->base + TPDA_FLUSH_CR); > + CS_LOCK(drvdata->base); > + > + return size; > +} > +static DEVICE_ATTR_RW(port_flush_req); > + > static struct attribute *tpda_global_cr_attrs[] = { > tpda_trig_sysfs_rw(global_flush_req, FLREQ), > tpda_trig_sysfs_rw(freq_ts_enable, FREQTS), > @@ -385,13 +424,23 @@ static struct attribute *tpda_global_cr_attrs[] = { > NULL, > }; > > +static struct attribute *tpda_attrs[] = { > + &dev_attr_port_flush_req.attr, > + NULL, > +}; > + But why ? Why can't this be a part of the tpda_global_cr_attrs[] ? For that matter, why is tpda_global_cr_attrs named as such and why not tpda_attrs ? Suzuki > static struct attribute_group tpda_global_cr_attr_grp = { > .attrs = tpda_global_cr_attrs, > .name = "global_cr", > }; > > +static struct attribute_group tpda_attr_grp = { > + .attrs = tpda_attrs, > +}; > + > static const struct attribute_group *tpda_attr_grps[] = { > &tpda_global_cr_attr_grp, > + &tpda_attr_grp, > NULL, > }; > > diff --git a/drivers/hwtracing/coresight/coresight-tpda.h b/drivers/hwtracing/coresight/coresight-tpda.h > index 97e2729c15c9..ec93f9cb9648 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.h > +++ b/drivers/hwtracing/coresight/coresight-tpda.h > @@ -10,6 +10,7 @@ > #define TPDA_Pn_CR(n) (0x004 + (n * 4)) > #define TPDA_FPID_CR (0x084) > #define TPDA_SYNCR (0x08C) > +#define TPDA_FLUSH_CR (0x090) > > /* Cross trigger Global (all ports) flush request bit */ > #define TPDA_CR_FLREQ BIT(0) >

1 month, 2 weeks

Re: [PATCH v2 00/12] coresight: Add CPU cluster funnel/replicator/tmc support

by Suzuki K Poulose

On 19/12/2025 10:21, Sudeep Holla wrote: > On Fri, Dec 19, 2025 at 10:13:14AM +0800, yuanfang zhang wrote: >> >> >> On 12/18/2025 7:33 PM, Sudeep Holla wrote: >>> On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote: >>>> This patch series adds support for CoreSight components local to CPU clusters, >>>> including funnel, replicator, and TMC, which reside within CPU cluster power >>>> domains. These components require special handling due to power domain >>>> constraints. >>>> >>> >>> Could you clarify why PSCI-based power domains associated with clusters in >>> domain-idle-states cannot address these requirements, given that PSCI CPU-idle >>> OSI mode was originally intended to support them? My understanding of this >>> patch series is that OSI mode is unable to do so, which, if accurate, appears >>> to be a flaw that should be corrected. >> >> It is due to the particular characteristics of the CPU cluster power >> domain.Runtime PM for CPU devices works little different, it is mostly used >> to manage hierarchicalCPU topology (PSCI OSI mode) to talk with genpd >> framework to manage the last CPU handling in cluster. > > That is indeed the intended design. Could you clarify which specific > characteristics differentiate it here? > >> It doesn’t really send IPI to wakeup CPU device (It don’t have >> .power_on/.power_off) callback implemented which gets invoked from >> .runtime_resume callback. This behavior is aligned with the upstream Kernel. >> > > I am quite lost here. Why is it necessary to wake up the CPU? If I understand > correctly, all of this complexity is meant to ensure that the cluster power > domain is enabled before any of the funnel registers are accessed. Is that > correct? > > If so, and if the cluster domains are already defined as the power domains for > these funnel devices, then they should be requested to power on automatically > before any register access occurs. Is that not the case? > > What am I missing in this reasoning? Exactly, this is what I am too. But then you get the "pre-formated standard response" without answering our questions. Suzuki

1 month, 2 weeks

Re: [PATCH v5 2/3] coresight: tpda: add logic to configure TPDA_SYNCR register

by Suzuki K Poulose

On 19/12/2025 10:04, Jie Gan wrote: > From: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > > The TPDA_SYNC counter tracks the number of bytes transferred from the > aggregator. When this count reaches the value programmed in the > TPDA_SYNCR register, an ASYNC request is triggered, allowing userspace > tools to accurately parse each valid packet. > > Signed-off-by: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Co-developed-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > drivers/hwtracing/coresight/coresight-tpda.c | 7 +++++++ > drivers/hwtracing/coresight/coresight-tpda.h | 5 +++++ > 2 files changed, 12 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c > index d25a8bcfb3d4..d378ff8ad77d 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.c > +++ b/drivers/hwtracing/coresight/coresight-tpda.c > @@ -163,6 +163,13 @@ static void tpda_enable_pre_port(struct tpda_drvdata *drvdata) > */ > if (drvdata->trig_flag_ts) > writel_relaxed(0x0, drvdata->base + TPDA_FPID_CR); > + > + val = readl_relaxed(drvdata->base + TPDA_SYNCR); > + /* Reset the mode ctrl */ > + val &= ~TPDA_SYNCR_MODE_CTRL; > + /* Program the counter value for TPDA_SYNCR */ > + val |= TPDA_SYNCR_COUNTER_MASK; Do we plan to change this value via sysfs ? If not whats the point of clearing the field. Why not simply set it (as it is all 1s anyways). > + writel_relaxed(val, drvdata->base + TPDA_SYNCR); > } > > static int tpda_enable_port(struct tpda_drvdata *drvdata, int port) > diff --git a/drivers/hwtracing/coresight/coresight-tpda.h b/drivers/hwtracing/coresight/coresight-tpda.h > index 8a075cfbc3cc..97e2729c15c9 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.h > +++ b/drivers/hwtracing/coresight/coresight-tpda.h > @@ -9,6 +9,7 @@ > #define TPDA_CR (0x000) > #define TPDA_Pn_CR(n) (0x004 + (n * 4)) > #define TPDA_FPID_CR (0x084) > +#define TPDA_SYNCR (0x08C) > > /* Cross trigger Global (all ports) flush request bit */ > #define TPDA_CR_FLREQ BIT(0) > @@ -38,6 +39,10 @@ > #define TPDA_Pn_CR_CMBSIZE GENMASK(7, 6) > /* Aggregator port DSB data set element size bit */ > #define TPDA_Pn_CR_DSBSIZE BIT(8) Newline to separate the defintions of different registers, please. > +/* TPDA_SYNCR mode control bit */ > +#define TPDA_SYNCR_MODE_CTRL BIT(12) > +/* TPDA_SYNCR counter mask */ > +#define TPDA_SYNCR_COUNTER_MASK GENMASK(11, 0) > > #define TPDA_MAX_INPORTS 32 > Suzuki >

1 month, 2 weeks

Re: [PATCH v5 1/3] coresight: tpda: add sysfs nodes for tpda cross-trigger configuration

by Suzuki K Poulose

On 19/12/2025 10:04, Jie Gan wrote: > From: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > > Introduce sysfs nodes to configure cross-trigger parameters for TPDA. > These registers define the characteristics of cross-trigger packets, > including generation frequency and flag values. > > Signed-off-by: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Co-developed-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > .../ABI/testing/sysfs-bus-coresight-devices-tpda | 43 +++++++ > drivers/hwtracing/coresight/coresight-tpda.c | 138 ++++++++++++++++++++- > drivers/hwtracing/coresight/coresight-tpda.h | 69 ++++++++++- > 3 files changed, 243 insertions(+), 7 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > new file mode 100644 > index 000000000000..a7855922328e > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > @@ -0,0 +1,43 @@ > +What: /sys/bus/coresight/devices/<tpda-name>/global_cr/trig_async_enable > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable cross trigger synchronization sequence interface. > + > +What: /sys/bus/coresight/devices/<tpda-name>/global_cr/trig_flag_ts_enable > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable cross trigger FLAG packet request interface. > + > +What: /sys/bus/coresight/devices/<tpda-name>/global_cr/trig_freq_enable > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable cross trigger FREQ packet request interface. > + > +What: /sys/bus/coresight/devices/<tpda-name>/global_cr/freq_ts_enable > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable the timestamp for all FREQ packets. > + > +What: /sys/bus/coresight/devices/<tpda-name>/global_cr/global_flush_req > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Set global (all ports) flush request bit. The bit remains set until a > + global flush request sequence completes. > + > +What: /sys/bus/coresight/devices/<tpda-name>/global_cr/cmbchan_mode > +Date: December 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Configure the CMB/MCMB channel mode for all enabled ports. > + Value 0 means raw channel mapping mode. Value 1 means channel pair marking mode. > diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c > index 3a3825d27f86..d25a8bcfb3d4 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.c > +++ b/drivers/hwtracing/coresight/coresight-tpda.c > @@ -137,12 +137,32 @@ static int tpda_get_element_size(struct tpda_drvdata *drvdata, > /* Settings pre enabling port control register */ > static void tpda_enable_pre_port(struct tpda_drvdata *drvdata) > { > - u32 val; > + u32 val = 0; > > - val = readl_relaxed(drvdata->base + TPDA_CR); > - val &= ~TPDA_CR_ATID; > val |= FIELD_PREP(TPDA_CR_ATID, drvdata->atid); > + if (drvdata->trig_async) > + val |= TPDA_CR_SRIE; > + > + if (drvdata->trig_flag_ts) > + val |= TPDA_CR_FLRIE; > + > + if (drvdata->trig_freq) > + val |= TPDA_CR_FRIE; > + > + if (drvdata->freq_ts) > + val |= TPDA_CR_FREQTS; > + > + if (drvdata->cmbchan_mode) > + val |= TPDA_CR_CMBCHANMODE; > + > writel_relaxed(val, drvdata->base + TPDA_CR); > + > + /* > + * If FLRIE bit is set, set the master and channel > + * id as zero > + */ > + if (drvdata->trig_flag_ts) > + writel_relaxed(0x0, drvdata->base + TPDA_FPID_CR); > } > > static int tpda_enable_port(struct tpda_drvdata *drvdata, int port) > @@ -258,6 +278,116 @@ static const struct coresight_ops tpda_cs_ops = { > .link_ops = &tpda_link_ops, > }; > > +/* Read cross-trigger register member */ > +static ssize_t tpda_trig_sysfs_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct tpda_trig_sysfs_attribute *tpda_attr = > + container_of(attr, struct tpda_trig_sysfs_attribute, attr); > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + unsigned long val; > + > + guard(spinlock)(&drvdata->spinlock); > + switch (tpda_attr->mem) { > + case FLREQ: > + if (!drvdata->csdev->refcnt) > + return -EINVAL; > + > + val = readl_relaxed(drvdata->base + TPDA_CR); > + /* read global flush request bit only */ > + val &= TPDA_CR_FLREQ; > + return sysfs_emit(buf, "%lu\n", val); > + case FREQTS: > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->freq_ts); > + case FRIE: > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->trig_freq); > + case FLRIE: > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->trig_flag_ts); > + case SRIE: > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->trig_async); > + case CMBCHANMODE: > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->cmbchan_mode); > + > + } > + return -EINVAL; > +} > + > +static ssize_t tpda_trig_sysfs_store(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t size) > +{ > + struct tpda_trig_sysfs_attribute *tpda_attr = > + container_of(attr, struct tpda_trig_sysfs_attribute, attr); > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + ssize_t ret = -EINVAL; + unsigned long val; > + > + if (kstrtoul(buf, 0, &val)) > + return ret; return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + switch (tpda_attr->mem) { > + case FLREQ: > + if (!drvdata->csdev->refcnt || !val) > + return ret; return -EINVAL; > + > + val = readl_relaxed(drvdata->base + TPDA_CR); CS_UNLOCK before readl ? I didn't mean the global_flush_req to be unified with the rest. Obviously it has different access semantics. > + /* set global flush request bit */ > + val |= TPDA_CR_FLREQ; > + CS_UNLOCK(drvdata->base); > + writel_relaxed(val, drvdata->base + TPDA_CR); > + CS_LOCK(drvdata->base); > + ret = size; Please remove this from all the cases and explicitly return -EINVAL in the error cases. > + break; > + case FREQTS: > + drvdata->freq_ts = !!val; > + ret = size; > + break; > + case FRIE: > + drvdata->trig_freq = !!val; > + ret = size; > + break; > + case FLRIE: > + drvdata->trig_flag_ts = !!val; > + ret = size; > + break; > + case SRIE: > + drvdata->trig_async = !!val; > + ret = size; > + break; > + case CMBCHANMODE: > + drvdata->cmbchan_mode = !!val; > + ret = size; > + break; > + default: return -EINVAL; > + break; > + } > + > + return ret; return size; > +} > + > +static struct attribute *tpda_global_cr_attrs[] = { > + tpda_trig_sysfs_rw(global_flush_req, FLREQ), > + tpda_trig_sysfs_rw(freq_ts_enable, FREQTS), > + tpda_trig_sysfs_rw(trig_freq_enable, FRIE), > + tpda_trig_sysfs_rw(trig_flag_ts_enable, FLRIE), > + tpda_trig_sysfs_rw(trig_async_enable, SRIE), > + tpda_trig_sysfs_rw(cmbchan_mode, CMBCHANMODE), > + NULL, > +}; > + > +static struct attribute_group tpda_global_cr_attr_grp = { > + .attrs = tpda_global_cr_attrs, > + .name = "global_cr", > +}; > + > +static const struct attribute_group *tpda_attr_grps[] = { > + &tpda_global_cr_attr_grp, > + NULL, > +}; > + > static int tpda_init_default_data(struct tpda_drvdata *drvdata) > { > int atid; > @@ -273,6 +403,7 @@ static int tpda_init_default_data(struct tpda_drvdata *drvdata) > return atid; > > drvdata->atid = atid; > + drvdata->freq_ts = true; > return 0; > } > > @@ -316,6 +447,7 @@ static int tpda_probe(struct amba_device *adev, const struct amba_id *id) > desc.ops = &tpda_cs_ops; > desc.pdata = adev->dev.platform_data; > desc.dev = &adev->dev; > + desc.groups = tpda_attr_grps; > desc.access = CSDEV_ACCESS_IOMEM(base); > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) > diff --git a/drivers/hwtracing/coresight/coresight-tpda.h b/drivers/hwtracing/coresight/coresight-tpda.h > index c6af3d2da3ef..8a075cfbc3cc 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.h > +++ b/drivers/hwtracing/coresight/coresight-tpda.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + * Copyright (c) 2023,2025 Qualcomm Innovation Center, Inc. All rights reserved. > */ > > #ifndef _CORESIGHT_CORESIGHT_TPDA_H > @@ -8,6 +8,30 @@ > > #define TPDA_CR (0x000) > #define TPDA_Pn_CR(n) (0x004 + (n * 4)) > +#define TPDA_FPID_CR (0x084) > + > +/* Cross trigger Global (all ports) flush request bit */ > +#define TPDA_CR_FLREQ BIT(0) > +/* Cross trigger FREQ packets timestamp bit */ > +#define TPDA_CR_FREQTS BIT(2) > +/* Cross trigger FREQ packet request bit */ > +#define TPDA_CR_FRIE BIT(3) > +/* Cross trigger FLAG packet request interface bit */ > +#define TPDA_CR_FLRIE BIT(4) > +/* Cross trigger synchronization bit */ > +#define TPDA_CR_SRIE BIT(5) > +/* Bits 6 ~ 12 is for atid value */ > +#define TPDA_CR_ATID GENMASK(12, 6) > +/* Bits 13 ~ 19 is for mid value */ > +/* Assign a unique master ID to identify the TPDA device */ > +#define TPDA_CR_MID GENMASK(19, 13) Where do we use this ? Does this need to be preserved ? Is this programmable ? Suzuki > +/* > + * Channel mode bit of the packetization of CMB/MCB traffic > + * 0 - raw channel mapping mode > + * 1 - channel pair marking mode > + */ > +#define TPDA_CR_CMBCHANMODE BIT(20) > + > /* Aggregator port enable bit */ > #define TPDA_Pn_CR_ENA BIT(0) > /* Aggregator port CMB data set element size bit */ > @@ -17,9 +41,6 @@ > > #define TPDA_MAX_INPORTS 32 > > -/* Bits 6 ~ 12 is for atid value */ > -#define TPDA_CR_ATID GENMASK(12, 6) > - > /** > * struct tpda_drvdata - specifics associated to an TPDA component > * @base: memory mapped base address for this component. > @@ -29,6 +50,11 @@ > * @enable: enable status of the component. > * @dsb_esize Record the DSB element size. > * @cmb_esize Record the CMB element size. > + * @trig_async: Enable/disable cross trigger synchronization sequence interface. > + * @trig_flag_ts: Enable/disable cross trigger FLAG packet request interface. > + * @trig_freq: Enable/disable cross trigger FREQ packet request interface. > + * @freq_ts: Enable/disable the timestamp for all FREQ packets. > + * @cmbchan_mode: Configure the CMB/MCMB channel mode. > */ > struct tpda_drvdata { > void __iomem *base; > @@ -38,6 +64,41 @@ struct tpda_drvdata { > u8 atid; > u32 dsb_esize; > u32 cmb_esize; > + bool trig_async; > + bool trig_flag_ts; > + bool trig_freq; > + bool freq_ts; > + bool cmbchan_mode; > +}; > + > +/* Enumerate members of global control register(cr) */ > +enum tpda_cr_mem { > + FLREQ, > + FREQTS, > + FRIE, > + FLRIE, > + SRIE, > + CMBCHANMODE > +}; > + > +/** > + * struct tpda_trig_sysfs_attribute - Record the member variables of cross > + * trigger register that need to be operated by sysfs file > + * @attr: The device attribute > + * @mem: The member in the control register data structure > + */ > +struct tpda_trig_sysfs_attribute { > + struct device_attribute attr; > + enum tpda_cr_mem mem; > }; > > +#define tpda_trig_sysfs_rw(name, mem) \ > + (&((struct tpda_trig_sysfs_attribute[]) { \ > + { \ > + __ATTR(name, 0644, tpda_trig_sysfs_show, \ > + tpda_trig_sysfs_store), \ > + mem, \ > + } \ > + })[0].attr.attr) > + > #endif /* _CORESIGHT_CORESIGHT_TPDA_H */ >

1 month, 2 weeks

Re: [PATCH v8 5/8] dt-bindings: arm: add an interrupt property for Coresight CTCU

by Suzuki K Poulose

On 19/12/2025 02:05, Jie Gan wrote: > > > On 12/19/2025 7:19 AM, Suzuki K Poulose wrote: >> On 18/12/2025 10:17, Krzysztof Kozlowski wrote: >>> On 12/12/2025 02:12, Jie Gan wrote: >>>> >>>> >>>> On 12/11/2025 9:37 PM, Rob Herring wrote: >>>>> On Thu, Dec 11, 2025 at 02:10:44PM +0800, Jie Gan wrote: >>>>>> Add an interrupt property to CTCU device. The interrupt will be >>>>>> triggered >>>>>> when the data size in the ETR buffer exceeds the threshold of the >>>>>> BYTECNTRVAL register. Programming a threshold in the BYTECNTRVAL >>>>>> register >>>>>> of CTCU device will enable the interrupt. >>>>>> >>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> >>>>>> Reviewed-by: Mike Leach <mike.leach(a)linaro.org> >>>>>> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> >>>>>> --- >>>>>> .../devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 17 ++ >>>>>> + ++++++++++++++ >>>>>> 1 file changed, 17 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight- >>>>>> ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight- >>>>>> ctcu.yaml >>>>>> index c969c16c21ef..90f88cc6cd3e 100644 >>>>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>> @@ -39,6 +39,16 @@ properties: >>>>>> items: >>>>>> - const: apb >>>>>> + interrupts: >>>>>> + items: >>>>>> + - description: Byte cntr interrupt for the first etr device >>>>>> + - description: Byte cntr interrupt for the second etr device >> >> This is really vague. How do you define first vs second ? Probe order ? >> No way. This must be the "port" number to which the ETR is connected >> to the CTCU. IIUC, there is a config area for each ETR (e.g., trace id >> filter) connected to the CTCU. I was under the assumption that they >> are identified as "ports" (input ports). I don't really understand how >> this interrupt mapping works now. Please explain it clearly. >> > > Sorry for the misunderstanding. > > Each ETR device should have its own interrupt line and an IRQ register > within the CTCU device, as defined by the specification. In existing > projects, the maximum supported number of ETR devices is 2. > > Each interrupt is directly mapped to a specific ETR device, for example: > tmc@1000 → interrupt line 0 > tmc@1001 → interrupt line 1 > > The suggestion to identify devices by ‘ports’ is much clearer than my > previous explanation, as it explicitly shows which device is connected > to which port. Thanks for confirming. > >>>>>> + >>>>>> + interrupt-names: >>>>>> + items: >>>>>> + - const: etrirq0 >>>>>> + - const: etrirq1 >>>>> >>>>> Names are kind of pointless when it is just foo<index>. >>>> >>>> Hi Rob, >>>> >>>> I was naming them as etr0/etr1. Are these names acceptable? >>> >>> Obviously irq is redundant, but how does etr0 solves the problem of >>> calling it foo0? >>> >>> I don't think you really read Rob's comment. >>> >>>> The interrupts are assigned exclusively to a specific ETR device. >>>> >>>> But Suzuki is concerned that this might cause confusion because the ETR >>>> device is named randomly in the driver. Suzuki suggested using ‘port-0’ >>>> and ‘port-1’ and would also like to hear your feedback on these names. >>> >>> There is no confusion here. Writing bindings luckily clarifies this what >>> the indices in the array mean. >> >> The point is there are "n" interrupts. Question is, could there be more >> devices(ETRs) connected to the CTCU than "n". >> >> e.g., Lets CTCU can control upto 4 ETRs and on a particular system, the >> >> TMC-ETR0 -> CTCU-Port0 >> >> TMC-ETR1 -> CTCU-Port2 >> TMC-ETR2 -> CTCU-Port3 >> >> Now, how many interrupts are described in the DT ? How do we map which >> interrupts correspond to the CTCU-Portn. (Finding the TMC-ETRx back >> from the port is possible, with the topology). >> > > Got your point and it's much clearer. > >> This is what I raised in the previous version. Again, happy to hear >> if there is a standard way to describe the interrupts. >> >> Suzuki >> >> >>> >>>> >>>> Usually, the probe sequence follows the order of the addresses. In our >>>> specification, ‘ETR0’ is always probed before ‘ETR1’ because its >>>> address >>>> is lower. >>> >>> How is this even relevant? You are answering to something completely >>> different, so I don't think you really tried to understand review. >>> > > My previous explanation was definitely unclear. As Suzuki suggested, > mapping the interrupt to the port number (to identify the relevant > device based on topology) makes sense and provides a much easier way to > understand the relationship between the interrupt and the ETR device. > > So with the suggestion, here is the new description about the interrupts: > > interrupts: > items: > - description: Interrupt for the ETR device connected to in-port0. > - description: Interrupt for the ETR device connected to in-port1. > > interrupt-names: > items: > - const: port0 > - const: port1 Which brings us back to the question I posted in the previous version. Do we really need a "name" or are there other ways to define, a sparse list of interrupts ? Suzuki > > Thanks, > Jie > >>> >>> >>> Best regards, >>> Krzysztof >> >

1 month, 2 weeks

Re: [PATCH v2 00/12] coresight: Add CPU cluster funnel/replicator/tmc support

by yuanfang zhang

On 12/18/2025 7:33 PM, Sudeep Holla wrote: > On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote: >> This patch series adds support for CoreSight components local to CPU clusters, >> including funnel, replicator, and TMC, which reside within CPU cluster power >> domains. These components require special handling due to power domain >> constraints. >> > > Could you clarify why PSCI-based power domains associated with clusters in > domain-idle-states cannot address these requirements, given that PSCI CPU-idle > OSI mode was originally intended to support them? My understanding of this > patch series is that OSI mode is unable to do so, which, if accurate, appears > to be a flaw that should be corrected. It is due to the particular characteristics of the CPU cluster power domain.Runtime PM for CPU devices works little different, it is mostly used to manage hierarchical CPU topology (PSCI OSI mode) to talk with genpd framework to manage the last CPU handling in cluster. It doesn’t really send IPI to wakeup CPU device (It don’t have .power_on/.power_off) callback implemented which gets invoked from .runtime_resume callback. This behavior is aligned with the upstream Kernel. > >> Unlike system-level CoreSight devices, these components share the CPU cluster's >> power domain. When the cluster enters low-power mode (LPM), their registers >> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster >> out of LPM, making standard register access unreliable. >> > > Are these devices the only ones on the system that are uniquely bound to > cluster-level power domains? If not, what additional devices share this > dependency so that we can understand how they are managed in comparison? > Yes, devices like ETM and TRBE also share this power domain and access constraint. Their drivers naturally handle enablement/disablement on the specific CPU they belong to (e.g., via hotplug callbacks or existing smp_call_function paths). >> To address this, the series introduces: >> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components` >> device tree property. > > Really, no please. > Our objective is to determine which CoreSight components are physically locate within the CPU cluster power domain. Would it be acceptable to derive this relationship from the existing power-domains binding? For example, if a Funnel or Replicator node is linked to a power-domains entry that specifies a cpumask, the driver could recognize this shared dependency and automatically apply the appropriate cluster-aware behavior. thanks, yuanfang.

1 month, 2 weeks

Re: [PATCH v8 5/8] dt-bindings: arm: add an interrupt property for Coresight CTCU

by Suzuki K Poulose

On 18/12/2025 10:17, Krzysztof Kozlowski wrote: > On 12/12/2025 02:12, Jie Gan wrote: >> >> >> On 12/11/2025 9:37 PM, Rob Herring wrote: >>> On Thu, Dec 11, 2025 at 02:10:44PM +0800, Jie Gan wrote: >>>> Add an interrupt property to CTCU device. The interrupt will be triggered >>>> when the data size in the ETR buffer exceeds the threshold of the >>>> BYTECNTRVAL register. Programming a threshold in the BYTECNTRVAL register >>>> of CTCU device will enable the interrupt. >>>> >>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> >>>> Reviewed-by: Mike Leach <mike.leach(a)linaro.org> >>>> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> >>>> --- >>>> .../devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 17 +++++++++++++++++ >>>> 1 file changed, 17 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>> index c969c16c21ef..90f88cc6cd3e 100644 >>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>> @@ -39,6 +39,16 @@ properties: >>>> items: >>>> - const: apb >>>> >>>> + interrupts: >>>> + items: >>>> + - description: Byte cntr interrupt for the first etr device >>>> + - description: Byte cntr interrupt for the second etr device This is really vague. How do you define first vs second ? Probe order ? No way. This must be the "port" number to which the ETR is connected to the CTCU. IIUC, there is a config area for each ETR (e.g., trace id filter) connected to the CTCU. I was under the assumption that they are identified as "ports" (input ports). I don't really understand how this interrupt mapping works now. Please explain it clearly. >>>> + >>>> + interrupt-names: >>>> + items: >>>> + - const: etrirq0 >>>> + - const: etrirq1 >>> >>> Names are kind of pointless when it is just foo<index>. >> >> Hi Rob, >> >> I was naming them as etr0/etr1. Are these names acceptable? > > Obviously irq is redundant, but how does etr0 solves the problem of > calling it foo0? > > I don't think you really read Rob's comment. > >> The interrupts are assigned exclusively to a specific ETR device. >> >> But Suzuki is concerned that this might cause confusion because the ETR >> device is named randomly in the driver. Suzuki suggested using ‘port-0’ >> and ‘port-1’ and would also like to hear your feedback on these names. > > There is no confusion here. Writing bindings luckily clarifies this what > the indices in the array mean. The point is there are "n" interrupts. Question is, could there be more devices(ETRs) connected to the CTCU than "n". e.g., Lets CTCU can control upto 4 ETRs and on a particular system, the TMC-ETR0 -> CTCU-Port0 TMC-ETR1 -> CTCU-Port2 TMC-ETR2 -> CTCU-Port3 Now, how many interrupts are described in the DT ? How do we map which interrupts correspond to the CTCU-Portn. (Finding the TMC-ETRx back from the port is possible, with the topology). This is what I raised in the previous version. Again, happy to hear if there is a standard way to describe the interrupts. Suzuki > >> >> Usually, the probe sequence follows the order of the addresses. In our >> specification, ‘ETR0’ is always probed before ‘ETR1’ because its address >> is lower. > > How is this even relevant? You are answering to something completely > different, so I don't think you really tried to understand review. > > > > Best regards, > Krzysztof

1 month, 2 weeks

Re: [PATCH v8 2/8] coresight: core: add a new API to retrieve the helper device

by Suzuki K Poulose

On 11/12/2025 06:10, Jie Gan wrote: > Retrieving the helper device of the specific coresight device based on > its helper_subtype because a single coresight device may has multiple types > of the helper devices. > > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > drivers/hwtracing/coresight/coresight-core.c | 35 ++++++++++++++++++++++++++++ > drivers/hwtracing/coresight/coresight-priv.h | 2 ++ > 2 files changed, 37 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index 0e8448784c62..667883ccb4b7 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -585,6 +585,41 @@ struct coresight_device *coresight_get_sink(struct coresight_path *path) > } > EXPORT_SYMBOL_GPL(coresight_get_sink); > > +/** > + * coresight_get_helper: find the helper device of the assigned csdev. > + * > + * @csdev: The csdev the helper device is conntected to. > + * @type: helper_subtype of the expected helper device. > + * > + * Retrieve the helper device for the specific csdev based on its > + * helper_subtype. > + * > + * Return: the helper's csdev upon success or NULL for fail. > + */ > +struct coresight_device *coresight_get_helper(struct coresight_device *csdev, > + enum coresight_dev_subtype_helper subtype) We have almost a similar function in coresight-core.c : coresight_find_output_type(pdata, type, subtype). Please could we reuse that, instead of adding similar funcitons ? Please be careful about the mutex. Suzuki > +{ > + int i; > + struct coresight_device *helper; > + > + /* protect the connections */ > + mutex_lock(&coresight_mutex); > + for (i = 0; i < csdev->pdata->nr_outconns; ++i) { > + helper = csdev->pdata->out_conns[i]->dest_dev; > + if (!helper || !coresight_is_helper(helper)) > + continue; > + > + if (helper->subtype.helper_subtype == subtype) { > + mutex_unlock(&coresight_mutex); > + return helper; > + } > + } > + mutex_unlock(&coresight_mutex); > + > + return NULL; > +} > +EXPORT_SYMBOL_GPL(coresight_get_helper); > + > /** > * coresight_get_in_port: Find the input port number at @csdev where a @remote > * device is connected to. > diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h > index cbf80b83e5ce..8e39a4dc7256 100644 > --- a/drivers/hwtracing/coresight/coresight-priv.h > +++ b/drivers/hwtracing/coresight/coresight-priv.h > @@ -157,6 +157,8 @@ void coresight_path_assign_trace_id(struct coresight_path *path, > enum cs_mode mode); > int coresight_get_in_port(struct coresight_device *csdev, > struct coresight_device *remote); > +struct coresight_device *coresight_get_helper(struct coresight_device *csdev, > + enum coresight_dev_subtype_helper subtype); > > #if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X) > int etm_readl_cp14(u32 off, unsigned int *val); >

1 month, 2 weeks

Re: [PATCH v4 1/3] coresight: tpda: add sysfs nodes for tpda cross-trigger configuration

by Suzuki K Poulose

On 28/10/2025 02:02, Jie Gan wrote: > From: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > > Introduce sysfs nodes to configure cross-trigger parameters for TPDA. > These registers define the characteristics of cross-trigger packets, > including generation frequency and flag values. > > Signed-off-by: Tao Zhang <tao.zhang(a)oss.qualcomm.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Co-developed-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > .../ABI/testing/sysfs-bus-coresight-devices-tpda | 43 ++++ > drivers/hwtracing/coresight/coresight-tpda.c | 230 +++++++++++++++++++++ > drivers/hwtracing/coresight/coresight-tpda.h | 27 ++- > 3 files changed, 299 insertions(+), 1 deletion(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > new file mode 100644 > index 000000000000..80e4b05a1ab4 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpda > @@ -0,0 +1,43 @@ > +What: /sys/bus/coresight/devices/<tpda-name>/trig_async_enable > +Date: October 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable cross trigger synchronization sequence interface. > + > +What: /sys/bus/coresight/devices/<tpda-name>/trig_flag_ts_enable > +Date: October 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable cross trigger FLAG packet request interface. > + > +What: /sys/bus/coresight/devices/<tpda-name>/trig_freq_enable > +Date: October 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable cross trigger FREQ packet request interface. > + > +What: /sys/bus/coresight/devices/<tpda-name>/freq_ts_enable > +Date: October 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Enable/disable the timestamp for all FREQ packets. > + > +What: /sys/bus/coresight/devices/<tpda-name>/global_flush_req > +Date: October 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Set global (all ports) flush request bit. The bit remains set until a > + global flush request sequence completes. > + > +What: /sys/bus/coresight/devices/<tpda-name>/cmbchan_mode > +Date: October 2025 > +KernelVersion: 6.19 > +Contact: Jinlong Mao <jinlong.mao(a)oss.qualcomm.com>, Tao Zhang <tao.zhang(a)oss.qualcomm.com>, Jie Gan <jie.gan(a)oss.qualcomm.com> > +Description: > + (RW) Configure the CMB/MCMB channel mode for all enabled ports. > + Value 0 means raw channel mapping mode. Value 1 means channel pair marking mode. > diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c > index 333b3cb23685..a9a27bcc65a1 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.c > +++ b/drivers/hwtracing/coresight/coresight-tpda.c > @@ -147,9 +147,37 @@ static void tpda_enable_pre_port(struct tpda_drvdata *drvdata) > u32 val; > > val = readl_relaxed(drvdata->base + TPDA_CR); > + val &= ~TPDA_CR_MID; > val &= ~TPDA_CR_ATID; See, below. > val |= FIELD_PREP(TPDA_CR_ATID, drvdata->atid); > + if (drvdata->trig_async) > + val |= TPDA_CR_SRIE; > + else > + val &= ~TPDA_CR_SRIE; > + if (drvdata->trig_flag_ts) > + val |= TPDA_CR_FLRIE; > + else > + val &= ~TPDA_CR_FLRIE; > + if (drvdata->trig_freq) > + val |= TPDA_CR_FRIE; > + else > + val &= ~TPDA_CR_FRIE; > + if (drvdata->freq_ts) > + val |= TPDA_CR_FREQTS; > + else > + val &= ~TPDA_CR_FREQTS; > + if (drvdata->cmbchan_mode) > + val |= TPDA_CR_CMBCHANMODE; > + else > + val &= ~TPDA_CR_CMBCHANMODE; Could we clear all of the bits that are configurable in one go in the beginning and set the appropriate ones based on the setting ? i.e.: Do we really need to retain any values ? And if not, why not start with a fresh set of values and avoid the read ? > writel_relaxed(val, drvdata->base + TPDA_CR); > + > + /* > + * If FLRIE bit is set, set the master and channel > + * id as zero > + */ > + if (drvdata->trig_flag_ts) > + writel_relaxed(0x0, drvdata->base + TPDA_FPID_CR); > } > > static int tpda_enable_port(struct tpda_drvdata *drvdata, int port) > @@ -265,6 +293,206 @@ static const struct coresight_ops tpda_cs_ops = { > .link_ops = &tpda_link_ops, > }; > > +static ssize_t trig_async_enable_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->trig_async); > +} > + > +static ssize_t trig_async_enable_store(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t size) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + unsigned long val; > + > + if (kstrtoul(buf, 0, &val)) > + return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + drvdata->trig_async = !!val; > + > + return size; > +} > +static DEVICE_ATTR_RW(trig_async_enable); ... > +static DEVICE_ATTR_RW(trig_flag_ts_enable); ... > +static DEVICE_ATTR_RW(trig_freq_enable); ... > +static DEVICE_ATTR_RW(freq_ts_enable); These attribute are boolean and looks like we could save some space on code by using dev_ext_attribute. see tpdm_simple_dataset_rw()/tpdm_simple_dataset_ro() . You could #define TPDA_TRIG_ASYNC 0 #define TPDA_TRIG_FLAG_TS 1 #define TPDA_TRIG_FREQ 2 tpda_trig_sysfs_show/store() bool *ptr; switch (eattr->var) { case TPDA_TRIG_ASYNC: ptr = &drvdata->trig_async; break; case TPDA_TRIG_FLAG_TS: ptr = &drvdata->trig_flag_ts; break; ... } > + > +static ssize_t global_flush_req_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + unsigned long val; > + > + if (!drvdata->csdev->refcnt) > + return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + CS_UNLOCK(drvdata->base); > + val = readl_relaxed(drvdata->base + TPDA_CR); > + CS_LOCK(drvdata->base); > + /* Only read value for bit 0 */ > + val &= BIT(0); > + > + return sysfs_emit(buf, "%lu\n", val); > +} > + > +static ssize_t global_flush_req_store(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t size) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + unsigned long val; > + > + if (kstrtoul(buf, 0, &val)) > + return -EINVAL; > + > + if (!drvdata->csdev->refcnt || !val) > + return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + CS_UNLOCK(drvdata->base); > + val = readl_relaxed(drvdata->base + TPDA_CR); > + /* Only set bit 0 */ > + val |= BIT(0); What is BIT 0 ? Please document it > + writel_relaxed(val, drvdata->base + TPDA_CR); > + CS_LOCK(drvdata->base); > + > + return size; > +} > +static DEVICE_ATTR_RW(global_flush_req); > + > +static ssize_t cmbchan_mode_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + > + return sysfs_emit(buf, "%u\n", (unsigned int)drvdata->cmbchan_mode); > +} > + > +static ssize_t cmbchan_mode_store(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t size) > +{ > + struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent); > + unsigned long val; > + > + if (kstrtoul(buf, 0, &val)) > + return -EINVAL; > + > + guard(spinlock)(&drvdata->spinlock); > + drvdata->cmbchan_mode = !!val; > + > + return size; > +} > +static DEVICE_ATTR_RW(cmbchan_mode); Even this could go to the dev_ext_attribute magic and reuse a single show/store. > + > +static struct attribute *tpda_attrs[] = { > + &dev_attr_trig_async_enable.attr, > + &dev_attr_trig_flag_ts_enable.attr, > + &dev_attr_trig_freq_enable.attr, > + &dev_attr_freq_ts_enable.attr, > + &dev_attr_global_flush_req.attr, > + &dev_attr_cmbchan_mode.attr, > + NULL, > +}; > diff --git a/drivers/hwtracing/coresight/coresight-tpda.h b/drivers/hwtracing/coresight/coresight-tpda.h > index c6af3d2da3ef..0be625fb52fd 100644 > --- a/drivers/hwtracing/coresight/coresight-tpda.h > +++ b/drivers/hwtracing/coresight/coresight-tpda.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + * Copyright (c) 2023,2025 Qualcomm Innovation Center, Inc. All rights reserved. > */ > > #ifndef _CORESIGHT_CORESIGHT_TPDA_H > @@ -8,6 +8,19 @@ > > #define TPDA_CR (0x000) > #define TPDA_Pn_CR(n) (0x004 + (n * 4)) > +#define TPDA_FPID_CR (0x084) > + > +/* Cross trigger FREQ packets timestamp bit */ > +#define TPDA_CR_FREQTS BIT(2) > +/* Cross trigger FREQ packet request bit */ > +#define TPDA_CR_FRIE BIT(3) > +/* Cross trigger FLAG packet request interface bit */ > +#define TPDA_CR_FLRIE BIT(4) > +/* Cross trigger synchronization bit */ > +#define TPDA_CR_SRIE BIT(5) > +/* Packetize CMB/MCMB traffic bit */ > +#define TPDA_CR_CMBCHANMODE BIT(20) > + Why are these not clubbed with the other TPDA_CR_ defintions ? > /* Aggregator port enable bit */ > #define TPDA_Pn_CR_ENA BIT(0) > /* Aggregator port CMB data set element size bit */ > @@ -19,6 +32,8 @@ > > /* Bits 6 ~ 12 is for atid value */ > #define TPDA_CR_ATID GENMASK(12, 6) > +/* Bits 13 ~ 19 is for mid value */ > +#define TPDA_CR_MID GENMASK(19, 13) > > /** > * struct tpda_drvdata - specifics associated to an TPDA component > @@ -29,6 +44,11 @@ > * @enable: enable status of the component. > * @dsb_esize Record the DSB element size. > * @cmb_esize Record the CMB element size. > + * @trig_async: Enable/disable cross trigger synchronization sequence interface. > + * @trig_flag_ts: Enable/disable cross trigger FLAG packet request interface. > + * @trig_freq: Enable/disable cross trigger FREQ packet request interface. > + * @freq_ts: Enable/disable the timestamp for all FREQ packets. > + * @cmbchan_mode: Configure the CMB/MCMB channel mode. > */ > struct tpda_drvdata { > void __iomem *base; > @@ -38,6 +58,11 @@ struct tpda_drvdata { > u8 atid; > u32 dsb_esize; > u32 cmb_esize; > + bool trig_async; > + bool trig_flag_ts; > + bool trig_freq; > + bool freq_ts; > + bool cmbchan_mode; > }; > > #endif /* _CORESIGHT_CORESIGHT_TPDA_H */ Suzuki

1 month, 2 weeks

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight