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