Received-SPF: pass (google.com: domain of linux-kernel+bounces-84785-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <6389f1e3-57b2-453a-af6f-6bc7f725ad31@collabora.com>
Date: Wed, 28 Feb 2024 10:41:15 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] soc: mediatek: cmdq: Don't log an error when
 gce-client-reg is not found
To: =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com>,
 Matthias Brugger <matthias.bgg@gmail.com>
Cc: kernel@collabora.com, linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org
References: <20240226-gce-client-reg-log-dbg-v1-1-f0fff97c30c7@collabora.com>
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Content-Language: en-US
In-Reply-To: <20240226-gce-client-reg-log-dbg-v1-1-f0fff97c30c7@collabora.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Il 26/02/24 22:31, Nícolas F. R. A. Prado ha scritto:
> Most of the callers to this function do not require CMDQ support, it is
> optional, so the missing property shouldn't cause an error message.
> Furthermore, the callers that do require CMDQ support already log at the
> error level when an error is returned.
> 
> Change the log message in this helper to be printed at the debug level
> instead.

CMDQ is optional, yes. At least, for some devices it is.

Full story, though, wants that if you use the CPU for register manipulation
instead of programming the GCE (even with threading, fantastic!) you will
trigger various performance issues.

In the end, you *don't want* to use the CPU if GCE is available!

The reasons why the CMDQ/GCE is optional are:
  - You can check register-by-register r/w for debugging scenarios by using
    the CPU to manipulate them instead of having something magically doing
    that for you at a certain (pre-set, yes, but still!) point;
  - Not all SoCs have the same amount of GCE threads and channels, some may
    support writing to IP block X through the GCE, some may not, but both
    may support writing for IP block Y through this mailbox;
  - MediaTek chose to support both ways, enabling means to debug stuff upstream,
    the other choice would've been to never support CPU register R/W on some IPs

    ... and btw - about the last part: Kudos, MediaTek.

Now, I also get why you're raising this, but we have to find an agreement here
on a different way to proceed that satisfies all of us.

First of all..

Which device on which SoC is missing the GCE client register DT property?
Do said SoC really not have a GCE client register for that device?

Is any upstream supported SoC really lacking a GCE register for the upstream
supported IPs?

I'm not sure.... :-)

P.S.: I guess that the alternative (that I somewhat dislike, and you can probably
       understand why after reading the reasons above) would be to turn that into a
       dev_info() instead...

P.P.S.: Having no GCE usually means that there's a performance issue! In that case,
         it's ... a mistake, so, an error, kind-of.... :-)

Cheers,
Angelo

> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>   drivers/soc/mediatek/mtk-cmdq-helper.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index b0cd071c4719..2130ff3aac9e 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -55,7 +55,7 @@ int cmdq_dev_get_client_reg(struct device *dev,
>   					       "mediatek,gce-client-reg",
>   					       3, idx, &spec);
>   	if (err < 0) {
> -		dev_err(dev,
> +		dev_dbg(dev,
>   			"error %d can't parse gce-client-reg property (%d)",
>   			err, idx);
>   
> 
> ---
> base-commit: 41913bcddc83b131649ee8ff0d9ff29e01731398
> change-id: 20240226-gce-client-reg-log-dbg-5ae9637a08ed
> 
> Best regards,