CoreSight

coresight@lists.linaro.org

5 participants
2698 discussions

by info11＠foescoformacion.net

Buenos días Desde FOESCO (Formación Estatal Continua) estamos informando a todas las empresas españolas acerca de los Cursos Bonificables disponibles para empleados en activo o en situación de ERTE. Todos los cursos impartidos son bonificables con cargo al Crédito de Formación 2021. Rogamos nos respondan a este mismo correo electrónico eligiendo una de las opciones que a continuación indicamos: 1 - Precisamos información para la PRESENTE convocatoria ABRIL 2021. 2 - Precisamos información para la convocatoria del mes de JUNIO 2021. 3 - Precisamos información para la convocatoria del mes de SEPTIEMBRE 2021. 4 - Precisamos información para la ÚLTIMA convocatoria NOVIEMBRE 2021. 5 - Precisamos información para el año 2022. 6 - No precisamos ninguna información BAJA (AVISO: Indicando esta opción tenga en cuenta que no volverá a recibir ninguna información en un futuro) Recordamos que el Crédito de Formación únicamente puede utilizarse en el mismo año en curso. Quedamos a la espera de su respuesta. Un cordial saludo. Alex Pons. Director FOESCO. FOESCO Formación Estatal Continua e-mail: cursos(a)foesco.net Tel.: 91 032 37 94 (Horario de 9h a 14h y de 16:30h a 21h de Lunes a Viernes) FOESCO ofrece formación a empresas y trabajadores en activo a través de cursos bonificables por la Fundación Estatal para la Formación en el Empleo (antiguo FORCEM) que gestiona las acciones formativas de FORMACIÓN CONTINUA para trabajadores y se rige por la ley 30/2015 de 9 de Septiembre. Antes de imprimir este e-mail piense bien si es necesario hacerlo. Before printing this e-mail please think twice if you really need it. FOESCO Tfno: 910 382 880 Email: cursos(a)foesco.com. La información transmitida en este mensaje está dirigida solamente a las personas o entidades que figuran en el encabezamiento y contiene información confidencial, por lo que, si usted lo recibiera por error, por favor destrúyalo sin copiarlo, usarlo ni distribuirlo, comunicándolo inmediatamente al emisor del mensaje. De conformidad con lo dispuesto en el Reglamento Europeo del 2016/679, del 27 de Abril de 2016, FOESCO le informa que los datos por usted suministrados serán tratados con las medidas de seguridad conformes a la normativa vigente que se requiere. Dichos datos serán empleados con fines de gestión. Para el ejercicio de sus derechos de transparencia, información, acceso, rectificación, supresión o derecho al olvido, limitación del tratamiento , portabilidad de datos y oposición de sus datos de carácter personal deberá dirigirse a la dirección del Responsable del tratamiento a C/ LAGUNA DEL MARQUESADO Nº10, 28021, MADRID, "PULSANDO AQUI" <mailto:bajas@foesco.com?Subject=BAJA%20CORREOS> y "ENVIAR" o a través de la dirección de correo electrónico: bajas(a)foesco.com <mailto:bajas@foesco.com?Subject=BAJA%20CORREOS>

5 years

[PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace device

by Yicong Yang

[RESEND with perf and coresight folks Cc'ed] HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex integrated Endpoint (RCiEP) device, providing the capability to dynamically monitor and tune the PCIe traffic (tune), and trace the TLP headers (trace). PTT tune is designed for monitoring and adjusting PCIe link parameters. We provide several parameters of the PCIe link. Through the driver, user can adjust the value of certain parameter to affect the PCIe link for the purpose of enhancing the performance in certian situation. PTT trace is designed for dumping the TLP headers to the memory, which can be used to analyze the transactions and usage condition of the PCIe Link. Users can choose filters to trace headers, by either requester ID, or those downstream of a set of Root Ports on the same core of the PTT device. It's also supported to trace the headers of certain type and of certain direction. We use debugfs to expose the interface. For tune, one parameter is a debugfs file and user can set/get the value by reading/writing the file. For trace, we have several control files for the user to configure the trace parameters like filters, TLP type and format, the desired trace data size and so on. There is one data file for dumping the traced data to the user. The traced data maybe hundreds of megabytes so sysfs cannot support. The reason for debugfs rather than character device is that we don't want to have additional userspace tools. The operation through debugfs is easier and a bit like ftrace. The reason for not using perf is because there is no current support for uncore tracing in the perf facilities. We have our own format of data and don't need perf doing the parsing. The setting through perf tools doesn't seem to be friendly as well. For example, we cannot count on perf to decode the usual format BDF number like <domain>:<bus>:<dev>.<fn>, which user can use to filter the TLP headers through the PTT device. A similar approach for implementing this function is ETM, which use sysfs for configuring and a character device for dumping data. Greg has some comments on our implementation and doesn't advocate to build driver on debugfs [1]. So I resend this series to collect more feedbacks on the implementation of this driver. Hi perf and ETM related experts, is it suggested to adapt this driver to perf? Or is the debugfs approach acceptable? Otherwise use sysfs + character device like ETM and use perf tools for decoding it? Any comments is welcomed. [1] https://lore.kernel.org/linux-pci/1617713154-35533-1-git-send-email-yangyic… Yicong Yang (4): hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device hwtracing: Add tune function support for HiSilicon PCIe Tune and Trace device docs: Add HiSilicon PTT device driver documentation MAINTAINERS: Add maintainer for HiSilicon PTT driver Documentation/trace/hisi-ptt.rst | 326 +++++++ MAINTAINERS | 7 + drivers/Makefile | 1 + drivers/hwtracing/Kconfig | 2 + drivers/hwtracing/hisilicon/Kconfig | 11 + drivers/hwtracing/hisilicon/Makefile | 2 + drivers/hwtracing/hisilicon/hisi_ptt.c | 1636 ++++++++++++++++++++++++++++++++ 7 files changed, 1985 insertions(+) create mode 100644 Documentation/trace/hisi-ptt.rst create mode 100644 drivers/hwtracing/hisilicon/Kconfig create mode 100644 drivers/hwtracing/hisilicon/Makefile create mode 100644 drivers/hwtracing/hisilicon/hisi_ptt.c -- 2.8.1

5 years

Disposable Vape pen bars

by Simon

5 years

Disposable Vape pen bars

by Simon

5 years

Formación Bonificable para empleados en activo o ERTE

by info22＠foescoformacion.com

5 years

[PATCH v2 0/2] perf cs-etm: Set time on synthesised samples to preserve ordering

by James Clark

Changes since v1: * Improved variable name from etm_timestamp -> cs_timestamp * Fixed ordering of Signed-off-by James Clark (2): perf cs-etm: Refactor timestamp variable names perf cs-etm: Set time on synthesised samples to preserve ordering .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +++---- tools/perf/util/cs-etm.c | 52 ++++++++++--------- tools/perf/util/cs-etm.h | 4 +- 3 files changed, 39 insertions(+), 35 deletions(-) -- 2.28.0

5 years

[PATCH v5 00/19] coresight: Add support for ETE and TRBE

by Suzuki K Poulose

This series enables future IP trace features Embedded Trace Extension (ETE) and Trace Buffer Extension (TRBE). This series applies on v5.12-rc4 + some patches queued. A standalone tree is also available here [0]. The queued patches (almost there) are included in this posting for the sake of constructing a tree from the posting. ETE is the PE (CPU) trace unit for CPUs, implementing future architecture extensions. ETE overlaps with the ETMv4 architecture, with additions to support the newer architecture features and some restrictions on the supported features w.r.t ETMv4. The ETE support is added by extending the ETMv4 driver to recognise the ETE and handle the features as exposed by the TRCIDRx registers. ETE only supports system instructions access from the host CPU. The ETE could be integrated with a TRBE (see below), or with the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same firmware description as the ETMs and requires a node per instance. Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which is accessible via the system registers and can be combined with the ETE to provide a 1x1 configuration of source & sink. TRBE is being represented here as a CoreSight sink. Primary reason is that the ETE source could work with other traditional CoreSight sink devices. As TRBE captures the trace data which is produced by ETE, it cannot work alone. TRBE representation here have some distinct deviations from a traditional CoreSight sink device. Coresight path between ETE and TRBE are not built during boot looking at respective DT or ACPI entries. Unlike traditional sinks, TRBE can generate interrupts to signal including many other things, buffer got filled. The interrupt is a PPI and should be communicated from the platform. DT or ACPI entry representing TRBE should have the PPI number for a given platform. During perf session, the TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting it back. System registers being used here to configure ETE and TRBE could be referred in the link below. https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers. [0] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/ete/v5/ Changes since V4: https://lkml.kernel.org/r/20210225193543.2920532-1-suzuki.poulose@arm.com - Split the documentation patches from the TRBE driver - Drop the patches already queued for v5.12. - Mark the buffer TRUNCATED in case of a WRAP event - Fix error code for vmap failure - Fix build break on arm32 for per-cpu sink patch - Address comments on ETE dts bindings. - Make ete_sysreg_read/write static (kernel test robot) - Merged ete sysreg definition patch with ete support, to avoid a "defined but unused warning" on build in part of the series. - Add new bindings to MAINTAINERS Changes since V3: https://lore.kernel.org/linux-arm-kernel/1611737738-1493-1-git-send-email-a… - ETE and TRBE changes have been captured in the respective patches - Better support for nVHE - Re-ordered and splitted the patches to keep the changes separate for the generic/arm64 tree from CoreSight driver specific changes. - Fixes for KVM handling of Trace/SPE Changes since V2: https://lore.kernel.org/linux-arm-kernel/1610511498-4058-1-git-send-email-a… - Rebased on coresight/next - Changed DT bindings for ETE - Included additional patches for arm64 nvhe, perf aux buffer flags etc - TRBE changes have been captured in the respective patches Changes since V1: https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-… - Converted both ETE and TRBE DT bindings into Yaml - TRBE changes have been captured in the respective patches Changes since RFC: - There are not much ETE changes from Suzuki apart from splitting of the ETE DTS patch - TRBE changes have been captured in the respective patches RFC: https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-… Cc: Will Deacon <will(a)kernel.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Peter Zilstra <peterz(a)infradead.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: Linu Cherian <lcherian(a)marvell.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (5): arm64: Add TRBE definitions coresight: core: Add support for dedicated percpu sinks coresight: sink: Add TRBE driver Documentation: coresight: trbe: Sysfs ABI description Documentation: trace: Add documentation for TRBE Suzuki K Poulose (14): [Queued] kvm: arm64: Hide system instruction access to Trace registers [Queued] kvm: arm64: Disable guest access to trace filter controls perf: aux: Add flags for the buffer format perf: aux: Add CoreSight PMU buffer formats arm64: Add support for trace synchronization barrier arm64: kvm: Enable access to TRBE support for host coresight: etm4x: Move ETM to prohibited region for disable coresight: etm-perf: Allow an event to use different sinks coresight: Do not scan for graph if none is present coresight: etm4x: Add support for PE OS lock coresight: ete: Add support for ETE tracing dts: bindings: Document device tree bindings for ETE coresight: etm-perf: Handle stale output handles dts: bindings: Document device tree bindings for Arm TRBE .../testing/sysfs-bus-coresight-devices-trbe | 14 + .../devicetree/bindings/arm/ete.yaml | 75 ++ .../devicetree/bindings/arm/trbe.yaml | 49 + .../trace/coresight/coresight-trbe.rst | 38 + MAINTAINERS | 2 + arch/arm64/include/asm/barrier.h | 1 + arch/arm64/include/asm/el2_setup.h | 13 + arch/arm64/include/asm/kvm_arm.h | 3 + arch/arm64/include/asm/kvm_host.h | 2 + arch/arm64/include/asm/sysreg.h | 50 + arch/arm64/kernel/cpufeature.c | 1 - arch/arm64/kernel/hyp-stub.S | 3 +- arch/arm64/kvm/debug.c | 6 +- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 + arch/arm64/kvm/hyp/nvhe/switch.c | 1 + drivers/hwtracing/coresight/Kconfig | 24 +- drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 +- .../hwtracing/coresight/coresight-etm-perf.c | 119 +- .../coresight/coresight-etm4x-core.c | 161 ++- .../coresight/coresight-etm4x-sysfs.c | 19 +- drivers/hwtracing/coresight/coresight-etm4x.h | 83 +- .../hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-priv.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 1157 +++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 152 +++ include/linux/coresight.h | 13 + include/uapi/linux/perf_event.h | 13 +- 28 files changed, 2016 insertions(+), 64 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml create mode 100644 Documentation/trace/coresight/coresight-trbe.rst create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h -- 2.24.1

5 years

Re: [PATCH v1 2/2] dt-bindings: arm: add property for coresight component name

by taozha＠codeaurora.org

On 2021-04-16 19:23, Alexander Shishkin wrote: > Tao Zhang <taozha(a)codeaurora.org> writes: > >> Add property "coresight-name" for coresight component name. This >> allows coresight driver to read device name from device entries. >> >> Signed-off-by: Tao Zhang <taozha(a)codeaurora.org> >> --- >> Documentation/devicetree/bindings/arm/coresight.txt | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt >> b/Documentation/devicetree/bindings/arm/coresight.txt >> index d711676..0e980ce 100644 >> --- a/Documentation/devicetree/bindings/arm/coresight.txt >> +++ b/Documentation/devicetree/bindings/arm/coresight.txt >> @@ -103,6 +103,8 @@ its hardware characteristcs. >> powers down the coresight component also powers down and loses its >> context. This property is currently only used for the ETM 4.x >> driver. >> >> + * coresight-name: the name of the coresight devices. > > Which devices? Also, is it a common practice to extend device tree > definitions based on arbitrary driver needs, or should there be some > sort of a discussion first? > > Regards, > -- > Alex Through the device tree entries, we can define their own name for any coresight device. This design is mainly used to facilitate the unified naming of coresight devgies across targets. e.g, without this patch, we can only see from sysFS there are multiple funnels, but we cannot know which funnel it is based on their names from sysFS. After applying this patch, we can directly know what device it is by observing the device name in sysFS. And the common scripts can be developed, since applying this patch, the same coresight device can have the same name across targets. Each developer or vendor can define the name of each coresight device according to their preferences and products. Tao

5 years

[PATCH 0/2] *** SUBJECT HERE ***

by Tao Zhang

*** BLURB HERE *** Tao Zhang (2): coresight: Add support for device names dt-bindings: arm: add property for coresight component name Documentation/devicetree/bindings/arm/coresight.txt | 2 ++ drivers/hwtracing/coresight/coresight-core.c | 6 ++++++ 2 files changed, 8 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

5 years

[PATCH] coresight: add support to enable more coresight paths

by Tao Zhang

Current coresight implementation only supports enabling source ETMs or STM. This patch adds support to enable more kinds of coresight source to sink paths. We build a path from source to sink when any source is enabled and store it in a list. When the source is disabled, we fetch the corresponding path from the list and decrement the refcount on each device in the path. The device is disabled if the refcount reaches zero. Don't store path to coresight data structure of source to avoid unnecessary change to ABI. Since some targets may have coresight sources other than STM and ETMs, we need to add this change to support these coresight devices. Signed-off-by: Satyajit Desai <sadesai(a)codeaurora.org> Signed-off-by: Rama Aparna Mallavarapu <aparnam(a)codeaurora.org> Signed-off-by: Mulu He <muluhe(a)codeaurora.org> Signed-off-by: Tingwei Zhang <tingwei(a)codeaurora.org> Signed-off-by: Tao Zhang <taozha(a)codeaurora.org> --- drivers/hwtracing/coresight/coresight-core.c | 101 +++++++++++++++------------ 1 file changed, 56 insertions(+), 45 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c index 4ba801d..7dfadb6 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -35,18 +35,16 @@ struct coresight_node { }; /* - * When operating Coresight drivers from the sysFS interface, only a single - * path can exist from a tracer (associated to a CPU) to a sink. + * struct coresight_path - path from source to sink + * @path: Address of path list. + * @link: hook to the list. */ -static DEFINE_PER_CPU(struct list_head *, tracer_path); +struct coresight_path { + struct list_head *path; + struct list_head link; +}; -/* - * As of this writing only a single STM can be found in CS topologies. Since - * there is no way to know if we'll ever see more and what kind of - * configuration they will enact, for the time being only define a single path - * for STM. - */ -static struct list_head *stm_path; +static LIST_HEAD(cs_active_paths); /* * When losing synchronisation a new barrier packet needs to be inserted at the @@ -326,7 +324,7 @@ static void coresight_disable_sink(struct coresight_device *csdev) if (ret) return; coresight_control_assoc_ectdev(csdev, false); - csdev->enable = false; + csdev->activated = false; } static int coresight_enable_link(struct coresight_device *csdev, @@ -562,6 +560,20 @@ int coresight_enable_path(struct list_head *path, u32 mode, void *sink_data) goto out; } +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; +} + struct coresight_device *coresight_get_sink(struct list_head *path) { struct coresight_device *csdev; @@ -1047,9 +1059,23 @@ static int coresight_validate_source(struct coresight_device *csdev, return 0; } +static int coresight_store_path(struct list_head *path) +{ + struct coresight_path *node; + + node = kzalloc(sizeof(struct coresight_path), GFP_KERNEL); + if (!node) + return -ENOMEM; + + node->path = path; + list_add(&node->link, &cs_active_paths); + + return 0; +} + int coresight_enable(struct coresight_device *csdev) { - int cpu, ret = 0; + int ret = 0; struct coresight_device *sink; struct list_head *path; enum coresight_dev_subtype_source subtype; @@ -1094,25 +1120,9 @@ int coresight_enable(struct coresight_device *csdev) if (ret) goto err_source; - switch (subtype) { - case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC: - /* - * When working from sysFS it is important to keep track - * of the paths that were created so that they can be - * undone in 'coresight_disable()'. Since there can only - * be a single session per tracer (when working from sysFS) - * a per-cpu variable will do just fine. - */ - cpu = source_ops(csdev)->cpu_id(csdev); - per_cpu(tracer_path, cpu) = path; - break; - case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE: - stm_path = path; - break; - default: - /* We can't be here */ - break; - } + ret = coresight_store_path(path); + if (ret) + goto err_source; out: mutex_unlock(&coresight_mutex); @@ -1129,8 +1139,11 @@ EXPORT_SYMBOL_GPL(coresight_enable); void coresight_disable(struct coresight_device *csdev) { - int cpu, ret; + int ret; struct list_head *path = NULL; + struct coresight_path *cspath = NULL; + struct coresight_path *cspath_next = NULL; + struct coresight_device *src_csdev = NULL; mutex_lock(&coresight_mutex); @@ -1141,20 +1154,18 @@ void coresight_disable(struct coresight_device *csdev) if (!csdev->enable || !coresight_disable_source(csdev)) goto out; - switch (csdev->subtype.source_subtype) { - case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC: - cpu = source_ops(csdev)->cpu_id(csdev); - path = per_cpu(tracer_path, cpu); - per_cpu(tracer_path, cpu) = NULL; - break; - case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE: - path = stm_path; - stm_path = NULL; - break; - default: - /* We can't be here */ - break; + list_for_each_entry_safe(cspath, cspath_next, &cs_active_paths, link) { + src_csdev = coresight_get_source(cspath->path); + if (!src_csdev) + continue; + if (src_csdev == csdev) { + path = cspath->path; + list_del(&cspath->link); + kfree(cspath); + } } + if (path == NULL) + goto out; coresight_disable_path(path); coresight_release_path(path); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

5 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight