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

STALE2201d

Revision v2 of 3 in this series.

11 messages, 2 authors, 2020-07-26 · open the first message on its own page

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

From: Alex Bee <hidden>
Date: 2020-07-22 18:13:48 

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 1/5] drm: rockchip: add scaling for RK3036 win1

From: Alex Bee <hidden>
Date: 2020-07-22 18:14:03 

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

Signed-off-by: Alex Bee <redacted>
---

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 2/5] drm: rockchip: add missing registers for RK3188

From: Alex Bee <hidden>
Date: 2020-07-22 18:14:22 

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

Signed-off-by: Alex Bee <redacted>
---

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 3/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188

From: Alex Bee <hidden>
Date: 2020-07-22 18:14:29 

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 <redacted>
---

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 4/5] drm: rockchip: set alpha_en to 0 if it is not used

From: Alex Bee <hidden>
Date: 2020-07-22 18:14:35 

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 <redacted>
---

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 5/5] drm: rockchip: use overlay windows as such

From: Alex Bee <hidden>
Date: 2020-07-22 18:14:39 

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 <redacted>
---

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

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

From: Daniel Vetter <hidden>
Date: 2020-07-22 21:43:18 

On Wed, Jul 22, 2020 at 8:13 PM Alex Bee [off-list ref] 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

From: Alex Bee <hidden>
Date: 2020-07-25 13:52:41 

Am 22.07.20 um 23:43 schrieb Daniel Vetter:
On Wed, Jul 22, 2020 at 8:13 PM Alex Bee [off-list ref] wrote:
quoted
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
quoted
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

From: Daniel Vetter <hidden>
Date: 2020-07-25 15:54:20 

On Sat, Jul 25, 2020 at 3:52 PM Alex Bee [off-list ref] wrote:

Am 22.07.20 um 23:43 schrieb Daniel Vetter:
quoted
On Wed, Jul 22, 2020 at 8:13 PM Alex Bee [off-list ref] wrote:
quoted
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
quoted
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.
quoted
-Daniel
quoted
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

From: Alex Bee <hidden>
Date: 2020-07-25 18:48:44 

Am 25.07.20 um 17:54 schrieb Daniel Vetter:
On Sat, Jul 25, 2020 at 3:52 PM Alex Bee [off-list ref] wrote:
quoted
Am 22.07.20 um 23:43 schrieb Daniel Vetter:
quoted
On Wed, Jul 22, 2020 at 8:13 PM Alex Bee [off-list ref] wrote:
quoted
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
quoted
quoted
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.
quoted
-Daniel
quoted
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

From: Daniel Vetter <hidden>
Date: 2020-07-26 10:55:56 

On Sat, Jul 25, 2020 at 8:48 PM Alex Bee [off-list ref] wrote:

Am 25.07.20 um 17:54 schrieb Daniel Vetter:
quoted
On Sat, Jul 25, 2020 at 3:52 PM Alex Bee [off-list ref] wrote:
quoted
Am 22.07.20 um 23:43 schrieb Daniel Vetter:
quoted
On Wed, Jul 22, 2020 at 8:13 PM Alex Bee [off-list ref] wrote:
quoted
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

quoted
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.
quoted
-Daniel

quoted
quoted
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.

quoted
-Daniel


quoted
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




    
  

  
    

      

        Keyboard shortcuts
      

      

        
          
hback out one level

          
jnext message in thread

          
kprevious message in thread

          
ldrill in

          
Escclose help / fold thread tree

          
?toggle this help