mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>, coresight@lists.linaro.org
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 8/9] coresight: Enable and disable helper devices adjacent to the path
Date: Wed, 29 Mar 2023 13:04:41 +0100	[thread overview]
Message-ID: <303e295e-0bdb-c771-3756-ca4c81b4c600@arm.com> (raw)
In-Reply-To: <ca4dba90-8739-ad73-d3d7-681cf2326643@arm.com>



On 17/03/2023 11:04, Suzuki K Poulose wrote:
> On 10/03/2023 16:06, James Clark wrote:
>> Currently CATU is the only helper device, and its enable and disable
>> calls are hard coded. To allow more helper devices to be added in a
>> generic way, remove these hard coded calls and just enable and disable
>> all helper devices.
>>
>> This has to apply to helpers adjacent to the path, because they will
>> never be in the path. CATU was already discovered in this way, so
>> there is no change there.
>>
>> One change that is needed is for CATU to call back into ETR to allocate
>> the buffer. Because the enable call was previously hard coded, it was
>> done at a point where the buffer was already allocated, but this is no
>> longer the case.
>>
>> Signed-off-by: James Clark <james.clark@arm.com>
>> ---
>>   drivers/hwtracing/coresight/coresight-catu.c  | 34 ++++++++--
>>   drivers/hwtracing/coresight/coresight-core.c  | 68 ++++++++++++++++++-
>>   .../hwtracing/coresight/coresight-tmc-etr.c   | 28 --------
>>   include/linux/coresight.h                     |  3 +-
>>   4 files changed, 99 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-catu.c
>> b/drivers/hwtracing/coresight/coresight-catu.c
>> index bc90a03f478f..24a08a2b96b1 100644
>> --- a/drivers/hwtracing/coresight/coresight-catu.c
>> +++ b/drivers/hwtracing/coresight/coresight-catu.c
>> @@ -395,13 +395,32 @@ static inline int catu_wait_for_ready(struct
>> catu_drvdata *drvdata)
>>       return coresight_timeout(csa, CATU_STATUS, CATU_STATUS_READY, 1);
>>   }
>>   -static int catu_enable_hw(struct catu_drvdata *drvdata, void *data)
>> +static struct coresight_device *
>> +catu_get_etr_device(struct coresight_device *csdev)
>> +{
>> +    int i;
>> +    struct coresight_device *tmp;
>> +
>> +    for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>> +        tmp = csdev->pdata->in_conns[i].remote_dev;
>> +        if (tmp && tmp->type == CORESIGHT_DEV_TYPE_SINK &&
>> +            tmp->subtype.sink_subtype ==
>> +                CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM)
>> +            return tmp;
>> +    }
>> +
>> +    return NULL;
>> +}
>> +
>> +static int catu_enable_hw(struct catu_drvdata *drvdata, enum cs_mode
>> cs_mode,
>> +              void *data)
>>   {
>>       int rc;
>>       u32 control, mode;
>> -    struct etr_buf *etr_buf = data;
>> +    struct etr_buf *etr_buf = NULL;
>>       struct device *dev = &drvdata->csdev->dev;
>>       struct coresight_device *csdev = drvdata->csdev;
>> +    struct coresight_device *etrdev;
>>         if (catu_wait_for_ready(drvdata))
>>           dev_warn(dev, "Timeout while waiting for READY\n");
>> @@ -416,6 +435,12 @@ static int catu_enable_hw(struct catu_drvdata
>> *drvdata, void *data)
>>       if (rc)
>>           return rc;
>>   +    etrdev = catu_get_etr_device(csdev);
>> +    if (etrdev) {
>> +        etr_buf = tmc_etr_get_buffer(etrdev, cs_mode, data);
>> +        if (IS_ERR(etr_buf))
>> +            return PTR_ERR(etr_buf);
>> +    }
> 
> WARN_ON(!etrdev) ? We are not supposed to reach in the first place and
> return.
> 

I saw there was the pass-through mode below which I thought didn't need
an ETR device. I think I followed the code through and there was a way
for it to get there without an ETR in the existing version, but now I'm
not sure. Or does it still need the ETR device but it just doesn't
access the buffer?

> 
>>       control |= BIT(CATU_CONTROL_ENABLE);
>>         if (etr_buf && etr_buf->mode == ETR_MODE_CATU) {
>> @@ -441,13 +466,14 @@ static int catu_enable_hw(struct catu_drvdata
>> *drvdata, void *data)
>>       return 0;
>>   }
>>   -static int catu_enable(struct coresight_device *csdev, void *data)
>> +static int catu_enable(struct coresight_device *csdev, enum cs_mode
>> mode,
>> +               void *data)
>>   {
>>       int rc;
>>       struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev);
>>         CS_UNLOCK(catu_drvdata->base);
>> -    rc = catu_enable_hw(catu_drvdata, data);
>> +    rc = catu_enable_hw(catu_drvdata, mode, data);
>>       CS_LOCK(catu_drvdata->base);
>>       return rc;
>>   }
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c
>> b/drivers/hwtracing/coresight/coresight-core.c
>> index a8ba7493c09a..3e6ccd9e8d4e 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -441,6 +441,34 @@ static int coresight_enable_source(struct
>> coresight_device *csdev,
>>       return 0;
>>   }
>>   +static int coresight_enable_helper(struct coresight_device *csdev,
>> +                   enum cs_mode mode, void *sink_data)
> 
> minor nit: s/sink_data/data/ ? Though it is always either sink_data
> (perf mode) or NULL (sysfs mode), for the core code it is simply an
> opaque data.
> 

