devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Tao Zhang <quic_taozha@quicinc.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: Wed, 1 Nov 2023 11:36:29 +0000	[thread overview]
Message-ID: <f79adb8e-6545-f43b-c685-bc6b0d755702@arm.com> (raw)
In-Reply-To: <c1a46885-2dd0-4280-9318-798c873a0c78@quicinc.com>



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.

>>> +}
>>> +
>>> +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;



  parent reply	other threads:[~2023-11-01 11:36 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 [this message]
2023-11-02  1:50         ` Tao Zhang
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=f79adb8e-6545-f43b-c685-bc6b0d755702@arm.com \
    --to=james.clark@arm.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=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_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).