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: [Intel-gfx] [RFC 2/7] drm: allow drm_wait_vblank_kernel() callback from workqueues
Date: Thu, 4 Dec 2014 16:34:35 -0800 [thread overview]
Message-ID: <20141205003435.GA962@intel.com> (raw)
In-Reply-To: <1416426435-2237-4-git-send-email-przanoni@gmail.com>
On Wed, Nov 19, 2014 at 05:47:10PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> This is going to be needed by i915.ko, and I guess other drivers could
> use it too.
You may want to explain what we plan to use this for in i915 so that
other driver developers will more easily see where it might apply to
their own drivers.
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
> drivers/gpu/drm/drm_irq.c | 46 ++++++++++++++++++++++++++++++++-----
> drivers/gpu/drm/i915/i915_debugfs.c | 45 ++++++++++++++++++++++++++++--------
> include/drm/drmP.h | 11 ++++++++-
> 3 files changed, 86 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index f031f77..099aef1 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1108,6 +1108,22 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_crtc_wait_one_vblank);
>
> +static void drm_wait_vblank_callback(struct drm_device *dev,
> + struct drm_pending_vblank_event *e,
> + unsigned long seq, struct timeval *now,
> + bool premature)
> +{
> + if (e->callback_from_work) {
> + e->callback_args.dev = dev;
> + e->callback_args.seq = seq;
> + e->callback_args.now = now;
> + e->callback_args.premature = premature;
> + schedule_work(&e->callback_work);
As I noted on your alternative implementation, do we need to let the
driver choose the workqueue it wants to wait on? We're always going to
use the system workqueue here, but some places in i915 already use a
private workqueue.
> + } else {
> + e->callback(dev, e, seq, now, premature);
> + }
> +}
> +
...
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 39d0d87..bc114f0 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -669,7 +669,16 @@ struct drm_pending_vblank_event {
> struct drm_pending_event base;
> int pipe;
> struct drm_event_vblank event;
> +
> drm_vblank_callback_t callback;
> + bool callback_from_work;
> + struct work_struct callback_work;
> + struct {
> + struct drm_device *dev;
> + unsigned long seq;
> + struct timeval *now;
Do we need seq and now here? We still have access to the
drm_pending_vblank_event in our callback, so can't we just use the
fields we already have in e->event?
Also, do we need dev for something specific? Can't the driver just grab
that from its user_data structure?
Matt
> + bool premature;
> + } callback_args;
> };
>
> struct drm_vblank_crtc {
> @@ -906,7 +915,7 @@ extern int drm_vblank_init(struct drm_device *dev, int num_crtcs);
> extern int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp);
> extern int drm_wait_vblank_kernel(struct drm_crtc *crtc, int count,
> - bool absolute,
> + bool absolute, bool callback_from_work,
> drm_vblank_callback_t callback,
> unsigned long user_data);
> extern u32 drm_vblank_count(struct drm_device *dev, int crtc);
> --
> 2.1.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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-05 0:34 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
2014-11-19 19:47 ` [RFC 2/7] drm: allow drm_wait_vblank_kernel() callback from workqueues Paulo Zanoni
2014-12-05 0:34 ` Matt Roper [this message]
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=20141205003435.GA962@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox