CoreSight

coresight@lists.linaro.org

7 participants
2438 discussions

[PATCH] coresight-tmc: Add configurable timeout for flush and tmcready

by Yuanfang Zhang

The current implementation uses a fixed timeout via coresight_timeout(), which may be insufficient when multiple sources are enabled or under heavy load, leading to TMC readiness or flush completion timeout. This patch introduces a configurable timeout mechanism for flush and tmcready. Signed-off-by: Yuanfang Zhang <quic_yuanfang(a)quicinc.com> --- drivers/hwtracing/coresight/coresight-tmc-core.c | 43 ++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c index 88afb16bb6bec395ba535155228d176250f38625..286d56ce88fe80fbfa022946dc798f0f4e72f961 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-core.c +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c @@ -8,6 +8,7 @@ #include <linux/kernel.h> #include <linux/init.h> #include <linux/types.h> +#include <linux/delay.h> #include <linux/device.h> #include <linux/idr.h> #include <linux/io.h> @@ -35,13 +36,31 @@ DEFINE_CORESIGHT_DEVLIST(etb_devs, "tmc_etb"); DEFINE_CORESIGHT_DEVLIST(etf_devs, "tmc_etf"); DEFINE_CORESIGHT_DEVLIST(etr_devs, "tmc_etr"); +static u32 tmc_timeout; + +static void tmc_extend_timeout(struct csdev_access *csa, u32 offset, int pos, int val) +{ + int i; + + for (i = tmc_timeout; i > 0; i--) { + if (i - 1) + udelay(1); + } +} + +static int tmc_wait_status(struct csdev_access *csa, u32 offset, int pos, int val) +{ + return coresight_timeout_action(csa, offset, pos, val, + tmc_extend_timeout); +} + int tmc_wait_for_tmcready(struct tmc_drvdata *drvdata) { struct coresight_device *csdev = drvdata->csdev; struct csdev_access *csa = &csdev->access; /* Ensure formatter, unformatter and hardware fifo are empty */ - if (coresight_timeout(csa, TMC_STS, TMC_STS_TMCREADY_BIT, 1)) { + if (tmc_wait_status(csa, TMC_STS, TMC_STS_TMCREADY_BIT, 1)) { dev_err(&csdev->dev, "timeout while waiting for TMC to be Ready\n"); return -EBUSY; @@ -61,7 +80,7 @@ void tmc_flush_and_stop(struct tmc_drvdata *drvdata) ffcr |= BIT(TMC_FFCR_FLUSHMAN_BIT); writel_relaxed(ffcr, drvdata->base + TMC_FFCR); /* Ensure flush completes */ - if (coresight_timeout(csa, TMC_FFCR, TMC_FFCR_FLUSHMAN_BIT, 0)) { + if (tmc_wait_status(csa, TMC_FFCR, TMC_FFCR_FLUSHMAN_BIT, 0)) { dev_err(&csdev->dev, "timeout while waiting for completion of Manual Flush\n"); } @@ -561,11 +580,31 @@ static ssize_t stop_on_flush_store(struct device *dev, static DEVICE_ATTR_RW(stop_on_flush); +static ssize_t timeout_cfg_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + return scnprintf(buf, PAGE_SIZE, "%d\n", tmc_timeout); +} + +static ssize_t timeout_cfg_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t size) +{ + unsigned long val; + + if (kstrtoul(buf, 0, &val)) + return -EINVAL; + tmc_timeout = val; + + return size; +} +static DEVICE_ATTR_RW(timeout_cfg); static struct attribute *coresight_tmc_attrs[] = { &dev_attr_trigger_cntr.attr, &dev_attr_buffer_size.attr, &dev_attr_stop_on_flush.attr, + &dev_attr_timeout_cfg.attr, NULL, }; --- base-commit: 408c97c4a5e0b634dcd15bf8b8808b382e888164 change-id: 20250627-flush_timeout-a598b4c0ce7b Best regards, -- Yuanfang Zhang <quic_yuanfang(a)quicinc.com>

