CoreSight

coresight@lists.linaro.org

3 participants
2673 discussions

[PATCH] coresight: etm4x: Do not access TRCIDR1 for identification

by Suzuki K Poulose

CoreSight ETM4x architecture clearly provides ways to identify a device via registers in the "Management" class, TRCDEVARCH and TRCDEVTYPE. These registers can be accessed without the Trace domain being powered on. We additionally added TRCIDR1 as fallback in order to cover for any ETMs that may not have implemented TRCDEVARCH. So far, nobody has reported hitting a WARNING we placed to catch such systems. Also, more importantly it is problematic to access TRCIDR1, which is a "Trace" register via MMIO access, without clearing the OSLK. But we cannot mess with the OSLK until we know for sure that this is an ETMv4 device. Thus, this kind of creates a chicken and egg problem unnecessarily for systems "which are compliant" to the ETMv4 architecture. Let us remove the TRCIDR1 fall back check and rely only on TRCDEVARCH. Reported-by: Steve Clevenger <scclevenger(a)os.amperecomputing.com> Link: https://lore.kernel.org/all/143540e5623d4c7393d24833f2b80600d8d745d2.167788… Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Fixes: 8b94db1edaee ("coresight: etm4x: Use TRCDEVARCH for component discovery") Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> --- .../hwtracing/coresight/coresight-etm4x-core.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 104333c2c8a3..c1b72d892d7d 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -1070,25 +1070,17 @@ static bool etm4_init_iomem_access(struct etmv4_drvdata *drvdata, struct csdev_access *csa) { u32 devarch = readl_relaxed(drvdata->base + TRCDEVARCH); - u32 idr1 = readl_relaxed(drvdata->base + TRCIDR1); /* * All ETMs must implement TRCDEVARCH to indicate that - * the component is an ETMv4. To support any broken - * implementations we fall back to TRCIDR1 check, which - * is not really reliable. + * the component is an ETMv4 */ - if ((devarch & ETM_DEVARCH_ID_MASK) == ETM_DEVARCH_ETMv4x_ARCH) { - drvdata->arch = etm_devarch_to_arch(devarch); - } else { - pr_warn("CPU%d: ETM4x incompatible TRCDEVARCH: %x, falling back to TRCIDR1\n", - smp_processor_id(), devarch); - - if (ETM_TRCIDR1_ARCH_MAJOR(idr1) != ETM_TRCIDR1_ARCH_ETMv4) - return false; - drvdata->arch = etm_trcidr_to_arch(idr1); + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { + pr_warn_once("TRCDEVARCH doesn't match ETMv4 architecture\n"); + return false; } + drvdata->arch = etm_devarch_to_arch(devarch); *csa = CSDEV_ACCESS_IOMEM(drvdata->base); return true; } -- 2.34.1

3 years

Re: [PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus

by Suzuki K Poulose

On 17/03/2023 20:06, Rob Herring wrote: > On Fri, Mar 17, 2023 at 11:03 AM Suzuki K Poulose > <suzuki.poulose(a)arm.com> wrote: >> >> Hi Rob >> >> Thanks for your response. >> >> On 17/03/2023 14:52, Rob Herring wrote: >>> On Thu, Mar 16, 2023 at 10:06 PM Anshuman Khandual >>> <anshuman.khandual(a)arm.com> wrote: >>>> >>>> Allow other drivers to claim a device, disregarding the "priority" of >>>> "arm,primecell". e.g., CoreSight ETM4x devices could be accessed via MMIO >>>> (AMBA Bus) or via CPU system instructions. >>> >>> The OS can pick which one, use both, or this is a system integration >>> time decision? >> >> Not an OS choice. Historically, this has always been MMIO accessed but >> with v8.4 TraceFiltering support, CPUs are encouraged to use system >> instructions and obsolete MMIO. So, yes, MMIO is still possible but >> something that is discouraged and have to be decided at system >> integration time. >> >>> >>>> The CoreSight ETM4x platform >>>> driver can now handle both types of devices. In order to make sure the >>>> driver gets to handle the "MMIO based" devices, which always had the >>>> "arm,primecell" compatible, we have two options : >>>> >>>> 1) Remove the "arm,primecell" from the DTS. But this may be problematic >>>> for an older kernel without the support. >>>> >>>> 2) The other option is to allow OF code to "ignore" the arm,primecell >>>> priority for a selected list of compatibles. This would make sure that >>>> both older kernels and the new kernels work fine without breaking >>>> the functionality. The new DTS could always have the "arm,primecell" >>>> removed. >>> >>> 3) Drop patches 6 and 7 and just register as both AMBA and platform >>> drivers. It's just some extra boilerplate. I would also do different >>> compatible strings for CPU system instruction version (assuming this >>> is an integration time decision). >> >> The system instruction (and the reigster layouts) are all part of the >> ETMv4/ETE architecture and specific capabilities/features are >> discoverable, just like the Arm CPUs. Thus we don't need special >> versions within the ETMv4x or ETE minor versions. As of now, we have >> one for etm4x and another for ete. > > I just meant 2 new compatible strings. One each for ETMv4x and ETE, > but different from the 2 existing ones. It is different h/w presented > to the OS, so different compatible. > Sorry, was not very clear here. Right now, we have : 1) arm,coresight-etm4x && arm,primecell - For AMBA based devices 2) arm,coresight-etm4x-sysreg - For system instruction based 3) arm,embedded-trace-extension - For ETE >> One problem with the AMBA driver in place is having to keep on adding >> new PIDs for the CPUs. The other option is to have a blanket mask >> for matching the PIDs with AMBA_UCI_ID checks. > > But if MMIO access is discouraged, then new h/w would use the platform > driver(s), not the amba driver, and you won't have to add PIDs. Yes for v8.4 onwards. Alternatively, the newer DTS could skip arm,primecell in the entry and that would kick the platform driver in. So, that should be fine I guess. Kind regards Suzuki > > Rob

3 years

Re: [PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus

by Suzuki K Poulose

Hi Rob Thanks for your response. On 17/03/2023 14:52, Rob Herring wrote: > On Thu, Mar 16, 2023 at 10:06 PM Anshuman Khandual > <anshuman.khandual(a)arm.com> wrote: >> >> Allow other drivers to claim a device, disregarding the "priority" of >> "arm,primecell". e.g., CoreSight ETM4x devices could be accessed via MMIO >> (AMBA Bus) or via CPU system instructions. > > The OS can pick which one, use both, or this is a system integration > time decision? Not an OS choice. Historically, this has always been MMIO accessed but with v8.4 TraceFiltering support, CPUs are encouraged to use system instructions and obsolete MMIO. So, yes, MMIO is still possible but something that is discouraged and have to be decided at system integration time. > >> The CoreSight ETM4x platform >> driver can now handle both types of devices. In order to make sure the >> driver gets to handle the "MMIO based" devices, which always had the >> "arm,primecell" compatible, we have two options : >> >> 1) Remove the "arm,primecell" from the DTS. But this may be problematic >> for an older kernel without the support. >> >> 2) The other option is to allow OF code to "ignore" the arm,primecell >> priority for a selected list of compatibles. This would make sure that >> both older kernels and the new kernels work fine without breaking >> the functionality. The new DTS could always have the "arm,primecell" >> removed. > > 3) Drop patches 6 and 7 and just register as both AMBA and platform > drivers. It's just some extra boilerplate. I would also do different > compatible strings for CPU system instruction version (assuming this > is an integration time decision). The system instruction (and the reigster layouts) are all part of the ETMv4/ETE architecture and specific capabilities/features are discoverable, just like the Arm CPUs. Thus we don't need special versions within the ETMv4x or ETE minor versions. As of now, we have one for etm4x and another for ete. One problem with the AMBA driver in place is having to keep on adding new PIDs for the CPUs. The other option is to have a blanket mask for matching the PIDs with AMBA_UCI_ID checks. > >> >> This patch implements Option (2). >> >> Cc: Rob Herring <robh+dt(a)kernel.org> >> Cc: Frank Rowand <frowand.list(a)gmail.com> >> Cc: Russell King (Oracle) <linux(a)armlinux.org.uk> >> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> >> Cc: devicetree(a)vger.kernel.org >> Cc: linux-kernel(a)vger.kernel.org >> Co-developed-by: Suzuki Poulose <suzuki.poulose(a)arm.com> >> Signed-off-by: Suzuki Poulose <suzuki.poulose(a)arm.com> >> Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com> >> --- >> drivers/of/platform.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c >> index b2bd2e783445..59ff1a38ccaa 100644 >> --- a/drivers/of/platform.c >> +++ b/drivers/of/platform.c >> @@ -325,6 +325,13 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l >> return NULL; >> } >> >> +static const struct of_device_id of_ignore_amba_table[] = { >> +#ifdef CONFIG_CORESIGHT_SOURCE_ETM4X >> + { .compatible = "arm,coresight-etm4x" }, >> +#endif >> + {} /* NULL terminated */ >> +}; >> + >> /** >> * of_platform_bus_create() - Create a device for a node and its children. >> * @bus: device node of the bus to instantiate >> @@ -373,7 +380,8 @@ static int of_platform_bus_create(struct device_node *bus, >> platform_data = auxdata->platform_data; >> } >> >> - if (of_device_is_compatible(bus, "arm,primecell")) { >> + if (of_device_is_compatible(bus, "arm,primecell") && >> + unlikely(!of_match_node(of_ignore_amba_table, bus))) { > > of_match_node is going to take orders of magnitude longer than any > difference unlikely() would make. Drop it. Agreed. Suzuki > >> /* >> * Don't return an error here to keep compatibility with older >> * device tree files. >> -- >> 2.25.1 >>

3 years

[PATCH 0/7] coresight: etm4x: Migrate AMBA devices to platform driver

by Anshuman Khandual

CoreSight ETM4x devices could be accessed either via MMIO (handled via amba_driver) or CPU system instructions (handled via platform driver). But this has the following issues : - Each new CPU comes up with its own PID and thus we need to keep on adding the "known" PIDs to get it working with AMBA driver. While the ETM4 architecture (and CoreSight architecture) defines way to identify a device as ETM4. Thus older kernels won't be able to "discover" a newer CPU, unless we add the PIDs. - With ACPI, the ETM4x devices have the same HID to identify the device irrespective of the mode of access. This creates a problem where two different drivers (both AMBA based driver and platform driver) would hook into the "HID" and could conflict. e.g., if AMBA driver gets hold of a non-MMIO device, the probe fails. If we have single driver hooked into the given "HID", we could handle them seamlessly, irrespective of the mode of access. - CoreSight is heavily dependent on the runtime power management. With ACPI, amba_driver doesn't get us anywhere with handling the power and thus one need to always turn the power ON to use them. Moving to platform driver gives us the power management for free. Due to all of the above, we are moving the MMIO based etm4x devices to be supported via platform driver. The series makes the existing platform driver generic to handle both type of the access modes. With that we can also remove the etm4x amba driver. Finally, we need a way to make sure the new driver gets control of the ETM4x device on a DT based system. CoreSight devices have always had the "arm,primecell" in the compatible list. But the way this is handled currently in OF code is a bit messy. The ETM4x devices are identified by "arm,coresight-etm4x". The platform driver can never get a chance to probe these devices, since the "arm,primecell" takes priority and is hard-coded in the OF code. We have two options here : 1) Remove the arm,primecell from all DTS. This is fine for "new" kernels with this change. But, for existing boards, using an older kernel will break. Thus, is not preferred. 2) Add a white list of "compatibles" where the "priority" of the "arm,primecell" can be ignored. The series implements (2) above and applies on 6.3-rc2. Cc: Steve Clevenger <scclevenger(a)os.amperecomputing.com> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Cc: Russell King (Oracle) <linux(a)armlinux.org.uk> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael(a)kernel.org> Cc: Len Brown <lenb(a)kernel.org> Cc: Sudeep Holla <sudeep.holla(a)arm.com> Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: devicetree(a)vger.kernel.org Cc: linux-acpi(a)vger.kernel.org Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (6): coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier coresight: etm4x: Drop iomem 'base' argument from etm4_probe() coresight: etm4x: Drop pid argument from etm4_probe() coresight: etm4x: Change etm4_platform_driver driver for MMIO devices of/platform: Skip coresight etm4x devices from AMBA bus coresight: etm4x: Drop the AMBA driver Suzuki Poulose (1): coresight: etm4x: Add ACPI support in platform driver drivers/acpi/acpi_amba.c | 1 - .../coresight/coresight-etm4x-core.c | 171 ++++++++---------- drivers/hwtracing/coresight/coresight-etm4x.h | 3 + drivers/of/platform.c | 10 +- include/linux/coresight.h | 56 ++++++ 5 files changed, 143 insertions(+), 98 deletions(-) -- 2.25.1

