Add in-kernel vblank delaying mechanism

From: Paulo Zanoni <[email protected]>

The drivers need a way to schedule functions to be ran after a certain number of vblanks. The i915.ko driver has plenty of examples where this could be used, such as for unpinning buffers after a modeset. Since the vblank wait IOCTL does basically what we want, but for the user space, in this patch we add a new list of vblank events (dev->vblank_kernel_list) and handle it exactly like we handle the user space events.

Signed-off-by Paulo Zanoni <[email protected]>

---
 drivers/gpu/drm/drm_drv.c           |   1 +
 drivers/gpu/drm/drm_irq.c           | 106 ++++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/i915_debugfs.c |  81 +++++++++++++++++++++++++++
 include/drm/drmP.h                  |  22 ++++++++
 4 files changed, 206 insertions(+), 4 deletions(-)

drivers/gpu/drm/drm_drv.c +1 -0

index 2e5c7d9..b5ae6c8 100644
@@ -557,6 +557,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
 	INIT_LIST_HEAD(&dev->vmalist);
 	INIT_LIST_HEAD(&dev->maplist);
 	INIT_LIST_HEAD(&dev->vblank_event_list);
+	INIT_LIST_HEAD(&dev->vblank_kernel_list);
 
 	spin_lock_init(&dev->buf_lock);
 	spin_lock_init(&dev->event_lock);

drivers/gpu/drm/drm_irq.c +0 -0

index 0e47df4..6e04035 100644

drivers/gpu/drm/drm_irq.c +18 -2

 /**
  * drm_vblank_off - disable vblank events on a CRTC
  * @dev: DRM device

@@ -1124,7 +1131,8 @@ EXPORT_SYMBOL(drm_crtc_wait_one_vblank);
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
 	struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
-	struct drm_pending_vblank_event *e, *t;
+	struct drm_pending_vblank_event *e, *et;
+	struct drm_kernel_vblank_item *i, *it;
 	struct timeval now;
 	unsigned long irqflags;
 	unsigned int seq;

@@ -1151,7 +1159,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
 	/* Send any queued vblank events, lest the natives grow disquiet */
 	seq = drm_vblank_count_and_time(dev, crtc, &now);
 
-	list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
+	list_for_each_entry_safe(e, et, &dev->vblank_event_list, base.link) {
 		if (e->pipe != crtc)
 			continue;
 		DRM_DEBUG("Sending premature vblank event on disable: \

@@ -1161,6 +1169,21 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
 		drm_vblank_put(dev, e->pipe);
 		send_vblank_event(dev, e, seq, &now);
 	}
+
+	list_for_each_entry_safe(i, it, &dev->vblank_kernel_list, link) {
+		int pipe = drm_crtc_index(i->crtc);
+
+		if (pipe != crtc)
+			continue;
+
+		DRM_DEBUG("Sending premature kernel vblank event on disable: \
+			  wanted %d, current %d\n",
+			  i->target_seq, seq);
+		i->premature = true;
+		list_del(&i->link);
+		drm_vblank_put(dev, pipe);
+		send_kernel_vblank_event(i);
+	}
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_vblank_off);

@@ -1560,9 +1583,68 @@ done:
 	return ret;
 }
 

drivers/gpu/drm/drm_irq.c +45 -2