1 month, 2 weeks

Re: [PATCH v2 06/28] coresight: etm4x: Add context synchronization before enabling trace

by Leo Yan

On Wed, Jul 02, 2025 at 12:05:10PM +0100, Yeoreum Yun wrote: [...] > > @@ -445,13 +445,37 @@ static int etm4_enable_trace_unit(struct etmv4_drvdata *drvdata) > > etm4x_relaxed_write32(csa, TRCRSR_TA, TRCRSR); > > > > etm4x_allow_trace(drvdata); > > + > > + /* > > + * According to software usage PKLXF in Arm ARM (ARM DDI 0487 L.a), > > + * execute a Context synchronization event to guarantee the trace unit > > + * will observe the new values of the System registers. > > + */ > > + if (!csa->io_mem) > > + isb(); > > + > > But, when write to SYS_TRFCR_EL1 in etm4x_allow_trace(), it already does > isb(). Is it redundant? Good point. It is not sufficient. As a system register writing in kvm_tracing_set_el1_configuration(), this is why adds a ISB here. Thanks, Leo

1 month, 2 weeks

Re: [PATCH v2 05/28] coresight: etm4x: Ensure context synchronization is not ignored

by Leo Yan

Hi Levi, On Wed, Jul 02, 2025 at 12:10:17PM +0100, Yeoreum Yun wrote: [...] > > @@ -579,6 +572,13 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > > > > if (!drvdata->paused) > > rc = etm4_enable_trace_unit(drvdata); > > + > > + /* > > + * As recommended by section 4.3.7 (Synchronization of register updates) > > + * of ARM IHI 0064H.b, the self-hosted trace analyzer always executes an > > + * ISB instruction after programming the trace unit registers. > > + */ > > + isb(); > > But according to 4.3.7 ("Synchronization when using memory-mapped > interface"), doesn't it need to dsb like: > > if (csa->iomem) > dsb(sy); > isb(); > > Or am I missing something? Section 4.3.7 suggests using a DSB barrier to ensure that writes have completed in MMIO mode. It also mentions an alternative: "If the memory is marked as Device-nGnRE or stronger, read back the value of any register in the trace unit. This relies on the peripheral coherence order defined in the Arm architecture." In the etm4_{enable|disable}_trace_unit() functions, each time the TRCPRGCTLR register is written, the driver polls bits in TRCSTATR. This acts as synchronization using read-after-write (RAW), which is exactly the approach suggested above. This is why we don't need DSB() anymore. Thanks, Leo

1 month, 2 weeks

Re: [PATCH v2 03/28] coresight: etm3x: Always set tracer's device mode on target CPU

by Leo Yan

On Wed, Jul 02, 2025 at 11:18:21AM +0100, Yeoreum Yun wrote: > Hi Leo, > > [...] > > @@ -464,17 +477,29 @@ static int etm_enable_perf(struct coresight_device *csdev, > > struct perf_event *event, > > struct coresight_path *path) > > { > > + int ret = 0; > > struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > > > > - if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id())) > > - return -EINVAL; > > + if (!coresight_take_mode(csdev, CS_MODE_PERF)) > > + return -EBUSY; > > + > > + if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id())) { > > + ret = -EINVAL; > > + goto out; > > + } > > Small question: why drvdata->cpu != smp_processor_id() check after > changing mode? Would it better to check before change of it? You are right. I will update in next version. Thanks for pointing out this! Leo

1 month, 2 weeks

Re: [PATCH v2 01/28] coresight: Change device mode to atomic type

by Leo Yan

