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:30:51 +0200 Message-ID: <20190417143051.GG13337@phenom.ffwll.local> References: <20190416183841.1577-1-christian.koenig@amd.com> <20190416183841.1577-6-christian.koenig@amd.com> <20190417142002.GE13337@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190417142002.GE13337-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@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?= , sumit.semwal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org T24gV2VkLCBBcHIgMTcsIDIwMTkgYXQgMDQ6MjA6MDJQTSArMDIwMCwgRGFuaWVsIFZldHRlciB3 cm90ZToKPiBPbiBUdWUsIEFwciAxNiwgMjAxOSBhdCAwODozODozNFBNICswMjAwLCBDaHJpc3Rp YW4gS8O2bmlnIHdyb3RlOgo+ID4gQWRkIG9wdGlvbmFsIGV4cGxpY2l0IHBpbm5pbmcgY2FsbGJh Y2tzIGluc3RlYWQgb2YgaW1wbGljaXRseSBhc3N1bWUgdGhlCj4gPiBleHBvcnRlciBwaW5zIHRo ZSBidWZmZXIgd2hlbiBhIG1hcHBpbmcgaXMgY3JlYXRlZC4KPiA+IAo+ID4gU2lnbmVkLW9mZi1i eTogQ2hyaXN0aWFuIEvDtm5pZyA8Y2hyaXN0aWFuLmtvZW5pZ0BhbWQuY29tPgo+IAo+IERvbid0 IHdlIG5lZWQgdGhpcyB0b2dldGhlciB3aXRoIHRoZSBpbnZhbGlkYXRlIGNhbGxiYWNrIGFuZCB0 aGUgZHluYW1pYwo+IHN0dWZmPyBBbHNvIEknbSBhc3N1bWluZyB0aGF0IHBpbi91bnBpbiBpcyBw cmV0dHkgbXVjaCByZXF1aXJlZCBmb3IKPiBkeW5hbWljIGJvLCBzbyBjb3VsZCB3ZSBsb29rIGF0 IHRoZXNlIGNhbGxiYWNrcyBpbnN0ZWFkIG9mIHRoZSBkeW5hbWljCj4gZmxhZyB5b3UgYWRkIGlu IHBhdGNoIDEuCj4gCj4gSSdtIGFzc3VtaW5nIGZvbGxvd2luZyBydWxlcyBob2xkOgo+IG5vIHBp bi91cGluIGZyb20gZXhwb3J0ZXI6Cj4gCj4gZG1hLWJ1ZiBpcyBub3QgZHluYW1pYywgYW5kIHBp bm5lZCBmb3IgdGhlIGR1cmF0aW9uIG9mIG1hcC91bm1hcC4gSSdtCj4gbm90IDEwMCUgc3VyZSB3 aGV0aGVyIHJlYWxseSBldmVyeW9uZSB3YW50cyB0aGUgbWFwcGluZyB0byBiZSBjYWNoZWQgZm9y Cj4gdGhlIGVudGlyZSBhdHRhY2htZW50LCBvbmx5IGRybV9wcmltZSBkb2VzIHRoYXQuIEFuZCB0 aGF0J3Mgbm90IHRoZSBvbmx5Cj4gZG1hLWJ1ZiBpbXBvcnRlci4KPiAKPiBwaW4vdW5waW4gY2Fs bHMgYXJlIG5vb3BzLgo+IAo+IHBpbi91bnBpbiBleGlzdCBpbiB0aGUgZXhwb3J0ZXIsIGJ1dCBp bXBvcnRlciBoYXMgbm90IHByb3ZpZGVkIGFuCj4gaW52YWxpZGF0ZSBjYWxsYmFjazoKPiAKPiBX ZSBtYXAgYXQgYXR0YWNoIHRpbWUsIGFuZCB3ZSBhbHNvIGhhdmUgdG8gcGluLCBzaW5jZSB0aGUg aW1wb3J0ZXIgY2FuJ3QKPiBoYW5kbGUgdGhlIGJ1ZmZlciBkaXNhcHBlYXJpbmcsIGF0IGF0dGFj aCB0aW1lLiBXZSB1bm1hcC91bnBpbiBhdCBkZXRhY2guCgpGb3IgdGhpcyBjYXNlIHdlIHNob3Vs ZCBoYXZlIGEgV0FSTiBpbiBwaW4vdW5waW4sIHRvIG1ha2Ugc3VyZSBpbXBvcnRlcnMKZG9uJ3Qg ZG8gc29tZXRoaW5nIHN0dXBpZC4gT25lIG1vcmUgdGhvdWdodCBiZWxvdyBvbiBwaW4vdW5waW4u Cgo+IHBpbi91bnBpbiBmcm9tIGV4cG9ydGVyLCBpbnZhbGlkYXRlIGZyb20gaW1wb3J0ZXI6Cj4g Cj4gRnVsbCBkeW5hbWljIG1hcHBpbmcuIFdlIGFzc3VtZSB0aGUgaW1wb3J0ZXIgd2lsbCBkbyBj YWNoaW5nLCBhdHRhY2gKPiBmZW5jZXMgYXMgbmVlZGVkLCBhbmQgcGluIHRoZSB1bmRlcmx5aW5n IGJvIHdoZW4gaXQgbmVlZHMgaXQgaXQKPiBwZXJtYW5lbnRseSwgd2l0aG91dCBhdHRhY2hpbmcg ZmVuY2VzIChpLmUuIHRoZSBzY2Fub3V0IGNhc2UpLgo+IAo+IEFzc3VtaW5nIEknbSBub3QgdGVy cmlibHkgb2ZmIHdpdGggbXkgdW5kZXJzdGFuZGluZywgdGhlbiBJIHRoaW5rIGl0J2QgYmUKPiBi ZXN0IHRvIGludHJvZHVjZSB0aGUgZW50aXJlIG5ldyBkbWEtYnVmIGFwaSBpbiB0aGUgZmlyc3Qg cGF0Y2gsIGFuZCBmbGVzaAo+IGl0IG91dCBsYXRlci4gSW5zdGVhZCBvZiBzcHJlYWQgb3ZlciBh IGZldyBwYXRjaGVzLiBQbHVzIHRoZSBhYm92ZSAobWF5YmUKPiBwcmV0dGllcikgYXMgYSBuaWNl IGtlcm5lbGRvYyBvdmVydmlldyBjb21tZW50IGZvciBob3cgZHluYW1pYyBkbWEtYnVmIGlzCj4g c3VwcG9zZWQgdG8gd29yayByZWFsbHkuCj4gLURhbmllbAo+IAo+ID4gLS0tCj4gPiAgZHJpdmVy cy9kbWEtYnVmL2RtYS1idWYuYyB8IDM5ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKwo+ID4gIGluY2x1ZGUvbGludXgvZG1hLWJ1Zi5oICAgfCAzNyArKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrLS0tLS0tCj4gPiAgMiBmaWxlcyBjaGFuZ2VkLCA3MCBpbnNlcnRp b25zKCspLCA2IGRlbGV0aW9ucygtKQo+ID4gCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9kbWEt YnVmL2RtYS1idWYuYyBiL2RyaXZlcnMvZG1hLWJ1Zi9kbWEtYnVmLmMKPiA+IGluZGV4IGEzNzM4 ZmFiMzkyNy4uZjIzZmY4MzU1NTA1IDEwMDY0NAo+ID4gLS0tIGEvZHJpdmVycy9kbWEtYnVmL2Rt YS1idWYuYwo+ID4gKysrIGIvZHJpdmVycy9kbWEtYnVmL2RtYS1idWYuYwo+ID4gQEAgLTYzMCw2 ICs2MzAsNDEgQEAgdm9pZCBkbWFfYnVmX2RldGFjaChzdHJ1Y3QgZG1hX2J1ZiAqZG1hYnVmLCBz dHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICphdHRhY2gpCj4gPiAgfQo+ID4gIEVYUE9SVF9TWU1C T0xfR1BMKGRtYV9idWZfZGV0YWNoKTsKPiA+ICAKPiA+ICsvKioKPiA+ICsgKiBkbWFfYnVmX3Bp biAtIExvY2sgZG93biB0aGUgRE1BLWJ1Zgo+ID4gKyAqCj4gPiArICogQGRtYWJ1ZjoJW2luXQlE TUEtYnVmIHRvIGxvY2sgZG93bi4KPiA+ICsgKgo+ID4gKyAqIFJldHVybnM6Cj4gPiArICogMCBv biBzdWNjZXNzLCBuZWdhdGl2ZSBlcnJvciBjb2RlIG9uIGZhaWx1cmUuCj4gPiArICovCj4gPiAr aW50IGRtYV9idWZfcGluKHN0cnVjdCBkbWFfYnVmICpkbWFidWYpCgpIbSwgSSB0aGluayBpdCdk IGJlIGJldHRlciB0byBwaW4gdGhlIGF0dGFjaG1lbnQsIG5vdCB0aGUgdW5kZXJseWluZwpidWZm ZXIuIEF0dGFjaG1lbnQgaXMgdGhlIHRoaW4gdGhlIGltcG9ydGVyIHdpbGwgaGF2ZSB0byBwaW4s IGFuZCBpdCdzIGF0CmF0dGFjaC9kZXRhY2ggdGltZSB3aGVyZSBkbWEtYnVmIG5lZWRzIHRvIHBp biBmb3IgaW1wb3J0ZXJzIHdobyBkb24ndAp1bmRlcnN0YW5kIGR5bmFtaWMgYnVmZmVyIHNoYXJp bmcuCgpQbHVzIHdoZW4gd2UgcHV0IHRoYXQgb250byBhdHRhY2htZW50cywgd2UgY2FuIGRvIGEK CglXQVJOX09OKCFhdHRhY2gtPmludmFsaWRhdGUpOwoKc2FuaXR5IGNoZWNrLiBJIHRoaW5rIHRo YXQgd291bGQgYmUgZ29vZCB0byBoYXZlLgotRGFuaWVsCgo+ID4gK3sKPiA+ICsJaW50IHJldCA9 IDA7Cj4gPiArCj4gPiArCXJlc2VydmF0aW9uX29iamVjdF9hc3NlcnRfaGVsZChkbWFidWYtPnJl c3YpOwo+ID4gKwo+ID4gKwlpZiAoZG1hYnVmLT5vcHMtPnBpbikKPiA+ICsJCXJldCA9IGRtYWJ1 Zi0+b3BzLT5waW4oZG1hYnVmKTsKPiA+ICsKPiA+ICsJcmV0dXJuIHJldDsKPiA+ICt9Cj4gPiAr RVhQT1JUX1NZTUJPTF9HUEwoZG1hX2J1Zl9waW4pOwo+ID4gKwo+ID4gKy8qKgo+ID4gKyAqIGRt YV9idWZfdW5waW4gLSBSZW1vdmUgbG9jayBmcm9tIERNQS1idWYKPiA+ICsgKgo+ID4gKyAqIEBk bWFidWY6CVtpbl0JRE1BLWJ1ZiB0byB1bmxvY2suCj4gPiArICovCj4gPiArdm9pZCBkbWFfYnVm X3VucGluKHN0cnVjdCBkbWFfYnVmICpkbWFidWYpCj4gPiArewo+ID4gKwlyZXNlcnZhdGlvbl9v YmplY3RfYXNzZXJ0X2hlbGQoZG1hYnVmLT5yZXN2KTsKPiA+ICsKPiA+ICsJaWYgKGRtYWJ1Zi0+ b3BzLT51bnBpbikKPiA+ICsJCWRtYWJ1Zi0+b3BzLT51bnBpbihkbWFidWYpOwo+ID4gK30KPiA+ ICtFWFBPUlRfU1lNQk9MX0dQTChkbWFfYnVmX3VucGluKTsKPiA+ICsKPiA+ICAvKioKPiA+ICAg KiBkbWFfYnVmX21hcF9hdHRhY2htZW50X2xvY2tlZCAtIE1hcHMgdGhlIGJ1ZmZlciBpbnRvIF9k ZXZpY2VfIGFkZHJlc3Mgc3BhY2UKPiA+ICAgKiB3aXRoIHRoZSByZXNlcnZhdGlvbiBsb2NrIGhl bGQuIElzIGEgd3JhcHBlciBmb3IgbWFwX2RtYV9idWYoKSBvZiB0aGUKPiA+IEBAIC02NjYsNiAr NzAxLDggQEAgZG1hX2J1Zl9tYXBfYXR0YWNobWVudF9sb2NrZWQoc3RydWN0IGRtYV9idWZfYXR0 YWNobWVudCAqYXR0YWNoLAo+ID4gIAkgKi8KPiA+ICAJaWYgKGF0dGFjaC0+aW52YWxpZGF0ZSkK PiA+ICAJCWxpc3RfZGVsKCZhdHRhY2gtPm5vZGUpOwo+ID4gKwllbHNlCj4gPiArCQlkbWFfYnVm X3BpbihhdHRhY2gtPmRtYWJ1Zik7Cj4gPiAgCXNnX3RhYmxlID0gYXR0YWNoLT5kbWFidWYtPm9w cy0+bWFwX2RtYV9idWYoYXR0YWNoLCBkaXJlY3Rpb24pOwo+ID4gIAlpZiAoYXR0YWNoLT5pbnZh bGlkYXRlKQo+ID4gIAkJbGlzdF9hZGQoJmF0dGFjaC0+bm9kZSwgJmF0dGFjaC0+ZG1hYnVmLT5h dHRhY2htZW50cyk7Cj4gPiBAQCAtNzM1LDYgKzc3Miw4IEBAIHZvaWQgZG1hX2J1Zl91bm1hcF9h dHRhY2htZW50X2xvY2tlZChzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICphdHRhY2gsCj4gPiAg Cj4gPiAgCWF0dGFjaC0+ZG1hYnVmLT5vcHMtPnVubWFwX2RtYV9idWYoYXR0YWNoLCBzZ190YWJs ZSwKPiA+ICAJCQkJCQlkaXJlY3Rpb24pOwo+ID4gKwlpZiAoIWF0dGFjaC0+aW52YWxpZGF0ZSkK PiA+ICsJCWRtYV9idWZfdW5waW4oYXR0YWNoLT5kbWFidWYpOwo+ID4gIH0KPiA+ICBFWFBPUlRf U1lNQk9MX0dQTChkbWFfYnVmX3VubWFwX2F0dGFjaG1lbnRfbG9ja2VkKTsKPiA+ICAKPiA+IGRp ZmYgLS1naXQgYS9pbmNsdWRlL2xpbnV4L2RtYS1idWYuaCBiL2luY2x1ZGUvbGludXgvZG1hLWJ1 Zi5oCj4gPiBpbmRleCBlY2U0NjM4MzU5YTguLmE2MTViNzRlNTg5NCAxMDA2NDQKPiA+IC0tLSBh L2luY2x1ZGUvbGludXgvZG1hLWJ1Zi5oCj4gPiArKysgYi9pbmNsdWRlL2xpbnV4L2RtYS1idWYu aAo+ID4gQEAgLTEwMCwxNCArMTAwLDQwIEBAIHN0cnVjdCBkbWFfYnVmX29wcyB7Cj4gPiAgCSAq Lwo+ID4gIAl2b2lkICgqZGV0YWNoKShzdHJ1Y3QgZG1hX2J1ZiAqLCBzdHJ1Y3QgZG1hX2J1Zl9h dHRhY2htZW50ICopOwo+ID4gIAo+ID4gKwkvKioKPiA+ICsJICogQHBpbl9kbWFfYnVmOgo+ID4g KwkgKgo+ID4gKwkgKiBUaGlzIGlzIGNhbGxlZCBieSBkbWFfYnVmX3BpbiBhbmQgbGV0cyB0aGUg ZXhwb3J0ZXIga25vdyB0aGF0IGFuCj4gPiArCSAqIGltcG9ydGVyIGFzc3VtZXMgdGhhdCB0aGUg RE1BLWJ1ZiBjYW4ndCBiZSBpbnZhbGlkYXRlZCBhbnkgbW9yZS4KPiA+ICsJICoKPiA+ICsJICog VGhpcyBpcyBjYWxsZWQgd2l0aCB0aGUgZG1hYnVmLT5yZXN2IG9iamVjdCBsb2NrZWQuCj4gPiAr CSAqCj4gPiArCSAqIFRoaXMgY2FsbGJhY2sgaXMgb3B0aW9uYWwuCj4gPiArCSAqCj4gPiArCSAq IFJldHVybnM6Cj4gPiArCSAqCj4gPiArCSAqIDAgb24gc3VjY2VzcywgbmVnYXRpdmUgZXJyb3Ig Y29kZSBvbiBmYWlsdXJlLgo+ID4gKwkgKi8KPiA+ICsJaW50ICgqcGluKShzdHJ1Y3QgZG1hX2J1 ZiAqKTsKPiA+ICsKPiA+ICsJLyoqCj4gPiArCSAqIEB1bnBpbl9kbWFfYnVmOgo+ID4gKwkgKgo+ ID4gKwkgKiBUaGlzIGlzIGNhbGxlZCBieSBkbWFfYnVmX3VucGluIGFuZCBsZXRzIHRoZSBleHBv cnRlciBrbm93IHRoYXQgYW4KPiA+ICsJICogaW1wb3J0ZXIgZG9lc24ndCBuZWVkIHRvIHRoZSBE TUEtYnVmIHRvIHN0YXkgd2VyZSBpdCBpcyBhbnkgbW9yZS4KPiA+ICsJICoKPiA+ICsJICogVGhp cyBpcyBjYWxsZWQgd2l0aCB0aGUgZG1hYnVmLT5yZXN2IG9iamVjdCBsb2NrZWQuCj4gPiArCSAq Cj4gPiArCSAqIFRoaXMgY2FsbGJhY2sgaXMgb3B0aW9uYWwuCj4gPiArCSAqLwo+ID4gKwl2b2lk ICgqdW5waW4pKHN0cnVjdCBkbWFfYnVmICopOwo+ID4gKwo+ID4gIAkvKioKPiA+ICAJICogQG1h cF9kbWFfYnVmOgo+ID4gIAkgKgo+ID4gIAkgKiBUaGlzIGlzIGNhbGxlZCBieSBkbWFfYnVmX21h cF9hdHRhY2htZW50KCkgYW5kIGlzIHVzZWQgdG8gbWFwIGEKPiA+ICAJICogc2hhcmVkICZkbWFf YnVmIGludG8gZGV2aWNlIGFkZHJlc3Mgc3BhY2UsIGFuZCBpdCBpcyBtYW5kYXRvcnkuIEl0Cj4g PiAtCSAqIGNhbiBvbmx5IGJlIGNhbGxlZCBpZiBAYXR0YWNoIGhhcyBiZWVuIGNhbGxlZCBzdWNj ZXNzZnVsbHkuIFRoaXMKPiA+IC0JICogZXNzZW50aWFsbHkgcGlucyB0aGUgRE1BIGJ1ZmZlciBp bnRvIHBsYWNlLCBhbmQgaXQgY2Fubm90IGJlIG1vdmVkCj4gPiAtCSAqIGFueSBtb3JlCj4gPiAr CSAqIGNhbiBvbmx5IGJlIGNhbGxlZCBpZiBAYXR0YWNoIGhhcyBiZWVuIGNhbGxlZCBzdWNjZXNz ZnVsbHkuCj4gPiAgCSAqCj4gPiAgCSAqIFRoaXMgY2FsbCBtYXkgc2xlZXAsIGUuZy4gd2hlbiB0 aGUgYmFja2luZyBzdG9yYWdlIGZpcnN0IG5lZWRzIHRvIGJlCj4gPiAgCSAqIGFsbG9jYXRlZCwg b3IgbW92ZWQgdG8gYSBsb2NhdGlvbiBzdWl0YWJsZSBmb3IgYWxsIGN1cnJlbnRseSBhdHRhY2hl ZAo+ID4gQEAgLTE0OCw5ICsxNzQsNiBAQCBzdHJ1Y3QgZG1hX2J1Zl9vcHMgewo+ID4gIAkgKgo+ ID4gIAkgKiBUaGlzIGlzIGNhbGxlZCBieSBkbWFfYnVmX3VubWFwX2F0dGFjaG1lbnQoKSBhbmQg c2hvdWxkIHVubWFwIGFuZAo+ID4gIAkgKiByZWxlYXNlIHRoZSAmc2dfdGFibGUgYWxsb2NhdGVk IGluIEBtYXBfZG1hX2J1ZiwgYW5kIGl0IGlzIG1hbmRhdG9yeS4KPiA+IC0JICogSXQgc2hvdWxk IGFsc28gdW5waW4gdGhlIGJhY2tpbmcgc3RvcmFnZSBpZiB0aGlzIGlzIHRoZSBsYXN0IG1hcHBp bmcKPiA+IC0JICogb2YgdGhlIERNQSBidWZmZXIsIGl0IHRoZSBleHBvcnRlciBzdXBwb3J0cyBi YWNraW5nIHN0b3JhZ2UKPiA+IC0JICogbWlncmF0aW9uLgo+ID4gIAkgKgo+ID4gIAkgKiBUaGlz IGlzIGFsd2F5cyBjYWxsZWQgd2l0aCB0aGUgZG1hYnVmLT5yZXN2IG9iamVjdCBsb2NrZWQgd2hl bgo+ID4gIAkgKiBub19zZ3RfY2FjaGUgaXMgdHJ1ZS4KPiA+IEBAIC00NDIsNiArNDY1LDggQEAg aW50IGRtYV9idWZfZmQoc3RydWN0IGRtYV9idWYgKmRtYWJ1ZiwgaW50IGZsYWdzKTsKPiA+ICBz dHJ1Y3QgZG1hX2J1ZiAqZG1hX2J1Zl9nZXQoaW50IGZkKTsKPiA+ICB2b2lkIGRtYV9idWZfcHV0 KHN0cnVjdCBkbWFfYnVmICpkbWFidWYpOwo+ID4gIAo+ID4gK2ludCBkbWFfYnVmX3BpbihzdHJ1 Y3QgZG1hX2J1ZiAqZG1hYnVmKTsKPiA+ICt2b2lkIGRtYV9idWZfdW5waW4oc3RydWN0IGRtYV9i dWYgKmRtYWJ1Zik7Cj4gPiAgc3RydWN0IHNnX3RhYmxlICpkbWFfYnVmX21hcF9hdHRhY2htZW50 X2xvY2tlZChzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICosCj4gPiAgCQkJCQkgICAgICAgZW51 bSBkbWFfZGF0YV9kaXJlY3Rpb24pOwo+ID4gIHN0cnVjdCBzZ190YWJsZSAqZG1hX2J1Zl9tYXBf YXR0YWNobWVudChzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICosCj4gPiAtLSAKPiA+IDIuMTcu MQo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+ID4gZHJpLWRldmVsIG1haWxpbmcgbGlzdAo+ID4gZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNr dG9wLm9yZwo+ID4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5m by9kcmktZGV2ZWwKPiAKPiAtLSAKPiBEYW5pZWwgVmV0dGVyCj4gU29mdHdhcmUgRW5naW5lZXIs IEludGVsIENvcnBvcmF0aW9uCj4gaHR0cDovL2Jsb2cuZmZ3bGwuY2gKCi0tIApEYW5pZWwgVmV0 dGVyClNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgpodHRwOi8vYmxvZy5mZnds bC5jaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwphbWQt Z2Z4IG1haWxpbmcgbGlzdAphbWQtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FtZC1nZng= 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 ED635C282DC for ; Wed, 17 Apr 2019 14:31:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A75FA21773 for ; Wed, 17 Apr 2019 14:31:01 +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="jz7yfzJe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732369AbfDQOa4 (ORCPT ); Wed, 17 Apr 2019 10:30:56 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:43717 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729453AbfDQOa4 (ORCPT ); Wed, 17 Apr 2019 10:30:56 -0400 Received: by mail-ed1-f66.google.com with SMTP id j20so10963342edq.10 for ; Wed, 17 Apr 2019 07:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=UtwXfgHiW9uxr4io2NrLhIlt9faL/SpYVdNzzRRZdyE=; b=jz7yfzJePU9xVKg98q0j9gYBrMPepskYacPVPUSRTBKqyYiX04AHNuRcrz7uRDO/8f ys4BD+WkVNbAA/cRFZ8tWp1Ts0mtTJL8ejOnPFUOZAeOFVIjMMQgmSap1cXh75O5pb1h NxFTEug9hca9QghD86YEpDGy3ntZbtdmKrHVA= 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:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=UtwXfgHiW9uxr4io2NrLhIlt9faL/SpYVdNzzRRZdyE=; b=NfTn2otP/yVCwlifDz19jVx4Yu6mTC57CIQ3uQnNzSrN1jhGnWzTQK4b2z9jFFCcMQ LWLyTQc+M6329bsEMNu5rCTS6Ol7QoF6dAc7tybhvISadVEm5iX9/X7d4QHRQ1Xk3QCs j4KjSUwVcMP5biVCFr426mVK6EOWNeQKlXcxIOALyv0V1MMwvSHovEYsNMKddwUMns38 zMkIcQeHFzhqu8PUXsRYq9ifXiVIJn/YEmzjt7bbtcZc2dquY1rwFdi/t289269xEQgn lbSJx7mBz2N9uWrBR/h0hptQkpgmbvcge972xrpFxBZoe6TKBcdNAKfyj7Zkavx6Oybo 4W2Q== X-Gm-Message-State: APjAAAVsR4+9RCJxtf+Bdj2HPlF1Y2ORG3JHfaSgHNf0cXhJknvLQ4Di NqVuxqMyAzCbMHUrKES2nBr/4drLHSY= X-Google-Smtp-Source: APXvYqxy1+5aJUdsuQrBfB1YwfPwwMbZ3cdbG1XS9RQBH621Drh22ZrDRGjDIz7yVQp0NbCbwbGmMw== X-Received: by 2002:a17:906:a291:: with SMTP id i17mr7689751ejz.180.1555511453952; Wed, 17 Apr 2019 07:30:53 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id j8sm4891124edq.39.2019.04.17.07.30.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 07:30:53 -0700 (PDT) Date: Wed, 17 Apr 2019 16:30:51 +0200 From: Daniel Vetter 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 Subject: Re: [PATCH 05/12] dma-buf: add explicit buffer pinning Message-ID: <20190417143051.GG13337@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> <20190417142002.GE13337@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190417142002.GE13337@phenom.ffwll.local> 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 Wed, Apr 17, 2019 at 04:20:02PM +0200, Daniel Vetter wrote: > 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. For this case we should have a WARN in pin/unpin, to make sure importers don't do something stupid. One more thought below on pin/unpin. > 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) Hm, I think it'd be better to pin the attachment, not the underlying buffer. Attachment is the thin the importer will have to pin, and it's at attach/detach time where dma-buf needs to pin for importers who don't understand dynamic buffer sharing. Plus when we put that onto attachments, we can do a WARN_ON(!attach->invalidate); sanity check. I think that would be good to have. -Daniel > > +{ > > + 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch