Re: [PATCHv3/RFC 1/4] drm/arm: Factor out generic afbc helpers

[Andrzej Pietrasiewicz <andrzej.p@collabora.com>]

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@collabora.com>
>> ---
>>   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?

<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?

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?

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)?

> 
>> +	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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel