Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Tue, Mar 27, 2018 at 10:06:04AM +0200, Christian König wrote: > Am 27.03.2018 um 09:53 schrieb Daniel Vetter: > > [SNIP] > > > > [SNIP] > > > > A slightly better solution is using atomic counter: > > > > driver_range_start() { > > > > atomic_inc(>notifier_count); > > > ... > > > > >

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 27.03.2018 um 09:53 schrieb Daniel Vetter: [SNIP] [SNIP] A slightly better solution is using atomic counter: driver_range_start() { atomic_inc(>notifier_count); ... Yeah, that is exactly what amdgpu is doing now. Sorry if my description didn't made that clear. I would like to

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Tue, Mar 27, 2018 at 09:35:17AM +0200, Christian König wrote: > Am 26.03.2018 um 17:42 schrieb Jerome Glisse: > > On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote: > > > On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote: > > > > Am 22.03.2018 um 08:18 schrieb Daniel

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 26.03.2018 um 17:42 schrieb Jerome Glisse: On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote: On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote: Am 22.03.2018 um 08:18 schrieb Daniel Vetter: [SNIP] Key take away from that was that you can't take any locks from

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote: > On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote: > > Am 22.03.2018 um 08:18 schrieb Daniel Vetter: > > > On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote: > > > > Am 21.03.2018 um 09:28 schrieb Daniel

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote: > Am 22.03.2018 um 08:18 schrieb Daniel Vetter: > > On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote: > > > Am 21.03.2018 um 09:28 schrieb Daniel Vetter: > > > > On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Thu, Mar 22, 2018 at 10:37:55AM +0100, Christian König wrote: > Am 22.03.2018 um 08:14 schrieb Daniel Vetter: > > On Wed, Mar 21, 2018 at 10:34:05AM +0100, Christian König wrote: > > > Am 21.03.2018 um 09:18 schrieb Daniel Vetter: > > > > [SNIP] > > > For correct operation you always need to

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 22.03.2018 um 08:18 schrieb Daniel Vetter: On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote: Am 21.03.2018 um 09:28 schrieb Daniel Vetter: On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: Am 20.03.2018 um 15:08 schrieb Daniel Vetter: [SNIP] For the in-driver

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 22.03.2018 um 08:14 schrieb Daniel Vetter: On Wed, Mar 21, 2018 at 10:34:05AM +0100, Christian König wrote: Am 21.03.2018 um 09:18 schrieb Daniel Vetter: [SNIP] For correct operation you always need to implement invalidate_range_end as well and add some lock/completion work Otherwise

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote: > Am 21.03.2018 um 09:28 schrieb Daniel Vetter: > > On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: > > > Am 20.03.2018 um 15:08 schrieb Daniel Vetter: > > > > [SNIP] > > > > For the in-driver reservation path (CS)

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Wed, Mar 21, 2018 at 10:34:05AM +0100, Christian König wrote: > Am 21.03.2018 um 09:18 schrieb Daniel Vetter: > > [SNIP] > > They're both in i915_gem_userptr.c, somewhat interleaved. Would be > > interesting if you could show what you think is going wrong in there > > compared to amdgpu_mn.c. >

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 21.03.2018 um 09:28 schrieb Daniel Vetter: On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: Am 20.03.2018 um 15:08 schrieb Daniel Vetter: [SNIP] For the in-driver reservation path (CS) having a slow-path that grabs a temporary reference, drops the vram lock and then locks

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 21.03.2018 um 09:18 schrieb Daniel Vetter: [SNIP] They're both in i915_gem_userptr.c, somewhat interleaved. Would be interesting if you could show what you think is going wrong in there compared to amdgpu_mn.c. i915 implements only one callback: static const struct mmu_notifier_ops

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: > Am 20.03.2018 um 15:08 schrieb Daniel Vetter: > > [SNIP] > > For the in-driver reservation path (CS) having a slow-path that grabs a > > temporary reference, drops the vram lock and then locks the reservation > > normally (using

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: > Am 20.03.2018 um 15:08 schrieb Daniel Vetter: > > [SNIP] > > For the in-driver reservation path (CS) having a slow-path that grabs a > > temporary reference, drops the vram lock and then locks the reservation > > normally (using

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 20.03.2018 um 15:08 schrieb Daniel Vetter: [SNIP] For the in-driver reservation path (CS) having a slow-path that grabs a temporary reference, drops the vram lock and then locks the reservation normally (using the acquire context used already for the entire CS) is a bit tricky, but totally

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Tue, Mar 20, 2018 at 11:54:18AM +0100, Christian König wrote: > Am 20.03.2018 um 08:44 schrieb Daniel Vetter: > > On Mon, Mar 19, 2018 at 5:23 PM, Christian König > > wrote: > > > Am 19.03.2018 um 16:53 schrieb Chris Wilson: > > > > Quoting Christian König

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 20.03.2018 um 08:44 schrieb Daniel Vetter: On Mon, Mar 19, 2018 at 5:23 PM, Christian König wrote: Am 19.03.2018 um 16:53 schrieb Chris Wilson: Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] This allows for full grown

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Mon, Mar 19, 2018 at 5:23 PM, Christian König wrote: > Am 19.03.2018 um 16:53 schrieb Chris Wilson: >> >> Quoting Christian König (2018-03-16 14:22:32) >> [snip, probably lost too must context] >>> >>> This allows for full grown pipelining, e.g. the exporter

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 19.03.2018 um 16:53 schrieb Chris Wilson: Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] This allows for full grown pipelining, e.g. the exporter can say I need to move the buffer for some operation. Then let the move operation wait for all existing

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] > This allows for full grown pipelining, e.g. the exporter can say I need > to move the buffer for some operation. Then let the move operation wait > for all existing fences in the reservation object and install

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Fri, Mar 16, 2018 at 02:20:45PM +0100, Christian König wrote: > Each importer can now provide an invalidate_mappings callback. > > This allows the exporter to provide the mappings without the need to pin > the backing store. > > v2: don't try to invalidate mappings when the callback is NULL,

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 16.03.2018 um 14:51 schrieb Chris Wilson: Quoting Christian König (2018-03-16 13:20:45) @@ -326,6 +338,29 @@ struct dma_buf_attachment { struct device *dev; struct list_head node; void *priv; + + /** +* @invalidate_mappings: +* +*

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Quoting Christian König (2018-03-16 13:20:45) > @@ -326,6 +338,29 @@ struct dma_buf_attachment { > struct device *dev; > struct list_head node; > void *priv; > + > + /** > +* @invalidate_mappings: > +* > +* Optional callback provided by the

[PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Each importer can now provide an invalidate_mappings callback. This allows the exporter to provide the mappings without the need to pin the backing store. v2: don't try to invalidate mappings when the callback is NULL, lock the reservation obj while using the attachments, add helper to