Done

> Rest looks fine to me.
> 
> Suzuki
> 
> 

  parent reply	other threads:[~2023-03-29 12:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 16:05 [PATCH v2 0/9] coresight: Fix CTI module refcount leak by making it a helper device James Clark
2023-03-10 16:06 ` [PATCH v2 1/9] coresight: Use enum type for cs_mode wherever possible James Clark
2023-03-16 16:47   ` Suzuki K Poulose
2023-03-21 15:12     ` Mike Leach
2023-03-10 16:06 ` [PATCH v2 2/9] coresight: Change name of pdata->conns James Clark
2023-03-16 17:17   ` Suzuki K Poulose
2023-03-21 15:12     ` Mike Leach
2023-03-10 16:06 ` [PATCH v2 3/9] coresight: Rename nr_outports to nr_outconns James Clark
2023-03-16 17:18   ` Suzuki K Poulose
2023-03-21 17:33     ` Mike Leach
2023-03-10 16:06 ` [PATCH v2 4/9] coresight: Rename connection members to allow for input connections James Clark
2023-03-21 17:33   ` Mike Leach
2023-03-10 16:06 ` [PATCH v2 5/9] coresight: Dynamically add connections James Clark
2023-03-16 17:12   ` Suzuki K Poulose
2023-03-21 17:56     ` Mike Leach
2023-03-23 10:49       ` James Clark
2023-03-29 12:02     ` James Clark
2023-03-10 16:06 ` [PATCH v2 6/9] coresight: Store in-connections as well as out-connections James Clark
2023-03-14  5:35   ` Jinlong Mao
2023-03-29 12:06     ` James Clark
2023-03-16 20:23   ` Suzuki K Poulose
2023-03-21 17:56     ` Mike Leach
2023-03-29 11:59     ` James Clark
2023-03-10 16:06 ` [PATCH v2 7/9] coresight: Refactor out buffer allocation function for ETR James Clark
2023-03-21 18:01   ` Mike Leach
2023-03-10 16:06 ` [PATCH v2 8/9] coresight: Enable and disable helper devices adjacent to the path James Clark
2023-03-17 11:04   ` Suzuki K Poulose
2023-03-22  9:29     ` Mike Leach
2023-03-29 12:04     ` James Clark [this message]
2023-03-29 13:23       ` Suzuki K Poulose
2023-03-29 14:10         ` James Clark
2023-03-10 16:06 ` [PATCH v2 9/9] coresight: Fix CTI module refcount leak by making it a helper device James Clark
2023-03-17 11:40   ` Suzuki K Poulose
2023-03-22  9:29   ` Mike Leach
2023-03-21 15:12 ` [PATCH v2 0/9] " Mike Leach
2023-03-22  9:26   ` James Clark
     [not found]     ` <CAJ9a7VgbehyFVF1PUZSSGVzhdSY083AvN0bC2xKH=JEUp8oVbw@mail.gmail.com>
2023-03-22 17:18       ` 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=303e295e-0bdb-c771-3756-ca4c81b4c600@arm.com \
    --to=james.clark@arm.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.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

all inboxes | Powered by JetHome®