From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 04/12] dma-buf: add optional invalidate_mappings callback v5 Date: Thu, 18 Apr 2019 10:40:31 +0200 Message-ID: <20190418084031.GT13337@phenom.ffwll.local> References: <20190416183841.1577-1-christian.koenig@amd.com> <20190416183841.1577-5-christian.koenig@amd.com> <20190417190719.GL13337@phenom.ffwll.local> <03a04d1d-9bc0-8f20-0436-b0f0017f0506@gmail.com> <20190418080826.GN13337@phenom.ffwll.local> <0611f62c-2b81-b85f-a8d9-69c3daf0c635@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: <0611f62c-2b81-b85f-a8d9-69c3daf0c635@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: "Koenig, Christian" Cc: "linux-kernel@vger.kernel.org" , "amd-gfx@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "dri-devel@lists.freedesktop.org" , "linux-media@vger.kernel.org" List-Id: amd-gfx.lists.freedesktop.org T24gVGh1LCBBcHIgMTgsIDIwMTkgYXQgMDg6Mjg6NTFBTSArMDAwMCwgS29lbmlnLCBDaHJpc3Rp YW4gd3JvdGU6Cj4gQW0gMTguMDQuMTkgdW0gMTA6MDggc2NocmllYiBEYW5pZWwgVmV0dGVyOgo+ ID4gT24gV2VkLCBBcHIgMTcsIDIwMTkgYXQgMDk6MTM6MjJQTSArMDIwMCwgQ2hyaXN0aWFuIEvD tm5pZyB3cm90ZToKPiA+PiBBbSAxNy4wNC4xOSB1bSAyMTowNyBzY2hyaWViIERhbmllbCBWZXR0 ZXI6Cj4gPj4+IE9uIFR1ZSwgQXByIDE2LCAyMDE5IGF0IDA4OjM4OjMzUE0gKzAyMDAsIENocmlz dGlhbiBLw7ZuaWcgd3JvdGU6Cj4gPj4+PiBFYWNoIGltcG9ydGVyIGNhbiBub3cgcHJvdmlkZSBh biBpbnZhbGlkYXRlX21hcHBpbmdzIGNhbGxiYWNrLgo+ID4+Pj4KPiA+Pj4+IFRoaXMgYWxsb3dz IHRoZSBleHBvcnRlciB0byBwcm92aWRlIHRoZSBtYXBwaW5ncyB3aXRob3V0IHRoZSBuZWVkIHRv IHBpbgo+ID4+Pj4gdGhlIGJhY2tpbmcgc3RvcmUuCj4gPj4+Pgo+ID4+Pj4gdjI6IGRvbid0IHRy eSB0byBpbnZhbGlkYXRlIG1hcHBpbmdzIHdoZW4gdGhlIGNhbGxiYWNrIGlzIE5VTEwsCj4gPj4+ PiAgICAgICBsb2NrIHRoZSByZXNlcnZhdGlvbiBvYmogd2hpbGUgdXNpbmcgdGhlIGF0dGFjaG1l bnRzLAo+ID4+Pj4gICAgICAgYWRkIGhlbHBlciB0byBzZXQgdGhlIGNhbGxiYWNrCj4gPj4+PiB2 MzogbW92ZSBmbGFnIGZvciBpbnZhbGlkYXRpb24gc3VwcG9ydCBpbnRvIHRoZSBETUEtYnVmLAo+ ID4+Pj4gICAgICAgdXNlIG5ldyBhdHRhY2hfaW5mbyBzdHJ1Y3R1cmUgdG8gc2V0IHRoZSBjYWxs YmFjawo+ID4+Pj4gdjQ6IHVzZSBpbXBvcnRlcl9wcml2IGZpZWxkIGluc3RlYWQgb2YgbWFuZ2xp bmcgZXhwb3J0ZXIgcHJpdi4KPiA+Pj4+IHY1OiBkcm9wIGludmFsaWRhdGlvbl9zdXBwb3J0ZWQg ZmxhZwo+ID4+Pj4KPiA+Pj4+IFNpZ25lZC1vZmYtYnk6IENocmlzdGlhbiBLw7ZuaWcgPGNocmlz dGlhbi5rb2VuaWdAYW1kLmNvbT4KPiA+Pj4+IC0tLQo+ID4+Pj4gICAgZHJpdmVycy9kbWEtYnVm L2RtYS1idWYuYyB8IDM3ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPiA+ Pj4+ICAgIGluY2x1ZGUvbGludXgvZG1hLWJ1Zi5oICAgfCAzMyArKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrLS0KPiA+Pj4+ICAgIDIgZmlsZXMgY2hhbmdlZCwgNjggaW5zZXJ0aW9ucygr KSwgMiBkZWxldGlvbnMoLSkKPiA+Pj4+Cj4gPj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9kbWEt YnVmL2RtYS1idWYuYyBiL2RyaXZlcnMvZG1hLWJ1Zi9kbWEtYnVmLmMKPiA+Pj4+IGluZGV4IDgz YzkyYmZkOTY0Yy4uYTM3MzhmYWIzOTI3IDEwMDY0NAo+ID4+Pj4gLS0tIGEvZHJpdmVycy9kbWEt YnVmL2RtYS1idWYuYwo+ID4+Pj4gKysrIGIvZHJpdmVycy9kbWEtYnVmL2RtYS1idWYuYwo+ID4+ Pj4gQEAgLTU2Myw2ICs1NjMsOCBAQCBzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICpkbWFfYnVm X2F0dGFjaChjb25zdCBzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2hfaW5mbyAqaW5mbwo+ID4+Pj4gICAg CWF0dGFjaC0+ZGV2ID0gaW5mby0+ZGV2Owo+ID4+Pj4gICAgCWF0dGFjaC0+ZG1hYnVmID0gZG1h YnVmOwo+ID4+Pj4gKwlhdHRhY2gtPmltcG9ydGVyX3ByaXYgPSBpbmZvLT5pbXBvcnRlcl9wcml2 Owo+ID4+Pj4gKwlhdHRhY2gtPmludmFsaWRhdGUgPSBpbmZvLT5pbnZhbGlkYXRlOwo+ID4+Pj4g ICAgCW11dGV4X2xvY2soJmRtYWJ1Zi0+bG9jayk7Cj4gPj4+PiBAQCAtNTcxLDcgKzU3Myw5IEBA IHN0cnVjdCBkbWFfYnVmX2F0dGFjaG1lbnQgKmRtYV9idWZfYXR0YWNoKGNvbnN0IHN0cnVjdCBk bWFfYnVmX2F0dGFjaF9pbmZvICppbmZvCj4gPj4+PiAgICAJCWlmIChyZXQpCj4gPj4+PiAgICAJ CQlnb3RvIGVycl9hdHRhY2g7Cj4gPj4+PiAgICAJfQo+ID4+Pj4gKwlyZXNlcnZhdGlvbl9vYmpl Y3RfbG9jayhkbWFidWYtPnJlc3YsIE5VTEwpOwo+ID4+Pj4gICAgCWxpc3RfYWRkKCZhdHRhY2gt Pm5vZGUsICZkbWFidWYtPmF0dGFjaG1lbnRzKTsKPiA+Pj4+ICsJcmVzZXJ2YXRpb25fb2JqZWN0 X3VubG9jayhkbWFidWYtPnJlc3YpOwo+ID4+Pj4gICAgCW11dGV4X3VubG9jaygmZG1hYnVmLT5s b2NrKTsKPiA+Pj4+IEBAIC02MTUsNyArNjE5LDkgQEAgdm9pZCBkbWFfYnVmX2RldGFjaChzdHJ1 Y3QgZG1hX2J1ZiAqZG1hYnVmLCBzdHJ1Y3QgZG1hX2J1Zl9hdHRhY2htZW50ICphdHRhY2gpCj4g Pj4+PiAgICAJCQkJCSAgIERNQV9CSURJUkVDVElPTkFMKTsKPiA+Pj4+ICAgIAltdXRleF9sb2Nr KCZkbWFidWYtPmxvY2spOwo+ID4+Pj4gKwlyZXNlcnZhdGlvbl9vYmplY3RfbG9jayhkbWFidWYt PnJlc3YsIE5VTEwpOwo+ID4+Pj4gICAgCWxpc3RfZGVsKCZhdHRhY2gtPm5vZGUpOwo+ID4+Pj4g KwlyZXNlcnZhdGlvbl9vYmplY3RfdW5sb2NrKGRtYWJ1Zi0+cmVzdik7Cj4gPj4+PiAgICAJaWYg KGRtYWJ1Zi0+b3BzLT5kZXRhY2gpCj4gPj4+PiAgICAJCWRtYWJ1Zi0+b3BzLT5kZXRhY2goZG1h YnVmLCBhdHRhY2gpOwo+ID4+Pj4gQEAgLTY1Myw3ICs2NTksMTYgQEAgZG1hX2J1Zl9tYXBfYXR0 YWNobWVudF9sb2NrZWQoc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCAqYXR0YWNoLAo+ID4+Pj4g ICAgCWlmIChhdHRhY2gtPnNndCkKPiA+Pj4+ICAgIAkJcmV0dXJuIGF0dGFjaC0+c2d0Owo+ID4+ Pj4gKwkvKgo+ID4+Pj4gKwkgKiBNYXBwaW5nIGEgRE1BLWJ1ZiBjYW4gdHJpZ2dlciBpdHMgaW52 YWxpZGF0aW9uLCBwcmV2ZW50IHNlbmRpbmcgdGhpcwo+ID4+Pj4gKwkgKiBldmVudCB0byB0aGUg Y2FsbGVyIGJ5IHRlbXBvcmFyeSByZW1vdmluZyB0aGlzIGF0dGFjaG1lbnQgZnJvbSB0aGUKPiA+ Pj4+ICsJICogbGlzdC4KPiA+Pj4+ICsJICovCj4gPj4+PiArCWlmIChhdHRhY2gtPmludmFsaWRh dGUpCj4gPj4+PiArCQlsaXN0X2RlbCgmYXR0YWNoLT5ub2RlKTsKPiA+Pj4gSnVzdCBub3RpY2Vk IHRoaXM6IFdoeSBkbyB3ZSBuZWVkIHRoaXM/IGludmFsaWRhdGUgbmVlZHMgdGhlIHJlc2VydmF0 aW9uCj4gPj4+IGxvY2ssIGFzIGRvZXMgbWFwX2F0dGFjaG1lbnQuIEl0IHNob3VsZCBiZSBpbXBz c29ibGUgdG8gaGF2ZSBzb21lb25lIGVsc2UKPiA+Pj4gc25lYWsgaW4gaGVyZS4KPiA+PiBJIHdh cyBoYXZpbmcgcHJvYmxlbXMgd2l0aCBzZWxmIHRyaWdnZXJlZCBpbnZhbGlkYXRpb25zLgo+ID4+ Cj4gPj4gRS5nLiBjbGllbnQgQSB0cmllcyB0byBtYXAgYW4gYXR0YWNobWVudCwgdGhhdCBpbiB0 dXJuIGNhdXNlcyB0aGUgYnVmZmVyIHRvCj4gPj4gbW92ZSB0byBhIG5ldyBwbGFjZSBhbmQgY2xp ZW50IEEgaXMgaW5mb3JtZWQgYWJvdXQgdGhhdCBtb3ZlbWVudCB3aXRoIGFuCj4gPj4gaW52YWxp ZGF0aW9uLgo+ID4gVWgsIHRoYXQgc291bmRzIGxpa2UgYSBidWcgaW4gdHRtIG9yIHNvbWV3aGVy ZSBlbHNlIGluIHRoZSBleHBvcnRlci4gSWYKPiA+IHlvdSBldmljdCB0aGUgYm8gdGhhdCB5b3Un cmUgdHJ5aW5nIHRvIG1hcCwgdGhhdCdzIGJhZC4KPiA+Cj4gPiBPciBtYXliZSBpdCdzIGEgZnJh bWV3b3JrIGJ1ZywgYW5kIHdlIG5lZWQgdG8gdHJhY2sgd2hldGhlciBhbiBhdHRhY2htZW50Cj4g PiBoYXMgYSBtYXAgb3Igbm90LiBUaGF0IHdvdWxkIG1ha2UgbW9yZSBzZW5zZSAuLi4KPiAKPiBX ZWxsIG5laXRoZXIsIGFzIGZhciBhcyBJIGNhbiBzZWUgdGhpcyBpcyBwZXJmZWN0bHkgbm9ybWFs IGJlaGF2aW9yLgo+IAo+IFdlIGp1c3QgZG9uJ3Qgd2FudCBhbnkgaW52YWxpZGF0aW9uIHNlbmQg dG8gYSBkcml2ZXIgd2hpY2ggaXMgY3VycmVudGx5IAo+IG1ha2luZyBhIG1hcHBpbmcuCj4gCj4g SWYgeW91IHdhbnQgSSBjYW4gZG8gdGhpcyBpbiB0aGUgZHJpdmVyIGFzIHdlbGwsIGJ1dCBhdCBs ZWFzdCBvZiBoYW5kIGl0IAo+IGxvb2tzIGxpa2UgYSBnb29kIGlkZWEgdG8gaGF2ZSB0aGF0IGlu IGNvbW1vbiBjb2RlLgoKSG0uIFRoaXMgc291bmRzIGxpa2Ugd2UnZCB3YW50IHRvIGludmFsaWRh dGUgYSBzcGVjaWZpYyBtYXBwaW5nLgoKPiBUcmFja2luZyB0aGUgbWFwcGluZ3MgY291bGQgd29y ayBhcyB3ZWxsLCBidXQgdGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IEkgCj4gYWN0dWFsbHkgd2Fu dCB0aGUgbGlmZXRpbWUgb2Ygb2xkIGFuZCBuZXcgbWFwcGluZ3MgdG8gb3ZlcmxhcCBmb3IgCj4g cGlwZWxpbmluZy4KCkFzaWRlOiBPdmVybGFwcGluZyBtYXBwaW5ncyBiZWluZyBleHBsaWNpdGx5 IGFsbG93ZWQgc2hvdWxkIGJlIGluIHRoZQpkb2NzLiBUaGUgY3VycmVudCBrZXJuZWxkb2MgZm9y IGludmFsaWRhdGUgbGVhdmVzIHRoYXQgdXAgZm9yCmludGVycHJldGF0aW9uLiBUaGlzIGFuc3dl cnMgb25lIG9mIHRoZSBxdWVzdGlvbnMgSSBoYWQgb3Zlcm5pZ2h0LCBhYm91dAp3aGV0aGVyIHdl IGV4cGVjdCAtPmludmFsaWRhdGUgdG8gdGVhciBkb3duIHRoZSBtYXBwaW5nIG9yIG5vdC4KCklt byBhIGJldHRlciBzZW1hbnRpY3Mgd291bGQgYmUgdGhhdCAtPmludmFsaWRhdGUgbXVzdCB0ZWFy IGRvd24gdGhlCm1hcHBpbmcsIGJ1dCB0aGUgZXhwb3J0ZXIgbXVzdCBkZWxheSBhY3R1YWwgdW5t YXAgdW50aWwgYWxsIGZlbmNlcyBoYXZlCmNsZWFyZWQuIE90aGVyd2lzZSB5b3UgY291bGQgZW5k IHVwIHdpdGggZnVuIHN0dWZmIHdoZXJlIHRoZSBleHBvcnRlcgpyZWxlYXNlcyB0aGUgbWVtb3J5 IChpdCB3YW50ZWQgdG8gaW52YWxpZGF0ZSBhZnRlciBhbGwpLCB3aGlsZSB0aGUKaW1wb3J0ZXIg c3RpbGwgaGFzIGEgbWFwcGluZyBhcm91bmQuIFRoYXQncyBub3QgZ29pbmcgdG8gZW5kIHdlbGwg SSB0aGluay4KClRoYXQgd291bGQgYWxzbyBzb2x2ZSB0aGUgaXNzdWUgb2YgZ2V0dGluZyBhbiBp bnZhbGlkYXRlIHdoaWxlIHlvdSBtYXAsIGF0CmxlYXN0IGlmIHdlIGZpbHRlciBwZXIgYXR0YWNo bWVudC4KLURhbmllbAotLSAKRGFuaWVsIFZldHRlcgpTb2Z0d2FyZSBFbmdpbmVlciwgSW50ZWwg Q29ycG9yYXRpb24KaHR0cDovL2Jsb2cuZmZ3bGwuY2gKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxt YW4vbGlzdGluZm8vZHJpLWRldmVs 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,USER_AGENT_MUTT autolearn=ham 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 54646C10F0B for ; Thu, 18 Apr 2019 08:40:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 13E9220835 for ; Thu, 18 Apr 2019 08:40:37 +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="c8Yk1ofh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388287AbfDRIkg (ORCPT ); Thu, 18 Apr 2019 04:40:36 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:39859 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388197AbfDRIkg (ORCPT ); Thu, 18 Apr 2019 04:40:36 -0400 Received: by mail-wr1-f66.google.com with SMTP id j9so1901435wrn.6 for ; Thu, 18 Apr 2019 01:40:34 -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=skwtDJD9rjBC757Fuf+izswt3O0Gl6Gh8+xaj/p0/Tw=; b=c8Yk1ofhJWF4O9IC2vM1bVcCmr7c+dnn+9a1M7zDyrIbvdc7cKvTAojow1eR3ul7XD GjuTUcdCJ3A6yx4oLchdxcF3cA//5z+h93WYU7RYu42VhEYK+BPGY3hG1K1iqbWni46Y wB7g2yA7OS4UC02D2QsROPNx7LOO1JbwYUJJk= 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=skwtDJD9rjBC757Fuf+izswt3O0Gl6Gh8+xaj/p0/Tw=; b=FlVRlkF9W5ZD6cOo7tM8yRgLrVJAl6MHjW81M7M9Q/1I6Nw6mBi1oo4y9pT5t1SY5e m2KZM6/DmhOLi4E7It4rDMHq7BC0IEP/3P8zsbdomp1szsWv508SLu428PjFV/6d6uhf Tq2gBIxSK5Qu2ovb6jPWvuGuryOfT+gvSswSmt0dF8cXGGcN2MvReIILnojX8McAVn4C ev9sMF5jqhZXEJ0WnDT3GPi2u9Z8QbawY2YSrOjxMIVWs8SOSU8C450VGSiNGChIxbk8 FjXoWHUQzOxm/o7c4Z3W57HMKgLcTYa3R+292p2Bj8MusOzxmzVNOYzZoDtrsBaJeQys o6hw== X-Gm-Message-State: APjAAAWV5vb3bKaQfqNUx25xYg3++kOycOJz/STITuTQTUdDoQp4JWyF 9BPOEHD2P0JHSJt9CSf4HNgf2w== X-Google-Smtp-Source: APXvYqxbgpo3TqiwMefXU/0IbE3MGyWCgheWi0qqGnGg9D4MF1o2jz9zTh5kY/l8BghYa1aYV1xsAA== X-Received: by 2002:adf:fc0b:: with SMTP id i11mr23417044wrr.145.1555576833887; Thu, 18 Apr 2019 01:40:33 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id d4sm1349416wrv.42.2019.04.18.01.40.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Apr 2019 01:40:33 -0700 (PDT) Date: Thu, 18 Apr 2019 10:40:31 +0200 From: Daniel Vetter To: "Koenig, Christian" 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 04/12] dma-buf: add optional invalidate_mappings callback v5 Message-ID: <20190418084031.GT13337@phenom.ffwll.local> Mail-Followup-To: "Koenig, Christian" , "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-5-christian.koenig@amd.com> <20190417190719.GL13337@phenom.ffwll.local> <03a04d1d-9bc0-8f20-0436-b0f0017f0506@gmail.com> <20190418080826.GN13337@phenom.ffwll.local> <0611f62c-2b81-b85f-a8d9-69c3daf0c635@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0611f62c-2b81-b85f-a8d9-69c3daf0c635@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 Thu, Apr 18, 2019 at 08:28:51AM +0000, Koenig, Christian wrote: > Am 18.04.19 um 10:08 schrieb Daniel Vetter: > > On Wed, Apr 17, 2019 at 09:13:22PM +0200, Christian König wrote: > >> Am 17.04.19 um 21:07 schrieb Daniel Vetter: > >>> On Tue, Apr 16, 2019 at 08:38:33PM +0200, 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, > >>>> lock the reservation obj while using the attachments, > >>>> add helper to set the callback > >>>> v3: move flag for invalidation support into the DMA-buf, > >>>> use new attach_info structure to set the callback > >>>> v4: use importer_priv field instead of mangling exporter priv. > >>>> v5: drop invalidation_supported flag > >>>> > >>>> Signed-off-by: Christian König > >>>> --- > >>>> drivers/dma-buf/dma-buf.c | 37 +++++++++++++++++++++++++++++++++++++ > >>>> include/linux/dma-buf.h | 33 +++++++++++++++++++++++++++++++-- > >>>> 2 files changed, 68 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > >>>> index 83c92bfd964c..a3738fab3927 100644 > >>>> --- a/drivers/dma-buf/dma-buf.c > >>>> +++ b/drivers/dma-buf/dma-buf.c > >>>> @@ -563,6 +563,8 @@ struct dma_buf_attachment *dma_buf_attach(const struct dma_buf_attach_info *info > >>>> attach->dev = info->dev; > >>>> attach->dmabuf = dmabuf; > >>>> + attach->importer_priv = info->importer_priv; > >>>> + attach->invalidate = info->invalidate; > >>>> mutex_lock(&dmabuf->lock); > >>>> @@ -571,7 +573,9 @@ struct dma_buf_attachment *dma_buf_attach(const struct dma_buf_attach_info *info > >>>> if (ret) > >>>> goto err_attach; > >>>> } > >>>> + reservation_object_lock(dmabuf->resv, NULL); > >>>> list_add(&attach->node, &dmabuf->attachments); > >>>> + reservation_object_unlock(dmabuf->resv); > >>>> mutex_unlock(&dmabuf->lock); > >>>> @@ -615,7 +619,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) > >>>> DMA_BIDIRECTIONAL); > >>>> mutex_lock(&dmabuf->lock); > >>>> + reservation_object_lock(dmabuf->resv, NULL); > >>>> list_del(&attach->node); > >>>> + reservation_object_unlock(dmabuf->resv); > >>>> if (dmabuf->ops->detach) > >>>> dmabuf->ops->detach(dmabuf, attach); > >>>> @@ -653,7 +659,16 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment *attach, > >>>> if (attach->sgt) > >>>> return attach->sgt; > >>>> + /* > >>>> + * Mapping a DMA-buf can trigger its invalidation, prevent sending this > >>>> + * event to the caller by temporary removing this attachment from the > >>>> + * list. > >>>> + */ > >>>> + if (attach->invalidate) > >>>> + list_del(&attach->node); > >>> Just noticed this: Why do we need this? invalidate needs the reservation > >>> lock, as does map_attachment. It should be impssoble to have someone else > >>> sneak in here. > >> I was having problems with self triggered invalidations. > >> > >> E.g. client A tries to map an attachment, that in turn causes the buffer to > >> move to a new place and client A is informed about that movement with an > >> invalidation. > > Uh, that sounds like a bug in ttm or somewhere else in the exporter. If > > you evict the bo that you're trying to map, that's bad. > > > > Or maybe it's a framework bug, and we need to track whether an attachment > > has a map or not. That would make more sense ... > > Well neither, as far as I can see this is perfectly normal behavior. > > We just don't want any invalidation send to a driver which is currently > making a mapping. > > If you want I can do this in the driver as well, but at least of hand it > looks like a good idea to have that in common code. Hm. This sounds like we'd want to invalidate a specific mapping. > Tracking the mappings could work as well, but the problem here is that I > actually want the lifetime of old and new mappings to overlap for > pipelining. Aside: Overlapping mappings being explicitly allowed should be in the docs. The current kerneldoc for invalidate leaves that up for interpretation. This answers one of the questions I had overnight, about whether we expect ->invalidate to tear down the mapping or not. Imo a better semantics would be that ->invalidate must tear down the mapping, but the exporter must delay actual unmap until all fences have cleared. Otherwise you could end up with fun stuff where the exporter releases the memory (it wanted to invalidate after all), while the importer still has a mapping around. That's not going to end well I think. That would also solve the issue of getting an invalidate while you map, at least if we filter per attachment. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch