From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Deucher, Alexander" Subject: RE: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2 Date: Wed, 7 Jun 2017 03:50:10 +0000 Message-ID: References: <1494348547-1465-1-git-send-email-deathsimple@vodafone.de> <1494348547-1465-6-git-send-email-deathsimple@vodafone.de> <20170601201430.GC12257@bhelgaas-glaptop.roam.corp.google.com> <72e061a5-9684-06e2-3021-80de8ca97bd7@vodafone.de> <20170602202631.GA1452@bhelgaas-glaptop.roam.corp.google.com> <779a883a-265a-ae04-b0cd-8cb3599f0dc0@vodafone.de> <20170606231019.GC12672@bhelgaas-glaptop.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170606231019.GC12672@bhelgaas-glaptop.roam.corp.google.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: 'Bjorn Helgaas' , =?iso-8859-1?Q?Christian_K=F6nig?= Cc: "linux-pci@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" , "platform-driver-x86@vger.kernel.org" List-Id: platform-driver-x86.vger.kernel.org PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEJqb3JuIEhlbGdhYXMgW21haWx0 bzpoZWxnYWFzQGtlcm5lbC5vcmddCj4gU2VudDogVHVlc2RheSwgSnVuZSAwNiwgMjAxNyA3OjEw IFBNCj4gVG86IENocmlzdGlhbiBLw7ZuaWcKPiBDYzogbGludXgtcGNpQHZnZXIua2VybmVsLm9y ZzsgcGxhdGZvcm0tZHJpdmVyLXg4NkB2Z2VyLmtlcm5lbC5vcmc7Cj4gRGV1Y2hlciwgQWxleGFu ZGVyOyBEYXZpZCBBaXJsaWU7IGFtZC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnOyBkcmktCj4g ZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NiA1LzVd IGRybS9hbWRncHU6IHJlc2l6ZSBWUkFNIEJBUiBmb3IgQ1BVIGFjY2Vzcwo+IHYyCj4gCj4gT24g VHVlLCBKdW4gMDYsIDIwMTcgYXQgMDE6NTE6MTFQTSArMDIwMCwgQ2hyaXN0aWFuIEvDtm5pZyB3 cm90ZToKPiA+IEFtIDAyLjA2LjIwMTcgdW0gMjI6MjYgc2NocmllYiBCam9ybiBIZWxnYWFzOgo+ ID4gPk9uIEZyaSwgSnVuIDAyLCAyMDE3IGF0IDExOjMyOjIxQU0gKzAyMDAsIENocmlzdGlhbiBL w7ZuaWcgd3JvdGU6Cj4gPiA+PkhpIEJqb3JuLAo+ID4gPj4KPiA+ID4+c29ycnkgZm9yIG5vdCBy ZXNwb25kaW5nIGVhcmxpZXIgYW5kIHRoYW5rcyBmb3IgcGlja2luZyB0aGlzIHRocmVhZAo+ID4g Pj51cCBhZ2Fpbi4KPiA+ID4+Cj4gPiA+PkFtIDAxLjA2LjIwMTcgdW0gMjI6MTQgc2NocmllYiBC am9ybiBIZWxnYWFzOgo+ID4gPj4+WytjYyBBRE1HUFUsIERSTSBmb2xrc10KPiA+ID4+Pgo+ID4g Pj4+T24gVHVlLCBNYXkgMDksIDIwMTcgYXQgMDY6NDk6MDdQTSArMDIwMCwgQ2hyaXN0aWFuIEvD tm5pZyB3cm90ZToKPiA+ID4+Pj5bU05JUF0KPiA+ID4+Pj4rLyoqCj4gPiA+Pj4+KyAqIGFtZGdw dV9yZXNpemVfYmFyMCAtIHRyeSB0byByZXNpemUgQkFSMAo+ID4gPj4+PisgKgo+ID4gPj4+Pisg KiBAYWRldjogYW1kZ3B1X2RldmljZSBwb2ludGVyCj4gPiA+Pj4+KyAqCj4gPiA+Pj4+KyAqIFRy eSB0byByZXNpemUgQkFSMCB0byBtYWtlIGFsbCBWUkFNIENQVSBhY2Nlc3NpYmxlLgo+ID4gPj4+ PisgKi8KPiA+ID4+Pj4rdm9pZCBhbWRncHVfcmVzaXplX2JhcjAoc3RydWN0IGFtZGdwdV9kZXZp Y2UgKmFkZXYpCj4gPiA+Pj4+K3sKPiA+ID4+Pj4rCXU2NCBzcGFjZV9uZWVkZWQgPSByb3VuZHVw X3Bvd19vZl90d28oYWRldi0KPiA+bWMucmVhbF92cmFtX3NpemUpOwo+ID4gPj4+PisJdTMyIHJi YXJfc2l6ZSA9IG9yZGVyX2Jhc2VfMigoKHNwYWNlX25lZWRlZCA+PiAyMCkgfCAxKSkgLQo+IDE7 Cj4gPiA+Pj4+Kwl1MTYgY21kOwo+ID4gPj4+PisJaW50IHI7Cj4gPiA+Pj4+Kwo+ID4gPj4+PisJ LyogRnJlZSB0aGUgZG9vcmJlbGwgbWFwcGluZywgaXQgbW9zdCBsaWtlbHkgbmVlZHMgdG8gbW92 ZSBhcwo+IHdlbGwgKi8KPiA+ID4+Pj4rCWFtZGdwdV9kb29yYmVsbF9maW5pKGFkZXYpOwo+ID4g Pj4+PisJcGNpX3JlbGVhc2VfcmVzb3VyY2UoYWRldi0+cGRldiwgMik7Cj4gPiA+Pj4+Kwo+ID4g Pj4+PisJLyogRGlzYWJsZSBtZW1vcnkgZGVjb2Rpbmcgd2hpbGUgd2UgY2hhbmdlIHRoZSBCQVIK PiBhZGRyZXNzZXMgYW5kIHNpemUgKi8KPiA+ID4+Pj4rCXBjaV9yZWFkX2NvbmZpZ193b3JkKGFk ZXYtPnBkZXYsIFBDSV9DT01NQU5ELAo+ICZjbWQpOwo+ID4gPj4+PisJcGNpX3dyaXRlX2NvbmZp Z193b3JkKGFkZXYtPnBkZXYsIFBDSV9DT01NQU5ELAo+ID4gPj4+PisJCQkgICAgICBjbWQgJiB+ UENJX0NPTU1BTkRfTUVNT1JZKTsKPiA+ID4+Pj4rCj4gPiA+Pj4+KwlyID0gcGNpX3Jlc2l6ZV9y ZXNvdXJjZShhZGV2LT5wZGV2LCAwLCByYmFyX3NpemUpOwo+ID4gPj4+PisJaWYgKHIgPT0gLUVO T1NQQykKPiA+ID4+Pj4rCQlEUk1fSU5GTygiTm90IGVub3VnaCBQQ0kgYWRkcmVzcyBzcGFjZSBm b3IgYQo+IGxhcmdlIEJBUi4iKTsKPiA+ID4+Pj4rCWVsc2UgaWYgKHIgJiYgciAhPSAtRU5PVFNV UFApCj4gPiA+Pj4+KwkJRFJNX0VSUk9SKCJQcm9ibGVtIHJlc2l6aW5nIEJBUjAgKCVkKS4iLCBy KTsKPiA+ID4+Pj4rCj4gPiA+Pj4+KwlwY2lfd3JpdGVfY29uZmlnX3dvcmQoYWRldi0+cGRldiwg UENJX0NPTU1BTkQsIGNtZCk7Cj4gPiA+Pj4+Kwo+ID4gPj4+PisJLyogV2hlbiB0aGUgZG9vcmJl bGwgQkFSIGlzbid0IGF2YWlsYWJsZSB3ZSBoYXZlIG5vIGNoYW5jZQo+IG9mCj4gPiA+Pj4+Kwkg KiB1c2luZyB0aGUgZGV2aWNlLgo+ID4gPj4+PisJICovCj4gPiA+Pj4+KwlCVUdfT04oYW1kZ3B1 X2Rvb3JiZWxsX2luaXQoYWRldikpOwo+IAo+ID4gPj4+IEZyb20gdGhlIFBDSSBjb3JlIHBlcnNw ZWN0aXZlLCBpdCB3b3VsZCBiZSBtdWNoIGNsZWFuZXIgdG8gZG8gdGhlIEJBUgo+ID4gPj4+cmVz aXplIGJlZm9yZSB0aGUgZHJpdmVyIGNhbGxzIHBjaV9lbmFibGVfZGV2aWNlKCkuICBJZiB0aGF0 IGNvdWxkIGJlCj4gPiA+Pj5kb25lLCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciB0aGlzIHNv cnQgb2Ygc2h1dGRvd24vcmVpbml0IHN0dWZmCj4gPiA+Pj5hbmQgd2Ugd291bGRuJ3QgaGF2ZSB0 byB3b3JyeSBhYm91dCBpc3N1ZXMgbGlrZSB0aGVzZS4gIFRoZSBhbWRncHUKPiA+ID4+PmluaXQg cGF0aCBpcyBwcmV0dHkgY29tcGxpY2F0ZWQsIHNvIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMg aXMKPiA+ID4+PnBvc3NpYmxlLgo+ID4gPj5JIGNvbXBsZXRlbHkgYWdyZWUgb24gdGhpcyBhbmQg aXQgaXMgYWN0dWFsbHkgdGhlIGFwcHJvYWNoIEkgdHJpZWQgZmlyc3QuCj4gPiA+Pgo+ID4gPj5U aGVyZSBhcmUganVzdCB0d28gcHJvYmxlbXMgd2l0aCB0aGlzIGFwcHJvYWNoOgo+ID4gPj4xLiBX aGVuIHRoZSBhbWRncHUgZHJpdmVyIGlzIGxvYWRlZCB0aGVyZSBjYW4gYWxyZWFkeSBiZSB0aGUg VkdBCj4gPiA+PmNvbnNvbGUsIFZlc2Egb3IgRUZJIGRyaXZlciBhY3RpdmUgZm9yIHRoZSBkZXZp Y2UgYW5kIGRpc3BsYXlpbmcgdGhlCj4gPiA+PnNwbGFzaCBzY3JlZW4uCj4gPiA+Pgo+ID4gPj5X aGVuIHdlIHJlc2l6ZSBhbmQgbW9zdCBsaWtlbHkgcmVsb2NhdGUgdGhlIEJBUiB3aGlsZSB0aG9z ZSBkcml2ZXJzCj4gPiA+PmFyZSBhY3RpdmUgaXQgd2lsbCBjZXJ0YWlubHkgY2F1c2UgcHJvYmxl bXMuCj4gPiA+Pgo+ID4gPj5XaGF0IGFtZGdwdSBkb2VzIGJlZm9yZSB0cnlpbmcgdG8gcmVzaXpl IHRoZSBCQVIgaXMga2lja2luZyBvdXQKPiA+ID4+b3RoZXIgZHJpdmVyIGFuZCBtYWtpbmcgc3Vy ZSBpdCBoYXMgZXhjbHVzaXZlIGFjY2VzcyB0byB0aGUKPiA+ID4+aGFyZHdhcmUuCj4gPiA+SSBk b24ndCB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIGhlcmUgeWV0LiAgSWYgeW91IG5lZWQgdG8gZW5h YmxlIHRoZQo+ID4gPmRldmljZSwgdGhlbiBkaXNhYmxlIGl0LCByZXNpemUsIGFuZCByZS1lbmFi bGUgaXQsIHRoYXQncyBmaW5lLgo+ID4KPiA+IFRoZSBpc3N1ZSBpcyB3ZSBuZXZlciBlbmFibGUg dGhlIGRldmljZSBvdXJzZWxmIGluIGFtZGdwdSwgZXhjZXB0Cj4gPiBmb3Igc29tZSByYXJlIGNh c2VzIGR1cmluZyByZXN1bWUuCj4gPgo+ID4gSW4gbW9zdCBvZiB0aGUgY2FzZXMgd2UgaGF2ZSB0 byBoYW5kbGUgdGhpcyBpcyB0aGUgcHJpbWFyeSBkaXNwbGF5Cj4gPiBkZXZpY2Ugd2hpY2ggaXMg ZW5hYmxlZCBieSBlaXRoZXIgdGhlIEJJT1MsIFZHQSBjb25zb2xlLCBWZXNhRkIgb3IKPiA+IEVG SUZCLiBBbWRncHUganVzdCBraWNrcyBvdXQgd2hhdGV2ZXIgZHJpdmVyIHdhcyByZXNwb25zaWJs ZSBmb3IgdGhlCj4gPiBkZXZpY2UgcHJldmlvdXNseSBhbmQgdGFrZXMgb3Zlci4KPiA+Cj4gPiBJ IGNvdWxkIG9mIGNvdXJzZSBkbyB0aGUgZGlzYWJsZS9yZXNpemUvcmVlbmFibGUgZGFuY2UsIGJ1 dCBJIHdvdWxkCj4gPiByYXRoZXIgd2FudCB0byBhdm9pZCB0aGF0Lgo+ID4KPiA+IFRoZSBoYXJk d2FyZSBpcyBtb3N0IGxpa2VseSBhbHJlYWR5IGRpc3BsYXlpbmcgYSBib290IHNwbGFzaCBhbmQg d2UKPiA+IHdhbnQgdG8gdHJhbnNpdCB0byB0aGUgZGVza3RvcCB3aXRob3V0IGFueSBmbGlja2Vy aW5nIChhdCBsZWFzdAo+ID4gdGhhdCdzIHRoZSBsb25nIHRlcm0gZ29hbCkuIENvbXBsZXRlbHkg ZGlzYWJsaW5nIHRoZSBkZXZpY2UgdG8gZG8KPiA+IHRoaXMgZG9lc24ndCBzb3VuZHMgbGlrZSBh IGdvb2QgaWRlYSBpZiB3ZSB3YW50IHRoYXQuCj4gPgo+ID4gPlRoZSBpbXBvcnRhbnQgdGhpbmcg SSdtIGxvb2tpbmcgZm9yIGlzIHRoYXQgdGhlIHJlc2l6ZSBoYXBwZW5zIGJlZm9yZQo+ID4gPmEg cGNpX2VuYWJsZV9kZXZpY2UoKSwgYmVjYXVzZSBwY2lfZW5hYmxlX2RldmljZSgpIGlzIHRoZSBz eW5jIHBvaW50Cj4gPiA+d2hlcmUgdGhlIFBDSSBjb3JlIGVuYWJsZXMgcmVzb3VyY2VzIGFuZCBt YWtlcyB0aGVtIGF2YWlsYWJsZSB0byB0aGUKPiA+ID5kcml2ZXIuICBEcml2ZXJzIGtub3cgdGhh dCB0aGV5IGNhbid0IGxvb2sgYXQgdGhlIHJlc291cmNlcyBiZWZvcmUKPiA+ID50aGF0IHBvaW50 LiAgVGhlcmUncyBhIGxpdHRsZSBiaXQgb2YgdGV4dCBhYm91dCB0aGlzIGluIFsxXS4KPiA+Cj4g PiBZZWFoLCBJIHVuZGVyc3RhbmQgdGhhdC4gQnV0IHdvdWxkbid0IGl0IGJlIHN1ZmZpY2llbnQg dG8ganVzdAo+ID4gZGlzYWJsZSBtZW1vcnkgZGVjb2RpbmcgZHVyaW5nIHRoZSByZXNpemU/Cj4g Pgo+ID4gSSBjYW4gZWFzaWx5IGd1YXJhbnRlZSB0aGF0IHRoZSBDUFUgaXNuJ3QgYWNjZXNzaW5n IHRoZSBCQVIgZHVyaW5nCj4gPiB0aGUgdGltZSAod2UgbmVlZCB0byBkbyB0aGlzIGZvciBjaGFu Z2luZyB0aGUgbWVtb3J5IGNsb2NrcyBhcwo+ID4gd2VsbCksIGJ1dCBJIGhhdmUgYSBiYWQgZ3V0 IGZlZWxpbmcgY29tcGxldGVseSB0dXJuaW5nIG9mIHRoZSBkZXZpY2UKPiA+IHdoaWxlIHdlIGFy ZSBzdGlsbCBkaXNwbGF5aW5nIHN0dWZmLgo+IAo+IHBjaV9kaXNhYmxlX2RldmljZSgpIGRvZXNu J3QgdHVybiBvZmYgdGhlIGRldmljZTsgaXQgb25seSBkaXNhYmxlcyBidXMKPiBtYXN0ZXJpbmcg KGFuZCBzb21lIG9mIHRoZSBhcmNoLXNwZWNpZmljIHBjaWJpb3NfZGlzYWJsZV9kZXZpY2UoKQo+ IGltcGxlbWVudGF0aW9ucyBkbyBhIGxpdHRsZSBtb3JlKS4gIEJ1dCBpdCdzIGNlcnRhaW5seSB0 aGUgd3JvbmcKPiBkaXJlY3Rpb24gLS0gaXQgZGlzYWJsZXMgRE1BLCB3aGljaCBoYXMgbm90aGlu ZyB0byBkbyB3aXRoIHRoZSBCQVIKPiBkZWNvZGluZyB3ZSdyZSBpbnRlcmVzdGVkIGluLgo+IAo+ IFdoYXQgaWYgdGhlIGRyaXZlciBkaWQgc29tZXRoaW5nIGxpa2UgdGhpczoKPiAKPiAgIHBjaV9k aXNhYmxlX2RlY29kaW5nKGRldiwgSU9SRVNPVVJDRV9NRU0pOwo+ICAgcGNpX3JlbGVhc2VfcmVz b3VyY2UoZGV2LCAyKTsKPiAgIHBjaV9yZXNpemVfYmFyKGRldiwgYmFyLCBzaXplKTsKPiAgIHBj aV9hc3NpZ25fcmVzb3VyY2VzKGRldik7Cj4gICBwY2lfZW5hYmxlX2RlY29kaW5nKGRldiwgSU9S RVNPVVJDRV9NRU0pOwo+IAo+IFRoYXQgd291bGQgcmVxdWlyZSBhZGRpbmcgcGNpX2VuYWJsZS9k aXNhYmxlX2RlY29kaW5nKCkgdG8gdGhlIGRyaXZlcgo+IEFQSSwgYWxvbmcgd2l0aCB0aGUgcmVx dWlyZW1lbnQgdGhhdCB0aGUgZHJpdmVyIGRpc2NhcmQgYW5kIHJlbWFwCj4gc29tZSByZXNvdXJj ZXMgYWZ0ZXIgcGNpX2VuYWJsZV9kZWNvZGluZygpLiAgSSB0aGluawo+IHBjaV9lbmFibGVfZGVj b2RpbmcoKSB3b3VsZCBsb29rIG11Y2ggbGlrZSB0aGUgZXhpc3RpbmcKPiBwY2lfZW5hYmxlX3Jl c291cmNlcygpIGV4Y2VwdCB0YWtpbmcgYSByZXNvdXJjZSB0eXBlIGluc3RlYWQgb2YgYQo+IGJp dG1hc2suCj4gCj4gSSB3b3VsZCAqcHJlZmVyKiBpZiB3ZSByZWxlYXNlZCBhbmQgcmVhc3NpZ25l ZCBhbGwgcmVzb3VyY2VzLCBiZWNhdXNlCj4gdGhlbiB0aGUgY29yZSBoYXMgY29tcGxldGUgZmxl eGliaWxpdHkgdG8gbW92ZSB0aGluZ3MgYXJvdW5kLCBhbmQgaXQncwo+IGVhc3kgdG8gZG9jdW1l bnQgdGhhdCBwY2lfYXNzaWduX3Jlc291cmNlcygpIG1lYW5zIHlvdSBoYXZlIHRvCj4gcmVyZWFk L3JlbWFwIGV2ZXJ5dGhpbmcuCj4gCj4gSWYgdGhlIGRyaXZlciBvbmx5IHJlbGVhc2VzIHNwZWNp ZmllZCBCQVJzLCB0aGUgcGNpX2Fzc2lnbl9yZXNvdXJjZXMoKQo+IGludGVyZmFjZSBiZWNvbWVz ICJ5b3UgbmVlZCB0byByZXJlYWQvcmVtYXAgdGhlIEJBUiB5b3UgcmVzaXplZCwgcGx1cwo+IGFu eSBvdGhlciBCQVJzIHlvdSByZWxlYXNlZCIuICBJdCdzIGEgbGl0dGxlIG1vcmUgY29tcGxpY2F0 ZWQgdG8KPiBkZXNjcmliZSBhbmQgbW9yZSBkZXBlbmRlbnQgb24gcHJldmlvdXMgZHJpdmVyIGFj dGlvbnMuCj4gCj4gQnV0IHJlbGVhc2luZyBvbmx5IHRoZSBzcGVjaWZpZWQgQkFSIHdpbGwgbWFr ZSB5b3VyIGxpZmUgZWFzaWVyIGFuZAo+IGhlbHAgd2l0aCB0aGUgZmFjdCB0aGF0IG11bHRpcGxl IGRyaXZlcnMgbWlnaHQgYmUgdXNpbmcgdGhlIHNhbWUgQkFSCj4gKEkgaGF2ZSB0byByYWlzZSBt eSBleWVicm93cyBhdCB0aGF0KSwgc28gSSB0aGluayBJJ20gT0sgd2l0aCBpdC4gIEFuZAoKSXQn cyBwcmV0dHkgc3RhbmRhcmQgb24gU29Dcy4gIFRoZSBrZXJuZWwgaGFzIHRoZSBtZmQgaW5mcmFz dHJ1Y3R1cmUgdG8gc3VwcG9ydCBpdC4KCkFsZXgKCj4gaXQgd291bGQgYWxzbyBzaWRlLXN0ZXAg dGhlICJjYW4ndCByZXN0b3JlIHByZXZpb3VzIHN0YXRlIiBwcm9ibGVtLgo+IAo+IEl0J3MgYW4g ImludGVyZXN0aW5nIiBhc3ltbWV0cnkgdGhhdCBwY2lfZW5hYmxlX2RldmljZSgpIHR1cm5zIG9u IEJBUgo+IGRlY29kaW5nIGJ1dCBkb2Vzbid0IHRvdWNoIGJ1cyBtYXN0ZXJpbmcsIHdoaWxlIHBj aV9kaXNhYmxlX2RldmljZSgpCj4gdHVybnMgb2ZmIGJ1cyBtYXN0ZXJpbmcgYnV0IGRvZXNuJ3Qg dG91Y2ggQkFSIGRlY29kaW5nLgo+IAo+IEJqb3JuCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxp c3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-by2nam03on0083.outbound.protection.outlook.com ([104.47.42.83]:19376 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751492AbdFGDuN (ORCPT ); Tue, 6 Jun 2017 23:50:13 -0400 From: "Deucher, Alexander" To: 'Bjorn Helgaas' , =?iso-8859-1?Q?Christian_K=F6nig?= CC: "linux-pci@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" , David Airlie , "amd-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" Subject: RE: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2 Date: Wed, 7 Jun 2017 03:50:10 +0000 Message-ID: References: <1494348547-1465-1-git-send-email-deathsimple@vodafone.de> <1494348547-1465-6-git-send-email-deathsimple@vodafone.de> <20170601201430.GC12257@bhelgaas-glaptop.roam.corp.google.com> <72e061a5-9684-06e2-3021-80de8ca97bd7@vodafone.de> <20170602202631.GA1452@bhelgaas-glaptop.roam.corp.google.com> <779a883a-265a-ae04-b0cd-8cb3599f0dc0@vodafone.de> <20170606231019.GC12672@bhelgaas-glaptop.roam.corp.google.com> In-Reply-To: <20170606231019.GC12672@bhelgaas-glaptop.roam.corp.google.com> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org List-ID: > -----Original Message----- > From: Bjorn Helgaas [mailto:helgaas@kernel.org] > Sent: Tuesday, June 06, 2017 7:10 PM > To: Christian K=F6nig > Cc: linux-pci@vger.kernel.org; platform-driver-x86@vger.kernel.org; > Deucher, Alexander; David Airlie; amd-gfx@lists.freedesktop.org; dri- > devel@lists.freedesktop.org > Subject: Re: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access > v2 >=20 > On Tue, Jun 06, 2017 at 01:51:11PM +0200, Christian K=F6nig wrote: > > Am 02.06.2017 um 22:26 schrieb Bjorn Helgaas: > > >On Fri, Jun 02, 2017 at 11:32:21AM +0200, Christian K=F6nig wrote: > > >>Hi Bjorn, > > >> > > >>sorry for not responding earlier and thanks for picking this thread > > >>up again. > > >> > > >>Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas: > > >>>[+cc ADMGPU, DRM folks] > > >>> > > >>>On Tue, May 09, 2017 at 06:49:07PM +0200, Christian K=F6nig wrote: > > >>>>[SNIP] > > >>>>+/** > > >>>>+ * amdgpu_resize_bar0 - try to resize BAR0 > > >>>>+ * > > >>>>+ * @adev: amdgpu_device pointer > > >>>>+ * > > >>>>+ * Try to resize BAR0 to make all VRAM CPU accessible. > > >>>>+ */ > > >>>>+void amdgpu_resize_bar0(struct amdgpu_device *adev) > > >>>>+{ > > >>>>+ u64 space_needed =3D roundup_pow_of_two(adev- > >mc.real_vram_size); > > >>>>+ u32 rbar_size =3D order_base_2(((space_needed >> 20) | 1)) - > 1; > > >>>>+ u16 cmd; > > >>>>+ int r; > > >>>>+ > > >>>>+ /* Free the doorbell mapping, it most likely needs to move as > well */ > > >>>>+ amdgpu_doorbell_fini(adev); > > >>>>+ pci_release_resource(adev->pdev, 2); > > >>>>+ > > >>>>+ /* Disable memory decoding while we change the BAR > addresses and size */ > > >>>>+ pci_read_config_word(adev->pdev, PCI_COMMAND, > &cmd); > > >>>>+ pci_write_config_word(adev->pdev, PCI_COMMAND, > > >>>>+ cmd & ~PCI_COMMAND_MEMORY); > > >>>>+ > > >>>>+ r =3D pci_resize_resource(adev->pdev, 0, rbar_size); > > >>>>+ if (r =3D=3D -ENOSPC) > > >>>>+ DRM_INFO("Not enough PCI address space for a > large BAR."); > > >>>>+ else if (r && r !=3D -ENOTSUPP) > > >>>>+ DRM_ERROR("Problem resizing BAR0 (%d).", r); > > >>>>+ > > >>>>+ pci_write_config_word(adev->pdev, PCI_COMMAND, cmd); > > >>>>+ > > >>>>+ /* When the doorbell BAR isn't available we have no chance > of > > >>>>+ * using the device. > > >>>>+ */ > > >>>>+ BUG_ON(amdgpu_doorbell_init(adev)); >=20 > > >>> From the PCI core perspective, it would be much cleaner to do the B= AR > > >>>resize before the driver calls pci_enable_device(). If that could b= e > > >>>done, there would be no need for this sort of shutdown/reinit stuff > > >>>and we wouldn't have to worry about issues like these. The amdgpu > > >>>init path is pretty complicated, so I don't know whether this is > > >>>possible. > > >>I completely agree on this and it is actually the approach I tried fi= rst. > > >> > > >>There are just two problems with this approach: > > >>1. When the amdgpu driver is loaded there can already be the VGA > > >>console, Vesa or EFI driver active for the device and displaying the > > >>splash screen. > > >> > > >>When we resize and most likely relocate the BAR while those drivers > > >>are active it will certainly cause problems. > > >> > > >>What amdgpu does before trying to resize the BAR is kicking out > > >>other driver and making sure it has exclusive access to the > > >>hardware. > > >I don't understand the problem here yet. If you need to enable the > > >device, then disable it, resize, and re-enable it, that's fine. > > > > The issue is we never enable the device ourself in amdgpu, except > > for some rare cases during resume. > > > > In most of the cases we have to handle this is the primary display > > device which is enabled by either the BIOS, VGA console, VesaFB or > > EFIFB. Amdgpu just kicks out whatever driver was responsible for the > > device previously and takes over. > > > > I could of course do the disable/resize/reenable dance, but I would > > rather want to avoid that. > > > > The hardware is most likely already displaying a boot splash and we > > want to transit to the desktop without any flickering (at least > > that's the long term goal). Completely disabling the device to do > > this doesn't sounds like a good idea if we want that. > > > > >The important thing I'm looking for is that the resize happens before > > >a pci_enable_device(), because pci_enable_device() is the sync point > > >where the PCI core enables resources and makes them available to the > > >driver. Drivers know that they can't look at the resources before > > >that point. There's a little bit of text about this in [1]. > > > > Yeah, I understand that. But wouldn't it be sufficient to just > > disable memory decoding during the resize? > > > > I can easily guarantee that the CPU isn't accessing the BAR during > > the time (we need to do this for changing the memory clocks as > > well), but I have a bad gut feeling completely turning of the device > > while we are still displaying stuff. >=20 > pci_disable_device() doesn't turn off the device; it only disables bus > mastering (and some of the arch-specific pcibios_disable_device() > implementations do a little more). But it's certainly the wrong > direction -- it disables DMA, which has nothing to do with the BAR > decoding we're interested in. >=20 > What if the driver did something like this: >=20 > pci_disable_decoding(dev, IORESOURCE_MEM); > pci_release_resource(dev, 2); > pci_resize_bar(dev, bar, size); > pci_assign_resources(dev); > pci_enable_decoding(dev, IORESOURCE_MEM); >=20 > That would require adding pci_enable/disable_decoding() to the driver > API, along with the requirement that the driver discard and remap > some resources after pci_enable_decoding(). I think > pci_enable_decoding() would look much like the existing > pci_enable_resources() except taking a resource type instead of a > bitmask. >=20 > I would *prefer* if we released and reassigned all resources, because > then the core has complete flexibility to move things around, and it's > easy to document that pci_assign_resources() means you have to > reread/remap everything. >=20 > If the driver only releases specified BARs, the pci_assign_resources() > interface becomes "you need to reread/remap the BAR you resized, plus > any other BARs you released". It's a little more complicated to > describe and more dependent on previous driver actions. >=20 > But releasing only the specified BAR will make your life easier and > help with the fact that multiple drivers might be using the same BAR > (I have to raise my eyebrows at that), so I think I'm OK with it. And It's pretty standard on SoCs. The kernel has the mfd infrastructure to sup= port it. Alex > it would also side-step the "can't restore previous state" problem. >=20 > It's an "interesting" asymmetry that pci_enable_device() turns on BAR > decoding but doesn't touch bus mastering, while pci_disable_device() > turns off bus mastering but doesn't touch BAR decoding. >=20 > Bjorn