[PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Lucas Stach
l.stach at pengutronix.de
Tue Apr 12 08:10:57 UTC 2022
Am Dienstag, dem 12.04.2022 um 09:50 +0200 schrieb Sascha Hauer:
> On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> > this is DRI state when there is no any Qt.vars overwrites.
> > (so all is autodetected/setup like in other working SoCs; VOP2 gives here black screen UI):
> >
> > 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
> > 2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
> > 2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> > 2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for video
> > 2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
> > 2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
> > 2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
> > 2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1
> >
> > plane[31]: Smart0-win0
> > crtc=video_port0
> > fb=53
> > allocated by = [fbcon]
> > refcount=2
> > format=XR24 little-endian (0x34325258)
> > modifier=0x0
> > size=1920x1080
> > layers:
> > size[0]=1920x1080
> > pitch[0]=7680
> > offset[0]=0
> > obj[0]:
> > name=0
> > refcount=3
> > start=00000000
> > size=8294400
> > imported=no
> > crtc-pos=1920x1080+0+0
> > src-pos=1920.000000x1080.000000+0.000000+0.000000
> > rotation=1
> > normalized-zpos=0
> > color-encoding=ITU-R BT.601 YCbCr
> > color-range=YCbCr limited range
> > plane[37]: Esmart0-win0
> > crtc=(null)
> > fb=0
> > crtc-pos=0x0+0+0
> > src-pos=0.000000x0.000000+0.000000+0.000000
> > rotation=1
> > normalized-zpos=0
> > color-encoding=ITU-R BT.601 YCbCr
> > color-range=YCbCr limited range
> > plane[43]: Cluster0-win0
> > crtc=video_port0
> > fb=58
> > allocated by = mythfrontend
> > refcount=2
> > format=AR24 little-endian (0x34325241)
>
> Here is your problem. The cluster windows only allow AFBC compressed
> formats. AR24 is supported by the cluster windows, but not by the GPU,
> see panfrost_afbc_format() in Mesa:
>
> > enum pipe_format
> > panfrost_afbc_format(const struct panfrost_device *dev, enum pipe_format format)
> > {
> > /* Don't allow swizzled formats on v7 */
> > switch (format) {
> > case PIPE_FORMAT_B8G8R8A8_UNORM:
> > case PIPE_FORMAT_B8G8R8X8_UNORM:
> > case PIPE_FORMAT_A8R8G8B8_UNORM:
> > case PIPE_FORMAT_X8R8G8B8_UNORM:
> > case PIPE_FORMAT_X8B8G8R8_UNORM:
> > case PIPE_FORMAT_A8B8G8R8_UNORM:
> > case PIPE_FORMAT_B8G8R8_UNORM:
> > case PIPE_FORMAT_B5G6R5_UNORM:
> > if (dev->arch >= 7)
> > return PIPE_FORMAT_NONE;
> >
> > break;
> > default:
> > break;
> > }
> >
>
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR8888 aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB8888 aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
>
This could be both a Mesa/Panfrost or application issue. The
application is supposed to try to allocate with a arbitrary chosen
format and the valid modifiers queried from the plane it wants to put
the surface on. However I'm not sure if all applications have a
fallback path in place to try another format swizzling if the surface
allocation fails. Now there are two possible failures here:
1. The application feeds a wrong modifier list to the GBM
implementation, as it may have queried another plane in the assumption
that supported modifiers are uniform across all planes.
2. The GBM implementation (Panfrost) actually allocates a surface
instead of failing the allocation, even if it does not support any
combination of the provided format and modifier list.
Regards,
Lucas
> Could you try the following patch? It removed the formats in question
> from the list of supported formats in the hope that your application
> then picks one of the supported formats.
>
> Sascha
>
> -----------------------8<-----------------------------
>
> From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer at pengutronix.de>
> Date: Tue, 12 Apr 2022 09:42:32 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
>
> The cluster windows only allow AFBC compressed formats. Not all of the
> offered formats are supported by the GPU though. Applications pick one
> of the formats and assume that this is also supported by the GPU they
> use to render on them, but this is not the case for all formats.
> Particularly DRM_FORMAT_XRGB8888 and DRM_FORMAT_ARGB8888 are not
> supported by the GPU and choosing them results in a black screen.
> Drop these formats for now.
>
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> ---
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 9bf0637bf8e26..38412766e3659 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -16,8 +16,6 @@
> #include "rockchip_drm_vop2.h"
>
> static const uint32_t formats_win_full_10bit[] = {
> - DRM_FORMAT_XRGB8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XBGR8888,
> DRM_FORMAT_ABGR8888,
> DRM_FORMAT_RGB888,
> --
> 2.30.2
>
>
More information about the dri-devel
mailing list