[PATCH 00/11] Plane Color Pipeline support for MediaTek

[PATCH 00/11] Plane Color Pipeline support for MediaTek

[Nícolas F. R. A. Prado]

This series implements a plane color pipeline for MediaTek platforms,
specifically for MT8195-compatible SoCs.

The pipeline is composed of the following blocks:

Inverse Gamma -> RGB to RGB Color Space Conversion (R2R CSC) -> Gamma
(1D Curve)       (3x3 Matrix)                                   (1D Curve) 

The curves supported by Inverse Gamma are:
* scRGB
* BT.709

The curves supported by Gamma are:
* scRGB
* BT.709
* BT.2020
* HLG

Given the lack of support for writeback connectors on the MediaTek KMS
driver, combined with limited hardware documentation, I haven't been
able to verify the correctness of each curve, only that they were
visually sane (gamma curves made the image on the display brighter,
while inverse gamma made it darker).

This series depends on "drm: Color pipeline teardown and follow-up
fixes/improvements" [1].

This series was tested on the MT8195-Tomato Chromebook.

Regarding the support of color operations in OVL for different SoCs:
* it's not supported by MT8183, and presumably also not by older
  generations
* On MT8192 it's supported by ovl0 and ovl_2l0, but not ovl_2l2 (despite
  the same compatible as ovl_2l0).

For this series I'm only enabling it on MT8195 since that's the one
where I can readily test.

[1] https://lore.kernel.org/all/20251219065614.190834-1-chaitanya.kumar.borah@intel.com/#t

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
Nícolas F. R. A. Prado (11):
      drm/mediatek: Introduce DDP plane_colorops_init() hook
      drm/mediatek: Initialize colorops when creating plane
      drm/mediatek: ovl: Add supports_plane_colorops flag
      drm/mediatek: ovl: Enable per-plane color operations on MT8195
      drm/mediatek: ovl: Implement support for Inverse Gamma
      drm/mediatek: Add plane_colorops_init() DDP hook for OVL
      drm/colorop: Introduce HLG EOTF
      drm/mediatek: ovl: Implement support for Gamma
      drm/colorop: Introduce 3x3 Matrix
      drm/mediatek: ovl: Enable support for R2R Color Space Conversion
      drm/mediatek: Check 3x3 Matrix colorop has DATA set

 drivers/gpu/drm/drm_atomic.c            |   1 +
 drivers/gpu/drm/drm_atomic_uapi.c       |   3 +
 drivers/gpu/drm/drm_colorop.c           |  22 +++
 drivers/gpu/drm/mediatek/mtk_crtc.c     |  36 +++-
 drivers/gpu/drm/mediatek/mtk_ddp_comp.c |   1 +
 drivers/gpu/drm/mediatek/mtk_ddp_comp.h |   2 +
 drivers/gpu/drm/mediatek/mtk_disp_drv.h |   1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 287 ++++++++++++++++++++++++++++++++
 include/drm/drm_colorop.h               |  13 ++
 include/uapi/drm/drm_mode.h             |  16 ++
 10 files changed, 381 insertions(+), 1 deletion(-)
---
base-commit: 1783cdadb70e74a30dfee250f8c2dc13b4e61128
change-id: 20251219-mtk-ovl-pre-blend-colorops-95b7b2883d95

Best regards,
-- 
Nícolas F. R. A. Prado <nfraprado@collabora.com>

[PATCH 01/11] drm/mediatek: Introduce DDP plane_colorops_init() hook

[Nícolas F. R. A. Prado]

Introduce a plane_colorops_init() hook to allow DDP components to define
how to initialize the color pipeline on their planes.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
index 99bf1e1015da..3a7393b7f4c9 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
@@ -13,6 +13,7 @@
 #include <linux/soc/mediatek/mtk-mutex.h>
 
 #include <drm/drm_modes.h>
+#include <drm/drm_plane.h>
 
 struct device;
 struct device_node;
@@ -86,6 +87,7 @@ struct mtk_ddp_comp_funcs {
 	const u32 *(*get_formats)(struct device *dev);
 	size_t (*get_num_formats)(struct device *dev);
 	bool (*is_afbc_supported)(struct device *dev);
+	int (*plane_colorops_init)(struct device *dev, struct drm_plane *plane);
 	void (*connect)(struct device *dev, struct device *mmsys_dev, unsigned int next);
 	void (*disconnect)(struct device *dev, struct device *mmsys_dev, unsigned int next);
 	void (*add)(struct device *dev, struct mtk_mutex *mutex);

-- 
2.51.0

Re: [PATCH 01/11] drm/mediatek: Introduce DDP plane_colorops_init() hook

[AngeloGioacchino Del Regno]

Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> Introduce a plane_colorops_init() hook to allow DDP components to define
> how to initialize the color pipeline on their planes.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Just a nit for the commit description.

In preparation for adding support for per-plane color pipelines, introduce a new
plane_colorops_init() hook to allow [...etc]

Otherwise,
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH 01/11] drm/mediatek: Introduce DDP plane_colorops_init() hook

[Nícolas F. R. A. Prado]

On Fri, 2026-02-06 at 11:07 +0100, AngeloGioacchino Del Regno wrote:
> Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> > Introduce a plane_colorops_init() hook to allow DDP components to
> > define
> > how to initialize the color pipeline on their planes.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> 
> Just a nit for the commit description.
> 
> In preparation for adding support for per-plane color pipelines,
> introduce a new
> plane_colorops_init() hook to allow [...etc]

Will do in v2!

-- 
Thanks,

Nícolas

[PATCH 02/11] drm/mediatek: Initialize colorops when creating plane

[Nícolas F. R. A. Prado]

During initialization of a plane, if the DDP component supplying it
defines a plane_colorops_init() hook, call it to initialize the color
pipeline on the plane.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_crtc.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
index 22f255c3ddd3..f7db235d986f 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -985,8 +985,10 @@ static int mtk_crtc_init_comp_planes(struct drm_device *drm_dev,
 	int i, ret;
 
 	for (i = 0; i < num_planes; i++) {
+		struct drm_plane *plane = &mtk_crtc->planes[mtk_crtc->layer_nr];
+
 		ret = mtk_plane_init(drm_dev,
-				&mtk_crtc->planes[mtk_crtc->layer_nr],
+				plane,
 				BIT(pipe),
 				mtk_crtc_plane_type(mtk_crtc->layer_nr, num_planes),
 				mtk_ddp_comp_supported_rotations(comp),
@@ -997,6 +999,12 @@ static int mtk_crtc_init_comp_planes(struct drm_device *drm_dev,
 		if (ret)
 			return ret;
 
+		if (comp->funcs && comp->funcs->plane_colorops_init) {
+			ret = comp->funcs->plane_colorops_init(comp->dev, plane);
+			if (ret)
+				return ret;
+		}
+
 		mtk_crtc->layer_nr++;
 	}
 	return 0;

-- 
2.51.0

Re: [PATCH 02/11] drm/mediatek: Initialize colorops when creating plane

[AngeloGioacchino Del Regno]

Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> During initialization of a plane, if the DDP component supplying it
> defines a plane_colorops_init() hook, call it to initialize the color
> pipeline on the plane.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

[PATCH 03/11] drm/mediatek: ovl: Add supports_plane_colorops flag

[Nícolas F. R. A. Prado]

Add a supports_plane_colorops flag to the driver data to allow SoCs that
support per-plane color operations to enable support for it in the
driver.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8e20b45411fc..46238c21b0ac 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -150,6 +150,7 @@ struct mtk_disp_ovl_data {
 	const u32 *formats;
 	size_t num_formats;
 	bool supports_clrfmt_ext;
+	bool supports_plane_colorops;
 };
 
 /*

-- 
2.51.0

Re: [PATCH 03/11] drm/mediatek: ovl: Add supports_plane_colorops flag

[Macpaul Lin (林智斌)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> Add a supports_plane_colorops flag to the driver data to allow SoCs
> that
> support per-plane color operations to enable support for it in the
> driver.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 8e20b45411fc..46238c21b0ac 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -150,6 +150,7 @@ struct mtk_disp_ovl_data {
>         const u32 *formats;
>         size_t num_formats;
>         bool supports_clrfmt_ext;
> +       bool supports_plane_colorops;
>  };
> 
>  /*
> 
> --
> 2.51.0
> 
> 

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>

BR,
Macpaul Lin

Re: [PATCH 03/11] drm/mediatek: ovl: Add supports_plane_colorops flag

[AngeloGioacchino Del Regno]

Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> Add a supports_plane_colorops flag to the driver data to allow SoCs that
> support per-plane color operations to enable support for it in the
> driver.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

You should merge this patch [03/11] with [05/11] - so that you introduce the member
in the same commit where you use it.

This patch is a one-liner and it's not doing anything complicated at all :-)

Cheers,
Angelo

> ---
>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 8e20b45411fc..46238c21b0ac 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -150,6 +150,7 @@ struct mtk_disp_ovl_data {
>   	const u32 *formats;
>   	size_t num_formats;
>   	bool supports_clrfmt_ext;
> +	bool supports_plane_colorops;
>   };
>   
>   /*
> 

Re: [PATCH 03/11] drm/mediatek: ovl: Add supports_plane_colorops flag

[Nícolas F. R. A. Prado]

On Fri, 2026-02-06 at 11:07 +0100, AngeloGioacchino Del Regno wrote:
> Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> > Add a supports_plane_colorops flag to the driver data to allow SoCs
> > that
> > support per-plane color operations to enable support for it in the
> > driver.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> 
> You should merge this patch [03/11] with [05/11] - so that you
> introduce the member
> in the same commit where you use it.
> 
> This patch is a one-liner and it's not doing anything complicated at
> all :-)

Sure, will do in v2 :).

-- 
Thanks,

Nícolas

[PATCH 04/11] drm/mediatek: ovl: Enable per-plane color operations on MT8195

[Nícolas F. R. A. Prado]

MT8195's OVL hardware supports per-plane color operations. Enable
support for it in the driver.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 46238c21b0ac..cfc6a3154f73 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -738,6 +738,7 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
 	.fmt_rgb565_is_0 = true,
 	.smi_id_en = true,
 	.supports_afbc = true,
+	.supports_plane_colorops = true,
 	.blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
 		       BIT(DRM_MODE_BLEND_COVERAGE) |
 		       BIT(DRM_MODE_BLEND_PIXEL_NONE),

-- 
2.51.0

Re: [PATCH 04/11] drm/mediatek: ovl: Enable per-plane color operations on MT8195

[Macpaul Lin (林智斌)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> MT8195's OVL hardware supports per-plane color operations. Enable
> support for it in the driver.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 46238c21b0ac..cfc6a3154f73 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -738,6 +738,7 @@ static const struct mtk_disp_ovl_data
> mt8195_ovl_driver_data = {
>         .fmt_rgb565_is_0 = true,
>         .smi_id_en = true,
>         .supports_afbc = true,
> +       .supports_plane_colorops = true,
>         .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
>                        BIT(DRM_MODE_BLEND_COVERAGE) |
>                        BIT(DRM_MODE_BLEND_PIXEL_NONE),
> 
> --
> 2.51.0
> 
> 

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>

Best regards,
Macpaul Lin

Re: [PATCH 04/11] drm/mediatek: ovl: Enable per-plane color operations on MT8195

[AngeloGioacchino Del Regno]

Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> MT8195's OVL hardware supports per-plane color operations. Enable
> support for it in the driver.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Agreed, but you're enabling something that doesn't exist.
Please move this commit at the end, so that you enable it after it's all
implemented.

Cheers,
Angelo

> ---
>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 46238c21b0ac..cfc6a3154f73 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -738,6 +738,7 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
>   	.fmt_rgb565_is_0 = true,
>   	.smi_id_en = true,
>   	.supports_afbc = true,
> +	.supports_plane_colorops = true,
>   	.blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
>   		       BIT(DRM_MODE_BLEND_COVERAGE) |
>   		       BIT(DRM_MODE_BLEND_PIXEL_NONE),
> 

Re: [PATCH 04/11] drm/mediatek: ovl: Enable per-plane color operations on MT8195

[Nícolas F. R. A. Prado]

On Fri, 2026-02-06 at 11:07 +0100, AngeloGioacchino Del Regno wrote:
> Il 23/12/25 20:44, Nícolas F. R. A. Prado ha scritto:
> > MT8195's OVL hardware supports per-plane color operations. Enable
> > support for it in the driver.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> 
> Agreed, but you're enabling something that doesn't exist.
> Please move this commit at the end, so that you enable it after it's
> all
> implemented.

Ack, will do it in v2.

-- 
Thanks,

Nícolas

[PATCH 05/11] drm/mediatek: ovl: Implement support for Inverse Gamma

[Nícolas F. R. A. Prado]

The OVL hardware allows selecting between different fixed transfer
functions for each layer through the Inverse Gamma setting. Available
functions are scRGB and BT.709. Implement support for it and expose it
as a colorop through the DRM plane color pipeline uAPI.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h |   1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 169 ++++++++++++++++++++++++++++++++
 2 files changed, 170 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index e0c30c6c7cc8..fde31e3fcc4a 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -115,6 +115,7 @@ void mtk_ovl_disable_vblank(struct device *dev);
 u32 mtk_ovl_get_blend_modes(struct device *dev);
 const u32 *mtk_ovl_get_formats(struct device *dev);
 size_t mtk_ovl_get_num_formats(struct device *dev);
+int mtk_ovl_plane_colorops_init(struct device *dev, struct drm_plane *plane);
 bool mtk_ovl_is_afbc_supported(struct device *dev);
 
 void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index cfc6a3154f73..4eaa31541ccc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -4,8 +4,11 @@
  */
 
 #include <drm/drm_blend.h>
+#include <drm/drm_colorop.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_framebuffer.h>
+#include <drm/drm_mode.h>
+#include <drm/drm_print.h>
 
 #include <linux/clk.h>
 #include <linux/component.h>
@@ -47,6 +50,12 @@
 #define OVL_CON_CLRFMT_BIT_DEPTH(depth, n)		((depth) << (4 * (n)))
 #define OVL_CON_CLRFMT_8_BIT				(0)
 #define OVL_CON_CLRFMT_10_BIT				(1)
+#define DISP_REG_OVL_WCG_CFG1			0x2d8
+#define IGAMMA_EN(layer)				BIT(0 + 4 * (layer))
+#define DISP_REG_OVL_WCG_CFG2			0x2dc
+#define IGAMMA_MASK(layer)				GENMASK((layer) * 4 + 1, (layer) * 4)
+#define IGAMMA_SCRGB					0
+#define IGAMMA_BT709					1
 #define DISP_REG_OVL_ADDR_MT8173		0x0f40
 #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n))
 #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n) + 0x04)
@@ -492,6 +501,91 @@ static void mtk_ovl_afbc_layer_config(struct mtk_disp_ovl *ovl,
 	}
 }
 
+static int mtk_ovl_colorop_curve_to_reg_val(enum drm_colorop_curve_1d_type curve)
+{
+	switch (curve) {
+	case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
+		return IGAMMA_SCRGB;
+	case DRM_COLOROP_1D_CURVE_BT2020_OETF:
+		return IGAMMA_BT709;
+	default:
+		return -EINVAL;
+	}
+}
+
+static void mtk_ovl_apply_igamma(struct mtk_disp_ovl *ovl, unsigned int idx,
+				 struct drm_colorop *colorop,
+				 struct cmdq_pkt *cmdq_pkt)
+{
+	int curve_reg_val;
+
+	if (colorop->state->bypass) {
+		/* igamma curve needs to be set to default when igamma is disabled */
+		curve_reg_val = IGAMMA_SCRGB;
+	} else {
+		curve_reg_val = mtk_ovl_colorop_curve_to_reg_val(colorop->state->curve_1d_type);
+		if (curve_reg_val < 0) {
+			drm_WARN(ovl->crtc->dev, 1,
+				 "Invalid curve 1d type %u\n",
+				 colorop->state->curve_1d_type);
+			return;
+		}
+	}
+
+	mtk_ddp_write_mask(cmdq_pkt,
+			   field_prep(IGAMMA_MASK(idx), curve_reg_val),
+			   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG2,
+			   IGAMMA_MASK(idx));
+
+	mtk_ddp_write_mask(cmdq_pkt,
+			   colorop->state->bypass ? 0 : IGAMMA_EN(idx),
+			   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG1,
+			   IGAMMA_EN(idx));
+}
+
+static void mtk_ovl_apply_colorop(struct mtk_disp_ovl *ovl, unsigned int idx,
+				  struct drm_colorop *colorop,
+				  struct cmdq_pkt *cmdq_pkt)
+{
+	switch (colorop->type) {
+	case DRM_COLOROP_1D_CURVE:
+		mtk_ovl_apply_igamma(ovl, idx, colorop, cmdq_pkt);
+		break;
+	default:
+		drm_WARN(ovl->crtc->dev, 1, "Invalid colorop type %u\n", colorop->type);
+		break;
+	}
+}
+
+static void mtk_ovl_disable_colorops(struct mtk_disp_ovl *ovl, unsigned int idx,
+				     struct cmdq_pkt *cmdq_pkt)
+{
+	mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl->regs,
+			   DISP_REG_OVL_WCG_CFG1,
+			   IGAMMA_EN(idx));
+
+	/* igamma curve needs to be set to default when igamma is disabled */
+	mtk_ddp_write_mask(cmdq_pkt, IGAMMA_SCRGB, &ovl->cmdq_reg, ovl->regs,
+			   DISP_REG_OVL_WCG_CFG2, IGAMMA_MASK(idx));
+}
+
+static void mtk_ovl_apply_colorops(struct mtk_disp_ovl *ovl, unsigned int idx,
+				   struct mtk_plane_state *state,
+				   struct cmdq_pkt *cmdq_pkt)
+{
+	if (!ovl->data->supports_plane_colorops)
+		return;
+
+	if (!state->base.color_pipeline) {
+		mtk_ovl_disable_colorops(ovl, idx, cmdq_pkt);
+		return;
+	}
+
+	for (struct drm_colorop *colorop = state->base.color_pipeline; colorop;
+	     colorop = colorop->next)
+		mtk_ovl_apply_colorop(ovl, idx, colorop, cmdq_pkt);
+}
+
 void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 			  struct mtk_plane_state *state,
 			  struct cmdq_pkt *cmdq_pkt)
