Hi Piotr,
On Wed, Jan 19, 2022 at 12:29:49PM +0100, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Sascha Hauer <s.ha...@pengutronix.de> w dniu
> > 20.12.2021, o godz. 12:06:
> >
> >
> > Third round of patches and last one for this year. I hopefully integrated
> > all review feedback. Additionally the driver is now fully converted to
> > regmap, so no struct vop_reg necessary anymore.
> >
> > Sascha
> >
> > 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
> >
>
> Sascha
>
> I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.
>
> I have just few questions:
>
> 1. how support for CEC looks/prospects (plans for future, not in this code,
> expecting others should implement, etc)?
I had to google what CEC actually is. We don't have plans supporting it.
It looks like this is a matter of the HDMI driver supporting this and
not bound to the rockchip driver.
>
> 2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf
> rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
> I have issue however with app. rendering to DRM planes (GUI is DRM plane1,
> video is DRM pane2).
> My ppp starts/works without any errors in log - but screen stays with kernel
> messages content.
> (it looks to me like i.e. app renders to DRM plane but DRM display driver not
> pass it to CRTC. just wild guess here...).
You enabled the panfrost driver with other patches, right?
>
> 3. in kernel dmesg I have many:
>
> "rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier
> 0x810000000000001".
This message is correct. This corresponds to
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
support this. I have a similar problem here with
weston-simple-dmabuf-egl. By default this uses DRM_FORMAT_XRGB8888
which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA. In
panfrost_afbc_format() we have:
/* 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;
}
This means the driver won't do AFBC with that format and picks
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED instead. Now weston is
clever enough to not pass that into the VOP2 driver, apparently your
application is not and as a result you see that message.
In weston-simple-dmabuf-egl I can pass a suitable format on the command
line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
which then can be rendered in the VOP2 cluster window overlay.
>
> It comes from MESA i think - but i suspect because VOP2 provides
> unknown/wrong DRM modifier to mesa?
Nope, the modifiers the VOP2 driver propagates are correct. It doesn't
claim to support DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED.
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 |
