On 9/28/26 10:08 AM, Julien Stephan wrote:
> The mutex serialises the components of a pipeline on the same frame: it
> holds the list of the modules started together and the source of the
> start and end of frame signals driving them.
> 
> Extend the driver, so far only used by the MT8188 HDMI pipeline, with the
> DSI pipeline of the MT8365 and the MT8366: the overlay to the DSI,
> through the colour pipeline on the MT8365 and straight out of the rdma on
> the MT8366, which the per-compatible data selects.
> 
> Two compatibles are added, "mediatek,mt8365-disp-mutex" and
> "mediatek,mt8366-disp-mutex". Neither node declares a generic fallback,
> so both SoC specific strings have to be listed; they also differ in
> the module indices, in the DSI0 module bit the MT8366 needs, and in the
> shift of the end-of-frame selector (6 on the MT8365, 7 on the MT8366).
> 
> The MT8365 mutex has no clock of its own, as "no_clk" in the Linux
> driver says, so the shared component probe now tolerates a node without
> a "clocks" property instead of failing on it.
> 
> The driver includes <dm/device.h> and <dm/device_compat.h>, for the
> dev_err() it now uses, instead of <dm.h>.
> 
> Signed-off-by: Julien Stephan <[email protected]>
> ---
>  drivers/video/mediatek/mtk_disp_comp.c  |   3 +-
>  drivers/video/mediatek/mtk_disp_mutex.c | 120 
> ++++++++++++++++++++++++++++++--
>  drivers/video/mediatek/mtk_disp_mutex.h |   9 +++
>  3 files changed, 125 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/video/mediatek/mtk_disp_comp.c 
> b/drivers/video/mediatek/mtk_disp_comp.c
> index 3846a46f698..5d0e69a75b3 100644
> --- a/drivers/video/mediatek/mtk_disp_comp.c
> +++ b/drivers/video/mediatek/mtk_disp_comp.c
> @@ -114,8 +114,9 @@ int mtk_disp_comp_probe(struct udevice *dev)
>       if (!priv->base)
>               return -EINVAL;
>  
> +     /* some components, such as the MT8365 mutex, have no clock of their 
> own */

Should we make a flag in the driver data for that rather than ignoing error?
Otherwise, we might ignore the wrong error and make it harder to troubleshoot.

>       ret = clk_get_bulk(dev, &priv->clk_bulk);
> -     if (ret) {
> +     if (ret && ret != -ENOENT) {
>               dev_err(dev, "failed to get clocks: %d\n", ret);
>               return ret;
>       }
> diff --git a/drivers/video/mediatek/mtk_disp_mutex.c 
> b/drivers/video/mediatek/mtk_disp_mutex.c
> index 0e1d2e3ead2..36a1fca26b1 100644
> --- a/drivers/video/mediatek/mtk_disp_mutex.c
> +++ b/drivers/video/mediatek/mtk_disp_mutex.c

...

>  void mtk_disp_mutex_config_hdmi(struct udevice *dev)
>  {
>       mtk_disp_comp_write(dev, DISP_MUTEX_SOF(MUTEX_HDMI_ID),
> @@ -65,8 +107,74 @@ void mtk_disp_mutex_config_hdmi(struct udevice *dev)
>       mtk_disp_comp_write(dev, DISP_MUTEX_EN(MUTEX_HDMI_ID), MUTEX_EN);
>  }
>  

Similar to the comment in patch 9 and explained more in patch 11 reply,
we really have more than two pipline possibilities. So we could either
make these generic. Or if the bit flags per SoC don't line up, then just
name these functions after the SoC instead

> +static void mtk_disp_mutex_ovl_dsi_enable_color_pipeline(struct udevice *dev)
> +{
> +     mtk_disp_comp_write(dev, DISP_MUTEX_MOD0(MUTEX_DSI_ID),
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_OVL0) |
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_RDMA0) |
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_COLOR0) |
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_CCORR) |
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_AAL) |
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_GAMMA) |
> +                         MUTEX_MOD_BIT(MT8365_MUTEX_MOD_DISP_DITHER));
> +     mtk_disp_comp_write(dev, DISP_MUTEX_SOF(MUTEX_DSI_ID),
> +                         MT8365_MUTEX_EOF_DSI0 | MT8365_MUTEX_SOF_DSI0);
> +     mtk_disp_comp_write(dev, DISP_MUTEX_EN(MUTEX_DSI_ID), MUTEX_EN);
> +}
> +
> +static void mtk_disp_mutex_ovl_dsi_enable_no_color_pipeline(struct udevice 
> *dev)
> +{
> +     mtk_disp_comp_write(dev, DISP_MUTEX_MOD0(MUTEX_DSI_ID),
> +                         MUTEX_MOD_BIT(MT8366_MUTEX_MOD_DISP_OVL0) |
> +                         MUTEX_MOD_BIT(MT8366_MUTEX_MOD_DISP_RDMA0) |
> +                         MUTEX_MOD_BIT(MT8366_MUTEX_MOD_DISP_DSI0));
> +     mtk_disp_comp_write(dev, DISP_MUTEX_SOF(MUTEX_DSI_ID),
> +                         MT8366_MUTEX_EOF_DSI0 | MT8366_MUTEX_SOF_DSI0);
> +     mtk_disp_comp_write(dev, DISP_MUTEX_EN(MUTEX_DSI_ID), MUTEX_EN);
> +}
> +
> +static const struct mtk_disp_mutex_data mt8365_mutex_data = {
> +     .ovl_dsi_enable = mtk_disp_mutex_ovl_dsi_enable_color_pipeline,
> +};
> +
> +static const struct mtk_disp_mutex_data mt8366_mutex_data = {
> +     .ovl_dsi_enable = mtk_disp_mutex_ovl_dsi_enable_no_color_pipeline,
> +};
> +
> +void mtk_disp_mutex_ovl_dsi_enable(struct udevice *dev)
> +{
> +     struct mtk_disp_mutex_priv *mutex = dev_get_priv(dev);
> +
> +     if (!mutex->data) {
> +             dev_err(dev, "no DSI pipeline on this mutex\n");

Should we perhaps return an error here?

> +             return;
> +     }
> +
> +     mutex->data->ovl_dsi_enable(dev);
> +}
> +

Reply via email to