Introduce a new helper framework for buffer synchronization

[Inki Dae]

Hi Daniel,

2013/5/17 Daniel Vetter <daniel at ffwll.ch>

> On Wed, May 15, 2013 at 4:06 PM, Rob Clark <robdclark at gmail.com> wrote:
> > So while it seems nice and orthogonal/clean to couple cache and
> > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > same generic way, but I think in practice we have to make things more
> > complex than they otherwise need to be to do this.  Otherwise I think
> > we'll be having problems with badly behaved or crashing userspace.
>
> I haven't read through the entire thread careful but imo this is very
> important. If we add a fence interface which allows userspace to block
> dma this is a no-go. The only thing we need is to sync up with all
> outstanding dma operations and flush caches for cpu access. If broken
> userspace starts to issue new dma (or multiple thread stomp onto each
> another) that's not a problem dma fences/syncpoints should try to
> solve.



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,
               http://www.spinics.net/lists/dri-devel/msg38359.html

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.

Thanks,
Inki Dae


> This way we can concentrate on solving the (already
> challenging) device-to-device sync issues without additional
> complexities which cpu->cpu sync would impose.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130518/60d33702/attachment-0001.html>