[PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Hi,

this series mainly ports existining functionality to older SoCs - most
importantly enables alpha blending for RK3036, RK3066, RK3126 and
RK3188.
Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.

Regards,
Alex

Changes in v2:
- drop not yet upstreamed dsp_data_swap from RK3188 regs
- rephrase most commit messages

Alex Bee (5):
  drm: rockchip: add scaling for RK3036 win1
  drm: rockchip: add missing registers for RK3188
  drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
  drm: rockchip: set alpha_en to 0 if it is not used
  drm: rockchip: use overlay windows as such

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 3 files changed, 38 insertions(+), 6 deletions(-)

-- 
2.17.1

[PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Hi,

this series mainly ports existining functionality to older SoCs - most
importantly enables alpha blending for RK3036, RK3066, RK3126 and
RK3188.
Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.

Regards,
Alex

Changes in v2:
- drop not yet upstreamed dsp_data_swap from RK3188 regs
- rephrase most commit messages

Alex Bee (5):
  drm: rockchip: add scaling for RK3036 win1
  drm: rockchip: add missing registers for RK3188
  drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
  drm: rockchip: set alpha_en to 0 if it is not used
  drm: rockchip: use overlay windows as such

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 3 files changed, 38 insertions(+), 6 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Hi,

this series mainly ports existining functionality to older SoCs - most
importantly enables alpha blending for RK3036, RK3066, RK3126 and
RK3188.
Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.

Regards,
Alex

Changes in v2:
- drop not yet upstreamed dsp_data_swap from RK3188 regs
- rephrase most commit messages

Alex Bee (5):
  drm: rockchip: add scaling for RK3036 win1
  drm: rockchip: add missing registers for RK3188
  drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
  drm: rockchip: set alpha_en to 0 if it is not used
  drm: rockchip: use overlay windows as such

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 3 files changed, 38 insertions(+), 6 deletions(-)

-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/5] drm: rockchip: add scaling for RK3036 win1

[Alex Bee]

Add the registers needed to make scaling work on RK3036's win1.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a301..b046910129fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -77,15 +77,20 @@ static const uint64_t format_modifiers_win_lite[] = {
 	DRM_FORMAT_MOD_INVALID,
 };
 
-static const struct vop_scl_regs rk3036_win_scl = {
+static const struct vop_scl_regs rk3036_win0_scl = {
 	.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0xffff, 0x0),
 	.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0xffff, 16),
 	.scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0xffff, 0x0),
 	.scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0xffff, 16),
 };
 
+static const struct vop_scl_regs rk3036_win1_scl = {
+	.scale_yrgb_x = VOP_REG(RK3036_WIN1_SCL_FACTOR_YRGB, 0xffff, 0x0),
+	.scale_yrgb_y = VOP_REG(RK3036_WIN1_SCL_FACTOR_YRGB, 0xffff, 16),
+};
+
 static const struct vop_win_phy rk3036_win0_data = {
-	.scl = &rk3036_win_scl,
+	.scl = &rk3036_win0_scl,
 	.data_formats = formats_win_full,
 	.nformats = ARRAY_SIZE(formats_win_full),
 	.format_modifiers = format_modifiers_win_full,
@@ -102,6 +107,7 @@ static const struct vop_win_phy rk3036_win0_data = {
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
+	.scl = &rk3036_win1_scl,
 	.data_formats = formats_win_lite,
 	.nformats = ARRAY_SIZE(formats_win_lite),
 	.format_modifiers = format_modifiers_win_lite,
-- 
2.17.1

[PATCH v2 1/5] drm: rockchip: add scaling for RK3036 win1

[Alex Bee]

Add the registers needed to make scaling work on RK3036's win1.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a301..b046910129fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -77,15 +77,20 @@ static const uint64_t format_modifiers_win_lite[] = {
 	DRM_FORMAT_MOD_INVALID,
 };
 
-static const struct vop_scl_regs rk3036_win_scl = {
+static const struct vop_scl_regs rk3036_win0_scl = {
 	.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0xffff, 0x0),
 	.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0xffff, 16),
 	.scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0xffff, 0x0),
 	.scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0xffff, 16),
 };
 
+static const struct vop_scl_regs rk3036_win1_scl = {
+	.scale_yrgb_x = VOP_REG(RK3036_WIN1_SCL_FACTOR_YRGB, 0xffff, 0x0),
+	.scale_yrgb_y = VOP_REG(RK3036_WIN1_SCL_FACTOR_YRGB, 0xffff, 16),
+};
+
 static const struct vop_win_phy rk3036_win0_data = {
-	.scl = &rk3036_win_scl,
+	.scl = &rk3036_win0_scl,
 	.data_formats = formats_win_full,
 	.nformats = ARRAY_SIZE(formats_win_full),
 	.format_modifiers = format_modifiers_win_full,
@@ -102,6 +107,7 @@ static const struct vop_win_phy rk3036_win0_data = {
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
+	.scl = &rk3036_win1_scl,
 	.data_formats = formats_win_lite,
 	.nformats = ARRAY_SIZE(formats_win_lite),
 	.format_modifiers = format_modifiers_win_lite,
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/5] drm: rockchip: add scaling for RK3036 win1

[Alex Bee]

Add the registers needed to make scaling work on RK3036's win1.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a301..b046910129fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -77,15 +77,20 @@ static const uint64_t format_modifiers_win_lite[] = {
 	DRM_FORMAT_MOD_INVALID,
 };
 
-static const struct vop_scl_regs rk3036_win_scl = {
+static const struct vop_scl_regs rk3036_win0_scl = {
 	.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0xffff, 0x0),
 	.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0xffff, 16),
 	.scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0xffff, 0x0),
 	.scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0xffff, 16),
 };
 
