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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Wiadomość napisana przez Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> w dniu 30.03.2022, o godz. 09:28:
> 
>> 
>> You can easily reproduce with modetest utility:
>> 
>> modetest -P 43@67:1920x1080@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@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@xxxxxxxxxxxxxx>
> 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 |





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux