<div dir="ltr"><div class="gmail_extra"> </div><div class="gmail_extra">Hi Daniel,<br><br><div class="gmail_quote">2013/5/17 Daniel Vetter <span dir="ltr"><<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div class="im">On Wed, May 15, 2013 at 4:06 PM, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>

> So while it seems nice and orthogonal/clean to couple cache and<br>
> synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the<br>
> same generic way, but I think in practice we have to make things more<br>
> complex than they otherwise need to be to do this.  Otherwise I think<br>
> we'll be having problems with badly behaved or crashing userspace.<br>
<br>
</div>I haven't read through the entire thread careful but imo this is very<br>
important. If we add a fence interface which allows userspace to block<br>
dma this is a no-go. The only thing we need is to sync up with all<br>
outstanding dma operations and flush caches for cpu access. If broken<br>
userspace starts to issue new dma (or multiple thread stomp onto each<br>
another) that's not a problem dma fences/syncpoints should try to<br>
solve.</blockquote><div> </div><div> </div><div>I'm not sure that I understood your concerns but it seems that you say we have to prohibit userspace from blocking dma. Could you please give me more detail for it? Without critical problem by userspace, this appoach is a better way against the traditional at least for ARM based embedded system. For this, I had already mentioned before like below,</div>
<div>               <a href="http://www.spinics.net/lists/dri-devel/msg38359.html">http://www.spinics.net/lists/dri-devel/msg38359.html</a></div><div> </div><div>If you agree to my opinion, I'd like to say we could try to solve this problem in the long term. If we prohibit such interfaces from be used without sure reason, I carefully think we might to be just going thourgh the motions: we have to use traditional way NECESSARILY. As previously stated, could please tell me about that there are sure reasons we have to prohibit the such user interfaces from being used necessarily and there is really no any way we have to solve that? Basically, I have designed and implemented that all resources to user fence are freed once timed out so that the user cannot affect the other anymore. However, I'm sure that there are things I didn't cach up. As I already mentioned, the purpose of this post is to collect other opinions and advices for better something else. Of course, we have to concentrate on solving the device-to-device sync issues first.</div>
<div> </div><div>Thanks,</div><div>Inki Dae</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
 This way we can concentrate on solving the (already<br>
challenging) device-to-device sync issues without additional<br>
complexities which cpu->cpu sync would impose.<br>
-Daniel<br>
--<br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
+41 (0) 79 365 57 48 - <a href="http://blog.ffwll.ch" target="_blank">http://blog.ffwll.ch</a><br>
<div><div class="h5">_______________________________________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dri-devel</a><br>
</div></div></blockquote></div><br></div></div>