From: Daniel Vetter <daniel@ffwll.ch>
To: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: kernel@collabora.com, Mihail Atanassov <mihail.atanassov@arm.com>,
David Airlie <airlied@linux.ie>,
Liviu Dudau <liviu.dudau@arm.com>,
dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org,
James Wang <james.qian.wang@arm.com>,
Ayan Halder <Ayan.Halder@arm.com>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers
Date: Thu, 7 Nov 2019 09:27:33 +0100 [thread overview]
Message-ID: <20191107082733.GI23790@phenom.ffwll.local> (raw)
In-Reply-To: <d4828420-6109-ff93-e0da-d0493cf3aef5@collabora.com>
On Wed, Nov 06, 2019 at 01:45:05PM +0100, Andrzej Pietrasiewicz wrote:
> Hi Daniel,
>
> Thank you for review,
>
> W dniu 05.11.2019 o 10:22, Daniel Vetter pisze:
> > On Mon, Nov 04, 2019 at 11:12:25PM +0100, Andrzej Pietrasiewicz wrote:
> > > These are useful for other users of afbc, e.g. rockchip.
> > >
>
> <snip>
>
> > > +
> > > +bool drm_afbc_check_fb_size_ret(u32 pitch, int bpp,
> > > + u32 w, u32 h, u32 superblk_w, u32 superblk_h,
> > > + size_t size, u32 offset, u32 hdr_align,
> > > + u32 *payload_off, u32 *total_size)
> > > +{
> > > + int n_superblks = 0;
> > > + u32 superblk_sz = 0;
> > > + u32 afbc_size = 0;
> > > +
> > > + n_superblks = (w / superblk_w) * (h / superblk_h);
> > > + superblk_sz = (bpp * superblk_w * superblk_h) / BITS_PER_BYTE;
> > > + afbc_size = ALIGN(n_superblks * AFBC_HEADER_SIZE, hdr_align);
> > > + *payload_off = afbc_size;
> > > +
> > > + afbc_size += n_superblks * ALIGN(superblk_sz, AFBC_SUPERBLK_ALIGNMENT);
> > > + *total_size = afbc_size + offset;
> > > +
> > > + if ((w * bpp) != (pitch * BITS_PER_BYTE)) {
> > > + DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) should be same as width (=%u) * bpp (=%u)\n",
> > > + pitch * BITS_PER_BYTE, w, bpp
> > > + );
> > > + return false;
> > > + }
> > > +
> > > + if (size < afbc_size) {
> > > + DRM_DEBUG_KMS("buffer size (%zu) too small for AFBC buffer size = %u\n",
> > > + size, afbc_size
> > > + );
> > > +
> > > + return false;
> > > + }
> > > +
> > > + return true;
> > > +}
> > > +EXPORT_SYMBOL(drm_afbc_check_fb_size_ret);
> > > +
> > > +bool drm_afbc_check_fb_size(u32 pitch, int bpp,
> > > + u32 w, u32 h, u32 superblk_w, u32 superblk_h,
> > > + size_t size, u32 offset, u32 hdr_align)
> > > +{
> > > + u32 payload_offset, total_size;
> > > +
> > > + return drm_afbc_check_fb_size_ret(pitch, bpp, w, h,
> > > + superblk_w, superblk_h,
> > > + size, offset, hdr_align,
> > > + &payload_offset, &total_size);
> > > +}
> > > +EXPORT_SYMBOL(drm_afbc_check_fb_size);
> >
> > Why don't we have one overall "check afbc parameters against buffer"
> > function?
> >
>
> I noticed that different drivers have different needs (malidp
> and rockchip are kind of similar, but komeda is a bit different).
> That is why the helpers are only building blocks out of which
> each driver builds its own checking logic. In particular komeda
> wants some by-products of the check stored in its internal data
> structures, hence drm_afbc_check_fb_size_ret() and its wrapper
> drm_afbc_check_fb_size() which ignores the "out" parameters.
>
> If I wanted to create one overall "check afbc parameters" I'd have
> to come up with a way to pass driver-specific requirements to it
> and then inside the function have some logic to decide what to
> check against what. Do you think it is worth it?
Hm I figured there's at least two parts of this:
- Generic checking of afbc against the fb parameters, i.e. is it big
enough, correctly aligned, all that.
- Additional driver checks, which might need some of the same parameters
again.
The idea behind asking for the first part is that maybe we should put that
into the core as part of the addfb checks (like we do for the tiled NV12
thing already). Then drivers only need to do additional checks on top for
their specific constraints. For that you could expose some helpers ofc (to
get the payload_offset and anything else computed you might need).
But the basic drm_afbc_check_fb_size() should imo be done unconditionally
for any afbc modifier. To make sure we don't have lots of drivers with
different bugs in that thing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-07 8:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 11:18 [PATCH 0/2] AFBC for Rockchip Andrzej Pietrasiewicz
2019-10-11 11:18 ` [PATCH 1/2] drm/arm: Factor out generic afbc helpers Andrzej Pietrasiewicz
2019-10-21 13:50 ` Ayan Halder
2019-10-21 14:41 ` Mihail Atanassov
2019-11-04 22:12 ` [PATCHv2 0/4] AFBC support for Rockchip Andrzej Pietrasiewicz
2019-11-04 22:12 ` [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers Andrzej Pietrasiewicz
2019-11-05 9:22 ` Daniel Vetter
2019-11-06 12:45 ` Andrzej Pietrasiewicz
2019-11-07 8:27 ` Daniel Vetter [this message]
2019-11-05 23:26 ` Daniel Stone
2019-11-06 10:28 ` Liviu Dudau
2019-11-07 17:20 ` Brian Starkey
2019-11-07 17:32 ` Daniel Vetter
2019-11-07 17:49 ` Brian Starkey
2019-11-07 19:28 ` Daniel Vetter
2019-11-08 9:46 ` Brian Starkey
2019-11-04 22:12 ` [PATCHv2 2/4] drm/malidp: use " Andrzej Pietrasiewicz
2019-11-06 11:09 ` Liviu Dudau
2019-11-04 22:12 ` [PATCHv2 3/4] drm/komeda: " Andrzej Pietrasiewicz
2019-11-08 16:09 ` Ayan Halder
2019-11-13 2:01 ` james qian wang (Arm Technology China)
2019-11-13 11:39 ` Daniel Vetter
2019-11-14 1:52 ` james qian wang (Arm Technology China)
2019-11-14 10:12 ` Daniel Vetter
2019-11-18 7:09 ` james qian wang (Arm Technology China)
2019-11-18 9:51 ` Daniel Vetter
[not found] ` <20191118095136.GC23790-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-11-19 8:34 ` james qian wang (Arm Technology China)
2019-11-04 22:12 ` [PATCHv2 4/4] drm/rockchip: Add support for afbc Andrzej Pietrasiewicz
2019-11-05 23:34 ` Daniel Stone
2019-10-11 11:18 ` [PATCH 2/2] " Andrzej Pietrasiewicz
2019-10-11 11:59 ` Daniel Stone
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=20191107082733.GI23790@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Ayan.Halder@arm.com \
--cc=airlied@linux.ie \
--cc=andrzej.p@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=james.qian.wang@arm.com \
--cc=kernel@collabora.com \
--cc=linux-rockchip@lists.infradead.org \
--cc=liviu.dudau@arm.com \
--cc=mihail.atanassov@arm.com \
--cc=sean@poorly.run \
/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;
as well as URLs for NNTP newsgroup(s).