devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tao Zhang <quic_taozha@quicinc.com>
To: James Clark <james.clark@arm.com>
Cc: Jinlong Mao <quic_jinlmao@quicinc.com>,
	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>,
	Yuanfang Zhang <quic_yuanfang@quicinc.com>,
	Trilok Soni <quic_tsoni@quicinc.com>,
	Song Chai <quic_songchai@quicinc.com>,
	<linux-arm-msm@vger.kernel.org>, <andersson@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Konrad Dybcio <konradybcio@gmail.com>,
	Mike Leach <mike.leach@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Subject: Re: [PATCH v2 2/8] coresight-tpda: Add support to configure CMB element
Date: Thu, 2 Nov 2023 09:50:38 +0800	[thread overview]
Message-ID: <a13c58c9-ce2c-4613-a2fc-a5fd2c46e1df@quicinc.com> (raw)
In-Reply-To: <f79adb8e-6545-f43b-c685-bc6b0d755702@arm.com>


On 11/1/2023 7:36 PM, James Clark wrote:
>
>
> On 01/11/2023 08:53, Tao Zhang wrote:
>>
>> On 10/30/2023 7:11 PM, James Clark wrote:
>>>
>>> On 25/10/2023 03:53, Tao Zhang wrote:
>>>> Read the CMB element size from the device tree. Set the register
>>>> bit that controls the CMB element size of the corresponding port.
>>>>
>>>> Signed-off-by: Tao Zhang<quic_taozha@quicinc.com>
>>>> Signed-off-by: Mao Jinlong<quic_jinlmao@quicinc.com>
>>>> ---
>>>>   drivers/hwtracing/coresight/coresight-tpda.c | 108
>>>> ++++++++++++++++-----------
>>>>   drivers/hwtracing/coresight/coresight-tpda.h |   6 ++
>>>>   2 files changed, 69 insertions(+), 45 deletions(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c
>>>> b/drivers/hwtracing/coresight/coresight-tpda.c
>>>> index 5f82737..3101d2a 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpda.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
>>>> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct
>>>> coresight_device *csdev)
>>>>               CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>>>>   }
>>>>   +static void tpdm_clear_element_size(struct coresight_device *csdev)
>>>> +{
>>>> +    struct tpda_drvdata *drvdata = 
>>>> dev_get_drvdata(csdev->dev.parent);
>>>> +
>>>> +    if (drvdata->dsb_esize)
>>>> +        drvdata->dsb_esize = 0;
>>>> +    if (drvdata->cmb_esize)
>>>> +        drvdata->cmb_esize = 0;
>
> The ifs don't do anything here, it's just the same as always setting 
> to 0.
I will update in the next patch series.
>
>>>> +}
>>>> +
>>>> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32
>>>> *val)
>>>> +{
>>>> +
>>>> +    if (drvdata->dsb_esize == 64)
>>>> +        *val |= TPDA_Pn_CR_DSBSIZE;
>>>> +    else if (drvdata->dsb_esize == 32)
>>>> +        *val &= ~TPDA_Pn_CR_DSBSIZE;
>>>> +
>>>> +    if (drvdata->cmb_esize == 64)
>>>> +        *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
>>>> +    else if (drvdata->cmb_esize == 32)
>>>> +        *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
>>>> +    else if (drvdata->cmb_esize == 8)
>>>> +        *val &= ~TPDA_Pn_CR_CMBSIZE;
>>>> +}
>>>> +
>>>>   /*
>>>>    * Read the DSB element size from the TPDM device
>>>>    * Returns
>>>>    *    The dsb element size read from the devicetree if available.
>>> Hi Tao,
>>>
>>> I think the function description and the return value description above
>>> need updating now.
>> I will update this in the next patch series.
>>>
>>>>    *    0 - Otherwise, with a warning once.
>>>>    */
>>>> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>>>> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
>>>> +                  struct coresight_device *csdev)
>>>>   {
>>>> -    int rc = 0;
>>>> -    u8 size = 0;
>>>> -
>>>> -    rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>>> -            "qcom,dsb-element-size", &size);
>>>> +    int rc = -EEXIST;
>>>> +
>>>> +    if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>>> +            "qcom,dsb-element-size", &drvdata->dsb_esize))
>>>> +        rc &= 0;
>>> Is &= 0 significant? Why not = 0?
>> I will update this in the next patch series.
>>>
>>>> +    if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>>> +            "qcom,cmb-element-size", &drvdata->cmb_esize))
>>>> +        rc &= 0;
>>>>       if (rc)
>>>>           dev_warn_once(&csdev->dev,
>>>> -            "Failed to read TPDM DSB Element size: %d\n", rc);
>>>> +            "Failed to read TPDM Element size: %d\n", rc);
>>>>   -    return size;
>>>> +    return rc;
>>>>   }
>>>>     /*
>>>> @@ -56,13 +86,17 @@ static int tpdm_read_dsb_element_size(struct
>>>> coresight_device *csdev)
>>>>    * Parameter "inport" is used to pass in the input port number
>>>>    * of TPDA, and it is set to -1 in the recursize call.
>>>>    */
>>>> -static int tpda_get_element_size(struct coresight_device *csdev,
>>>> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
>>>> +                 struct coresight_device *csdev,
>>>>                    int inport)
>>>>   {
>>>> -    int dsb_size = -ENOENT;
>>>> -    int i, size;
>>>> +    int rc = -ENOENT;
>>>> +    int i;
>>>>       struct coresight_device *in;
>>>>   +    if (inport > 0)
>>>> +        tpdm_clear_element_size(csdev);
>>>> +
>>>>       for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>>>>           in = csdev->pdata->in_conns[i]->src_dev;
>>>>           if (!in)
>>>> @@ -74,25 +108,20 @@ static int tpda_get_element_size(struct
>>>> coresight_device *csdev,
>>>>               continue;
>>>>             if (coresight_device_is_tpdm(in)) {
>>>> -            size = tpdm_read_dsb_element_size(in);
>>>> +            if (rc)
>>>> +                rc = tpdm_read_element_size(drvdata, in);
>>>> +            else
>>>> +                return -EINVAL;
>>> This is quite hard to follow, is checking rc here before calling
>>> tpdm_read_element_size() some kind of way of only calling it once?
>>
>> Yes, there can only be one TPDM on one input port of TPDA. If
>> "tpdm_read_element_size" is called
>>
>> twice, it means that two TPDMs are found on one input port of TPDA.
>>
>>> rc isn't actually a return value at this point, it's just default
>>> initialised to -ENOENT.
>>
>> In this loop, "tpdm_read_element_size" will be called for the first time
>> TPDM found. If rc equals to
>>
>> 0, it means that at lease one TPDM has been found on the input port.
>> Does it make sense?
>>
>>> Then it's not clear why the else condition returns an error?
>> The same as the above.
>>>
>>>>           } else {
>>>>               /* Recurse down the path */
>>>> -            size = tpda_get_element_size(in, -1);
>>>> -        }
>>>> -
>>>> -        if (size < 0)
>>>> -            return size;
>>>> -
>>>> -        if (dsb_size < 0) {
>>>> -            /* Found a size, save it. */
>>>> -            dsb_size = size;
>>>> -        } else {
>>>> -            /* Found duplicate TPDMs */
>>>> -            return -EEXIST;
>>>> +            rc = tpda_get_element_size(drvdata, in, -1);
>>> And then why it's assigned here but not checked for an error in this
>>> case?
>>
>> |Remote ETM|                           |TPDM|
>>
>>             |    branch0                           | branch1
>>
>>                         --------------------------
>>
>>                                     funnel1
>>
>>                         ---------------------------
>>
>>                                           | input port 1
>>
>> -----------------------------
>>
>>                                                        TPDA1
>>
>> -----------------------------
>>
>> The  branches on some TPDA's input ports may not have TPDM. For example,
>> branch 0 doesn't has a
>>
>> TPDM connected, tpda_get_element_size will not return 0 here. This is a
>> normal situation. We need to
>>
>> continue to find TPDM on branch1 through recursion.
>>
>>>
>>> Maybe some comments explaining the flow would help. Or to me it seems
>>> like a second variable to track the thing that's actually intended 
>>> could
>>> be used as well. Like "bool found_element" or something, rather than
>>> re-using rc to also track another thing.
>>
>> Do you prefer to use "static bool found_element" to mark if we already
>> have read an element size in
>>
>> the recursion function?
>>
>
> You could add a static, or you could use whether a set dsb or cmb size
> exists to mark that one was found, which I think is already partially 
> done.
>
> My confusion comes from the fact that instead of just a recursive
> search, the function doesn't stop at the first found one, it continues
> to sanity check that there is only one connected across all ports.
>
> And instead of just checking the error condition at the very end, it
> does it mid recursion, relying on the rc value from a previous
> iteration. IMO the following is a simplification because it always
> returns at the first error found, and checks the final condition outside
> of the recursive function. But you could probably leave it as you have
> but with some comments explaining why:
>
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c 
> b/drivers/hwtracing/coresight/coresight-tpda.c
> index 3101d2a0671d..00b7607d36be 100644
> --- a/drivers/hwtracing/coresight/coresight-tpda.c
> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
> @@ -90,13 +90,10 @@ static int tpda_get_element_size(struct 
> tpda_drvdata *drvdata,
>                                  struct coresight_device *csdev,
>                                  int inport)
>  {
> -       int rc = -ENOENT;
> +       int rc = 0;
>         int i;
>         struct coresight_device *in;
>
> -       if (inport > 0)
> -               tpdm_clear_element_size(csdev);
> -
>         for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>                 in = csdev->pdata->in_conns[i]->src_dev;
>                 if (!in)
> @@ -108,19 +105,23 @@ static int tpda_get_element_size(struct 
> tpda_drvdata *drvdata,
>                         continue;
>
>                 if (coresight_device_is_tpdm(in)) {
> -                       if (rc)
> -                               rc = tpdm_read_element_size(drvdata, in);
> -                       else
> +                       if ((drvdata->dsb_esize) || 
> (drvdata->cmb_esize)) {
> +                               /* Error if already previously found 
> and initialised one */
> + dev_warn_once(&drvdata->csdev->dev,
> +                                       "Detected multiple TPDMs on 
> port %d", -EEXIST);
>                                 return -EINVAL;
> +                       }
> +                       rc = tpdm_read_element_size(drvdata, in);
> +                       if (rc)
> +                               return rc;
>                 } else {
>                         /* Recurse down the path */
>                         rc = tpda_get_element_size(drvdata, in, -1);
> +                       if (rc)
> +                               return rc;
>                 }
>         }
>
> -       if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
> -               rc = 0;
> -
>         return rc;
>  }
>
> @@ -146,15 +147,17 @@ static int tpda_enable_port(struct tpda_drvdata 
> *drvdata, int port)
>          * Set the bit to 0 if the size is 32
>          * Set the bit to 1 if the size is 64
>          */
> +       tpdm_clear_element_size(drvdata->csdev);
>         rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
> -       if (!rc) {
> +       if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize)))
> +       {
>                 tpda_set_element_size(drvdata, &val);
>                 /* Enable the port */
>                 val |= TPDA_Pn_CR_ENA;
>                 writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
> -       } else if (rc == -EINVAL) {
> -               dev_warn_once(&drvdata->csdev->dev,
> -                       "Detected multiple TPDMs on port %d", -EEXIST);
> +       } else {
> +               dev_warn_once(&drvdata->csdev->dev, "Didn't find TPDM 
> elem size");
> +               rc = -EINVAL;
>         }
>
>         return rc;

Make sense. I will refine and update the code in the next patch series.


Best,

Tao

>
>

  reply	other threads:[~2023-11-02  1:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25  2:53 [PATCH v2 0/8] Add support to configure TPDM CMB subunit Tao Zhang
2023-10-25  2:53 ` [PATCH v2 1/8] dt-bindings: arm: Add support for CMB element size Tao Zhang
2023-10-26 21:25   ` Rob Herring
2023-11-01  6:29     ` Tao Zhang
2023-11-08  7:21       ` Tao Zhang
2023-10-25  2:53 ` [PATCH v2 2/8] coresight-tpda: Add support to configure CMB element Tao Zhang
2023-10-30 11:11   ` James Clark
     [not found]     ` <c1a46885-2dd0-4280-9318-798c873a0c78@quicinc.com>
2023-11-01 11:36       ` James Clark
2023-11-02  1:50         ` Tao Zhang [this message]
2023-10-25  2:53 ` [PATCH v2 3/8] coresight-tpdm: Add CMB dataset support Tao Zhang
2023-10-30 11:15   ` James Clark
2023-10-25  2:53 ` [PATCH v2 4/8] coresight-tpdm: Add support to configure CMB Tao Zhang
2023-10-30 11:29   ` James Clark
2023-11-01  9:06     ` Tao Zhang
2023-10-25  2:53 ` [PATCH v2 5/8] coresight-tpdm: Add pattern registers support for CMB Tao Zhang
2023-10-30 11:33   ` James Clark
2023-10-25  2:53 ` [PATCH v2 6/8] coresight-tpdm: Add timestamp control register support for the CMB Tao Zhang
2023-10-30 11:37   ` James Clark
2023-10-25  2:53 ` [PATCH v2 7/8] dt-bindings: arm: Add support for TPDM CMB MSR register Tao Zhang
2023-10-26 21:27   ` Rob Herring
2023-11-01  7:10     ` Tao Zhang
2023-10-25  2:53 ` [PATCH v2 8/8] coresight-tpdm: Add msr register support for CMB Tao Zhang
2023-10-30 11:41   ` James Clark

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=a13c58c9-ce2c-4613-a2fc-a5fd2c46e1df@quicinc.com \
    --to=quic_taozha@quicinc.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andersson@kernel.org \
    --cc=coresight@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.clark@arm.com \
    --cc=konradybcio@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=quic_jinlmao@quicinc.com \
    --cc=quic_songchai@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).