3 years

Re: [PATCH 4/7] coresight: etm4x: Change etm4_platform_driver driver for MMIO devices

by Anshuman Khandual

On 3/18/23 15:54, kernel test robot wrote: > Hi Anshuman, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on robh/for-next] > [also build test WARNING on soc/for-next rafael-pm/linux-next linus/master v6.3-rc2 next-20230317] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Anshuman-Khandual/coresight-… > base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next > patch link: https://lore.kernel.org/r/20230317030501.1811905-5-anshuman.khandual%40arm.… > patch subject: [PATCH 4/7] coresight: etm4x: Change etm4_platform_driver driver for MMIO devices > config: arm64-buildonly-randconfig-r002-20230312 (https://download.01.org/0day-ci/archive/20230318/202303181800.KxbuwjRT-lkp@…) > compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project 67409911353323ca5edf2049ef0df54132fa1ca7) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # https://github.com/intel-lab-lkp/linux/commit/f02ad9e7f97ab4fc1f90c7e639900… > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Anshuman-Khandual/coresight-etm4x-Allocate-and-device-assign-struct-etmv4_drvdata-earlier/20230317-110755 > git checkout f02ad9e7f97ab4fc1f90c7e6399004e9ec89ef26 > # save the config file > mkdir build_dir && cp config build_dir/.config > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm64 olddefconfig > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/hwtracing/coresight/ > > If you fix the issue, kindly add following tag where applicable > | Reported-by: kernel test robot <lkp(a)intel.com> > | Link: https://lore.kernel.org/oe-kbuild-all/202303181800.KxbuwjRT-lkp@intel.com/ > > All warnings (new ones prefixed by >>): > >>> drivers/hwtracing/coresight/coresight-etm4x-core.c:2336:32: warning: unused variable 'etm4_dev_pm_ops' [-Wunused-const-variable] > static const struct dev_pm_ops etm4_dev_pm_ops = { These pm_ops needs to tagged along with the platform driver. diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 3ce2b4911a49..fe10dd91183e 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -2280,6 +2280,7 @@ static struct platform_driver etm4_platform_driver = { .of_match_table = etm4_match, .acpi_match_table = ACPI_PTR(etm4x_acpi_ids), .suppress_bind_attrs = true, + .pm = &etm4_dev_pm_ops, }, };

3 years

Re: [PATCH 3/7] coresight: etm4x: Drop pid argument from etm4_probe()

by Anshuman Khandual

