[PATCH 2/3] drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Wed, Jul 27, 2016 at 11:59:10AM +0200, Stefan Christ wrote:
> Hi Daniel,
> 
> I finally found some time to look into this issue again.
> 
> On Fri, Jul 15, 2016 at 09:19:22AM +0200, Daniel Vetter wrote:
> > <snippet>
> > 
> > To roll new vfuncs out consistently I think it'd be great to create a
> > DRM_FB_HELPER_DEFAULT_OPS #define which sets all the fb_ops. Drivers can
> > then overwrite just what they need, e.g.
> > 
> > static struct fb_ops drm_fbdev_cma_ops = {
> > 	.owner		= THIS_MODULE,
> > 	DRM_FB_HELPER_DEFAULT_OPS,
> > 	.fb_mmap 	= drm_fb_cma_mmap,
> > };
> > 
> > Maybe even include the .owner = THIS_MODULE line in the macro, but that
> > might be too much magic and mislead people into reusing it when it's not
> > the same module.
> > 
> > Of course this would be an additional (subsystem-wide) prep patch before
> > this one here.
> > -Daniel
> 
> Ok. This pattern seems like single inheritance in object-oriented programming
> languages ;-) The define looks very reasonable since these drm helper functions
> are used in lot of drivers.
> 
> I would also not include '.owner = THIS_MODULE' in the define, because it would
> contain even more magic.

Agreed, that's why I left it out in the example.

> What is the preferred way for subsystem-wide patches? One big patch, one patch
> per driver or group of drivers per patch?

Since this patch is not a flag day I'd say 1 patch to create the #define,
1 patch per driver (with maintainers/mailing lists per
scripts/get_maintainers.pl on cc) for each driver. It's a bit busy work,
but easiest to do that way. For flag-day changes you kinda have to do 1
huge patch, but that easily runs into cc limits of various mailing lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch