From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-io0-f179.google.com ([209.85.223.179]:39492 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbeCLTlj (ORCPT ); Mon, 12 Mar 2018 15:41:39 -0400 Received: by mail-io0-f179.google.com with SMTP id v10so6220234iob.6 for ; Mon, 12 Mar 2018 12:41:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180309191144.1817-1-christian.koenig@amd.com> <20180312172401.GM8589@phenom.ffwll.local> From: Daniel Vetter Date: Mon, 12 Mar 2018 20:41:37 +0100 Message-ID: Subject: Re: RFC: unpinned DMA-buf exporting To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org, dri-devel , amd-gfx list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-media-owner@vger.kernel.org List-ID: On Mon, Mar 12, 2018 at 8:15 PM, Christian K=C3=B6nig wrote: > Am 12.03.2018 um 18:24 schrieb Daniel Vetter: >> >> On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote: >>> >>> This set of patches adds an option invalidate_mappings callback to each >>> DMA-buf attachment which can be filled in by the importer. >>> >>> This callback allows the exporter to provided the DMA-buf content >>> without pinning it. The reservation objects lock acts as synchronizatio= n >>> point for buffer moves and creating mappings. >>> >>> This set includes an implementation for amdgpu which should be rather >>> easily portable to other DRM drivers. >> >> Bunch of higher level comments, and one I've forgotten in reply to patch >> 1: >> >> - What happens when a dma-buf is pinned (e.g. i915 loves to pin buffers >> for scanout)? > > > When you need to pin an imported DMA-buf you need to detach and reattach > without the invalidate_mappings callback. I think that must both be better documented, and also somehow enforced with checks. Atm nothing makes sure you actually manage to unmap if you claim to be able to do so. I think a helper to switch from pinned to unpinned would be lovely (just need to clear/reset the ->invalidate_mapping pointer while holding the reservation). Or do you expect to map buffers differently depending whether you can move them or not? At least for i915 we'd need to rework our driver quite a bit if you expect us to throw the mapping away just to be able to pin it. Atm pinning requires that it's mapped already (and depending upon platform the gpu might be using that exact mapping to render, so unmapping for pinning is a bad idea for us). >> - pulling the dma-buf implementations into amdgpu makes sense, that's >> kinda how it was meant to be anyway. The gem prime helpers are a bit >> too >> much midlayer for my taste (mostly because nvidia wanted to bypass th= e >> EXPORT_SYMBOL_GPL of core dma-buf, hooray for legal bs). We can alway= s >> extract more helpers once there's more ttm based drivers doing this. > > > Yeah, I though to abstract that similar to the AGP backend. > > Just moving some callbacks around in TTM should be sufficient to de-midla= yer > the whole thing. Yeah TTM has all the abstractions needed to handle dma-bufs "properly", it's just sometimes at the wrong level or can't be overriden. At least per my understanding of TTM (which is most likely ... confused). -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: RFC: unpinned DMA-buf exporting Date: Mon, 12 Mar 2018 20:41:37 +0100 Message-ID: References: <20180309191144.1817-1-christian.koenig@amd.com> <20180312172401.GM8589@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, amd-gfx list , dri-devel , linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBNYXIgMTIsIDIwMTggYXQgODoxNSBQTSwgQ2hyaXN0aWFuIEvDtm5pZwo8Y2tvZW5p Zy5sZWljaHR6dW1lcmtlbkBnbWFpbC5jb20+IHdyb3RlOgo+IEFtIDEyLjAzLjIwMTggdW0gMTg6 MjQgc2NocmllYiBEYW5pZWwgVmV0dGVyOgo+Pgo+PiBPbiBGcmksIE1hciAwOSwgMjAxOCBhdCAw ODoxMTo0MFBNICswMTAwLCBDaHJpc3RpYW4gSz8/bmlnIHdyb3RlOgo+Pj4KPj4+IFRoaXMgc2V0 IG9mIHBhdGNoZXMgYWRkcyBhbiBvcHRpb24gaW52YWxpZGF0ZV9tYXBwaW5ncyBjYWxsYmFjayB0 byBlYWNoCj4+PiBETUEtYnVmIGF0dGFjaG1lbnQgd2hpY2ggY2FuIGJlIGZpbGxlZCBpbiBieSB0 aGUgaW1wb3J0ZXIuCj4+Pgo+Pj4gVGhpcyBjYWxsYmFjayBhbGxvd3MgdGhlIGV4cG9ydGVyIHRv IHByb3ZpZGVkIHRoZSBETUEtYnVmIGNvbnRlbnQKPj4+IHdpdGhvdXQgcGlubmluZyBpdC4gVGhl IHJlc2VydmF0aW9uIG9iamVjdHMgbG9jayBhY3RzIGFzIHN5bmNocm9uaXphdGlvbgo+Pj4gcG9p bnQgZm9yIGJ1ZmZlciBtb3ZlcyBhbmQgY3JlYXRpbmcgbWFwcGluZ3MuCj4+Pgo+Pj4gVGhpcyBz ZXQgaW5jbHVkZXMgYW4gaW1wbGVtZW50YXRpb24gZm9yIGFtZGdwdSB3aGljaCBzaG91bGQgYmUg cmF0aGVyCj4+PiBlYXNpbHkgcG9ydGFibGUgdG8gb3RoZXIgRFJNIGRyaXZlcnMuCj4+Cj4+IEJ1 bmNoIG9mIGhpZ2hlciBsZXZlbCBjb21tZW50cywgYW5kIG9uZSBJJ3ZlIGZvcmdvdHRlbiBpbiBy ZXBseSB0byBwYXRjaAo+PiAxOgo+Pgo+PiAtIFdoYXQgaGFwcGVucyB3aGVuIGEgZG1hLWJ1ZiBp cyBwaW5uZWQgKGUuZy4gaTkxNSBsb3ZlcyB0byBwaW4gYnVmZmVycwo+PiAgICBmb3Igc2Nhbm91 dCk/Cj4KPgo+IFdoZW4geW91IG5lZWQgdG8gcGluIGFuIGltcG9ydGVkIERNQS1idWYgeW91IG5l ZWQgdG8gZGV0YWNoIGFuZCByZWF0dGFjaAo+IHdpdGhvdXQgdGhlIGludmFsaWRhdGVfbWFwcGlu Z3MgY2FsbGJhY2suCgpJIHRoaW5rIHRoYXQgbXVzdCBib3RoIGJlIGJldHRlciBkb2N1bWVudGVk LCBhbmQgYWxzbyBzb21laG93IGVuZm9yY2VkCndpdGggY2hlY2tzLiBBdG0gbm90aGluZyBtYWtl cyBzdXJlIHlvdSBhY3R1YWxseSBtYW5hZ2UgdG8gdW5tYXAgaWYKeW91IGNsYWltIHRvIGJlIGFi bGUgdG8gZG8gc28uCgpJIHRoaW5rIGEgaGVscGVyIHRvIHN3aXRjaCBmcm9tIHBpbm5lZCB0byB1 bnBpbm5lZCB3b3VsZCBiZSBsb3ZlbHkKKGp1c3QgbmVlZCB0byBjbGVhci9yZXNldCB0aGUgLT5p bnZhbGlkYXRlX21hcHBpbmcgcG9pbnRlciB3aGlsZQpob2xkaW5nIHRoZSByZXNlcnZhdGlvbiku IE9yIGRvIHlvdSBleHBlY3QgdG8gbWFwIGJ1ZmZlcnMgZGlmZmVyZW50bHkKZGVwZW5kaW5nIHdo ZXRoZXIgeW91IGNhbiBtb3ZlIHRoZW0gb3Igbm90PyBBdCBsZWFzdCBmb3IgaTkxNSB3ZSdkCm5l ZWQgdG8gcmV3b3JrIG91ciBkcml2ZXIgcXVpdGUgYSBiaXQgaWYgeW91IGV4cGVjdCB1cyB0byB0 aHJvdyB0aGUKbWFwcGluZyBhd2F5IGp1c3QgdG8gYmUgYWJsZSB0byBwaW4gaXQuIEF0bSBwaW5u aW5nIHJlcXVpcmVzIHRoYXQgaXQncwptYXBwZWQgYWxyZWFkeSAoYW5kIGRlcGVuZGluZyB1cG9u IHBsYXRmb3JtIHRoZSBncHUgbWlnaHQgYmUgdXNpbmcKdGhhdCBleGFjdCBtYXBwaW5nIHRvIHJl bmRlciwgc28gdW5tYXBwaW5nIGZvciBwaW5uaW5nIGlzIGEgYmFkIGlkZWEKZm9yIHVzKS4KCj4+ IC0gcHVsbGluZyB0aGUgZG1hLWJ1ZiBpbXBsZW1lbnRhdGlvbnMgaW50byBhbWRncHUgbWFrZXMg c2Vuc2UsIHRoYXQncwo+PiAgICBraW5kYSBob3cgaXQgd2FzIG1lYW50IHRvIGJlIGFueXdheS4g VGhlIGdlbSBwcmltZSBoZWxwZXJzIGFyZSBhIGJpdAo+PiB0b28KPj4gICAgbXVjaCBtaWRsYXll ciBmb3IgbXkgdGFzdGUgKG1vc3RseSBiZWNhdXNlIG52aWRpYSB3YW50ZWQgdG8gYnlwYXNzIHRo ZQo+PiAgICBFWFBPUlRfU1lNQk9MX0dQTCBvZiBjb3JlIGRtYS1idWYsIGhvb3JheSBmb3IgbGVn YWwgYnMpLiBXZSBjYW4gYWx3YXlzCj4+ICAgIGV4dHJhY3QgbW9yZSBoZWxwZXJzIG9uY2UgdGhl cmUncyBtb3JlIHR0bSBiYXNlZCBkcml2ZXJzIGRvaW5nIHRoaXMuCj4KPgo+IFllYWgsIEkgdGhv dWdoIHRvIGFic3RyYWN0IHRoYXQgc2ltaWxhciB0byB0aGUgQUdQIGJhY2tlbmQuCj4KPiBKdXN0 IG1vdmluZyBzb21lIGNhbGxiYWNrcyBhcm91bmQgaW4gVFRNIHNob3VsZCBiZSBzdWZmaWNpZW50 IHRvIGRlLW1pZGxheWVyCj4gdGhlIHdob2xlIHRoaW5nLgoKWWVhaCBUVE0gaGFzIGFsbCB0aGUg YWJzdHJhY3Rpb25zIG5lZWRlZCB0byBoYW5kbGUgZG1hLWJ1ZnMKInByb3Blcmx5IiwgaXQncyBq dXN0IHNvbWV0aW1lcyBhdCB0aGUgd3JvbmcgbGV2ZWwgb3IgY2FuJ3QgYmUKb3ZlcnJpZGVuLiBB dCBsZWFzdCBwZXIgbXkgdW5kZXJzdGFuZGluZyBvZiBUVE0gKHdoaWNoIGlzIG1vc3QgbGlrZWx5 Ci4uLiBjb25mdXNlZCkuCi1EYW5pZWwKLS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5l ZXIsIEludGVsIENvcnBvcmF0aW9uCis0MSAoMCkgNzkgMzY1IDU3IDQ4IC0gaHR0cDovL2Jsb2cu ZmZ3bGwuY2gKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K YW1kLWdmeCBtYWlsaW5nIGxpc3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4Cg==