Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4286024rwl; Tue, 28 Mar 2023 05:22:22 -0700 (PDT) X-Google-Smtp-Source: AKy350bUcvbmJwUDjUxP+92nKz+jGysAW5FIguBObkUVMmnzNayq96T3YByBCQyuSQ0RlQH7E0tt X-Received: by 2002:a17:907:76f8:b0:939:c395:1b3 with SMTP id kg24-20020a17090776f800b00939c39501b3mr16162115ejc.31.1680006142082; Tue, 28 Mar 2023 05:22:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680006142; cv=none; d=google.com; s=arc-20160816; b=SeTNYYVCSHZyX0TjjxXylfOx8l6ocZq3hvHgzaJVbxUhPpBbK6o2P+iyTvOB3nUtLJ 0ZlqbmfOjGCmaZb4aoxjH3TGuXv29Q1GaAnDgAt5QdHcfc66JR3Ku2rMMFeM5Adth+4h Hp9BfR56hnt3kBaeXEClFwDMwA3/WwGniXSy7g82F8mvZPOsRWlmPZpj9Hc9WWOetoEF 4j9Y/i8KqLLj7Zg7uzJK66h2qDjpTRtHsSAz7hN/A6WfsM6b9JFE3oZQhNVTi4yC51Vo Uctms51FH8sOcoCgkLg18tKo/XAS65F4ycubtjLPcGmc9WEhc3rvqdqprUNqeWt2xNC7 YnXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=e+yEZHsrRvEfR1cL4pGpgEK/IIpNBp49UMQLd4NWIDA=; b=HP6t3CmBf5FgPUQF+n/oyju81YsoK4wTGZT0QGPIdaDY1KC3ubVffnu5HWtQSBfW8v ME1tdomZ1MWogQWUsApqaEOeKiPXDXVo/C/ci8rUM3d5y7/PojupO0rojt9veBPYckD9 rrQTojKNiCB2bK3HnVXv1zyQI5QD1m8jaT8MkWEh2tMVajGalbMMpf3Hv9/nyyeqq09B vVGesCTmDe+WQELh5n41cQ6fLQ+8Y3UG6LgCz8Zowhm9uw6aHPL1flm0IrJLbfQUPL+v 0wk8qMcd3qA0laOECKoU5i1CDNKYlyOymLPZcqyvKuyCM1+fLMlXCCUkggun1n2oqPzX 1jOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt36-20020a1709072da400b0093defbd6292si12730055ejc.1049.2023.03.28.05.21.56; Tue, 28 Mar 2023 05:22:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231432AbjC1MV3 (ORCPT + 99 others); Tue, 28 Mar 2023 08:21:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229654AbjC1MV2 (ORCPT ); Tue, 28 Mar 2023 08:21:28 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D1F2C1BD; Tue, 28 Mar 2023 05:21:25 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BF2E3C14; Tue, 28 Mar 2023 05:22:09 -0700 (PDT) Received: from [10.57.54.240] (unknown [10.57.54.240]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9D2833F6C4; Tue, 28 Mar 2023 05:21:21 -0700 (PDT) Message-ID: Date: Tue, 28 Mar 2023 13:21:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver To: Hao Zhang , Mike Leach Cc: Mathieu Poirier , Alexander Shishkin , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Andy Gross , Paul Walmsley , Palmer Dabbelt , Albert Ou , Jonathan Corbet , Leo Yan , Greg Kroah-Hartman , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Tingwei Zhang , Jinlong Mao , Yuanfang Zhang , Tao Zhang , Trilok Soni , linux-arm-msm@vger.kernel.org, Bjorn Andersson , linux-doc@vger.kernel.org References: <20230324061608.33609-1-quic_hazha@quicinc.com> <20230324061608.33609-2-quic_hazha@quicinc.com> <0faff427-1f01-8783-9585-32dca872fe45@quicinc.com> <883c72a4-0c72-fd08-1b04-577037138b43@arm.com> <9fcc59cf-c76e-8cee-d232-830b31e35060@quicinc.com> <19028b1a-d167-07d9-59d4-a8446f2330d6@quicinc.com> From: Suzuki K Poulose In-Reply-To: <19028b1a-d167-07d9-59d4-a8446f2330d6@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 >>>>>> 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 >>>>>>> --- >>>>>>>    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 >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> + >>>>>>> +#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// >>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>> >> >> >>