<font face="courier new,monospace">Hi Dave, Daniel, Rob,</font><div><font face="courier new,monospace"><br></font></div><div><div class="gmail_quote">On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote:<br>
> On Fri, Nov 25, 2011 at 17:28, Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br>
>> I've rebuilt my PRIME interface on top of dmabuf to see how it would work,<br>
>><br>
>> I've got primed gears running again on top, but I expect all my object<br>
>> lifetime and memory ownership rules need fixing up (i.e. leaks like a<br>
>> sieve).<br>
>><br>
>> <a href="http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf" target="_blank">http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf</a><br>
>><br>
>> has the i915/nouveau patches for the kernel to produce the prime interface.<br>
><br>
> I've noticed that your implementations for get_scatterlist (at least<br>
> for the i915 driver) doesn't return the sg table mapped into the<br>
> device address space. I've checked and the documentation makes it<br>
> clear that this should be the case (and we really need this to support<br>
> certain insane hw), but the get/put_scatterlist names are a bit<br>
> misleading. Proposal:<br>
><br>
> - use struct sg_table instead of scatterlist like you've already done<br>
> in you branch. Simply more consistent with the dma api.<br>
<br>
</div>yup<br>
<div class="im"><br>
> - rename get/put_scatterlist into map/unmap for consistency with all<br>
> the map/unmap dma api functions. The attachement would then serve as<br>
> the abstract cookie to the backing storage, similar to how struct page<br>
> * works as an abstract cookie for dma_map/unmap_page. The only special<br>
> thing is that struct device * parameter because that's already part of<br>
> the attachment.<br>
<br>
</div>yup<br>
<div class="im"><br>
> - add new wrapper functions dma_buf_map_attachment and<br>
> dma_buf_unmap_attachement to hide all the pointer/vtable-chasing that<br>
> we currently expose to users of this interface.<br>
<br>
</div>I thought that was one of the earlier comments on the initial dmabuf<br>
patch, but either way: yup<br></blockquote><div>Thanks for your comments; I will incorporate all of these in the next version I'll send out. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
BR,<br>
-R<br></blockquote><div>BR,</div><div>Sumit. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im HOEnZb"><br>
> Comments?<br>
><br>
> Cheers, Daniel<br>
> --<br>
> Daniel Vetter<br>
> <a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a> - +41 (0) 79 364 57 48 - <a href="http://blog.ffwll.ch" target="_blank">http://blog.ffwll.ch</a><br>
</div><div class="HOEnZb"><div class="h5">> --<br>
> To unsubscribe from this list: send the line "unsubscribe linux-media" in<br>
> the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a><br>
> More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a><br>
><br>
</div></div></blockquote></div><br></div>