+		item->target_seq += seq;
+
+	spin_lock_irqsave(&dev->event_lock, irqflags);
+
+	if (!vblank->enabled) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (seq - item->target_seq <= (1 << 23)) {
+		drm_vblank_put(dev, pipe);
+		send_kernel_vblank_event(item);
+	} else {
+		list_add_tail(&item->link, &dev->vblank_kernel_list);
+	}
+
+	spin_unlock_irqrestore(&dev->event_lock, irqflags);
+	return 0;
+
+out:
+	spin_unlock_irqrestore(&dev->event_lock, irqflags);
+	drm_vblank_put(dev, pipe);
+	return ret;
+}
+EXPORT_SYMBOL(drm_wait_vblank_kernel);
+
 static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 {
-	struct drm_pending_vblank_event *e, *t;
+	struct drm_pending_vblank_event *e, *et;
+	struct drm_kernel_vblank_item *i, *it;
 	struct timeval now;
 	unsigned int seq;
 

@@ -1570,7 +1652,7 @@ static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 
 	seq = drm_vblank_count_and_time(dev, crtc, &now);
 
-	list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
+	list_for_each_entry_safe(e, et, &dev->vblank_event_list, base.link) {
 		if (e->pipe != crtc)
 			continue;
 		if ((seq - e->event.sequence) > (1<<23))

@@ -1584,6 +1666,22 @@ static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 		send_vblank_event(dev, e, seq, &now);
 	}
 
+	list_for_each_entry_safe(i, it, &dev->vblank_kernel_list, link) {
+		int pipe = drm_crtc_index(i->crtc);
+
+		if (pipe != crtc)
+			continue;
+		if ((seq - i->target_seq) > (1<<23))
+			continue;
+
+		DRM_DEBUG("kernel vblank event on %d, current %d\n",
+			  i->target_seq, seq);
+
+		list_del(&i->link);
+		drm_vblank_put(dev, pipe);
+		send_kernel_vblank_event(i);
+	}
+
 	trace_drm_vblank_event(crtc, seq);
 }
 

drivers/gpu/drm/i915/i915_debugfs.c +81 -0

index 319da61..e705976 100644
@@ -2715,6 +2715,86 @@ static int i915_ddb_info(struct seq_file *m, void *unused)
 	return 0;
 }
 
+struct vblank_data {
+	int eight;
+	const char *message;
+	struct drm_kernel_vblank_item item;
+};
+
+static void vblank_callback(struct drm_kernel_vblank_item *item)
+{
+	struct vblank_data *data = container_of(item, struct vblank_data, item);
+
+	WARN_ON(data->eight != 8);
+	WARN_ON(item->callback_from_work != drm_can_sleep());
+	DRM_DEBUG_KMS("vblank callback, premature: %s, message: %s\n",
+		      yesno(item->premature), data->message);
+
+	kfree(data);
+}
+
+static int i915_vblank_queue_test_new(struct seq_file *m, void *unused)
+{
+	struct drm_info_node *node = m->private;
+	struct drm_device *dev = node->minor->dev;
+	struct intel_crtc *crtc = NULL;
+	int ret = 0;
+	struct vblank_data *data1, *data2;
+
+	for_each_intel_crtc(dev, crtc)
+		if (crtc->pipe == PIPE_A)
+			break;
+	if (WARN_ON(!crtc))
+		return -EINVAL;
+
+	data1 = kzalloc(sizeof *data1, GFP_KERNEL);
+	if (!data1)
+		return -ENOMEM;
+
+	data2 = kzalloc(sizeof *data2, GFP_KERNEL);
+	if (!data2) {
+		kfree(data1);
+		return -ENOMEM;
+	}
+
+	data1->message = "hello world (atomic)";
+	data1->eight = 8;
+	data1->item.crtc = &crtc->base;
+	data1->item.target_seq = 60;
+	data1->item.absolute = false;
+	data1->item.callback = vblank_callback;
+	data1->item.callback_from_work = false;
+
+	data2->message = "hello world (work)";
+	data2->eight = 8;
+	data2->item.crtc = &crtc->base;
+	data2->item.target_seq = 60;
+	data2->item.absolute = false;
+	data2->item.callback = vblank_callback;
+	data2->item.callback_from_work = true;
+
+	DRM_DEBUG_KMS("scheduling 60 vblanks (no work)\n");
+	ret = drm_wait_vblank_kernel(&data1->item);
+	if (ret) {
+		DRM_DEBUG_KMS("vblank schedule error: %d\n", ret);
+		kfree(data1);
+		kfree(data2);
+		return ret;
+	}
+	DRM_DEBUG_KMS("vblanks scheduled\n");
+
+	DRM_DEBUG_KMS("scheduling 60 vblanks (with work)\n");
+	ret = drm_wait_vblank_kernel(&data2->item);
+	if (ret) {
+		DRM_DEBUG_KMS("vblank schedule error: %d\n", ret);
+		kfree(data2);
+		return ret;
+	}
+	DRM_DEBUG_KMS("vblanks scheduled\n");
+
+	return 0;
+}
+
 struct pipe_crc_info {
 	const char *name;
 	struct drm_device *dev;

@@ -4289,6 +4369,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
 	{"i915_dp_mst_info", i915_dp_mst_info, 0},
 	{"i915_wa_registers", i915_wa_registers, 0},
 	{"i915_ddb_info", i915_ddb_info, 0},
+	{"i915_vblank_queue_test_new", i915_vblank_queue_test_new, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
 

include/drm/drmP.h +22 -0

index be776fb..295d0e0 100644
@@ -667,6 +667,26 @@ struct drm_pending_vblank_event {
 	struct drm_event_vblank event;
 };
 
+struct drm_kernel_vblank_item {
+	/* Internal members, set by drm.ko. */
+	struct list_head link;
+	struct work_struct work;
+
+	/* Parameters: set by the caller of drm_wait_vblank_kernel(). */
+	struct drm_crtc *crtc;
+
+	int target_seq;
+	bool absolute; /* Tells if target_seq is a relative offset to the
+			* current vblank count, or just an absolute value. */
+
+	void (*callback)(struct drm_kernel_vblank_item *item);
+
+	bool callback_from_work;
+
+	/* Output: to be used by the callback function. */
+	bool premature;
+};
+
 struct drm_vblank_crtc {
 	struct drm_device *dev;		/* pointer to the drm_device */
 	wait_queue_head_t queue;	/**< VBLANK wait queue */

@@ -784,6 +804,7 @@ struct drm_device {
 	 * List of events
 	 */
 	struct list_head vblank_event_list;
+	struct list_head vblank_kernel_list;
 	spinlock_t event_lock;
 
 	/*@} */

@@ -900,6 +921,7 @@ extern int drm_irq_uninstall(struct drm_device *dev);
 extern int drm_vblank_init(struct drm_device *dev, int num_crtcs);
 extern int drm_wait_vblank(struct drm_device *dev, void *data,
 			   struct drm_file *filp);
+extern int drm_wait_vblank_kernel(struct drm_kernel_vblank_item *item);
 extern u32 drm_vblank_count(struct drm_device *dev, int crtc);
 extern u32 drm_vblank_count_and_time(struct drm_device *dev, int crtc,
 				     struct timeval *vblanktime);

Signature · 6 lines

2.1.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

From: Paulo Zanoni <[email protected]>

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 <[email protected]>

---

From: Paulo Zanoni <[email protected]>

This is going to be needed by i915.ko, and I guess other drivers could use it too.

Signed-off-by Paulo Zanoni <[email protected]>

---
 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(-)

drivers/gpu/drm/drm_irq.c +1 -0

index f031f77..099aef1 100644
@@ -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,

drivers/gpu/drm/drm_irq.c +5 -0

+	} else {
+		e->callback(dev, e, seq, now, premature);
+	}
+}
+

include/drm/drmP.h +0 -0

index 39d0d87..bc114f0 100644
@@ -669,7 +669,16 @@ struct drm_pending_vblank_event {
 	struct drm_pending_event base;

include/drm/drmP.h +3 -1

+		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);

Signature · 6 lines

2.1.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

From: Paulo Zanoni <[email protected]>

It's supposed to contain all the information that is required for both kernel and user space vblank wait items, but not hold any information required by just one of them.

For now, we just moved the struct members from one place to another, but the long term goal is that most of the drm.ko code will only handle "struct drm_vblank_wait_item", not knowing anything else. This will allow the callers to wrap this struct in their own private structures. This will happen in the next patches.

Signed-off-by Paulo Zanoni <[email protected]>

include/drm/drmP.h +6 -0

 	drm_vblank_callback_t callback;
 	bool callback_from_work;

@@ -681,6 +679,12 @@ struct drm_pending_vblank_event {
 	} callback_args;
 };
 
+struct drm_pending_vblank_event {
+	struct drm_pending_event base;
+	struct drm_event_vblank event;
+	struct drm_vblank_wait_item item;
+};
+
 struct drm_vblank_crtc {
 	struct drm_device *dev;		/* pointer to the drm_device */
 	wait_queue_head_t queue;	/**< VBLANK wait queue */

Signature · 6 lines

2.1.1

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

From: Paulo Zanoni <[email protected]>

Which means the list doesn't really need to know if the event is from user space or kernel space.

The only place here where we have to break the abstraction is at drm_fops, when we're releasing all the events associated with a file_priv. Here we introduced item.from_user_space, that needs to be checked before we transform the item pointer into the appropriate drm_pending_vblank_event pointer. Other strategies to solve this problem - instead of adding item->from_user_space - would be to: (i) store a copy of the file_priv pointer in the drm_vblank_wait_item structure, but then we'd also need a custom destroy() function; or (ii) add file_priv->pending_event_list, but then we'd have to keep all the user space items in sync with dev->vblank_event_list, which could lead to complicated code.

Signed-off-by Paulo Zanoni <[email protected]>

---
 drivers/gpu/drm/drm_fops.c | 15 +++++++++++----
 drivers/gpu/drm/drm_irq.c  | 33 +++++++++++++++++----------------
 include/drm/drmP.h         |  4 +++-
 3 files changed, 31 insertions(+), 21 deletions(-)

drivers/gpu/drm/drm_fops.c +11 -4

index 47c5e58..fbdbde2 100644
@@ -280,18 +280,25 @@ static void drm_events_release(struct drm_file *file_priv)
 {
 	struct drm_device *dev = file_priv->minor->dev;
 	struct drm_pending_event *e, *et;
-	struct drm_pending_vblank_event *v, *vt;
+	struct drm_vblank_wait_item *i, *it;
 	unsigned long flags;
 
 	spin_lock_irqsave(&dev->event_lock, flags);
 
 	/* Remove pending flips */
-	list_for_each_entry_safe(v, vt, &dev->vblank_event_list, base.link)
+	list_for_each_entry_safe(i, it, &dev->vblank_event_list, link) {
+		struct drm_pending_vblank_event *v;
+
+		if (!i->from_user_space)
+			continue;
+
+		v = container_of(i, struct drm_pending_vblank_event, item);
 		if (v->base.file_priv == file_priv) {
-			list_del(&v->base.link);
-			drm_vblank_put(dev, v->item.pipe);
+			list_del(&i->link);
+			drm_vblank_put(dev, i->pipe);
 			v->base.destroy(&v->base);
 		}
+	}
 
 	/* Remove unconsumed events */
 	list_for_each_entry_safe(e, et, &file_priv->event_list, link) {

drivers/gpu/drm/drm_irq.c +17 -16

index 4c03240..dd091c3 100644
@@ -1144,7 +1144,7 @@ static void drm_wait_vblank_callback(struct drm_device *dev,
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
 	struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
-	struct drm_pending_vblank_event *e, *t;
+	struct drm_vblank_wait_item *i, *t;
 	struct timeval now;
 	unsigned long irqflags;
 	unsigned int seq;

@@ -1171,15 +1171,15 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
 	/* Send any queued vblank events, lest the natives grow disquiet */
 	seq = drm_vblank_count_and_time(dev, crtc, &now);
 
-	list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
-		if (e->item.pipe != crtc)
+	list_for_each_entry_safe(i, t, &dev->vblank_event_list, link) {
+		if (i->pipe != crtc)
 			continue;
 		DRM_DEBUG("Sending premature vblank event on disable: \
 			  wanted %d, current %d\n",
-			  e->item.wanted_seq, seq);
-		list_del(&e->base.link);
-		drm_vblank_put(dev, e->item.pipe);
-		drm_wait_vblank_callback(dev, &e->item, seq, &now, true);
+			 i->wanted_seq, seq);
+		list_del(&i->link);
+		drm_vblank_put(dev, i->pipe);
+		drm_wait_vblank_callback(dev, i, seq, &now, true);
 	}
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 }

@@ -1427,6 +1427,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
 	e->base.event = &e->event.base;
 	e->base.file_priv = file_priv;
 	e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
+	e->item.from_user_space = true;
 	e->item.callback = callback;
 	e->item.callback_from_work = callback_from_work;
 	if (callback_from_work)

@@ -1476,7 +1477,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
 		vblwait->reply.sequence = seq;
 	} else {
 		/* drm_handle_vblank_events will call drm_vblank_put */
-		list_add_tail(&e->base.link, &dev->vblank_event_list);
+		list_add_tail(&e->item.link, &dev->vblank_event_list);
 		vblwait->reply.sequence = vblwait->request.sequence;
 	}
 

@@ -1635,7 +1636,7 @@ EXPORT_SYMBOL(drm_wait_vblank_kernel);
 
 static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 {
-	struct drm_pending_vblank_event *e, *t;
+	struct drm_vblank_wait_item *i, *t;
 	struct timeval now;
 	unsigned int seq;
 

@@ -1643,18 +1644,18 @@ static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 
 	seq = drm_vblank_count_and_time(dev, crtc, &now);
 
-	list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
-		if (e->item.pipe != crtc)
+	list_for_each_entry_safe(i, t, &dev->vblank_event_list, link) {
+		if (i->pipe != crtc)
 			continue;
-		if ((seq - e->item.wanted_seq) > (1<<23))
+		if ((seq - i->wanted_seq) > (1<<23))
 			continue;
 
 		DRM_DEBUG("vblank event on %d, current %d\n",
-			  e->item.wanted_seq, seq);
+			  i->wanted_seq, seq);
 
-		list_del(&e->base.link);
-		drm_vblank_put(dev, e->item.pipe);
-		drm_wait_vblank_callback(dev, &e->item, seq, &now, false);
+		list_del(&i->link);
+		drm_vblank_put(dev, i->pipe);
+		drm_wait_vblank_callback(dev, i, seq, &now, false);
 	}
 
 	trace_drm_vblank_event(crtc, seq);

include/drm/drmP.h +3 -1

index 474c892..46724d9 100644
@@ -258,7 +258,7 @@ struct drm_ioctl_desc {
 /* Event queued up for userspace to read */
 struct drm_pending_event {
 	struct drm_event *event;
-	struct list_head link;
+	struct list_head link; /* file_priv->event_list */
 	struct drm_file *file_priv;
 	pid_t pid; /* pid of requester, no guarantee it's valid by the time
 		      we deliver the event, for tracing only */

@@ -668,8 +668,10 @@ typedef void (*drm_vblank_callback_t)(struct drm_device *dev,
 				      bool premature);
 
 struct drm_vblank_wait_item {
+	struct list_head link; /* dev->vblank_event_list */
 	int pipe;
 	unsigned int wanted_seq;
+	bool from_user_space;
 
 	drm_vblank_callback_t callback;
 	bool callback_from_work;

Signature · 6 lines

2.1.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

From: Paulo Zanoni <[email protected]>

Hi

---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---

So the i915.ko driver could use some mechanism to run functions after a given number of vblanks. Implementations for this mechanism were already proposed in the past (by Chris Wilson and others), but they were i915-specific instead of a generic drm.ko implementation. We even had patches that make use of this new mechanism.

Since this is very similar to the vblank IOCTL we currently have, but with the caller being a Kernel module instead of user space, I decided to write an implementation that tries to reuse the current IOCTL infrastructure.

In the first patch we add all the necessary code to allow the modules to call the vblank ioctl from Kernel space: they provide a callback function that is going to be called instead of the traditional send_vblank_event(), which means the Kernel callers don't have to deal with the file descriptors and DRM events.

In the second patch we add a simple extension of the feature, to allow the drivers to have their callbacks called in a non-atomic context.

In all the other subsequent patches we rework the underlying code so that the common aspects between the user space vblank IOCTL and the Kernel interface are all stored in a single structure (struct drm_vblank_wait_item), and then anything that is specific to the different users is stored in a structure that contains struct drm_vblank_wait_item. This way, most of the drm.ko code only needs to deal with struct drm_vblank_wait_item, not really knowing how it is wrapped. The advantage of this rework is that it reduces the number of memory allocations needed in some cases (from 2 to 1) and it also reduces the amount of memory used on each allocation.

But while this all sounds nice in the above description, I had the feeling that this adds a lot of complexity and makes the code not-so-beautiful. If we ever need more extensions/options to this feature, we're going to have to untangle the code even more from the IOCTL part. We also have a small "abstraction break" in change introduced in patch 6. And there's the risk that some of the reworks may have added a regression somewhere.

Based on that, I decided to also provide an alternative implementation. In this implementation we add a new dev->vblank_kernel_list instead of reusing dev->vblank_event_list, and add new code to handle that this. This new code is completely based on the code that handles dev->vblank_kernel_list, so there's some duplication here. On the other hand, since the in-Kernel infrastructure is not tied to the IOCTL structure, we can very easily grow and adapt the Kernel code without having to fight against the IOCTL code. And the risk of regressions is greatly reduced.

The second difference of this alternative implementation is the signature of the drm_wait_vblank_kernel() function. While it could be exactly the same as the one used in the other series, I decided to make it different so we can also choose which one to use. In the 7-patch series implementation, all the user needs to do is to allocate the structure, and call the function, properly setting all its arguments. Then the function is responsible for parsing the arguments and populating the structure based on that. On the alternative implementation, the user has to fill the structure with the appropriate arguments, and then call drm_wait_vblank_kernel() passing just the allocated structure as an argument.

If you notice, you will see that these patches add a new debugfs file to i915.ko. This file is just a very simple example user of the new interface, which I used while developing. If you have difficulty understanding the new interface, please also look at the i915/i915_debugfs.c diff. Of course, I plan to exclude this debugfs interface from the final to-be-merged patches.

So, in summary, we have a few things we need to discuss:

1. Which implementation to use?

a. Just the 2 first patches of the 7-patch series?
Pros:
- the Kernel users basically call the vblank IOCTL
- the code changes are minimal
Cons:
- The amount of memory allocations and memory space consumed is not optimal

b. The full 7-patch series?
Pros:
- The same backend is used for both the Kernel and IOCTL.
Cons:
- The code gets more complex.
- Extending the Kernel interface can get complicated due to the fact that it shares code with the IOCTL interface.
- I didn't really like this solution.

c. The alternative implementation I wrote?
Pros:
- It's independent from the IOCTL code, making further patches easier.
Cons:
- There is some duplicated code.

d. Something totally different from these alternatives?

2. How should the driver interface look like?

a. All the possibilities are passed through the function call, so the drm.ko
code needs to set the struct members itself.
b. The caller already sets the struct members instead of passing them as
parameters to the function.
c. Something different?

All these patches are based on top of Daniel Vetter's drm-intel-nightly tree. It's all just an RFC, so don't expect something very well tested.

Flamewars and bikeshedding are welcome!

Thanks,
Paulo

Paulo Zanoni (7):

- First implementation:
drm: allow the drivers to call the vblank IOCTL internally
drm: allow drm_wait_vblank_kernel() callback from workqueues
drm: introduce struct drm_vblank_wait_item
drm: add wanted_seq to drm_vblank_wait_item
drm: change the drm vblank callback item type
drm: make vblank_event_list handle drm_vblank_wait_item types
drm: make the callers of drm_wait_vblank() allocate the memory

- Alternative implementation:
drm: add a mechanism for drivers to schedule vblank callbacks

Stats for only the first implementation:

 drivers/gpu/drm/drm_fops.c          |  15 ++-
 drivers/gpu/drm/drm_ioctl.c         |   2 +-
 drivers/gpu/drm/drm_irq.c           | 178 ++++++++++++++++++++++++++----------
 drivers/gpu/drm/i915/i915_debugfs.c |  90 ++++++++++++++++++
 include/drm/drmP.h                  |  35 ++++++-
 5 files changed, 264 insertions(+), 56 deletions(-)

Signature · 6 lines

2.1.1

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 102 lines

---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---

So the i915.ko driver could use some mechanism to run functions after a given number of vblanks. Implementations for this mechanism were already proposed in the past (by Chris Wilson and others), but they were i915-specific instead of a generic drm.ko implementation. We even had patches that make use of this new mechanism.

Since this is very similar to the vblank IOCTL we currently have, but with the caller being a Kernel module instead of user space, I decided to write an implementation that tries to reuse the current IOCTL infrastructure.

In the first patch we add all the necessary code to allow the modules to call the vblank ioctl from Kernel space: they provide a callback function that is going to be called instead of the traditional send_vblank_event(), which means the Kernel callers don't have to deal with the file descriptors and DRM events.

In the second patch we add a simple extension of the feature, to allow the drivers to have their callbacks called in a non-atomic context.

In all the other subsequent patches we rework the underlying code so that the common aspects between the user space vblank IOCTL and the Kernel interface are all stored in a single structure (struct drm_vblank_wait_item), and then anything that is specific to the different users is stored in a structure that contains struct drm_vblank_wait_item. This way, most of the drm.ko code only needs to deal with struct drm_vblank_wait_item, not really knowing how it is wrapped. The advantage of this rework is that it reduces the number of memory allocations needed in some cases (from 2 to 1) and it also reduces the amount of memory used on each allocation.

But while this all sounds nice in the above description, I had the feeling that this adds a lot of complexity and makes the code not-so-beautiful. If we ever need more extensions/options to this feature, we're going to have to untangle the code even more from the IOCTL part. We also have a small "abstraction break" in change introduced in patch 6. And there's the risk that some of the reworks may have added a regression somewhere.

Based on that, I decided to also provide an alternative implementation. In this implementation we add a new dev->vblank_kernel_list instead of reusing dev->vblank_event_list, and add new code to handle that this. This new code is completely based on the code that handles dev->vblank_kernel_list, so there's some duplication here. On the other hand, since the in-Kernel infrastructure is not tied to the IOCTL structure, we can very easily grow and adapt the Kernel code without having to fight against the IOCTL code. And the risk of regressions is greatly reduced.

The second difference of this alternative implementation is the signature of the drm_wait_vblank_kernel() function. While it could be exactly the same as the one used in the other series, I decided to make it different so we can also choose which one to use. In the 7-patch series implementation, all the user needs to do is to allocate the structure, and call the function, properly setting all its arguments. Then the function is responsible for parsing the arguments and populating the structure based on that. On the alternative implementation, the user has to fill the structure with the appropriate arguments, and then call drm_wait_vblank_kernel() passing just the allocated structure as an argument.

If you notice, you will see that these patches add a new debugfs file to i915.ko. This file is just a very simple example user of the new interface, which I used while developing. If you have difficulty understanding the new interface, please also look at the i915/i915_debugfs.c diff. Of course, I plan to exclude this debugfs interface from the final to-be-merged patches.

So, in summary, we have a few things we need to discuss:

1. Which implementation to use?

a. Just the 2 first patches of the 7-patch series?
Pros:
- the Kernel users basically call the vblank IOCTL
- the code changes are minimal
Cons:
- The amount of memory allocations and memory space consumed is not optimal

b. The full 7-patch series?
Pros:
- The same backend is used for both the Kernel and IOCTL.
Cons:
- The code gets more complex.
- Extending the Kernel interface can get complicated due to the fact that it shares code with the IOCTL interface.
- I didn't really like this solution.

c. The alternative implementation I wrote?
Pros:
- It's independent from the IOCTL code, making further patches easier.
Cons:
- There is some duplicated code.

d. Something totally different from these alternatives?

2. How should the driver interface look like?

a. All the possibilities are passed through the function call, so the drm.ko
code needs to set the struct members itself.
b. The caller already sets the struct members instead of passing them as
parameters to the function.
c. Something different?

Quoted 4 lines

All these patches are based on top of Daniel Vetter's drm-intel-nightly tree. It's all just an RFC, so don't expect something very well tested.

Flamewars and bikeshedding are welcome!

As we've discussed on irc a bit I still think cleaning up this rathole is beneficial. Getting the event handling and vblank callbacks right just in drivers seems to be really hard, so better to clean this up and unify things.

But like you've said patches are a lot of churn, so do you have a git branch somewhere for the lazy to look at?

Thanks, Daniel

Quoted 112 lines

Quoted 102 lines

---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---

So the i915.ko driver could use some mechanism to run functions after a given number of vblanks. Implementations for this mechanism were already proposed in the past (by Chris Wilson and others), but they were i915-specific instead of a generic drm.ko implementation. We even had patches that make use of this new mechanism.

Since this is very similar to the vblank IOCTL we currently have, but with the caller being a Kernel module instead of user space, I decided to write an implementation that tries to reuse the current IOCTL infrastructure.

In the first patch we add all the necessary code to allow the modules to call the vblank ioctl from Kernel space: they provide a callback function that is going to be called instead of the traditional send_vblank_event(), which means the Kernel callers don't have to deal with the file descriptors and DRM events.

In the second patch we add a simple extension of the feature, to allow the drivers to have their callbacks called in a non-atomic context.

In all the other subsequent patches we rework the underlying code so that the common aspects between the user space vblank IOCTL and the Kernel interface are all stored in a single structure (struct drm_vblank_wait_item), and then anything that is specific to the different users is stored in a structure that contains struct drm_vblank_wait_item. This way, most of the drm.ko code only needs to deal with struct drm_vblank_wait_item, not really knowing how it is wrapped. The advantage of this rework is that it reduces the number of memory allocations needed in some cases (from 2 to 1) and it also reduces the amount of memory used on each allocation.

But while this all sounds nice in the above description, I had the feeling that this adds a lot of complexity and makes the code not-so-beautiful. If we ever need more extensions/options to this feature, we're going to have to untangle the code even more from the IOCTL part. We also have a small "abstraction break" in change introduced in patch 6. And there's the risk that some of the reworks may have added a regression somewhere.

Based on that, I decided to also provide an alternative implementation. In this implementation we add a new dev->vblank_kernel_list instead of reusing dev->vblank_event_list, and add new code to handle that this. This new code is completely based on the code that handles dev->vblank_kernel_list, so there's some duplication here. On the other hand, since the in-Kernel infrastructure is not tied to the IOCTL structure, we can very easily grow and adapt the Kernel code without having to fight against the IOCTL code. And the risk of regressions is greatly reduced.

The second difference of this alternative implementation is the signature of the drm_wait_vblank_kernel() function. While it could be exactly the same as the one used in the other series, I decided to make it different so we can also choose which one to use. In the 7-patch series implementation, all the user needs to do is to allocate the structure, and call the function, properly setting all its arguments. Then the function is responsible for parsing the arguments and populating the structure based on that. On the alternative implementation, the user has to fill the structure with the appropriate arguments, and then call drm_wait_vblank_kernel() passing just the allocated structure as an argument.

If you notice, you will see that these patches add a new debugfs file to i915.ko. This file is just a very simple example user of the new interface, which I used while developing. If you have difficulty understanding the new interface, please also look at the i915/i915_debugfs.c diff. Of course, I plan to exclude this debugfs interface from the final to-be-merged patches.

So, in summary, we have a few things we need to discuss:

1. Which implementation to use?

a. Just the 2 first patches of the 7-patch series?
Pros:
- the Kernel users basically call the vblank IOCTL
- the code changes are minimal
Cons:
- The amount of memory allocations and memory space consumed is not optimal

b. The full 7-patch series?
Pros:
- The same backend is used for both the Kernel and IOCTL.
Cons:
- The code gets more complex.
- Extending the Kernel interface can get complicated due to the fact that it shares code with the IOCTL interface.
- I didn't really like this solution.

c. The alternative implementation I wrote?
Pros:
- It's independent from the IOCTL code, making further patches easier.
Cons:
- There is some duplicated code.

d. Something totally different from these alternatives?

2. How should the driver interface look like?

a. All the possibilities are passed through the function call, so the drm.ko
code needs to set the struct members itself.
b. The caller already sets the struct members instead of passing them as
parameters to the function.
c. Something different?

Quoted 4 lines

All these patches are based on top of Daniel Vetter's drm-intel-nightly tree. It's all just an RFC, so don't expect something very well tested.

Flamewars and bikeshedding are welcome!

As we've discussed on irc a bit I still think cleaning up this rathole is beneficial. Getting the event handling and vblank callbacks right just in drivers seems to be really hard, so better to clean this up and unify things.

Quoted 5 lines

But like you've said patches are a lot of churn, so do you have a git branch somewhere for the lazy to look at?

Thanks, Daniel

I also think vmwgfx might already have something like this, maybe take a look and see if this is the same use case and can cover that as well.

2. How should the driver interface look like?

a. All the possibilities are passed through the function call, so the drm.ko
code needs to set the struct members itself.
b. The caller already sets the struct members instead of passing them as
parameters to the function.
c. Something different?