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@xxxxxxxxx> > > > > Just a small remark below, otherwise > > > > Acked-by: Thomas Zimmermann <tzimmermann@xxxxxxx> > > > > > > > --- > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
