On Fri, Nov 29, 2019 at 10:34:10AM +0100, Thomas Zimmermann wrote:
Hi
Am 27.11.19 um 19:00 schrieb Daniel Vetter:
We're doing a great job for really simple drivers right now, but still a lot of boilerplate for the bigger ones.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Just a small remark below, otherwise
Acked-by: Thomas Zimmermann tzimmermann@suse.de
Documentation/gpu/todo.rst | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 3ec509381fc5..2d85f37284a1 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -182,6 +182,32 @@ Contact: Maintainer of the driver you plan to convert
Level: Intermediate
+drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup +-----------------------------------------------------------------
+A lot more drivers could be switched over to the drm_gem_framebuffer helpers. +Various hold-ups:
+- Need to switch over to the generic dirty tracking code using
- drm_atomic_helper_dirtyfb first (e.g. qxl).
+- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
- setup code can't be deleted.
From what I remember, almost all of the obvious, low-hanging fruits have been picked here. The remaining fbdev users either have HW acceleration (nouveau, gma500), or use the cfb drawing functions.
I think a bunch of these (from you) aren't merged yet. I'll add a note about sys vs cfb. About gma500/nouveau, I'm kinda tempted to just ditch the acceleration ... but maybe someone cares, dunno.
The TODO item should probably mention this, with some advise to do some extra testing for compatibility or performance after moving to generic fbdev.
Testing (at least on x86) won't catch the cfb/sysfb stuff, since it's exactly the same asm instructions :-/ tbh I still don't know where this actually makes a difference. -Daniel
Best regards Thomas
+- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
- atomic drivers we could check for valid formats by calling
- drm_plane_check_pixel_format() against all planes, and pass if any plane
- supports the format. For non-atomic that's not possible since like the format
- list for the primary plane is fake and we'd therefor reject valid formats.
+- Many drivers subclass drm_framebuffer, we'd need a embedding compatible
- version of the varios drm_gem_fb_create functions. Maybe called
- drm_gem_fb_create/_with_dirty/_with_funcs as needed.
+Contact: Daniel Vetter
+Level: Intermediate
Clean up mmap forwarding
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer