Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

Am 22.05.19 um 13:29 schrieb Daniel Vetter: > [SNIP] > Forgot to add: Iirc it was buffer sharing between i915 and amdgpu that > hits this. Can't say for sure since intel-gfx isn't cc'ed on this > version, so our CI hasn't picked this up. I've changed this so that when exporter/importer disagree

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

On Wed, May 22, 2019 at 1:27 PM Daniel Vetter wrote: > > On Wed, May 22, 2019 at 10:49 AM Christian König > wrote: > > > > Am 22.05.19 um 10:19 schrieb Daniel Vetter: > > > On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote: > > > [SNAP] > > > Just this functional comment, since I

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

On Wed, May 15, 2019 at 4:38 PM Christian König wrote: > > On the exporter side we add optional explicit pinning callbacks. If those > callbacks are implemented the framework no longer caches sg tables and the > map/unmap callbacks are always called with the lock of the reservation object > held.

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

On Wed, May 22, 2019 at 10:49 AM Christian König wrote: > > Am 22.05.19 um 10:19 schrieb Daniel Vetter: > > On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote: > > [SNAP] > > Just this functional comment, since I think api detail polishing is > > premature if we're not yet aware of

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

Am 22.05.19 um 10:19 schrieb Daniel Vetter: On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote: [SNAP] Just this functional comment, since I think api detail polishing is premature if we're not yet aware of how this works. + /* When the importer is dynamic but the exporter

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

On Wed, May 15, 2019 at 04:38:26PM +0200, Christian König wrote: > On the exporter side we add optional explicit pinning callbacks. If those > callbacks are implemented the framework no longer caches sg tables and the > map/unmap callbacks are always called with the lock of the reservation object

[PATCH 1/6] dma-buf: add dynamic DMA-buf handling v8

On the exporter side we add optional explicit pinning callbacks. If those callbacks are implemented the framework no longer caches sg tables and the map/unmap callbacks are always called with the lock of the reservation object held. On the importer side we add an optional invalidate callback.