public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
To: Moudy Ho <moudy.ho@mediatek.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Rob Landley <rob@landley.net>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	Alexandre Courbot <acourbot@chromium.org>,
	tfiga@chromium.org, drinkcat@chromium.org, pihsun@chromium.org,
	hsinyi@google.com,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	daoyuan huang <daoyuan.huang@mediatek.com>,
	Ping-Hsun Wu <ping-hsun.wu@mediatek.com>,
	allen-kh.cheng@mediatek.com, xiandong.wang@mediatek.com,
	randy.wu@mediatek.com, jason-jh.lin@mediatek.com,
	roy-cw.yeh@mediatek.com, river.cheng@mediatek.com,
	srv_heupstream@mediatek.com,
	Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: Re: [PATCH v14 6/6] soc: mediatek: mutex: add functions that operate registers by CMDQ
Date: Wed, 13 Apr 2022 10:41:34 +0200	[thread overview]
Message-ID: <858afddd-c008-8a6c-c3c1-e1883e710c5e@collabora.com> (raw)
In-Reply-To: <20220411072403.24016-7-moudy.ho@mediatek.com>

Il 11/04/22 09:24, Moudy Ho ha scritto:
> Due to HW limitations, MDP3 is necessary to enable MUTEX in each frame
> for SOF triggering and cooperate with CMDQ control to reduce the amount
> of interrupts generated(also, reduce frame latency).
> 
> In response to the above situation, a new interface
> "mtk_mutex_enable_by_cmdq" has been added to achieve the purpose.
> 
> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> ---
>   drivers/soc/mediatek/mtk-mutex.c       | 42 +++++++++++++++++++++++++-
>   include/linux/soc/mediatek/mtk-mutex.h |  2 ++
>   2 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
> index fc9ba2749946..1811beaf399d 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -7,10 +7,12 @@
>   #include <linux/iopoll.h>
>   #include <linux/module.h>
>   #include <linux/of_device.h>
> +#include <linux/of_address.h>
>   #include <linux/platform_device.h>
>   #include <linux/regmap.h>
>   #include <linux/soc/mediatek/mtk-mmsys.h>
>   #include <linux/soc/mediatek/mtk-mutex.h>
> +#include <linux/soc/mediatek/mtk-cmdq.h>
>   
>   #define MT2701_MUTEX0_MOD0			0x2c
>   #define MT2701_MUTEX0_SOF0			0x30
> @@ -176,6 +178,9 @@ struct mtk_mutex_ctx {
>   	void __iomem			*regs;
>   	struct mtk_mutex		mutex[10];
>   	const struct mtk_mutex_data	*data;
> +	phys_addr_t			addr;
> +	struct cmdq_client_reg		cmdq_reg;
> +	bool				has_gce_client_reg;
>   };
>   
>   static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> @@ -618,6 +623,28 @@ void mtk_mutex_enable(struct mtk_mutex *mutex)
>   }
>   EXPORT_SYMBOL_GPL(mtk_mutex_enable);
>   
> +void mtk_mutex_enable_by_cmdq(struct mtk_mutex *mutex, void *pkt)
> +{
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +	struct mtk_mutex_ctx *mtx = container_of(mutex, struct mtk_mutex_ctx,
> +						 mutex[mutex->id]);
> +	struct cmdq_pkt *cmdq_pkt = (struct cmdq_pkt *)pkt;
> +
> +	WARN_ON(&mtx->mutex[mutex->id] != mutex);
> +
> +	if (!mtx->has_gce_client_reg) {
> +		dev_dbg(mtx->dev, "mediatek,gce-client-reg hasn't been set in dts");
> +		return;

Is this really supposed to happen?

Reiterating: when the gce-client-reg is not set, this function should either never
be called from the principle, or it should actually fail.
If a driver relies on mtk_mutex_enable_by_cmdq() and does *not* fall back to
register write from cpu, then no change will occur at all, leading to a random
breakage with no apparent reason.

This means that - for safety - this function should return -EINVAL when it gets
called while no gce client reg is declared.
Of course, this would also mean that the dev_dbg() should be a dev_err(), and
that efforts should be done to avoid triggering this error by adding fallbacks
in the drivers that will call this.

Another option would be to keep this function void, keep the print a dev_dbg(),
but automatically fallback to mtk_mutex_enable(), so that here:

if (!mtx->has_gce_client_reg) {
	dev_dbg(mtx->dev,
		"No GCE client register found: falling back to cpu write.\n");
	mtk_mutex_enable(mutex);
	return;
}

...you're free to choose whichever of the two options, but this has to be fixed
to remove this fragility.

> +	}
> +
> +	cmdq_pkt_write(cmdq_pkt, mtx->cmdq_reg.subsys,
> +		       mtx->addr + DISP_REG_MUTEX_EN(mutex->id), 1);
> +#else
> +	dev_err(mtx->dev, "Not support for enable MUTEX by CMDQ");

...obviously, if mtk_cmdq not reachable, instead of simply letting drivers break,
you should, also here, fall back to the less performant and very suboptimal (for
the specific case of mdp3 and some others) mtk_mutex_enable().


Thanks,
Angelo

  reply	other threads:[~2022-04-13  8:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11  7:23 [PATCH v14 0/6] Add mutex support for MDP Moudy Ho
2022-04-11  7:23 ` [PATCH v14 1/6] soc: mediatek: mutex: add common interface to accommodate multiple modules operationg MUTEX Moudy Ho
2022-04-13  8:27   ` AngeloGioacchino Del Regno
2022-04-11  7:23 ` [PATCH v14 2/6] soc: mediatek: mutex: add 8183 MUTEX MOD settings for MDP Moudy Ho
2022-04-13  8:28   ` AngeloGioacchino Del Regno
2022-04-11  7:24 ` [PATCH v14 3/6] dt-bindings: soc: mediatek: move out common module from display folder Moudy Ho
2022-04-13  8:28   ` AngeloGioacchino Del Regno
2022-04-11  7:24 ` [PATCH v14 4/6] dt-bindings: soc: mediatek: add gce-client-reg for MUTEX Moudy Ho
2022-04-11  7:24 ` [PATCH v14 5/6] dts: arm64: mt8183: add GCE client property for Mediatek MUTEX Moudy Ho
2022-04-13  8:29   ` AngeloGioacchino Del Regno
2022-04-11  7:24 ` [PATCH v14 6/6] soc: mediatek: mutex: add functions that operate registers by CMDQ Moudy Ho
2022-04-13  8:41   ` AngeloGioacchino Del Regno [this message]
     [not found] <72f7feabe22064365457b5b72dfb1972ba2b3151.camel@mediatek.com>
2022-03-18  8:38 ` Miles Chen
  -- strict thread matches above, loose matches on Subject: below --
2022-03-17 14:39 [PATCH v14 0/6] Add mutex support for MDP Moudy Ho
2022-03-17 14:39 ` [PATCH v14 6/6] soc: mediatek: mutex: add functions that operate registers by CMDQ Moudy Ho
2022-03-17 23:31   ` Miles Chen
2022-03-22 10:04   ` CK Hu

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=858afddd-c008-8a6c-c3c1-e1883e710c5e@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=acourbot@chromium.org \
    --cc=allen-kh.cheng@mediatek.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=daoyuan.huang@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=geert+renesas@glider.be \
    --cc=hsinyi@google.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jason-jh.lin@mediatek.com \
    --cc=jernej.skrabec@siol.net \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=moudy.ho@mediatek.com \
    --cc=pihsun@chromium.org \
    --cc=ping-hsun.wu@mediatek.com \
    --cc=randy.wu@mediatek.com \
    --cc=river.cheng@mediatek.com \
    --cc=rob@landley.net \
    --cc=robh+dt@kernel.org \
    --cc=roy-cw.yeh@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@chromium.org \
    --cc=xiandong.wang@mediatek.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