[PATCH 3/3] drm/todo: Add entry for fb funcs related cleanups

[Daniel Vetter]

On Fri, Nov 29, 2019 at 07:57:39PM +0100, Daniel Vetter wrote:
> 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 at intel.com>
> > 
> > Just a small remark below, otherwise
> > 
> > Acked-by: Thomas Zimmermann <tzimmermann at 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.

Correction, we already have a task for drm_fbdev_generic_setup, and that
mentions the sys/cfb issue already. So I'll leave this as-is.
-Daniel

> 
> > 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
> > 
> 
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch