| Message ID | 20220328151116.2034635-1-s.hauer@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/rockchip: RK356x VOP2 support | expand |
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 28.03.2022, o godz. 17:10: > > > Changes since v8: > - make hclk_vo a critical clock instead of enabling it in the hdmi driver > - Fix vop2_setup_layer_mixer(), reported by Andy Yan > - Limit planes possible_crtcs to actually existing crtcs > > Sascha, FYI: I was hoping v9 will fix green screen issue i see when video player wants to draw to nv12 capable drm plane. It look issue is still present :-( You can easily reproduce with modetest utility: modetest -P 43@67:1920x1080@NV12 gives green screen. however if you do: modetest #43 (green screen) modetest #49 (ok) then modetest #43 gives expected result ("rainbow" picture on screen) let me know if i can do any extra tests helping you to fix issue br
Hi Piotr, On Tue, Mar 29, 2022 at 09:31:01AM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 28.03.2022, o godz. 17:10: > > > > > > Changes since v8: > > - make hclk_vo a critical clock instead of enabling it in the hdmi driver > > - Fix vop2_setup_layer_mixer(), reported by Andy Yan > > - Limit planes possible_crtcs to actually existing crtcs > > > > > > Sascha, > > FYI: > I was hoping v9 will fix green screen issue i see when video player wants to draw to nv12 capable drm plane. > It look issue is still present :-( > > 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 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 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@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; } }
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> 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@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 |
On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> 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? 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 crtc type possible crtcs possible clones 68 0 TMDS 0x00000001 0x00000001 Connectors: id encoder status name size (mm) modes encoders 69 0 connected HDMI-A-1 530x300 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? > > > > 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. > Is plane #43 working ok for you? Yes. > > 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. plane #43 should support NV12 and it seems to work fine here. I believe you that there's a problem, but I can't reproduce it here and I might need further assistence to reproduce it. Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 11:45: > > On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com 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 crtc type possible crtcs possible clones > 68 0 TMDS 0x00000001 0x00000001 > Connectors: > id encoder status name size (mm) modes encoders > 69 0 connected HDMI-A-1 530x300 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)
On Wed, Mar 30, 2022 at 12:01:05PM +0200, piotro.oniszczuk@google.com wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 11:45: > > > > On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com 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 crtc type possible crtcs possible clones > > 68 0 TMDS 0x00000001 0x00000001 > > Connectors: > > id encoder status name size (mm) modes encoders > > 69 0 connected HDMI-A-1 530x300 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) Does it change anything if you do a "modetest -s 69@67:1920x1080" before starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12" before starting the app? Or other combinations thereof? Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20: > > Does it change anything if you do a "modetest -s 69@67:1920x1080" before > starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12" > before starting the app? Or other combinations thereof? So i tried following combinations 1. -boot -start app -stop app -modetest -s 69@67:1920x1080 -> ok -modetest -P 43@67:1920x1080@NV12 -> green screen 2. -boot -modetest -s 69@67:1920x1080 -> ok -modetest -P 43@67:1920x1080@NV12 -> green screen 3. -boot -modetest -s 69@67:1920x1080 -> ok -start app -playback in app -> green screen -stop app -modetest -P 43@67:1920x1080@NV12 -> green screen 4. -boot -modetest -s 69@67:1920x1080 -> ok -start app -playback in app -> green screen -stop app -modetest -s 69@67:1920x1080 -> ok -modetest -P 43@67:1920x1080@NV12 -> green screen br
On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20: > > > > Does it change anything if you do a "modetest -s 69@67:1920x1080" before > > starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12" > > before starting the app? Or other combinations thereof? > > So i tried following combinations > > -boot > -modetest -s 69@67:1920x1080 -> ok > -modetest -P 43@67:1920x1080@NV12 -> green screen I have no idea what is going on here. There same commands work for me. You could provide me your kernel config and upstream commitish you are working on, maybe that gets me closer to your setup. Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 21:20: > >> So i tried following combinations >> >> -boot >> -modetest -s 69@67:1920x1080 -> ok >> -modetest -P 43@67:1920x1080@NV12 -> green screen > > I have no idea what is going on here. There same commands work for me. > You could provide me your kernel config and upstream commitish you are > working on, maybe that gets me closer to your setup. Sascha May you try with my kernel config? https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.17/files/linux-5.17-arm64-armv8.config If this config will work for you then: i'll try to build vanilla 5.17 + minimal possible set of patches allowing me to get video decoder working on rk3566. This may help us to find why: -you have it working -I have it not working
On Wed, Mar 30, 2022 at 09:35:17PM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 21:20: > > > >> So i tried following combinations > >> > >> -boot > >> -modetest -s 69@67:1920x1080 -> ok > >> -modetest -P 43@67:1920x1080@NV12 -> green screen > > > > I have no idea what is going on here. There same commands work for me. > > You could provide me your kernel config and upstream commitish you are > > working on, maybe that gets me closer to your setup. > > Sascha > > May you try with my kernel config? > https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.17/files/linux-5.17-arm64-armv8.config This works for me as well. > > If this config will work for you then: > > i'll try to build vanilla 5.17 + minimal possible set of patches allowing me to get video decoder working on rk3566. You shouldn't need a video decoder for this test. For your convenience I pushed the branch I just tested to: git://git.pengutronix.de/sha/linux rockchip-vop2-v9 Sascha
Hi Piotr: On 3/31/22 03:20, Sascha Hauer wrote: > On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote: >> >>> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20: >>> >>> Does it change anything if you do a "modetest -s 69@67:1920x1080" before >>> starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12" >>> before starting the app? Or other combinations thereof? >> So i tried following combinations >> >> -boot >> -modetest -s 69@67:1920x1080 -> ok >> -modetest -P 43@67:1920x1080@NV12 -> green screen > I have no idea what is going on here. There same commands work for me. > You could provide me your kernel config and upstream commitish you are > working on, maybe that gets me closer to your setup. It's a little strange, I can't reproduce this issue neither. But I have problem with this two step command sequence. step 1: modetest -s 69@67:1920x1080 -> ok step 2: modetest -P 43@67:1920x1080@NV12, I got the failed message: "failed to enable plane: Permission denied" Because the drm core will stop step2 by drm_ioctrl_permit as DRM_IOCTL_SETPLANE need a master, but the current master is the modetest run by step1. static int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) { /* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) { printk("DRM_ROOT_ONLY\n"); return -EACCES; } /* AUTH is only for authenticated or render client */ if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && !file_priv->authenticated)) { printk("DRM_AUTH\n"); return -EACCES; } /* MASTER is only for master or control clients */ if (unlikely((flags & DRM_MASTER) && !drm_is_current_master(file_priv))) { printk("DRM_MASTER\n"); return -EACCES; } /* Render clients must be explicitly allowed */ if (unlikely(!(flags & DRM_RENDER_ALLOW) && drm_is_render_client(file_priv))) { printk("DRM_RENDER_NOT_ALLOW\n"); return -EACCES; } return 0; } After bypass the permission check, I can run step 2 , but the display on the screen will have a shift as the wrong dly configuration. So how you two got step two run success? Piotr: What soc is on you board? rk3566 or rk3568? I have a scripts[0] use io[1] command to dump the VOP2 register you can use it dump the register configuration when you meet a display failure, then send the dump to me, maybe I can figure out something. [0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh [1] https://github.com/andyshrk/io > > Sascha >
On Thu, Mar 31, 2022 at 08:13:09PM +0800, Andy Yan wrote: > Hi Piotr: > > On 3/31/22 03:20, Sascha Hauer wrote: > > On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote: > > > > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20: > > > > > > > > Does it change anything if you do a "modetest -s 69@67:1920x1080" before > > > > starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12" > > > > before starting the app? Or other combinations thereof? > > > So i tried following combinations > > > > > > -boot > > > -modetest -s 69@67:1920x1080 -> ok > > > -modetest -P 43@67:1920x1080@NV12 -> green screen > > I have no idea what is going on here. There same commands work for me. > > You could provide me your kernel config and upstream commitish you are > > working on, maybe that gets me closer to your setup. > > > It's a little strange, I can't reproduce this issue neither. > > But I have problem with this two step command sequence. > > step 1: modetest -s 69@67:1920x1080 -> ok > > step 2: modetest -P 43@67:1920x1080@NV12, > > I got the failed message: "failed to enable plane: Permission denied" > > Because the drm core will stop step2 by drm_ioctrl_permit as > DRM_IOCTL_SETPLANE need a master, > > but the current master is the modetest run by step1. > [...] > > So how you two got step two run success? You have to stop the first modetest by hitting return. Alternatively you could pass the -d option to the first modetest. Sascha
> Wiadomość napisana przez Andy Yan <andy.yan@rock-chips.com> w dniu 31.03.2022, o godz. 14:13: > > > Piotr: > > What soc is on you board? rk3566 or rk3568? it is rk3566 in x96-x6 tvbox > > I have a scripts[0] use io[1] command to dump the VOP2 register you can use it dump the register configuration when you meet a display failure, > > then send the dump to me, maybe I can figure out something. > > [0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh > > [1] https://github.com/andyshrk/io Andy Pls see https://pastebin.com/CHmu9s22 I put dumps for following scenarios: 1. -boot -modetest -s 69@67:1920x1080 -> ok -modetest -P 43@67:1920x1080@NV12 -> green screen 2. -boot -modetest -s 69@67:1920x1080 -> ok -modetest -P 49@67:1920x1080@NV12 -> ok (but shifted horizontally by about 5% of screen width) (setting palne#49 fixes plane #43. Here i set plane #49 but not yet setting #43) 3. -boot -modetest -s 69@67:1920x1080 -> ok -modetest -P 49@67:1920x1080@NV12 -> ok (but shifted horizontally by about 5% of screen width) -modetest -P 43@67:1920x1080@NV12 -> now ok (but shifted horizontally by about 5% of screen width)
On Thu, Mar 31, 2022 at 04:53:05PM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Andy Yan <andy.yan@rock-chips.com> w dniu 31.03.2022, o godz. 14:13: > > > > > > Piotr: > > > > What soc is on you board? rk3566 or rk3568? > > it is rk3566 in x96-x6 tvbox > > > > > > I have a scripts[0] use io[1] command to dump the VOP2 register you can use it dump the register configuration when you meet a display failure, > > > > then send the dump to me, maybe I can figure out something. > > > > [0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh > > > > [1] https://github.com/andyshrk/io > > Andy > > Pls see https://pastebin.com/CHmu9s22 > > I put dumps for following scenarios: > > 1. > -boot > -modetest -s 69@67:1920x1080 -> ok > -modetest -P 43@67:1920x1080@NV12 -> green screen > > > 2. > -boot > -modetest -s 69@67:1920x1080 -> ok > -modetest -P 49@67:1920x1080@NV12 -> ok (but shifted horizontally by about 5% of screen width) Have you applied the bugfix I shared with you here: https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/ Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 31.03.2022, o godz. 17:00: > > > Have you applied the bugfix I shared with you here: > > https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/ > oooops noooooo didn't noticed :-( let me try with it!
> Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 31.03.2022, o godz. 17:06: > > > >> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 31.03.2022, o godz. 17:00: >> >> >> Have you applied the bugfix I shared with you here: >> >> https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/ >> > > oooops > > noooooo > didn't noticed :-( > > let me try with it! > ok - i tried. unfortunately no any difference :-(
On Fri, Apr 01, 2022 at 09:52:01AM +0800, Andy Yan wrote: > Hi Piotr: > > On 3/31/22 22:53, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Andy Yan [1]<andy.yan@rock-chips.com> w dniu 31.03.2022, o godz. 14:13: > > > Piotr: > > What soc is on you board? rk3566 or rk3568? > > it is rk3566 in x96-x6 tvbox > > RK3566? Maybe that is the problem. Likely, yes. > > plane[43]: Esmart1-win0 > crtc=(null) > fb=0 > crtc-pos=0x0+0+0 > src-pos=0.000000x0.000000+0.000000+0.000000 > rotation=1 > normalized-zpos=1 > color-encoding=ITU-R BT.601 YCbCr > color-range=YCbCr limited range > > From your dri/state dump, Plane 43 is Esmart1. > > Cluster1, Esmart1, Smart1 are special on rk3566, they are > > mirror window of Cluster0, Esmart0, Esmart0. That means > > the software can't program a independent framebuffer for > > these three windows. They can only share the fb address set > > in Cluster0, Esmart0, Smart0. Downstream Kernel has this: static bool vop2_is_mirror_win(struct vop2_win *win) { return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR); } static int vop2_create_crtc(struct vop2 *vop2) { ... for (j = 0; j < vop2->registered_num_wins; j++) { win = &vop2->win[j]; if (win->type != DRM_PLANE_TYPE_OVERLAY) continue; /* * Only dual display on rk3568(which need two crtcs) need mirror win */ if (registered_num_crtcs < 2 && vop2_is_mirror_win(win)) continue; ... ret = vop2_plane_init(vop2, win, possible_crtcs); } ... } "Smart1-win0" and "Esmart1-win0" have this WIN_FEATURE_MIRROR bit set. It seems we just should just don't register these windows for rk3566. Sascha
Hi Piotr, On Tue, Mar 29, 2022 at 09:31:01AM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 28.03.2022, o godz. 17:10: > > > > > > Changes since v8: > > - make hclk_vo a critical clock instead of enabling it in the hdmi driver > > - Fix vop2_setup_layer_mixer(), reported by Andy Yan > > - Limit planes possible_crtcs to actually existing crtcs > > > > > > Sascha, > > FYI: > I was hoping v9 will fix green screen issue i see when video player wants to draw to nv12 capable drm plane. > It look issue is still present :-( Based on the discussion with Andy please try the following patch, it should fix your green screen issue. Note that with this patch the CRTC and plane ids will change, so the modetest commands need to be adjusted accordingly. Sascha -------------------------8<---------------------------
> Wiadomość napisana przez Andy Yan <andy.yan@rock-chips.com> w dniu 01.04.2022, o godz. 14:04: > > Hi Piotr: > > On 4/1/22 09:52, Andy Yan wrote: > > Pls update the new vop2_dump.sh scripts from github. The > > previous scripts I gave you has some bug. sorry. > Andy, Sure. np. Pls find dump with current vop2_dump.sh https://pastebin.com/CwVj0kuX btw: this is with latest patch from Sascha: https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 01.04.2022, o godz. 14:52: > > Based on the discussion with Andy please try the following patch, it > should fix your green screen issue. Note that with this patch the > CRTC and plane ids will change, so the modetest commands need to be > adjusted accordingly. > > Sascha > > -------------------------8<--------------------------- > > -- > From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 > From: Sascha Hauer <s.hauer@pengutronix.de> > Date: Fri, 1 Apr 2022 14:48:49 +0200 > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver > > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > index 7dba7b9b63dc6..1421bf2f133f1 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) > } > } > > + if (vop2->data->soc_id == 3566) { > + /* > + * On RK3566 these windows don't have an independent > + * framebuffer. They share the framebuffer with smart0, > + * esmart0 and cluster0 respectively. > + */ > + switch (win->data->phys_id) { > + case ROCKCHIP_VOP2_SMART1: > + case ROCKCHIP_VOP2_ESMART1: > + case ROCKCHIP_VOP2_CLUSTER1: > + continue; > + } > + } > + > if (win->type == DRM_PLANE_TYPE_OVERLAY) > possible_crtcs = (1 << nvps) - 1; > > -- > 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 | Sascha Now works perfectly! (hd playback with 3.5...5.5% cpu while rendering to drm plane) Fantastic work of You!
Hi Sacha: On 4/1/22 20:52, Sascha Hauer wrote: > -- > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 > From: Sascha Hauer<s.hauer@pengutronix.de> > Date: Fri, 1 Apr 2022 14:48:49 +0200 > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver > > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > index 7dba7b9b63dc6..1421bf2f133f1 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) > } > } > > + if (vop2->data->soc_id == 3566) { > + /* > + * On RK3566 these windows don't have an independent > + * framebuffer. They share the framebuffer with smart0, > + * esmart0 and cluster0 respectively. > + */ > + switch (win->data->phys_id) { > + case ROCKCHIP_VOP2_SMART1: > + case ROCKCHIP_VOP2_ESMART1: > + case ROCKCHIP_VOP2_CLUSTER1: > + continue; > + } Think about this , there maybe other upcoming vop2 base soc, they may only have mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1. I think this should add WIN_FEATURE at the platform description file rockchip_vop2_reg.c, then check the FEATURE to decide whether the driver should give this window a special treatment. this can make one code run for different soc with different platform description. or we should add the same code logic for different soc again and again. > + } > + > if (win->type == DRM_PLANE_TYPE_OVERLAY) > possible_crtcs = (1 << nvps) - 1; >
On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote: > Hi Sacha: > > On 4/1/22 20:52, Sascha Hauer wrote: > > -- > > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 > > From: Sascha Hauer<s.hauer@pengutronix.de> > > Date: Fri, 1 Apr 2022 14:48:49 +0200 > > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver > > > > --- > > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > index 7dba7b9b63dc6..1421bf2f133f1 100644 > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) > > } > > } > > + if (vop2->data->soc_id == 3566) { > > + /* > > + * On RK3566 these windows don't have an independent > > + * framebuffer. They share the framebuffer with smart0, > > + * esmart0 and cluster0 respectively. > > + */ > > + switch (win->data->phys_id) { > > + case ROCKCHIP_VOP2_SMART1: > > + case ROCKCHIP_VOP2_ESMART1: > > + case ROCKCHIP_VOP2_CLUSTER1: > > + continue; > > + } > > > Think about this , there maybe other upcoming vop2 base soc, they may only > have > > mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1. > > I think this should add WIN_FEATURE at the platform description file > rockchip_vop2_reg.c, then > > check the FEATURE to decide whether the driver should give this window a > special treatment. > > this can make one code run for different soc with different platform > description. or we should add > > the same code logic for different soc again and again. You mean like done in the downstream Kernel? Here indeed we have a WIN_FEATURE_MIRROR flag added to the platform description. This is then evaluated with: static bool vop2_is_mirror_win(struct vop2_win *win) { return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR); } So a flag is added and afterwards its evaluation is SoC specific. That doesn't help at all and only obfuscates things. Besides, experience shows that you can't predict a good abstraction for future hardware revisions, the hardware guys are just too creative in creating hardware that breaks existing abstractions. Sascha
Hi: On 4/5/22 17:37, Sascha Hauer wrote: > On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote: >> Hi Sacha: >> >> On 4/1/22 20:52, Sascha Hauer wrote: >>> -- >>> >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 >>> From: Sascha Hauer<s.hauer@pengutronix.de> >>> Date: Fri, 1 Apr 2022 14:48:49 +0200 >>> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver >>> >>> --- >>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ >>> 1 file changed, 14 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >>> index 7dba7b9b63dc6..1421bf2f133f1 100644 >>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >>> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) >>> } >>> } >>> + if (vop2->data->soc_id == 3566) { >>> + /* >>> + * On RK3566 these windows don't have an independent >>> + * framebuffer. They share the framebuffer with smart0, >>> + * esmart0 and cluster0 respectively. >>> + */ >>> + switch (win->data->phys_id) { >>> + case ROCKCHIP_VOP2_SMART1: >>> + case ROCKCHIP_VOP2_ESMART1: >>> + case ROCKCHIP_VOP2_CLUSTER1: >>> + continue; >>> + } >> >> Think about this , there maybe other upcoming vop2 base soc, they may only >> have >> >> mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1. >> >> I think this should add WIN_FEATURE at the platform description file >> rockchip_vop2_reg.c, then >> >> check the FEATURE to decide whether the driver should give this window a >> special treatment. >> >> this can make one code run for different soc with different platform >> description. or we should add >> >> the same code logic for different soc again and again. > You mean like done in the downstream Kernel? Here indeed we have a > WIN_FEATURE_MIRROR flag added to the platform description. This is then > evaluated with: > > static bool vop2_is_mirror_win(struct vop2_win *win) > { > return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR); > } > > So a flag is added and afterwards its evaluation is SoC specific. That > doesn't help at all and only obfuscates things. > > Besides, experience shows that you can't predict a good abstraction for This is not a predict, this is an IP feature, so it will appeared on upcoming SOC. We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and also have a entry level soc which only have 4 windows, they both have this feature. > future hardware revisions, the hardware guys are just too creative in > creating hardware that breaks existing abstractions. > > Sascha >
On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote: > Hi: > > On 4/5/22 17:37, Sascha Hauer wrote: > > On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote: > > > Hi Sacha: > > > > > > On 4/1/22 20:52, Sascha Hauer wrote: > > > > -- > > > > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 > > > > From: Sascha Hauer<s.hauer@pengutronix.de> > > > > Date: Fri, 1 Apr 2022 14:48:49 +0200 > > > > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver > > > > > > > > --- > > > > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ > > > > 1 file changed, 14 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > > > index 7dba7b9b63dc6..1421bf2f133f1 100644 > > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > > > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) > > > > } > > > > } > > > > + if (vop2->data->soc_id == 3566) { > > > > + /* > > > > + * On RK3566 these windows don't have an independent > > > > + * framebuffer. They share the framebuffer with smart0, > > > > + * esmart0 and cluster0 respectively. > > > > + */ > > > > + switch (win->data->phys_id) { > > > > + case ROCKCHIP_VOP2_SMART1: > > > > + case ROCKCHIP_VOP2_ESMART1: > > > > + case ROCKCHIP_VOP2_CLUSTER1: > > > > + continue; > > > > + } > > > > > > Think about this , there maybe other upcoming vop2 base soc, they may only > > > have > > > > > > mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1. > > > > > > I think this should add WIN_FEATURE at the platform description file > > > rockchip_vop2_reg.c, then > > > > > > check the FEATURE to decide whether the driver should give this window a > > > special treatment. > > > > > > this can make one code run for different soc with different platform > > > description. or we should add > > > > > > the same code logic for different soc again and again. > > You mean like done in the downstream Kernel? Here indeed we have a > > WIN_FEATURE_MIRROR flag added to the platform description. This is then > > evaluated with: > > > > static bool vop2_is_mirror_win(struct vop2_win *win) > > { > > return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR); > > } > > > > So a flag is added and afterwards its evaluation is SoC specific. That > > doesn't help at all and only obfuscates things. > > > > Besides, experience shows that you can't predict a good abstraction for > > This is not a predict, this is an IP feature, so it will appeared on > upcoming SOC. > > We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and > > also have a entry level soc which only have 4 windows, they both have this > feature. Same as with the other discussion: Please let's solve this once we are there. For now my addition is the easiest way out. Once other SoCs shall be supported we can re-evaluate that and find better suitable ways for SoC abstractions. This may result in just your suggestion (in which case you can say told-you-so) or completely different. Sascha
Hi: On 4/6/22 16:13, Sascha Hauer wrote: > On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote: >> Hi: >> >> On 4/5/22 17:37, Sascha Hauer wrote: >>> On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote: >>>> Hi Sacha: >>>> >>>> On 4/1/22 20:52, Sascha Hauer wrote: >>>>> -- >>>>> >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 >>>>> From: Sascha Hauer<s.hauer@pengutronix.de> >>>>> Date: Fri, 1 Apr 2022 14:48:49 +0200 >>>>> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver >>>>> >>>>> --- >>>>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ >>>>> 1 file changed, 14 insertions(+) >>>>> >>>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >>>>> index 7dba7b9b63dc6..1421bf2f133f1 100644 >>>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >>>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >>>>> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) >>>>> } >>>>> } >>>>> + if (vop2->data->soc_id == 3566) { >>>>> + /* >>>>> + * On RK3566 these windows don't have an independent >>>>> + * framebuffer. They share the framebuffer with smart0, >>>>> + * esmart0 and cluster0 respectively. >>>>> + */ >>>>> + switch (win->data->phys_id) { >>>>> + case ROCKCHIP_VOP2_SMART1: >>>>> + case ROCKCHIP_VOP2_ESMART1: >>>>> + case ROCKCHIP_VOP2_CLUSTER1: >>>>> + continue; >>>>> + } >>>> Think about this , there maybe other upcoming vop2 base soc, they may only >>>> have >>>> >>>> mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1. >>>> >>>> I think this should add WIN_FEATURE at the platform description file >>>> rockchip_vop2_reg.c, then >>>> >>>> check the FEATURE to decide whether the driver should give this window a >>>> special treatment. >>>> >>>> this can make one code run for different soc with different platform >>>> description. or we should add >>>> >>>> the same code logic for different soc again and again. >>> You mean like done in the downstream Kernel? Here indeed we have a >>> WIN_FEATURE_MIRROR flag added to the platform description. This is then >>> evaluated with: >>> >>> static bool vop2_is_mirror_win(struct vop2_win *win) >>> { >>> return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR); >>> } >>> >>> So a flag is added and afterwards its evaluation is SoC specific. That >>> doesn't help at all and only obfuscates things. >>> >>> Besides, experience shows that you can't predict a good abstraction for >> This is not a predict, this is an IP feature, so it will appeared on >> upcoming SOC. >> >> We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and >> >> also have a entry level soc which only have 4 windows, they both have this >> feature. > Same as with the other discussion: Please let's solve this once we are > there. I am not sure if this is the suitable way for upstream, this sound like just solve the issue appeared at the front of eyes and not think any thing about make this driver easy to support new hardware in the future. > For now my addition is the easiest way out. Once other SoCs shall be > supported we can re-evaluate that and find better suitable ways for SoC > abstractions. This may result in just your suggestion (in which case you > can say told-you-so) or completely different. > > Sascha >
> Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05: > > > >> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 01.04.2022, o godz. 14:52: >> >> Based on the discussion with Andy please try the following patch, it >> should fix your green screen issue. Note that with this patch the >> CRTC and plane ids will change, so the modetest commands need to be >> adjusted accordingly. >> >> Sascha >> >> -------------------------8<--------------------------- >> >> -- >> From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 >> From: Sascha Hauer <s.hauer@pengutronix.de> >> Date: Fri, 1 Apr 2022 14:48:49 +0200 >> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver >> >> --- >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >> index 7dba7b9b63dc6..1421bf2f133f1 100644 >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c >> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) >> } >> } >> >> + if (vop2->data->soc_id == 3566) { >> + /* >> + * On RK3566 these windows don't have an independent >> + * framebuffer. They share the framebuffer with smart0, >> + * esmart0 and cluster0 respectively. >> + */ >> + switch (win->data->phys_id) { >> + case ROCKCHIP_VOP2_SMART1: >> + case ROCKCHIP_VOP2_ESMART1: >> + case ROCKCHIP_VOP2_CLUSTER1: >> + continue; >> + } >> + } >> + >> if (win->type == DRM_PLANE_TYPE_OVERLAY) >> possible_crtcs = (1 << nvps) - 1; >> >> -- >> 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 | > > Sascha > > Now works perfectly! > (hd playback with 3.5...5.5% cpu while rendering to drm plane) > > Fantastic work of You! Sascha, Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. context: player draws video on plane #X and osd on overlay plane #Y When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.) This works well on all platforms i have - except rk3566 For me it looks like z-order vop2 issue or alpha blending issue. As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho. what you think?
On Wed, Apr 06, 2022 at 04:36:42PM +0800, Andy Yan wrote: > Hi: > > On 4/6/22 16:13, Sascha Hauer wrote: > > On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote: > > > Hi: > > > > > > On 4/5/22 17:37, Sascha Hauer wrote: > > > > On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote: > > > > > Hi Sacha: > > > > > > > > > > On 4/1/22 20:52, Sascha Hauer wrote: > > > > > > -- > > > > > > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 > > > > > > From: Sascha Hauer<s.hauer@pengutronix.de> > > > > > > Date: Fri, 1 Apr 2022 14:48:49 +0200 > > > > > > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver > > > > > > > > > > > > --- > > > > > > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ > > > > > > 1 file changed, 14 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > > > > > index 7dba7b9b63dc6..1421bf2f133f1 100644 > > > > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > > > > > > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) > > > > > > } > > > > > > } > > > > > > + if (vop2->data->soc_id == 3566) { > > > > > > + /* > > > > > > + * On RK3566 these windows don't have an independent > > > > > > + * framebuffer. They share the framebuffer with smart0, > > > > > > + * esmart0 and cluster0 respectively. > > > > > > + */ > > > > > > + switch (win->data->phys_id) { > > > > > > + case ROCKCHIP_VOP2_SMART1: > > > > > > + case ROCKCHIP_VOP2_ESMART1: > > > > > > + case ROCKCHIP_VOP2_CLUSTER1: > > > > > > + continue; > > > > > > + } > > > > > Think about this , there maybe other upcoming vop2 base soc, they may only > > > > > have > > > > > > > > > > mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1. > > > > > > > > > > I think this should add WIN_FEATURE at the platform description file > > > > > rockchip_vop2_reg.c, then > > > > > > > > > > check the FEATURE to decide whether the driver should give this window a > > > > > special treatment. > > > > > > > > > > this can make one code run for different soc with different platform > > > > > description. or we should add > > > > > > > > > > the same code logic for different soc again and again. > > > > You mean like done in the downstream Kernel? Here indeed we have a > > > > WIN_FEATURE_MIRROR flag added to the platform description. This is then > > > > evaluated with: > > > > > > > > static bool vop2_is_mirror_win(struct vop2_win *win) > > > > { > > > > return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR); > > > > } > > > > > > > > So a flag is added and afterwards its evaluation is SoC specific. That > > > > doesn't help at all and only obfuscates things. > > > > > > > > Besides, experience shows that you can't predict a good abstraction for > > > This is not a predict, this is an IP feature, so it will appeared on > > > upcoming SOC. > > > > > > We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and > > > > > > also have a entry level soc which only have 4 windows, they both have this > > > feature. > > Same as with the other discussion: Please let's solve this once we are > > there. > > > I am not sure if this is the suitable way for upstream, this sound like > > just solve the issue appeared at the front of eyes and not think any > > thing about make this driver easy to support new hardware in the future. Oh come on, we are not talking about any major design decisions here, this is merely a small implementation detail that can be refactored anytime. I would change it when all it takes is to add a feature (or better: nonfeature) flag to the window data, but the combination of the flag *and* testing on which SoC the flag shall be honoured makes me feel that the feature flag is still not the best abstraction. Sascha
On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05: > > > > > > > >> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 01.04.2022, o godz. 14:52: > >> > >> Based on the discussion with Andy please try the following patch, it > >> should fix your green screen issue. Note that with this patch the > >> CRTC and plane ids will change, so the modetest commands need to be > >> adjusted accordingly. > >> > >> Sascha > >> > >> -------------------------8<--------------------------- > >> > >> -- > >> From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001 > >> From: Sascha Hauer <s.hauer@pengutronix.de> > >> Date: Fri, 1 Apr 2022 14:48:49 +0200 > >> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver > >> > >> --- > >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++ > >> 1 file changed, 14 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> index 7dba7b9b63dc6..1421bf2f133f1 100644 > >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2) > >> } > >> } > >> > >> + if (vop2->data->soc_id == 3566) { > >> + /* > >> + * On RK3566 these windows don't have an independent > >> + * framebuffer. They share the framebuffer with smart0, > >> + * esmart0 and cluster0 respectively. > >> + */ > >> + switch (win->data->phys_id) { > >> + case ROCKCHIP_VOP2_SMART1: > >> + case ROCKCHIP_VOP2_ESMART1: > >> + case ROCKCHIP_VOP2_CLUSTER1: > >> + continue; > >> + } > >> + } > >> + > >> if (win->type == DRM_PLANE_TYPE_OVERLAY) > >> possible_crtcs = (1 << nvps) - 1; > >> > >> -- > >> 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 | > > > > Sascha > > > > Now works perfectly! > > (hd playback with 3.5...5.5% cpu while rendering to drm plane) > > > > Fantastic work of You! > > Sascha, > > Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. > > context: player draws video on plane #X and osd on overlay plane #Y > When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.) > > This works well on all platforms i have - except rk3566 > > For me it looks like z-order vop2 issue or alpha blending issue. > As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho. During my testing I haven't seen any z-order issues, but that doesn't mean much. With Weston I can currently only use the AFBC enabled cluster windows and with modetest I can only use the non-cluster windows. Are you able to find out which window is used for the OSD? Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 06.04.2022, o godz. 16:58: > > On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote: >> >> >> Sascha, >> >> Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. >> >> context: player draws video on plane #X and osd on overlay plane #Y >> When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.) >> >> This works well on all platforms i have - except rk3566 >> >> For me it looks like z-order vop2 issue or alpha blending issue. >> As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho. > > During my testing I haven't seen any z-order issues, but that doesn't > mean much. With Weston I can currently only use the AFBC enabled cluster > windows and with modetest I can only use the non-cluster windows. Are > you able to find out which window is used for the OSD? > > Sascha > > -- > 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 | WiIl this answer to your Q? player: 2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt): 930mmx530mm 2022-04-06 17:52:26.424922 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1 2022-04-06 17:52:26.425061 I /dev/dri/card0: Authenticated 2022-04-06 17:52:26.534362 I /dev/dri/card0: Found 3 planes; 3 for this CRTC 2022-04-06 17:52:26.534384 I /dev/dri/card0: Selected Plane #37 Overlay for video 2022-04-06 17:52:26.534430 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY 2022-04-06 17:52:26.534437 I /dev/dri/card0: Selected Plane #43 Overlay for GUI 2022-04-06 17:52:26.534480 I /dev/dri/card0: DRM device retrieved from Qt 2022-04-06 17:52:26.534489 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1 so: plane #37 is where video is drawing plane #43 is GUI/OSD dri state: root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state plane[31]: Smart0-win0 crtc=video_port0 fb=58 allocated by = mythfrontend 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=4 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=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[43]: Cluster0-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 crtc[49]: video_port0 enable=1 active=1 self_refresh_active=0 planes_changed=1 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=1 connector_mask=1 encoder_mask=1 mode: "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 connector[51]: HDMI-A-1 crtc=video_port0 self_refresh_aware=0
On Wed, Apr 06, 2022 at 06:00:00PM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 06.04.2022, o godz. 16:58: > > > > On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote: > >> > >> > >> Sascha, > >> > >> Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. > >> > >> context: player draws video on plane #X and osd on overlay plane #Y > >> When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.) > >> > >> This works well on all platforms i have - except rk3566 > >> > >> For me it looks like z-order vop2 issue or alpha blending issue. > >> As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho. > > > > During my testing I haven't seen any z-order issues, but that doesn't > > mean much. With Weston I can currently only use the AFBC enabled cluster > > windows and with modetest I can only use the non-cluster windows. Are > > you able to find out which window is used for the OSD? > > > > Sascha > > > > -- > > 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 | > > WiIl this answer to your Q? Yes, and it raises a few more ;) > > player: > > 2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt): 930mmx530mm > 2022-04-06 17:52:26.424922 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1 > 2022-04-06 17:52:26.425061 I /dev/dri/card0: Authenticated > 2022-04-06 17:52:26.534362 I /dev/dri/card0: Found 3 planes; 3 for this CRTC > 2022-04-06 17:52:26.534384 I /dev/dri/card0: Selected Plane #37 Overlay for video > 2022-04-06 17:52:26.534430 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY > 2022-04-06 17:52:26.534437 I /dev/dri/card0: Selected Plane #43 Overlay for GUI > 2022-04-06 17:52:26.534480 I /dev/dri/card0: DRM device retrieved from Qt > 2022-04-06 17:52:26.534489 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1 > > so: > plane #37 is where video is drawing > plane #43 is GUI/OSD > > > dri state: > > root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state > plane[31]: Smart0-win0 > crtc=video_port0 > fb=58 > allocated by = mythfrontend > 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=4 > 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 Ok, this seems to be the base plane. > plane[37]: Esmart0-win0 > crtc=(null) crtc=null? Did you capture the state without a video playing? Otherwise I would expect a crtc associated here. > fb=0 > 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[43]: Cluster0-win0 > crtc=(null) This plane is selected for OSD by your application. The cluster windows can't show a regular linear framebuffer, they can only do AFBC. You'll see that in modetest: in_formats blob decoded: XR24: ARM_BLOCK_SIZE=16x16, ARM_BLOCK_SIZE=16x16,MODE=SPARSE ARM_BLOCK_SIZE=16x16,MODE=YTR ARM_BLOCK_SIZE=16x16,MODE=CBR ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE ARM_BLOCK_SIZE=16x16,MODE=SPARSE|CBR ARM_BLOCK_SIZE=16x16,MODE=YTR|CBR ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE|CBR ARM_BLOCK_SIZE=16x16,MODE=YTR|SPLIT|SPARSE ... The other windows show "XR24: LINEAR" here. Does your application use the GPU to render the OSD? Otherwise I doubt your application can handle this format, so it should not use this layer. > fb=0 > crtc-pos=0x0+0+0 > src-pos=0.000000x0.000000+0.000000+0.000000 > rotation=1 > normalized-zpos=0 I would be interested in this output when the player is actually playing something. This normalized-zpos puzzles me a bit. Normally it should be unique over all enabled planes for a CRTC. Maybe 0 is ok here because it's currently not associated to any CRTC. Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 07.04.2022, o godz. 12:16: > > > Yes, and it raises a few more ;) pls see at end of email: DRI state with playback > >> >> player: >> >> 2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt): 930mmx530mm >> 2022-04-06 17:52:26.424922 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1 >> 2022-04-06 17:52:26.425061 I /dev/dri/card0: Authenticated >> 2022-04-06 17:52:26.534362 I /dev/dri/card0: Found 3 planes; 3 for this CRTC >> 2022-04-06 17:52:26.534384 I /dev/dri/card0: Selected Plane #37 Overlay for video >> 2022-04-06 17:52:26.534430 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY >> 2022-04-06 17:52:26.534437 I /dev/dri/card0: Selected Plane #43 Overlay for GUI >> 2022-04-06 17:52:26.534480 I /dev/dri/card0: DRM device retrieved from Qt >> 2022-04-06 17:52:26.534489 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1 >> >> so: >> plane #37 is where video is drawing >> plane #43 is GUI/OSD >> >> >> dri state: >> >> root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state >> plane[31]: Smart0-win0 >> crtc=video_port0 >> fb=58 >> allocated by = mythfrontend >> 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=4 >> 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 > > Ok, this seems to be the base plane. > >> plane[37]: Esmart0-win0 >> crtc=(null) > > crtc=null? Did you capture the state without a video playing? Otherwise > I would expect a crtc associated here. Indeed. This was from player sitting in UI (no playback). Pls see at bottom of email state with video playback (it has crtc=video_port0) > >> fb=0 >> 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[43]: Cluster0-win0 >> crtc=(null) > > This plane is selected for OSD by your application. The cluster windows > can't show a regular linear framebuffer, they can only do AFBC. You'll > see that in modetest: > > in_formats blob decoded: > XR24: ARM_BLOCK_SIZE=16x16, > ARM_BLOCK_SIZE=16x16,MODE=SPARSE > ARM_BLOCK_SIZE=16x16,MODE=YTR > ARM_BLOCK_SIZE=16x16,MODE=CBR > ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE > ARM_BLOCK_SIZE=16x16,MODE=SPARSE|CBR > ARM_BLOCK_SIZE=16x16,MODE=YTR|CBR > ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE|CBR > ARM_BLOCK_SIZE=16x16,MODE=YTR|SPLIT|SPARSE > ... > > The other windows show "XR24: LINEAR" here. Does your application use > the GPU to render the OSD? Yes. > Otherwise I doubt your application can > handle this format, so it should not use this layer. > >> fb=0 >> crtc-pos=0x0+0+0 >> src-pos=0.000000x0.000000+0.000000+0.000000 >> rotation=1 >> normalized-zpos=0 > > I would be interested in this output when the player is actually playing > something. Pls see at bottom. > This normalized-zpos puzzles me a bit. I'm not surprised :-). You are puzzled probably because rk35xx current VOP2 code requires - from me - to force Z-position = 0 in Qt if I want to have GUI visible on screen. Without this screen is black. This seems to be i think - another issue to resolve (no any other SoC requires this....). I'm not sure where issue is - but as i need to do this only on VOP2 - i think there is somewhere something not right in VOP2 code. > Normally it should be > unique over all enabled planes for a CRTC. Maybe 0 is ok here because > it's currently not associated to any CRTC. It is because of me setting it to 0 (see explanations above) > > DRI state with video playback: root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state plane[31]: Smart0-win0 crtc=video_port0 fb=55 allocated by = mythfrontend 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=4 start=00000000 size=8294400 imported=no crtc-pos=1920x1080+0+0 src-pos=1920.000000x1080.000000+0.000000+0.000000 rotation=1 normalized-zpos=1 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[37]: Esmart0-win0 crtc=video_port0 fb=65 allocated by = mythfrontend refcount=2 format=NV12 little-endian (0x3231564e) modifier=0x0 size=1920x1080 layers: size[0]=1920x1080 pitch[0]=1920 offset[0]=0 obj[0]: name=0 refcount=3 start=00000000 size=3657728 imported=yes size[1]=960x540 pitch[1]=1920 offset[1]=2088960 obj[1]: name=0 refcount=3 start=00000000 size=3657728 imported=yes 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[43]: Cluster0-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 crtc[49]: video_port0 enable=1 active=1 self_refresh_active=0 planes_changed=1 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=3 connector_mask=1 encoder_mask=1 mode: "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 connector[51]: HDMI-A-1 crtc=video_port0 self_refresh_aware=0
On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05: > > Sascha > > > > Now works perfectly! > > (hd playback with 3.5...5.5% cpu while rendering to drm plane) > > > > Fantastic work of You! > > Sascha, > > Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. > > context: player draws video on plane #X and osd on overlay plane #Y > When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.) > > This works well on all platforms i have - except rk3566 > > For me it looks like z-order vop2 issue or alpha blending issue. > As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho. That turned out to be simpler than I thought it would be. The zpos values were never actually written to the hardware. Please try the following fixup, it should fix this issue. Thanks for your valuable testing feedback so far :) Sascha ----------------------------8<------------------------ From d5a102ff1d3010320f492a6ebac6710276fc641f Mon Sep 17 00:00:00 2001 From: Sascha Hauer <s.hauer@pengutronix.de> Date: Fri, 8 Apr 2022 09:45:24 +0200 Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver --- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c index 54208b20a5a7e..8d1323a47f822 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -1943,8 +1943,10 @@ static void vop2_setup_layer_mixer(struct vop2_video_port *vp) break; } - layer_sel &= ~RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, 0x7); - layer_sel |= RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, win->data->layer_sel_id); + layer_sel &= ~RK3568_OVL_LAYER_SEL__LAYER(plane->state->normalized_zpos + ofs, + 0x7); + layer_sel |= RK3568_OVL_LAYER_SEL__LAYER(plane->state->normalized_zpos + ofs, + win->data->layer_sel_id); nlayer++; }
On Fri, Apr 08, 2022 at 10:07:48AM +0200, Sascha Hauer wrote: > On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote: > > > > > > > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05: > > > Sascha > > > > > > Now works perfectly! > > > (hd playback with 3.5...5.5% cpu while rendering to drm plane) > > > > > > Fantastic work of You! > > > > Sascha, > > > > Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. > > > > context: player draws video on plane #X and osd on overlay plane #Y > > When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.) > > > > This works well on all platforms i have - except rk3566 > > > > For me it looks like z-order vop2 issue or alpha blending issue. > > As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho. > > That turned out to be simpler than I thought it would be. The zpos > values were never actually written to the hardware. Please try the > following fixup, it should fix this issue. Or better try v10 which I have just sent. Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 08.04.2022, o godz. 14:00: > >> That turned out to be simpler than I thought it would be. The zpos >> values were never actually written to the hardware. Please try the >> following fixup, it should fix this issue. > > Or better try v10 which I have just sent. > Sascha, I applied v10 on 5.17.2 and...can't see difference. I still need to play with zpos to get ui screen. if i have playback - no OSD. If I have OSD - no playback. Maybe fix needs some adjustments for 3566? Here is short summary of playings with zpos and kms plane in Qt: QT_QPA_EGLFS_KMS_ZPOS, QT_QPA_EGLFS_KMS_PLANE_INDEX 0,0 - GUI=ok, playback=ok, OSD=nok 1,0 - GUI=ok, playback=nok, OSD=ok 2,0 - GUI=ok, playback=nok, OSD=ok 0,1 - GUI=ok, playback=nok, OSD=ok 1,1 - GUI=ok, playback=nok, OSD=ok 2,1 - GUI=ok, playback=nok, OSD=ok 0,2 - GUI=nok, playback=n/a, OSD=n/a 1,2 - GUI=nok, playback=n/a, OSD=n/a 2,2 - GUI=nok, playback=n/a, OSD=n/a player launch: ....... 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 ....... playback: ..... 2022-04-08 17:48:55.457823 I DRMVideo: Using Plane #37 for video ..... DRI state with zpos=0, kms_id=0 and ongoing playback: root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state plane[31]: Smart0-win0 crtc=video_port0 fb=58 allocated by = mythfrontend 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=4 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=video_port0 fb=65 allocated by = mythfrontend refcount=2 format=NV12 little-endian (0x3231564e) modifier=0x0 size=1920x1080 layers: size[0]=1920x1080 pitch[0]=1920 offset[0]=0 obj[0]: name=0 refcount=3 start=00000000 size=3657728 imported=yes size[1]=960x540 pitch[1]=1920 offset[1]=2088960 obj[1]: name=0 refcount=3 start=00000000 size=3657728 imported=yes crtc-pos=1920x1080+0+0 src-pos=1920.000000x1080.000000+0.000000+0.000000 rotation=1 normalized-zpos=1 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[43]: Cluster0-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 crtc[49]: video_port0 enable=1 active=1 self_refresh_active=0 planes_changed=1 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=3 connector_mask=1 encoder_mask=1 mode: "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 connector[51]: HDMI-A-1 crtc=video_port0 self_refresh_aware=0 root@Myth-Frontend-06c7e973c2f1:~ #
On Fri, Apr 08, 2022 at 05:54:24PM +0200, Piotr Oniszczuk wrote: > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 08.04.2022, o godz. 14:00: > > > >> That turned out to be simpler than I thought it would be. The zpos > >> values were never actually written to the hardware. Please try the > >> following fixup, it should fix this issue. > > > > Or better try v10 which I have just sent. > > > > Sascha, > > I applied v10 on 5.17.2 and...can't see difference. > I still need to play with zpos to get ui screen. > if i have playback - no OSD. > If I have OSD - no playback. > > Maybe fix needs some adjustments for 3566? I don't think so. > player launch: > ....... > 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 Ok, so #37 for video, #43 for GUI. Where is the OSD rendered? Is it rendered on the GUI layer? > ....... > > > playback: > ..... > 2022-04-08 17:48:55.457823 I DRMVideo: Using Plane #37 for video > ..... > > DRI state with zpos=0, kms_id=0 and ongoing playback: > > root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state > plane[31]: Smart0-win0 > crtc=video_port0 > fb=58 > allocated by = mythfrontend > 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=4 > 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 Base plane. > plane[37]: Esmart0-win0 > crtc=video_port0 > fb=65 > allocated by = mythfrontend > refcount=2 > format=NV12 little-endian (0x3231564e) > modifier=0x0 > size=1920x1080 > layers: > size[0]=1920x1080 > pitch[0]=1920 > offset[0]=0 > obj[0]: > name=0 > refcount=3 > start=00000000 > size=3657728 > imported=yes > size[1]=960x540 > pitch[1]=1920 > offset[1]=2088960 > obj[1]: > name=0 > refcount=3 > start=00000000 > size=3657728 > imported=yes > crtc-pos=1920x1080+0+0 > src-pos=1920.000000x1080.000000+0.000000+0.000000 > rotation=1 > normalized-zpos=1 > color-encoding=ITU-R BT.601 YCbCr > color-range=YCbCr limited range Video plane, rendered full screen above the base plane without alpha. > plane[43]: Cluster0-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 Here should be the GUI, but this plane is not active. With this state I would expect to see a full screen video without anything on it. Is that the case? If yes, then fine. Could you post a state where you expect something else than is actually seen? Sascha
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 11.04.2022, o godz. 11:08: > > Ok, so #37 for video, #43 for GUI. > > Where is the OSD rendered? Is it rendered on the GUI layer? Yes > >> ....... >> >> >> playback: >> ..... >> 2022-04-08 17:48:55.457823 I DRMVideo: Using Plane #37 for video >> ..... >> >> DRI state with zpos=0, kms_id=0 and ongoing playback: >> >> root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state >> plane[31]: Smart0-win0 >> crtc=video_port0 >> fb=58 >> allocated by = mythfrontend >> 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=4 >> 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 > > Base plane. > >> plane[37]: Esmart0-win0 >> crtc=video_port0 >> fb=65 >> allocated by = mythfrontend >> refcount=2 >> format=NV12 little-endian (0x3231564e) >> modifier=0x0 >> size=1920x1080 >> layers: >> size[0]=1920x1080 >> pitch[0]=1920 >> offset[0]=0 >> obj[0]: >> name=0 >> refcount=3 >> start=00000000 >> size=3657728 >> imported=yes >> size[1]=960x540 >> pitch[1]=1920 >> offset[1]=2088960 >> obj[1]: >> name=0 >> refcount=3 >> start=00000000 >> size=3657728 >> imported=yes >> crtc-pos=1920x1080+0+0 >> src-pos=1920.000000x1080.000000+0.000000+0.000000 >> rotation=1 >> normalized-zpos=1 >> color-encoding=ITU-R BT.601 YCbCr >> color-range=YCbCr limited range > > Video plane, rendered full screen above the base plane without alpha. > >> plane[43]: Cluster0-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 > > Here should be the GUI, but this plane is not active. I suspect this is because above DRI state report was with user-forced Qt vars. This was because to get UI non-black screen. I done this by request to provide DRI state with video playback. (to get playback I need UI to navigate) By this DRI state report might misleading as i'm manually forcing Qt KMS_Index/Zpos. > > With this state I would expect to see a full screen video without > anything on it. Is that the case? If yes, then fine. yes. this is a case. so this is fine. So I think non-visible OSD issue is side effect of other, root cause issue: issue causing user to force Qt vars to get UI on VOP2 Context: (my view): We have stack of 3 components interacting: 1.player (draws video to DRM plane) 2.Qt (draws UI to GL to DRM plane) 3.DRM (mixing planes+displaying) Stack coperation: a. DRM reports available planes+attributes to player b. player - accordingly to above report - sets Qt (KMS/Zpos, etc). c. user starting player. player uses Qt for drawing UI d. user asks for playback e. player draws (by Qt) OSD and directly video (accordingly to Qt setup in (b) With VOP2 i have issue at (c): screen is black. Above procedure works fully automated on all other platforms i have/supporting. For me most probable hypothesis: 1\ - In steep (b) Qt is set (or configured to use DRM) in way that UI resulting with black screen - this is because in (a) player receives (wrong?) DRM report - and by this Qt is wrongly set This may explain we have issue at (c) 2\ - In steep (b) Qt is set & using DRM in way that UI should work ok - but VOP2 draws black screen (by some reason) This may explain we have issue at (c) Alternative hypothesis: DRM properly realises (a) Player wrongly realises (b) This hypothesis is way less probable (for me) because: 1. procedure (a)...(e) works well on all other SoC. No need from user to overwrite automatically detected/set of Qt vars. 2. vop2 is single requiring from user overwrite of autodetected Qt vars. to get non-black screen UI. I'm a bit out of ideas how to progress with this. As (a)...(e) concept works ok (and afaik also is used by other players exploiting DRM planes rendering) - i'm not sure should I play with (b) because of VOP2 black-screen? BTW: 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) modifier=0x0 size=1920x1080 layers: size[0]=1920x1080 pitch[0]=7680 offset[0]=0 obj[0]: name=0 refcount=4 start=00000000 size=8294400 imported=no crtc-pos=1920x1080+0+0 src-pos=1920.000000x1080.000000+0.000000+0.000000 rotation=1 normalized-zpos=1 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range crtc[49]: video_port0 enable=1 active=1 self_refresh_active=0 planes_changed=1 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=5 connector_mask=1 encoder_mask=1 mode: "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 connector[51]: HDMI-A-1 crtc=video_port0 self_refresh_aware=0
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. 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@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@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,
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@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@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 > >
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 12.04.2022, o godz. 09:50: > > > 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. > Applied :-) Results: pls see below > 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@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@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, > -- > With above patch app select expected format (i think): 1970-01-01 01:00:31.074643 I /dev/dri/card0: Authenticated 1970-01-01 01:00:31.189420 I /dev/dri/card0: Found 3 planes; 3 for this CRTC 1970-01-01 01:00:31.189444 I /dev/dri/card0: Selected Plane #37 Overlay for video 1970-01-01 01:00:31.189528 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY 1970-01-01 01:00:31.189536 I /dev/dri/card0: Selected Plane #43 Overlay for GUI 1970-01-01 01:00:31.190279 I Wrote /home/minimyth/.mythtv/eglfs_kms_config.json: { "device": "/dev/dri/card0", "outputs": [ { "name": "HDMI1", "format": "abgr8888", "mode": "current" } ] } (file eglfs_kms_config.json is generated by app to configure Qt; it is steep (b) in yesterday's email) I see format abgr8888 is now selected by app (this is expected t think) but later Qt says: 1970-01-01 01:00:34.985215 I Qt: EGL Error : Could not create the egl surface: error = 0x3009 Handling Aborted Aborted I suspect Qt tries with this format talk to GLES provider - but it wasn't somehow accepted by underlying EGL provider (mesa GLES)?
> Wiadomość napisana przez Lucas Stach <l.stach@pengutronix.de> w dniu 12.04.2022, o godz. 10:10: > > 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. This is good remark imho. I think we have this fallback. I'll try verify this. Generalising a bit - I think we my consider following cases: a\ format is correctly negotiated and signalled to consumer/provider but we don't see expected results (=correct screen seen by user) b\ format was correctly negotiated but consumer/provider failed using signalled format (i.e. due bug in implementation) c\ consumer or provider advertising - in reality unsupported format (false positive) - so negotiation resulting with signalling efficiently non-working format Sascha says (in today's email): "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:" I'm reading this as case c\ as Sascha said "negotiated format is not supported by GPU" ....but this format was negotiated. ......but for sure Sascha is much better than me here in subject - so i'm might be wrong here > 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. > This will be cardinal design error. (keeping in mind we have multiple producers (GPU/video decoder) and multiple consumers (base & overlay DRM 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. > Testing Sacha patch (see today's email from Sascha) i'm getting Qt: EGL Error : Could not create the egl surface: error = 0x3009 i'm reading this as: Qt tries allocate EGL surface and EGL returns error. or i'm wrong?
On Tue, 12 Apr 2022 at 11:14, Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > Wiadomość napisana przez Lucas Stach <l.stach@pengutronix.de> w dniu 12.04.2022, o godz. 10:10: > > 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. > > This will be cardinal design error. > (keeping in mind we have multiple producers (GPU/video decoder) and multiple consumers (base & overlay DRM 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. > > Testing Sacha patch (see today's email from Sascha) i'm getting > > Qt: EGL Error : Could not create the egl surface: error = 0x3009 > > i'm reading this as: Qt tries allocate EGL surface and EGL returns error. > or i'm wrong? Correct, that's EGL_BAD_MATCH. There are very few ways that can happen; by far the most likely is that Qt has chosen an EGLConfig which does not correctly correspond to the format. (If it was an impossible format/modifier combination, then this would be already caught when allocating the gbm_surface.) Either way, it seems quite clear that the VOP2 driver is totally fine here, and that you have a Qt (likely) or Mesa (tbh less likely) issue to debug to get the app working. Cheers, Daniel
> Wiadomość napisana przez Daniel Stone <daniel@fooishbar.org> w dniu 12.04.2022, o godz. 13:30: > >> Testing Sacha patch (see today's email from Sascha) i'm getting >> >> Qt: EGL Error : Could not create the egl surface: error = 0x3009 >> >> i'm reading this as: Qt tries allocate EGL surface and EGL returns error. >> or i'm wrong? > > Correct, that's EGL_BAD_MATCH. There are very few ways that can > happen; by far the most likely is that Qt has chosen an EGLConfig > which does not correctly correspond to the format. (If it was an > impossible format/modifier combination, then this would be already > caught when allocating the gbm_surface.) > > Either way, it seems quite clear that the VOP2 driver is totally fine > here, and that you have a Qt (likely) or Mesa (tbh less likely) issue > to debug to get the app working. > > Cheers, > Daniel Thx Daniel! Indeed - this is probably another case where I see: writing DRM planes rendering mediaplayer with help of Qt is (too)corner case for Qt.... @all Looking on Qt sources it looks to me this format should be supported: https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/kmsconvenience/qkmsdevice.cpp?h=5.15.2#n380 Interesting that with custom Qt config1: "format": "argb8888", DRI state shows: format=AR24 little-endian (0x34325241) UI is OK, playback is OK. OSD not visible (*) custom config2: "format": "abgr8888" Qt crashes with EGL_BAD_MATCH So it looks forcing some Qt formats works while other - not. Looking why this: Qt logging says nothing. export MESA_DEBUG=1 gives no any message. I'm a lost here a bit... But from a bit more distant perspective: 1. Sascha concludes in (*) that issue is most probably in format negotiation by app. 2. imho app probably correctly negotiates accordingly to inputs it gets from providers (DRM) and clients (mesa). Test with patch excluding DRM_FORMAT_XRGB8888, DRM_FORMAT_ARGB8888, shows imho proper app reaction on this (new format elected; but Qt fails with this format). Indirectly i conclude app logic is ok.... 3. Sum of p1 & p2 tells me: i need to add extra logic in format election to specifically deal with constrains of rk356x (see explanation in (*)) 4. Even if i implement p3 - then user world - (this using Qt) - will be not happy as: - majority users are using pre-build Qt - I don't believe Trolltech will fix this soon So i see following path: we will verify is issue of Qt with abgr8888 an Qt root cause issue, If Yes - then: - Investigate is there reasonable way to workaround with this outside of Qt? If not - then: - conclude: vop2 - due Qt bug - will not work ok with Qt until Qt will be fixed. If you think this make sense - i need some help with: verify is issue of Qt with abgr8888 an Qt root cause issue let me know what you think (*) Sascha mentioned: > 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.
Hi Piotr, On Fri, 15 Apr 2022 at 12:11, Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > Looking on Qt sources it looks to me this format should be supported: > > https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/kmsconvenience/qkmsdevice.cpp?h=5.15.2#n380 > > Interesting that with custom Qt config1: "format": "argb8888", > DRI state shows: format=AR24 little-endian (0x34325241) > > UI is OK, playback is OK. OSD not visible (*) > > custom config2: "format": "abgr8888" > Qt crashes with EGL_BAD_MATCH > > So it looks forcing some Qt formats works while other - not. > > Looking why this: > > Qt logging says nothing. > export MESA_DEBUG=1 gives no any message. I'm a lost here a bit... I bet if you dumped the gbm_surface format (passed by Qt as a parameter to gbm_surface_create_with_modifiers or gbm_surface_create) and the EGLConfig's EGL_NATIVE_VISUAL_ID (from eglQueryConfig), you would see that the format tokens are different. Which is a Qt coding error. > But from a bit more distant perspective: > > 1. Sascha concludes in (*) that issue is most probably in format negotiation by app. > > 2. imho app probably correctly negotiates accordingly to inputs it gets from providers (DRM) and clients (mesa). > Test with patch excluding > DRM_FORMAT_XRGB8888, > DRM_FORMAT_ARGB8888, > shows imho proper app reaction on this (new format elected; but Qt fails with this format). Indirectly i conclude app logic is ok.... > > 3. Sum of p1 & p2 tells me: > i need to add extra logic in format election to specifically deal with constrains of rk356x (see explanation in (*)) I disagree. I looked at a clone of Qt, and I could not see a coherent path that ensured that the gbm_surface format chosen by Qt matched the EGLConfig format used on that EGLSurface. A mismatch is an error. There are some workarounds allowing you to specify a format, however those only work by coincidence sometimes. Even with the explicit format specification, Qt never makes any attempt to match gbm_surface and EGLConfig formats; it just hopes that they will match by coincidence. There is no additional complexity or strangeness that RK356x is introducing here. It only works by pure luck on other platforms. > 4. Even if i implement p3 - then user world - (this using Qt) - will be not happy as: > - majority users are using pre-build Qt > - I don't believe Trolltech will fix this soon > > So i see following path: > > we will verify is issue of Qt with abgr8888 an Qt root cause issue, > > If Yes - then: > - Investigate is there reasonable way to workaround with this outside of Qt? > If not - then: > - conclude: vop2 - due Qt bug - will not work ok with Qt until Qt will be fixed. > > > If you think this make sense - i need some help with: verify is issue of Qt with abgr8888 an Qt root cause issue Unfortunately there is no reasonable workaround outside of Qt. Looking at the Qt/QPA source tree, it looks like the usual way of 'fixing' this is to hack platform specific configuration into the Qt backend. If Qt won't be fixed to use generic APIs correctly, then I guess your best option is to just hack up yet another platform-specific backend. Which is a shame, but there is no reasonable workaround we can do in low-level code for toolkits doing the wrong thing and hoping it works. Cheers, Daniel
This is v9 of the VOP2 series. Biggest change this time is that I marked the hclk_vo as critical instead of enabling it in the HDMI driver. Also a little bugfix is included for a bug in setting up the layer mixer, reported by Andy Yan. Note that this series depends on these patches: clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop* clk: rockchip: rk3568: Add more PLL rates These are not included in this series as they are already applied by Heiko. They haven't hit mainline yet, you can pick them from v4 of this series. Sascha Changes since v8: - make hclk_vo a critical clock instead of enabling it in the hdmi driver - Fix vop2_setup_layer_mixer(), reported by Andy Yan - Limit planes possible_crtcs to actually existing crtcs - simplify vop2_create_crtc() a bit Changes since v7: - rename hclk to niu Changes since v6: - Move of_graph parsing out of runtime code to initialization Changes since v5: - Add new patch to fix dw-hdmi of_graph binding - Drop "drm/encoder: Add of_graph port to struct drm_encoder" and solve issue internally in the driver - make checkpatch cleaner Changes since v4: - Reorder patches in a way that binding/dts/driver patches are closer together - Drop clk patches already applied by Heiko Changes since v3: - added changelog to each patch - Add 4k support to hdmi driver - rebase on v5.17-rc1 Changes since v2: - Add pin names to HDMI supply pin description - Add hclk support to HDMI driver - Dual license rockchip-vop2 binding, update binding - Add HDMI connector to board dts files - drop unnecessary gamma_lut registers from vop2 - Update dclk_vop[012] clock handling, no longer hacks needed - Complete regmap conversion Changes since v1: - drop all unnecessary waiting for frames within atomic modeset and plane update - Cluster subwin support removed - gamma support removed - unnecessary irq_lock removed - interrupt handling simplified - simplified zpos handling - drop is_alpha_support(), use fb->format->has_alpha instead - use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi regulators - Use fixed number of planes per video port - Drop homegrown regmap code from vop2 driver (not complete yet) - Add separate include file for vop2 driver to not pollute the vop include Andy Yan (1): drm: rockchip: Add VOP2 driver Benjamin Gaignard (1): dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI Douglas Anderson (2): drm/rockchip: dw_hdmi: Use auto-generated tables drm/rockchip: dw_hdmi: Set cur_ctr to 0 always Michael Riesch (1): arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a Nickey Yang (1): drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz Sascha Hauer (17): clk: rk3568: Mark hclk_vo as critical drm/rockchip: Embed drm_encoder into rockchip_decoder drm/rockchip: Add crtc_endpoint_id to rockchip_encoder drm/rockchip: dw_hdmi: rename vpll clock to reference clock dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref' drm/rockchip: dw_hdmi: add rk3568 support drm/rockchip: dw_hdmi: add regulator support dt-bindings: display: rockchip: dw-hdmi: Add regulator support drm/rockchip: dw_hdmi: drop mode_valid hook dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional arm64: dts: rockchip: rk356x: Add VOP2 nodes arm64: dts: rockchip: rk356x: Add HDMI nodes arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi drm/rockchip: Make VOP driver optional dt-bindings: display: rockchip: Add binding for VOP2 dt-bindings: display: rockchip: dw-hdmi: fix ports description .../display/rockchip/rockchip,dw-hdmi.yaml | 46 +- .../display/rockchip/rockchip-vop2.yaml | 140 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +- .../boot/dts/rockchip/rk3566-quartz64-a.dts | 47 + arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 + .../boot/dts/rockchip/rk3568-evb1-v10.dts | 47 + arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 83 + drivers/clk/rockchip/clk-rk3568.c | 1 + drivers/gpu/drm/rockchip/Kconfig | 14 + drivers/gpu/drm/rockchip/Makefile | 4 +- .../gpu/drm/rockchip/analogix_dp-rockchip.c | 32 +- drivers/gpu/drm/rockchip/cdn-dp-core.c | 18 +- drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 17 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 276 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 32 +- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 34 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 36 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 20 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 + drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2688 +++++++++++++++++ drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 477 +++ drivers/gpu/drm/rockchip/rockchip_lvds.c | 26 +- drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 281 ++ include/dt-bindings/soc/rockchip,vop2.h | 14 + 27 files changed, 4167 insertions(+), 195 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c create mode 100644 include/dt-bindings/soc/rockchip,vop2.h