From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 05/12] dma-buf: add explicit buffer pinning Date: Wed, 17 Apr 2019 16:20:02 +0200 Message-ID: <20190417142002.GE13337@phenom.ffwll.local> References: <20190416183841.1577-1-christian.koenig@amd.com> <20190416183841.1577-6-christian.koenig@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190416183841.1577-6-christian.koenig-5C7GfCeVMHo@public.gmane.org> List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, sumit.semwal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org T24gVHVlLCBBcHIgMTYsIDIwMTkgYXQgMDg6Mzg6MzRQTSArMDIwMCwgQ2hyaXN0aWFuIEvDtm5p ZyB3cm90ZToKPiBBZGQgb3B0aW9uYWwgZXhwbGljaXQgcGlubmluZyBjYWxsYmFja3MgaW5zdGVh ZCBvZiBpbXBsaWNpdGx5IGFzc3VtZSB0aGUKPiBleHBvcnRlciBwaW5zIHRoZSBidWZmZXIgd2hl biBhIG1hcHBpbmcgaXMgY3JlYXRlZC4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBDaHJpc3RpYW4gS8O2 bmlnIDxjaHJpc3RpYW4ua29lbmlnQGFtZC5jb20+CgpEb24ndCB3ZSBuZWVkIHRoaXMgdG9nZXRo ZXIgd2l0aCB0aGUgaW52YWxpZGF0ZSBjYWxsYmFjayBhbmQgdGhlIGR5bmFtaWMKc3R1ZmY/IEFs c28gSSdtIGFzc3VtaW5nIHRoYXQgcGluL3VucGluIGlzIHByZXR0eSBtdWNoIHJlcXVpcmVkIGZv cgpkeW5hbWljIGJvLCBzbyBjb3VsZCB3ZSBsb29rIGF0IHRoZXNlIGNhbGxiYWNrcyBpbnN0ZWFk IG9mIHRoZSBkeW5hbWljCmZsYWcgeW91IGFkZCBpbiBwYXRjaCAxLgoKSSdtIGFzc3VtaW5nIGZv bGxvd2luZyBydWxlcyBob2xkOgpubyBwaW4vdXBpbiBmcm9tIGV4cG9ydGVyOgoKZG1hLWJ1ZiBp cyBub3QgZHluYW1pYywgYW5kIHBpbm5lZCBmb3IgdGhlIGR1cmF0aW9uIG9mIG1hcC91bm1hcC4g SSdtCm5vdCAxMDAlIHN1cmUgd2hldGhlciByZWFsbHkgZXZlcnlvbmUgd2FudHMgdGhlIG1hcHBp bmcgdG8gYmUgY2FjaGVkIGZvcgp0aGUgZW50aXJlIGF0dGFjaG1lbnQsIG9ubHkgZHJtX3ByaW1l IGRvZXMgdGhhdC4gQW5kIHRoYXQncyBub3QgdGhlIG9ubHkKZG1hLWJ1ZiBpbXBvcnRlci4KCnBp bi91bnBpbiBjYWxscyBhcmUgbm9vcHMuCgpwaW4vdW5waW4gZXhpc3QgaW4gdGhlIGV4cG9ydGVy LCBidXQgaW1wb3J0ZXIgaGFzIG5vdCBwcm92aWRlZCBhbgppbnZhbGlkYXRlIGNhbGxiYWNrOgoK V2UgbWFwIGF0IGF0dGFjaCB0aW1lLCBhbmQgd2UgYWxzbyBoYXZlIHRvIHBpbiwgc2luY2UgdGhl IGltcG9ydGVyIGNhbid0CmhhbmRsZSB0aGUgYnVmZmVyIGRpc2FwcGVhcmluZywgYXQgYXR0YWNo IHRpbWUuIFdlIHVubWFwL3VucGluIGF0IGRldGFjaC4KCnBpbi91bnBpbiBmcm9tIGV4cG9ydGVy LCBpbnZhbGlkYXRlIGZyb20gaW1wb3J0ZXI6CgpGdWxsIGR5bmFtaWMgbWFwcGluZy4gV2UgYXNz dW1lIHRoZSBpbXBvcnRlciB3aWxsIGRvIGNhY2hpbmcsIGF0dGFjaApmZW5jZXMgYXMgbmVlZGVk LCBhbmQgcGluIHRoZSB1bmRlcmx5aW5nIGJvIHdoZW4gaXQgbmVlZHMgaXQgaXQKcGVybWFuZW50 bHksIHdpdGhvdXQgYXR0YWNoaW5nIGZlbmNlcyAoaS5lLiB0aGUgc2Nhbm91dCBjYXNlKS4KCkFz c3VtaW5nIEknbSBub3QgdGVycmlibHkgb2ZmIHdpdGggbXkgdW5kZXJzdGFuZGluZywgdGhlbiBJ IHRoaW5rIGl0J2QgYmUKYmVzdCB0byBpbnRyb2R1Y2UgdGhlIGVudGlyZSBuZXcgZG1hLWJ1ZiBh cGkgaW4gdGhlIGZpcnN0IHBhdGNoLCBhbmQgZmxlc2gKaXQgb3V0IGxhdGVyLiBJbnN0ZWFkIG9m IHNwcmVhZCBvdmVyIGEgZmV3IHBhdGNoZXMuIFBsdXMgdGhlIGFib3ZlIChtYXliZQpwcmV0dGll cikgYXMgYSBuaWNlIGtlcm5lbGRvYyBvdmVydmlldyBjb21tZW50IGZvciBob3cgZHluYW1pYyBk bWEtYnVmIGlzCnN1cHBvc2VkIHRvIHdvcmsgcmVhbGx5LgotRGFuaWVsCgo+IC0tLQo+ICBkcml2 ZXJzL2RtYS1idWYvZG1hLWJ1Zi5jIHwgMzkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrCj4gIGluY2x1ZGUvbGludXgvZG1hLWJ1Zi5oICAgfCAzNyArKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrLS0tLS0tCj4gIDIgZmlsZXMgY2hhbmdlZCwgNzAgaW5zZXJ0aW9u cygrKSwgNiBkZWxldGlvbnMoLSkKPiAKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9kbWEtYnVmL2Rt YS1idWYuYyBiL2RyaXZlcnMvZG1hLWJ1Zi9kbWEtYnVmLmMKPiBpbmRleCBhMzczOGZhYjM5Mjcu LmYyM2ZmODM1NTUwNSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL2RtYS1idWYvZG1hLWJ1Zi5jCj4g KysrIGIvZHJpdmVycy9kbWEtYnVmL2RtYS1idWYuYwo+IEBAIC02MzAsNiArNjMwLDQxIEBAIHZv aWQgZG1hX2J1Zl9kZXRhY2goc3RydWN0IGRtYV9idWYgKmRtYWJ1Ziwgc3RydWN0IGRtYV9idWZf YXR0YWNobWVudCAqYXR0YWNoKQo+ICB9Cj4gIEVYUE9SVF9TWU1CT0xfR1BMKGRtYV9idWZfZGV0 YWNoKTsKPiAgCj4gKy8qKgo+ICsgKiBkbWFfYnVmX3BpbiAtIExvY2sgZG93biB0aGUgRE1BLWJ1 Zgo+ICsgKgo+ICsgKiBAZG1hYnVmOglbaW5dCURNQS1idWYgdG8gbG9jayBkb3duLgo+ICsgKgo+ ICsgKiBSZXR1cm5zOgo+ICsgKiAwIG9uIHN1Y2Nlc3MsIG5lZ2F0aXZlIGVycm9yIGNvZGUgb24g ZmFpbHVyZS4KPiArICovCj4gK2ludCBkbWFfYnVmX3BpbihzdHJ1Y3QgZG1hX2J1ZiAqZG1hYnVm KQo+ICt7Cj4gKwlpbnQgcmV0ID0gMDsKPiArCj4gKwlyZXNlcnZhdGlvbl9vYmplY3RfYXNzZXJ0 X2hlbGQoZG1hYnVmLT5yZXN2KTsKPiArCj4gKwlpZiAoZG1hYnVmLT5vcHMtPnBpbikKPiArCQly ZXQgPSBkbWFidWYtPm9wcy0+cGluKGRtYWJ1Zik7Cj4gKwo+ICsJcmV0dXJuIHJldDsKPiArfQo+ ICtFWFBPUlRfU1lNQk9MX0dQTChkbWFfYnVmX3Bpbik7Cj4gKwo+ICsvKioKPiArICogZG1hX2J1 Zl91bnBpbiAtIFJlbW92ZSBsb2NrIGZyb20gRE1BLWJ1Zgo+ICsgKgo+ICsgKiBAZG1hYnVmOglb aW5dCURNQS1idWYgdG8gdW5sb2NrLgo+ICsgKi8KPiArdm9pZCBkbWFfYnVmX3VucGluKHN0cnVj dCBkbWFfYnVmICpkbWFidWYpCj4gK3sKPiArCXJlc2VydmF0aW9uX29iamVjdF9hc3NlcnRfaGVs ZChkbWFidWYtPnJlc3YpOwo+ICsKPiArCWlmIChkbWFidWYtPm9wcy0+dW5waW4pCj4gKwkJZG1h YnVmLT5vcHMtPnVucGluKGRtYWJ1Zik7Cj4gK30KPiArRVhQT1JUX1NZTUJPTF9HUEwoZG1hX2J1 Zl91bnBpbik7Cj4gKwo+ICAvKioKPiAgICogZG1hX2J1Zl9tYXBfYXR0YWNobWVudF9sb2NrZWQg LSBNYXBzIHRoZSBidWZmZXIgaW50byBfZGV2aWNlXyBhZGRyZXNzIHNwYWNlCj4gICAqIHdpdGgg dGhlIHJlc2VydmF0aW9uIGxvY2sgaGVsZC4gSXMgYSB3cmFwcGVyIGZvciBtYXBfZG1hX2J1Zigp IG9mIHRoZQo+IEBAIC02NjYsNiArNzAxLDggQEAgZG1hX2J1Zl9tYXBfYXR0YWNobWVudF9sb2Nr ZWQoc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCAqYXR0YWNoLAo+ICAJICovCj4gIAlpZiAoYXR0 YWNoLT5pbnZhbGlkYXRlKQo+ICAJCWxpc3RfZGVsKCZhdHRhY2gtPm5vZGUpOwo+ICsJZWxzZQo+ ICsJCWRtYV9idWZfcGluKGF0dGFjaC0+ZG1hYnVmKTsKPiAgCXNnX3RhYmxlID0gYXR0YWNoLT5k bWFidWYtPm9wcy0+bWFwX2RtYV9idWYoYXR0YWNoLCBkaXJlY3Rpb24pOwo+ICAJaWYgKGF0dGFj aC0+aW52YWxpZGF0ZSkKPiAgCQlsaXN0X2FkZCgmYXR0YWNoLT5ub2RlLCAmYXR0YWNoLT5kbWFi dWYtPmF0dGFjaG1lbnRzKTsKPiBAQCAtNzM1LDYgKzc3Miw4IEBAIHZvaWQgZG1hX2J1Zl91bm1h cF9hdHRhY2htZW50X2xvY2tlZChzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICphdHRhY2gsCj4g IAo+ICAJYXR0YWNoLT5kbWFidWYtPm9wcy0+dW5tYXBfZG1hX2J1ZihhdHRhY2gsIHNnX3RhYmxl LAo+ICAJCQkJCQlkaXJlY3Rpb24pOwo+ICsJaWYgKCFhdHRhY2gtPmludmFsaWRhdGUpCj4gKwkJ ZG1hX2J1Zl91bnBpbihhdHRhY2gtPmRtYWJ1Zik7Cj4gIH0KPiAgRVhQT1JUX1NZTUJPTF9HUEwo ZG1hX2J1Zl91bm1hcF9hdHRhY2htZW50X2xvY2tlZCk7Cj4gIAo+IGRpZmYgLS1naXQgYS9pbmNs dWRlL2xpbnV4L2RtYS1idWYuaCBiL2luY2x1ZGUvbGludXgvZG1hLWJ1Zi5oCj4gaW5kZXggZWNl NDYzODM1OWE4Li5hNjE1Yjc0ZTU4OTQgMTAwNjQ0Cj4gLS0tIGEvaW5jbHVkZS9saW51eC9kbWEt YnVmLmgKPiArKysgYi9pbmNsdWRlL2xpbnV4L2RtYS1idWYuaAo+IEBAIC0xMDAsMTQgKzEwMCw0 MCBAQCBzdHJ1Y3QgZG1hX2J1Zl9vcHMgewo+ICAJICovCj4gIAl2b2lkICgqZGV0YWNoKShzdHJ1 Y3QgZG1hX2J1ZiAqLCBzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICopOwo+ICAKPiArCS8qKgo+ ICsJICogQHBpbl9kbWFfYnVmOgo+ICsJICoKPiArCSAqIFRoaXMgaXMgY2FsbGVkIGJ5IGRtYV9i dWZfcGluIGFuZCBsZXRzIHRoZSBleHBvcnRlciBrbm93IHRoYXQgYW4KPiArCSAqIGltcG9ydGVy IGFzc3VtZXMgdGhhdCB0aGUgRE1BLWJ1ZiBjYW4ndCBiZSBpbnZhbGlkYXRlZCBhbnkgbW9yZS4K PiArCSAqCj4gKwkgKiBUaGlzIGlzIGNhbGxlZCB3aXRoIHRoZSBkbWFidWYtPnJlc3Ygb2JqZWN0 IGxvY2tlZC4KPiArCSAqCj4gKwkgKiBUaGlzIGNhbGxiYWNrIGlzIG9wdGlvbmFsLgo+ICsJICoK PiArCSAqIFJldHVybnM6Cj4gKwkgKgo+ICsJICogMCBvbiBzdWNjZXNzLCBuZWdhdGl2ZSBlcnJv ciBjb2RlIG9uIGZhaWx1cmUuCj4gKwkgKi8KPiArCWludCAoKnBpbikoc3RydWN0IGRtYV9idWYg Kik7Cj4gKwo+ICsJLyoqCj4gKwkgKiBAdW5waW5fZG1hX2J1ZjoKPiArCSAqCj4gKwkgKiBUaGlz IGlzIGNhbGxlZCBieSBkbWFfYnVmX3VucGluIGFuZCBsZXRzIHRoZSBleHBvcnRlciBrbm93IHRo YXQgYW4KPiArCSAqIGltcG9ydGVyIGRvZXNuJ3QgbmVlZCB0byB0aGUgRE1BLWJ1ZiB0byBzdGF5 IHdlcmUgaXQgaXMgYW55IG1vcmUuCj4gKwkgKgo+ICsJICogVGhpcyBpcyBjYWxsZWQgd2l0aCB0 aGUgZG1hYnVmLT5yZXN2IG9iamVjdCBsb2NrZWQuCj4gKwkgKgo+ICsJICogVGhpcyBjYWxsYmFj ayBpcyBvcHRpb25hbC4KPiArCSAqLwo+ICsJdm9pZCAoKnVucGluKShzdHJ1Y3QgZG1hX2J1ZiAq KTsKPiArCj4gIAkvKioKPiAgCSAqIEBtYXBfZG1hX2J1ZjoKPiAgCSAqCj4gIAkgKiBUaGlzIGlz IGNhbGxlZCBieSBkbWFfYnVmX21hcF9hdHRhY2htZW50KCkgYW5kIGlzIHVzZWQgdG8gbWFwIGEK PiAgCSAqIHNoYXJlZCAmZG1hX2J1ZiBpbnRvIGRldmljZSBhZGRyZXNzIHNwYWNlLCBhbmQgaXQg aXMgbWFuZGF0b3J5LiBJdAo+IC0JICogY2FuIG9ubHkgYmUgY2FsbGVkIGlmIEBhdHRhY2ggaGFz IGJlZW4gY2FsbGVkIHN1Y2Nlc3NmdWxseS4gVGhpcwo+IC0JICogZXNzZW50aWFsbHkgcGlucyB0 aGUgRE1BIGJ1ZmZlciBpbnRvIHBsYWNlLCBhbmQgaXQgY2Fubm90IGJlIG1vdmVkCj4gLQkgKiBh bnkgbW9yZQo+ICsJICogY2FuIG9ubHkgYmUgY2FsbGVkIGlmIEBhdHRhY2ggaGFzIGJlZW4gY2Fs bGVkIHN1Y2Nlc3NmdWxseS4KPiAgCSAqCj4gIAkgKiBUaGlzIGNhbGwgbWF5IHNsZWVwLCBlLmcu IHdoZW4gdGhlIGJhY2tpbmcgc3RvcmFnZSBmaXJzdCBuZWVkcyB0byBiZQo+ICAJICogYWxsb2Nh dGVkLCBvciBtb3ZlZCB0byBhIGxvY2F0aW9uIHN1aXRhYmxlIGZvciBhbGwgY3VycmVudGx5IGF0 dGFjaGVkCj4gQEAgLTE0OCw5ICsxNzQsNiBAQCBzdHJ1Y3QgZG1hX2J1Zl9vcHMgewo+ICAJICoK PiAgCSAqIFRoaXMgaXMgY2FsbGVkIGJ5IGRtYV9idWZfdW5tYXBfYXR0YWNobWVudCgpIGFuZCBz aG91bGQgdW5tYXAgYW5kCj4gIAkgKiByZWxlYXNlIHRoZSAmc2dfdGFibGUgYWxsb2NhdGVkIGlu IEBtYXBfZG1hX2J1ZiwgYW5kIGl0IGlzIG1hbmRhdG9yeS4KPiAtCSAqIEl0IHNob3VsZCBhbHNv IHVucGluIHRoZSBiYWNraW5nIHN0b3JhZ2UgaWYgdGhpcyBpcyB0aGUgbGFzdCBtYXBwaW5nCj4g LQkgKiBvZiB0aGUgRE1BIGJ1ZmZlciwgaXQgdGhlIGV4cG9ydGVyIHN1cHBvcnRzIGJhY2tpbmcg c3RvcmFnZQo+IC0JICogbWlncmF0aW9uLgo+ICAJICoKPiAgCSAqIFRoaXMgaXMgYWx3YXlzIGNh bGxlZCB3aXRoIHRoZSBkbWFidWYtPnJlc3Ygb2JqZWN0IGxvY2tlZCB3aGVuCj4gIAkgKiBub19z Z3RfY2FjaGUgaXMgdHJ1ZS4KPiBAQCAtNDQyLDYgKzQ2NSw4IEBAIGludCBkbWFfYnVmX2ZkKHN0 cnVjdCBkbWFfYnVmICpkbWFidWYsIGludCBmbGFncyk7Cj4gIHN0cnVjdCBkbWFfYnVmICpkbWFf YnVmX2dldChpbnQgZmQpOwo+ICB2b2lkIGRtYV9idWZfcHV0KHN0cnVjdCBkbWFfYnVmICpkbWFi dWYpOwo+ICAKPiAraW50IGRtYV9idWZfcGluKHN0cnVjdCBkbWFfYnVmICpkbWFidWYpOwo+ICt2 b2lkIGRtYV9idWZfdW5waW4oc3RydWN0IGRtYV9idWYgKmRtYWJ1Zik7Cj4gIHN0cnVjdCBzZ190 YWJsZSAqZG1hX2J1Zl9tYXBfYXR0YWNobWVudF9sb2NrZWQoc3RydWN0IGRtYV9idWZfYXR0YWNo bWVudCAqLAo+ICAJCQkJCSAgICAgICBlbnVtIGRtYV9kYXRhX2RpcmVjdGlvbik7Cj4gIHN0cnVj dCBzZ190YWJsZSAqZG1hX2J1Zl9tYXBfYXR0YWNobWVudChzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2ht ZW50ICosCj4gLS0gCj4gMi4xNy4xCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiBkcmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4gZHJpLWRldmVsQGxp c3RzLmZyZWVkZXNrdG9wLm9yZwo+IGh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxt YW4vbGlzdGluZm8vZHJpLWRldmVsCgotLSAKRGFuaWVsIFZldHRlcgpTb2Z0d2FyZSBFbmdpbmVl ciwgSW50ZWwgQ29ycG9yYXRpb24KaHR0cDovL2Jsb2cuZmZ3bGwuY2gKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYW1kLWdmeCBtYWlsaW5nIGxpc3QKYW1k LWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv bWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80113C282DC for ; Wed, 17 Apr 2019 14:20:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4CF9120872 for ; Wed, 17 Apr 2019 14:20:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="EvnrgSgw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732492AbfDQOUH (ORCPT ); Wed, 17 Apr 2019 10:20:07 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:46778 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732007AbfDQOUH (ORCPT ); Wed, 17 Apr 2019 10:20:07 -0400 Received: by mail-ed1-f68.google.com with SMTP id d1so21116927edd.13 for ; Wed, 17 Apr 2019 07:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=IckmlwlCYuYebAcm4zShyTjyGza8QayjzJCK2BIDC8A=; b=EvnrgSgwKziWe2cW4rkAUzKIQplJ10lLdiJ83Vt1Mn1sXfJfIy+XzMDFUVurZUAxN1 +CzrKwnU4OAhVw7rltEruRDSpvijL7SbddL9ijUHuLEcTy2ZEtOox7/G6tXmcvD983dN Ycg2CEczhicwhkacHk4LFCoHwsShyHoUc6fqs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=IckmlwlCYuYebAcm4zShyTjyGza8QayjzJCK2BIDC8A=; b=uOuBQdh4LKF1vn4cPQ2CKsa0VSTzGCG2E1FzHDuQnc5vYQkJQ/isPZ5mrl3uBJsUoF RyVLnzNzxbOSZS+sRnBVaaXzTR75RoWOWS0WLT1T85lWvpgnLN9bYnTzre+A4II/408B IayJ7r+pRvgFphUmkJrl9ynbY9VyhDNX/K0edllswWmM8BrPpMXa8AfMdnVWS80et0Oa hAIvPDOtxnWEYGIcTA10osmQIDkw61n6SFpcBU5VmKZexI2T268s26jO1XSBCRNyIhA2 QRwAHzPAnCpbM2ejdb3Zn4vWABUGdUha0PIQE5GbgGxreyyAEKgyzsGMCTwK5wcMCNO3 lZXg== X-Gm-Message-State: APjAAAURHnh9SsZMSTYKlidiUp8W/p9xpt04Gyk9IiUeLIs61xjqMhZy iP80FklbeGUCEvtIKky/IvJwrI9/1Os= X-Google-Smtp-Source: APXvYqyheS+LMtUGXq44aXxVzKb+GydoNsHhKC1b6fYaB+qqgFFyDv0RDHiAmrb75q/3tAQ5vq/2hg== X-Received: by 2002:a17:906:3e85:: with SMTP id a5mr48593940ejj.272.1555510804861; Wed, 17 Apr 2019 07:20:04 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id w58sm17267091edd.69.2019.04.17.07.20.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 07:20:04 -0700 (PDT) Date: Wed, 17 Apr 2019 16:20:02 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: sumit.semwal@linaro.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 05/12] dma-buf: add explicit buffer pinning Message-ID: <20190417142002.GE13337@phenom.ffwll.local> Mail-Followup-To: Christian =?iso-8859-1?Q?K=F6nig?= , sumit.semwal@linaro.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org References: <20190416183841.1577-1-christian.koenig@amd.com> <20190416183841.1577-6-christian.koenig@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190416183841.1577-6-christian.koenig@amd.com> X-Operating-System: Linux phenom 4.19.0-1-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote: > Add optional explicit pinning callbacks instead of implicitly assume the > exporter pins the buffer when a mapping is created. > > Signed-off-by: Christian König Don't we need this together with the invalidate callback and the dynamic stuff? Also I'm assuming that pin/unpin is pretty much required for dynamic bo, so could we look at these callbacks instead of the dynamic flag you add in patch 1. I'm assuming following rules hold: no pin/upin from exporter: dma-buf is not dynamic, and pinned for the duration of map/unmap. I'm not 100% sure whether really everyone wants the mapping to be cached for the entire attachment, only drm_prime does that. And that's not the only dma-buf importer. pin/unpin calls are noops. pin/unpin exist in the exporter, but importer has not provided an invalidate callback: We map at attach time, and we also have to pin, since the importer can't handle the buffer disappearing, at attach time. We unmap/unpin at detach. pin/unpin from exporter, invalidate from importer: Full dynamic mapping. We assume the importer will do caching, attach fences as needed, and pin the underlying bo when it needs it it permanently, without attaching fences (i.e. the scanout case). Assuming I'm not terribly off with my understanding, then I think it'd be best to introduce the entire new dma-buf api in the first patch, and flesh it out later. Instead of spread over a few patches. Plus the above (maybe prettier) as a nice kerneldoc overview comment for how dynamic dma-buf is supposed to work really. -Daniel > --- > drivers/dma-buf/dma-buf.c | 39 +++++++++++++++++++++++++++++++++++++++ > include/linux/dma-buf.h | 37 +++++++++++++++++++++++++++++++------ > 2 files changed, 70 insertions(+), 6 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index a3738fab3927..f23ff8355505 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -630,6 +630,41 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) > } > EXPORT_SYMBOL_GPL(dma_buf_detach); > > +/** > + * dma_buf_pin - Lock down the DMA-buf > + * > + * @dmabuf: [in] DMA-buf to lock down. > + * > + * Returns: > + * 0 on success, negative error code on failure. > + */ > +int dma_buf_pin(struct dma_buf *dmabuf) > +{ > + int ret = 0; > + > + reservation_object_assert_held(dmabuf->resv); > + > + if (dmabuf->ops->pin) > + ret = dmabuf->ops->pin(dmabuf); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(dma_buf_pin); > + > +/** > + * dma_buf_unpin - Remove lock from DMA-buf > + * > + * @dmabuf: [in] DMA-buf to unlock. > + */ > +void dma_buf_unpin(struct dma_buf *dmabuf) > +{ > + reservation_object_assert_held(dmabuf->resv); > + > + if (dmabuf->ops->unpin) > + dmabuf->ops->unpin(dmabuf); > +} > +EXPORT_SYMBOL_GPL(dma_buf_unpin); > + > /** > * dma_buf_map_attachment_locked - Maps the buffer into _device_ address space > * with the reservation lock held. Is a wrapper for map_dma_buf() of the > @@ -666,6 +701,8 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment *attach, > */ > if (attach->invalidate) > list_del(&attach->node); > + else > + dma_buf_pin(attach->dmabuf); > sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); > if (attach->invalidate) > list_add(&attach->node, &attach->dmabuf->attachments); > @@ -735,6 +772,8 @@ void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach, > > attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, > direction); > + if (!attach->invalidate) > + dma_buf_unpin(attach->dmabuf); > } > EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked); > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index ece4638359a8..a615b74e5894 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -100,14 +100,40 @@ struct dma_buf_ops { > */ > void (*detach)(struct dma_buf *, struct dma_buf_attachment *); > > + /** > + * @pin_dma_buf: > + * > + * This is called by dma_buf_pin and lets the exporter know that an > + * importer assumes that the DMA-buf can't be invalidated any more. > + * > + * This is called with the dmabuf->resv object locked. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success, negative error code on failure. > + */ > + int (*pin)(struct dma_buf *); > + > + /** > + * @unpin_dma_buf: > + * > + * This is called by dma_buf_unpin and lets the exporter know that an > + * importer doesn't need to the DMA-buf to stay were it is any more. > + * > + * This is called with the dmabuf->resv object locked. > + * > + * This callback is optional. > + */ > + void (*unpin)(struct dma_buf *); > + > /** > * @map_dma_buf: > * > * This is called by dma_buf_map_attachment() and is used to map a > * shared &dma_buf into device address space, and it is mandatory. It > - * can only be called if @attach has been called successfully. This > - * essentially pins the DMA buffer into place, and it cannot be moved > - * any more > + * can only be called if @attach has been called successfully. > * > * This call may sleep, e.g. when the backing storage first needs to be > * allocated, or moved to a location suitable for all currently attached > @@ -148,9 +174,6 @@ struct dma_buf_ops { > * > * This is called by dma_buf_unmap_attachment() and should unmap and > * release the &sg_table allocated in @map_dma_buf, and it is mandatory. > - * It should also unpin the backing storage if this is the last mapping > - * of the DMA buffer, it the exporter supports backing storage > - * migration. > * > * This is always called with the dmabuf->resv object locked when > * no_sgt_cache is true. > @@ -442,6 +465,8 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags); > struct dma_buf *dma_buf_get(int fd); > void dma_buf_put(struct dma_buf *dmabuf); > > +int dma_buf_pin(struct dma_buf *dmabuf); > +void dma_buf_unpin(struct dma_buf *dmabuf); > struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *, > enum dma_data_direction); > struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *, > -- > 2.17.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch