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 <[email protected]>
---
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
