On Tue, Nov 26, 2019 at 09:27:59PM +0100, Andrzej Pietrasiewicz wrote:
> Hi Daniel,
>
> Thanks for the comments, please see inline
>
> W dniu 25.11.2019 o 09:55, Daniel Vetter pisze:
> > On Thu, Nov 21, 2019 at 06:22:44PM +0100, Andrzej Pietrasiewicz wrote:
> > > These are useful for other users of afbc, e.g. rockchip.
> > >
> > > Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@xxxxxxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/Makefile | 2 +-
> > > drivers/gpu/drm/drm_afbc.c | 84 +++++++++++++++++++++++++++++++
> > > drivers/gpu/drm/drm_fourcc.c | 11 +++-
> > > drivers/gpu/drm/drm_framebuffer.c | 71 +++++++++++++++++++++++++-
> > > include/drm/drm_afbc.h | 35 +++++++++++++
> > > 5 files changed, 199 insertions(+), 4 deletions(-)
> > > create mode 100644 drivers/gpu/drm/drm_afbc.c
> > > create mode 100644 include/drm/drm_afbc.h
> > >
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index d9bcc9f2a0a4..3a58f30b83a6 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -44,7 +44,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper
> > > drm_simple_kms_helper.o drm_modeset_helper.o \
> > > drm_scdc_helper.o drm_gem_framebuffer_helper.o \
> > > drm_atomic_state_helper.o drm_damage_helper.o \
> > > - drm_format_helper.o drm_self_refresh_helper.o
> > > + drm_format_helper.o drm_self_refresh_helper.o drm_afbc.o
> >
> > Just a quick drive-by:
> > - you can't put this into helpers and call from core code. This should be
> > core code. Also, I'd have just stuffed it into drm_format.c.
> >
>
> drm_format.c does not exist. Did you mean drm_format_helper.c?
drm_fourcc.c. You can't put this into a helper and call it from core code,
it wont link for modular builds.
> <snip>
>
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > > index 57564318ceea..303eea624a02 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -23,6 +23,7 @@
> > > #include <linux/export.h>
> > > #include <linux/uaccess.h>
> > > +#include <drm/drm_afbc.h>
> > > #include <drm/drm_atomic.h>
> > > #include <drm/drm_atomic_uapi.h>
> > > #include <drm/drm_auth.h>
> > > @@ -31,6 +32,7 @@
> > > #include <drm/drm_file.h>
> > > #include <drm/drm_fourcc.h>
> > > #include <drm/drm_framebuffer.h>
> > > +#include <drm/drm_gem.h>
> > > #include <drm/drm_print.h>
> > > #include <drm/drm_util.h>
> > > @@ -168,7 +170,69 @@ static int fb_plane_height(int height,
> > > return DIV_ROUND_UP(height, format->vsub);
> > > }
> > > +static int afbc_check(struct drm_file *file_priv,
> > > + const struct drm_mode_fb_cmd2 *r, int i,
> > > + const struct drm_format_info *info)
> > > +{
> > > + struct drm_gem_object *obj;
> > > + int bpp = info->cpp[0] * 8;
> > > + int tiles;
> > > + u32 w, h, height, tile_sz, afbc_size;
> > > + int result = 0;
> > > +
> > > + if (i) {
> > > + DRM_DEBUG_KMS("AFBC supported only for plane 0\n");
> > > +
> > > + return 1;
> > > + }
> > > +
> > > + /* get tile w/h */
> > > + if (!drm_afbc_get_superblk_wh(r->modifier[0], &w, &h))
> > > + return 1;
> > > +
> > > + /* pitch must be divisible by tile width */
> > > + if (r->pitches[0] % w) {
> > > + DRM_DEBUG_KMS("Invalid pitch for plane %d\n", i);
> > > +
> > > + return 1;
> > > + }
> > > +
> > > + obj = drm_gem_object_lookup(file_priv, r->handles[0]);
> >
> > I think this is a bit ugly ... I'd split this into a new
> > framebuffer_check_post() function which is called after fb_create, at that
> > point you do have the objects already looked up.
> >
> > Also I suggested that this could be done as a helper implementation for
> > fb_create, wrapping it around the default gem implementation. That way you
> > could keep all the afbc stuff in helpers entirely (but drivers could screw
> > things up, so there's a tradeoff).
> >
> > What's definitely not ok is calling drm_gem_object_lookup unconditionally
> > from core code here. For consistency I think the helper approach would be
> > good, since currently the size related checks are done in
> > drm_gem_fb_create() - i.e. in the helpers, not in core. Otoh having checks
> > split like this is also ugly, so maybe we should have a
> > framebuffer_check_post for everyone, and move all the size checks into
> > core (not just for afbc).
> > -Daniel
>
> As far as I understand you see more than one way forward.
> Can you please comment on the below? And in particular, can you say
> if I understood you correctly? So, my understanding of what you
> said above is to either:
>
> 1) move the part of the code which requires objects to be looked up
> to a new framebuffer_check_post() called after fb_create, that is
> from drm_internal_framebuffer_create() after
>
> fb = dev->mode_config.funcs->fb_create(dev, file_priv, r);
>
> because at that point the objects have already been looked up.
> How driver-specific checks can be done in this scheme?
Yup that's one way of doing it. Still feels a bit icky.
> or
>
> 2) Move the body of afbc_check() to a helper implementation to be used by
> driver-specific fb_create implementations. Sorry for my ignorance, it seems
> that "helpers" and "core" have precise meaning here but I don't quite
> understand what is what of what, so I also don't quite understand where
> to move the code to and why this would mean keeping all the afbc stuff
> entirely in helpers :O Can you explain?
That's the 2nd option, where 2a would be putting the checks into
drm_gem_fb_create_with_funcs(). That would at least be consistent with the
existing placement of size related checks we have.
For more context on core vs midlayer:
https://blog.ffwll.ch/2016/12/midlayers-once-more-with-feeling.html
The first few paragraphs have a pile of links with what this means for
kernel hackers.
In this case specifically the choice of using gem as backing storage for
drm_framebuffer is up to drivers, and hence anything gem related should be
in opt-in helpers. Although we only have 1 driver not using gem, so we
standardized this a lot and somewhat muddied the core/helper separation
here. Still, we should at least try to be consistent across the different
formats and checks.
> Did you mean that all the checking code is called by specific drivers
> on an opt-in basis? I thought you were not in favor of drivers opting-in,
> as some of them might opt-in while some others opt-out, or use different
> subsets of available checks.
>
> or
>
> 3) e.g. rockchip does not use drm_gem_fb_create(). It uses
> drm_gem_fb_create_handle(), though. Anyway, the third way forward
> is to have framebuffer_check_post() as in 1) and move the size checks
> to "core" - which I don't quite understand where exactly it is.
> What is the difference to 1)?
create_handle is a different ioctl, it's called from the GETFB ioctl. We'd
need to move the fb_create hook over to helpers for rockchip, and you're
lucky, I have a patch for you:
"drm/rockchip: Use drm_gem_fb_create_with_dirty"
Can you pls review/test that one?
Thanks, Daniel
>
> >
> > > + if (!obj) {
> > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > > +
> > > + return 1;
> > > + }
> > > +
> > > + /* estimate height based on tile size and height from userspace */
> > > + height = DIV_ROUND_UP(r->height, h) * h;
> > > +
> > > + tiles = (r->pitches[0] / w) * (height / h);
> > > + afbc_size = ALIGN(tiles * AFBC_HEADER_SIZE, AFBC_SUPERBLK_ALIGNMENT);
>
> This computation is for malidp/rockchip, but for komeda the alignment
> is different. So it seems it is driver-specific. If so, we need
> some way for specific drivers to provide their specific checks
> and/or specific data for generic checking code to use.
>
> Thanks
>
> Andrzej
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
