CoreSight March 2023

coresight@lists.linaro.org

10 participants
48 discussions

Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver

by Suzuki K Poulose

On 28/03/2023 12:25, Hao Zhang wrote: > Hi Mike, > > On 3/28/2023 6:06 PM, Mike Leach wrote: >> Hi, >> >> A few additional comments.... >> >> On Tue, 28 Mar 2023 at 10:24, Hao Zhang <quic_hazha(a)quicinc.com> wrote: >>> >>> Hi Suzuki, >>> >>> On 3/28/2023 4:35 PM, Suzuki K Poulose wrote: >>>> On 28/03/2023 08:22, Hao Zhang wrote: >>>>> Hi Mike, >>>>> >>>>> On 3/27/2023 11:58 PM, Mike Leach wrote: >>>>>> Hi, >>>>>> >>>>>> On Fri, 24 Mar 2023 at 06:16, Hao Zhang <quic_hazha(a)quicinc.com> >>>>>> wrote: >>>>>>> >>>>>>> Some Coresight devices that HLOS don't have permission to access >>>>>>> or configure. Such as Coresight sink EUD, some TPDMs etc. So there >>>>>>> need driver to register dummy devices as Coresight devices. Provide >>>>>>> Coresight API for dummy device operations, such as enabling and >>>>>>> disabling dummy devices. Build the Coresight path for dummy sink or >>>>>>> dummy source for debugging. >>>>>>> >>>>>>> Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> >>>>>>> --- >>>>>>> drivers/hwtracing/coresight/Kconfig | 11 ++ >>>>>>> drivers/hwtracing/coresight/Makefile | 1 + >>>>>>> drivers/hwtracing/coresight/coresight-dummy.c | 176 >>>>>>> ++++++++++++++++++ >>>>>>> 3 files changed, 188 insertions(+) >>>>>>> create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> >>>>>>> diff --git a/drivers/hwtracing/coresight/Kconfig >>>>>>> b/drivers/hwtracing/coresight/Kconfig >>>>>>> index 2b5bbfffbc4f..06f0a7594169 100644 >>>>>>> --- a/drivers/hwtracing/coresight/Kconfig >>>>>>> +++ b/drivers/hwtracing/coresight/Kconfig >>>>>>> @@ -236,4 +236,15 @@ config CORESIGHT_TPDA >>>>>>> >>>>>>> To compile this driver as a module, choose M here: the >>>>>>> module will be >>>>>>> called coresight-tpda. >>>>>>> + >>>>>>> +config CORESIGHT_DUMMY >>>>>>> + tristate "Dummy driver support" >>>>>>> + help >>>>>>> + Enables support for dummy driver. Dummy driver can be used >>>>>>> for >>>>>>> + CoreSight sources/sinks that are owned and configured >>>>>>> by some >>>>>>> + other subsystem and use Linux drivers to configure rest of >>>>>>> trace >>>>>>> + path. >>>>>>> + >>>>>>> + To compile this driver as a module, choose M here: the >>>>>>> module will be >>>>>>> + called coresight-dummy. >>>>>>> endif >>>>>>> diff --git a/drivers/hwtracing/coresight/Makefile >>>>>>> b/drivers/hwtracing/coresight/Makefile >>>>>>> index 33bcc3f7b8ae..995d3b2c76df 100644 >>>>>>> --- a/drivers/hwtracing/coresight/Makefile >>>>>>> +++ b/drivers/hwtracing/coresight/Makefile >>>>>>> @@ -30,3 +30,4 @@ obj-$(CONFIG_CORESIGHT_TPDA) += coresight-tpda.o >>>>>>> coresight-cti-y := coresight-cti-core.o >>>>>>> coresight-cti-platform.o \ >>>>>>> coresight-cti-sysfs.o >>>>>>> obj-$(CONFIG_ULTRASOC_SMB) += ultrasoc-smb.o >>>>>>> +obj-$(CONFIG_CORESIGHT_DUMMY) += coresight-dummy.o >>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> b/drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> new file mode 100644 >>>>>>> index 000000000000..2d4eb3e546eb >>>>>>> --- /dev/null >>>>>>> +++ b/drivers/hwtracing/coresight/coresight-dummy.c >>>>>>> @@ -0,0 +1,176 @@ >>>>>>> +// SPDX-License-Identifier: GPL-2.0 >>>>>>> +/* >>>>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights >>>>>>> reserved. >>>>>>> + */ >>>>>>> + >>>>>>> +#include <linux/kernel.h> >>>>>>> +#include <linux/module.h> >>>>>>> +#include <linux/platform_device.h> >>>>>>> +#include <linux/coresight.h> >>>>>>> +#include <linux/of.h> >>>>>>> +#include <linux/pm_runtime.h> >>>>>>> + >>>>>>> +#include "coresight-priv.h" >>>>>>> +#include "coresight-trace-id.h" >>>>>>> + >>>>>>> +struct dummy_drvdata { >>>>>>> + struct device *dev; >>>>>>> + struct coresight_device *csdev; >>>>>>> + int traceid; >>>>>>> +}; >>>>>>> + >>>>>>> +DEFINE_CORESIGHT_DEVLIST(dummy_devs, "dummy"); >>>>>>> + >> >> minor nit: can we have dummy_source and dummy_sink as the device names >> to make it clear at the first level what these are without having to >> look at the attributes? >> > > This is a good advice, dummy_source and dummy_sink are two different > components, so it's better to separate it at the first level. I will > take your advice in the next version of patch. > >>>>>>> +static int dummy_source_enable(struct coresight_device *csdev, >>>>>>> + struct perf_event *event, u32 mode) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy source enabled\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static void dummy_source_disable(struct coresight_device *csdev, >>>>>>> + struct perf_event *event) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy source disabled\n"); >>>>>>> +} >>>>>>> + >>>>>>> +static int dummy_sink_enable(struct coresight_device *csdev, u32 >>>>>>> mode, >>>>>>> + void *data) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy sink enabled\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static int dummy_sink_disable(struct coresight_device *csdev) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = >>>>>>> dev_get_drvdata(csdev->dev.parent); >>>>>>> + >>>>>>> + dev_info(drvdata->dev, "Dummy sink disabled\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static const struct coresight_ops_source dummy_source_ops = { >>>>>>> + .enable = dummy_source_enable, >>>>>>> + .disable = dummy_source_disable, >>>>>>> +}; >>>>>>> + >>>>>>> +static const struct coresight_ops_sink dummy_sink_ops = { >>>>>>> + .enable = dummy_sink_enable, >>>>>>> + .disable = dummy_sink_disable, >>>>>>> +}; >>>>>>> + >>>>>>> +static const struct coresight_ops dummy_cs_ops = { >>>>>>> + .source_ops = &dummy_source_ops, >>>>>>> + .sink_ops = &dummy_sink_ops, >>>>>>> +}; >>>>>>> + >>>>>>> +static int dummy_probe(struct platform_device *pdev) >>>>>>> +{ >>>>>>> + int ret, trace_id; >>>>>>> + struct device *dev = &pdev->dev; >>>>>>> + struct coresight_platform_data *pdata; >>>>>>> + struct dummy_drvdata *drvdata; >>>>>>> + struct coresight_desc desc = { 0 }; >>>>>>> + >>>>>>> + desc.name = coresight_alloc_device_name(&dummy_devs, dev); >>>>>>> + if (!desc.name) >>>>>>> + return -ENOMEM; >>>>>>> + >>>>>>> + pdata = coresight_get_platform_data(dev); >>>>>>> + if (IS_ERR(pdata)) >>>>>>> + return PTR_ERR(pdata); >>>>>>> + pdev->dev.platform_data = pdata; >>>>>>> + >>>>>>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); >>>>>>> + if (!drvdata) >>>>>>> + return -ENOMEM; >>>>>>> + >>>>>>> + drvdata->dev = &pdev->dev; >>>>>>> + platform_set_drvdata(pdev, drvdata); >>>>>>> + >>>>>>> + if (of_property_read_bool(pdev->dev.of_node, >>>>>>> "qcom,dummy-source")) { >>>>>>> + desc.type = CORESIGHT_DEV_TYPE_SOURCE; >>>>>>> + desc.subtype.source_subtype = >>>>>>> + CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS; >>>>>>> + } else if (of_property_read_bool(pdev->dev.of_node, >>>>>>> + "qcom,dummy-sink")) { >> >> It would simplify things if the compatibles were >> arm,coresight-dummy-source and arm,coresight-dummy-sink - and drop the >> two additional attributes, using of_device_is_compatible() here. >> > > Yes, I will update it in the next version of patch. > >>>>>>> + desc.type = CORESIGHT_DEV_TYPE_SINK; >>>>>>> + desc.subtype.sink_subtype = >>>>>>> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER; >>>>>> >>>>>> This will break the automatic sink selection on a system where >>>>>> perf is >>>>>> looking for a default sink and the dummy sink is closest / first >>>>>> discovered. >>>>>> >>>>>> i.e. when perf record -e cs_etm// <options> >>>>>> is used to trace a program in linux, a dummy sink appearing in the >>>>>> coresight tree with this designation may be selected. >>>>>> >>>>>> This needs to be corrected, probably with a unique sub-type that >>>>>> appears before the CORESIGHT_DEV_SUBTYPE_SINK_BUFFER value in the >>>>>> enum >>>>>> as the selection is based on >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER. >>>>>> >>>> >>>> Good point Mike. >>>> >>>>>> By implication adding a new value - will possibly affect other code >>>>>> using the enum values so will need to be checked >>>>>> >>>>>> Regards >>>>>> >>>>>> Mike >>>>>> >>>>> >>>>> Thanks for your comments, I will add a new sub-type for dummy sink and >>>>> check the impact of it. >>>> >>>> Please keep this as the lowest priority, something like: >>>> >>>> enum coresight_dev_subtype_sink { >>>> + CORESIGHT_DEV_SUBTYPE_SINK_DUMMY, >>>> CORESIGHT_DEV_SUBTYPE_SINK_PORT, >>>> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER, >>>> CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM, >>>> CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM, >>>> }; >>>> >>>> This should be fine without any impact on the existing code, as we >>>> expect the driver modules to be updated with the new core module. >>>> >>>> Suzuki >>>> >>> >>> Sure, I will take your advice in the next version of patch. >>> >>> Thanks, >>> Hao >>> >>>> >>>>> >>>>> Thanks, >>>>> Hao >>>>> >>>>>> >>>>>>> + } else { >>>>>>> + dev_info(dev, "Device type not set\n"); >>>>>>> + return -EINVAL; >>>>>>> + } >>>>>>> + >>>>>>> + desc.ops = &dummy_cs_ops; >>>>>>> + desc.pdata = pdev->dev.platform_data; >>>>>>> + desc.dev = &pdev->dev; >>>>>>> + drvdata->csdev = coresight_register(&desc); >>>>>>> + if (IS_ERR(drvdata->csdev)) >>>>>>> + return PTR_ERR(drvdata->csdev); >>>>>>> + >>>>>>> + trace_id = coresight_trace_id_get_system_id(); >>>>>>> + if (trace_id < 0) { >>>>>>> + ret = trace_id; >>>>>>> + goto cs_unregister; >>>>>>> + } >>>>>>> + drvdata->traceid = (u8)trace_id; >>>>>>> + >> >> Number of issues here:- >> 1) Why are sinks being given a trace ID? - they do not need them. >> 2) how is the trace ID communicated to the underlying hardware system? >> - there appears to be no way of doing this here. Without this you >> cannot guarantee that there will not be clashes. >> Although your use case may mitigate against this - for this to be a >> generic module there must be a way to ensure the IDs can be discovered >> externally. >> 3) Trace IDs are a limited resource - most sources allocate on enable, >> release on disable / reset - this would be preferable. >> >> >> Regards >> >> Mike Good points Mike. > > 1. It should not be given a trace ID for sink, I will correct it in the > next version of patch. > 2. There are other patches to transmit the trace ID to sub-processor. > But We have an upstream dependency on QMI project. We will sync with > them for the other related patches. > 3. The trace ID of dummy source need to be communicated to the > sub-processor, it's better to be allocated on probe, that would reduce > communications costs. On the other hand, there will be few dummy > sources. I'd perfer to allocate it on probe function. Could that be delayed to dynamic allocation when the device is enabled ? Also, do we need a property for the dummy-source to "allocate" a traceID? i.e., add a "property" (not compatible) "arm,coresight-dummy-source-traceid" ? Suzuki > > Thanks, > Hao > >> >>>>>>> + pm_runtime_enable(dev); >>>>>>> + dev_info(dev, "Dummy device initialized\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> + >>>>>>> +cs_unregister: >>>>>>> + coresight_unregister(drvdata->csdev); >>>>>>> + >>>>>>> + return ret; >>>>>>> +} >>>>>>> + >>>>>>> +static int dummy_remove(struct platform_device *pdev) >>>>>>> +{ >>>>>>> + struct dummy_drvdata *drvdata = platform_get_drvdata(pdev); >>>>>>> + struct device *dev = &pdev->dev; >>>>>>> + >>>>>>> + coresight_trace_id_put_system_id(drvdata->traceid); >>>>>>> + pm_runtime_disable(dev); >>>>>>> + coresight_unregister(drvdata->csdev); >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static const struct of_device_id dummy_match[] = { >>>>>>> + {.compatible = "qcom,coresight-dummy"}, >>>>>>> + {}, >>>>>>> +}; >>>>>>> + >>>>>>> +static struct platform_driver dummy_driver = { >>>>>>> + .probe = dummy_probe, >>>>>>> + .remove = dummy_remove, >>>>>>> + .driver = { >>>>>>> + .name = "coresight-dummy", >>>>>>> + .of_match_table = dummy_match, >>>>>>> + }, >>>>>>> +}; >>>>>>> + >>>>>>> +static int __init dummy_init(void) >>>>>>> +{ >>>>>>> + return platform_driver_register(&dummy_driver); >>>>>>> +} >>>>>>> +module_init(dummy_init); >>>>>>> + >>>>>>> +static void __exit dummy_exit(void) >>>>>>> +{ >>>>>>> + platform_driver_unregister(&dummy_driver); >>>>>>> +} >>>>>>> +module_exit(dummy_exit); >>>>>>> + >>>>>>> +MODULE_LICENSE("GPL"); >>>>>>> +MODULE_DESCRIPTION("CoreSight dummy source driver"); >>>>>>> -- >>>>>>> 2.17.1 >>>>>>> >>>>>> >>>>>> >>>> >> >> >>

1 year, 1 month

Re: [PATCH v3 01/11] dt-bindings: arm: Add support for DSB element size

by Tao Zhang

Hi Krzysztof, On 3/25/2023 7:35 PM, Krzysztof Kozlowski wrote: > On 24/03/2023 10:15, Tao Zhang wrote: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + minimum: 32 >>>>> + maximum: 64 >>>> Shouldn't this be something like oneOf ? It is not a range, but one of >>>> those two specific values ? >>> Yes, "qcom,dsb-element-size" should be an optional option required in >>> TPDM >>> >>> devicetree. Other properties like "qcom,cmb-element-size", >>> "qcom,tc-element-size" >>> >>> and etc. will be added in a later patch series. >>> >>> I will update this doc according to your advice in the next version of >>> the patch. >>> >>> Tao >>> >> Correct my misunderstanding in the mail above. >> >> You are right, DSB element size should be 32-bit or 64-bit. I will >> update this in the next > Then 'enum', not 'oneOf'. Got it. Tao > > Best regards, > Krzysztof >

1 year, 1 month

Re: [PATCH v2 2/3] dt-bindings: arm: Add Coresight Dummy Trace YAML schema

by Mike Leach

Hi, As per my comments in the previous patch in this set.... On Mon, 27 Mar 2023 at 08:38, Hao Zhang <quic_hazha(a)quicinc.com> wrote: > > Hi Krzysztof, > > On 3/25/2023 7:49 PM, Krzysztof Kozlowski wrote: > > On 24/03/2023 07:16, Hao Zhang wrote: > >> Add new coresight-dummy.yaml file describing the bindings required > >> to define coresight dummy trace in the device trees. > >> > > > > Subject: drop second/last, redundant "YAML schema". The "dt-bindings" > > prefix is already stating that these are bindings and all new must be DT > > schema. You cannot add anything else, so this is redundant. > > > I will take your advice to drop redundant part of title in the next > version of patch. > > > >> Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> > >> --- > >> .../bindings/arm/qcom,coresight-dummy.yaml | 118 ++++++++++++++++++ > >> 1 file changed, 118 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > >> > >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > >> new file mode 100644 > >> index 000000000000..7b719b084d72 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > >> @@ -0,0 +1,118 @@ > >> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > >> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/arm/qcom,coresight-dummy.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: QCOM Coresight Dummy component > >> + > >> +description: | > >> + The Coresight Dummy component is for the specific devices that HLOS don't have > >> + permission to access or configure. Such as Coresight sink EUD, some TPDMs etc. > >> + So there need driver to register dummy devices as Coresight devices. Provide > >> + Coresight API for dummy device operations, such as enabling and disabling > >> + dummy devices. Build the Coresight path for dummy sink or dummy source for > >> + debugging. > >> + > >> + The primary use case of the coresight dummy is to build path for dummy sink or > >> + dummy source. > >> + > >> +maintainers: > >> + - Mao Jinlong <quic_jinlmao(a)quicinc.com> > >> + - Tao Zhang <quic_taozha(a)quicinc.com> > >> + - Hao Zhang <quic_hazha(a)quicinc.com> > >> + > >> +select: > >> + properties: > >> + compatible: > >> + contains: > >> + enum: > >> + - qcom,coresight-dummy Can we have coresight-dummy-source and coresight-dummy-sink? > >> + required: > >> + - compatible > > > > Why do you need the select? > > > This is a mistake, will remove it in the next version of patch. > >> + > >> +properties: > >> + $nodename: > >> + pattern: "^dummy_.*(sink|source)_[0-9]+.*$" > > > > We do not enforce node names in individual bindings. Why do you need it? > > Plus underscore is not even proper character... > > > I will remove this node. > > >> + compatible: > >> + items: > > > > Drop items. You have only one item, so no need for list. > > I will take your advice and update it in the next version of patch. > > >> + - const: qcom,coresight-dummy > >> + > >> + qcom,dummy-sink: > >> + type: boolean > >> + description: > >> + Indicates that the type of this coresight node is dummy sink. > > > > You just duplicated property name. Write something useful. > > > >> + > >> + qcom,dummy-source: > >> + type: boolean > >> + description: > >> + Indicates that the type of this coresight node is dummy source. > > > > You just duplicated property name. Write something useful. > > > These properties not required if the compatible name is more specific > Sure, I will add more details for it. > > >> + > >> + out-ports: > >> + description: | > > > > No need for | > > > >> + Output connections from the dummy source to Coresight Trace bus. > >> + $ref: /schemas/graph.yaml#/properties/ports > >> + > >> + properties: > >> + port: > >> + description: Output connection from the dummy source to Coresight > >> + Trace bus. > >> + $ref: /schemas/graph.yaml#/properties/port > >> + > >> + in-ports: > >> + description: | > > > > Ditto > > > I will remove it in the next version of patch. > > >> + Input connections from the CoreSight Trace bus to dummy sink. > >> + $ref: /schemas/graph.yaml#/properties/ports > >> + > >> + properties: > >> + port: > >> + description: Input connection from the Coresight Trace bus to > >> + dummy sink. > >> + $ref: /schemas/graph.yaml#/properties/port > >> + > >> +required: > >> + - compatible > >> + The binding should constrain out ports to dummy-source only, and in ports to dummy sink only. Regards Mike > >> +additionalProperties: false > >> + > >> +oneOf: > >> + - required: > >> + - qcom,dummy-sink > >> + - required: > >> + - qcom,dummy-source > >> + > >> +examples: > >> + # minimum dummy sink definition. dummy sink connect to coresight replicator. > >> + - | > >> + dummy_sink_1 { > > > > Node names should be generic, so "sink" > > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetr… > > > >> + compatible = "qcom,coresight-dummy"; > >> + qcom,dummy-sink; > >> + > >> + in-ports { > >> + port { > >> + eud_in_replicator_swao: endpoint { > >> + remote-endpoint = > >> + <&replicator_swao_out_eud>; > > > > Why line break after =? > > > > >> + }; > >> + }; > >> + }; > >> + }; > >> + > >> + # minimum dummy source definition. dummy source connect to coresight funnel. > > > > If you use sentences, then start with capital letter. > > > > I will update it according to your advice in the next version of patch. > > >> + - | > >> + dummy_source_1 { > >> + compatible = "qcom,coresight-dummy"; > >> + qcom,dummy-source; > >> + > >> + out-ports { > >> + port { > >> + dummy_riscv_out_funnel_swao: endpoint { > >> + remote-endpoint = > >> + <&funnel_swao_in_dummy_riscv>; > > > > Why line break? > > I copy it from device tree and keep the original format, will correct > the format in the next version of patch. > > Thanks, > Hao > > >> + }; > >> + }; > >> + }; > >> + }; > >> + > >> +... > > > > Best regards, > > Krzysztof > > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 year, 1 month

Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver

by Mike Leach

Hi, A few additional comments.... On Tue, 28 Mar 2023 at 10:24, Hao Zhang <quic_hazha(a)quicinc.com> wrote: > > Hi Suzuki, > > On 3/28/2023 4:35 PM, Suzuki K Poulose wrote: > > On 28/03/2023 08:22, Hao Zhang wrote: > >> Hi Mike, > >> > >> On 3/27/2023 11:58 PM, Mike Leach wrote: > >>> Hi, > >>> > >>> On Fri, 24 Mar 2023 at 06:16, Hao Zhang <quic_hazha(a)quicinc.com> wrote: > >>>> > >>>> Some Coresight devices that HLOS don't have permission to access > >>>> or configure. Such as Coresight sink EUD, some TPDMs etc. So there > >>>> need driver to register dummy devices as Coresight devices. Provide > >>>> Coresight API for dummy device operations, such as enabling and > >>>> disabling dummy devices. Build the Coresight path for dummy sink or > >>>> dummy source for debugging. > >>>> > >>>> Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> > >>>> --- > >>>> drivers/hwtracing/coresight/Kconfig | 11 ++ > >>>> drivers/hwtracing/coresight/Makefile | 1 + > >>>> drivers/hwtracing/coresight/coresight-dummy.c | 176 > >>>> ++++++++++++++++++ > >>>> 3 files changed, 188 insertions(+) > >>>> create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c > >>>> > >>>> diff --git a/drivers/hwtracing/coresight/Kconfig > >>>> b/drivers/hwtracing/coresight/Kconfig > >>>> index 2b5bbfffbc4f..06f0a7594169 100644 > >>>> --- a/drivers/hwtracing/coresight/Kconfig > >>>> +++ b/drivers/hwtracing/coresight/Kconfig > >>>> @@ -236,4 +236,15 @@ config CORESIGHT_TPDA > >>>> > >>>> To compile this driver as a module, choose M here: the > >>>> module will be > >>>> called coresight-tpda. > >>>> + > >>>> +config CORESIGHT_DUMMY > >>>> + tristate "Dummy driver support" > >>>> + help > >>>> + Enables support for dummy driver. Dummy driver can be used > >>>> for > >>>> + CoreSight sources/sinks that are owned and configured by some > >>>> + other subsystem and use Linux drivers to configure rest of > >>>> trace > >>>> + path. > >>>> + > >>>> + To compile this driver as a module, choose M here: the > >>>> module will be > >>>> + called coresight-dummy. > >>>> endif > >>>> diff --git a/drivers/hwtracing/coresight/Makefile > >>>> b/drivers/hwtracing/coresight/Makefile > >>>> index 33bcc3f7b8ae..995d3b2c76df 100644 > >>>> --- a/drivers/hwtracing/coresight/Makefile > >>>> +++ b/drivers/hwtracing/coresight/Makefile > >>>> @@ -30,3 +30,4 @@ obj-$(CONFIG_CORESIGHT_TPDA) += coresight-tpda.o > >>>> coresight-cti-y := coresight-cti-core.o coresight-cti-platform.o \ > >>>> coresight-cti-sysfs.o > >>>> obj-$(CONFIG_ULTRASOC_SMB) += ultrasoc-smb.o > >>>> +obj-$(CONFIG_CORESIGHT_DUMMY) += coresight-dummy.o > >>>> diff --git a/drivers/hwtracing/coresight/coresight-dummy.c > >>>> b/drivers/hwtracing/coresight/coresight-dummy.c > >>>> new file mode 100644 > >>>> index 000000000000..2d4eb3e546eb > >>>> --- /dev/null > >>>> +++ b/drivers/hwtracing/coresight/coresight-dummy.c > >>>> @@ -0,0 +1,176 @@ > >>>> +// SPDX-License-Identifier: GPL-2.0 > >>>> +/* > >>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights > >>>> reserved. > >>>> + */ > >>>> + > >>>> +#include <linux/kernel.h> > >>>> +#include <linux/module.h> > >>>> +#include <linux/platform_device.h> > >>>> +#include <linux/coresight.h> > >>>> +#include <linux/of.h> > >>>> +#include <linux/pm_runtime.h> > >>>> + > >>>> +#include "coresight-priv.h" > >>>> +#include "coresight-trace-id.h" > >>>> + > >>>> +struct dummy_drvdata { > >>>> + struct device *dev; > >>>> + struct coresight_device *csdev; > >>>> + int traceid; > >>>> +}; > >>>> + > >>>> +DEFINE_CORESIGHT_DEVLIST(dummy_devs, "dummy"); > >>>> + minor nit: can we have dummy_source and dummy_sink as the device names to make it clear at the first level what these are without having to look at the attributes? > >>>> +static int dummy_source_enable(struct coresight_device *csdev, > >>>> + struct perf_event *event, u32 mode) > >>>> +{ > >>>> + struct dummy_drvdata *drvdata = > >>>> dev_get_drvdata(csdev->dev.parent); > >>>> + > >>>> + dev_info(drvdata->dev, "Dummy source enabled\n"); > >>>> + > >>>> + return 0; > >>>> +} > >>>> + > >>>> +static void dummy_source_disable(struct coresight_device *csdev, > >>>> + struct perf_event *event) > >>>> +{ > >>>> + struct dummy_drvdata *drvdata = > >>>> dev_get_drvdata(csdev->dev.parent); > >>>> + > >>>> + dev_info(drvdata->dev, "Dummy source disabled\n"); > >>>> +} > >>>> + > >>>> +static int dummy_sink_enable(struct coresight_device *csdev, u32 mode, > >>>> + void *data) > >>>> +{ > >>>> + struct dummy_drvdata *drvdata = > >>>> dev_get_drvdata(csdev->dev.parent); > >>>> + > >>>> + dev_info(drvdata->dev, "Dummy sink enabled\n"); > >>>> + > >>>> + return 0; > >>>> +} > >>>> + > >>>> +static int dummy_sink_disable(struct coresight_device *csdev) > >>>> +{ > >>>> + struct dummy_drvdata *drvdata = > >>>> dev_get_drvdata(csdev->dev.parent); > >>>> + > >>>> + dev_info(drvdata->dev, "Dummy sink disabled\n"); > >>>> + > >>>> + return 0; > >>>> +} > >>>> + > >>>> +static const struct coresight_ops_source dummy_source_ops = { > >>>> + .enable = dummy_source_enable, > >>>> + .disable = dummy_source_disable, > >>>> +}; > >>>> + > >>>> +static const struct coresight_ops_sink dummy_sink_ops = { > >>>> + .enable = dummy_sink_enable, > >>>> + .disable = dummy_sink_disable, > >>>> +}; > >>>> + > >>>> +static const struct coresight_ops dummy_cs_ops = { > >>>> + .source_ops = &dummy_source_ops, > >>>> + .sink_ops = &dummy_sink_ops, > >>>> +}; > >>>> + > >>>> +static int dummy_probe(struct platform_device *pdev) > >>>> +{ > >>>> + int ret, trace_id; > >>>> + struct device *dev = &pdev->dev; > >>>> + struct coresight_platform_data *pdata; > >>>> + struct dummy_drvdata *drvdata; > >>>> + struct coresight_desc desc = { 0 }; > >>>> + > >>>> + desc.name = coresight_alloc_device_name(&dummy_devs, dev); > >>>> + if (!desc.name) > >>>> + return -ENOMEM; > >>>> + > >>>> + pdata = coresight_get_platform_data(dev); > >>>> + if (IS_ERR(pdata)) > >>>> + return PTR_ERR(pdata); > >>>> + pdev->dev.platform_data = pdata; > >>>> + > >>>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); > >>>> + if (!drvdata) > >>>> + return -ENOMEM; > >>>> + > >>>> + drvdata->dev = &pdev->dev; > >>>> + platform_set_drvdata(pdev, drvdata); > >>>> + > >>>> + if (of_property_read_bool(pdev->dev.of_node, > >>>> "qcom,dummy-source")) { > >>>> + desc.type = CORESIGHT_DEV_TYPE_SOURCE; > >>>> + desc.subtype.source_subtype = > >>>> + CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS; > >>>> + } else if (of_property_read_bool(pdev->dev.of_node, > >>>> + "qcom,dummy-sink")) { It would simplify things if the compatibles were arm,coresight-dummy-source and arm,coresight-dummy-sink - and drop the two additional attributes, using of_device_is_compatible() here. > >>>> + desc.type = CORESIGHT_DEV_TYPE_SINK; > >>>> + desc.subtype.sink_subtype = > >>>> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER; > >>> > >>> This will break the automatic sink selection on a system where perf is > >>> looking for a default sink and the dummy sink is closest / first > >>> discovered. > >>> > >>> i.e. when perf record -e cs_etm// <options> > >>> is used to trace a program in linux, a dummy sink appearing in the > >>> coresight tree with this designation may be selected. > >>> > >>> This needs to be corrected, probably with a unique sub-type that > >>> appears before the CORESIGHT_DEV_SUBTYPE_SINK_BUFFER value in the enum > >>> as the selection is based on >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER. > >>> > > > > Good point Mike. > > > >>> By implication adding a new value - will possibly affect other code > >>> using the enum values so will need to be checked > >>> > >>> Regards > >>> > >>> Mike > >>> > >> > >> Thanks for your comments, I will add a new sub-type for dummy sink and > >> check the impact of it. > > > > Please keep this as the lowest priority, something like: > > > > enum coresight_dev_subtype_sink { > > + CORESIGHT_DEV_SUBTYPE_SINK_DUMMY, > > CORESIGHT_DEV_SUBTYPE_SINK_PORT, > > CORESIGHT_DEV_SUBTYPE_SINK_BUFFER, > > CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM, > > CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM, > > }; > > > > This should be fine without any impact on the existing code, as we > > expect the driver modules to be updated with the new core module. > > > > Suzuki > > > > Sure, I will take your advice in the next version of patch. > > Thanks, > Hao > > > > >> > >> Thanks, > >> Hao > >> > >>> > >>>> + } else { > >>>> + dev_info(dev, "Device type not set\n"); > >>>> + return -EINVAL; > >>>> + } > >>>> + > >>>> + desc.ops = &dummy_cs_ops; > >>>> + desc.pdata = pdev->dev.platform_data; > >>>> + desc.dev = &pdev->dev; > >>>> + drvdata->csdev = coresight_register(&desc); > >>>> + if (IS_ERR(drvdata->csdev)) > >>>> + return PTR_ERR(drvdata->csdev); > >>>> + > >>>> + trace_id = coresight_trace_id_get_system_id(); > >>>> + if (trace_id < 0) { > >>>> + ret = trace_id; > >>>> + goto cs_unregister; > >>>> + } > >>>> + drvdata->traceid = (u8)trace_id; > >>>> + Number of issues here:- 1) Why are sinks being given a trace ID? - they do not need them. 2) how is the trace ID communicated to the underlying hardware system? - there appears to be no way of doing this here. Without this you cannot guarantee that there will not be clashes. Although your use case may mitigate against this - for this to be a generic module there must be a way to ensure the IDs can be discovered externally. 3) Trace IDs are a limited resource - most sources allocate on enable, release on disable / reset - this would be preferable. Regards Mike > >>>> + pm_runtime_enable(dev); > >>>> + dev_info(dev, "Dummy device initialized\n"); > >>>> + > >>>> + return 0; > >>>> + > >>>> +cs_unregister: > >>>> + coresight_unregister(drvdata->csdev); > >>>> + > >>>> + return ret; > >>>> +} > >>>> + > >>>> +static int dummy_remove(struct platform_device *pdev) > >>>> +{ > >>>> + struct dummy_drvdata *drvdata = platform_get_drvdata(pdev); > >>>> + struct device *dev = &pdev->dev; > >>>> + > >>>> + coresight_trace_id_put_system_id(drvdata->traceid); > >>>> + pm_runtime_disable(dev); > >>>> + coresight_unregister(drvdata->csdev); > >>>> + return 0; > >>>> +} > >>>> + > >>>> +static const struct of_device_id dummy_match[] = { > >>>> + {.compatible = "qcom,coresight-dummy"}, > >>>> + {}, > >>>> +}; > >>>> + > >>>> +static struct platform_driver dummy_driver = { > >>>> + .probe = dummy_probe, > >>>> + .remove = dummy_remove, > >>>> + .driver = { > >>>> + .name = "coresight-dummy", > >>>> + .of_match_table = dummy_match, > >>>> + }, > >>>> +}; > >>>> + > >>>> +static int __init dummy_init(void) > >>>> +{ > >>>> + return platform_driver_register(&dummy_driver); > >>>> +} > >>>> +module_init(dummy_init); > >>>> + > >>>> +static void __exit dummy_exit(void) > >>>> +{ > >>>> + platform_driver_unregister(&dummy_driver); > >>>> +} > >>>> +module_exit(dummy_exit); > >>>> + > >>>> +MODULE_LICENSE("GPL"); > >>>> +MODULE_DESCRIPTION("CoreSight dummy source driver"); > >>>> -- > >>>> 2.17.1 > >>>> > >>> > >>> > > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 year, 1 month

Re: [BUG] perf: No samples found when using kcore + coresight

by James Clark

On 28/03/2023 01:53, Yang Shi wrote: > Hi Leo, > > Just follow up on this one. Any update? > Hi Yang, Sorry no update on this yet from me. I was just finishing off "coresight: Fix CTI module refcount leak by making it a helper device" which I hope to post in the next day or two and then I will start on this. James > Thanks, > Yang > > On Mon, Mar 13, 2023 at 5:36 PM Leo Yan <leo.yan(a)linaro.org> wrote: >> >> On Mon, Mar 13, 2023 at 11:15:44AM -0700, Yang Shi wrote: >> >> [...] >> >>>> Just a quick summary, here we have two issues: >>>> >>>> - With command: >>>> perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \ >>>> -- taskset --cpu-list 1 uname", >>>> >>>> perf doesn't enable "text poke" attribution. >>> >>> No, it enables "text poke" and perf fails to decode coresight trace >>> data too. It doesn't matter whether "--kcore" is after or before "-e >>> cs/etm/@tmc_etf63/k". >> >> Understand now. Thanks for correction, if so we can ignore this one. >> >> Leo

1 year, 1 month

Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver

by Suzuki K Poulose

On 28/03/2023 08:22, Hao Zhang wrote: > Hi Mike, > > On 3/27/2023 11:58 PM, Mike Leach wrote: >> Hi, >> >> On Fri, 24 Mar 2023 at 06:16, Hao Zhang <quic_hazha(a)quicinc.com> wrote: >>> >>> Some Coresight devices that HLOS don't have permission to access >>> or configure. Such as Coresight sink EUD, some TPDMs etc. So there >>> need driver to register dummy devices as Coresight devices. Provide >>> Coresight API for dummy device operations, such as enabling and >>> disabling dummy devices. Build the Coresight path for dummy sink or >>> dummy source for debugging. >>> >>> Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> >>> --- >>> drivers/hwtracing/coresight/Kconfig | 11 ++ >>> drivers/hwtracing/coresight/Makefile | 1 + >>> drivers/hwtracing/coresight/coresight-dummy.c | 176 ++++++++++++++++++ >>> 3 files changed, 188 insertions(+) >>> create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c >>> >>> diff --git a/drivers/hwtracing/coresight/Kconfig >>> b/drivers/hwtracing/coresight/Kconfig >>> index 2b5bbfffbc4f..06f0a7594169 100644 >>> --- a/drivers/hwtracing/coresight/Kconfig >>> +++ b/drivers/hwtracing/coresight/Kconfig >>> @@ -236,4 +236,15 @@ config CORESIGHT_TPDA >>> >>> To compile this driver as a module, choose M here: the >>> module will be >>> called coresight-tpda. >>> + >>> +config CORESIGHT_DUMMY >>> + tristate "Dummy driver support" >>> + help >>> + Enables support for dummy driver. Dummy driver can be used for >>> + CoreSight sources/sinks that are owned and configured by some >>> + other subsystem and use Linux drivers to configure rest of >>> trace >>> + path. >>> + >>> + To compile this driver as a module, choose M here: the >>> module will be >>> + called coresight-dummy. >>> endif >>> diff --git a/drivers/hwtracing/coresight/Makefile >>> b/drivers/hwtracing/coresight/Makefile >>> index 33bcc3f7b8ae..995d3b2c76df 100644 >>> --- a/drivers/hwtracing/coresight/Makefile >>> +++ b/drivers/hwtracing/coresight/Makefile >>> @@ -30,3 +30,4 @@ obj-$(CONFIG_CORESIGHT_TPDA) += coresight-tpda.o >>> coresight-cti-y := coresight-cti-core.o >>> coresight-cti-platform.o \ >>> coresight-cti-sysfs.o >>> obj-$(CONFIG_ULTRASOC_SMB) += ultrasoc-smb.o >>> +obj-$(CONFIG_CORESIGHT_DUMMY) += coresight-dummy.o >>> diff --git a/drivers/hwtracing/coresight/coresight-dummy.c >>> b/drivers/hwtracing/coresight/coresight-dummy.c >>> new file mode 100644 >>> index 000000000000..2d4eb3e546eb >>> --- /dev/null >>> +++ b/drivers/hwtracing/coresight/coresight-dummy.c >>> @@ -0,0 +1,176 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights >>> reserved. >>> + */ >>> + >>> +#include <linux/kernel.h> >>> +#include <linux/module.h> >>> +#include <linux/platform_device.h> >>> +#include <linux/coresight.h> >>> +#include <linux/of.h> >>> +#include <linux/pm_runtime.h> >>> + >>> +#include "coresight-priv.h" >>> +#include "coresight-trace-id.h" >>> + >>> +struct dummy_drvdata { >>> + struct device *dev; >>> + struct coresight_device *csdev; >>> + int traceid; >>> +}; >>> + >>> +DEFINE_CORESIGHT_DEVLIST(dummy_devs, "dummy"); >>> + >>> +static int dummy_source_enable(struct coresight_device *csdev, >>> + struct perf_event *event, u32 mode) >>> +{ >>> + struct dummy_drvdata *drvdata = >>> dev_get_drvdata(csdev->dev.parent); >>> + >>> + dev_info(drvdata->dev, "Dummy source enabled\n"); >>> + >>> + return 0; >>> +} >>> + >>> +static void dummy_source_disable(struct coresight_device *csdev, >>> + struct perf_event *event) >>> +{ >>> + struct dummy_drvdata *drvdata = >>> dev_get_drvdata(csdev->dev.parent); >>> + >>> + dev_info(drvdata->dev, "Dummy source disabled\n"); >>> +} >>> + >>> +static int dummy_sink_enable(struct coresight_device *csdev, u32 mode, >>> + void *data) >>> +{ >>> + struct dummy_drvdata *drvdata = >>> dev_get_drvdata(csdev->dev.parent); >>> + >>> + dev_info(drvdata->dev, "Dummy sink enabled\n"); >>> + >>> + return 0; >>> +} >>> + >>> +static int dummy_sink_disable(struct coresight_device *csdev) >>> +{ >>> + struct dummy_drvdata *drvdata = >>> dev_get_drvdata(csdev->dev.parent); >>> + >>> + dev_info(drvdata->dev, "Dummy sink disabled\n"); >>> + >>> + return 0; >>> +} >>> + >>> +static const struct coresight_ops_source dummy_source_ops = { >>> + .enable = dummy_source_enable, >>> + .disable = dummy_source_disable, >>> +}; >>> + >>> +static const struct coresight_ops_sink dummy_sink_ops = { >>> + .enable = dummy_sink_enable, >>> + .disable = dummy_sink_disable, >>> +}; >>> + >>> +static const struct coresight_ops dummy_cs_ops = { >>> + .source_ops = &dummy_source_ops, >>> + .sink_ops = &dummy_sink_ops, >>> +}; >>> + >>> +static int dummy_probe(struct platform_device *pdev) >>> +{ >>> + int ret, trace_id; >>> + struct device *dev = &pdev->dev; >>> + struct coresight_platform_data *pdata; >>> + struct dummy_drvdata *drvdata; >>> + struct coresight_desc desc = { 0 }; >>> + >>> + desc.name = coresight_alloc_device_name(&dummy_devs, dev); >>> + if (!desc.name) >>> + return -ENOMEM; >>> + >>> + pdata = coresight_get_platform_data(dev); >>> + if (IS_ERR(pdata)) >>> + return PTR_ERR(pdata); >>> + pdev->dev.platform_data = pdata; >>> + >>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); >>> + if (!drvdata) >>> + return -ENOMEM; >>> + >>> + drvdata->dev = &pdev->dev; >>> + platform_set_drvdata(pdev, drvdata); >>> + >>> + if (of_property_read_bool(pdev->dev.of_node, >>> "qcom,dummy-source")) { >>> + desc.type = CORESIGHT_DEV_TYPE_SOURCE; >>> + desc.subtype.source_subtype = >>> + >>> CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS; >>> + } else if (of_property_read_bool(pdev->dev.of_node, >>> + "qcom,dummy-sink")) { >>> + desc.type = CORESIGHT_DEV_TYPE_SINK; >>> + desc.subtype.sink_subtype = >>> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER; >> >> This will break the automatic sink selection on a system where perf is >> looking for a default sink and the dummy sink is closest / first >> discovered. >> >> i.e. when perf record -e cs_etm// <options> >> is used to trace a program in linux, a dummy sink appearing in the >> coresight tree with this designation may be selected. >> >> This needs to be corrected, probably with a unique sub-type that >> appears before the CORESIGHT_DEV_SUBTYPE_SINK_BUFFER value in the enum >> as the selection is based on >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER. >> Good point Mike. >> By implication adding a new value - will possibly affect other code >> using the enum values so will need to be checked >> >> Regards >> >> Mike >> > > Thanks for your comments, I will add a new sub-type for dummy sink and > check the impact of it. Please keep this as the lowest priority, something like: enum coresight_dev_subtype_sink { + CORESIGHT_DEV_SUBTYPE_SINK_DUMMY, CORESIGHT_DEV_SUBTYPE_SINK_PORT, CORESIGHT_DEV_SUBTYPE_SINK_BUFFER, CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM, CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM, }; This should be fine without any impact on the existing code, as we expect the driver modules to be updated with the new core module. Suzuki > > Thanks, > Hao > >> >>> + } else { >>> + dev_info(dev, "Device type not set\n"); >>> + return -EINVAL; >>> + } >>> + >>> + desc.ops = &dummy_cs_ops; >>> + desc.pdata = pdev->dev.platform_data; >>> + desc.dev = &pdev->dev; >>> + drvdata->csdev = coresight_register(&desc); >>> + if (IS_ERR(drvdata->csdev)) >>> + return PTR_ERR(drvdata->csdev); >>> + >>> + trace_id = coresight_trace_id_get_system_id(); >>> + if (trace_id < 0) { >>> + ret = trace_id; >>> + goto cs_unregister; >>> + } >>> + drvdata->traceid = (u8)trace_id; >>> + >>> + pm_runtime_enable(dev); >>> + dev_info(dev, "Dummy device initialized\n"); >>> + >>> + return 0; >>> + >>> +cs_unregister: >>> + coresight_unregister(drvdata->csdev); >>> + >>> + return ret; >>> +} >>> + >>> +static int dummy_remove(struct platform_device *pdev) >>> +{ >>> + struct dummy_drvdata *drvdata = platform_get_drvdata(pdev); >>> + struct device *dev = &pdev->dev; >>> + >>> + coresight_trace_id_put_system_id(drvdata->traceid); >>> + pm_runtime_disable(dev); >>> + coresight_unregister(drvdata->csdev); >>> + return 0; >>> +} >>> + >>> +static const struct of_device_id dummy_match[] = { >>> + {.compatible = "qcom,coresight-dummy"}, >>> + {}, >>> +}; >>> + >>> +static struct platform_driver dummy_driver = { >>> + .probe = dummy_probe, >>> + .remove = dummy_remove, >>> + .driver = { >>> + .name = "coresight-dummy", >>> + .of_match_table = dummy_match, >>> + }, >>> +}; >>> + >>> +static int __init dummy_init(void) >>> +{ >>> + return platform_driver_register(&dummy_driver); >>> +} >>> +module_init(dummy_init); >>> + >>> +static void __exit dummy_exit(void) >>> +{ >>> + platform_driver_unregister(&dummy_driver); >>> +} >>> +module_exit(dummy_exit); >>> + >>> +MODULE_LICENSE("GPL"); >>> +MODULE_DESCRIPTION("CoreSight dummy source driver"); >>> -- >>> 2.17.1 >>> >> >>

1 year, 1 month

Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver

by Mike Leach

Hi, On Fri, 24 Mar 2023 at 06:16, Hao Zhang <quic_hazha(a)quicinc.com> wrote: > > Some Coresight devices that HLOS don't have permission to access > or configure. Such as Coresight sink EUD, some TPDMs etc. So there > need driver to register dummy devices as Coresight devices. Provide > Coresight API for dummy device operations, such as enabling and > disabling dummy devices. Build the Coresight path for dummy sink or > dummy source for debugging. > > Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> > --- > drivers/hwtracing/coresight/Kconfig | 11 ++ > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-dummy.c | 176 ++++++++++++++++++ > 3 files changed, 188 insertions(+) > create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c > > diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig > index 2b5bbfffbc4f..06f0a7594169 100644 > --- a/drivers/hwtracing/coresight/Kconfig > +++ b/drivers/hwtracing/coresight/Kconfig > @@ -236,4 +236,15 @@ config CORESIGHT_TPDA > > To compile this driver as a module, choose M here: the module will be > called coresight-tpda. > + > +config CORESIGHT_DUMMY > + tristate "Dummy driver support" > + help > + Enables support for dummy driver. Dummy driver can be used for > + CoreSight sources/sinks that are owned and configured by some > + other subsystem and use Linux drivers to configure rest of trace > + path. > + > + To compile this driver as a module, choose M here: the module will be > + called coresight-dummy. > endif > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile > index 33bcc3f7b8ae..995d3b2c76df 100644 > --- a/drivers/hwtracing/coresight/Makefile > +++ b/drivers/hwtracing/coresight/Makefile > @@ -30,3 +30,4 @@ obj-$(CONFIG_CORESIGHT_TPDA) += coresight-tpda.o > coresight-cti-y := coresight-cti-core.o coresight-cti-platform.o \ > coresight-cti-sysfs.o > obj-$(CONFIG_ULTRASOC_SMB) += ultrasoc-smb.o > +obj-$(CONFIG_CORESIGHT_DUMMY) += coresight-dummy.o > diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c > new file mode 100644 > index 000000000000..2d4eb3e546eb > --- /dev/null > +++ b/drivers/hwtracing/coresight/coresight-dummy.c > @@ -0,0 +1,176 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/coresight.h> > +#include <linux/of.h> > +#include <linux/pm_runtime.h> > + > +#include "coresight-priv.h" > +#include "coresight-trace-id.h" > + > +struct dummy_drvdata { > + struct device *dev; > + struct coresight_device *csdev; > + int traceid; > +}; > + > +DEFINE_CORESIGHT_DEVLIST(dummy_devs, "dummy"); > + > +static int dummy_source_enable(struct coresight_device *csdev, > + struct perf_event *event, u32 mode) > +{ > + struct dummy_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > + > + dev_info(drvdata->dev, "Dummy source enabled\n"); > + > + return 0; > +} > + > +static void dummy_source_disable(struct coresight_device *csdev, > + struct perf_event *event) > +{ > + struct dummy_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > + > + dev_info(drvdata->dev, "Dummy source disabled\n"); > +} > + > +static int dummy_sink_enable(struct coresight_device *csdev, u32 mode, > + void *data) > +{ > + struct dummy_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > + > + dev_info(drvdata->dev, "Dummy sink enabled\n"); > + > + return 0; > +} > + > +static int dummy_sink_disable(struct coresight_device *csdev) > +{ > + struct dummy_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > + > + dev_info(drvdata->dev, "Dummy sink disabled\n"); > + > + return 0; > +} > + > +static const struct coresight_ops_source dummy_source_ops = { > + .enable = dummy_source_enable, > + .disable = dummy_source_disable, > +}; > + > +static const struct coresight_ops_sink dummy_sink_ops = { > + .enable = dummy_sink_enable, > + .disable = dummy_sink_disable, > +}; > + > +static const struct coresight_ops dummy_cs_ops = { > + .source_ops = &dummy_source_ops, > + .sink_ops = &dummy_sink_ops, > +}; > + > +static int dummy_probe(struct platform_device *pdev) > +{ > + int ret, trace_id; > + struct device *dev = &pdev->dev; > + struct coresight_platform_data *pdata; > + struct dummy_drvdata *drvdata; > + struct coresight_desc desc = { 0 }; > + > + desc.name = coresight_alloc_device_name(&dummy_devs, dev); > + if (!desc.name) > + return -ENOMEM; > + > + pdata = coresight_get_platform_data(dev); > + if (IS_ERR(pdata)) > + return PTR_ERR(pdata); > + pdev->dev.platform_data = pdata; > + > + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); > + if (!drvdata) > + return -ENOMEM; > + > + drvdata->dev = &pdev->dev; > + platform_set_drvdata(pdev, drvdata); > + > + if (of_property_read_bool(pdev->dev.of_node, "qcom,dummy-source")) { > + desc.type = CORESIGHT_DEV_TYPE_SOURCE; > + desc.subtype.source_subtype = > + CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS; > + } else if (of_property_read_bool(pdev->dev.of_node, > + "qcom,dummy-sink")) { > + desc.type = CORESIGHT_DEV_TYPE_SINK; > + desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER; This will break the automatic sink selection on a system where perf is looking for a default sink and the dummy sink is closest / first discovered. i.e. when perf record -e cs_etm// <options> is used to trace a program in linux, a dummy sink appearing in the coresight tree with this designation may be selected. This needs to be corrected, probably with a unique sub-type that appears before the CORESIGHT_DEV_SUBTYPE_SINK_BUFFER value in the enum as the selection is based on >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER. By implication adding a new value - will possibly affect other code using the enum values so will need to be checked Regards Mike > + } else { > + dev_info(dev, "Device type not set\n"); > + return -EINVAL; > + } > + > + desc.ops = &dummy_cs_ops; > + desc.pdata = pdev->dev.platform_data; > + desc.dev = &pdev->dev; > + drvdata->csdev = coresight_register(&desc); > + if (IS_ERR(drvdata->csdev)) > + return PTR_ERR(drvdata->csdev); > + > + trace_id = coresight_trace_id_get_system_id(); > + if (trace_id < 0) { > + ret = trace_id; > + goto cs_unregister; > + } > + drvdata->traceid = (u8)trace_id; > + > + pm_runtime_enable(dev); > + dev_info(dev, "Dummy device initialized\n"); > + > + return 0; > + > +cs_unregister: > + coresight_unregister(drvdata->csdev); > + > + return ret; > +} > + > +static int dummy_remove(struct platform_device *pdev) > +{ > + struct dummy_drvdata *drvdata = platform_get_drvdata(pdev); > + struct device *dev = &pdev->dev; > + > + coresight_trace_id_put_system_id(drvdata->traceid); > + pm_runtime_disable(dev); > + coresight_unregister(drvdata->csdev); > + return 0; > +} > + > +static const struct of_device_id dummy_match[] = { > + {.compatible = "qcom,coresight-dummy"}, > + {}, > +}; > + > +static struct platform_driver dummy_driver = { > + .probe = dummy_probe, > + .remove = dummy_remove, > + .driver = { > + .name = "coresight-dummy", > + .of_match_table = dummy_match, > + }, > +}; > + > +static int __init dummy_init(void) > +{ > + return platform_driver_register(&dummy_driver); > +} > +module_init(dummy_init); > + > +static void __exit dummy_exit(void) > +{ > + platform_driver_unregister(&dummy_driver); > +} > +module_exit(dummy_exit); > + > +MODULE_LICENSE("GPL"); > +MODULE_DESCRIPTION("CoreSight dummy source driver"); > -- > 2.17.1 > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 year, 1 month

[PATCH] coresight: cti: Check if the CPU activated for the CPU CTI

by Tao Zhang

Check whether the CPU corresponding to the CPU CTI is activated. If it is not activated, the CPU CTI node should not exist, and an error will be returned in the initialization function. Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> --- drivers/hwtracing/coresight/coresight-cti-core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index 277c890..aaa83ae 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -899,10 +899,12 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id) drvdata->config.hw_powered = true; /* set up device name - will depend if cpu bound or otherwise */ - if (drvdata->ctidev.cpu >= 0) + if (drvdata->ctidev.cpu >= 0) { + if (!cpu_active(drvdata->ctidev.cpu)) + return -ENXIO; cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d", drvdata->ctidev.cpu); - else + } else cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev); if (!cti_desc.name) return -ENOMEM; -- 2.7.4

1 year, 1 month

Re: [PATCH v2 3/3] Documentation: trace: Add documentation for Coresight Dummy Trace

by Suzuki K Poulose

On 24/03/2023 06:16, Hao Zhang wrote: > Add documentation for Coresight Dummy Trace under trace/coresight. > > Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> > --- > .../trace/coresight/coresight-dummy.rst | 58 +++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 Documentation/trace/coresight/coresight-dummy.rst > > diff --git a/Documentation/trace/coresight/coresight-dummy.rst b/Documentation/trace/coresight/coresight-dummy.rst > new file mode 100644 > index 000000000000..819cabab8623 > --- /dev/null > +++ b/Documentation/trace/coresight/coresight-dummy.rst > @@ -0,0 +1,58 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +============================= > +Coresight Dummy Trace Module > +============================= > + > + :Author: Hao Zhang <quic_hazha(a)quicinc.com> > + :Date: March 2023 > + > +Introduction > +--------------------------- > + > +Coresight Dummy Trace Module is for the specific devices that HLOS don't Please do not use cryptic abbreviations, please use "kernel" > +have permission to access or configure. Such as Coresight sink EUD, some > +TPDMs etc. Say "e.g., CoreSight TPDMs on Qualcomm platforms.: So there need driver to register dummy devices as Coresight > +devices. Add: "It may also be used to define components that may not have any programming interfaces (e.g, static links), so that paths can be established in the driver. " Provide Coresight API for dummy device operations, such as > +enabling and disabling dummy devices. Build the Coresight path for dummy > +sink or dummy source for debugging. I think the following content may not be needed as they are part of the standard source/sink type devices, nothing specific to dummy devices. --- vvvvv --- > + > +Sysfs files and directories > +--------------------------- > + > +Root: ``/sys/bus/coresight/devices/dummy<N>`` > + > +---- > + > +:File: ``enable_source`` (RW) > +:Notes: > + - > 0 : enable the datasets of dummy source. > + > + - = 0 : disable the datasets of dummy source. > + > +:Syntax: > + ``echo 1 > enable_source`` > + > +---- > + > +:File: ``enable_sink`` (RW) > +:Notes: > + - > 0 : enable the datasets of dummy sink. > + > + - = 0 : disable the datasets of dummy sink. > + > +:Syntax: > + ``echo 1 > enable_sink`` > + > +---- > + --- You may remove the above ^^^ ---- > +Config details > +--------------------------- > + > +There are two types of nodes, dummy sink and dummy source. The nodes > +should be observed at the coresight path > +"/sys/bus/coresight/devices". > +e.g. > +/sys/bus/coresight/devices # ls -l | grep dummy > +dummy0 -> ../../../devices/platform/soc@0/soc@0:dummy_source/dummy0 > +dummy1 -> ../../../devices/platform/soc@0/soc@0:dummy_sink/dummy1 Suzuki

1 year, 1 month

Re: [PATCH v2 2/3] dt-bindings: arm: Add Coresight Dummy Trace YAML schema

by Suzuki K Poulose

On 24/03/2023 06:16, Hao Zhang wrote: > Add new coresight-dummy.yaml file describing the bindings required > to define coresight dummy trace in the device trees. > > Signed-off-by: Hao Zhang <quic_hazha(a)quicinc.com> > --- > .../bindings/arm/qcom,coresight-dummy.yaml | 118 ++++++++++++++++++ > 1 file changed, 118 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > > diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > new file mode 100644 > index 000000000000..7b719b084d72 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > @@ -0,0 +1,118 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/qcom,coresight-dummy.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: QCOM Coresight Dummy component As mentioned in the previous email, please make this Arm CoreSight. This is not specific to Qcom, rather something the CoreSight driver exposes as a dummy framework. Otherwise looks good to me. Suzuki

1 year, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight March 2023