On 3/18/23 13:51, kernel test robot wrote: > Hi Anshuman, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on robh/for-next] > [also build test WARNING on soc/for-next rafael-pm/linux-next linus/master v6.3-rc2 next-20230317] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Anshuman-Khandual/coresight-… > base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next > patch link: https://lore.kernel.org/r/20230317030501.1811905-4-anshuman.khandual%40arm.… > patch subject: [PATCH 3/7] coresight: etm4x: Drop pid argument from etm4_probe() > config: arm64-randconfig-r021-20230312 (https://download.01.org/0day-ci/archive/20230318/202303181632.wBUDE5wa-lkp@…) > compiler: aarch64-linux-gcc (GCC) 12.1.0 > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://github.com/intel-lab-lkp/linux/commit/39e224e4248f0f7b2c59b97c12a12… > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Anshuman-Khandual/coresight-etm4x-Allocate-and-device-assign-struct-etmv4_drvdata-earlier/20230317-110755 > git checkout 39e224e4248f0f7b2c59b97c12a12f8343ab900e > # save the config file > mkdir build_dir && cp config build_dir/.config > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm64 olddefconfig > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/hwtracing/coresight/ > > If you fix the issue, kindly add following tag where applicable > | Reported-by: kernel test robot <lkp(a)intel.com> > | Link: https://lore.kernel.org/oe-kbuild-all/202303181632.wBUDE5wa-lkp@intel.com/ > > All warnings (new ones prefixed by >>): > > drivers/hwtracing/coresight/coresight-etm4x-core.c: In function 'etm4_init_arch_data': >>> drivers/hwtracing/coresight/coresight-etm4x-core.c:1169:43: warning: passing argument 2 of 'etm4_check_arch_features' makes integer from pointer without a cast [-Wint-conversion] > 1169 | etm4_check_arch_features(drvdata, csa); > | ^~~ > | | > | struct csdev_access * > drivers/hwtracing/coresight/coresight-etm4x-core.c:389:51: note: expected 'unsigned int' but argument is of type 'struct csdev_access *' > 389 | unsigned int id) > | ~~~~~~~~~~~~~^~ Fallback stub's signature also needs an update. I will fold this change in next series. --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -388,7 +388,7 @@ static void etm4_disable_arch_specific(struct etmv4_drvdata *drvdata) } static void etm4_check_arch_features(struct etmv4_drvdata *drvdata, - unsigned int id) + struct csdev_access *csa) { } #endif /* CONFIG_ETM4X_IMPDEF_FEATURE */

3 years

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

by Suzuki K Poulose

Hi Steve On 06/03/2023 05:54, Steve Clevenger wrote: > An Ampere Computing design decision is MMIO reads are considered the > same as an external debug access. If TRCOSLAR.OSLK is left set, the > TRCIDR1 access results in a bus fault followed by a kernel panic. A > TRCIDR1 read should be valid regardless of TRCOSLAR.OSLK provided MMIO > access (now deprecated) is supported. > > The Ampere work around is to early clear ETM TRCOSLAR.OSLK prior to > TRCIDR1 access. Do not distinguish between manufacturers. > AC03_DEBUG_06 is described in the AmpereOne Developer Errata: > > Add Ampere ETM PID required for Coresight ETM driver support. > > https://solutions.amperecomputing.com/customer-connect/products/AmpereOne-d… > > Signed-off-by: Steve Clevenger <scclevenger(a)os.amperecomputing.com> I went back to the CoreSight ETM4x architecture and this is not an erratum at your end. This is actually a bug in the ETMv4 driver. TRCIDR1 is part of the "Trace" and not "Management" registers of ETMv4. Access to "Trace" registers without OSLK is going to cause issues. (Un)Fortunately, we never hit this on existing systems, but that doesn't mean it can stay there. So we should really fix our detection and only rely on accessing the TRCDEVARCH to detect the device to be ETMv4. I have a sent out the fix here [0], are you able to test it : [0] https://lkml.kernel.org/r/20230317115728.1358368-1-suzuki.poulose@arm.com Suzuki

3 years

[PATCH] coresight: core: Add sysfs node to reset all sources and sinks

by Mao Jinlong

Add sysfs node to reset all the sources and sinks. When mltiple sources are enabled, write 1 to reset_source_sink node to disable all sources and sinks. Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> --- drivers/hwtracing/coresight/coresight-core.c | 106 +++++++++++++++++-- 1 file changed, 99 insertions(+), 7 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c index d3bf82c0de1d..06741ed2dee7 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -458,6 +458,28 @@ static bool coresight_disable_source(struct coresight_device *csdev) return !csdev->enable; } +/** + * coresight_get_source - Get the source from the path + * + * @path: The list of devices. + * + * Returns the soruce csdev. + * + */ +static struct coresight_device *coresight_get_source(struct list_head *path) +{ + struct coresight_device *csdev; + + if (!path) + return NULL; + + csdev = list_first_entry(path, struct coresight_node, link)->csdev; + if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) + return NULL; + + return csdev; +} + /* * coresight_disable_path_from : Disable components in the given path beyond * @nd in the list. If @nd is NULL, all the components, except the SOURCE are @@ -1159,20 +1181,18 @@ int coresight_enable(struct coresight_device *csdev) } EXPORT_SYMBOL_GPL(coresight_enable); -void coresight_disable(struct coresight_device *csdev) +static void _coresight_disable(struct coresight_device *csdev) { int cpu, ret; struct list_head *path = NULL; u32 hash; - mutex_lock(&coresight_mutex); - ret = coresight_validate_source(csdev, __func__); if (ret) - goto out; + return; if (!csdev->enable || !coresight_disable_source(csdev)) - goto out; + return; switch (csdev->subtype.source_subtype) { case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC: @@ -1187,7 +1207,7 @@ void coresight_disable(struct coresight_device *csdev) path = idr_find(&path_idr, hash); if (path == NULL) { pr_err("Path is not found for %s\n", dev_name(&csdev->dev)); - goto out; + return; } idr_remove(&path_idr, hash); break; @@ -1198,8 +1218,12 @@ void coresight_disable(struct coresight_device *csdev) coresight_disable_path(path); coresight_release_path(path); +} -out: +void coresight_disable(struct coresight_device *csdev) +{ + mutex_lock(&coresight_mutex); + _coresight_disable(csdev); mutex_unlock(&coresight_mutex); } EXPORT_SYMBOL_GPL(coresight_disable); @@ -1761,8 +1785,76 @@ char *coresight_alloc_device_name(struct coresight_dev_list *dict, } EXPORT_SYMBOL_GPL(coresight_alloc_device_name); +/* + * Set the sink active status to false. + */ +static int coresight_reset_sink(struct device *dev, void *data) +{ + struct coresight_device *csdev = to_coresight_device(dev); + + if ((csdev->type == CORESIGHT_DEV_TYPE_SINK || + csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) && + csdev->activated) + csdev->activated = false; + + return 0; +} + +static void coresight_reset_all_sink(void) +{ + bus_for_each_dev(&coresight_bustype, NULL, NULL, coresight_reset_sink); +} + +static ssize_t reset_source_sink_store(struct bus_type *bus, + const char *buf, size_t size) +{ + int id, cpu, ret = 0; + unsigned long val; + struct coresight_device *csdev; + struct list_head *path = NULL; + + ret = kstrtoul(buf, 10, &val); + if (ret) + return ret; + + mutex_lock(&coresight_mutex); + + /* Disable all per cpu sources */ + for_each_present_cpu(cpu) { + path = per_cpu(tracer_path, cpu); + if (path) { + csdev = coresight_get_source(path); + if (!csdev) + continue; + } + _coresight_disable(csdev); + } + + /* Disable all sources which aren't associated with CPU */ + idr_for_each_entry (&path_idr, path, id) { + csdev = coresight_get_source(path); + if (!csdev) + continue; + + _coresight_disable(csdev); + } + /* Reset all activated sinks */ + coresight_reset_all_sink(); + + mutex_unlock(&coresight_mutex); + return size; +} +static BUS_ATTR_WO(reset_source_sink); + +static struct attribute *coresight_reset_source_sink_attrs[] = { + &bus_attr_reset_source_sink.attr, + NULL, +}; +ATTRIBUTE_GROUPS(coresight_reset_source_sink); + struct bus_type coresight_bustype = { .name = "coresight", + .bus_groups = coresight_reset_source_sink_groups, }; static int __init coresight_init(void) -- 2.39.0