@@ -513,6 +607,8 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 		return;
 	}
 
+	mtk_ovl_apply_colorops(ovl, idx, state, cmdq_pkt);
+
 	con = mtk_ovl_fmt_convert(ovl, state);
 	if (state->base.fb) {
 		con |= state->base.alpha & OVL_CON_ALPHA;
@@ -593,6 +689,79 @@ void mtk_ovl_bgclr_in_off(struct device *dev)
 	writel(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
 }
 
+static const struct drm_colorop_funcs mtk_ovl_colorop_funcs = {
+	.destroy = drm_colorop_destroy,
+};
+
+static const u64 igamma_supported_tfs =
+	BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
+	BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
+
+#define MAX_COLOR_PIPELINE_OPS 3
+
+static int
+mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
+					struct drm_prop_enum_list *pipeline)
+{
+	struct drm_colorop *ops[MAX_COLOR_PIPELINE_OPS];
+	struct drm_device *dev = plane->dev;
+	int i = 0;
+	int ret;
+
+	memset(ops, 0, sizeof(ops));
+
+	/* 1st op: OVL's Inverse Gamma */
+	ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
+	if (!ops[i]) {
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+
+	ret = drm_plane_colorop_curve_1d_init(dev, ops[i], plane,
+					      &mtk_ovl_colorop_funcs,
+					      igamma_supported_tfs,
+					      DRM_COLOROP_FLAG_ALLOW_BYPASS);
+	if (ret)
+		goto err_colorop_init;
+
+	pipeline->type = ops[0]->base.id;
+	pipeline->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", ops[0]->base.id);
+
+	return 0;
+
+err_colorop_init:
+	kfree(ops[i]);
+
+err_alloc:
+	i--;
+	for (; i >= 0; i--) {
+		drm_colorop_cleanup(ops[i]);
+		kfree(ops[i]);
+	}
+
+	return ret;
+}
+
+int mtk_ovl_plane_colorops_init(struct device *dev, struct drm_plane *plane)
+{
+	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+	struct drm_prop_enum_list pipeline = {};
+	int ret;
+
+	if (!ovl->data->supports_plane_colorops)
+		return 0;
+
+	ret = mtk_ovl_initialize_plane_color_pipeline(plane, &pipeline);
+	if (ret)
+		return ret;
+
+	ret = drm_plane_create_color_pipeline_property(plane, &pipeline, 1);
+
+	kfree(pipeline.name);
+
+	return ret;
+}
+
 static int mtk_disp_ovl_bind(struct device *dev, struct device *master,
 			     void *data)
 {

-- 
2.51.0

Re: [PATCH 05/11] drm/mediatek: ovl: Implement support for Inverse Gamma

[CK Hu (胡俊光)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> The OVL hardware allows selecting between different fixed transfer
> functions for each layer through the Inverse Gamma setting. Available
> functions are scRGB and BT.709. Implement support for it and expose it
> as a colorop through the DRM plane color pipeline uAPI.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---

[snip]

> 
>  #include <linux/clk.h>
>  #include <linux/component.h>
> @@ -47,6 +50,12 @@
>  #define OVL_CON_CLRFMT_BIT_DEPTH(depth, n)             ((depth) << (4 * (n)))
>  #define OVL_CON_CLRFMT_8_BIT                           (0)
>  #define OVL_CON_CLRFMT_10_BIT                          (1)
> +#define DISP_REG_OVL_WCG_CFG1                  0x2d8
> +#define IGAMMA_EN(layer)                               BIT(0 + 4 * (layer))

BIT(4 * (layer))

> +#define DISP_REG_OVL_WCG_CFG2                  0x2dc
> +#define IGAMMA_MASK(layer)                             GENMASK((layer) * 4 + 1, (layer) * 4)
> +#define IGAMMA_SCRGB                                   0
> +#define IGAMMA_BT709                                   1
>  #define DISP_REG_OVL_ADDR_MT8173               0x0f40
>  #define DISP_REG_OVL_ADDR(ovl, n)              ((ovl)->data->addr + 0x20 * (n))
>  #define DISP_REG_OVL_HDR_ADDR(ovl, n)          ((ovl)->data->addr + 0x20 * (n) + 0x04)
> @@ -492,6 +501,91 @@ static void mtk_ovl_afbc_layer_config(struct mtk_disp_ovl *ovl,
>         }
>  }
> 
> +static int mtk_ovl_colorop_curve_to_reg_val(enum drm_colorop_curve_1d_type curve)
> +{
> +       switch (curve) {
> +       case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
> +               return IGAMMA_SCRGB;
> +       case DRM_COLOROP_1D_CURVE_BT2020_OETF:

I don't exactly know what DRM_COLOROP_1D_CURVE_BT2020_OETF mean, but there is DRM_COLOROP_1D_CURVE_BT2020_INV_OETF.
This patch is about inverse gamma, so this should be DRM_COLOROP_1D_CURVE_BT2020_INV_OETF?

> +               return IGAMMA_BT709;
> +       default:
> +               return -EINVAL;
> +       }
> +}
> +
> +static void mtk_ovl_apply_igamma(struct mtk_disp_ovl *ovl, unsigned int idx,
> +                                struct drm_colorop *colorop,
> +                                struct cmdq_pkt *cmdq_pkt)
> +{
> +       int curve_reg_val;
> +
> +       if (colorop->state->bypass) {
> +               /* igamma curve needs to be set to default when igamma is disabled */
> +               curve_reg_val = IGAMMA_SCRGB;

I would like to set igamma curve after disable.
So

if (colorop->state->bypass) {
	mtk_ovl_disable_colorops();
	return;
}
	

> +       } else {
> +               curve_reg_val = mtk_ovl_colorop_curve_to_reg_val(colorop->state->curve_1d_type);
> +               if (curve_reg_val < 0) {
> +                       drm_WARN(ovl->crtc->dev, 1,
> +                                "Invalid curve 1d type %u\n",
> +                                colorop->state->curve_1d_type);
> +                       return;
> +               }
> +       }
> +
> +       mtk_ddp_write_mask(cmdq_pkt,
> +                          field_prep(IGAMMA_MASK(idx), curve_reg_val),
> +                          &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG2,
> +                          IGAMMA_MASK(idx));
> +
> +       mtk_ddp_write_mask(cmdq_pkt,
> +                          colorop->state->bypass ? 0 : IGAMMA_EN(idx),
> +                          &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG1,
> +                          IGAMMA_EN(idx));
> +}
> +

[snip]

> 
> +static const struct drm_colorop_funcs mtk_ovl_colorop_funcs = {
> +       .destroy = drm_colorop_destroy,
> +};
> +
> +static const u64 igamma_supported_tfs =
> +       BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
> +       BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
> +
> +#define MAX_COLOR_PIPELINE_OPS 3

Why is 3? Is this hardware limitation?
Provide some information about this value,
so we know it's possible to change it or not.

> +
> +static int
> +mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
> +                                       struct drm_prop_enum_list *pipeline)
> +{
> +       struct drm_colorop *ops[MAX_COLOR_PIPELINE_OPS];
> +       struct drm_device *dev = plane->dev;
> +       int i = 0;
> +       int ret;
> +
> +       memset(ops, 0, sizeof(ops));
> +
> +       /* 1st op: OVL's Inverse Gamma */
> +       ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
> +       if (!ops[i]) {
> +               ret = -ENOMEM;
> +               goto err_alloc;
> +       }
> +
> +       ret = drm_plane_colorop_curve_1d_init(dev, ops[i], plane,
> +                                             &mtk_ovl_colorop_funcs,
> +                                             igamma_supported_tfs,
> +                                             DRM_COLOROP_FLAG_ALLOW_BYPASS);

If other sub driver (maybe ovl adapter) also has inverse gamma,
most part of this function looks common and only mtk_ovl_colorop_funcs and igamma_supported_tfs are sub driver specific.
So move the common part to mtk_crtc.c and sub driver provide function to query mtk_ovl_colorop_funcs and igamma_supported_tfs.
(mtk_ovl_colorop_funcs looks not a sub driver specific function, maybe it could be common part)

Regards,
CK

> +       if (ret)
> +               goto err_colorop_init;
> +
> +       pipeline->type = ops[0]->base.id;
> +       pipeline->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", ops[0]->base.id);
> +
> +       return 0;
> +
> +err_colorop_init:
> +       kfree(ops[i]);
> +
> +err_alloc:
> +       i--;
> +       for (; i >= 0; i--) {
> +               drm_colorop_cleanup(ops[i]);
> +               kfree(ops[i]);
> +       }
> +
> +       return ret;
> +}
> +
> 

Re: [PATCH 05/11] drm/mediatek: ovl: Implement support for Inverse Gamma

[CK Hu (胡俊光)]

On Wed, 2026-02-25 at 08:54 +0000, CK Hu (胡俊光) wrote:
> 
> On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> > External email : Please do not click links or open attachments until you have verified the sender or the content.
> > 
> > 
> > The OVL hardware allows selecting between different fixed transfer
> > functions for each layer through the Inverse Gamma setting. Available
> > functions are scRGB and BT.709. Implement support for it and expose it
> > as a colorop through the DRM plane color pipeline uAPI.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---

[snip]

> > +
> > +#define MAX_COLOR_PIPELINE_OPS 3

After review later patch, this is hardware limitation.
The three ops is:
1. Inverse gamme
2. 3x3 matrix
3. gamme

Please add this information.

> 
> Why is 3? Is this hardware limitation?
> Provide some information about this value,
> so we know it's possible to change it or not.
> 
> > +
> > +static int
> > +mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
> > +                                       struct drm_prop_enum_list *pipeline)
> > +{
> > +       struct drm_colorop *ops[MAX_COLOR_PIPELINE_OPS];
> > +       struct drm_device *dev = plane->dev;
> > +       int i = 0;
> > +       int ret;
> > +
> > +       memset(ops, 0, sizeof(ops));
> > +
> > +       /* 1st op: OVL's Inverse Gamma */
> > +       ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
> > +       if (!ops[i]) {
> > +               ret = -ENOMEM;
> > +               goto err_alloc;
> > +       }
> > +
> > +       ret = drm_plane_colorop_curve_1d_init(dev, ops[i], plane,
> > +                                             &mtk_ovl_colorop_funcs,
> > +                                             igamma_supported_tfs,
> > +                                             DRM_COLOROP_FLAG_ALLOW_BYPASS);
> 
> If other sub driver (maybe ovl adapter) also has inverse gamma,
> most part of this function looks common and only mtk_ovl_colorop_funcs and igamma_supported_tfs are sub driver specific.
> So move the common part to mtk_crtc.c and sub driver provide function to query mtk_ovl_colorop_funcs and igamma_supported_tfs.
> (mtk_ovl_colorop_funcs looks not a sub driver specific function, maybe it could be common part)

Sorry, I've reviewed the later patch, and I find the whole function is sub driver specific.
So forget this comment.

Regards,
CK

> 
> Regards,
> CK
> 
> > +       if (ret)
> > +               goto err_colorop_init;
> > +
> > +       pipeline->type = ops[0]->base.id;
> > +       pipeline->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", ops[0]->base.id);
> > +
> > +       return 0;
> > +
> > +err_colorop_init:
> > +       kfree(ops[i]);
> > +
> > +err_alloc:
> > +       i--;
> > +       for (; i >= 0; i--) {
> > +               drm_colorop_cleanup(ops[i]);
> > +               kfree(ops[i]);
> > +       }
> > +
> > +       return ret;
> > +}
> > +
> > 
> 
> 
> ************* MEDIATEK Confidentiality Notice
>  ********************
> The information contained in this e-mail message (including any 
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be 
> conveyed only to the designated recipient(s). Any use, dissemination, 
> distribution, printing, retaining or copying of this e-mail (including its 
> attachments) by unintended recipient(s) is strictly prohibited and may 
> be unlawful. If you are not an intended recipient of this e-mail, or believe
>  
> 
> 
> 
> that you have received this e-mail in error, please notify the sender 
> immediately (by replying to this e-mail), delete any and all copies of 
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!

[PATCH 06/11] drm/mediatek: Add plane_colorops_init() DDP hook for OVL

[Nícolas F. R. A. Prado]

Hook OVL's plane colorops initialization function in DDP to allow its
usage by the MediaTek KMS driver.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
index 94b356da6de7..ef906b2aff74 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
@@ -331,6 +331,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
 	.get_formats = mtk_ovl_get_formats,
 	.get_num_formats = mtk_ovl_get_num_formats,
 	.is_afbc_supported = mtk_ovl_is_afbc_supported,
+	.plane_colorops_init = mtk_ovl_plane_colorops_init,
 };
 
 static const struct mtk_ddp_comp_funcs ddp_postmask = {

-- 
2.51.0

Re: [PATCH 06/11] drm/mediatek: Add plane_colorops_init() DDP hook for OVL

[Macpaul Lin (林智斌)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> Hook OVL's plane colorops initialization function in DDP to allow its
> usage by the MediaTek KMS driver.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> index 94b356da6de7..ef906b2aff74 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> @@ -331,6 +331,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl =
> {
>         .get_formats = mtk_ovl_get_formats,
>         .get_num_formats = mtk_ovl_get_num_formats,
>         .is_afbc_supported = mtk_ovl_is_afbc_supported,
> +       .plane_colorops_init = mtk_ovl_plane_colorops_init,
>  };
> 
>  static const struct mtk_ddp_comp_funcs ddp_postmask = {
> 
> --
> 2.51.0
> 
> 

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>

Best regards,
Macpaul Lin

Re: [PATCH 06/11] drm/mediatek: Add plane_colorops_init() DDP hook for OVL

[CK Hu (胡俊光)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> Hook OVL's plane colorops initialization function in DDP to allow its
> usage by the MediaTek KMS driver.

Squash this patch into patch [5/11].

Regards,
CK

> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> index 94b356da6de7..ef906b2aff74 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> @@ -331,6 +331,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
>         .get_formats = mtk_ovl_get_formats,
>         .get_num_formats = mtk_ovl_get_num_formats,
>         .is_afbc_supported = mtk_ovl_is_afbc_supported,
> +       .plane_colorops_init = mtk_ovl_plane_colorops_init,
>  };
> 
>  static const struct mtk_ddp_comp_funcs ddp_postmask = {
> 
> --
> 2.51.0
> 

[PATCH 07/11] drm/colorop: Introduce HLG EOTF

[Nícolas F. R. A. Prado]

Introduce definition of a hybrid log-gamma electro-optical transfer
function for 1D Curve colorops.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/drm_colorop.c |  1 +
 include/drm/drm_colorop.h     | 10 ++++++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index fafe45b93ff8..a19e03fb9c7c 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -79,6 +79,7 @@ static const char * const colorop_curve_1d_type_names[] = {
 	[DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
 	[DRM_COLOROP_1D_CURVE_GAMMA22] = "Gamma 2.2",
 	[DRM_COLOROP_1D_CURVE_GAMMA22_INV] = "Gamma 2.2 Inverse",
+	[DRM_COLOROP_1D_CURVE_HLG_EOTF] = "HLG",
 };
 
 static const struct drm_prop_enum_list drm_colorop_lut1d_interpolation_list[] = {
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index ee6454b08b2d..8ec98521607d 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -126,6 +126,16 @@ enum drm_colorop_curve_1d_type {
 	 * The inverse of &DRM_COLOROP_1D_CURVE_GAMMA22
 	 */
 	DRM_COLOROP_1D_CURVE_GAMMA22_INV,
+
+	/**
+	 * @DRM_COLOROP_1D_CURVE_HLG_EOTF:
+	 *
+	 * enum string "HLG"
+	 *
+	 * Hybrid log-gamma transfer function.
+	 */
+	DRM_COLOROP_1D_CURVE_HLG_EOTF,
+
 	/**
 	 * @DRM_COLOROP_1D_CURVE_COUNT:
 	 *

-- 
2.51.0

Re: [PATCH 07/11] drm/colorop: Introduce HLG EOTF

[Macpaul Lin (林智斌)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> Introduce definition of a hybrid log-gamma electro-optical transfer
> function for 1D Curve colorops.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/drm_colorop.c |  1 +
>  include/drm/drm_colorop.h     | 10 ++++++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_colorop.c
> b/drivers/gpu/drm/drm_colorop.c
> index fafe45b93ff8..a19e03fb9c7c 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -79,6 +79,7 @@ static const char * const
> colorop_curve_1d_type_names[] = {
>         [DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
>         [DRM_COLOROP_1D_CURVE_GAMMA22] = "Gamma 2.2",
>         [DRM_COLOROP_1D_CURVE_GAMMA22_INV] = "Gamma 2.2 Inverse",
> +       [DRM_COLOROP_1D_CURVE_HLG_EOTF] = "HLG",
>  };
> 
>  static const struct drm_prop_enum_list
> drm_colorop_lut1d_interpolation_list[] = {
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index ee6454b08b2d..8ec98521607d 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -126,6 +126,16 @@ enum drm_colorop_curve_1d_type {
>          * The inverse of &DRM_COLOROP_1D_CURVE_GAMMA22
>          */
>         DRM_COLOROP_1D_CURVE_GAMMA22_INV,
> +
> +       /**
> +        * @DRM_COLOROP_1D_CURVE_HLG_EOTF:
> +        *
> +        * enum string "HLG"
> +        *
> +        * Hybrid log-gamma transfer function.
> +        */
> +       DRM_COLOROP_1D_CURVE_HLG_EOTF,
> +
>         /**
>          * @DRM_COLOROP_1D_CURVE_COUNT:
>          *
> 
> --
> 2.51.0
> 
> 

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>

Best regards,
Macpaul Lin

Re: [PATCH 07/11] drm/colorop: Introduce HLG EOTF

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Tue, 23 Dec 2025 16:44:48 -0300
Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote:

> Introduce definition of a hybrid log-gamma electro-optical transfer
> function for 1D Curve colorops.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/drm_colorop.c |  1 +
>  include/drm/drm_colorop.h     | 10 ++++++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index fafe45b93ff8..a19e03fb9c7c 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -79,6 +79,7 @@ static const char * const colorop_curve_1d_type_names[] = {
>  	[DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
>  	[DRM_COLOROP_1D_CURVE_GAMMA22] = "Gamma 2.2",
>  	[DRM_COLOROP_1D_CURVE_GAMMA22_INV] = "Gamma 2.2 Inverse",
> +	[DRM_COLOROP_1D_CURVE_HLG_EOTF] = "HLG",
>  };
>  
>  static const struct drm_prop_enum_list drm_colorop_lut1d_interpolation_list[] = {
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index ee6454b08b2d..8ec98521607d 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -126,6 +126,16 @@ enum drm_colorop_curve_1d_type {
>  	 * The inverse of &DRM_COLOROP_1D_CURVE_GAMMA22
>  	 */
>  	DRM_COLOROP_1D_CURVE_GAMMA22_INV,
> +
> +	/**
> +	 * @DRM_COLOROP_1D_CURVE_HLG_EOTF:
> +	 *
> +	 * enum string "HLG"
> +	 *
> +	 * Hybrid log-gamma transfer function.
> +	 */
> +	DRM_COLOROP_1D_CURVE_HLG_EOTF,
> +

Hi,

if you read ITU-R BT.2100[1], you will see that the HLG EOTF has three
parameters: the system gamma, the display nominal peak luminance, and
the display black luminance. You cannot define a HLG EOTF or its
inverse without these parameters. One might assume to derive the system
gamma from the peak luminance, but I would like to leave that as a free
parameter if possible, because I'm not convinced the formulas for it are
universally applicable.

The HLG OETF on the other hand is a fixed function. Did you mean that
instead?


[1]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt2100


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 07/11] drm/colorop: Introduce HLG EOTF

[Nícolas F. R. A. Prado]

On Fri, 2026-02-06 at 10:51 +0200, Pekka Paalanen wrote:
> On Tue, 23 Dec 2025 16:44:48 -0300
> Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote:
> 
> > Introduce definition of a hybrid log-gamma electro-optical transfer
> > function for 1D Curve colorops.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
> >  drivers/gpu/drm/drm_colorop.c |  1 +
> >  include/drm/drm_colorop.h     | 10 ++++++++++
> >  2 files changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c
> > index fafe45b93ff8..a19e03fb9c7c 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -79,6 +79,7 @@ static const char * const
> > colorop_curve_1d_type_names[] = {
> >  	[DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
> >  	[DRM_COLOROP_1D_CURVE_GAMMA22] = "Gamma 2.2",
> >  	[DRM_COLOROP_1D_CURVE_GAMMA22_INV] = "Gamma 2.2 Inverse",
> > +	[DRM_COLOROP_1D_CURVE_HLG_EOTF] = "HLG",
> >  };
> >  
> >  static const struct drm_prop_enum_list
> > drm_colorop_lut1d_interpolation_list[] = {
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index ee6454b08b2d..8ec98521607d 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -126,6 +126,16 @@ enum drm_colorop_curve_1d_type {
> >  	 * The inverse of &DRM_COLOROP_1D_CURVE_GAMMA22
> >  	 */
> >  	DRM_COLOROP_1D_CURVE_GAMMA22_INV,
> > +
> > +	/**
> > +	 * @DRM_COLOROP_1D_CURVE_HLG_EOTF:
> > +	 *
> > +	 * enum string "HLG"
> > +	 *
> > +	 * Hybrid log-gamma transfer function.
> > +	 */
> > +	DRM_COLOROP_1D_CURVE_HLG_EOTF,
> > +
> 
> Hi,
> 
> if you read ITU-R BT.2100[1], you will see that the HLG EOTF has
> three
> parameters: the system gamma, the display nominal peak luminance, and
> the display black luminance. You cannot define a HLG EOTF or its
> inverse without these parameters. One might assume to derive the
> system
> gamma from the peak luminance, but I would like to leave that as a
> free
> parameter if possible, because I'm not convinced the formulas for it
> are
> universally applicable.
> 
> The HLG OETF on the other hand is a fixed function. Did you mean that
> instead?

Thank you for the insights! But as it's obvious by now I don't have
enough information to answer that. Hopefully someone from MediaTek
could clarify what is the precise function implemented in hardware.

I didn't know about this difference between the HLG EOTF and OETF, but
what made me guess it would be the EOTF is that this curve is available
at the GAMMA block, which is right before blending the planes (the
pipeline topology I reverse-engineered from testing is on the cover-
letter), which I believe is usually done in the optical domain. But I
suppose one option would be that this curve really is the Inverse HLG
OETF, which wouldn't require additional parameters and also brings the
content to the optical domain.

-- 
Thanks,

Nícolas

[PATCH 08/11] drm/mediatek: ovl: Implement support for Gamma

[Nícolas F. R. A. Prado]

The OVL hardware allows selecting between different fixed transfer
functions for each layer through the Gamma setting. Available
functions are scRGB, BT.709, BT.2020 and HLG. Implement support for it
and expose it as a colorop through the DRM plane color pipeline uAPI.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 67 ++++++++++++++++++++++++++++++++-
 1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 4eaa31541ccc..a70092c792a9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -52,10 +52,16 @@
 #define OVL_CON_CLRFMT_10_BIT				(1)
 #define DISP_REG_OVL_WCG_CFG1			0x2d8
 #define IGAMMA_EN(layer)				BIT(0 + 4 * (layer))
+#define GAMMA_EN(layer)					BIT(2 + 4 * (layer))
 #define DISP_REG_OVL_WCG_CFG2			0x2dc
 #define IGAMMA_MASK(layer)				GENMASK((layer) * 4 + 1, (layer) * 4)
 #define IGAMMA_SCRGB					0
 #define IGAMMA_BT709					1
+#define GAMMA_MASK(layer)				GENMASK((layer) * 4 + 3, (layer) * 4 + 2)
+#define GAMMA_SCRGB					0
+#define GAMMA_BT709					1
+#define GAMMA_BT2020					2
+#define GAMMA_HLG					3
 #define DISP_REG_OVL_ADDR_MT8173		0x0f40
 #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n))
 #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n) + 0x04)
@@ -508,11 +514,41 @@ static int mtk_ovl_colorop_curve_to_reg_val(enum drm_colorop_curve_1d_type curve
 		return IGAMMA_SCRGB;
 	case DRM_COLOROP_1D_CURVE_BT2020_OETF:
 		return IGAMMA_BT709;
+	case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
+		return GAMMA_SCRGB;
+	case DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:
+		return GAMMA_BT2020;
+	case DRM_COLOROP_1D_CURVE_HLG_EOTF:
+		return GAMMA_HLG;
 	default:
 		return -EINVAL;
 	}
 }
 
+static void mtk_ovl_apply_gamma(struct mtk_disp_ovl *ovl, unsigned int idx,
+				struct drm_colorop *colorop,
+				struct cmdq_pkt *cmdq_pkt)
+{
+	int curve_reg_val;
+
+	curve_reg_val = mtk_ovl_colorop_curve_to_reg_val(colorop->state->curve_1d_type);
+	if (curve_reg_val < 0) {
+		drm_WARN(ovl->crtc->dev, 1, "Invalid curve 1d type %u\n",
+			 colorop->state->curve_1d_type);
+		return;
+	}
+
+	mtk_ddp_write_mask(cmdq_pkt,
+			   field_prep(GAMMA_MASK(idx), curve_reg_val),
+			   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG2,
+			   GAMMA_MASK(idx));
+
+	mtk_ddp_write_mask(cmdq_pkt,
+			   colorop->state->bypass ? 0 : GAMMA_EN(idx),
+			   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG1,
+			   GAMMA_EN(idx));
+}
+
 static void mtk_ovl_apply_igamma(struct mtk_disp_ovl *ovl, unsigned int idx,
 				 struct drm_colorop *colorop,
 				 struct cmdq_pkt *cmdq_pkt)
@@ -549,7 +585,11 @@ static void mtk_ovl_apply_colorop(struct mtk_disp_ovl *ovl, unsigned int idx,
 {
 	switch (colorop->type) {
 	case DRM_COLOROP_1D_CURVE:
-		mtk_ovl_apply_igamma(ovl, idx, colorop, cmdq_pkt);
+		/* gamma is the last colorop in pipeline */
+		if (!colorop->next)
+			mtk_ovl_apply_gamma(ovl, idx, colorop, cmdq_pkt);
+		else
+			mtk_ovl_apply_igamma(ovl, idx, colorop, cmdq_pkt);
 		break;
 	default:
 		drm_WARN(ovl->crtc->dev, 1, "Invalid colorop type %u\n", colorop->type);
@@ -562,7 +602,7 @@ static void mtk_ovl_disable_colorops(struct mtk_disp_ovl *ovl, unsigned int idx,
 {
 	mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl->regs,
 			   DISP_REG_OVL_WCG_CFG1,
-			   IGAMMA_EN(idx));
+			   IGAMMA_EN(idx) | GAMMA_EN(idx));
 
 	/* igamma curve needs to be set to default when igamma is disabled */
 	mtk_ddp_write_mask(cmdq_pkt, IGAMMA_SCRGB, &ovl->cmdq_reg, ovl->regs,
@@ -697,6 +737,11 @@ static const u64 igamma_supported_tfs =
 	BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
 	BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
 
+static const u64 gamma_supported_tfs =
+	BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+	BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF) |
+	BIT(DRM_COLOROP_1D_CURVE_HLG_EOTF);
+
 #define MAX_COLOR_PIPELINE_OPS 3
 
 static int
@@ -724,6 +769,24 @@ mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
 	if (ret)
 		goto err_colorop_init;
 
+	i++;
+
+	/* 3rd op: OVL's Gamma */
+	ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
+	if (!ops[i]) {
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+
+	ret = drm_plane_colorop_curve_1d_init(dev, ops[i], plane,
+					      &mtk_ovl_colorop_funcs,
+					      gamma_supported_tfs,
+					      DRM_COLOROP_FLAG_ALLOW_BYPASS);
+	if (ret)
+		goto err_colorop_init;
+
+	drm_colorop_set_next_property(ops[i - 1], ops[i]);
+
 	pipeline->type = ops[0]->base.id;
 	pipeline->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", ops[0]->base.id);
 

-- 
2.51.0

Re: [PATCH 08/11] drm/mediatek: ovl: Implement support for Gamma

[CK Hu (胡俊光)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> The OVL hardware allows selecting between different fixed transfer
> functions for each layer through the Gamma setting. Available
> functions are scRGB, BT.709, BT.2020 and HLG. Implement support for it
> and expose it as a colorop through the DRM plane color pipeline uAPI.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 67 ++++++++++++++++++++++++++++++++-
>  1 file changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4eaa31541ccc..a70092c792a9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -52,10 +52,16 @@
>  #define OVL_CON_CLRFMT_10_BIT                          (1)
>  #define DISP_REG_OVL_WCG_CFG1                  0x2d8
>  #define IGAMMA_EN(layer)                               BIT(0 + 4 * (layer))
> +#define GAMMA_EN(layer)                                        BIT(2 + 4 * (layer))
>  #define DISP_REG_OVL_WCG_CFG2                  0x2dc
>  #define IGAMMA_MASK(layer)                             GENMASK((layer) * 4 + 1, (layer) * 4)
>  #define IGAMMA_SCRGB                                   0
>  #define IGAMMA_BT709                                   1
> +#define GAMMA_MASK(layer)                              GENMASK((layer) * 4 + 3, (layer) * 4 + 2)
> +#define GAMMA_SCRGB                                    0
> +#define GAMMA_BT709                                    1
> +#define GAMMA_BT2020                                   2
> +#define GAMMA_HLG                                      3
>  #define DISP_REG_OVL_ADDR_MT8173               0x0f40
>  #define DISP_REG_OVL_ADDR(ovl, n)              ((ovl)->data->addr + 0x20 * (n))
>  #define DISP_REG_OVL_HDR_ADDR(ovl, n)          ((ovl)->data->addr + 0x20 * (n) + 0x04)
> @@ -508,11 +514,41 @@ static int mtk_ovl_colorop_curve_to_reg_val(enum drm_colorop_curve_1d_type curve
>                 return IGAMMA_SCRGB;
>         case DRM_COLOROP_1D_CURVE_BT2020_OETF:
>                 return IGAMMA_BT709;
> +       case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
> +               return GAMMA_SCRGB;
> +       case DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:

Maybe DRM_COLOROP_1D_CURVE_BT2020_OETF?

> +               return GAMMA_BT2020;
> +       case DRM_COLOROP_1D_CURVE_HLG_EOTF:
> +               return GAMMA_HLG;

igamma and gamma use the same function mtk_ovl_colorop_curve_to_reg_val() to check.
If curve is DRM_COLOROP_1D_CURVE_HLG_EOTF for igamma, error happen but not detected.

>         default:
>                 return -EINVAL;
>         }
>  }
> 
> +static void mtk_ovl_apply_gamma(struct mtk_disp_ovl *ovl, unsigned int idx,
> +                               struct drm_colorop *colorop,
> +                               struct cmdq_pkt *cmdq_pkt)
> +{
> +       int curve_reg_val;
> +
> +       curve_reg_val = mtk_ovl_colorop_curve_to_reg_val(colorop->state->curve_1d_type);
> +       if (curve_reg_val < 0) {
> +               drm_WARN(ovl->crtc->dev, 1, "Invalid curve 1d type %u\n",
> +                        colorop->state->curve_1d_type);
> +               return;
> +       }
> +
> +       mtk_ddp_write_mask(cmdq_pkt,
> +                          field_prep(GAMMA_MASK(idx), curve_reg_val),
> +                          &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG2,
> +                          GAMMA_MASK(idx));
> +

When gamma is disable, I would like to disable first then clear curve value.

> +       mtk_ddp_write_mask(cmdq_pkt,
> +                          colorop->state->bypass ? 0 : GAMMA_EN(idx),
> +                          &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG1,
> +                          GAMMA_EN(idx));
> +}
> +
>  static void mtk_ovl_apply_igamma(struct mtk_disp_ovl *ovl, unsigned int idx,
>                                  struct drm_colorop *colorop,
>                                  struct cmdq_pkt *cmdq_pkt)
> @@ -549,7 +585,11 @@ static void mtk_ovl_apply_colorop(struct mtk_disp_ovl *ovl, unsigned int idx,
>  {
>         switch (colorop->type) {
>         case DRM_COLOROP_1D_CURVE:
> -               mtk_ovl_apply_igamma(ovl, idx, colorop, cmdq_pkt);
> +               /* gamma is the last colorop in pipeline */
> +               if (!colorop->next)
> +                       mtk_ovl_apply_gamma(ovl, idx, colorop, cmdq_pkt);
> +               else
> +                       mtk_ovl_apply_igamma(ovl, idx, colorop, cmdq_pkt);
>                 break;
>         default:
>                 drm_WARN(ovl->crtc->dev, 1, "Invalid colorop type %u\n", colorop->type);
> @@ -562,7 +602,7 @@ static void mtk_ovl_disable_colorops(struct mtk_disp_ovl *ovl, unsigned int idx,
>  {
>         mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl->regs,
>                            DISP_REG_OVL_WCG_CFG1,
> -                          IGAMMA_EN(idx));
> +                          IGAMMA_EN(idx) | GAMMA_EN(idx));
> 
>         /* igamma curve needs to be set to default when igamma is disabled */
>         mtk_ddp_write_mask(cmdq_pkt, IGAMMA_SCRGB, &ovl->cmdq_reg, ovl->regs,
> @@ -697,6 +737,11 @@ static const u64 igamma_supported_tfs =
>         BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
>         BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
> 
> +static const u64 gamma_supported_tfs =
> +       BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
> +       BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF) |
> +       BIT(DRM_COLOROP_1D_CURVE_HLG_EOTF);
> +
>  #define MAX_COLOR_PIPELINE_OPS 3
> 
>  static int
> @@ -724,6 +769,24 @@ mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
>         if (ret)
>                 goto err_colorop_init;
> 
> +       i++;
> +
> +       /* 3rd op: OVL's Gamma */

I would like you apply patch order according to op order.
So apply 3x3 matrix patch before this patch.

> +       ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);

variable i is not necessary.
Use constant value is enough.

Regards,
CK

> +       if (!ops[i]) {
> +               ret = -ENOMEM;
> +               goto err_alloc;
> +       }
> +
> +       ret = drm_plane_colorop_curve_1d_init(dev, ops[i], plane,
> +                                             &mtk_ovl_colorop_funcs,
> +                                             gamma_supported_tfs,
> +                                             DRM_COLOROP_FLAG_ALLOW_BYPASS);
> +       if (ret)
> +               goto err_colorop_init;
> +
> +       drm_colorop_set_next_property(ops[i - 1], ops[i]);
> +
>         pipeline->type = ops[0]->base.id;
>         pipeline->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", ops[0]->base.id);
> 
> 
> --
> 2.51.0
> 

Re: [PATCH 08/11] drm/mediatek: ovl: Implement support for Gamma

[Nícolas F. R. A. Prado]

On Tue, 2026-03-03 at 06:53 +0000, CK Hu (胡俊光) wrote:
> On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> > External email : Please do not click links or open attachments
> > until you have verified the sender or the content.
> > 
> > 
> > The OVL hardware allows selecting between different fixed transfer
> > functions for each layer through the Gamma setting. Available
> > functions are scRGB, BT.709, BT.2020 and HLG. Implement support for
> > it
> > and expose it as a colorop through the DRM plane color pipeline
> > uAPI.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 67
> > ++++++++++++++++++++++++++++++++-
> >  1 file changed, 65 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 4eaa31541ccc..a70092c792a9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -52,10 +52,16 @@
> >  #define OVL_CON_CLRFMT_10_BIT                          (1)
> >  #define DISP_REG_OVL_WCG_CFG1                  0x2d8
> >  #define IGAMMA_EN(layer)                               BIT(0 + 4 *
> > (layer))
> > +#define GAMMA_EN(layer)                                       
> > BIT(2 + 4 * (layer))
> >  #define DISP_REG_OVL_WCG_CFG2                  0x2dc
> >  #define IGAMMA_MASK(layer)                            
> > GENMASK((layer) * 4 + 1, (layer) * 4)
> >  #define IGAMMA_SCRGB                                   0
> >  #define IGAMMA_BT709                                   1
> > +#define GAMMA_MASK(layer)                             
> > GENMASK((layer) * 4 + 3, (layer) * 4 + 2)
> > +#define GAMMA_SCRGB                                    0
> > +#define GAMMA_BT709                                    1
> > +#define GAMMA_BT2020                                   2
> > +#define GAMMA_HLG                                      3
> >  #define DISP_REG_OVL_ADDR_MT8173               0x0f40
> >  #define DISP_REG_OVL_ADDR(ovl, n)              ((ovl)->data->addr
> > + 0x20 * (n))
> >  #define DISP_REG_OVL_HDR_ADDR(ovl, n)          ((ovl)->data->addr
> > + 0x20 * (n) + 0x04)
> > @@ -508,11 +514,41 @@ static int
> > mtk_ovl_colorop_curve_to_reg_val(enum drm_colorop_curve_1d_type
> > curve
> >                 return IGAMMA_SCRGB;
> >         case DRM_COLOROP_1D_CURVE_BT2020_OETF:
> >                 return IGAMMA_BT709;
> > +       case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
> > +               return GAMMA_SCRGB;
> > +       case DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:
> 
> Maybe DRM_COLOROP_1D_CURVE_BT2020_OETF?

That is the kind of thing that is just guessing unless we can verify
through writeback or through official documentation of the hardware.
Just because a block is called "Inverse Gamma" it doesn't guarantee
that all curves should have inverse in their names. Some specifications
define EOTF curves, others define OETF curves. The inverse curves are
the inverse functions of a given EOTF or OETF curve, which are often
mathematically derived and not explicitly mentioned in the specs.

As for the other comments I'll address them in a following version.

Thanks,
Nícolas
> 

[PATCH 09/11] drm/colorop: Introduce 3x3 Matrix

[Nícolas F. R. A. Prado]

Introduce a 3x3 Matrix colorop analogous to the 3x4 Matrix colorop, with
the difference of not supporting offset coefficients.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/drm_atomic.c      |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c |  3 +++
 drivers/gpu/drm/drm_colorop.c     | 21 +++++++++++++++++++++
 include/drm/drm_colorop.h         |  3 +++
 include/uapi/drm/drm_mode.h       | 16 ++++++++++++++++
 5 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6d3ea8056b60..bf4a31c02b70 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -802,6 +802,7 @@ static void drm_atomic_colorop_print_state(struct drm_printer *p,
 		drm_printf(p, "\tdata blob id=%d\n", state->data ? state->data->base.id : 0);
 		break;
 	case DRM_COLOROP_CTM_3X4:
+	case DRM_COLOROP_CTM_3X3:
 		drm_printf(p, "\tdata blob id=%d\n", state->data ? state->data->base.id : 0);
 		break;
 	case DRM_COLOROP_MULTIPLIER:
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 7320db4b8489..7a70e894a2ef 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -709,6 +709,9 @@ static int drm_atomic_color_set_data_property(struct drm_colorop *colorop,
 		size = colorop->size * colorop->size * colorop->size *
 		       sizeof(struct drm_color_lut32);
 		break;
+	case DRM_COLOROP_CTM_3X3:
+		size = sizeof(struct drm_color_ctm);
+		break;
 	default:
 		/* should never get here */
 		return -EINVAL;
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index a19e03fb9c7c..51c1a0726dfa 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -68,6 +68,7 @@ static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
 	{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
 	{ DRM_COLOROP_MULTIPLIER, "Multiplier"},
 	{ DRM_COLOROP_3D_LUT, "3D LUT"},
+	{ DRM_COLOROP_CTM_3X3, "3x3 Matrix"},
 };
 
 static const char * const colorop_curve_1d_type_names[] = {
@@ -377,6 +378,26 @@ int drm_plane_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop *c
 }
 EXPORT_SYMBOL(drm_plane_colorop_ctm_3x4_init);
 
+int drm_plane_colorop_ctm_3x3_init(struct drm_device *dev, struct drm_colorop *colorop,
+				   struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
+				   uint32_t flags)
+{
+	int ret;
+
+	ret = drm_plane_colorop_init(dev, colorop, plane, funcs, DRM_COLOROP_CTM_3X3, flags);
+	if (ret)
+		return ret;
+
+	ret = drm_colorop_create_data_prop(dev, colorop);
+	if (ret)
+		return ret;
+
+	drm_colorop_reset(colorop);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_plane_colorop_ctm_3x3_init);
+
 /**
  * drm_plane_colorop_mult_init - Initialize a DRM_COLOROP_MULTIPLIER
  *
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 8ec98521607d..ee7fa0eb5dbf 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -426,6 +426,9 @@ int drm_plane_colorop_curve_1d_lut_init(struct drm_device *dev, struct drm_color
 int drm_plane_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop *colorop,
 				   struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
 				   uint32_t flags);
+int drm_plane_colorop_ctm_3x3_init(struct drm_device *dev, struct drm_colorop *colorop,
+				   struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
+				   uint32_t flags);
 int drm_plane_colorop_mult_init(struct drm_device *dev, struct drm_colorop *colorop,
 				struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
 				uint32_t flags);
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index cbbbfc1dfe2b..b894b19eb9f8 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -964,6 +964,22 @@ enum drm_colorop_type {
 	 *         color = lut3d[index]
 	 */
 	DRM_COLOROP_3D_LUT,
+
+	/**
+	 * @DRM_COLOROP_CTM_3X3:
+	 *
+	 * enum string "3x3 Matrix"
+	 *
+	 * A 3x3 matrix. Its values are specified via the
+	 * &drm_color_ctm struct provided via the DATA property.
+	 *
+	 * The DATA blob is a float[9]:
+	 * out   matrix          in
+	 * | R |   | 0  1  2 |   | R |
+	 * | G | = | 3  4  5 | x | G |
+	 * | B |   | 6  7  8 |   | B |
+	 */
+	DRM_COLOROP_CTM_3X3,
 };
 
 /**

-- 
2.51.0

Re: [PATCH 09/11] drm/colorop: Introduce 3x3 Matrix

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 5346 bytes --]

On Tue, 23 Dec 2025 16:44:50 -0300
Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote:

> Introduce a 3x3 Matrix colorop analogous to the 3x4 Matrix colorop, with
> the difference of not supporting offset coefficients.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/drm_atomic.c      |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  3 +++
>  drivers/gpu/drm/drm_colorop.c     | 21 +++++++++++++++++++++
>  include/drm/drm_colorop.h         |  3 +++
>  include/uapi/drm/drm_mode.h       | 16 ++++++++++++++++
>  5 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 6d3ea8056b60..bf4a31c02b70 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -802,6 +802,7 @@ static void drm_atomic_colorop_print_state(struct drm_printer *p,
>  		drm_printf(p, "\tdata blob id=%d\n", state->data ? state->data->base.id : 0);
>  		break;
>  	case DRM_COLOROP_CTM_3X4:
> +	case DRM_COLOROP_CTM_3X3:
>  		drm_printf(p, "\tdata blob id=%d\n", state->data ? state->data->base.id : 0);
>  		break;
>  	case DRM_COLOROP_MULTIPLIER:
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 7320db4b8489..7a70e894a2ef 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -709,6 +709,9 @@ static int drm_atomic_color_set_data_property(struct drm_colorop *colorop,
>  		size = colorop->size * colorop->size * colorop->size *
>  		       sizeof(struct drm_color_lut32);
>  		break;
> +	case DRM_COLOROP_CTM_3X3:
> +		size = sizeof(struct drm_color_ctm);
> +		break;
>  	default:
>  		/* should never get here */
>  		return -EINVAL;
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index a19e03fb9c7c..51c1a0726dfa 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -68,6 +68,7 @@ static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
>  	{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
>  	{ DRM_COLOROP_MULTIPLIER, "Multiplier"},
>  	{ DRM_COLOROP_3D_LUT, "3D LUT"},
> +	{ DRM_COLOROP_CTM_3X3, "3x3 Matrix"},
>  };
>  
>  static const char * const colorop_curve_1d_type_names[] = {
> @@ -377,6 +378,26 @@ int drm_plane_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop *c
>  }
>  EXPORT_SYMBOL(drm_plane_colorop_ctm_3x4_init);
>  
> +int drm_plane_colorop_ctm_3x3_init(struct drm_device *dev, struct drm_colorop *colorop,
> +				   struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
> +				   uint32_t flags)
> +{
> +	int ret;
> +
> +	ret = drm_plane_colorop_init(dev, colorop, plane, funcs, DRM_COLOROP_CTM_3X3, flags);
> +	if (ret)
> +		return ret;
> +
> +	ret = drm_colorop_create_data_prop(dev, colorop);
> +	if (ret)
> +		return ret;
> +
> +	drm_colorop_reset(colorop);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_colorop_ctm_3x3_init);
> +
>  /**
>   * drm_plane_colorop_mult_init - Initialize a DRM_COLOROP_MULTIPLIER
>   *
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index 8ec98521607d..ee7fa0eb5dbf 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -426,6 +426,9 @@ int drm_plane_colorop_curve_1d_lut_init(struct drm_device *dev, struct drm_color
>  int drm_plane_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop *colorop,
>  				   struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
>  				   uint32_t flags);
> +int drm_plane_colorop_ctm_3x3_init(struct drm_device *dev, struct drm_colorop *colorop,
> +				   struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
> +				   uint32_t flags);
>  int drm_plane_colorop_mult_init(struct drm_device *dev, struct drm_colorop *colorop,
>  				struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
>  				uint32_t flags);
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index cbbbfc1dfe2b..b894b19eb9f8 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -964,6 +964,22 @@ enum drm_colorop_type {
>  	 *         color = lut3d[index]
>  	 */
>  	DRM_COLOROP_3D_LUT,
> +
> +	/**
> +	 * @DRM_COLOROP_CTM_3X3:
> +	 *
> +	 * enum string "3x3 Matrix"
> +	 *
> +	 * A 3x3 matrix. Its values are specified via the
> +	 * &drm_color_ctm struct provided via the DATA property.
> +	 *
> +	 * The DATA blob is a float[9]:
> +	 * out   matrix          in
> +	 * | R |   | 0  1  2 |   | R |
> +	 * | G | = | 3  4  5 | x | G |
> +	 * | B |   | 6  7  8 |   | B |
> +	 */
> +	DRM_COLOROP_CTM_3X3,
>  };
>  
>  /**
> 

Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>

FWIW, the statement "The DATA blob is a float[9]" is incorrect, but the
same wording exists already with the DRM_COLOROP_CTM_3X4. The data type
is not a float, nor is it a float reinterpreted as __u64 (they are not
even the same size). Documentation for the structs explains the correct
type, which is a fixed-point number.

The struct types document also the layout, so there is no need to
repeat the layout here. It may be worth mentioning that the blob must
contain exactly one instance of the struct.


Thanks,
pq


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 09/11] drm/colorop: Introduce 3x3 Matrix

[Nícolas F. R. A. Prado]

On Fri, 2026-02-06 at 11:27 +0200, Pekka Paalanen wrote:
> On Tue, 23 Dec 2025 16:44:50 -0300
> Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote:
> 
> > Introduce a 3x3 Matrix colorop analogous to the 3x4 Matrix colorop,
> > with
> > the difference of not supporting offset coefficients.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
> >  drivers/gpu/drm/drm_atomic.c      |  1 +
> >  drivers/gpu/drm/drm_atomic_uapi.c |  3 +++
> >  drivers/gpu/drm/drm_colorop.c     | 21 +++++++++++++++++++++
> >  include/drm/drm_colorop.h         |  3 +++
> >  include/uapi/drm/drm_mode.h       | 16 ++++++++++++++++
> >  5 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c
> > b/drivers/gpu/drm/drm_atomic.c
> > index 6d3ea8056b60..bf4a31c02b70 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -802,6 +802,7 @@ static void
> > drm_atomic_colorop_print_state(struct drm_printer *p,
> >  		drm_printf(p, "\tdata blob id=%d\n", state->data ?
> > state->data->base.id : 0);
> >  		break;
> >  	case DRM_COLOROP_CTM_3X4:
> > +	case DRM_COLOROP_CTM_3X3:
> >  		drm_printf(p, "\tdata blob id=%d\n", state->data ?
> > state->data->base.id : 0);
> >  		break;
> >  	case DRM_COLOROP_MULTIPLIER:
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 7320db4b8489..7a70e894a2ef 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -709,6 +709,9 @@ static int
> > drm_atomic_color_set_data_property(struct drm_colorop *colorop,
> >  		size = colorop->size * colorop->size * colorop-
> > >size *
> >  		       sizeof(struct drm_color_lut32);
> >  		break;
> > +	case DRM_COLOROP_CTM_3X3:
> > +		size = sizeof(struct drm_color_ctm);
> > +		break;
> >  	default:
> >  		/* should never get here */
> >  		return -EINVAL;
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c
> > index a19e03fb9c7c..51c1a0726dfa 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -68,6 +68,7 @@ static const struct drm_prop_enum_list
> > drm_colorop_type_enum_list[] = {
> >  	{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
> >  	{ DRM_COLOROP_MULTIPLIER, "Multiplier"},
> >  	{ DRM_COLOROP_3D_LUT, "3D LUT"},
> > +	{ DRM_COLOROP_CTM_3X3, "3x3 Matrix"},
> >  };
> >  
> >  static const char * const colorop_curve_1d_type_names[] = {
> > @@ -377,6 +378,26 @@ int drm_plane_colorop_ctm_3x4_init(struct
> > drm_device *dev, struct drm_colorop *c
> >  }
> >  EXPORT_SYMBOL(drm_plane_colorop_ctm_3x4_init);
> >  
> > +int drm_plane_colorop_ctm_3x3_init(struct drm_device *dev, struct
> > drm_colorop *colorop,
> > +				   struct drm_plane *plane, const
> > struct drm_colorop_funcs *funcs,
> > +				   uint32_t flags)
> > +{
> > +	int ret;
> > +
> > +	ret = drm_plane_colorop_init(dev, colorop, plane, funcs,
> > DRM_COLOROP_CTM_3X3, flags);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = drm_colorop_create_data_prop(dev, colorop);
> > +	if (ret)
> > +		return ret;
> > +
> > +	drm_colorop_reset(colorop);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(drm_plane_colorop_ctm_3x3_init);
> > +
> >  /**
> >   * drm_plane_colorop_mult_init - Initialize a
> > DRM_COLOROP_MULTIPLIER
> >   *
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index 8ec98521607d..ee7fa0eb5dbf 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -426,6 +426,9 @@ int drm_plane_colorop_curve_1d_lut_init(struct
> > drm_device *dev, struct drm_color
> >  int drm_plane_colorop_ctm_3x4_init(struct drm_device *dev, struct
> > drm_colorop *colorop,
> >  				   struct drm_plane *plane, const
> > struct drm_colorop_funcs *funcs,
> >  				   uint32_t flags);
> > +int drm_plane_colorop_ctm_3x3_init(struct drm_device *dev, struct
> > drm_colorop *colorop,
> > +				   struct drm_plane *plane, const
> > struct drm_colorop_funcs *funcs,
> > +				   uint32_t flags);
> >  int drm_plane_colorop_mult_init(struct drm_device *dev, struct
> > drm_colorop *colorop,
> >  				struct drm_plane *plane, const
> > struct drm_colorop_funcs *funcs,
> >  				uint32_t flags);
> > diff --git a/include/uapi/drm/drm_mode.h
> > b/include/uapi/drm/drm_mode.h
> > index cbbbfc1dfe2b..b894b19eb9f8 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -964,6 +964,22 @@ enum drm_colorop_type {
> >  	 *         color = lut3d[index]
> >  	 */
> >  	DRM_COLOROP_3D_LUT,
> > +
> > +	/**
> > +	 * @DRM_COLOROP_CTM_3X3:
> > +	 *
> > +	 * enum string "3x3 Matrix"
> > +	 *
> > +	 * A 3x3 matrix. Its values are specified via the
> > +	 * &drm_color_ctm struct provided via the DATA property.
> > +	 *
> > +	 * The DATA blob is a float[9]:
> > +	 * out   matrix          in
> > +	 * | R |   | 0  1  2 |   | R |
> > +	 * | G | = | 3  4  5 | x | G |
> > +	 * | B |   | 6  7  8 |   | B |
> > +	 */
> > +	DRM_COLOROP_CTM_3X3,
> >  };
> >  
> >  /**
> > 
> 
> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> 
> FWIW, the statement "The DATA blob is a float[9]" is incorrect, but
> the
> same wording exists already with the DRM_COLOROP_CTM_3X4. The data
> type
> is not a float, nor is it a float reinterpreted as __u64 (they are
> not
> even the same size). Documentation for the structs explains the
> correct
> type, which is a fixed-point number.
> 
> The struct types document also the layout, so there is no need to
> repeat the layout here. It may be worth mentioning that the blob must
> contain exactly one instance of the struct.

Makes sense, thanks! I'll fix that in v2.

-- 
Thanks,

Nícolas

[PATCH 10/11] drm/mediatek: ovl: Enable support for R2R Color Space Conversion

[Nícolas F. R. A. Prado]

The OVL hardware allows applying a 3x3 matrix transformation for each
layer through the 'RGB to RGB Color Space Conversion' (R2R CSC) setting.
Implement support for it and expose it as a colorop through the DRM
plane color pipeline uAPI.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 55 ++++++++++++++++++++++++++++++++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index a70092c792a9..c8a2b1b13035 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -4,6 +4,7 @@
  */
 
 #include <drm/drm_blend.h>
+#include <drm/drm_color_mgmt.h>
 #include <drm/drm_colorop.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_framebuffer.h>
@@ -52,6 +53,7 @@
 #define OVL_CON_CLRFMT_10_BIT				(1)
 #define DISP_REG_OVL_WCG_CFG1			0x2d8
 #define IGAMMA_EN(layer)				BIT(0 + 4 * (layer))
+#define CSC_EN(layer)					BIT(1 + 4 * (layer))
 #define GAMMA_EN(layer)					BIT(2 + 4 * (layer))
 #define DISP_REG_OVL_WCG_CFG2			0x2dc
 #define IGAMMA_MASK(layer)				GENMASK((layer) * 4 + 1, (layer) * 4)
@@ -62,6 +64,7 @@
 #define GAMMA_BT709					1
 #define GAMMA_BT2020					2
 #define GAMMA_HLG					3
+#define DISP_REG_OVL_R2R_PARA(layer)		(0x500 + (layer) * 0x40)
 #define DISP_REG_OVL_ADDR_MT8173		0x0f40
 #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n))
 #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n) + 0x04)
@@ -579,11 +582,44 @@ static void mtk_ovl_apply_igamma(struct mtk_disp_ovl *ovl, unsigned int idx,
 			   IGAMMA_EN(idx));
 }
 
+static void mtk_ovl_write_r2r_para(struct mtk_disp_ovl *ovl, unsigned int idx,
+				   struct drm_color_ctm *ctm,
+				   struct cmdq_pkt *cmdq_pkt)
+{
+	unsigned int i;
+	u64 val;
+
+	for (i = 0; i < ARRAY_SIZE(ctm->matrix); i++) {
+		val = drm_color_ctm_s31_32_to_qm_n(ctm->matrix[i], 5, 18);
+		mtk_ddp_write(cmdq_pkt, val, &ovl->cmdq_reg, ovl->regs,
+			      DISP_REG_OVL_R2R_PARA(idx) + i * 4);
+	}
+}
+
+static void mtk_ovl_apply_r2r_csc(struct mtk_disp_ovl *ovl, unsigned int idx,
+				  struct drm_colorop *colorop,
+				  struct cmdq_pkt *cmdq_pkt)
+{
+	struct drm_color_ctm *ctm;
+
+	if (colorop->state->data && colorop->state->data->data) {
+		ctm = (struct drm_color_ctm *)colorop->state->data->data;
+		mtk_ovl_write_r2r_para(ovl, idx, ctm, cmdq_pkt);
+	}
+
+	mtk_ddp_write_mask(cmdq_pkt, colorop->state->bypass ? 0 : CSC_EN(idx),
+			   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG1,
+			   CSC_EN(idx));
+}
+
 static void mtk_ovl_apply_colorop(struct mtk_disp_ovl *ovl, unsigned int idx,
 				  struct drm_colorop *colorop,
 				  struct cmdq_pkt *cmdq_pkt)
 {
 	switch (colorop->type) {
+	case DRM_COLOROP_CTM_3X3:
+		mtk_ovl_apply_r2r_csc(ovl, idx, colorop, cmdq_pkt);
+		break;
 	case DRM_COLOROP_1D_CURVE:
 		/* gamma is the last colorop in pipeline */
 		if (!colorop->next)
@@ -602,7 +638,7 @@ static void mtk_ovl_disable_colorops(struct mtk_disp_ovl *ovl, unsigned int idx,
 {
 	mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl->regs,
 			   DISP_REG_OVL_WCG_CFG1,
-			   IGAMMA_EN(idx) | GAMMA_EN(idx));
+			   IGAMMA_EN(idx) | CSC_EN(idx) | GAMMA_EN(idx));
 
 	/* igamma curve needs to be set to default when igamma is disabled */
 	mtk_ddp_write_mask(cmdq_pkt, IGAMMA_SCRGB, &ovl->cmdq_reg, ovl->regs,
@@ -771,6 +807,23 @@ mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
 
 	i++;
 
+	/* 2nd op: OVL's R2R Color Space Conversion */
+	ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
+	if (!ops[i]) {
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+
+	ret = drm_plane_colorop_ctm_3x3_init(dev, ops[i], plane,
+					     &mtk_ovl_colorop_funcs,
+					     DRM_COLOROP_FLAG_ALLOW_BYPASS);
+	if (ret)
+		goto err_colorop_init;
+
+	drm_colorop_set_next_property(ops[i - 1], ops[i]);
+
+	i++;
+
 	/* 3rd op: OVL's Gamma */
 	ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
 	if (!ops[i]) {

-- 
2.51.0

Re: [PATCH 10/11] drm/mediatek: ovl: Enable support for R2R Color Space Conversion

[CK Hu (胡俊光)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> The OVL hardware allows applying a 3x3 matrix transformation for each
> layer through the 'RGB to RGB Color Space Conversion' (R2R CSC) setting.
> Implement support for it and expose it as a colorop through the DRM
> plane color pipeline uAPI.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 55 ++++++++++++++++++++++++++++++++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index a70092c792a9..c8a2b1b13035 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -4,6 +4,7 @@
>   */
> 
>  #include <drm/drm_blend.h>
> +#include <drm/drm_color_mgmt.h>
>  #include <drm/drm_colorop.h>
>  #include <drm/drm_fourcc.h>
>  #include <drm/drm_framebuffer.h>
> @@ -52,6 +53,7 @@
>  #define OVL_CON_CLRFMT_10_BIT                          (1)
>  #define DISP_REG_OVL_WCG_CFG1                  0x2d8
>  #define IGAMMA_EN(layer)                               BIT(0 + 4 * (layer))
> +#define CSC_EN(layer)                                  BIT(1 + 4 * (layer))
>  #define GAMMA_EN(layer)                                        BIT(2 + 4 * (layer))
>  #define DISP_REG_OVL_WCG_CFG2                  0x2dc
>  #define IGAMMA_MASK(layer)                             GENMASK((layer) * 4 + 1, (layer) * 4)
> @@ -62,6 +64,7 @@
>  #define GAMMA_BT709                                    1
>  #define GAMMA_BT2020                                   2
>  #define GAMMA_HLG                                      3
> +#define DISP_REG_OVL_R2R_PARA(layer)           (0x500 + (layer) * 0x40)
>  #define DISP_REG_OVL_ADDR_MT8173               0x0f40
>  #define DISP_REG_OVL_ADDR(ovl, n)              ((ovl)->data->addr + 0x20 * (n))
>  #define DISP_REG_OVL_HDR_ADDR(ovl, n)          ((ovl)->data->addr + 0x20 * (n) + 0x04)
> @@ -579,11 +582,44 @@ static void mtk_ovl_apply_igamma(struct mtk_disp_ovl *ovl, unsigned int idx,
>                            IGAMMA_EN(idx));
>  }
> 
> +static void mtk_ovl_write_r2r_para(struct mtk_disp_ovl *ovl, unsigned int idx,
> +                                  struct drm_color_ctm *ctm,
> +                                  struct cmdq_pkt *cmdq_pkt)
> +{
> +       unsigned int i;
> +       u64 val;
> +
> +       for (i = 0; i < ARRAY_SIZE(ctm->matrix); i++) {
> +               val = drm_color_ctm_s31_32_to_qm_n(ctm->matrix[i], 5, 18);
> +               mtk_ddp_write(cmdq_pkt, val, &ovl->cmdq_reg, ovl->regs,
> +                             DISP_REG_OVL_R2R_PARA(idx) + i * 4);
> +       }
> +}
> +
> +static void mtk_ovl_apply_r2r_csc(struct mtk_disp_ovl *ovl, unsigned int idx,
> +                                 struct drm_colorop *colorop,
> +                                 struct cmdq_pkt *cmdq_pkt)
> +{
> +       struct drm_color_ctm *ctm;
> +
> +       if (colorop->state->data && colorop->state->data->data) {
> +               ctm = (struct drm_color_ctm *)colorop->state->data->data;
> +               mtk_ovl_write_r2r_para(ovl, idx, ctm, cmdq_pkt);
> +       }
> +

If bypass imply colorop->state->data->data is NULL, nothing need to change.
If bypass does not imply colorop->state->data->data is NULL, I would like to disable CSC first then clear r2r parameter.

Regards,
CK

> +       mtk_ddp_write_mask(cmdq_pkt, colorop->state->bypass ? 0 : CSC_EN(idx),
> +                          &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_WCG_CFG1,
> +                          CSC_EN(idx));
> +}
> +
>  static void mtk_ovl_apply_colorop(struct mtk_disp_ovl *ovl, unsigned int idx,
>                                   struct drm_colorop *colorop,
>                                   struct cmdq_pkt *cmdq_pkt)
>  {
>         switch (colorop->type) {
> +       case DRM_COLOROP_CTM_3X3:
> +               mtk_ovl_apply_r2r_csc(ovl, idx, colorop, cmdq_pkt);
> +               break;
>         case DRM_COLOROP_1D_CURVE:
>                 /* gamma is the last colorop in pipeline */
>                 if (!colorop->next)
> @@ -602,7 +638,7 @@ static void mtk_ovl_disable_colorops(struct mtk_disp_ovl *ovl, unsigned int idx,
>  {
>         mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl->regs,
>                            DISP_REG_OVL_WCG_CFG1,
> -                          IGAMMA_EN(idx) | GAMMA_EN(idx));
> +                          IGAMMA_EN(idx) | CSC_EN(idx) | GAMMA_EN(idx));
> 
>         /* igamma curve needs to be set to default when igamma is disabled */
>         mtk_ddp_write_mask(cmdq_pkt, IGAMMA_SCRGB, &ovl->cmdq_reg, ovl->regs,
> @@ -771,6 +807,23 @@ mtk_ovl_initialize_plane_color_pipeline(struct drm_plane *plane,
> 
>         i++;
> 
> +       /* 2nd op: OVL's R2R Color Space Conversion */
> +       ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
> +       if (!ops[i]) {
> +               ret = -ENOMEM;
> +               goto err_alloc;
> +       }
> +
> +       ret = drm_plane_colorop_ctm_3x3_init(dev, ops[i], plane,
> +                                            &mtk_ovl_colorop_funcs,
> +                                            DRM_COLOROP_FLAG_ALLOW_BYPASS);
> +       if (ret)
> +               goto err_colorop_init;
> +
> +       drm_colorop_set_next_property(ops[i - 1], ops[i]);
> +
> +       i++;
> +
>         /* 3rd op: OVL's Gamma */
>         ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
>         if (!ops[i]) {
> 
> --
> 2.51.0
> 

Re: [PATCH 10/11] drm/mediatek: ovl: Enable support for R2R Color Space Conversion

[Nícolas F. R. A. Prado]

On Tue, 2026-03-03 at 07:16 +0000, CK Hu (胡俊光) wrote:
> On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> > External email : Please do not click links or open attachments
> > until you have verified the sender or the content.
> > 
> > 
> > The OVL hardware allows applying a 3x3 matrix transformation for
> > each
> > layer through the 'RGB to RGB Color Space Conversion' (R2R CSC)
> > setting.
> > Implement support for it and expose it as a colorop through the DRM
> > plane color pipeline uAPI.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 55
> > ++++++++++++++++++++++++++++++++-
> >  1 file changed, 54 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index a70092c792a9..c8a2b1b13035 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -4,6 +4,7 @@
> >   */
> > 
> >  #include <drm/drm_blend.h>
> > +#include <drm/drm_color_mgmt.h>
> >  #include <drm/drm_colorop.h>
> >  #include <drm/drm_fourcc.h>
> >  #include <drm/drm_framebuffer.h>
> > @@ -52,6 +53,7 @@
> >  #define OVL_CON_CLRFMT_10_BIT                          (1)
> >  #define DISP_REG_OVL_WCG_CFG1                  0x2d8
> >  #define IGAMMA_EN(layer)                               BIT(0 + 4 *
> > (layer))
> > +#define CSC_EN(layer)                                  BIT(1 + 4 *
> > (layer))
> >  #define GAMMA_EN(layer)                                       
> > BIT(2 + 4 * (layer))
> >  #define DISP_REG_OVL_WCG_CFG2                  0x2dc
> >  #define IGAMMA_MASK(layer)                            
> > GENMASK((layer) * 4 + 1, (layer) * 4)
> > @@ -62,6 +64,7 @@
> >  #define GAMMA_BT709                                    1
> >  #define GAMMA_BT2020                                   2
> >  #define GAMMA_HLG                                      3
> > +#define DISP_REG_OVL_R2R_PARA(layer)           (0x500 + (layer) *
> > 0x40)
> >  #define DISP_REG_OVL_ADDR_MT8173               0x0f40
> >  #define DISP_REG_OVL_ADDR(ovl, n)              ((ovl)->data->addr
> > + 0x20 * (n))
> >  #define DISP_REG_OVL_HDR_ADDR(ovl, n)          ((ovl)->data->addr
> > + 0x20 * (n) + 0x04)
> > @@ -579,11 +582,44 @@ static void mtk_ovl_apply_igamma(struct
> > mtk_disp_ovl *ovl, unsigned int idx,
> >                            IGAMMA_EN(idx));
> >  }
> > 
> > +static void mtk_ovl_write_r2r_para(struct mtk_disp_ovl *ovl,
> > unsigned int idx,
> > +                                  struct drm_color_ctm *ctm,
> > +                                  struct cmdq_pkt *cmdq_pkt)
> > +{
> > +       unsigned int i;
> > +       u64 val;
> > +
> > +       for (i = 0; i < ARRAY_SIZE(ctm->matrix); i++) {
> > +               val = drm_color_ctm_s31_32_to_qm_n(ctm->matrix[i],
> > 5, 18);
> > +               mtk_ddp_write(cmdq_pkt, val, &ovl->cmdq_reg, ovl-
> > >regs,
> > +                             DISP_REG_OVL_R2R_PARA(idx) + i * 4);
> > +       }
> > +}
> > +
> > +static void mtk_ovl_apply_r2r_csc(struct mtk_disp_ovl *ovl,
> > unsigned int idx,
> > +                                 struct drm_colorop *colorop,
> > +                                 struct cmdq_pkt *cmdq_pkt)
> > +{
> > +       struct drm_color_ctm *ctm;
> > +
> > +       if (colorop->state->data && colorop->state->data->data) {
> > +               ctm = (struct drm_color_ctm *)colorop->state->data-
> > >data;
> > +               mtk_ovl_write_r2r_para(ovl, idx, ctm, cmdq_pkt);
> > +       }
> > +
> 
> If bypass imply colorop->state->data->data is NULL, nothing need to
> change.
> If bypass does not imply colorop->state->data->data is NULL, I would
> like to disable CSC first then clear r2r parameter.

bypass does not imply NULL data. But even when setting the CSC block to
be bypassed, we don't want to clear its parameters, we want to set the
parameters passed by userspace in this atomic commit, if any, and if
not we want to keep the current parameters, in case they have been set
in a previous atomic commit, so that a future commit setting bypass=0
will have the parameters previously set, without having to pass them
again.

Thanks,
Nícolas

[PATCH 11/11] drm/mediatek: Check 3x3 Matrix colorop has DATA set

[Nícolas F. R. A. Prado]

Add an atomic check hook for the CRTC and use it to verify that any 3x3
Matrix colorop, which requires the DATA property to be set, does in fact
have it set.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_crtc.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
index f7db235d986f..1a55d5df6dbe 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -897,6 +897,31 @@ static void mtk_crtc_atomic_flush(struct drm_crtc *crtc,
 	mtk_crtc_update_config(mtk_crtc, !!mtk_crtc->event);
 }
 
+static int mtk_crtc_atomic_check(struct drm_crtc *crtc,
+				 struct drm_atomic_state *state)
+{
+	struct drm_colorop_state *new_colorop_state;
+	struct drm_colorop *colorop;
+	int i;
+
+	for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+		switch (colorop->type) {
+		case DRM_COLOROP_CTM_3X3:
+			if (!new_colorop_state->bypass && !new_colorop_state->data) {
+				drm_dbg_atomic(crtc->dev,
+					       "Missing required DATA property for COLOROP:%d\n",
+					       colorop->base.id);
+				return -EINVAL;
+			}
+			break;
+		default:
+			break;
+		}
+	}
+
+	return 0;
+}
+
 static const struct drm_crtc_funcs mtk_crtc_funcs = {
 	.set_config		= drm_atomic_helper_set_config,
 	.page_flip		= drm_atomic_helper_page_flip,
@@ -914,6 +939,7 @@ static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
 	.mode_valid	= mtk_crtc_mode_valid,
 	.atomic_begin	= mtk_crtc_atomic_begin,
 	.atomic_flush	= mtk_crtc_atomic_flush,
+	.atomic_check	= mtk_crtc_atomic_check,
 	.atomic_enable	= mtk_crtc_atomic_enable,
 	.atomic_disable	= mtk_crtc_atomic_disable,
 };

-- 
2.51.0

Re: [PATCH 11/11] drm/mediatek: Check 3x3 Matrix colorop has DATA set

[CK Hu (胡俊光)]

On Tue, 2025-12-23 at 16:44 -0300, Nícolas F. R. A. Prado wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> Add an atomic check hook for the CRTC and use it to verify that any 3x3
> Matrix colorop, which requires the DATA property to be set, does in fact
> have it set.

Reviewed-by: CK Hu <ck.hu@mediatek.com>

> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_crtc.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
> index f7db235d986f..1a55d5df6dbe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
> @@ -897,6 +897,31 @@ static void mtk_crtc_atomic_flush(struct drm_crtc *crtc,
>         mtk_crtc_update_config(mtk_crtc, !!mtk_crtc->event);
>  }
> 
> +static int mtk_crtc_atomic_check(struct drm_crtc *crtc,
> +                                struct drm_atomic_state *state)
> +{
> +       struct drm_colorop_state *new_colorop_state;
> +       struct drm_colorop *colorop;
> +       int i;
> +
> +       for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
> +               switch (colorop->type) {
> +               case DRM_COLOROP_CTM_3X3:
> +                       if (!new_colorop_state->bypass && !new_colorop_state->data) {
> +                               drm_dbg_atomic(crtc->dev,
> +                                              "Missing required DATA property for COLOROP:%d\n",
> +                                              colorop->base.id);
> +                               return -EINVAL;
> +                       }
> +                       break;
> +               default:
> +                       break;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
>  static const struct drm_crtc_funcs mtk_crtc_funcs = {
>         .set_config             = drm_atomic_helper_set_config,
>         .page_flip              = drm_atomic_helper_page_flip,
> @@ -914,6 +939,7 @@ static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
>         .mode_valid     = mtk_crtc_mode_valid,
>         .atomic_begin   = mtk_crtc_atomic_begin,
>         .atomic_flush   = mtk_crtc_atomic_flush,
> +       .atomic_check   = mtk_crtc_atomic_check,
>         .atomic_enable  = mtk_crtc_atomic_enable,
>         .atomic_disable = mtk_crtc_atomic_disable,
>  };
> 
> --
> 2.51.0
> 

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Shengyu Qu]

[-- Attachment #1.1.1: Type: text/plain, Size: 3714 bytes --]



在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
> This series implements a plane color pipeline for MediaTek platforms,
> specifically for MT8195-compatible SoCs.
> 
> The pipeline is composed of the following blocks:
> 
> Inverse Gamma -> RGB to RGB Color Space Conversion (R2R CSC) -> Gamma
> (1D Curve)       (3x3 Matrix)                                   (1D Curve)
> 
> The curves supported by Inverse Gamma are:
> * scRGB
> * BT.709

scRGB? That means this HW supports float point format surface, are you 
sure this is not standard sRGB?

> The curves supported by Gamma are:
> * scRGB
> * BT.709
> * BT.2020
> * HLG
> 
> Given the lack of support for writeback connectors on the MediaTek KMS
> driver, combined with limited hardware documentation, I haven't been
> able to verify the correctness of each curve, only that they were
> visually sane (gamma curves made the image on the display brighter,
> while inverse gamma made it darker).

Hmmm I don't think this is acceptable. sRGB/scRGB has two transfer 
functions mentioned in original specification[1]. To keep color 
accuracy, we need someone from mediatek confirm whether this is 
piece-wise or pure power 2.2 transfer function, this is already done in 
original amdgpu color pipeline series, sRGB means piece-wise while also 
dedicated power 2.2 function exists.

Also +cc Xaver for a review as userspace compositor developer.

[1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30

> This series depends on "drm: Color pipeline teardown and follow-up
> fixes/improvements" [1].
> 
> This series was tested on the MT8195-Tomato Chromebook.
> 
> Regarding the support of color operations in OVL for different SoCs:
> * it's not supported by MT8183, and presumably also not by older
>    generations
> * On MT8192 it's supported by ovl0 and ovl_2l0, but not ovl_2l2 (despite
>    the same compatible as ovl_2l0).
> 
> For this series I'm only enabling it on MT8195 since that's the one
> where I can readily test.
> 
> [1] https://lore.kernel.org/all/20251219065614.190834-1-chaitanya.kumar.borah@intel.com/#t
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
> Nícolas F. R. A. Prado (11):
>        drm/mediatek: Introduce DDP plane_colorops_init() hook
>        drm/mediatek: Initialize colorops when creating plane
>        drm/mediatek: ovl: Add supports_plane_colorops flag
>        drm/mediatek: ovl: Enable per-plane color operations on MT8195
>        drm/mediatek: ovl: Implement support for Inverse Gamma
>        drm/mediatek: Add plane_colorops_init() DDP hook for OVL
>        drm/colorop: Introduce HLG EOTF
>        drm/mediatek: ovl: Implement support for Gamma
>        drm/colorop: Introduce 3x3 Matrix
>        drm/mediatek: ovl: Enable support for R2R Color Space Conversion
>        drm/mediatek: Check 3x3 Matrix colorop has DATA set
> 
>   drivers/gpu/drm/drm_atomic.c            |   1 +
>   drivers/gpu/drm/drm_atomic_uapi.c       |   3 +
>   drivers/gpu/drm/drm_colorop.c           |  22 +++
>   drivers/gpu/drm/mediatek/mtk_crtc.c     |  36 +++-
>   drivers/gpu/drm/mediatek/mtk_ddp_comp.c |   1 +
>   drivers/gpu/drm/mediatek/mtk_ddp_comp.h |   2 +
>   drivers/gpu/drm/mediatek/mtk_disp_drv.h |   1 +
>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 287 ++++++++++++++++++++++++++++++++
>   include/drm/drm_colorop.h               |  13 ++
>   include/uapi/drm/drm_mode.h             |  16 ++
>   10 files changed, 381 insertions(+), 1 deletion(-)
> ---
> base-commit: 1783cdadb70e74a30dfee250f8c2dc13b4e61128
> change-id: 20251219-mtk-ovl-pre-blend-colorops-95b7b2883d95
> 
> Best regards,


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Shengyu Qu]

[-- Attachment #1.1.1: Type: text/plain, Size: 4292 bytes --]



在 2025/12/30 02:53, Shengyu Qu 写道:
> 
> 
> 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
>> This series implements a plane color pipeline for MediaTek platforms,
>> specifically for MT8195-compatible SoCs.
>>
>> The pipeline is composed of the following blocks:
>>
>> Inverse Gamma -> RGB to RGB Color Space Conversion (R2R CSC) -> Gamma
>> (1D Curve)       (3x3 Matrix)                                   (1D 
>> Curve)
>>
>> The curves supported by Inverse Gamma are:
>> * scRGB
>> * BT.709
> 
> scRGB? That means this HW supports float point format surface, are you 
> sure this is not standard sRGB?

Sorry, I mistook between Microsoft's modified float scRGB implementation 
between standard scRGB spec. But that's still weird to support such 
format in hardware, as this means frame buffer is 16bit uint per color.

> 
>> The curves supported by Gamma are:
>> * scRGB
>> * BT.709
>> * BT.2020
>> * HLG
>>
>> Given the lack of support for writeback connectors on the MediaTek KMS
>> driver, combined with limited hardware documentation, I haven't been
>> able to verify the correctness of each curve, only that they were
>> visually sane (gamma curves made the image on the display brighter,
>> while inverse gamma made it darker).
> 
> Hmmm I don't think this is acceptable. sRGB/scRGB has two transfer 
> functions mentioned in original specification[1]. To keep color 
> accuracy, we need someone from mediatek confirm whether this is piece- 
> wise or pure power 2.2 transfer function, this is already done in 
> original amdgpu color pipeline series, sRGB means piece-wise while also 
> dedicated power 2.2 function exists.
> 
> Also +cc Xaver for a review as userspace compositor developer.
> 
> [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30
> 
>> This series depends on "drm: Color pipeline teardown and follow-up
>> fixes/improvements" [1].
>>
>> This series was tested on the MT8195-Tomato Chromebook.
>>
>> Regarding the support of color operations in OVL for different SoCs:
>> * it's not supported by MT8183, and presumably also not by older
>>    generations
>> * On MT8192 it's supported by ovl0 and ovl_2l0, but not ovl_2l2 (despite
>>    the same compatible as ovl_2l0).
>>
>> For this series I'm only enabling it on MT8195 since that's the one
>> where I can readily test.
>>
>> [1] https://lore.kernel.org/all/20251219065614.190834-1- 
>> chaitanya.kumar.borah@intel.com/#t
>>
>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
>> ---
>> Nícolas F. R. A. Prado (11):
>>        drm/mediatek: Introduce DDP plane_colorops_init() hook
>>        drm/mediatek: Initialize colorops when creating plane
>>        drm/mediatek: ovl: Add supports_plane_colorops flag
>>        drm/mediatek: ovl: Enable per-plane color operations on MT8195
>>        drm/mediatek: ovl: Implement support for Inverse Gamma
>>        drm/mediatek: Add plane_colorops_init() DDP hook for OVL
>>        drm/colorop: Introduce HLG EOTF
>>        drm/mediatek: ovl: Implement support for Gamma
>>        drm/colorop: Introduce 3x3 Matrix
>>        drm/mediatek: ovl: Enable support for R2R Color Space Conversion
>>        drm/mediatek: Check 3x3 Matrix colorop has DATA set
>>
>>   drivers/gpu/drm/drm_atomic.c            |   1 +
>>   drivers/gpu/drm/drm_atomic_uapi.c       |   3 +
>>   drivers/gpu/drm/drm_colorop.c           |  22 +++
>>   drivers/gpu/drm/mediatek/mtk_crtc.c     |  36 +++-
>>   drivers/gpu/drm/mediatek/mtk_ddp_comp.c |   1 +
>>   drivers/gpu/drm/mediatek/mtk_ddp_comp.h |   2 +
>>   drivers/gpu/drm/mediatek/mtk_disp_drv.h |   1 +
>>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 287 ++++++++++++++++++++++ 
>> ++++++++++
>>   include/drm/drm_colorop.h               |  13 ++
>>   include/uapi/drm/drm_mode.h             |  16 ++
>>   10 files changed, 381 insertions(+), 1 deletion(-)
>> ---
>> base-commit: 1783cdadb70e74a30dfee250f8c2dc13b4e61128
>> change-id: 20251219-mtk-ovl-pre-blend-colorops-95b7b2883d95
>>
>> Best regards,
> 


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Harry Wentland]

On 2026-01-01 07:37, Shengyu Qu wrote:
> 
> 
> 在 2025/12/30 02:53, Shengyu Qu 写道:
>>
>>
>> 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
>>> This series implements a plane color pipeline for MediaTek platforms,
>>> specifically for MT8195-compatible SoCs.
>>>
>>> The pipeline is composed of the following blocks:
>>>
>>> Inverse Gamma -> RGB to RGB Color Space Conversion (R2R CSC) -> Gamma
>>> (1D Curve)       (3x3 Matrix)                                   (1D Curve)
>>>
>>> The curves supported by Inverse Gamma are:
>>> * scRGB
>>> * BT.709
>>
>> scRGB? That means this HW supports float point format surface, are you sure this is not standard sRGB?
> 
> Sorry, I mistook between Microsoft's modified float scRGB implementation between standard scRGB spec. But that's still weird to support such format in hardware, as this means frame buffer is 16bit uint per color.
> 
>>
>>> The curves supported by Gamma are:
>>> * scRGB
>>> * BT.709
>>> * BT.2020
>>> * HLG
>>>
>>> Given the lack of support for writeback connectors on the MediaTek KMS
>>> driver, combined with limited hardware documentation, I haven't been
>>> able to verify the correctness of each curve, only that they were
>>> visually sane (gamma curves made the image on the display brighter,
>>> while inverse gamma made it darker).
>>
>> Hmmm I don't think this is acceptable. sRGB/scRGB has two transfer functions mentioned in original specification[1]. To keep color accuracy, we need someone from mediatek confirm whether this is piece- wise or pure power 2.2 transfer function, this is already done in original amdgpu color pipeline series, sRGB means piece-wise while also dedicated power 2.2 function exists.

Not sure what you mean with this not being acceptable. This is about enabling HW support for this functionality. Not every HW has writeback for testing. At some point you'll have to trust the driver devs if you're going to use functionality of the driver. We're not always going to get everything perfect, but if that's really such a worry you can always use shaders to do precisely what you want.

Harry

>>
>> Also +cc Xaver for a review as userspace compositor developer.
>>
>> [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30
>>
>>> This series depends on "drm: Color pipeline teardown and follow-up
>>> fixes/improvements" [1].
>>>
>>> This series was tested on the MT8195-Tomato Chromebook.
>>>
>>> Regarding the support of color operations in OVL for different SoCs:
>>> * it's not supported by MT8183, and presumably also not by older
>>>    generations
>>> * On MT8192 it's supported by ovl0 and ovl_2l0, but not ovl_2l2 (despite
>>>    the same compatible as ovl_2l0).
>>>
>>> For this series I'm only enabling it on MT8195 since that's the one
>>> where I can readily test.
>>>
>>> [1] https://lore.kernel.org/all/20251219065614.190834-1- chaitanya.kumar.borah@intel.com/#t
>>>
>>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
>>> ---
>>> Nícolas F. R. A. Prado (11):
>>>        drm/mediatek: Introduce DDP plane_colorops_init() hook
>>>        drm/mediatek: Initialize colorops when creating plane
>>>        drm/mediatek: ovl: Add supports_plane_colorops flag
>>>        drm/mediatek: ovl: Enable per-plane color operations on MT8195
>>>        drm/mediatek: ovl: Implement support for Inverse Gamma
>>>        drm/mediatek: Add plane_colorops_init() DDP hook for OVL
>>>        drm/colorop: Introduce HLG EOTF
>>>        drm/mediatek: ovl: Implement support for Gamma
>>>        drm/colorop: Introduce 3x3 Matrix
>>>        drm/mediatek: ovl: Enable support for R2R Color Space Conversion
>>>        drm/mediatek: Check 3x3 Matrix colorop has DATA set
>>>
>>>   drivers/gpu/drm/drm_atomic.c            |   1 +
>>>   drivers/gpu/drm/drm_atomic_uapi.c       |   3 +
>>>   drivers/gpu/drm/drm_colorop.c           |  22 +++
>>>   drivers/gpu/drm/mediatek/mtk_crtc.c     |  36 +++-
>>>   drivers/gpu/drm/mediatek/mtk_ddp_comp.c |   1 +
>>>   drivers/gpu/drm/mediatek/mtk_ddp_comp.h |   2 +
>>>   drivers/gpu/drm/mediatek/mtk_disp_drv.h |   1 +
>>>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 287 ++++++++++++++++++++++ ++++++++++
>>>   include/drm/drm_colorop.h               |  13 ++
>>>   include/uapi/drm/drm_mode.h             |  16 ++
>>>   10 files changed, 381 insertions(+), 1 deletion(-)
>>> ---
>>> base-commit: 1783cdadb70e74a30dfee250f8c2dc13b4e61128
>>> change-id: 20251219-mtk-ovl-pre-blend-colorops-95b7b2883d95
>>>
>>> Best regards,
>>
> 

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Fri, 2 Jan 2026 13:40:21 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2026-01-01 07:37, Shengyu Qu wrote:
> > 
> > 
> > 在 2025/12/30 02:53, Shengyu Qu 写道:  
> >>
> >>
> >> 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:  

> >>> Given the lack of support for writeback connectors on the
> >>> MediaTek KMS driver, combined with limited hardware
> >>> documentation, I haven't been able to verify the correctness of
> >>> each curve, only that they were visually sane (gamma curves made
> >>> the image on the display brighter, while inverse gamma made it
> >>> darker).  
> >>
> >> Hmmm I don't think this is acceptable. sRGB/scRGB has two transfer
> >> functions mentioned in original specification[1]. To keep color
> >> accuracy, we need someone from mediatek confirm whether this is
> >> piece- wise or pure power 2.2 transfer function, this is already
> >> done in original amdgpu color pipeline series, sRGB means
> >> piece-wise while also dedicated power 2.2 function exists.  
> 
> Not sure what you mean with this not being acceptable. This is about
> enabling HW support for this functionality. Not every HW has
> writeback for testing. At some point you'll have to trust the driver
> devs if you're going to use functionality of the driver. We're not
> always going to get everything perfect, but if that's really such a
> worry you can always use shaders to do precisely what you want.
> 

Hi Harry,

yes, but I understood that in this case, the hardware documentation
available is so vague that it's impossible to say what it will actually
do. There are no formulas given or referenced in the documentation, are
there, Nícolas?

The "HLG EOTF" is probably a good example of that, referring to the
reply I just sent on the patch adding "HLG" as a curve.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Nícolas F. R. A. Prado]

On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:
> On Fri, 2 Jan 2026 13:40:21 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
> > On 2026-01-01 07:37, Shengyu Qu wrote:
> > > 
> > > 
> > > 在 2025/12/30 02:53, Shengyu Qu 写道:  
> > > > 
> > > > 
> > > > 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:  
> 
> > > > > Given the lack of support for writeback connectors on the
> > > > > MediaTek KMS driver, combined with limited hardware
> > > > > documentation, I haven't been able to verify the correctness
> > > > > of
> > > > > each curve, only that they were visually sane (gamma curves
> > > > > made
> > > > > the image on the display brighter, while inverse gamma made
> > > > > it
> > > > > darker).  
> > > > 
> > > > Hmmm I don't think this is acceptable. sRGB/scRGB has two
> > > > transfer
> > > > functions mentioned in original specification[1]. To keep color
> > > > accuracy, we need someone from mediatek confirm whether this is
> > > > piece- wise or pure power 2.2 transfer function, this is
> > > > already
> > > > done in original amdgpu color pipeline series, sRGB means
> > > > piece-wise while also dedicated power 2.2 function exists.  
> > 
> > Not sure what you mean with this not being acceptable. This is
> > about
> > enabling HW support for this functionality. Not every HW has
> > writeback for testing. At some point you'll have to trust the
> > driver
> > devs if you're going to use functionality of the driver. We're not
> > always going to get everything perfect, but if that's really such a
> > worry you can always use shaders to do precisely what you want.
> > 
> 
> Hi Harry,
> 
> yes, but I understood that in this case, the hardware documentation
> available is so vague that it's impossible to say what it will
> actually
> do. There are no formulas given or referenced in the documentation,
> are
> there, Nícolas?

No formulas at all, the only documentation I had available for the
curves was the register definition, which simply lists the possible
values: SCRGB, BT709, BT2020, HLG.

-- 
Thanks,

Nícolas

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[CK Hu (胡俊光)]

On Fri, 2026-02-06 at 08:28 -0500, Nícolas F. R. A. Prado wrote:
> On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:
> > On Fri, 2 Jan 2026 13:40:21 -0500
> > Harry Wentland <harry.wentland@amd.com> wrote:
> > 
> > > On 2026-01-01 07:37, Shengyu Qu wrote:
> > > > 
> > > > 
> > > > 在 2025/12/30 02:53, Shengyu Qu 写道:  
> > > > > 
> > > > > 
> > > > > 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:  
> > 
> > > > > > Given the lack of support for writeback connectors on the
> > > > > > MediaTek KMS driver, combined with limited hardware
> > > > > > documentation, I haven't been able to verify the correctness
> > > > > > of
> > > > > > each curve, only that they were visually sane (gamma curves
> > > > > > made
> > > > > > the image on the display brighter, while inverse gamma made
> > > > > > it
> > > > > > darker).  
> > > > > 
> > > > > Hmmm I don't think this is acceptable. sRGB/scRGB has two
> > > > > transfer
> > > > > functions mentioned in original specification[1]. To keep color
> > > > > accuracy, we need someone from mediatek confirm whether this is
> > > > > piece- wise or pure power 2.2 transfer function, this is
> > > > > already
> > > > > done in original amdgpu color pipeline series, sRGB means
> > > > > piece-wise while also dedicated power 2.2 function exists.  
> > > 
> > > Not sure what you mean with this not being acceptable. This is
> > > about
> > > enabling HW support for this functionality. Not every HW has
> > > writeback for testing. At some point you'll have to trust the
> > > driver
> > > devs if you're going to use functionality of the driver. We're not
> > > always going to get everything perfect, but if that's really such a
> > > worry you can always use shaders to do precisely what you want.
> > > 
> > 
> > Hi Harry,
> > 
> > yes, but I understood that in this case, the hardware documentation
> > available is so vague that it's impossible to say what it will
> > actually
> > do. There are no formulas given or referenced in the documentation,
> > are
> > there, Nícolas?
> 
> No formulas at all, the only documentation I had available for the
> curves was the register definition, which simply lists the possible
> values: SCRGB, BT709, BT2020, HLG.

Hi, Nicolas:

In [1], it shows OVL could output data to WDMA which could write data into DRAM.
Its control is similar to RDMA. RDMA read data from DRAM and WDMA write data into DRAM.
Do you have interest to implement WDMA?
This is just a suggestion.
I could accept we believe what document say first and wait for someone to verify it.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/mediatek/mt8195-mmsys.h?h=v7.0-rc1#n8

Regards,
CK

> 

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[AngeloGioacchino Del Regno]

Il 26/02/26 07:24, CK Hu (胡俊光) ha scritto:
> On Fri, 2026-02-06 at 08:28 -0500, Nícolas F. R. A. Prado wrote:
>> On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:
>>> On Fri, 2 Jan 2026 13:40:21 -0500
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>
>>>> On 2026-01-01 07:37, Shengyu Qu wrote:
>>>>>
>>>>>
>>>>> 在 2025/12/30 02:53, Shengyu Qu 写道:
>>>>>>
>>>>>>
>>>>>> 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
>>>
>>>>>>> Given the lack of support for writeback connectors on the
>>>>>>> MediaTek KMS driver, combined with limited hardware
>>>>>>> documentation, I haven't been able to verify the correctness
>>>>>>> of
>>>>>>> each curve, only that they were visually sane (gamma curves
>>>>>>> made
>>>>>>> the image on the display brighter, while inverse gamma made
>>>>>>> it
>>>>>>> darker).
>>>>>>
>>>>>> Hmmm I don't think this is acceptable. sRGB/scRGB has two
>>>>>> transfer
>>>>>> functions mentioned in original specification[1]. To keep color
>>>>>> accuracy, we need someone from mediatek confirm whether this is
>>>>>> piece- wise or pure power 2.2 transfer function, this is
>>>>>> already
>>>>>> done in original amdgpu color pipeline series, sRGB means
>>>>>> piece-wise while also dedicated power 2.2 function exists.
>>>>
>>>> Not sure what you mean with this not being acceptable. This is
>>>> about
>>>> enabling HW support for this functionality. Not every HW has
>>>> writeback for testing. At some point you'll have to trust the
>>>> driver
>>>> devs if you're going to use functionality of the driver. We're not
>>>> always going to get everything perfect, but if that's really such a
>>>> worry you can always use shaders to do precisely what you want.
>>>>
>>>
>>> Hi Harry,
>>>
>>> yes, but I understood that in this case, the hardware documentation
>>> available is so vague that it's impossible to say what it will
>>> actually
>>> do. There are no formulas given or referenced in the documentation,
>>> are
>>> there, Nícolas?
>>
>> No formulas at all, the only documentation I had available for the
>> curves was the register definition, which simply lists the possible
>> values: SCRGB, BT709, BT2020, HLG.
> 
> Hi, Nicolas:
> 
> In [1], it shows OVL could output data to WDMA which could write data into DRAM.
> Its control is similar to RDMA. RDMA read data from DRAM and WDMA write data into DRAM.
> Do you have interest to implement WDMA?

I wrote a WDMA driver a long ago, but I couldn't get it to work (though, I admit I
didn't try hard to actually get it working).... if you want to take a look to check
if anything obvious is missing, the driver is here:

https://gitlab.collabora.com/mediatek/aiot/linux/-/blob/mediatek-dev/drivers/gpu/drm/mediatek/mtk_disp_wdma.c?ref_type=heads

The driver I wrote was supposed to work on MT8781 Helio G99 (for a personal project
as in upstreaming of the Xiaomi Poco M5 smartphone) and on MT8195 as a PoC.
I did test both platforms and this driver didn't work on both... not sure if that
was because I misconfigured the MMSYS routing (on both) or if there's any actual
issue with the driver I wrote.

Again, didn't invest much time on this, anyway, so some obvious issue might be
present.

Cheers,
Angelo

> This is just a suggestion.
> I could accept we believe what document say first and wait for someone to verify it.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/mediatek/mt8195-mmsys.h?h=v7.0-rc1#n8
> 
> Regards,
> CK
> 
>>
> 

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[AngeloGioacchino Del Regno]

Il 26/02/26 11:26, AngeloGioacchino Del Regno ha scritto:
> Il 26/02/26 07:24, CK Hu (胡俊光) ha scritto:
>> On Fri, 2026-02-06 at 08:28 -0500, Nícolas F. R. A. Prado wrote:
>>> On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:
>>>> On Fri, 2 Jan 2026 13:40:21 -0500
>>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>>
>>>>> On 2026-01-01 07:37, Shengyu Qu wrote:
>>>>>>
>>>>>>
>>>>>> 在 2025/12/30 02:53, Shengyu Qu 写道:
>>>>>>>
>>>>>>>
>>>>>>> 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
>>>>
>>>>>>>> Given the lack of support for writeback connectors on the
>>>>>>>> MediaTek KMS driver, combined with limited hardware
>>>>>>>> documentation, I haven't been able to verify the correctness
>>>>>>>> of
>>>>>>>> each curve, only that they were visually sane (gamma curves
>>>>>>>> made
>>>>>>>> the image on the display brighter, while inverse gamma made
>>>>>>>> it
>>>>>>>> darker).
>>>>>>>
>>>>>>> Hmmm I don't think this is acceptable. sRGB/scRGB has two
>>>>>>> transfer
>>>>>>> functions mentioned in original specification[1]. To keep color
>>>>>>> accuracy, we need someone from mediatek confirm whether this is
>>>>>>> piece- wise or pure power 2.2 transfer function, this is
>>>>>>> already
>>>>>>> done in original amdgpu color pipeline series, sRGB means
>>>>>>> piece-wise while also dedicated power 2.2 function exists.
>>>>>
>>>>> Not sure what you mean with this not being acceptable. This is
>>>>> about
>>>>> enabling HW support for this functionality. Not every HW has
>>>>> writeback for testing. At some point you'll have to trust the
>>>>> driver
>>>>> devs if you're going to use functionality of the driver. We're not
>>>>> always going to get everything perfect, but if that's really such a
>>>>> worry you can always use shaders to do precisely what you want.
>>>>>
>>>>
>>>> Hi Harry,
>>>>
>>>> yes, but I understood that in this case, the hardware documentation
>>>> available is so vague that it's impossible to say what it will
>>>> actually
>>>> do. There are no formulas given or referenced in the documentation,
>>>> are
>>>> there, Nícolas?
>>>
>>> No formulas at all, the only documentation I had available for the
>>> curves was the register definition, which simply lists the possible
>>> values: SCRGB, BT709, BT2020, HLG.
>>
>> Hi, Nicolas:
>>
>> In [1], it shows OVL could output data to WDMA which could write data into DRAM.
>> Its control is similar to RDMA. RDMA read data from DRAM and WDMA write data into 
>> DRAM.
>> Do you have interest to implement WDMA?
> 
> I wrote a WDMA driver a long ago, but I couldn't get it to work (though, I admit I
> didn't try hard to actually get it working).... if you want to take a look to check
> if anything obvious is missing, the driver is here:
> 
> https://gitlab.collabora.com/mediatek/aiot/linux/-/blob/mediatek-dev/drivers/gpu/ 
> drm/mediatek/mtk_disp_wdma.c?ref_type=heads
> 
> The driver I wrote was supposed to work on MT8781 Helio G99 (for a personal project

Eh, sorry for the double email, I was meaning MT6789 Helio G99 - just to be
extremely clear, though that wasn't much important (given that the WDMA IP is
anyway practically the same between the two..).

> as in upstreaming of the Xiaomi Poco M5 smartphone) and on MT8195 as a PoC.
> I did test both platforms and this driver didn't work on both... not sure if that
> was because I misconfigured the MMSYS routing (on both) or if there's any actual
> issue with the driver I wrote.
> 
> Again, didn't invest much time on this, anyway, so some obvious issue might be
> present.
> 
> Cheers,
> Angelo
> 
>> This is just a suggestion.
>> I could accept we believe what document say first and wait for someone to verify it.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ 
>> drivers/soc/mediatek/mt8195-mmsys.h?h=v7.0-rc1#n8
>>
>> Regards,
>> CK
>>
>>>
>>
> 
> 

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Nícolas F. R. A. Prado]

On Thu, 2026-02-26 at 11:51 +0100, AngeloGioacchino Del Regno wrote:
> Il 26/02/26 11:26, AngeloGioacchino Del Regno ha scritto:
> > Il 26/02/26 07:24, CK Hu (胡俊光) ha scritto:
> > > On Fri, 2026-02-06 at 08:28 -0500, Nícolas F. R. A. Prado wrote:
> > > > On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:
> > > > > On Fri, 2 Jan 2026 13:40:21 -0500
> > > > > Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > 
> > > > > > On 2026-01-01 07:37, Shengyu Qu wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 在 2025/12/30 02:53, Shengyu Qu 写道:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
> > > > > 
> > > > > > > > > Given the lack of support for writeback connectors on
> > > > > > > > > the
> > > > > > > > > MediaTek KMS driver, combined with limited hardware
> > > > > > > > > documentation, I haven't been able to verify the
> > > > > > > > > correctness
> > > > > > > > > of
> > > > > > > > > each curve, only that they were visually sane (gamma
> > > > > > > > > curves
> > > > > > > > > made
> > > > > > > > > the image on the display brighter, while inverse
> > > > > > > > > gamma made
> > > > > > > > > it
> > > > > > > > > darker).
> > > > > > > > 
> > > > > > > > Hmmm I don't think this is acceptable. sRGB/scRGB has
> > > > > > > > two
> > > > > > > > transfer
> > > > > > > > functions mentioned in original specification[1]. To
> > > > > > > > keep color
> > > > > > > > accuracy, we need someone from mediatek confirm whether
> > > > > > > > this is
> > > > > > > > piece- wise or pure power 2.2 transfer function, this
> > > > > > > > is
> > > > > > > > already
> > > > > > > > done in original amdgpu color pipeline series, sRGB
> > > > > > > > means
> > > > > > > > piece-wise while also dedicated power 2.2 function
> > > > > > > > exists.
> > > > > > 
> > > > > > Not sure what you mean with this not being acceptable. This
> > > > > > is
> > > > > > about
> > > > > > enabling HW support for this functionality. Not every HW
> > > > > > has
> > > > > > writeback for testing. At some point you'll have to trust
> > > > > > the
> > > > > > driver
> > > > > > devs if you're going to use functionality of the driver.
> > > > > > We're not
> > > > > > always going to get everything perfect, but if that's
> > > > > > really such a
> > > > > > worry you can always use shaders to do precisely what you
> > > > > > want.
> > > > > > 
> > > > > 
> > > > > Hi Harry,
> > > > > 
> > > > > yes, but I understood that in this case, the hardware
> > > > > documentation
> > > > > available is so vague that it's impossible to say what it
> > > > > will
> > > > > actually
> > > > > do. There are no formulas given or referenced in the
> > > > > documentation,
> > > > > are
> > > > > there, Nícolas?
> > > > 
> > > > No formulas at all, the only documentation I had available for
> > > > the
> > > > curves was the register definition, which simply lists the
> > > > possible
> > > > values: SCRGB, BT709, BT2020, HLG.
> > > 
> > > Hi, Nicolas:
> > > 
> > > In [1], it shows OVL could output data to WDMA which could write
> > > data into DRAM.
> > > Its control is similar to RDMA. RDMA read data from DRAM and WDMA
> > > write data into 
> > > DRAM.
> > > Do you have interest to implement WDMA?
> > 
> > I wrote a WDMA driver a long ago, but I couldn't get it to work
> > (though, I admit I
> > didn't try hard to actually get it working).... if you want to take
> > a look to check
> > if anything obvious is missing, the driver is here:
> > 
> > https://gitlab.collabora.com/mediatek/aiot/linux/-/blob/mediatek-dev/drivers/gpu/
> >  
> > drm/mediatek/mtk_disp_wdma.c?ref_type=heads
> > 
> > The driver I wrote was supposed to work on MT8781 Helio G99 (for a
> > personal project
> 
> Eh, sorry for the double email, I was meaning MT6789 Helio G99 - just
> to be
> extremely clear, though that wasn't much important (given that the
> WDMA IP is
> anyway practically the same between the two..).
> 
> > as in upstreaming of the Xiaomi Poco M5 smartphone) and on MT8195
> > as a PoC.
> > I did test both platforms and this driver didn't work on both...
> > not sure if that
> > was because I misconfigured the MMSYS routing (on both) or if
> > there's any actual
> > issue with the driver I wrote.
> > 
> > Again, didn't invest much time on this, anyway, so some obvious
> > issue might be
> > present.

Hi,

Sorry for the delay.

Yes, I'm aware that the hardware supports writeback through the WDMA
component, but as Angelo's implementation still seems to need some work
(I quickly gave it a try but couldn't get it working), and I have very
limited time to work on this, I'm first trying to reach out to MediaTek
to see if more information can be obtained on this.

(We also considered other options like routing the output of OVL to
HDMI and capturing it from there, but again my time is the biggest
limiter right now)
> 

-- 
Thanks,

Nícolas

Re: [PATCH 00/11] Plane Color Pipeline support for MediaTek

[Xaver Hugl]

Am Mo., 29. Dez. 2025 um 19:53 Uhr schrieb Shengyu Qu <wiagn233@outlook.com>:
> > The curves supported by Gamma are:
> > * scRGB
> > * BT.709
> > * BT.2020
> > * HLG
> >
> > Given the lack of support for writeback connectors on the MediaTek KMS
> > driver, combined with limited hardware documentation, I haven't been
> > able to verify the correctness of each curve, only that they were
> > visually sane (gamma curves made the image on the display brighter,
> > while inverse gamma made it darker).
>
> Hmmm I don't think this is acceptable. sRGB/scRGB has two transfer
> functions mentioned in original specification[1]. To keep color
> accuracy, we need someone from mediatek confirm whether this is
> piece-wise or pure power 2.2 transfer function, this is already done in
> original amdgpu color pipeline series, sRGB means piece-wise while also
> dedicated power 2.2 function exists.
scRGB is a different specification from sRGB and has only piece-wise
and linear, not power 2.2. I seems unlikely that there's really a
problem here.

- Xaver