+static const struct vop_scl_regs rk3036_win1_scl = {
+	.scale_yrgb_x = VOP_REG(RK3036_WIN1_SCL_FACTOR_YRGB, 0xffff, 0x0),
+	.scale_yrgb_y = VOP_REG(RK3036_WIN1_SCL_FACTOR_YRGB, 0xffff, 16),
+};
+
 static const struct vop_win_phy rk3036_win0_data = {
-	.scl = &rk3036_win_scl,
+	.scl = &rk3036_win0_scl,
 	.data_formats = formats_win_full,
 	.nformats = ARRAY_SIZE(formats_win_full),
 	.format_modifiers = format_modifiers_win_full,
@@ -102,6 +107,7 @@ static const struct vop_win_phy rk3036_win0_data = {
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
+	.scl = &rk3036_win1_scl,
 	.data_formats = formats_win_lite,
 	.nformats = ARRAY_SIZE(formats_win_lite),
 	.format_modifiers = format_modifiers_win_lite,
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/5] drm: rockchip: add missing registers for RK3188

[Alex Bee]

Add dither_up, dsp_lut_en and data_blank registers to enable their
respective functionality for RK3188's VOP.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- drop the not yet upstreamed dsp_data_swap and rephrase the commit
  message according

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index b046910129fb..a50877818a86 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -512,6 +512,9 @@ static const struct vop_common rk3188_common = {
 	.dither_down_en = VOP_REG(RK3188_DSP_CTRL0, 0x1, 11),
 	.dither_down_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 10),
 	.dsp_blank = VOP_REG(RK3188_DSP_CTRL1, 0x3, 24),
+	.dither_up = VOP_REG(RK3188_DSP_CTRL0, 0x1, 9),
+	.dsp_lut_en = VOP_REG(RK3188_SYS_CTRL, 0x1, 28),
+	.data_blank = VOP_REG(RK3188_DSP_CTRL1, 0x1, 25),
 };
 
 static const struct vop_win_data rk3188_vop_win_data[] = {
-- 
2.17.1

[PATCH v2 2/5] drm: rockchip: add missing registers for RK3188

[Alex Bee]

Add dither_up, dsp_lut_en and data_blank registers to enable their
respective functionality for RK3188's VOP.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- drop the not yet upstreamed dsp_data_swap and rephrase the commit
  message according

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index b046910129fb..a50877818a86 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -512,6 +512,9 @@ static const struct vop_common rk3188_common = {
 	.dither_down_en = VOP_REG(RK3188_DSP_CTRL0, 0x1, 11),
 	.dither_down_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 10),
 	.dsp_blank = VOP_REG(RK3188_DSP_CTRL1, 0x3, 24),
+	.dither_up = VOP_REG(RK3188_DSP_CTRL0, 0x1, 9),
+	.dsp_lut_en = VOP_REG(RK3188_SYS_CTRL, 0x1, 28),
+	.data_blank = VOP_REG(RK3188_DSP_CTRL1, 0x1, 25),
 };
 
 static const struct vop_win_data rk3188_vop_win_data[] = {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/5] drm: rockchip: add missing registers for RK3188

[Alex Bee]

Add dither_up, dsp_lut_en and data_blank registers to enable their
respective functionality for RK3188's VOP.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- drop the not yet upstreamed dsp_data_swap and rephrase the commit
  message according

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index b046910129fb..a50877818a86 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -512,6 +512,9 @@ static const struct vop_common rk3188_common = {
 	.dither_down_en = VOP_REG(RK3188_DSP_CTRL0, 0x1, 11),
 	.dither_down_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 10),
 	.dsp_blank = VOP_REG(RK3188_DSP_CTRL1, 0x3, 24),
+	.dither_up = VOP_REG(RK3188_DSP_CTRL0, 0x1, 9),
+	.dsp_lut_en = VOP_REG(RK3188_SYS_CTRL, 0x1, 28),
+	.data_blank = VOP_REG(RK3188_DSP_CTRL1, 0x1, 25),
 };
 
 static const struct vop_win_data rk3188_vop_win_data[] = {
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188

[Alex Bee]

With commit 2aae8ed1f390
("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") alpha
support was introduced for PX30's VOP.
RK3036, RK3066, RK3126 and RK3188 VOPs support alpha blending in the
same manner.
With the exception of RK3066 all of them support pre-multiplied alpha.

Lets add these registers to make this work for those VOPs as well.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 21 +++++++++++++++++++++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a50877818a86..5a13b4ab77e1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -104,6 +104,9 @@ static const struct vop_win_phy rk3036_win0_data = {
 	.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 18),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 0),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
@@ -119,6 +122,9 @@ static const struct vop_win_phy rk3036_win1_data = {
 	.dsp_st = VOP_REG(RK3036_WIN1_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3036_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_data rk3036_vop_win_data[] = {
@@ -185,6 +191,9 @@ static const struct vop_win_phy rk3126_win1_data = {
 	.dsp_st = VOP_REG(RK3126_WIN1_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3126_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_data rk3126_vop_win_data[] = {
@@ -364,6 +373,8 @@ static const struct vop_win_phy rk3066_win0_data = {
 	.uv_mst = VOP_REG(RK3066_WIN0_CBR_MST0, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN0_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3066_WIN0_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 21),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 0),
 };
 
 static const struct vop_win_phy rk3066_win1_data = {
@@ -381,6 +392,8 @@ static const struct vop_win_phy rk3066_win1_data = {
 	.uv_mst = VOP_REG(RK3066_WIN1_CBR_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN1_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3066_WIN1_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 22),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 1),
 };
 
 static const struct vop_win_phy rk3066_win2_data = {
@@ -394,6 +407,8 @@ static const struct vop_win_phy rk3066_win2_data = {
 	.dsp_st = VOP_REG(RK3066_WIN2_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3066_WIN2_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN2_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 23),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 2),
 };
 
 static const struct vop_modeset rk3066_modeset = {
@@ -476,6 +491,9 @@ static const struct vop_win_phy rk3188_win0_data = {
 	.yrgb_mst = VOP_REG(RK3188_WIN0_YRGB_MST0, 0xffffffff, 0),
 	.uv_mst = VOP_REG(RK3188_WIN0_CBR_MST0, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 0),
+	.alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 18),
+	.alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 0),
+	.alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_phy rk3188_win1_data = {
@@ -490,6 +508,9 @@ static const struct vop_win_phy rk3188_win1_data = {
 	.dsp_st = VOP_REG(RK3188_WIN1_DSP_ST, 0x0fff0fff, 0),
 	.yrgb_mst = VOP_REG(RK3188_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_modeset rk3188_modeset = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 6e9fa5815d4d..0b3cd65ba5c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -955,6 +955,7 @@
 #define RK3188_DSP_CTRL0		0x04
 #define RK3188_DSP_CTRL1		0x08
 #define RK3188_INT_STATUS		0x10
+#define RK3188_ALPHA_CTRL		0x14
 #define RK3188_WIN0_YRGB_MST0		0x20
 #define RK3188_WIN0_CBR_MST0		0x24
 #define RK3188_WIN0_YRGB_MST1		0x28
-- 
2.17.1

[PATCH v2 3/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188

[Alex Bee]

With commit 2aae8ed1f390
("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") alpha
support was introduced for PX30's VOP.
RK3036, RK3066, RK3126 and RK3188 VOPs support alpha blending in the
same manner.
With the exception of RK3066 all of them support pre-multiplied alpha.

Lets add these registers to make this work for those VOPs as well.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 21 +++++++++++++++++++++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a50877818a86..5a13b4ab77e1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -104,6 +104,9 @@ static const struct vop_win_phy rk3036_win0_data = {
 	.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 18),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 0),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
@@ -119,6 +122,9 @@ static const struct vop_win_phy rk3036_win1_data = {
 	.dsp_st = VOP_REG(RK3036_WIN1_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3036_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_data rk3036_vop_win_data[] = {
@@ -185,6 +191,9 @@ static const struct vop_win_phy rk3126_win1_data = {
 	.dsp_st = VOP_REG(RK3126_WIN1_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3126_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_data rk3126_vop_win_data[] = {
@@ -364,6 +373,8 @@ static const struct vop_win_phy rk3066_win0_data = {
 	.uv_mst = VOP_REG(RK3066_WIN0_CBR_MST0, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN0_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3066_WIN0_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 21),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 0),
 };
 
 static const struct vop_win_phy rk3066_win1_data = {
@@ -381,6 +392,8 @@ static const struct vop_win_phy rk3066_win1_data = {
 	.uv_mst = VOP_REG(RK3066_WIN1_CBR_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN1_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3066_WIN1_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 22),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 1),
 };
 
 static const struct vop_win_phy rk3066_win2_data = {
@@ -394,6 +407,8 @@ static const struct vop_win_phy rk3066_win2_data = {
 	.dsp_st = VOP_REG(RK3066_WIN2_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3066_WIN2_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN2_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 23),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 2),
 };
 
 static const struct vop_modeset rk3066_modeset = {
@@ -476,6 +491,9 @@ static const struct vop_win_phy rk3188_win0_data = {
 	.yrgb_mst = VOP_REG(RK3188_WIN0_YRGB_MST0, 0xffffffff, 0),
 	.uv_mst = VOP_REG(RK3188_WIN0_CBR_MST0, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 0),
+	.alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 18),
+	.alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 0),
+	.alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_phy rk3188_win1_data = {
@@ -490,6 +508,9 @@ static const struct vop_win_phy rk3188_win1_data = {
 	.dsp_st = VOP_REG(RK3188_WIN1_DSP_ST, 0x0fff0fff, 0),
 	.yrgb_mst = VOP_REG(RK3188_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_modeset rk3188_modeset = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 6e9fa5815d4d..0b3cd65ba5c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -955,6 +955,7 @@
 #define RK3188_DSP_CTRL0		0x04
 #define RK3188_DSP_CTRL1		0x08
 #define RK3188_INT_STATUS		0x10
+#define RK3188_ALPHA_CTRL		0x14
 #define RK3188_WIN0_YRGB_MST0		0x20
 #define RK3188_WIN0_CBR_MST0		0x24
 #define RK3188_WIN0_YRGB_MST1		0x28
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188

[Alex Bee]

With commit 2aae8ed1f390
("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") alpha
support was introduced for PX30's VOP.
RK3036, RK3066, RK3126 and RK3188 VOPs support alpha blending in the
same manner.
With the exception of RK3066 all of them support pre-multiplied alpha.

Lets add these registers to make this work for those VOPs as well.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 21 +++++++++++++++++++++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a50877818a86..5a13b4ab77e1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -104,6 +104,9 @@ static const struct vop_win_phy rk3036_win0_data = {
 	.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 18),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 0),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
@@ -119,6 +122,9 @@ static const struct vop_win_phy rk3036_win1_data = {
 	.dsp_st = VOP_REG(RK3036_WIN1_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3036_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_data rk3036_vop_win_data[] = {
@@ -185,6 +191,9 @@ static const struct vop_win_phy rk3126_win1_data = {
 	.dsp_st = VOP_REG(RK3126_WIN1_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3126_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_data rk3126_vop_win_data[] = {
@@ -364,6 +373,8 @@ static const struct vop_win_phy rk3066_win0_data = {
 	.uv_mst = VOP_REG(RK3066_WIN0_CBR_MST0, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN0_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3066_WIN0_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 21),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 0),
 };
 
 static const struct vop_win_phy rk3066_win1_data = {
@@ -381,6 +392,8 @@ static const struct vop_win_phy rk3066_win1_data = {
 	.uv_mst = VOP_REG(RK3066_WIN1_CBR_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN1_VIR, 0xffff, 0),
 	.uv_vir = VOP_REG(RK3066_WIN1_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 22),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 1),
 };
 
 static const struct vop_win_phy rk3066_win2_data = {
@@ -394,6 +407,8 @@ static const struct vop_win_phy rk3066_win2_data = {
 	.dsp_st = VOP_REG(RK3066_WIN2_DSP_ST, 0x1fff1fff, 0),
 	.yrgb_mst = VOP_REG(RK3066_WIN2_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3066_WIN2_VIR, 0xffff, 0),
+	.alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 23),
+	.alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 2),
 };
 
 static const struct vop_modeset rk3066_modeset = {
@@ -476,6 +491,9 @@ static const struct vop_win_phy rk3188_win0_data = {
 	.yrgb_mst = VOP_REG(RK3188_WIN0_YRGB_MST0, 0xffffffff, 0),
 	.uv_mst = VOP_REG(RK3188_WIN0_CBR_MST0, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 0),
+	.alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 18),
+	.alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 0),
+	.alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_win_phy rk3188_win1_data = {
@@ -490,6 +508,9 @@ static const struct vop_win_phy rk3188_win1_data = {
 	.dsp_st = VOP_REG(RK3188_WIN1_DSP_ST, 0x0fff0fff, 0),
 	.yrgb_mst = VOP_REG(RK3188_WIN1_MST, 0xffffffff, 0),
 	.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 16),
+	.alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 19),
+	.alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 1),
+	.alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
 };
 
 static const struct vop_modeset rk3188_modeset = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 6e9fa5815d4d..0b3cd65ba5c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -955,6 +955,7 @@
 #define RK3188_DSP_CTRL0		0x04
 #define RK3188_DSP_CTRL1		0x08
 #define RK3188_INT_STATUS		0x10
+#define RK3188_ALPHA_CTRL		0x14
 #define RK3188_WIN0_YRGB_MST0		0x20
 #define RK3188_WIN0_CBR_MST0		0x24
 #define RK3188_WIN0_YRGB_MST1		0x28
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/5] drm: rockchip: set alpha_en to 0 if it is not used

[Alex Bee]

alpha_en should be set to 0 if it is not used, i.e. to disable alpha
blending if it was enabled before and should be disabled now.

Fixes: 2aae8ed1f390 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP")

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- capitalize "F" of "Fixes" in the commit message

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..0f23144491e4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1013,6 +1013,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 		VOP_WIN_SET(vop, win, alpha_en, 1);
 	} else {
 		VOP_WIN_SET(vop, win, src_alpha_ctl, SRC_ALPHA_EN(0));
+		VOP_WIN_SET(vop, win, alpha_en, 0);
 	}
 
 	VOP_WIN_SET(vop, win, enable, 1);
-- 
2.17.1

[PATCH v2 4/5] drm: rockchip: set alpha_en to 0 if it is not used

[Alex Bee]

alpha_en should be set to 0 if it is not used, i.e. to disable alpha
blending if it was enabled before and should be disabled now.

Fixes: 2aae8ed1f390 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP")

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- capitalize "F" of "Fixes" in the commit message

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..0f23144491e4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1013,6 +1013,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 		VOP_WIN_SET(vop, win, alpha_en, 1);
 	} else {
 		VOP_WIN_SET(vop, win, src_alpha_ctl, SRC_ALPHA_EN(0));
+		VOP_WIN_SET(vop, win, alpha_en, 0);
 	}
 
 	VOP_WIN_SET(vop, win, enable, 1);
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 4/5] drm: rockchip: set alpha_en to 0 if it is not used

[Alex Bee]

alpha_en should be set to 0 if it is not used, i.e. to disable alpha
blending if it was enabled before and should be disabled now.

Fixes: 2aae8ed1f390 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP")

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- capitalize "F" of "Fixes" in the commit message

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..0f23144491e4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1013,6 +1013,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 		VOP_WIN_SET(vop, win, alpha_en, 1);
 	} else {
 		VOP_WIN_SET(vop, win, src_alpha_ctl, SRC_ALPHA_EN(0));
+		VOP_WIN_SET(vop, win, alpha_en, 0);
 	}
 
 	VOP_WIN_SET(vop, win, enable, 1);
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/5] drm: rockchip: use overlay windows as such

[Alex Bee]

As stated in the comment for rk3288_vop_win_data windows that are
supposed to be an overlay window are missused as HWC windows due to the
missing implementation of that window type in the VOP driver.

This also applies to VOPs RK3036, RK3126, RK3188 and RK3228, which all
have at least one (1) dedicated HWC window (which are not currently
defined in the driver).
Since all the VOPs mentioned have only one (1) overlay window and all
now support alpha blending , it should also be used as such, as this
offers a much broader usage perspective for them.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 5a13b4ab77e1..b4a00f13b559 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -131,7 +131,7 @@ static const struct vop_win_data rk3036_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3036_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3036_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3036_vop_intrs[] = {
@@ -200,7 +200,7 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3036_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3126_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3126_vop = {
@@ -542,7 +542,7 @@ static const struct vop_win_data rk3188_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3188_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3188_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3188_vop_intrs[] = {
@@ -979,7 +979,7 @@ static const struct vop_win_data rk3228_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3288_win01_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x40, .phy = &rk3288_win01_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3228_vop = {
-- 
2.17.1

[PATCH v2 5/5] drm: rockchip: use overlay windows as such

[Alex Bee]

As stated in the comment for rk3288_vop_win_data windows that are
supposed to be an overlay window are missused as HWC windows due to the
missing implementation of that window type in the VOP driver.

This also applies to VOPs RK3036, RK3126, RK3188 and RK3228, which all
have at least one (1) dedicated HWC window (which are not currently
defined in the driver).
Since all the VOPs mentioned have only one (1) overlay window and all
now support alpha blending , it should also be used as such, as this
offers a much broader usage perspective for them.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 5a13b4ab77e1..b4a00f13b559 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -131,7 +131,7 @@ static const struct vop_win_data rk3036_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3036_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3036_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3036_vop_intrs[] = {
@@ -200,7 +200,7 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3036_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3126_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3126_vop = {
@@ -542,7 +542,7 @@ static const struct vop_win_data rk3188_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3188_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3188_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3188_vop_intrs[] = {
@@ -979,7 +979,7 @@ static const struct vop_win_data rk3228_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3288_win01_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x40, .phy = &rk3288_win01_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3228_vop = {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 5/5] drm: rockchip: use overlay windows as such

[Alex Bee]

As stated in the comment for rk3288_vop_win_data windows that are
supposed to be an overlay window are missused as HWC windows due to the
missing implementation of that window type in the VOP driver.

This also applies to VOPs RK3036, RK3126, RK3188 and RK3228, which all
have at least one (1) dedicated HWC window (which are not currently
defined in the driver).
Since all the VOPs mentioned have only one (1) overlay window and all
now support alpha blending , it should also be used as such, as this
offers a much broader usage perspective for them.

Signed-off-by: Alex Bee <knaerzche@gmail.com>
---

Changes in v2:
- rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 5a13b4ab77e1..b4a00f13b559 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -131,7 +131,7 @@ static const struct vop_win_data rk3036_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3036_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3036_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3036_vop_intrs[] = {
@@ -200,7 +200,7 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3036_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3126_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3126_vop = {
@@ -542,7 +542,7 @@ static const struct vop_win_data rk3188_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3188_win0_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x00, .phy = &rk3188_win1_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3188_vop_intrs[] = {
@@ -979,7 +979,7 @@ static const struct vop_win_data rk3228_vop_win_data[] = {
 	{ .base = 0x00, .phy = &rk3288_win01_data,
 	  .type = DRM_PLANE_TYPE_PRIMARY },
 	{ .base = 0x40, .phy = &rk3288_win01_data,
-	  .type = DRM_PLANE_TYPE_CURSOR },
+	  .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3228_vop = {
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>
> Hi,
>
> this series mainly ports existining functionality to older SoCs - most
> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> RK3188.
> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.

This doesn't make much sense, the cursor overlay is really just a hint
for legacy ioctls that this is the overlay that should be used for
cursors. Compositors should try to use such planes as full overlays
(if they don't want to use them as a cursor). So sounds like a case of
"fix your compositor".

For atomic there's 0 difference between a overlay or a cursor (primary
plane is still treated somewhat special in the RMFB ioctl, but again
that's for backwards compat reasons with existing uapi, not because
the primary plane is different).

What does happen though is that this breaks cursor for legacy
userspace, which is probably not really what you want.
-Daniel


>
> Regards,
> Alex
>
> Changes in v2:
> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> - rephrase most commit messages
>
> Alex Bee (5):
>   drm: rockchip: add scaling for RK3036 win1
>   drm: rockchip: add missing registers for RK3188
>   drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>   drm: rockchip: set alpha_en to 0 if it is not used
>   drm: rockchip: use overlay windows as such
>
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>  3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.17.1
>


--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>
> Hi,
>
> this series mainly ports existining functionality to older SoCs - most
> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> RK3188.
> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.

This doesn't make much sense, the cursor overlay is really just a hint
for legacy ioctls that this is the overlay that should be used for
cursors. Compositors should try to use such planes as full overlays
(if they don't want to use them as a cursor). So sounds like a case of
"fix your compositor".

For atomic there's 0 difference between a overlay or a cursor (primary
plane is still treated somewhat special in the RMFB ioctl, but again
that's for backwards compat reasons with existing uapi, not because
the primary plane is different).

What does happen though is that this breaks cursor for legacy
userspace, which is probably not really what you want.
-Daniel


>
> Regards,
> Alex
>
> Changes in v2:
> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> - rephrase most commit messages
>
> Alex Bee (5):
>   drm: rockchip: add scaling for RK3036 win1
>   drm: rockchip: add missing registers for RK3188
>   drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>   drm: rockchip: set alpha_en to 0 if it is not used
>   drm: rockchip: use overlay windows as such
>
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>  3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.17.1
>


--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>
> Hi,
>
> this series mainly ports existining functionality to older SoCs - most
> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> RK3188.
> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.

This doesn't make much sense, the cursor overlay is really just a hint
for legacy ioctls that this is the overlay that should be used for
cursors. Compositors should try to use such planes as full overlays
(if they don't want to use them as a cursor). So sounds like a case of
"fix your compositor".

For atomic there's 0 difference between a overlay or a cursor (primary
plane is still treated somewhat special in the RMFB ioctl, but again
that's for backwards compat reasons with existing uapi, not because
the primary plane is different).

What does happen though is that this breaks cursor for legacy
userspace, which is probably not really what you want.
-Daniel


>
> Regards,
> Alex
>
> Changes in v2:
> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> - rephrase most commit messages
>
> Alex Bee (5):
>   drm: rockchip: add scaling for RK3036 win1
>   drm: rockchip: add missing registers for RK3188
>   drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>   drm: rockchip: set alpha_en to 0 if it is not used
>   drm: rockchip: use overlay windows as such
>
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>  3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.17.1
>


--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>> Hi,
>>
>> this series mainly ports existining functionality to older SoCs - most
>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>> RK3188.
>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> This doesn't make much sense, the cursor overlay is really just a hint
> for legacy ioctls that this is the overlay that should be used for
> cursors. Compositors should try to use such planes as full overlays
> (if they don't want to use them as a cursor). So sounds like a case of
> "fix your compositor".
I agree here - but: If HWC windows would have been implemented in this 
particular driver, their max size would be 128x128 on some SoCs - so 
they woudn't be really suitable to create an OSD overlay at 4K, for 
example. I don't know, but I guess other vendors implement their HWC 
windows on this reduced HW resources as well. I guess that is one of the 
reasons, why userspace, which aims to be cross-plattfrom, avoids 
DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a 
heuristic, indeed)
> For atomic there's 0 difference between a overlay or a cursor (primary
> plane is still treated somewhat special in the RMFB ioctl, but again
> that's for backwards compat reasons with existing uapi, not because
> the primary plane is different).
>
> What does happen though is that this breaks cursor for legacy
> userspace, which is probably not really what you want.

Indeed not.

Beforhand I was submiiting this, I looked arround and couldn't find 
anything which relies or even depends of a cursor window to be 
available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is 
mandatory, everything else is optional.

> -Daniel
>
>
>> Regards,
>> Alex
>>
>> Changes in v2:
>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>> - rephrase most commit messages
>>
>> Alex Bee (5):
>>    drm: rockchip: add scaling for RK3036 win1
>>    drm: rockchip: add missing registers for RK3188
>>    drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>    drm: rockchip: set alpha_en to 0 if it is not used
>>    drm: rockchip: use overlay windows as such
>>
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>>   3 files changed, 38 insertions(+), 6 deletions(-)
>>
>> --
>> 2.17.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Best Regards

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>> Hi,
>>
>> this series mainly ports existining functionality to older SoCs - most
>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>> RK3188.
>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> This doesn't make much sense, the cursor overlay is really just a hint
> for legacy ioctls that this is the overlay that should be used for
> cursors. Compositors should try to use such planes as full overlays
> (if they don't want to use them as a cursor). So sounds like a case of
> "fix your compositor".
I agree here - but: If HWC windows would have been implemented in this 
particular driver, their max size would be 128x128 on some SoCs - so 
they woudn't be really suitable to create an OSD overlay at 4K, for 
example. I don't know, but I guess other vendors implement their HWC 
windows on this reduced HW resources as well. I guess that is one of the 
reasons, why userspace, which aims to be cross-plattfrom, avoids 
DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a 
heuristic, indeed)
> For atomic there's 0 difference between a overlay or a cursor (primary
> plane is still treated somewhat special in the RMFB ioctl, but again
> that's for backwards compat reasons with existing uapi, not because
> the primary plane is different).
>
> What does happen though is that this breaks cursor for legacy
> userspace, which is probably not really what you want.

Indeed not.

Beforhand I was submiiting this, I looked arround and couldn't find 
anything which relies or even depends of a cursor window to be 
available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is 
mandatory, everything else is optional.

> -Daniel
>
>
>> Regards,
>> Alex
>>
>> Changes in v2:
>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>> - rephrase most commit messages
>>
>> Alex Bee (5):
>>    drm: rockchip: add scaling for RK3036 win1
>>    drm: rockchip: add missing registers for RK3188
>>    drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>    drm: rockchip: set alpha_en to 0 if it is not used
>>    drm: rockchip: use overlay windows as such
>>
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>>   3 files changed, 38 insertions(+), 6 deletions(-)
>>
>> --
>> 2.17.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Best Regards


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>> Hi,
>>
>> this series mainly ports existining functionality to older SoCs - most
>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>> RK3188.
>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> This doesn't make much sense, the cursor overlay is really just a hint
> for legacy ioctls that this is the overlay that should be used for
> cursors. Compositors should try to use such planes as full overlays
> (if they don't want to use them as a cursor). So sounds like a case of
> "fix your compositor".
I agree here - but: If HWC windows would have been implemented in this 
particular driver, their max size would be 128x128 on some SoCs - so 
they woudn't be really suitable to create an OSD overlay at 4K, for 
example. I don't know, but I guess other vendors implement their HWC 
windows on this reduced HW resources as well. I guess that is one of the 
reasons, why userspace, which aims to be cross-plattfrom, avoids 
DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a 
heuristic, indeed)
> For atomic there's 0 difference between a overlay or a cursor (primary
> plane is still treated somewhat special in the RMFB ioctl, but again
> that's for backwards compat reasons with existing uapi, not because
> the primary plane is different).
>
> What does happen though is that this breaks cursor for legacy
> userspace, which is probably not really what you want.

Indeed not.

Beforhand I was submiiting this, I looked arround and couldn't find 
anything which relies or even depends of a cursor window to be 
available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is 
mandatory, everything else is optional.

> -Daniel
>
>
>> Regards,
>> Alex
>>
>> Changes in v2:
>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>> - rephrase most commit messages
>>
>> Alex Bee (5):
>>    drm: rockchip: add scaling for RK3036 win1
>>    drm: rockchip: add missing registers for RK3188
>>    drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>    drm: rockchip: set alpha_en to 0 if it is not used
>>    drm: rockchip: use overlay windows as such
>>
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>>   3 files changed, 38 insertions(+), 6 deletions(-)
>>
>> --
>> 2.17.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Best Regards

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
>
>
> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> > On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
> >> Hi,
> >>
> >> this series mainly ports existining functionality to older SoCs - most
> >> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> >> RK3188.
> >> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> >> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> > This doesn't make much sense, the cursor overlay is really just a hint
> > for legacy ioctls that this is the overlay that should be used for
> > cursors. Compositors should try to use such planes as full overlays
> > (if they don't want to use them as a cursor). So sounds like a case of
> > "fix your compositor".
> I agree here - but: If HWC windows would have been implemented in this
> particular driver, their max size would be 128x128 on some SoCs - so
> they woudn't be really suitable to create an OSD overlay at 4K, for
> example. I don't know, but I guess other vendors implement their HWC
> windows on this reduced HW resources as well. I guess that is one of the
> reasons, why userspace, which aims to be cross-plattfrom, avoids
> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
> heuristic, indeed)

Which userspace does that? We should fix that, not try to work around
that in all the drivers in upstream, that wont work.
-Daniel

> > For atomic there's 0 difference between a overlay or a cursor (primary
> > plane is still treated somewhat special in the RMFB ioctl, but again
> > that's for backwards compat reasons with existing uapi, not because
> > the primary plane is different).
> >
> > What does happen though is that this breaks cursor for legacy
> > userspace, which is probably not really what you want.
>
> Indeed not.
>
> Beforhand I was submiiting this, I looked arround and couldn't find
> anything which relies or even depends of a cursor window to be
> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
> mandatory, everything else is optional.
>
> > -Daniel
> >
> >
> >> Regards,
> >> Alex
> >>
> >> Changes in v2:
> >> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> >> - rephrase most commit messages
> >>
> >> Alex Bee (5):
> >>    drm: rockchip: add scaling for RK3036 win1
> >>    drm: rockchip: add missing registers for RK3188
> >>    drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
> >>    drm: rockchip: set alpha_en to 0 if it is not used
> >>    drm: rockchip: use overlay windows as such
> >>
> >>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
> >>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
> >>   drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> >>   3 files changed, 38 insertions(+), 6 deletions(-)
> >>
> >> --
> >> 2.17.1
> >>
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> Best Regards
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
>
>
> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> > On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
> >> Hi,
> >>
> >> this series mainly ports existining functionality to older SoCs - most
> >> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> >> RK3188.
> >> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> >> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> > This doesn't make much sense, the cursor overlay is really just a hint
> > for legacy ioctls that this is the overlay that should be used for
> > cursors. Compositors should try to use such planes as full overlays
> > (if they don't want to use them as a cursor). So sounds like a case of
> > "fix your compositor".
> I agree here - but: If HWC windows would have been implemented in this
> particular driver, their max size would be 128x128 on some SoCs - so
> they woudn't be really suitable to create an OSD overlay at 4K, for
> example. I don't know, but I guess other vendors implement their HWC
> windows on this reduced HW resources as well. I guess that is one of the
> reasons, why userspace, which aims to be cross-plattfrom, avoids
> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
> heuristic, indeed)

Which userspace does that? We should fix that, not try to work around
that in all the drivers in upstream, that wont work.
-Daniel

> > For atomic there's 0 difference between a overlay or a cursor (primary
> > plane is still treated somewhat special in the RMFB ioctl, but again
> > that's for backwards compat reasons with existing uapi, not because
> > the primary plane is different).
> >
> > What does happen though is that this breaks cursor for legacy
> > userspace, which is probably not really what you want.
>
> Indeed not.
>
> Beforhand I was submiiting this, I looked arround and couldn't find
> anything which relies or even depends of a cursor window to be
> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
> mandatory, everything else is optional.
>
> > -Daniel
> >
> >
> >> Regards,
> >> Alex
> >>
> >> Changes in v2:
> >> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> >> - rephrase most commit messages
> >>
> >> Alex Bee (5):
> >>    drm: rockchip: add scaling for RK3036 win1
> >>    drm: rockchip: add missing registers for RK3188
> >>    drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
> >>    drm: rockchip: set alpha_en to 0 if it is not used
> >>    drm: rockchip: use overlay windows as such
> >>
> >>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
> >>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
> >>   drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> >>   3 files changed, 38 insertions(+), 6 deletions(-)
> >>
> >> --
> >> 2.17.1
> >>
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> Best Regards
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
>
>
> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> > On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
> >> Hi,
> >>
> >> this series mainly ports existining functionality to older SoCs - most
> >> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> >> RK3188.
> >> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> >> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> > This doesn't make much sense, the cursor overlay is really just a hint
> > for legacy ioctls that this is the overlay that should be used for
> > cursors. Compositors should try to use such planes as full overlays
> > (if they don't want to use them as a cursor). So sounds like a case of
> > "fix your compositor".
> I agree here - but: If HWC windows would have been implemented in this
> particular driver, their max size would be 128x128 on some SoCs - so
> they woudn't be really suitable to create an OSD overlay at 4K, for
> example. I don't know, but I guess other vendors implement their HWC
> windows on this reduced HW resources as well. I guess that is one of the
> reasons, why userspace, which aims to be cross-plattfrom, avoids
> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
> heuristic, indeed)

Which userspace does that? We should fix that, not try to work around
that in all the drivers in upstream, that wont work.
-Daniel

> > For atomic there's 0 difference between a overlay or a cursor (primary
> > plane is still treated somewhat special in the RMFB ioctl, but again
> > that's for backwards compat reasons with existing uapi, not because
> > the primary plane is different).
> >
> > What does happen though is that this breaks cursor for legacy
> > userspace, which is probably not really what you want.
>
> Indeed not.
>
> Beforhand I was submiiting this, I looked arround and couldn't find
> anything which relies or even depends of a cursor window to be
> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
> mandatory, everything else is optional.
>
> > -Daniel
> >
> >
> >> Regards,
> >> Alex
> >>
> >> Changes in v2:
> >> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> >> - rephrase most commit messages
> >>
> >> Alex Bee (5):
> >>    drm: rockchip: add scaling for RK3036 win1
> >>    drm: rockchip: add missing registers for RK3188
> >>    drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
> >>    drm: rockchip: set alpha_en to 0 if it is not used
> >>    drm: rockchip: use overlay windows as such
> >>
> >>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
> >>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
> >>   drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> >>   3 files changed, 38 insertions(+), 6 deletions(-)
> >>
> >> --
> >> 2.17.1
> >>
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> Best Regards
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
>>
>> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
>>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> this series mainly ports existining functionality to older SoCs - most
>>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>>>> RK3188.
>>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
>>> This doesn't make much sense, the cursor overlay is really just a hint
>>> for legacy ioctls that this is the overlay that should be used for
>>> cursors. Compositors should try to use such planes as full overlays
>>> (if they don't want to use them as a cursor). So sounds like a case of
>>> "fix your compositor".
>> I agree here - but: If HWC windows would have been implemented in this
>> particular driver, their max size would be 128x128 on some SoCs - so
>> they woudn't be really suitable to create an OSD overlay at 4K, for
>> example. I don't know, but I guess other vendors implement their HWC
>> windows on this reduced HW resources as well. I guess that is one of the
>> reasons, why userspace, which aims to be cross-plattfrom, avoids
>> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
>> heuristic, indeed)
> Which userspace does that?
kodi-gbm: 
https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406 

> We should fix that, not try to work around
> that in all the drivers in upstream, that wont work.
You're right I'll drop this part.
> -Daniel
>
>>> For atomic there's 0 difference between a overlay or a cursor (primary
>>> plane is still treated somewhat special in the RMFB ioctl, but again
>>> that's for backwards compat reasons with existing uapi, not because
>>> the primary plane is different).
>>>
>>> What does happen though is that this breaks cursor for legacy
>>> userspace, which is probably not really what you want.
>> Indeed not.
>>
>> Beforhand I was submiiting this, I looked arround and couldn't find
>> anything which relies or even depends of a cursor window to be
>> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
>> mandatory, everything else is optional.
>>
>>> -Daniel
>>>
>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> Changes in v2:
>>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>>>> - rephrase most commit messages
>>>>
>>>> Alex Bee (5):
>>>>     drm: rockchip: add scaling for RK3036 win1
>>>>     drm: rockchip: add missing registers for RK3188
>>>>     drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>>>     drm: rockchip: set alpha_en to 0 if it is not used
>>>>     drm: rockchip: use overlay windows as such
>>>>
>>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>>>>    3 files changed, 38 insertions(+), 6 deletions(-)
>>>>
>>>> --
>>>> 2.17.1
>>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>> Best Regards
>>
>
Best regards

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
>>
>> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
>>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> this series mainly ports existining functionality to older SoCs - most
>>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>>>> RK3188.
>>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
>>> This doesn't make much sense, the cursor overlay is really just a hint
>>> for legacy ioctls that this is the overlay that should be used for
>>> cursors. Compositors should try to use such planes as full overlays
>>> (if they don't want to use them as a cursor). So sounds like a case of
>>> "fix your compositor".
>> I agree here - but: If HWC windows would have been implemented in this
>> particular driver, their max size would be 128x128 on some SoCs - so
>> they woudn't be really suitable to create an OSD overlay at 4K, for
>> example. I don't know, but I guess other vendors implement their HWC
>> windows on this reduced HW resources as well. I guess that is one of the
>> reasons, why userspace, which aims to be cross-plattfrom, avoids
>> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
>> heuristic, indeed)
> Which userspace does that?
kodi-gbm: 
https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406 

> We should fix that, not try to work around
> that in all the drivers in upstream, that wont work.
You're right I'll drop this part.
> -Daniel
>
>>> For atomic there's 0 difference between a overlay or a cursor (primary
>>> plane is still treated somewhat special in the RMFB ioctl, but again
>>> that's for backwards compat reasons with existing uapi, not because
>>> the primary plane is different).
>>>
>>> What does happen though is that this breaks cursor for legacy
>>> userspace, which is probably not really what you want.
>> Indeed not.
>>
>> Beforhand I was submiiting this, I looked arround and couldn't find
>> anything which relies or even depends of a cursor window to be
>> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
>> mandatory, everything else is optional.
>>
>>> -Daniel
>>>
>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> Changes in v2:
>>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>>>> - rephrase most commit messages
>>>>
>>>> Alex Bee (5):
>>>>     drm: rockchip: add scaling for RK3036 win1
>>>>     drm: rockchip: add missing registers for RK3188
>>>>     drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>>>     drm: rockchip: set alpha_en to 0 if it is not used
>>>>     drm: rockchip: use overlay windows as such
>>>>
>>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>>>>    3 files changed, 38 insertions(+), 6 deletions(-)
>>>>
>>>> --
>>>> 2.17.1
>>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>> Best Regards
>>
>
Best regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Alex Bee]

Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
>>
>> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
>>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> this series mainly ports existining functionality to older SoCs - most
>>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
>>>> RK3188.
>>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
>>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
>>> This doesn't make much sense, the cursor overlay is really just a hint
>>> for legacy ioctls that this is the overlay that should be used for
>>> cursors. Compositors should try to use such planes as full overlays
>>> (if they don't want to use them as a cursor). So sounds like a case of
>>> "fix your compositor".
>> I agree here - but: If HWC windows would have been implemented in this
>> particular driver, their max size would be 128x128 on some SoCs - so
>> they woudn't be really suitable to create an OSD overlay at 4K, for
>> example. I don't know, but I guess other vendors implement their HWC
>> windows on this reduced HW resources as well. I guess that is one of the
>> reasons, why userspace, which aims to be cross-plattfrom, avoids
>> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
>> heuristic, indeed)
> Which userspace does that?
kodi-gbm: 
https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406 

> We should fix that, not try to work around
> that in all the drivers in upstream, that wont work.
You're right I'll drop this part.
> -Daniel
>
>>> For atomic there's 0 difference between a overlay or a cursor (primary
>>> plane is still treated somewhat special in the RMFB ioctl, but again
>>> that's for backwards compat reasons with existing uapi, not because
>>> the primary plane is different).
>>>
>>> What does happen though is that this breaks cursor for legacy
>>> userspace, which is probably not really what you want.
>> Indeed not.
>>
>> Beforhand I was submiiting this, I looked arround and couldn't find
>> anything which relies or even depends of a cursor window to be
>> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
>> mandatory, everything else is optional.
>>
>>> -Daniel
>>>
>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> Changes in v2:
>>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
>>>> - rephrase most commit messages
>>>>
>>>> Alex Bee (5):
>>>>     drm: rockchip: add scaling for RK3036 win1
>>>>     drm: rockchip: add missing registers for RK3188
>>>>     drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
>>>>     drm: rockchip: set alpha_en to 0 if it is not used
>>>>     drm: rockchip: use overlay windows as such
>>>>
>>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
>>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
>>>>    3 files changed, 38 insertions(+), 6 deletions(-)
>>>>
>>>> --
>>>> 2.17.1
>>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>> Best Regards
>>
>
Best regards
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Sat, Jul 25, 2020 at 8:48 PM Alex Bee <knaerzche@gmail.com> wrote:
>
>
> Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> > On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
> >>
> >> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> >>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> this series mainly ports existining functionality to older SoCs - most
> >>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> >>>> RK3188.
> >>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> >>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> >>> This doesn't make much sense, the cursor overlay is really just a hint
> >>> for legacy ioctls that this is the overlay that should be used for
> >>> cursors. Compositors should try to use such planes as full overlays
> >>> (if they don't want to use them as a cursor). So sounds like a case of
> >>> "fix your compositor".
> >> I agree here - but: If HWC windows would have been implemented in this
> >> particular driver, their max size would be 128x128 on some SoCs - so
> >> they woudn't be really suitable to create an OSD overlay at 4K, for
> >> example. I don't know, but I guess other vendors implement their HWC
> >> windows on this reduced HW resources as well. I guess that is one of the
> >> reasons, why userspace, which aims to be cross-plattfrom, avoids
> >> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
> >> heuristic, indeed)
> > Which userspace does that?
> kodi-gbm:
> https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406

Can you pls file a bug report, linking to this thread here?

Maybe also link to the docs:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=drm_plane#c.drm_plane_type

"For userspace which is universal plane aware and which is using that
atomic IOCTL there’s no difference between these planes (beyong what
the driver and hardware can support of course)."

Also feel free to cc me on the github issue (I'm @danvet over there)
in case there's more questions.

Cheers, Daniel

>
> > We should fix that, not try to work around
> > that in all the drivers in upstream, that wont work.
> You're right I'll drop this part.
> > -Daniel
> >
> >>> For atomic there's 0 difference between a overlay or a cursor (primary
> >>> plane is still treated somewhat special in the RMFB ioctl, but again
> >>> that's for backwards compat reasons with existing uapi, not because
> >>> the primary plane is different).
> >>>
> >>> What does happen though is that this breaks cursor for legacy
> >>> userspace, which is probably not really what you want.
> >> Indeed not.
> >>
> >> Beforhand I was submiiting this, I looked arround and couldn't find
> >> anything which relies or even depends of a cursor window to be
> >> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
> >> mandatory, everything else is optional.
> >>
> >>> -Daniel
> >>>
> >>>
> >>>> Regards,
> >>>> Alex
> >>>>
> >>>> Changes in v2:
> >>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> >>>> - rephrase most commit messages
> >>>>
> >>>> Alex Bee (5):
> >>>>     drm: rockchip: add scaling for RK3036 win1
> >>>>     drm: rockchip: add missing registers for RK3188
> >>>>     drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
> >>>>     drm: rockchip: set alpha_en to 0 if it is not used
> >>>>     drm: rockchip: use overlay windows as such
> >>>>
> >>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
> >>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
> >>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> >>>>    3 files changed, 38 insertions(+), 6 deletions(-)
> >>>>
> >>>> --
> >>>> 2.17.1
> >>>>
> >>> --
> >>> Daniel Vetter
> >>> Software Engineer, Intel Corporation
> >>> http://blog.ffwll.ch
> >> Best Regards
> >>
> >
> Best regards



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Sat, Jul 25, 2020 at 8:48 PM Alex Bee <knaerzche@gmail.com> wrote:
>
>
> Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> > On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
> >>
> >> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> >>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> this series mainly ports existining functionality to older SoCs - most
> >>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> >>>> RK3188.
> >>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> >>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> >>> This doesn't make much sense, the cursor overlay is really just a hint
> >>> for legacy ioctls that this is the overlay that should be used for
> >>> cursors. Compositors should try to use such planes as full overlays
> >>> (if they don't want to use them as a cursor). So sounds like a case of
> >>> "fix your compositor".
> >> I agree here - but: If HWC windows would have been implemented in this
> >> particular driver, their max size would be 128x128 on some SoCs - so
> >> they woudn't be really suitable to create an OSD overlay at 4K, for
> >> example. I don't know, but I guess other vendors implement their HWC
> >> windows on this reduced HW resources as well. I guess that is one of the
> >> reasons, why userspace, which aims to be cross-plattfrom, avoids
> >> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
> >> heuristic, indeed)
> > Which userspace does that?
> kodi-gbm:
> https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406

Can you pls file a bug report, linking to this thread here?

Maybe also link to the docs:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=drm_plane#c.drm_plane_type

"For userspace which is universal plane aware and which is using that
atomic IOCTL there’s no difference between these planes (beyong what
the driver and hardware can support of course)."

Also feel free to cc me on the github issue (I'm @danvet over there)
in case there's more questions.

Cheers, Daniel

>
> > We should fix that, not try to work around
> > that in all the drivers in upstream, that wont work.
> You're right I'll drop this part.
> > -Daniel
> >
> >>> For atomic there's 0 difference between a overlay or a cursor (primary
> >>> plane is still treated somewhat special in the RMFB ioctl, but again
> >>> that's for backwards compat reasons with existing uapi, not because
> >>> the primary plane is different).
> >>>
> >>> What does happen though is that this breaks cursor for legacy
> >>> userspace, which is probably not really what you want.
> >> Indeed not.
> >>
> >> Beforhand I was submiiting this, I looked arround and couldn't find
> >> anything which relies or even depends of a cursor window to be
> >> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
> >> mandatory, everything else is optional.
> >>
> >>> -Daniel
> >>>
> >>>
> >>>> Regards,
> >>>> Alex
> >>>>
> >>>> Changes in v2:
> >>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> >>>> - rephrase most commit messages
> >>>>
> >>>> Alex Bee (5):
> >>>>     drm: rockchip: add scaling for RK3036 win1
> >>>>     drm: rockchip: add missing registers for RK3188
> >>>>     drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
> >>>>     drm: rockchip: set alpha_en to 0 if it is not used
> >>>>     drm: rockchip: use overlay windows as such
> >>>>
> >>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
> >>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
> >>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> >>>>    3 files changed, 38 insertions(+), 6 deletions(-)
> >>>>
> >>>> --
> >>>> 2.17.1
> >>>>
> >>> --
> >>> Daniel Vetter
> >>> Software Engineer, Intel Corporation
> >>> http://blog.ffwll.ch
> >> Best Regards
> >>
> >
> Best regards



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs

[Daniel Vetter]

On Sat, Jul 25, 2020 at 8:48 PM Alex Bee <knaerzche@gmail.com> wrote:
>
>
> Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> > On Sat, Jul 25, 2020 at 3:52 PM Alex Bee <knaerzche@gmail.com> wrote:
> >>
> >> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> >>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee <knaerzche@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> this series mainly ports existining functionality to older SoCs - most
> >>>> importantly enables alpha blending for RK3036, RK3066, RK3126 and
> >>>> RK3188.
> >>>> Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
> >>>> to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window.
> >>> This doesn't make much sense, the cursor overlay is really just a hint
> >>> for legacy ioctls that this is the overlay that should be used for
> >>> cursors. Compositors should try to use such planes as full overlays
> >>> (if they don't want to use them as a cursor). So sounds like a case of
> >>> "fix your compositor".
> >> I agree here - but: If HWC windows would have been implemented in this
> >> particular driver, their max size would be 128x128 on some SoCs - so
> >> they woudn't be really suitable to create an OSD overlay at 4K, for
> >> example. I don't know, but I guess other vendors implement their HWC
> >> windows on this reduced HW resources as well. I guess that is one of the
> >> reasons, why userspace, which aims to be cross-plattfrom, avoids
> >> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a
> >> heuristic, indeed)
> > Which userspace does that?
> kodi-gbm:
> https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406

Can you pls file a bug report, linking to this thread here?

Maybe also link to the docs:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=drm_plane#c.drm_plane_type

"For userspace which is universal plane aware and which is using that
atomic IOCTL there’s no difference between these planes (beyong what
the driver and hardware can support of course)."

Also feel free to cc me on the github issue (I'm @danvet over there)
in case there's more questions.

Cheers, Daniel

>
> > We should fix that, not try to work around
> > that in all the drivers in upstream, that wont work.
> You're right I'll drop this part.
> > -Daniel
> >
> >>> For atomic there's 0 difference between a overlay or a cursor (primary
> >>> plane is still treated somewhat special in the RMFB ioctl, but again
> >>> that's for backwards compat reasons with existing uapi, not because
> >>> the primary plane is different).
> >>>
> >>> What does happen though is that this breaks cursor for legacy
> >>> userspace, which is probably not really what you want.
> >> Indeed not.
> >>
> >> Beforhand I was submiiting this, I looked arround and couldn't find
> >> anything which relies or even depends of a cursor window to be
> >> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is
> >> mandatory, everything else is optional.
> >>
> >>> -Daniel
> >>>
> >>>
> >>>> Regards,
> >>>> Alex
> >>>>
> >>>> Changes in v2:
> >>>> - drop not yet upstreamed dsp_data_swap from RK3188 regs
> >>>> - rephrase most commit messages
> >>>>
> >>>> Alex Bee (5):
> >>>>     drm: rockchip: add scaling for RK3036 win1
> >>>>     drm: rockchip: add missing registers for RK3188
> >>>>     drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
> >>>>     drm: rockchip: set alpha_en to 0 if it is not used
> >>>>     drm: rockchip: use overlay windows as such
> >>>>
> >>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
> >>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++++++++++++++++++---
> >>>>    drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> >>>>    3 files changed, 38 insertions(+), 6 deletions(-)
> >>>>
> >>>> --
> >>>> 2.17.1
> >>>>
> >>> --
> >>> Daniel Vetter
> >>> Software Engineer, Intel Corporation
> >>> http://blog.ffwll.ch
> >> Best Regards
> >>
> >
> Best regards



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel