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

2022-03-30 Thread piotro.oniszc...@google.com



> Wiadomość napisana przez Sascha Hauer  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 
> 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- |



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

2022-03-30 Thread piotro.oniszc...@google.com



> Wiadomość napisana przez Sascha Hauer  w dniu 
> 30.03.2022, o godz. 11:45:
> 
> On Wed, Mar 30, 2022 at 10:41:56AM +0200, [email protected] wrote:
> 
> Let me rephrase this: The above sets a plane, but it doesn't set a mode
> on the crtc. When my system boots up then the output of modetest looks
> like this:
> 
> Encoders:
> id  crtctypepossible crtcs  possible clones
> 68  0   TMDS0x0001  0x0001
> Connectors:
> id  encoder status  namesize (mm)   modes  
> encoders
> 69  0   connected   HDMI-A-1530x300 9  68
> CRTCs:
> id  fb  pos size
> 67  0   (0,0)   (0x0)
>  #0  nan 0 0 0 0 0 0 0 0 0 flags: ; type: 
> 
> No mode is set on the CRTC and the encoder/connector/crtc are not bound
> to each other, consequently the screen is in standby. "modetest -P
> 43@67:1920x1080@NV12" doesn't change this, still no mode set. Hence my
> question: How did you set a mode initially?

Ah ok. I see your point.
mode is set by app (player). 

Sequence was like this:
-boot board
-start app
-on UI select playback
-playback has green screen
-exit app
-run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
-run modetest -P 49@67:1920x1080@NV12 (works ok)
-run modetest -P 43@67:1920x1080@NV12 (now works ok)

> 
>>> 
>> 
>> 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?
> 
> I used "modetest -s 69@67:1920x1080 -d" to set a mode. The '69' is the
> connector id, not a plane.

ack.
typo from my side.

it was
modetest -P 49@67:1920x1080@NV12


> 
>> Is plane #43 working ok for you?
> 
> Yes.

So it looks your testing method of #43 is not meaningful for verifying issue we 
are discussing here.

In my case:
12 SOC (except rk356x VOP2) gives me:
-boot board
-start app
-on UI select playback
-playback is ok
-exit app
-run modetest -P XX@YY:1920x1080@NV12 (diagonal stripes)

(XX/YY are plane/connector elected by app: plane@conector with format matching 
provider format) 

rk356x with vop2 v9:
-boot board
-start app
-on UI select playback
-playback has green screen
-exit app
-run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
-run modetest -P 49@67:1920x1080@NV12 (works ok)
-run modetest -P 43@67:1920x1080@NV12 (now works ok)