devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hao Zhang <quic_hazha@quicinc.com>
To: Mike Leach <mike.leach@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Konrad Dybcio <konradybcio@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Andy Gross <agross@kernel.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Jonathan Corbet <corbet@lwn.net>, Leo Yan <leo.yan@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	<coresight@lists.linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	Tingwei Zhang <quic_tingweiz@quicinc.com>,
	Jinlong Mao <quic_jinlmao@quicinc.com>,
	"Yuanfang Zhang" <quic_yuanfang@quicinc.com>,
	Tao Zhang <quic_taozha@quicinc.com>,
	Trilok Soni <quic_tsoni@quicinc.com>,
	<linux-arm-msm@vger.kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	<linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] Coresight: Add coresight dummy driver
Date: Tue, 28 Mar 2023 19:25:16 +0800	[thread overview]
Message-ID: <19028b1a-d167-07d9-59d4-a8446f2330d6@quicinc.com> (raw)
In-Reply-To: <CAJ9a7Vj7L1wbc2iad-Tbf+2d_t5z-GpN7WEff0_FupVZVRNymA@mail.gmail.com>

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@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@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@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

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.

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
>>>>>>
>>>>>
>>>>>
>>>
> 
> 
> 

  reply	other threads:[~2023-03-28 11:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24  6:16 [PATCH v2 0/3] Add support to configure Coresight Dummy subunit Hao Zhang
2023-03-24  6:16 ` [PATCH v2 1/3] Coresight: Add coresight dummy driver Hao Zhang
2023-03-24 10:44   ` Suzuki K Poulose
2023-03-27  5:43     ` Hao Zhang
2023-03-27 15:58   ` Mike Leach
2023-03-28  7:22     ` Hao Zhang
2023-03-28  8:35       ` Suzuki K Poulose
2023-03-28  9:24         ` Hao Zhang
2023-03-28 10:06           ` Mike Leach
2023-03-28 11:25             ` Hao Zhang [this message]
2023-03-28 12:21               ` Suzuki K Poulose
2023-03-28 14:32                 ` Mike Leach
2023-03-24  6:16 ` [PATCH v2 2/3] dt-bindings: arm: Add Coresight Dummy Trace YAML schema Hao Zhang
2023-03-24 10:47   ` Suzuki K Poulose
2023-03-27  5:58     ` Hao Zhang
2023-03-25 11:49   ` Krzysztof Kozlowski
2023-03-27  7:38     ` Hao Zhang
2023-03-28 10:12       ` Mike Leach
2023-03-28 11:29         ` Hao Zhang
2023-03-31 18:47   ` Rob Herring
2023-04-07  6:23     ` Hao Zhang
2023-03-24  6:16 ` [PATCH v2 3/3] Documentation: trace: Add documentation for Coresight Dummy Trace Hao Zhang
2023-03-24 11:00   ` Suzuki K Poulose
2023-03-27  6:05     ` Hao Zhang
2023-03-27  9:06   ` Bagas Sanjaya
2023-03-28  8:07     ` Hao Zhang
2023-03-27  9:13   ` Greg Kroah-Hartman
2023-03-28  1:45     ` Hao Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19028b1a-d167-07d9-59d4-a8446f2330d6@quicinc.com \
    --to=quic_hazha@quicinc.com \
    --cc=agross@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andersson@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=corbet@lwn.net \
    --cc=coresight@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=konradybcio@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=quic_jinlmao@quicinc.com \
    --cc=quic_taozha@quicinc.com \
    --cc=quic_tingweiz@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=quic_yuanfang@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).