[1/3] drm/i915: implement dma buf begin_cpu_access

Commit Message

Dave Airlie July 30, 2012, 4:06 a.m. UTC

From: Dave Airlie <[e-mail]>

In order for udl vmap to work properly, we need to push the object
into the CPU domain before we start copying the data to the USB device.

question: what is direction here in terms of read/write to the device.

This along with the udl change avoids userspace explicit mapping to
be used.

Signed-off-by: Dave Airlie <[e-mail]>
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Comments

Daniel Vetter Aug. 5, 2012, 8:52 p.m. UTC | #1

On Mon, Jul 30, 2012 at 02:06:54PM +1000, Dave Airlie wrote:
> From: Dave Airlie <[e-mail]>
> 
> In order for udl vmap to work properly, we need to push the object
> into the CPU domain before we start copying the data to the USB device.
> 
> question: what is direction here in terms of read/write to the device.
> 
> This along with the udl change avoids userspace explicit mapping to
> be used.
> 
> Signed-off-by: Dave Airlie <[e-mail]>

In my understanding TO_DEVICE means cpu writes, devices reads. FROM is
devices writes, cpu reads. So your patch looks correct.

One thing I wonder is how much lockdep likes this one here ... But I guess
it's not the first one ;-) Also, do we have a simple testcase that clears
the bo with the intel igd and then tells udl the updated damage, just to
exercise the code a bit?
-Daniel

Dave Airlie Aug. 6, 2012, 10:34 p.m. UTC | #2

On Mon, Aug 6, 2012 at 6:52 AM, Daniel Vetter <[e-mail]> wrote:
> On Mon, Jul 30, 2012 at 02:06:54PM +1000, Dave Airlie wrote:
>> From: Dave Airlie <[e-mail]>
>>
>> In order for udl vmap to work properly, we need to push the object
>> into the CPU domain before we start copying the data to the USB device.
>>
>> question: what is direction here in terms of read/write to the device.
>>
>> This along with the udl change avoids userspace explicit mapping to
>> be used.
>>
>> Signed-off-by: Dave Airlie <[e-mail]>
>
> In my understanding TO_DEVICE means cpu writes, devices reads. FROM is
> devices writes, cpu reads. So your patch looks correct.
>
> One thing I wonder is how much lockdep likes this one here ... But I guess
> it's not the first one ;-) Also, do we have a simple testcase that clears
> the bo with the intel igd and then tells udl the updated damage, just to
> exercise the code a bit?

no more lockdep that previously, which is to say one big splat.

I have real code to exercise the code a bit :-), but I'll try and add
another test to my intel-gpu-tools branches this week,

Dave.

Patch

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index cf6bdec..ee51c63 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -147,6 +147,22 @@  static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *
 	return -EINVAL;
 }
 
+static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start, size_t length, enum dma_data_direction direction)
+{
+	struct drm_i915_gem_object *obj = dma_buf->priv;
+	struct drm_device *dev = obj->base.dev;
+	int ret;
+	bool write = (direction == DMA_BIDIRECTIONAL || direction == DMA_TO_DEVICE);
+
+	ret = i915_mutex_lock_interruptible(dev);
+	if (ret)
+		return ret;
+
+	ret = i915_gem_object_set_to_cpu_domain(obj, write);
+	mutex_unlock(&dev->struct_mutex);
+	return ret;
+}
+
 static const struct dma_buf_ops i915_dmabuf_ops =  {
 	.map_dma_buf = i915_gem_map_dma_buf,
 	.unmap_dma_buf = i915_gem_unmap_dma_buf,
@@ -158,6 +174,7 @@  static const struct dma_buf_ops i915_dmabuf_ops =  {
 	.mmap = i915_gem_dmabuf_mmap,
 	.vmap = i915_gem_dmabuf_vmap,
 	.vunmap = i915_gem_dmabuf_vunmap,
+	.begin_cpu_access = i915_gem_begin_cpu_access,
 };
 
 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,