[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zv0nEqV5G2JamvxL@pineapple>
Date: Wed, 2 Oct 2024 10:57:22 +0000
From: Yao Zi <ziyao@...root.org>
To: Neil Armstrong <neil.armstrong@...aro.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: dri-devel@...ts.freedesktop.org, linux-amlogic@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] drm/meson: Support drm_panic
On Wed, Oct 02, 2024 at 09:59:57AM +0200, Neil Armstrong wrote:
> I thing the code should look like:
>
> if (priv->viu.osd1_afbcd) {
> meson_canvas_config(priv->canvas, priv->canvas_id_osd1,
> priv->viu.osd1_addr,
> priv->viu.osd1_stride,
> priv->viu.osd1_height,
> MESON_CANVAS_WRAP_NONE,
> MESON_CANVAS_BLKMODE_LINEAR, 0);
>
> if (priv->afbcd.ops) {
> priv->afbcd.ops->reset(priv);
> priv->afbcd.ops->disable(priv);
> }
>
> if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
> writel_bits_relaxed(OSD_ENDIANNESS_LE, OSD_ENDIANNESS_LE,
> priv->io_base +
> _REG(VIU_OSD1_BLK0_CFG_W0));
> meson_viu_g12a_disable_osd1_afbc(priv);
> } else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM)) {
> writel_bits_relaxed(OSD_DPATH_MALI_AFBCD, 0,
> priv->io_base +
> _REG(VIU_OSD1_CTRL_STAT2));
> meson_viu_gxm_disable_osd1_afbc(priv);
> }
> }
Thanks for correction!
> AFBC is quite hard to test since it requires DRM_FORMAT_XBGR8888, but
> I think sway should perhaps support it, Mesa should also support AFBC.
Have tried with Sway 1.9 and weston 14.0.0 and didn't find a way to make
them create buffers with AFBC modifiers. modetest util in libdrm doesn't
support it either.
> At some point I made some memory dumps of AFBC buffers, perhaps they could
> be useful here.
>
> Another way would be to simply ignore the AFBC case, and bail out since
> it would be a very rare case.
I'm not sure the use case of an AFBC-enabled primary plane. It should be
rare the whole primary plane is filled with pixel data from GPU or video
codec.
If my guess is true, bailing out when AFBC is enabled should be
acceptable. Will try to do some AFBC tests if possible and consider
it as a latest solution.
btw, I forget to check whether drm_gem_fb_vmap() succeeds. Will fix it
later.
Thanks for your advice again!
Best regards,
Yao Zi
Powered by blists - more mailing lists