3 years

[RESEND PATCH] perf cs-etm: add error logging to cs_etm_is_etmv4()

by Junhao He

On the HiSilicon platform, there is one ETM per logic core. When setting up SMT, not every process has an ETM. So the path ".../cs_etm/cpux/trcidr/trcidr0" does not exist, the function perf_pmu__scan_file() return an error. However, the command 'perf record' will returns silently and don't print. After this patch, log a error when read fails that makes it easy for users to debug. root@localhost:/# perf record -e /cs_etm/@ultra_smb0/ -C 3 uname -a cs_etm: can't read file cpu3/trcidr/trcidr0 root@localhost:/# Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- tools/perf/arch/arm/util/cs-etm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c index 7f71c8a237ff..19ea17430399 100644 --- a/tools/perf/arch/arm/util/cs-etm.c +++ b/tools/perf/arch/arm/util/cs-etm.c @@ -585,7 +585,6 @@ cs_etm_info_priv_size(struct auxtrace_record *itr __maybe_unused, static bool cs_etm_is_etmv4(struct auxtrace_record *itr, int cpu) { - bool ret = false; char path[PATH_MAX]; int scan; unsigned int val; @@ -600,9 +599,10 @@ static bool cs_etm_is_etmv4(struct auxtrace_record *itr, int cpu) /* The file was read successfully, we have a winner */ if (scan == 1) - ret = true; + return true; - return ret; + pr_err("%s: can't read file %s\n", CORESIGHT_ETM_PMU_NAME, path); + return false; } static int cs_etm_get_ro(struct perf_pmu *pmu, int cpu, const char *path) -- 2.33.0

3 years

Re: [PATCH v1 0/3] Add support to configure Coresight Dummy subunit

by Suzuki K Poulose

On 16/03/2023 03:20, Hao Zhang wrote: > Introduction of Coresight Dummy subunit > The Coresight Dummy subunit is for Coresight Dummy component, there are some > specific Coresight devices that HLOS don't have permission to access. Such as What is HLOS ? > some TPDMs, they would be configured in NON-HLOS side, but it's necessary to What is NON-HLOS ? > build Coresight path for it to debug. So there need driver to register dummy > devices as Coresight devices. Build a path for who to debug ? If this is used by some privileged software, shouldn't that do all of the work ? Suzuki > > Commit link: > https://git.codelinaro.org/clo/linux-kernel/coresight/-/tree/coresight-dummy > > Hao Zhang (3): > Coresight: Add coresight dummy driver > dt-bindings: arm: Add Coresight Dummy Trace YAML schema > Documentation: trace: Add documentation for Coresight Dummy Trace > > .../bindings/arm/qcom,coresight-dummy.yaml | 129 +++++++++++++ > .../trace/coresight/coresight-dummy.rst | 58 ++++++ > drivers/hwtracing/coresight/Kconfig | 11 ++ > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-dummy.c | 176 ++++++++++++++++++ > 5 files changed, 375 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > create mode 100644 Documentation/trace/coresight/coresight-dummy.rst > create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c >

3 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight