CoreSight

coresight@lists.linaro.org

1 participants
2095 discussions

Re: [PATCH v11 1/2] drivers/coresight: Add UltraSoc System Memory Buffer driver

by hejunhao

Hi Jonathan, Thanks for your comments. On 2022/11/7 22:30, Jonathan Cameron wrote: > On Mon, 7 Nov 2022 21:06:23 +0800 > Junhao He <hejunhao3(a)huawei.com> wrote: > >> From: Qi Liu <liuqi115(a)huawei.com> >> >> This patch adds driver for UltraSoc SMB(System Memory Buffer) >> device. SMB provides a way to buffer messages from ETM, and >> store these "CPU instructions trace" in system memory. >> >> SMB is developed by UltraSoc technology, which is acquired by >> Siemens, and we still use "UltraSoc" to name driver. >> >> Signed-off-by: Qi Liu <liuqi115(a)huawei.com> >> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> >> Tested-by: JunHao He <hejunhao3(a)huawei.com> > Hi JunHao, > > It's been a while since I last looked at this driver, so I may have > forgotten or missed previous discussions. > > All the comments inline are fairly superficial and mostly concerned > with making the code easy to review / maintain rather than correctness. > > Jonathan Yes, I will do that. Junhao. >> --- >> drivers/hwtracing/coresight/Kconfig | 11 + >> drivers/hwtracing/coresight/Makefile | 1 + >> drivers/hwtracing/coresight/ultrasoc-smb.c | 631 +++++++++++++++++++++ >> drivers/hwtracing/coresight/ultrasoc-smb.h | 113 ++++ >> 4 files changed, 756 insertions(+) >> create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c >> create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h >> >> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig >> index 45c1eb5dfcb7..05d791cb05e3 100644 >> --- a/drivers/hwtracing/coresight/Kconfig >> +++ b/drivers/hwtracing/coresight/Kconfig >> @@ -201,4 +201,15 @@ config CORESIGHT_TRBE >> >> To compile this driver as a module, choose M here: the module will be >> called coresight-trbe. >> + >> +config ULTRASOC_SMB >> + tristate "Ultrasoc system memory buffer drivers" >> + depends on ACPI && ARM64 && CORESIGHT_LINKS_AND_SINKS > Can you relax this at all in the interests of getting better CI build coverage > from random configs etc. > > >From a quick look, I think you can safely drop the ACPI dependency on basis > relevant functions are stubbed out in acpi.h > > However, it looks like coresight more generally uses such depends, so perhaps > better to just leave them here for consistency. Ok, Will check it. Thanks. >> + help >> + This driver provides support for the Ultrasoc system memory buffer (SMB). >> + SMB is responsible for receiving the trace data from Coresight ETM devices >> + and storing them to a system buffer. >> + >> + To compile this driver as a module, choose M here: the module will be >> + called ultrasoc-smb. >> endif > >> diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c >> new file mode 100644 >> index 000000000000..7fe8bf9623e8 >> --- /dev/null >> +++ b/drivers/hwtracing/coresight/ultrasoc-smb.c >> @@ -0,0 +1,631 @@ > ... > > >> + >> +static void smb_buffer_sync_status(struct smb_drv_data *drvdata) >> +{ >> + struct smb_data_buffer *sdb = &drvdata->sdb; >> + >> + sdb->wr_offset = readl(drvdata->base + SMB_LB_WR_ADDR) - sdb->start_addr; >> + sdb->rd_offset = readl(drvdata->base + SMB_LB_RD_ADDR) - sdb->start_addr; >> + if (sdb->wr_offset == sdb->rd_offset && !smb_buffer_is_empty(drvdata)) >> + sdb->full = true; >> + else >> + sdb->full = false; > Could do as > sdb->full = sdb->wr_offset == sdb->rd_offset && !smb_buffer_is_empty(drvdata); > up to you on which you think is more readable. Ok, I will drop this "if else" block. Thanks. > >> +} >> + > > >> +static struct attribute *smb_sink_attrs[] = { >> + coresight_simple_reg32(read_pos, SMB_LB_RD_ADDR), >> + coresight_simple_reg32(write_pos, SMB_LB_WR_ADDR), >> + coresight_simple_reg32(buf_status, SMB_LB_INT_STS), >> + &dev_attr_buf_size.attr, >> + NULL, > As below. Sure, Will fix in next version. Thanks. > >> +}; >> + >> +static const struct attribute_group smb_sink_group = { >> + .attrs = smb_sink_attrs, >> + .name = "mgmt", >> +}; >> + >> +static const struct attribute_group *smb_sink_groups[] = { >> + &smb_sink_group, >> + NULL, > Generally no comma after a NULL terminator. Having a comma > implies it may make sense to put something after it, which is never > the case for these. Sure, Will fix in next version. Thanks. >> +}; >> + > > ... > >> +static void smb_sync_perf_buffer(struct smb_drv_data *drvdata, >> + struct cs_buffers *buf, >> + unsigned long head, >> + unsigned long data_size) >> +{ >> + struct smb_data_buffer *sdb = &drvdata->sdb; >> + char **dst_pages = (char **)buf->data_pages; > Do you need the cast? It's void ** so implicit cast should work I think. > char **dst_pages = buf->data_pages; Ok, Will fix in next version. Thanks. >> + unsigned long to_copy; >> + long pg_idx, pg_offset; >> + >> + pg_idx = head >> PAGE_SHIFT; >> + pg_offset = head & (PAGE_SIZE - 1); >> + >> + while (data_size) { >> + unsigned long pg_space = PAGE_SIZE - pg_offset; >> + >> + /* Copy parts of trace data when read pointer wrap around */ >> + if (sdb->rd_offset + pg_space > sdb->buf_size) >> + to_copy = sdb->buf_size - sdb->rd_offset; >> + else >> + to_copy = min(data_size, pg_space); >> + >> + memcpy(dst_pages[pg_idx] + pg_offset, >> + sdb->buf_base + sdb->rd_offset, to_copy); >> + >> + pg_offset += to_copy; >> + if (pg_offset >= PAGE_SIZE) { >> + pg_offset = 0; >> + pg_idx++; >> + pg_idx %= buf->nr_pages; >> + } >> + data_size -= to_copy; >> + sdb->rd_offset += to_copy; >> + sdb->rd_offset %= sdb->buf_size; >> + } >> + >> + sdb->data_size = 0; >> + writel(sdb->start_addr + sdb->rd_offset, drvdata->base + SMB_LB_RD_ADDR); >> + >> + /* >> + * Data remained in link cannot be purged when SMB is full, so >> + * synchronize the read pointer to write pointer, to make sure >> + * these remained data won't influence next trace. >> + */ >> + if (sdb->full) { >> + smb_purge_data(drvdata); >> + writel(readl(drvdata->base + SMB_LB_WR_ADDR), >> + drvdata->base + SMB_LB_RD_ADDR); >> + } >> + smb_reset_buffer_status(drvdata); >> +} > > ... > >> + >> +static void smb_init_hw(struct smb_drv_data *drvdata) >> +{ >> + /* First disable smb and clear the status of SMB buffer */ > Check for consistency in capitalization of SMB in all comments. Sure, Will fix in next version. Thanks. > >> + smb_reset_buffer_status(drvdata); >> + smb_disable_hw(drvdata); >> + smb_purge_data(drvdata); >> + >> + writel(SMB_BUF_CFG_STREAMING, drvdata->base + SMB_LB_CFG_LO); >> + writel(SMB_MSG_FILTER, drvdata->base + SMB_LB_CFG_HI); >> + writel(SMB_GLOBAL_CFG, drvdata->base + SMB_CFG_REG); >> + writel(SMB_GLB_INT_CFG, drvdata->base + SMB_GLOBAL_INT); >> + writel(SMB_BUF_INT_CFG, drvdata->base + SMB_LB_INT_CTRL); >> +} >> + > > ... > >> +static int smb_probe(struct platform_device *pdev) >> +{ >> + struct device *dev = &pdev->dev; >> + struct smb_drv_data *drvdata; >> + int ret; >> + >> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); >> + if (!drvdata) >> + return -ENOMEM; >> + >> + drvdata->base = devm_platform_ioremap_resource(pdev, SMB_BASE_ADDR_RES); >> + if (IS_ERR(drvdata->base)) { >> + dev_err(dev, "Failed to ioremap resource\n"); >> + return PTR_ERR(drvdata->base); >> + } >> + >> + ret = smb_init_data_buffer(pdev, &drvdata->sdb); >> + if (ret) { >> + dev_err(dev, "Failed to init buffer, ret = %d\n", ret); >> + return ret; >> + } >> + >> + smb_init_hw(drvdata); >> + mutex_init(&drvdata->mutex); >> + drvdata->pid = -1; >> + >> + ret = smb_register_sink(pdev, drvdata); >> + if (ret) { >> + dev_err(dev, "Failed to register smb sink\n"); >> + return ret; >> + } >> + >> + ret = smb_config_inport(dev, true); >> + if (ret) { >> + smb_unregister_sink(drvdata); >> + return ret; >> + } >> + >> + platform_set_drvdata(pdev, drvdata); >> + return 0; >> +} >> + >> +static int smb_remove(struct platform_device *pdev) >> +{ >> + struct smb_drv_data *drvdata = platform_get_drvdata(pdev); >> + int ret; >> + >> + ret = smb_config_inport(&pdev->dev, false); >> + if (ret) >> + return ret; >> + >> + smb_unregister_sink(drvdata); > Trivial: I find a blank line before plane returns like this helps > a little with readability. Up to you though! Ok, Will fix it. Thanks. > >> + return 0; >> +} >> + >> +static const struct acpi_device_id ultrasoc_smb_acpi_match[] = { >> + {"HISI03A1", 0}, >> + {}, > Trivial, but little point in a trailing comma on a NULL terminator. Sure, Will fix in next version. Thanks. > > {} > }; > > is normally fine - note this is a bit subsystem specific so maintainer > may say otherwise. Ok, Thanks. > >> +}; >> +MODULE_DEVICE_TABLE(acpi, ultrasoc_smb_acpi_match); >> + >> +static struct platform_driver smb_driver = { >> + .driver = { >> + .name = "ultrasoc-smb", >> + .acpi_match_table = ACPI_PTR(ultrasoc_smb_acpi_match), >> + .suppress_bind_attrs = true, >> + }, >> + .probe = smb_probe, >> + .remove = smb_remove, >> +}; >> +module_platform_driver(smb_driver); >> + >> +MODULE_DESCRIPTION("UltraSoc SMB CoreSight driver"); >> +MODULE_LICENSE("Dual MIT/GPL"); >> +MODULE_AUTHOR("Jonathan Zhou <jonathan.zhouwen(a)huawei.com>"); >> +MODULE_AUTHOR("Qi Liu <liuqi115(a)huawei.com>"); >> diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.h b/drivers/hwtracing/coresight/ultrasoc-smb.h >> new file mode 100644 >> index 000000000000..56170e1a883d >> --- /dev/null >> +++ b/drivers/hwtracing/coresight/ultrasoc-smb.h >> @@ -0,0 +1,113 @@ >> +/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */ >> +/* >> + * Siemens System Memory Buffer driver. >> + * Copyright(c) 2022, HiSilicon Limited. >> + */ >> + >> +#ifndef _ULTRASOC_SMB_H >> +#define _ULTRASOC_SMB_H >> + >> +#include <linux/coresight.h> > I think you could move this down into the c files and provide > a forwards definition of struct coresight device > > Always good to keep scope of includes to minimum necessary. Sure, Will fix in next version. Thanks. > >> +#include <linux/miscdevice.h> >> +#include <linux/mutex.h> >> + >> +/* Offset of SMB logical buffer registers */ >> +#define SMB_CFG_REG 0x00 > To avoid any naming confusion I would postfix all the register > addresses with _REG > Then rethink the naming so the field names make it clear which > register they are in. OK, I'll check all REG names. Thanks. > >> +#define SMB_GLOBAL_EN 0x04 >> +#define SMB_GLOBAL_INT 0x08 >> +#define SMB_LB_CFG_LO 0x40 >> +#define SMB_LB_CFG_HI 0x44 >> +#define SMB_LB_INT_CTRL 0x48 >> +#define SMB_LB_INT_STS 0x4c >> +#define SMB_LB_LIMIT 0x58 >> +#define SMB_LB_RD_ADDR 0x5c >> +#define SMB_LB_WR_ADDR 0x60 >> +#define SMB_LB_PURGE 0x64 >> + >> +/* Set SMB_CFG_REG register */ >> +#define SMB_BURST_LEN GENMASK(7, 4) >> +#define SMB_IDLE_PRD GENMASK(15, 12) >> +#define SMB_MEM_WR GENMASK(17, 16) >> +#define SMB_MEM_RD (GENMASK(26, 25) | GENMASK(23, 22)) > Are these masks, or default values? Ideally express them as > a field mask then the value via FIELD_PREP > > e.g. > #define SMB_CFG_BURST_LEN_MSK GENMASK(7, 4) > #define SMB_GLOBAL_CFG_DEFAULT ... | FIELD_PREP(SMB_CFG_BURST_LEN_MSK, 0xf) | etc Sure, I will do that. Thanks. > > >> +#define SMB_GLOBAL_CFG (SMB_IDLE_PRD | SMB_MEM_WR | SMB_MEM_RD | \ >> + SMB_BURST_LEN) >> + >> +/* Set SMB_GLOBAL_INT register */ >> +#define SMB_INT_EN BIT(0) >> +#define SMB_INT_TYPE_PULSE BIT(1) >> +#define SMB_INT_POLARITY_HIGH BIT(2) >> +#define SMB_GLB_INT_CFG (SMB_INT_EN | SMB_INT_TYPE_PULSE | \ >> + SMB_INT_POLARITY_HIGH) >> + >> +/* Set SMB_LB_CFG_LO register */ >> +#define SMB_BUF_EN BIT(0) >> +#define SMB_BUF_SINGLE_END BIT(1) >> +#define SMB_BUF_INIT BIT(8) >> +#define SMB_BUF_CONTINUOUS BIT(11) >> +#define SMB_FILTER_FLOW GENMASK(19, 16) >> +#define SMB_BUF_CFG_STREAMING (SMB_BUF_INIT | SMB_BUF_CONTINUOUS | \ >> + SMB_FILTER_FLOW | SMB_BUF_SINGLE_END | \ >> + SMB_BUF_EN) >> + >> +#define SMB_BASE_LOW_MASK GENMASK(31, 0) >> + >> +/* Set SMB_LB_CFG_HI register */ >> +#define SMB_MSG_FILTER GENMASK(15, 8) >> + >> +/* Set SMB_LB_INT_CTRL */ >> +#define SMB_BUF_INT_EN BIT(0) >> +#define SMB_BUF_NOTE_MASK GENMASK(11, 8) >> +#define SMB_BUF_INT_CFG (SMB_BUF_INT_EN | SMB_BUF_NOTE_MASK) >> + >> +#define SMB_BUF_NOT_EMPTY BIT(0) >> +#define SMB_RESET_BUF_STS GENMASK(3, 0) >> +#define SMB_PURGED BIT(0) >> +#define SMB_HW_ENABLE BIT(0) > It is useful to give fields names that reflect which register they are in. > Perhaps > SMB_GLOBAL_EN_HW_ENABLE for this one. Sure, I will do that. Thanks. > >> + >> +#define SMB_BASE_ADDR_RES 0 >> +#define SMB_BUF_INFO_RES 1 >> + >> +/** >> + * struct smb_data_buffer - Details of the buffer used by SMB >> + * @buf_base: Memory mapped base address of SMB. >> + * @start_addr: SMB buffer start Physical address. >> + * @buf_size: Size of the buffer. >> + * @data_size: Size of Trace data copy to userspace. >> + * @rd_offset: Offset of the read pointer in the buffer. >> + * @wr_offset: Offset of the write pointer in the buffer. >> + * @status: Status of SMB buffer. > Naming wrong. Sure, Will fix in next version. Thanks. > >> + */ >> +struct smb_data_buffer { >> + void __iomem *buf_base; >> + u32 start_addr; >> + unsigned long buf_size; >> + unsigned long data_size; >> + unsigned long rd_offset; >> + unsigned long wr_offset; >> + bool full; >> +}; >> + >> +/** >> + * struct smb_drv_data - specifics associated to an SMB component >> + * @base: Memory mapped base address for SMB component. >> + * @csdev: Component vitals needed by the framework. >> + * @sdb: Data buffer for SMB. >> + * @miscdev: Specifics to handle "/dev/xyz.smb" entry. >> + * @mutex: Control data access to one at a time. >> + * @reading: Synchronise user space access to SMB buffer. >> + * @pid: Process ID of the process being monitored by the >> + * session that is using this component. >> + * @mode: how this SMB is being used, perf mode or sysfs mode. >> + */ >> +struct smb_drv_data { >> + void __iomem *base; >> + struct coresight_device *csdev; >> + struct smb_data_buffer sdb; >> + struct miscdevice miscdev; >> + struct mutex mutex; >> + local_t reading; >> + pid_t pid; >> + u32 mode; >> +}; >> + >> +#endif > . > Best regards, Junhao.

2 years

Re: [PATCH v11 2/2] Documentation: Add document for UltraSoc SMB drivers

by hejunhao

Hi Jonathan, On 2022/11/7 22:33, Jonathan Cameron wrote: > On Mon, 7 Nov 2022 21:06:24 +0800 > Junhao He <hejunhao3(a)huawei.com> wrote: > >> From: Qi Liu <liuqi115(a)huawei.com> >> >> This patch bring in documentation for UltraSoc SMB drivers. >> It simply describes the device, sysfs interface and the >> firmware bindings. >> >> Signed-off-by: Qi Liu <liuqi115(a)huawei.com> >> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> >> --- >> .../sysfs-bus-coresight-devices-ultra_smb | 31 +++++++ >> .../trace/coresight/ultrasoc-smb.rst | 80 +++++++++++++++++++ >> 2 files changed, 111 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb >> create mode 100644 Documentation/trace/coresight/ultrasoc-smb.rst >> >> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb >> new file mode 100644 >> index 000000000000..7804aef4b40b >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb >> @@ -0,0 +1,31 @@ >> +What: /sys/bus/coresight/devices/ultra_smb<N>/enable_sink >> +Date: October 2022 >> +KernelVersion: 6.1 > Update to 6.2 as this will hopefully go in next merge window and it makes > life easier for the maintainer if they don't need to fix all these up. Ok, i will fix in next version. Thanks. >> +Contact: Junhao He <hejunhao3(a)huawei.com> >> +Description: (RW) Add/remove a SMB device from a trace path. There can be >> + multiple sources for a single SMB device. > Rest looks good to me, (not an expert on this stuff though!) > > Jonathan > . > Best regards, Junhao.

2 years

[PATCH v3] coresight: etm4x: add CPU hotplug support for probing

by Tamas Zsoldos

etm4x devices cannot be successfully probed when their CPU is offline. For example, when booting with maxcpus=n, ETM probing will fail on CPUs >n, and the probing won't be reattempted once the CPUs come online. This will leave those CPUs unable to make use of ETM. This change adds a mechanism to delay the probing if the corresponding CPU is offline, and to try it again when the CPU comes online. Signed-off-by: Tamas Zsoldos <tamas.zsoldos(a)arm.com> --- Changes since v2: * Fix tear down issue (thanks to Suzuki). --- .../coresight/coresight-etm4x-core.c | 153 +++++++++++++----- 1 file changed, 113 insertions(+), 40 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 87299e99dabb..71ab1d6e72dc 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -66,10 +66,13 @@ static enum cpuhp_state hp_online; struct etm4_init_arg { unsigned int pid; - struct etmv4_drvdata *drvdata; + struct device *dev; struct csdev_access *csa; }; +static DEFINE_PER_CPU(struct etm4_init_arg *, delayed_probe); +static int etm4_probe_cpu(unsigned int cpu); + /* * Check if TRCSSPCICRn(i) is implemented for a given instance. * @@ -1071,7 +1074,7 @@ static void etm4_init_arch_data(void *info) struct csdev_access *csa; int i; - drvdata = init_arg->drvdata; + drvdata = dev_get_drvdata(init_arg->dev); csa = init_arg->csa; /* @@ -1514,7 +1517,7 @@ void etm4_config_trace_mode(struct etmv4_config *config) static int etm4_online_cpu(unsigned int cpu) { if (!etmdrvdata[cpu]) - return 0; + return etm4_probe_cpu(cpu); if (etmdrvdata[cpu]->boot_enable && !etmdrvdata[cpu]->sticky_enable) coresight_enable(etmdrvdata[cpu]->csdev); @@ -1890,48 +1893,20 @@ static void etm4_pm_clear(void) } } -static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) +static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg) { int ret; struct coresight_platform_data *pdata = NULL; - struct etmv4_drvdata *drvdata; + struct device *dev = init_arg->dev; + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev); struct coresight_desc desc = { 0 }; - struct etm4_init_arg init_arg = { 0 }; u8 major, minor; char *type_name; - drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); if (!drvdata) - return -ENOMEM; - - dev_set_drvdata(dev, drvdata); - - if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) - pm_save_enable = coresight_loses_context_with_cpu(dev) ? - PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER; - - if (pm_save_enable != PARAM_PM_SAVE_NEVER) { - drvdata->save_state = devm_kmalloc(dev, - sizeof(struct etmv4_save_state), GFP_KERNEL); - if (!drvdata->save_state) - return -ENOMEM; - } - - drvdata->base = base; - - spin_lock_init(&drvdata->spinlock); - - drvdata->cpu = coresight_get_cpu(dev); - if (drvdata->cpu < 0) - return drvdata->cpu; - - init_arg.drvdata = drvdata; - init_arg.csa = &desc.access; - init_arg.pid = etm_pid; + return -EINVAL; - if (smp_call_function_single(drvdata->cpu, - etm4_init_arch_data, &init_arg, 1)) - dev_err(dev, "ETM arch init failed\n"); + desc.access = *init_arg->csa; if (!drvdata->arch) return -EINVAL; @@ -2002,6 +1977,68 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) return 0; } +static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) +{ + struct etmv4_drvdata *drvdata; + struct csdev_access access = { 0 }; + struct etm4_init_arg init_arg = { 0 }; + struct etm4_init_arg *delayed; + + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); + if (!drvdata) + return -ENOMEM; + + dev_set_drvdata(dev, drvdata); + + if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) + pm_save_enable = coresight_loses_context_with_cpu(dev) ? + PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER; + + if (pm_save_enable != PARAM_PM_SAVE_NEVER) { + drvdata->save_state = devm_kmalloc(dev, + sizeof(struct etmv4_save_state), GFP_KERNEL); + if (!drvdata->save_state) + return -ENOMEM; + } + + drvdata->base = base; + + spin_lock_init(&drvdata->spinlock); + + drvdata->cpu = coresight_get_cpu(dev); + if (drvdata->cpu < 0) + return drvdata->cpu; + + init_arg.dev = dev; + init_arg.csa = &access; + init_arg.pid = etm_pid; + + /* + * Serialize against CPUHP callbacks to avoid race condition + * between the smp call and saving the delayed probe. + */ + cpus_read_lock(); + if (smp_call_function_single(drvdata->cpu, + etm4_init_arch_data, &init_arg, 1)) { + /* The CPU was offline, try again once it comes online. */ + delayed = devm_kmalloc(dev, sizeof(*delayed), GFP_KERNEL); + if (!delayed) { + cpus_read_unlock(); + return -ENOMEM; + } + + *delayed = init_arg; + + per_cpu(delayed_probe, drvdata->cpu) = delayed; + + cpus_read_unlock(); + return 0; + } + cpus_read_unlock(); + + return etm4_add_coresight_dev(&init_arg); +} + static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id) { void __iomem *base; @@ -2040,6 +2077,35 @@ static int etm4_probe_platform_dev(struct platform_device *pdev) return ret; } +static int etm4_probe_cpu(unsigned int cpu) +{ + int ret; + struct etm4_init_arg init_arg; + struct csdev_access access = { 0 }; + struct etm4_init_arg *iap = *this_cpu_ptr(&delayed_probe); + + if (!iap) + return 0; + + init_arg = *iap; + devm_kfree(init_arg.dev, iap); + *this_cpu_ptr(&delayed_probe) = NULL; + + ret = pm_runtime_resume_and_get(init_arg.dev); + if (ret < 0) { + dev_err(init_arg.dev, "Failed to get PM runtime!\n"); + return 0; + } + + init_arg.csa = &access; + etm4_init_arch_data(&init_arg); + + etm4_add_coresight_dev(&init_arg); + + pm_runtime_put(init_arg.dev); + return 0; +} + static struct amba_cs_uci_id uci_id_etm4[] = { { /* ETMv4 UCI data */ @@ -2054,16 +2120,20 @@ static void clear_etmdrvdata(void *info) int cpu = *(int *)info; etmdrvdata[cpu] = NULL; + per_cpu(delayed_probe, cpu) = NULL; } static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata) { - etm_perf_symlink(drvdata->csdev, false); + bool fully_registered; /* * Taking hotplug lock here to avoid racing between etm4_remove_dev() * and CPU hotplug call backs. */ cpus_read_lock(); + + fully_registered = (etmdrvdata[drvdata->cpu] == drvdata); + /* * The readers for etmdrvdata[] are CPU hotplug call backs * and PM notification call backs. Change etmdrvdata[i] on @@ -2071,12 +2141,15 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata) * inside one call back function. */ if (smp_call_function_single(drvdata->cpu, clear_etmdrvdata, &drvdata->cpu, 1)) - etmdrvdata[drvdata->cpu] = NULL; + clear_etmdrvdata(&drvdata->cpu); cpus_read_unlock(); - cscfg_unregister_csdev(drvdata->csdev); - coresight_unregister(drvdata->csdev); + if (fully_registered) { + etm_perf_symlink(drvdata->csdev, false); + cscfg_unregister_csdev(drvdata->csdev); + coresight_unregister(drvdata->csdev); + } return 0; } -- 2.17.1

2 years

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

by Leo Yan

Hi Bhupesh, On Thu, Aug 25, 2022 at 10:52:32AM +0530, Bhupesh Sharma wrote: > Some Qualcomm ETM implementations require skipping powering up > the trace unit, as the ETMs are in the same power domain as > their CPU cores. > > Via commit 5214b563588e ("coresight: etm4x: Add support for > sysreg only devices"), the setting of 'skip_power_up' flag was > moved after the 'etm4_init_arch_data' function is called, whereas > the flag value is itself used inside the function. This causes > a crash when ETM mode 'Low-power state behavior override' is set > on some Qualcomm parts. > > Fix the same. > > Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices") > Cc: Mike Leach <mike.leach(a)linaro.org> > Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma(a)linaro.org> > --- > - v1 can be seen here: https://lore.kernel.org/lkml/20220803191236.3037591-1-bhupesh.sharma@linaro… > - Addressed the review comments from Suzuki. > - Rebased on linux-next. > > drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index d39660a3e50c..14c1c7869795 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -977,6 +977,16 @@ static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata, > if (!cpu_supports_sysreg_trace()) > return false; > > + /* > + * Some Qualcomm implementations require skipping powering up the trace unit, > + * as the ETMs are in the same power domain as their CPU cores. > + * > + * Since the 'skip_power_up' flag is used inside 'etm4_init_arch_data' function, > + * initialize it before the function is called. > + */ > + if (fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) > + drvdata->skip_power_up = true; > + I personally think this sentence should be placed in the function etm4_probe(), you need to move it just before smp call etm4_init_arch_data(), this can allow DT property "qcom,skip-power-up" to be respected. > /* > * ETMs implementing sysreg access must implement TRCDEVARCH. > */ > @@ -1951,8 +1961,7 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > return -EINVAL; > > /* TRCPDCR is not accessible with system instructions. */ > - if (!desc.access.io_mem || > - fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) > + if (!desc.access.io_mem) > drvdata->skip_power_up = true; I prefer to move the condition checking for "desc.access.io_mem" to etm4_init_sysreg_access(), this can make sure the flag skip_power_up is set correctly based on property of system register access. A side topic, in the mainline kernel I found the value "desc.access.io_mem" is always zero (see the initialized value in etm4_probe() and etm4_init_sysreg_access()). Should we initialize desc.access.io_mem to true in etm4_probe()? diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index d39660a3e50c..cf2555c50abb 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -1939,6 +1939,7 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) if (drvdata->cpu < 0) return drvdata->cpu; + desc.access.io_mem = true; init_arg.drvdata = drvdata; init_arg.csa = &desc.access; init_arg.pid = etm_pid; Thanks, Leo > major = ETM_ARCH_MAJOR_VERSION(drvdata->arch); > -- > 2.35.3 >

2 years

[PATCH v11 0/2] Add support for UltraSoc System Memory Buffer

by Junhao He

Add support for UltraSoc System Memory Buffer. Change since v10: - Rebase onto v6.1-rc4, included similar sysfs register accessors (as same as James's patch) - Link: https://lore.kernel.org/lkml/20221022115929.7503-1-hejunhao3@huawei.com/ Change since v9: - Update the Contact tag in SMB document. - Replace the spinlock with mutex. - Do some clean-ups in "smb_enable()" and "smb_release()". - Use classic memory mapped interface. - Link: https://lore.kernel.org/linux-arm-kernel/20220818132231.28240-1-hejunhao3@h… Change since v8: - Insert a blank line at the end of the config tag in Kconfig to Randy's comment. - Link: https://lore.kernel.org/linux-arm-kernel/20220816131634.38195-1-hejunhao3@h… Change since v7: - Use the macros for register bit flags and numbers of resource. - Cleanup punctuation. - Update the Date tag and the KernelVersion tag in the document. - Link: https://lore.kernel.org/lkml/20220712091353.34540-1-hejunhao3@huawei.com/ Change since v6: - Modify the code style and driver description according to Suzuki's comment. - Modify configuration of "drvdata->reading", to void problems in open/read concurrency scenario. - Rename the macro of "SMB_FLOW_MASK". - Use the "handle->head" to determine the page number and offset. - Link: https://lore.kernel.org/linux-arm-kernel/20220606130223.57354-1-liuqi115@hu… Change since v5: - Address the comments from Suzuki, add some comments in SMB document, and modify configuration of "drvdata->reading", to void problems in multi-core concurrency scenario - Link: https://lore.kernel.org/linux-arm-kernel/20220416083953.52610-1-liuqi115@hu… Change since v4: - Add a simple document of SMB driver according to Suzuki's comment. - Address the comments from Suzuki. - Link: https://lore.kernel.org/linux-arm-kernel/20220128061755.31909-1-liuqi115@hu… Change since v3: - Modify the file header according to community specifications. - Address the comments from Mathieu. - Link: https://lore.kernel.org/linux-arm-kernel/20211118110016.40398-1-liuqi115@hu… Change since v2: - Move ultrasoc driver to drivers/hwtracing/coresight by Mathieu's comment. - Link: https://lists.linaro.org/pipermail/coresight/2021-November/007310.html Change since v1: - Drop the document of UltraSoc according to Mathieu's comment. - Add comments to explain some private hardware settings. - Address the comments from Mathieu. - Link: https://lists.linaro.org/pipermail/coresight/2021-August/006842.html Change since RFC: - Move driver to drivers/hwtracing/coresight/ultrasoc. - Remove ultrasoc-axi-com.c, as AXI-COM doesn't need to be configured in basic tracing function. - Remove ultrasoc.c as SMB does not need to register with the ultrasoc core. - Address the comments from Mathieu and Suzuki. - Link: https://lists.linaro.org/pipermail/coresight/2021-June/006535.html Qi Liu (2): drivers/coresight: Add UltraSoc System Memory Buffer driver Documentation: Add document for UltraSoc SMB drivers .../sysfs-bus-coresight-devices-ultra_smb | 31 + .../trace/coresight/ultrasoc-smb.rst | 80 +++ drivers/hwtracing/coresight/Kconfig | 11 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/ultrasoc-smb.c | 631 ++++++++++++++++++ drivers/hwtracing/coresight/ultrasoc-smb.h | 113 ++++ 6 files changed, 867 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb create mode 100644 Documentation/trace/coresight/ultrasoc-smb.rst create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h -- 2.33.0

2 years

Re: [PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

Hi Greg, On 07/11/2022 10:24, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2022 at 09:59:24AM +0000, Suzuki K Poulose wrote: >> On 07/11/2022 09:52, Greg Kroah-Hartman wrote: >>> On Mon, Nov 07, 2022 at 09:23:26AM +0000, Suzuki K Poulose wrote: >>>> On 07/11/2022 09:11, Greg Kroah-Hartman wrote: >>>>> On Wed, Nov 02, 2022 at 11:20:03AM +0000, James Clark wrote: >>>>>> commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. >>>>> >>>>> Isn't this commit 665c157e0204176023860b51a46528ba0ba62c33 instead? >>>> >>>> This was reverted in commit d76308f03ee1 and pushed in later >>>> with fixups as 6746eae4bbadd. >>> >>> So which should be applied? >> >> Sorry, this particular post is a backport for v5.10 stable branch. >> >>> >>> confused, >> >> Now I am too. What is expected here ? My understanding is, we >> should stick the "upstream" commit that is getting backported >> at the beginning of the commit description. In that sense, >> the commit id in this patch looks correct to me. Please let >> me know if this is not the case. >> >> As such, this is only for 5.10.x branch. The rest are taken >> care of. >> >> Please let us know if we are something missing. > > We already have commit 665c157e0204176023860b51a46528ba0ba62c33 queued > up in the 5.10 stable queue. Is that not correct? It has the same We pushed the fix as part of the coresight fixes for 6.1 [0], as commit: 6746eae4bbad "coresight: cti: Fix hang in cti_disable_hw()" But, the version in there, produced a build warning with "unused variable" (with CONFIG_WERROR) [1] and thus was reverted in [2], commit: d76308f03ee1: Revert "coresight: cti: Fix hang in cti_disable_hw()" Later, we sent you the corrected fix separately [3], which was queued as commit "6746eae4bbadd". 6746eae4bbad coresight: cti: Fix hang in cti_disable_hw() So, in effect, here is what we have in the tree : $ git log --oneline | grep "cti: Fix" 6746eae4bbad coresight: cti: Fix hang in cti_disable_hw() d76308f03ee1 Revert "coresight: cti: Fix hang in cti_disable_hw()" 665c157e0204 coresight: cti: Fix hang in cti_disable_hw() > subject line as this one. I understand the "same" subject line has caused this confusion. Will modify it in the future avoid this confusion. So, kindly drop "665c157e0204" from the queue for 5.10, it would fail to apply there anyway so does the correct "6746eae4bbad". This backport is appropriate for 5.10 branch, with the correct version. I have double checked the versions pulled into 6.0.x [4] and 5.15.x [5] branches and they all have the correct one (6746eae4bbad) applied. [0] https://lkml.kernel.org/r/16664341837810@kroah.com [1] https://lkml.kernel.org/r/20221024135752.2b83af97@canb.auug.org.au [2] https://lkml.kernel.org/r/166659326494120@kroah.com [3] https://lkml.kernel.org/r/1666717705115206@kroah.com [4] https://lkml.kernel.org/r/166719866563237@kroah.com [5] https://lkml.kernel.org/r/16671983698786@kroah.com Hope this helps. Suzuki > > Still confused. > > thanks, > > greg k-h

2 years

Re: [PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

On 07/11/2022 09:52, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2022 at 09:23:26AM +0000, Suzuki K Poulose wrote: >> On 07/11/2022 09:11, Greg Kroah-Hartman wrote: >>> On Wed, Nov 02, 2022 at 11:20:03AM +0000, James Clark wrote: >>>> commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. >>> >>> Isn't this commit 665c157e0204176023860b51a46528ba0ba62c33 instead? >> >> This was reverted in commit d76308f03ee1 and pushed in later >> with fixups as 6746eae4bbadd. > > So which should be applied? Sorry, this particular post is a backport for v5.10 stable branch. > > confused, Now I am too. What is expected here ? My understanding is, we should stick the "upstream" commit that is getting backported at the beginning of the commit description. In that sense, the commit id in this patch looks correct to me. Please let me know if this is not the case. As such, this is only for 5.10.x branch. The rest are taken care of. Please let us know if we are something missing. Suzuki > > greg k-h

2 years

Re: [PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by Suzuki K Poulose

On 07/11/2022 09:11, Greg Kroah-Hartman wrote: > On Wed, Nov 02, 2022 at 11:20:03AM +0000, James Clark wrote: >> commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. > > Isn't this commit 665c157e0204176023860b51a46528ba0ba62c33 instead? This was reverted in commit d76308f03ee1 and pushed in later with fixups as 6746eae4bbadd. Cheers Suzuki > > confused, > > greg k-h

2 years

[PATCH 5.10] coresight: cti: Fix hang in cti_disable_hw()

by James Clark

commit 6746eae4bbaddcc16b40efb33dab79210828b3ce upstream. cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. This can cause a hang when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. Fixes: 835d722ba10a ("coresight: cti: Initial CoreSight CTI Driver") Cc: stable <stable(a)kernel.org> # 5.10.x Reported-by: Aishwarya TCV <Aishwarya.TCV(a)arm.com> Reported-by: Cristian Marussi <Cristian.Marussi(a)arm.com> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Reviewed-by: Mike Leach <mike.leach(a)linaro.org> Tested-by: Mike Leach <mike.leach(a)linaro.org> [ Fix build warnings ] Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Link: https://lore.kernel.org/r/20221025131032.1149459-1-suzuki.poulose@arm.com Signed-off-by: James Clark <james.clark(a)arm.com> --- drivers/hwtracing/coresight/coresight-cti-core.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index 0276700c246d..90270696206c 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -90,11 +90,9 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata) static int cti_enable_hw(struct cti_drvdata *drvdata) { struct cti_config *config = &drvdata->config; - struct device *dev = &drvdata->csdev->dev; unsigned long flags; int rc = 0; - pm_runtime_get_sync(dev->parent); spin_lock_irqsave(&drvdata->spinlock, flags); /* no need to do anything if enabled or unpowered*/ @@ -119,7 +117,6 @@ static int cti_enable_hw(struct cti_drvdata *drvdata) /* cannot enable due to error */ cti_err_not_enabled: spin_unlock_irqrestore(&drvdata->spinlock, flags); - pm_runtime_put(dev->parent); return rc; } @@ -153,7 +150,6 @@ static void cti_cpuhp_enable_hw(struct cti_drvdata *drvdata) static int cti_disable_hw(struct cti_drvdata *drvdata) { struct cti_config *config = &drvdata->config; - struct device *dev = &drvdata->csdev->dev; spin_lock(&drvdata->spinlock); @@ -174,7 +170,6 @@ static int cti_disable_hw(struct cti_drvdata *drvdata) coresight_disclaim_device_unlocked(drvdata->base); CS_LOCK(drvdata->base); spin_unlock(&drvdata->spinlock); - pm_runtime_put(dev->parent); return 0; /* not disabled this call */ -- 2.25.1

2 years

OpenCSD version 1.3.3

by Mike Leach

Version 1.3.3 of OpenCSD is now released. Fixes problems where bad input data to the CoreSight frame demuxer was not being correctly handled, resulting in buffer misalignment and possible read beyond the end of the buffers. (Github issues #49, #50, #51) Adds a test program to validate these fixes and other error checking which has been improved / corrected. Also fixed and issue in PTM decode which failed to extract the address of a waypoint marker correctly under certain circumstances.(github issue #48) Adds build env for VS2022. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

2 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight