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(-)
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,
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[] = {
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
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);
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 = {
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
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
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
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#L40...
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
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#L40...
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....
"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
dri-devel@lists.freedesktop.org
-
Alex Bee -
Daniel Vetter