[PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

piotro.oniszczuk@google.com piotr.oniszczuk at gmail.com
Wed Mar 30 01:41:56 PDT 2022



> Wiadomość napisana przez Sascha Hauer <s.hauer at pengutronix.de> w dniu 30.03.2022, o godz. 09:28:
> 
>> 
>> You can easily reproduce with modetest utility:
>> 
>> modetest -P 43 at 67:1920x1080 at NV12
> 
> This only sets the overlay, but how did you get something on the screen
> initially?
> 

I'm not sure that above command only sets plane.
On other SoCs i’m testing it gives expected results: diagonal colored stripes.
There is single exception: rk356x with vop2 - where screen is green unless i „fix/enable” by playing with plane #69   

> I did with "modetest -s 69 at 67:1920x1080 -d" and with this it works as
> expected, I can't reproduce any green screen issue here.

I see you are using plane #69.
Why not #43?
Is plane #43 working ok for you?

I’m using plane #43 because: application (player) - at start -  queries all planes and selects first plane offering format being within offered formats by provider (video decoder; NV12 from rk356x hantro video decoder).

pls look on app log regarding planes discovery and election: https://pastebin.com/edAhbcvU

Now - looking what VOP2 reports: https://pastebin.com/8ujkaV9n
is see first plane accepting NV12 is #43 - so my app is electing this plane to use for displaying video.

This strategy works well for all 13 platforms i’m supporting (only 13 i have in my testbed).

If this approach is - by Yours VOP2 patches goal - is not supported - then OK.
I understand this :-)

But - if You want to support DRM features in the same way like other SOC are doing (and working well with KODI/MythTV/mpv/etc) - then i think:

1\ DRM plane #43 not supports NV12 - but code wrongly reports NV12 format is supported, or
2\ DRM plane #43 is supported - but code has bug resulting with green screen.

Pls let me know what you think!


> 
> I found another problem though which might or might not be related with
> your issue. I saw that the overlay is not exactly centered as it ought
> to be. This goes down to wrong delay settings for the overlay, the
> following patch fixes this.
> 
> Sascha
> 
> ---------------------------------8<-------------------------------
> 
> From f9a92401344e8aa3203fca2236dd4a40cc8690f6 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer at pengutronix.de>
> Date: Wed, 30 Mar 2022 09:22:26 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> 
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 69e9870d5f2dc..7dba7b9b63dc6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1979,10 +1979,10 @@ static void vop2_setup_dly_for_windows(struct vop2 *vop2)
> 			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__ESMART1, dly);
> 			break;
> 		case ROCKCHIP_VOP2_SMART0:
> -			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART1, dly);
> +			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART0, dly);
> 			break;
> 		case ROCKCHIP_VOP2_SMART1:
> -			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART0, dly);
> +			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART1, dly);
> 			break;
> 		}
> 	}
> -- 
> 2.30.2
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




More information about the linux-arm-kernel mailing list