Re: [RFC 1/7] drm: allow the drivers to call the vblank IOCTL internally

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