public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yingchao Deng (Consultant)" <quic_yingdeng@quicinc.com>
To: Leo Yan <leo.yan@arm.com>, Yingchao Deng <quic_yingdeng@quicinc.com>
Cc: <mike.leach@linaro.org>, <alexander.shishkin@linux.intel.com>,
	<coresight@lists.linaro.org>, <james.clark@linaro.org>,
	<jinlong.mao@oss.qualcomm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<quic_jinlmao@quicinc.com>, <suzuki.poulose@arm.com>,
	<tingwei.zhang@oss.qualcomm.com>
Subject: Re: [PATCH v6 2/2] coresight: cti: Add Qualcomm extended CTI support
Date: Tue, 9 Dec 2025 20:51:38 +0800	[thread overview]
Message-ID: <1fbe140c-b960-4f13-83e2-b0a0733a67bc@quicinc.com> (raw)
In-Reply-To: <20251209121916.GT724103@e132581.arm.com>

Hi Leo,

On 12/9/2025 8:19 PM, Leo Yan wrote:
> Hi Yingchao,
>
> On Tue, Dec 09, 2025 at 04:16:28PM +0800, Yingchao Deng wrote:
>> Hi Leo & Mike
>>
>> Based on Leo’s suggestions, I created a new patch, but there are three points that do not fully align with his recommendations:
>>
>>      1. The helper function for returning the register address now returns only the offset, because returning the full address would conflict with cti_write_single_reg.
> No need to change each callsite for cti_write_single_reg().  You could
> update cti_write_single_reg() instead:
>
>    void cti_write_single_reg(struct cti_drvdata *drvdata,
>                              int offset, u32 value)
>    {
>            CS_UNLOCK(drvdata->base);
>            writel_relaxed(value, cti_reg_addr(drvdata, offset));
>            CS_LOCK(drvdata->base);
>    }

However, since we also need to handle cti_reg_addr_with_nr, it will be 
necessary to add an additional parameter "nr" to cti_write_single_reg?

Thanks
Yingchao
>>      2. For registers such as triginstatus1...3, I defined additional macros CTITRIGINSTATUS1...3. This is because CTITRIGINSTATUS + 0x4 equals CTITRIGOUTSTATUS, and to avoid conflicts with existing macros, I chose numbers starting from 0x1000 for the new definitions.
> To avoid the register naming pollution, please don't define the common
> names but only used for Qcom registers.
>
> AFAIK, you even don't need to define these registers.  These registers
> are only used for sysfs knobs, we can define an extra "nr" field (e.g.,
> bits[31..28] for indexing these registers, something like:
>
>    #define CIT_REG_NR_SHIFT          28
>    #define CIT_REG_NR_MASK           GENMASK(31, 28)
>    #define CTI_REG_GET_NR(reg)       FIELD_GET(CIT_REG_NR_MASK, (reg))
>    #define CTI_REG_SET_NR(reg, nr)   ((reg) | FIELD_PREP(CIT_REG_NR_MASK, (nr))
>
>    static struct attribute *coresight_cti_regs_attrs[] = {
>    ...
>      coresight_cti_reg(triginstatus, CTITRIGINSTATUS),
>      coresight_cti_reg(triginstatus1, CTI_REG_SET_NR(CTITRIGINSTATUS, 1)),
>      coresight_cti_reg(triginstatus2, CTI_REG_SET_NR(CTITRIGINSTATUS, 2)),
>      coresight_cti_reg(triginstatus3, CTI_REG_SET_NR(CTITRIGINSTATUS, 3)),
>    ...
>
> Then, you just need to decode "nr" fields in cti_qcom_reg_off().
>
>>      3. Regarding the visibility of attributes for triginstatus1...3, since coresight_cti_reg produces an anonymous variable that cannot be directly referenced, I used coresight_cti_regs_attrs[i] to obtain the attribute corresponding to triginstatus1.
> Okay, I get the meaning for "an anonymous variable" - there have no
> field naming when define attr with the macro coresight_cti_reg().
>
> but you could comparing the attr string?
>
>    if (!strcmp(attr->name, "triginstatus1") ||
>        !strcmp(attr->name, "triginstatus2") ||
>        !strcmp(attr->name, "triginstatus3"))
>        ...
>
> Thanks,
> Leo

  reply	other threads:[~2025-12-09 12:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  6:42 [PATCH v6 0/2] Add Qualcomm extended CTI support Yingchao Deng
2025-12-02  6:42 ` [PATCH v6 1/2] coresight: cti: Convert trigger usage fields to dynamic bitmaps and arrays Yingchao Deng
2025-12-04  9:54   ` Mike Leach
2025-12-02  6:42 ` [PATCH v6 2/2] coresight: cti: Add Qualcomm extended CTI support Yingchao Deng
2025-12-03 18:29   ` Leo Yan
2025-12-04  8:38     ` Leo Yan
2025-12-04  9:04       ` Mike Leach
2025-12-04 10:02         ` Leo Yan
2025-12-04  9:07     ` Mike Leach
2025-12-04 10:31       ` Leo Yan
2025-12-04 16:17         ` Mike Leach
2025-12-05 10:04           ` Leo Yan
2025-12-08 14:47             ` Mike Leach
2025-12-09  8:16               ` Yingchao Deng
2025-12-09  9:40                 ` Jie Gan
2025-12-09 11:03                 ` Jie Gan
2025-12-09 12:42                   ` Yingchao Deng (Consultant)
2025-12-09 12:19                 ` Leo Yan
2025-12-09 12:51                   ` Yingchao Deng (Consultant) [this message]
2025-12-09 14:24                     ` Leo Yan
2025-12-09 13:59               ` Leo Yan
2025-12-04  9:15     ` Mike Leach
2025-12-04 10:47       ` Leo Yan
2025-12-04 15:07         ` Mike Leach
2025-12-05 10:27           ` Leo Yan
2025-12-08 14:25             ` Mike Leach

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=1fbe140c-b960-4f13-83e2-b0a0733a67bc@quicinc.com \
    --to=quic_yingdeng@quicinc.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=james.clark@linaro.org \
    --cc=jinlong.mao@oss.qualcomm.com \
    --cc=leo.yan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=quic_jinlmao@quicinc.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tingwei.zhang@oss.qualcomm.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