From: Stefan Christ <s.christ@phytec.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC
Date: Wed, 27 Jul 2016 11:59:10 +0200 [thread overview]
Message-ID: <20160727095909.GD3449@lws-christ> (raw)
In-Reply-To: <20160715071922.GM17101@phenom.ffwll.local>
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.
What is the preferred way for subsystem-wide patches? One big patch, one patch
per driver or group of drivers per patch?
Mit freundlichen Grüßen / Kind regards,
Stefan Christ
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-07-27 9:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 8:11 [PATCH 0/3] Support fast framebuffer panning for i.MX6 Stefan Christ
2016-07-13 8:11 ` [PATCH 1/3] drm/cma-helper: Add multi buffer support for cma fbdev Stefan Christ
2016-07-13 10:05 ` Daniel Vetter
2016-07-13 8:11 ` [PATCH 2/3] drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC Stefan Christ
2016-07-13 10:16 ` Daniel Vetter
2016-07-15 7:19 ` Daniel Vetter
2016-07-27 9:59 ` Stefan Christ [this message]
2016-07-27 13:09 ` Daniel Vetter
2016-07-13 8:11 ` [PATCH 3/3] drm/imx: ipuv3-crtc: implement fast path mode_set_base Stefan Christ
2016-07-13 10:00 ` [PATCH 0/3] Support fast framebuffer panning for i.MX6 Daniel Vetter
2016-07-14 15:11 ` Stefan Christ
2016-07-15 7:14 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160727095909.GD3449@lws-christ \
--to=s.christ@phytec.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.