From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: "CK Hu (胡俊光)" <ck.hu@mediatek.com>,
"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
"simona@ffwll.ch" <simona@ffwll.ch>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"airlied@gmail.com" <airlied@gmail.com>,
"greenjustin@chromium.org" <greenjustin@chromium.org>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>
Cc: "Ariel D'Alessandro" <ariel.dalessandro@collabora.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Nancy Lin (林欣螢)" <Nancy.Lin@mediatek.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Daniel Stone" <daniels@collabora.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"kernel@collabora.com" <kernel@collabora.com>
Subject: Re: [PATCH RFC 3/6] drm/mediatek: ovl: Fix misaligned layer source size on AFBC mode
Date: Thu, 05 Feb 2026 14:13:20 -0500 [thread overview]
Message-ID: <1394a4b34db511c921b2709a58dfaf28c1cce45c.camel@collabora.com> (raw)
In-Reply-To: <3716cf4707924e97c097cfefa11c7feb09a1ee16.camel@mediatek.com>
On Tue, 2026-02-03 at 02:01 +0000, CK Hu (胡俊光) wrote:
> On Tue, 2025-12-30 at 11:03 -0300, Nícolas F. R. A. Prado wrote:
> > From: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> >
> > In AFBC mode, OVL_SRC_SIZE must be block aligned. Due to this
> > limitation
> > of the AFBC format, OVL_CLIP needs to be used to achieve the
> > desired
> > output size of the layer while still meeting the alignment
> > constraints.
> > Failure to do this will result in vblank timeouts and no rendered
> > output
> > when the AFBC data source isn't aligned to the AFBC block (32x8).
> >
> > Configure OVL_CLIP so unaligned AFBC layers can be displayed.
> >
> > The following illustrates how the alignment is achieved through the
> > clip
> > settings for the horizontal coordinates, the vertical coordinates
> > are
> > analogous:
> >
> > /------------------------------------------------\
> > > |
> > > ........................ |
> > > ........................ |
> > > ........................ |
> > > ........................ |
> > > |
> > \------------------------------------------------/
> > | | | |
> > | src.x1 src.x2 |
> > | | | |
> > | |<-------------------->| |
> > | src_width |
> > | |
> > N * AFBC_DATA_BLOCK_WIDTH M *
> > AFBC_DATA_BLOCK_WIDTH
> > | |
> > |<----->| |<----->|
> > clip_left clip_right
>
> As I know, crop is used to drop pixel data.
> From the name of 'clip_left', I think it would drop the left part of
> this image.
> But usually the image is aligned to the left (start from axis 0) and
> append garbage data in right part.
> If so, clip_left should be zero and all the clip would be clip_right.
> This is the normal behavior.
> If OVL_CROP does behave as this, add comment to describe that
> clip_left does not drop pixel data.
Both clip_left and clip_right work in the same way, by discarding that
many pixels, on the left and right, respectively, of the plane's
framebuffer when compositing the plane on the final image.
In the simplest case, when the image to be displayed is left-aligned,
ie src.x1 = 0, then yes, only clip_right will be used to make sure that
the plane's width aligns with the AFBC_DATA_BLOCK_WIDTH.
However if only a sub-region of the image is to be displayed, then
src.x1 will be non-zero. If that x offset coordinate aligns with the
AFBC_DATA_BLOCK_WIDTH, then again clip_left will be 0, and we're back
at the simplest case.
But if it doesn't align, then clip_left will need to be used to ensure
only the intended sub-region is displayed, even though it starts in the
middle of an AFBC data block.
This is because not only the width and height in DISP_REG_OVL_SRC_SIZE
need to be aligned to the AFBC data block, but also the starting
address in DISP_REG_OVL_ADDR, while src.x1 and src.x2 supplied by
userspace are arbitrary and won't necessarily align, hence we use both
clips as needed to achieve the intended display outcome respecting the
hardware constraints.
--
Thanks,
Nícolas
next prev parent reply other threads:[~2026-02-05 19:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 14:03 [PATCH RFC 0/6] AFBC fixes for MediaTek DRM Nícolas F. R. A. Prado
2025-12-30 14:03 ` [PATCH RFC 1/6] drm/mediatek: plane: Remove extra block from AFBC data payload offset Nícolas F. R. A. Prado
2026-02-02 6:26 ` CK Hu (胡俊光)
2025-12-30 14:03 ` [PATCH RFC 2/6] drm/mediatek: plane: Correct AFBC alignment definition to 128 Nícolas F. R. A. Prado
2026-02-02 6:28 ` CK Hu (胡俊光)
2025-12-30 14:03 ` [PATCH RFC 3/6] drm/mediatek: ovl: Fix misaligned layer source size on AFBC mode Nícolas F. R. A. Prado
2026-02-02 8:46 ` CK Hu (胡俊光)
2026-02-05 18:46 ` Nícolas F. R. A. Prado
2026-02-03 2:01 ` CK Hu (胡俊光)
2026-02-05 19:13 ` Nícolas F. R. A. Prado [this message]
2026-02-12 1:54 ` CK Hu (胡俊光)
2026-02-12 7:10 ` CK Hu (胡俊光)
2025-12-30 14:03 ` [PATCH RFC 4/6] drm/mediatek: ovl: Disallow AFBC buffers with width over 1920 Nícolas F. R. A. Prado
2026-02-03 2:21 ` CK Hu (胡俊光)
2025-12-30 14:03 ` [PATCH RFC 5/6] drm/mediatek: ovl: Disable AFBC on MT8188 Nícolas F. R. A. Prado
2026-02-03 2:41 ` CK Hu (胡俊光)
2025-12-30 14:03 ` [PATCH RFC 6/6] drm/mediatek: Re-enable AFBC support on MediaTek DRM driver Nícolas F. R. A. Prado
2026-02-03 2:50 ` CK Hu (胡俊光)
2026-01-09 18:27 ` [PATCH RFC 0/6] AFBC fixes for MediaTek DRM Nícolas F. R. A. Prado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1394a4b34db511c921b2709a58dfaf28c1cce45c.camel@collabora.com \
--to=nfraprado@collabora.com \
--cc=Jason-JH.Lin@mediatek.com \
--cc=Nancy.Lin@mediatek.com \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ariel.dalessandro@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=ck.hu@mediatek.com \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=greenjustin@chromium.org \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®