<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/15 Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</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="HOEnZb"><div class="h5">On Wed, May 15, 2013 at 1:19 AM, Inki Dae <<a href="mailto:inki.dae@samsung.com">inki.dae@samsung.com</a>> wrote:<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: Rob Clark [mailto:<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>]<br>
>> Sent: Tuesday, May 14, 2013 10:39 PM<br>
>> To: Inki Dae<br>
>> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun<br>
>> Cho; <a href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a>; <a href="mailto:linux-media@vger.kernel.org">linux-media@vger.kernel.org</a><br>
>> Subject: Re: Introduce a new helper framework for buffer synchronization<br>
>><br>
>> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <<a href="mailto:inki.dae@samsung.com">inki.dae@samsung.com</a>> wrote:<br>
>> >> well, for cache management, I think it is a better idea.. I didn't<br>
>> >> really catch that this was the motivation from the initial patch, but<br>
>> >> maybe I read it too quickly.  But cache can be decoupled from<br>
>> >> synchronization, because CPU access is not asynchronous.  For<br>
>> >> userspace/CPU access to buffer, you should:<br>
>> >><br>
>> >>   1) wait for buffer<br>
>> >>   2) prepare-access<br>
>> >>   3)  ... do whatever cpu access to buffer ...<br>
>> >>   4) finish-access<br>
>> >>   5) submit buffer for new dma-operation<br>
>> >><br>
>> ><br>
>> ><br>
>> > For data flow from CPU to DMA device,<br>
>> > 1) wait for buffer<br>
>> > 2) prepare-access (dma_buf_begin_cpu_access)<br>
>> > 3) cpu access to buffer<br>
>> ><br>
>> ><br>
>> > For data flow from DMA device to CPU<br>
>> > 1) wait for buffer<br>
>><br>
>> Right, but CPU access isn't asynchronous (from the point of view of<br>
>> the CPU), so there isn't really any wait step at this point.  And if<br>
>> you do want the CPU to be able to signal a fence from userspace for<br>
>> some reason, you probably what something file/fd based so the<br>
>> refcnting/cleanup when process dies doesn't leave some pending DMA<br>
>> action wedged.  But I don't really see the point of that complexity<br>
>> when the CPU access isn't asynchronous in the first place.<br>
>><br>
><br>
> There was my missing comments, please see the below sequence.<br>
><br>
> For data flow from CPU to DMA device and then from DMA device to CPU,<br>
> 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)<br>
>         - including prepare-access (dma_buf_begin_cpu_access)<br>
> 2) cpu access to buffer<br>
> 3) wait for buffer <- at device driver<br>
>         - but CPU is already accessing the buffer so blocked.<br>
> 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)<br>
> 5) the thread, blocked at 3), is waked up by 4).<br>
>         - and then finish-access (dma_buf_end_cpu_access)<br>
<br>
</div></div>right, I understand you can have background threads, etc, in<br>
userspace.  But there are already plenty of synchronization primitives<br>
that can be used for cpu->cpu synchronization, either within the same<br>
process or between multiple processes.  For cpu access, even if it is<br>
handled by background threads/processes, I think it is better to use<br>
the traditional pthreads or unix synchronization primitives.  They<br>
have existed forever, they are well tested, and they work.<br>
<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></blockquote><div> </div><div>Right, this is very important. I think it's not esay to solve this issue. Aand at least for ARM based embedded system, such feature is useful to us; coupling cache operation and buffer synchronization. I'd like to collect other opinions and advices to solve this issue.</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">

BR,<br>
-R<br>
<div class="HOEnZb"><div class="h5"><br>
> 6) dma access to buffer<br>
> 7) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)<br>
>         - but DMA is already accessing the buffer so blocked.<br>
> 8) signal <- at device driver<br>
> 9) the thread, blocked at 7), is waked up by 8)<br>
>         - and then prepare-access (dma_buf_begin_cpu_access)<br>
> 10 cpu access to buffer<br>
><br>
> Basically, 'wait for buffer' includes buffer synchronization, committing<br>
> processing, and cache operation. The buffer synchronization means that a<br>
> current thread should wait for other threads accessing a shared buffer until<br>
> the completion of their access. And the committing processing means that a<br>
> current thread possesses the shared buffer so any trying to access the<br>
> shared buffer by another thread makes the thread to be blocked. However, as<br>
> I already mentioned before, it seems that these user interfaces are so ugly<br>
> yet. So we need better way.<br>
><br>
> Give me more comments if there is my missing point :)<br>
><br>
> Thanks,<br>
> Inki Dae<br>
><br>
>> BR,<br>
>> -R<br>
>><br>
>><br>
>> > 2) finish-access (dma_buf_end _cpu_access)<br>
>> > 3) dma access to buffer<br>
>> ><br>
>> > 1) and 2) are coupled with one function: we have implemented<br>
>> > fence_helper_commit_reserve() for it.<br>
>> ><br>
>> > Cache control(cache clean or cache invalidate) is performed properly<br>
>> > checking previous access type and current access type.<br>
>> > And the below is actual codes for it,<br>
><br>
</div></div><div class="HOEnZb"><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>