From: Matt Roper <matthew.d.roper@intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org,
Paulo Zanoni <paulo.r.zanoni@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC 1/7] drm: allow the drivers to call the vblank IOCTL internally
Date: Tue, 2 Dec 2014 18:14:25 -0800 [thread overview]
Message-ID: <20141203021425.GM10216@intel.com> (raw)
In-Reply-To: <1416426435-2237-3-git-send-email-przanoni@gmail.com>
On Wed, Nov 19, 2014 at 05:47:09PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> The i915.ko driver needs a way to schedule certain functions to run
> after some amount of vblanks. There are many different pieces of the
> driver which could benefit from that.
>
> Since what we want is essentially the vblank ioctl, this patch does
> the minimum change required to allow this ioctl to be called
> internally. The noticeable thing here is that the drivers pass a
> callback function, which is called by drm.ko after the specified
> amount of vblanks passes.
>
> The great benefit of this minimal change is that all the code
> responsible for taking care of properly emptying the queues (e.g.,
> when the CRTC is disabled) is already there, so we don't need to
> rewrite it.
>
> The current wait vblank IOCTL is now implemented on top of these
> changes, and it provides its own callback: send_vblank_event().
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
...
> +
> +int drm_wait_vblank_kernel(struct drm_crtc *crtc, int count, bool absolute,
> + drm_vblank_callback_t callback,
> + unsigned long user_data)
> +{
> + struct drm_device *dev = crtc->dev;
> + union drm_wait_vblank vblwait;
> + int type = 0;
> +
> + type |= absolute ? _DRM_VBLANK_ABSOLUTE : _DRM_VBLANK_RELATIVE;
> + type |= drm_crtc_index(crtc) << _DRM_VBLANK_HIGH_CRTC_SHIFT;
> + if (callback)
> + type |= _DRM_VBLANK_EVENT;
Need some kerneldoc on this function. It looks like if we have a NULL
callback this turns into a more general version of drm_wait_one_vblank()
that can handle arbitrary delay counts, right? Is there a case where a
multi-vblank wait would be useful internal to the kernel? If not, it
might be worth just returning failure on that case for now until we have
an actual caller.
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-12-03 2:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 19:47 [RFC 0/7+1] Add in-kernel vblank delaying mechanism Paulo Zanoni
2014-11-19 19:47 ` [RFC] drm: add a mechanism for drivers to schedule vblank callbacks Paulo Zanoni
2014-12-03 2:13 ` [Intel-gfx] " Matt Roper
2014-11-19 19:47 ` [RFC 1/7] drm: allow the drivers to call the vblank IOCTL internally Paulo Zanoni
2014-12-03 2:14 ` Matt Roper [this message]
2014-11-19 19:47 ` [RFC 2/7] drm: allow drm_wait_vblank_kernel() callback from workqueues Paulo Zanoni
2014-12-05 0:34 ` [Intel-gfx] " Matt Roper
2014-11-19 19:47 ` [RFC 3/7] drm: introduce struct drm_vblank_wait_item Paulo Zanoni
2014-12-05 2:27 ` Matt Roper
2014-11-19 19:47 ` [RFC 4/7] drm: add wanted_seq to drm_vblank_wait_item Paulo Zanoni
2014-11-19 19:47 ` [RFC 5/7] drm: change the drm vblank callback item type Paulo Zanoni
2014-11-19 19:47 ` [RFC 6/7] drm: make vblank_event_list handle drm_vblank_wait_item types Paulo Zanoni
2014-12-05 2:27 ` [Intel-gfx] " Matt Roper
2014-11-19 19:47 ` [RFC 7/7] drm: make the callers of drm_wait_vblank() allocate the memory Paulo Zanoni
2014-11-26 17:19 ` [RFC 0/7+1] Add in-kernel vblank delaying mechanism Daniel Vetter
2014-11-26 23:25 ` Dave Airlie
2014-11-27 10:06 ` Daniel Vetter
2014-12-04 17:09 ` 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=20141203021425.GM10216@intel.com \
--to=matthew.d.roper@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=przanoni@gmail.com \
/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.