Hi Levi, On Wed, Jul 02, 2025 at 10:49:01AM +0100, Yeoreum Yun wrote: > Hi Leo, > > > { > > - return local_cmpxchg(&csdev->mode, CS_MODE_DISABLED, new_mode) == > > - CS_MODE_DISABLED; > > + int curr = CS_MODE_DISABLED; > > + > > + return atomic_try_cmpxchg_acquire(&csdev->mode, &curr, new_mode); > > } > > Just question. why is acquire symentic enough in here? My understanding is that acquire semantics ensure ordering between cmpxchg_acquire() and all memory accesses that follow it. However, it does not guarantee that memory accesses appearing before the acquire are ordered as well. This is exactly what we want in the driver. We must ensure to first grab an active device mode, then it is safe to proceed later operations (e.g. set configurations in driver data and access registers). > before this change, local_cmpxchg seems to use full_fenced. Not really. Arm64 has atomic instruction for cmpxchg, it does not use full_fenced. It should run into the path of arch_cmpxchg(). Thanks, Leo

1 month, 2 weeks

Re: [PATCH v2 1/3] coresight: tmc: Add missing doc of tmc_drvdata::reading

by hejunhao

On 2025/6/20 19:53, Jonathan Cameron wrote: > On Fri, 20 Jun 2025 15:54:10 +0800 > Junhao He <hejunhao3(a)huawei.com> wrote: > >> From: Yicong Yang <yangyicong(a)hisilicon.com> >> >> tmc_drvdata::reading is used to indicate whether a reading process >> is performed through /dev/xyz.tmc. Document it. >> >> Reviewed-by: James Clark <james.clark(a)linaro.org> >> Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> >> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> >> --- >> drivers/hwtracing/coresight/coresight-tmc.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h >> index 6541a27a018e..3ca0d40c580d 100644 >> --- a/drivers/hwtracing/coresight/coresight-tmc.h >> +++ b/drivers/hwtracing/coresight/coresight-tmc.h >> @@ -220,6 +220,7 @@ struct tmc_resrv_buf { >> * @pid: Process ID of the process that owns the session that is using >> * this component. For example this would be the pid of the Perf >> * process. >> + * @reading: buffer's in the reading through "/dev/xyz.tmc" entry > Hi, > > Perhaps reword: > > "buffer is being read through "/dev/xyz.tmc" entry" or > "buffer read in progress through "/dev/xyz.tmc" entry" > > I've not checked what this actually means - just looking at what you have here. Will update this. Thanks Best regards, Junhao. >> * @stop_on_flush: Stop on flush trigger user configuration. >> * @buf: Snapshot of the trace data for ETF/ETB. >> * @etr_buf: details of buffer used in TMC-ETR > . >

1 month, 2 weeks

Re: [PATCH v2 2/3] coresight: tmc: refactor the tmc-etr mode setting to avoid race conditions

by hejunhao

On 2025/6/20 20:45, Jonathan Cameron wrote: > On Fri, 20 Jun 2025 15:54:11 +0800 > Junhao He <hejunhao3(a)huawei.com> wrote: > >> When trying to run perf and sysfs mode simultaneously, the WARN_ON() >> in tmc_etr_enable_hw() is triggered sometimes: >> >> WARNING: CPU: 42 PID: 3911571 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1060 tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] >> [..snip..] >> Call trace: >> tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] (P) >> tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] (L) >> tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] >> coresight_enable_path+0x1c8/0x218 [coresight] >> coresight_enable_sysfs+0xa4/0x228 [coresight] >> enable_source_store+0x58/0xa8 [coresight] >> dev_attr_store+0x20/0x40 >> sysfs_kf_write+0x4c/0x68 >> kernfs_fop_write_iter+0x120/0x1b8 >> vfs_write+0x2c8/0x388 >> ksys_write+0x74/0x108 >> __arm64_sys_write+0x24/0x38 >> el0_svc_common.constprop.0+0x64/0x148 >> do_el0_svc+0x24/0x38 >> el0_svc+0x3c/0x130 >> el0t_64_sync_handler+0xc8/0xd0 >> el0t_64_sync+0x1ac/0x1b0 >> ---[ end trace 0000000000000000 ]--- >> >> Since the sysfs buffer allocation and the hardware enablement is not >> in the same critical region, it's possible to race with the perf >> >> mode: >> [sysfs mode] [perf mode] >> tmc_etr_get_sysfs_buffer() >> spin_lock(&drvdata->spinlock) >> [sysfs buffer allocation] >> spin_unlock(&drvdata->spinlock) >> spin_lock(&drvdata->spinlock) >> tmc_etr_enable_hw() >> drvdata->etr_buf = etr_perf->etr_buf >> spin_unlock(&drvdata->spinlock) >> spin_lock(&drvdata->spinlock) >> tmc_etr_enable_hw() >> WARN_ON(drvdata->etr_buf) // WARN sicne etr_buf initialized at >> the perf side >> spin_unlock(&drvdata->spinlock) >> >> A race condition is introduced here, perf always prioritizes execution, and >> warnings can lead to concerns about potential hidden bugs, such as getting >> out of sync. >> >> To fix this, configure the tmc-etr mode before invoking enable_etr_perf() >> or enable_etr_sysfs(), explicitly check if the tmc-etr sink is already >> enabled in a different mode, and simplily the setup and checks for "mode". >> To prevent race conditions between mode transitions. >> >> Fixes: 296b01fd106e ("coresight: Refactor out buffer allocation function for ETR") >> Reported-by: Yicong Yang <yangyicong(a)hisilicon.com> >> Closes: https://lore.kernel.org/linux-arm-kernel/20241202092419.11777-2-yangyicong@… >> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> >> --- >> .../hwtracing/coresight/coresight-tmc-etr.c | 73 +++++++++++-------- >> 1 file changed, 43 insertions(+), 30 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c >> index b07fcdb3fe1a..252a57a8e94e 100644 >> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c >> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c >> @@ -1263,11 +1263,6 @@ static struct etr_buf *tmc_etr_get_sysfs_buffer(struct coresight_device *csdev) >> raw_spin_lock_irqsave(&drvdata->spinlock, flags); >> } >> >> - if (drvdata->reading || coresight_get_mode(csdev) == CS_MODE_PERF) { >> - ret = -EBUSY; >> - goto out; >> - } >> - >> /* >> * If we don't have a buffer or it doesn't match the requested size, >> * use the buffer allocated above. Otherwise reuse the existing buffer. >> @@ -1278,7 +1273,6 @@ static struct etr_buf *tmc_etr_get_sysfs_buffer(struct coresight_device *csdev) >> drvdata->sysfs_buf = new_buf; >> } >> >> -out: >> raw_spin_unlock_irqrestore(&drvdata->spinlock, flags); >> >> /* Free memory outside the spinlock if need be */ >> @@ -1289,7 +1283,7 @@ static struct etr_buf *tmc_etr_get_sysfs_buffer(struct coresight_device *csdev) >> >> static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev) >> { >> - int ret = 0; >> + int ret; >> unsigned long flags; >> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); >> struct etr_buf *sysfs_buf = tmc_etr_get_sysfs_buffer(csdev); >> @@ -1299,23 +1293,10 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev) >> >> raw_spin_lock_irqsave(&drvdata->spinlock, flags); >> >> - /* >> - * In sysFS mode we can have multiple writers per sink. Since this >> - * sink is already enabled no memory is needed and the HW need not be >> - * touched, even if the buffer size has changed. >> - */ >> - if (coresight_get_mode(csdev) == CS_MODE_SYSFS) { >> - csdev->refcnt++; >> - goto out; >> - } >> - >> ret = tmc_etr_enable_hw(drvdata, sysfs_buf); >> - if (!ret) { >> - coresight_set_mode(csdev, CS_MODE_SYSFS); >> + if (!ret) >> csdev->refcnt++; >> - } >> >> -out: >> raw_spin_unlock_irqrestore(&drvdata->spinlock, flags); >> >> if (!ret) >> @@ -1735,11 +1716,6 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data) >> struct etr_perf_buffer *etr_perf = etm_perf_sink_config(handle); >> >> raw_spin_lock_irqsave(&drvdata->spinlock, flags); >> - /* Don't use this sink if it is already claimed by sysFS */ >> - if (coresight_get_mode(csdev) == CS_MODE_SYSFS) { >> - rc = -EBUSY; >> - goto unlock_out; >> - } >> >> if (WARN_ON(!etr_perf || !etr_perf->etr_buf)) { >> rc = -EINVAL; >> @@ -1768,7 +1744,6 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data) >> if (!rc) { >> /* Associate with monitored process. */ >> drvdata->pid = pid; >> - coresight_set_mode(csdev, CS_MODE_PERF); >> drvdata->perf_buf = etr_perf->etr_buf; >> csdev->refcnt++; >> } >> @@ -1781,14 +1756,52 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data) >> static int tmc_enable_etr_sink(struct coresight_device *csdev, >> enum cs_mode mode, void *data) >> { >> + struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); >> + enum cs_mode old_mode; >> + int rc = -EINVAL; >> + >> + scoped_guard(spinlock_irqsave, &drvdata->spinlock) { >> + old_mode = coresight_get_mode(csdev); >> + if (old_mode != CS_MODE_DISABLED && old_mode != mode) >> + return -EBUSY; >> + >> + if (drvdata->reading) >> + return -EBUSY; >> + >> + /* In sysFS mode we can have multiple writers per sink. */ >> + if (old_mode == CS_MODE_SYSFS) { > This seems odd. You are incrementing the reference count when potentially changing > away from CS_MODE_SYSFS? > Is this meant to only occur if old_mode == mode && old_mode == CS_MODE_SYSFS? Yes, old_mode == CS_MODE_SYSFS means tmc_etr is occupied by sysfs, and old_mode == mode, so can add reference counting directly. When tmc_etr is idle its mode is CS_MODE_DISABLED. > In the code prior to this patch this bit only ran in tmc_enable_etr_sink_sysfs() > which was only called based on the mode being configured (mode here I think) being > sysfs. That no longer looks to be the case. before the patch, first check (mode == CS_MODE_SYSFS), then check (coresight_get_mode(csdev) == CS_MODE_SYSFS), and finally csdev->refcnt++. This is the same as the current functionality. > Maybe I'm missing something as the flows around this are complex. > > >> + csdev->refcnt++; >> + return 0; >> + } >> + >> + /* >> + * minor note: In sysFS mode, the task1 get locked first, it setup >> + * etr mode to SYSFS. Then task2 get locked，it will directly return >> + * success even when the tmc-etr is not enabled at this moment. >> + * Ultimately, task1 will still successfully enable tmc-etr. >> + * This is a transient state and does not cause an anomaly. >> + */ >> + coresight_set_mode(csdev, mode); >> + } >> + >> switch (mode) { >> case CS_MODE_SYSFS: >> - return tmc_enable_etr_sink_sysfs(csdev); >> + rc = tmc_enable_etr_sink_sysfs(csdev); >> + break; >> case CS_MODE_PERF: >> - return tmc_enable_etr_sink_perf(csdev, data); >> + rc = tmc_enable_etr_sink_perf(csdev, data); >> + break; >> default: >> - return -EINVAL; >> + rc = -EINVAL; >> } >> + >> + if (rc && old_mode != mode) { >> + scoped_guard(spinlock_irqsave, &drvdata->spinlock) { > Might be a local style matching thing but if not the scope is tight anyway > so could use the unscoped version. > > guard(spinlock_irqsave)(&drvdata->spinlock); > coresight_set_mode(csdev, old_mode); Sure, Will fix in next version. >> + coresight_set_mode(csdev, old_mode); >> + } >> + } >> + >> + return rc; >> } >> >> static int tmc_disable_etr_sink(struct coresight_device *csdev) > . >

1 month, 2 weeks

Re: [PATCH v4 01/10] coresight: tmc: Support atclk

by Leo Yan

Hi Levi, On Fri, Jun 27, 2025 at 02:49:19PM +0100, Yeoreum Yun wrote: > > > > > @@ -789,6 +789,10 @@ static int __tmc_probe(struct device *dev, struct resource *res) > > > struct coresight_desc desc = { 0 }; > > > struct coresight_dev_list *dev_list = NULL; > > > > > > + drvdata->atclk = devm_clk_get_optional_enabled(dev, "atclk"); > > > + if (IS_ERR(drvdata->atclk)) > > > + return PTR_ERR(drvdata->atclk); > > > + > > > ret = -ENOMEM; > > > > > > > Just another quetion. > > > > If this function is called from tmc_platform_probe() and failed, > > should it call the clk_put() for drvdata->pclk when it failed? > > Sorry, I missed the Patch #7. No worries. devm_clk_release() is a registered callback used by the device model layer to release resources. The clock will be released in the flow: devm_clk_release() `> clk_put() `> free_clk() Thanks, Leo

1 month, 3 weeks

[PATCH] arm: coresight: Finish removal of Coresight support in arch/arm/kernel

by James Clark

Commit 184901a06a36 ("ARM: removing support for etb/etm in "arch/arm/kernel/"") removed asm/hardware/coresight.h which is included by this file. Therefore this is dead code so delete it. Signed-off-by: James Clark <james.clark(a)linaro.org> --- arch/arm/include/asm/cti.h | 160 ------------------------------------- 1 file changed, 160 deletions(-) delete mode 100644 arch/arm/include/asm/cti.h diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h deleted file mode 100644 index f8500e5d6ea8..000000000000 --- a/arch/arm/include/asm/cti.h +++ /dev/null @@ -1,160 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __ASMARM_CTI_H -#define __ASMARM_CTI_H - -#include <asm/io.h> -#include <asm/hardware/coresight.h> - -/* The registers' definition is from section 3.2 of - * Embedded Cross Trigger Revision: r0p0 - */ -#define CTICONTROL 0x000 -#define CTISTATUS 0x004 -#define CTILOCK 0x008 -#define CTIPROTECTION 0x00C -#define CTIINTACK 0x010 -#define CTIAPPSET 0x014 -#define CTIAPPCLEAR 0x018 -#define CTIAPPPULSE 0x01c -#define CTIINEN 0x020 -#define CTIOUTEN 0x0A0 -#define CTITRIGINSTATUS 0x130 -#define CTITRIGOUTSTATUS 0x134 -#define CTICHINSTATUS 0x138 -#define CTICHOUTSTATUS 0x13c -#define CTIPERIPHID0 0xFE0 -#define CTIPERIPHID1 0xFE4 -#define CTIPERIPHID2 0xFE8 -#define CTIPERIPHID3 0xFEC -#define CTIPCELLID0 0xFF0 -#define CTIPCELLID1 0xFF4 -#define CTIPCELLID2 0xFF8 -#define CTIPCELLID3 0xFFC - -/* The below are from section 3.6.4 of - * CoreSight v1.0 Architecture Specification - */ -#define LOCKACCESS 0xFB0 -#define LOCKSTATUS 0xFB4 - -/** - * struct cti - cross trigger interface struct - * @base: mapped virtual address for the cti base - * @irq: irq number for the cti - * @trig_out_for_irq: triger out number which will cause - * the @irq happen - * - * cti struct used to operate cti registers. - */ -struct cti { - void __iomem *base; - int irq; - int trig_out_for_irq; -}; - -/** - * cti_init - initialize the cti instance - * @cti: cti instance - * @base: mapped virtual address for the cti base - * @irq: irq number for the cti - * @trig_out: triger out number which will cause - * the @irq happen - * - * called by machine code to pass the board dependent - * @base, @irq and @trig_out to cti. - */ -static inline void cti_init(struct cti *cti, - void __iomem *base, int irq, int trig_out) -{ - cti->base = base; - cti->irq = irq; - cti->trig_out_for_irq = trig_out; -} - -/** - * cti_map_trigger - use the @chan to map @trig_in to @trig_out - * @cti: cti instance - * @trig_in: trigger in number - * @trig_out: trigger out number - * @channel: channel number - * - * This function maps one trigger in of @trig_in to one trigger - * out of @trig_out using the channel @chan. - */ -static inline void cti_map_trigger(struct cti *cti, - int trig_in, int trig_out, int chan) -{ - void __iomem *base = cti->base; - unsigned long val; - - val = __raw_readl(base + CTIINEN + trig_in * 4); - val |= BIT(chan); - __raw_writel(val, base + CTIINEN + trig_in * 4); - - val = __raw_readl(base + CTIOUTEN + trig_out * 4); - val |= BIT(chan); - __raw_writel(val, base + CTIOUTEN + trig_out * 4); -} - -/** - * cti_enable - enable the cti module - * @cti: cti instance - * - * enable the cti module - */ -static inline void cti_enable(struct cti *cti) -{ - __raw_writel(0x1, cti->base + CTICONTROL); -} - -/** - * cti_disable - disable the cti module - * @cti: cti instance - * - * enable the cti module - */ -static inline void cti_disable(struct cti *cti) -{ - __raw_writel(0, cti->base + CTICONTROL); -} - -/** - * cti_irq_ack - clear the cti irq - * @cti: cti instance - * - * clear the cti irq - */ -static inline void cti_irq_ack(struct cti *cti) -{ - void __iomem *base = cti->base; - unsigned long val; - - val = __raw_readl(base + CTIINTACK); - val |= BIT(cti->trig_out_for_irq); - __raw_writel(val, base + CTIINTACK); -} - -/** - * cti_unlock - unlock cti module - * @cti: cti instance - * - * unlock the cti module, or else any writes to the cti - * module is not allowed. - */ -static inline void cti_unlock(struct cti *cti) -{ - __raw_writel(CS_LAR_KEY, cti->base + LOCKACCESS); -} - -/** - * cti_lock - lock cti module - * @cti: cti instance - * - * lock the cti module, so any writes to the cti - * module will be not allowed. - */ -static inline void cti_lock(struct cti *cti) -{ - __raw_writel(~CS_LAR_KEY, cti->base + LOCKACCESS); -} -#endif -- 2.34.1

1 month, 3 weeks

Re: [PATCH v5 3/5] dt-bindings: arm: Add qcom,qmi-id for remote etm

by Jinlong Mao

On 2025/6/18 11:16, Bjorn Andersson wrote: > On Thu, Apr 24, 2025 at 04:58:52AM -0700, Mao Jinlong wrote: >> qcom,qmi-id is required for remote etm driver to find the remote >> subsystem connection. It is the instance id used by qmi API to >> communicate with remote processor. >> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> index 4fd5752978cd..947fe33738a3 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> @@ -20,6 +20,13 @@ properties: >> compatible: >> const: qcom,coresight-remote-etm >> >> + qcom,qmi-id: > > Why isn't this "qcom,qmi-instance-id" if that's what it represents? ok. > >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + This id is used by qmi API to communicate with remote processor for >> + enabling and disabling remote etm. Each processor has its unique instance >> + id. > > DeviceTree describes the hardware and firmware interface, so don't > describe properties in terms of what Linux will do with this value, but > what it represents. Sure. I will update it. > >> + >> out-ports: >> $ref: /schemas/graph.yaml#/properties/ports >> additionalProperties: false >> @@ -32,6 +39,7 @@ properties: >> required: >> - compatible >> - out-ports >> + - qcom,qmi-id > > How can this suddenly be required, did devices described by this binding > up until this point not work? Without this instance id, remote etm won't work. > > If this is the case, make sure to clearly describe this in the commit > message. > > Regards, > Bjorn > >> >> additionalProperties: false >> >> @@ -40,6 +48,8 @@ examples: >> etm { >> compatible = "qcom,coresight-remote-etm"; >> >> + qcom,qmi-id = <2>; >> + >> out-ports { >> port { >> modem_etm0_out_funnel_modem: endpoint { >> -- >> 2.25.1 >>

1 month, 3 weeks

← Newer
1
...
4
5
6
7
8
9
10
...
244
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight