From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oded Gabbay Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init Date: Sun, 21 Dec 2014 18:03:00 +0200 Message-ID: <5496EF34.70302@amd.com> References: <1419108374-7020-1-git-send-email-oded.gabbay@amd.com> <1419108374-7020-2-git-send-email-oded.gabbay@amd.com> <5496AEAD.3090003@vodafone.de> <5496B04C.50502@amd.com> <5496BAE0.5090901@vodafone.de> <5496C5EA.7050200@amd.com> <5496CA0F.8000800@amd.com> <5496EDF1.7080106@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) by gabe.freedesktop.org (Postfix) with ESMTP id AD1A96E317 for ; Sun, 21 Dec 2014 08:03:21 -0800 (PST) In-Reply-To: <5496EDF1.7080106@vodafone.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , dri-devel@lists.freedesktop.org Cc: Alexander.Deucher@amd.com, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org CgpPbiAxMi8yMS8yMDE0IDA1OjU3IFBNLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+PiBUaGVy ZSBzaG91bGQgYmUsIGJ1dCB3aGVuIHRoZSBtb2R1bGVzIGFyZSBjb21waWxlZCBpbiwgdGhleSBh cmUgbG9hZGVkIGJhc2VkIG9uCj4+IGxpbmsgb3JkZXIgb25seSwgaWYgdGhleSBhcmUgaW4gdGhl IHNhbWUgZ3JvdXAsIGFuZCB0aGUgZ3JvdXBzIGFyZSBsb2FkZWQgYnkgYQo+PiBwcmUtZGVmaW5l ZCBvcmRlci4KPiBJcyB0aGF0IHJlYWxseSBzdGlsbCB1cCB0byBkYXRlPyBJJ3ZlIHNlZW4gZWZm b3J0IHRvIGNoYW5nZSB0aGF0IHNvbWV0aGluZyBsaWtlCj4gMTArIHllYXJzIGFnbyB3aGVuIFJ1 c3R5IHJld29ya2VkIHRoZSBtb2R1bGUgc3lzdGVtLiBBbmQgaXQgaXMgY29tbWluZyB1cCBvbiB0 aGUKPiBsaXN0cyBhZ2FpbiBmcm9tIHRpbWUgdG8gdGltZS4KIEZyb20gd2hhdCBJIGNhbiBzZWUg aW4gdGhlIE1ha2VmaWxlIHJ1bGVzLCBjb2RlIGFuZCBnb29nbGUsIHllcywgdGhhdCdzIHN0aWxs IAp0aGUgc2l0dWF0aW9uLiBJZiBzb21lb25lIHdpbGwgcHJvdmUgbWUgd3JvbmcgSSB3aWxsIGJl IG1vcmUgdGhhbiBoYXBweSB0byAKY29ycmVjdCBteSBjb2RlLgo+Cj4+IEkgZG9uJ3Qgd2FudCB0 byBtb3ZlIGlvbW11IGJlZm9yZSBncHUsIHNvIEkgZG9uJ3QgaGF2ZSBhIHNvbHV0aW9uIGZvciB0 aGUKPj4gb3JkZXIgYmV0d2VlbiBhbWRrZmQgYW5kIGFtZF9pb21tdV92Mi4KPiBXaHkgbm90PyBU aGF0J3Mgc3RpbGwgYmV0dGVyIHRoYW4gY3JlYXRpbmcgYSBrZXJuZWwgd29ya3F1ZXVlLCBzY2hl ZHVsaW5nIG9uZQo+IHdvcmsgaXRlbSBvbiBpdCwgcmVzY2hlZHVsaW5nIHRoZSB0YXNrIHVudGls IGV2ZXJ5dGhpbmcgaXMgY29tcGxldGVkIGFuZCB5b3UgY2FuCj4gY29udGludWUuCkJlY2F1c2Ug SSBkb24ndCBrbm93IHRoZSBjb25zZXF1ZW5jZXMgb2YgbW92aW5nIGFuIGVudGlyZSBzdWJzeXN0 ZW0gaW4gZnJvbnQgb2YgCmFub3RoZXIgb25lLiBJbiBhZGRpdGlvbiwgZXZlbiBpZiBldmVyeW9u ZSBhZ3JlZXMsIEknbSBwcmV0dHkgc3VyZSB0aGF0IExpbnVzIAp3b24ndCBiZSBoYXBweSB0byBk byB0aGF0IGluIC1yYyBzdGFnZXMuIFNvIG1heWJlIHRoaXMgaXMgc29tZXRoaW5nIHRvIGNvbnNp ZGVyIApmb3IgMy4yMCBtZXJnZSB3aW5kb3csIGJ1dCBJIHdvdWxkIHN0aWxsIGxpa2UgdG8gcHJv dmlkZSBhIHNvbHV0aW9uIGZvciAzLjE5LgoKCU9kZWQKPgo+IENocmlzdGlhbi4KPgo+IEFtIDIx LjEyLjIwMTQgdW0gMTQ6MjQgc2NocmllYiBPZGVkIEdhYmJheToKPj4KPj4KPj4gT24gMTIvMjEv MjAxNCAwMzowNiBQTSwgT2RlZCBHYWJiYXkgd3JvdGU6Cj4+Pgo+Pj4KPj4+IE9uIDEyLzIxLzIw MTQgMDI6MTkgUE0sIENocmlzdGlhbiBLw7ZuaWcgd3JvdGU6Cj4+Pj4gQW0gMjEuMTIuMjAxNCB1 bSAxMjozNCBzY2hyaWViIE9kZWQgR2FiYmF5Ogo+Pj4+Pgo+Pj4+Pgo+Pj4+PiBPbiAxMi8yMS8y MDE0IDAxOjI3IFBNLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+Pj4+Pj4gQW0gMjAuMTIuMjAx NCB1bSAyMTo0NiBzY2hyaWViIE9kZWQgR2FiYmF5Ogo+Pj4+Pj4+IFdoZW4gYW1ka2ZkIGFuZCBy YWRlb24gYXJlIGNvbXBpbGVkIGluc2lkZSB0aGUga2VybmVsIGltYWdlIChub3QgYXMKPj4+Pj4+ PiBtb2R1bGVzKSwKPj4+Pj4+PiByYWRlb24gd2lsbCBsb2FkIGJlZm9yZSBhbWRrZmQgYW5kIHdp bGwgc2V0ICprZmQya2dkIHRvIGl0cyBpbnRlcmZhY2UKPj4+Pj4+PiBzdHJ1Y3R1cmUuIFRoZXJl Zm9yZSwgd2UgbXVzdCBub3Qgc2V0ICprZmQya2dkIHRvIE5VTEwgd2hlbiBhbWRrZmQgaXMgbG9h ZGVkCj4+Pj4+Pj4gYmVjYXVzZSBpdCB3aWxsIG92ZXJyaWRlIHJhZGVvbidzIGluaXRpYWxpemF0 aW9uIGFuZCBjYXVzZSBrZXJuZWwgQlVHLgo+Pj4+Pj4+Cj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTog T2RlZCBHYWJiYXkgPG9kZWQuZ2FiYmF5QGFtZC5jb20+Cj4+Pj4+Pgo+Pj4+Pj4gWW91IHNob3Vs ZCBwcm9iYWJseSByYXRoZXIgZml4IHRoZSBkZXBlbmRlbmN5IGJldHdlZW4gdGhlIHR3byBtb2R1 bGVzIHRvCj4+Pj4+PiBnZXQgYW4KPj4+Pj4+IGRldGVybWluZWQgbG9hZCBvcmRlciBpbnN0ZWFk IG9mIGRvaW5nIHN1Y2ggbmFzdHkgd29ya2Fyb3VuZHMuCj4+Pj4+Pgo+Pj4+Pj4gQ2hyaXN0aWFu Lgo+Pj4+Pgo+Pj4+PiBUaGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gbW9kdWxlcyBhcmUgY29tcGls ZWQgaW5zaWRlIHRoZSBrZXJuZWwsIHRoZXJlIGlzIE5PCj4+Pj4+IGRldGVybWluZWQgbG9hZCBv cmRlciBhbmQgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGVuZm9yY2UgdGhhdC4gSWYgdGhlcmUK Pj4+Pj4gaXMvd2FzIHN1Y2ggYSBtZWNoYW5pc20sIEkgd291bGQgb2YgY291cnNlIHByZWZlciB0 byB1c2UgaXQuCj4+Pj4KPj4+PiBUaGVyZSBzaG91bGQgYmUgYW4gZGV0ZXJtaW5lZCBvcmRlciBi YXNlZCBvbiB0aGUgc3ltYm9sIHVzZSwgb3RoZXJ3aXNlCj4+Pj4gaW5pdGlhbGl6aW5nIG1vc3Qg b2YgdGhlIGtlcm5lbCBtb2R1bGVzIHdvdWxkbid0IHdvcmsgYXMgZXhwZWN0ZWQuIEZvciBleGFt cGxlCj4+Pj4gcmFkZW9uIGRlcGVuZHMgb24gdGhlIGRybSBtb2R1bGUgbXVzdCBiZSBsb2FkZWQg YmVmb3JlIHJhZGVvbiBpcyBsb2FkZWQuCj4+PiBUaGVyZSBzaG91bGQgYmUsIGJ1dCB3aGVuIHRo ZSBtb2R1bGVzIGFyZSBjb21waWxlZCBpbiwgdGhleSBhcmUgbG9hZGVkIGJhc2VkIG9uCj4+PiBs aW5rIG9yZGVyIG9ubHksIGlmIHRoZXkgYXJlIGluIHRoZSBzYW1lIGdyb3VwLCBhbmQgdGhlIGdy b3VwcyBhcmUgbG9hZGVkIGJ5IGEKPj4+IHByZS1kZWZpbmVkIG9yZGVyLgo+Pj4gVGhlIGdyb3Vw cyBhcmU6IHB1cmUsIGNvcmUsIHBvc3Rjb3JlLCBhcmNoLCBzdWJzeXMsIGZzLCBkZXZpY2UgKHdo aWNoIHJlcHJlc2VudHMKPj4+IGFsbCB0aGUgbW9kdWxlcykgYW5kIGxhdGUuIFNlZSBpbml0LmgK Pj4+Cj4+PiBTbyByYWRlb24sIGFtZGtmZCBhbmQgYW1kX2lvbW11X3YyIGFyZSBhbGwgaW4gZGV2 aWNlIGdyb3VwLCBhbmQgaW4gdGhlIGdyb3VwCj4+PiB0aGV5IGFyZSBvcmRlcmVkIGJ5IHRoZWly IGxpbmsgb3JkZXIuCj4+Pgo+Pj4gWWVzLCByYWRlb24gbG9hZHMgYWZ0ZXIgZHJtLCBiZWNhdXNl IGRybSoubyBhcmUgYmVmb3JlIHJhZGVvbioubyBpbiB0aGUKPj4+IE1ha2VmaWxlLiBTZWUKPj4+ IGh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvNTY2OTY0Ny9saW51eC1vcmRlci1v Zi1zdGF0aWNhbGx5LWxpbmtlZC1tb2R1bGUtbG9hZGluZwo+Pj4KPj4+Cj4+Cj4+IFNvIEkgdHJp ZWQgbW92aW5nIGFtZGtmZCBpbnNpZGUgdGhlIE1ha2VmaWxlIGJlZm9yZSByYWRlb24sIGFuZCB0 aGF0IG1hZGUKPj4gYW1ka2ZkIGxvYWQgYmVmb3JlIHJhZGVvbiBkaWQuIFRoaXMgc29sdmVzIG15 IGZpcnN0IHByb2JsZW0gLSBvcmRlciBiZXR3ZWVuCj4+IGFtZGtmZCBhbmQgcmFkZW9uLiBIb3dl dmVyLCBhbWRfaW9tbXVfdjIgZG9lc24ndCBiZWxvbmcgdG8gdGhlIGRybSBNYWtlZmlsZSwKPj4g YW5kIEkgZG9uJ3Qgd2FudCB0byBtb3ZlIGlvbW11IGJlZm9yZSBncHUsIHNvIEkgZG9uJ3QgaGF2 ZSBhIHNvbHV0aW9uIGZvciB0aGUKPj4gb3JkZXIgYmV0d2VlbiBhbWRrZmQgYW5kIGFtZF9pb21t dV92Mi4KPj4KPj4gICAgIE9kZWQKPj4+Cj4+Pgo+Pj4+Cj4+Pj4+Cj4+Pj4+IEFjdHVhbGx5LCBJ IGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSBrZXJuZWwgZG9lc24ndCBlbmZvcmNlIHRoZSBvcmRl cgo+Pj4+PiBhY2NvcmRpbmcgdG8gdGhlIHVzZSBvZiBleHBvcnRlZCBzeW1ib2xzLCBsaWtlIGl0 IGRvZXMgd2l0aCBtb2R1bGVzLgo+Pj4+Cj4+Pj4gWWVhaCwgdGhhdCdzIGluZGVlZCByYXRoZXIg c3RyYW5nZS4gVGhlcmUgbXVzdCBiZSBzb21ldGhpbmcgaW4gdGhlIGFtZGtmZCBjb2RlCj4+Pj4g d2hpY2ggYnJva2UgdGhhdCBzb21laG93Lgo+Pj4gSU1PLCB0aGF0J3MgYSBmYXItZmV0Y2hlZCBn dWVzcy4gQ291bGQgeW91IHBvaW50IHRvIHNvbWV0aGluZyBtb3JlIHNwZWNpZmljID8KPj4+Cj4+ Pj4KPj4+PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHlvdSB0aGUgZGVzaXJlZCBpbml0IG9yZGVy IGlzIHJhZGVvbiBhbmQgYW1kX2lvbW11X3YyCj4+Pj4gZmlyc3QgYW5kIHRoZW4gYW1ka2ZkLCBy aWdodD8KPj4+IEFjdHVhbGx5IG5vLiBUaGUgcHJlZmVycmVkIG9yZGVyIGlzIGFtZF9pb21tdV92 MiwgYW1ka2ZkIGFuZCByYWRlb24gbGFzdC4gVGhpcwo+Pj4gaXMgdGhlIG9yZGVyIHRoYXQgaGFw cGVucyB3aGVuIGFsbCB0aHJlZSBhcmUgYnVpbHQgYXMgbW9kdWxlcy4gTW9yZSBhY2N1cmF0ZWx5 LAo+Pj4gcmFkZW9uIGluaXRzLCBidXQgaXRzIGluaXQgdHJpZ2dlcnMgYW1ka2ZkIGluaXQsIHdo aWNoIHRyaWdnZXJzIGFtZF9pb21tdV92Mgo+Pj4gaW5pdC4gU28gYmVmb3JlIHJhZGVvbiByZWFj aGVzIGl0cyBwcm9iZSBzdGFnZSwgYWxsIHRoZSBtb2R1bGVzIHdlcmUKPj4+IGluaXRpYWxpemVk Lgo+Pj4KPj4+IFNvIHdoYXQgaGFwcGVucyB3aGVuIHlvdSBib290IHdpdGggcmFkZW9uLAo+Pj4+ IGFtZF9pb21tdV92MiBhbmQgYW1ka2ZkIGJsYWNrbGlzdGVkIGZvciBhdXRvbWF0aWNhbGx5IGxv YWQgYW5kIG9ubHkgbG9hZCBhbWRrZmQKPj4+PiBtYW51YWxseT8KPj4+IEFzIHNhaWQgYWJvdmUs IHRoYXQncyBvay4KPj4+Pgo+Pj4+PiBUaGVyZSB3aWxsIGFsd2F5cyBiZSBkZXBlbmRlbmNpZXMg YmV0d2VlbiBrZ2QgKHJhZGVvbikgYW5kIGFtZGtmZCBhbmQgYmV0d2Vlbgo+Pj4+PiBhbWRrZmQg YW5kIGFtZF9pb21tdV92Mi4gSSBkb24ndCB0aGluayBJIGNhbiBlbGltaW5hdGUgdGhvc2UgZGVw ZW5kZW5jaWVzLCBub3QKPj4+Pj4gd2l0aG91dCBhIHZlcnkgY29tcGxleCBzb2x1dGlvbi4gQW5k IHRoZSBmYWN0IHRoYXQgdGhpcyBjb21wbGV4IHNvbHV0aW9uCj4+Pj4+IG9jY3VycyBvbmx5IGlu IGEgdmVyeSBzcGVjaWZpYyB1c2UgY2FzZSAoYWxsIG1vZHVsZXMgY29tcGlsZWQgaW4pLCBtYWtl cyBtZQo+Pj4+PiBsZXNzIGluY2xpbmVkIHRvIGRvIHRoYXQuCj4+Pj4+Cj4+Pj4+IFNvIEkgZG9u J3Qgc2VlIGl0IGFzIGEgIm5hc3R5IHdvcmthcm91bmQiLiBJIHdvdWxkIGNhbGwgaXQganVzdCBh ICJ3b3JrYXJvdW5kIgo+Pj4+PiBmb3IgYSBzcGVjaWZpYyB1c2UgY2FzZSwgd2hpY2ggc2hvdWxk IGJlIHNvbHZlZCBieSBhIGdlbmVyaWMgc29sdXRpb24gdG8gdGhlCj4+Pj4+IGtlcm5lbCBlbmZv cmNpbmcgbG9hZCBvcmRlcnMuCj4+Pj4KPj4+PiBUaGUgbm9ybWFsIGtlcm5lbCBtb2R1bGUgaGFu ZGxpbmcgYWxyZWFkeSBzaG91bGQgcHJvdmlkZSB0aGUgY29ycmVjdCBpbml0Cj4+Pj4gb3JkZXIs Cj4+Pj4gc28gSSB3b3VsZCBzdGlsbCBjYWxsIHRoaXMgYSByYXRoZXIgbmFzdHkgd29ya2Fyb3Vu ZCBiZWNhdXNlIHdlIGNvdWxkbid0IGZpbmQKPj4+PiB0aGUgdW5kZXJseWluZyBwcm9ibGVtLgo+ Pj4gV2VsbCwgdGhlIG5vcm1hbCBrZXJuZWwgbW9kdWxlIGhhbmRsaW5nIGRvZXNuJ3Qgd29yayB3 aGVuIGFsbCBtb2R1bGVzIGFyZQo+Pj4gY29tcGlsZWQgaW4uIEknbSBub3QgYSBodWdlIGV4cGVy dCBvbiB0aGlzIGlzc3VlIHNvIEkgaGFkIEpvZXJnIFJvZWRlbCBoZWxwIG1lCj4+PiBhbmFseXpl IHRoaXMgKHRoYW5rcyBKb2VyZykgYW5kIGhlIGFncmVlZCB0aGF0IHRoZXJlIGlzIG5vIGVuZm9y Y2VtZW50IG9mIG9yZGVyCj4+PiBpbiB0aGlzIGNhc2UuCj4+Pgo+Pj4+Cj4+Pj4gQ2hyaXN0aWFu Lgo+Pj4+Cj4+Pj4+Cj4+Pj4+ICAgICBPZGVkCj4+Pj4+Pgo+Pj4+Pj4+IC0tLQo+Pj4+Pj4+ICAg ZHJpdmVycy9ncHUvZHJtL2FtZC9hbWRrZmQva2ZkX21vZHVsZS5jIHwgNSArKy0tLQo+Pj4+Pj4+ ICAgMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKPj4+Pj4+ Pgo+Pj4+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9k dWxlLmMKPj4+Pj4+PiBiL2RyaXZlcnMvZ3B1L2RybS9hbWQvYW1ka2ZkL2tmZF9tb2R1bGUuYwo+ Pj4+Pj4+IGluZGV4IDk1ZDVhZjEuLjIzNjU2MmYgMTAwNjQ0Cj4+Pj4+Pj4gLS0tIGEvZHJpdmVy cy9ncHUvZHJtL2FtZC9hbWRrZmQva2ZkX21vZHVsZS5jCj4+Pj4+Pj4gKysrIGIvZHJpdmVycy9n cHUvZHJtL2FtZC9hbWRrZmQva2ZkX21vZHVsZS5jCj4+Pj4+Pj4gQEAgLTM0LDcgKzM0LDcgQEAK Pj4+Pj4+PiAgICNkZWZpbmUgS0ZEX0RSSVZFUl9NSU5PUiAgICA3Cj4+Pj4+Pj4gICAjZGVmaW5l IEtGRF9EUklWRVJfUEFUQ0hMRVZFTCAgICAwCj4+Pj4+Pj4gLWNvbnN0IHN0cnVjdCBrZmQya2dk X2NhbGxzICprZmQya2dkOwo+Pj4+Pj4+ICtjb25zdCBzdHJ1Y3Qga2ZkMmtnZF9jYWxscyAqa2Zk MmtnZCA9IE5VTEw7Cj4+Pj4+Pj4gICBzdGF0aWMgY29uc3Qgc3RydWN0IGtnZDJrZmRfY2FsbHMg a2dkMmtmZCA9IHsKPj4+Pj4+PiAgICAgICAuZXhpdCAgICAgICAgPSBrZ2Qya2ZkX2V4aXQsCj4+ Pj4+Pj4gICAgICAgLnByb2JlICAgICAgICA9IGtnZDJrZmRfcHJvYmUsCj4+Pj4+Pj4gQEAgLTg0 LDE0ICs4NCwxMyBAQCBFWFBPUlRfU1lNQk9MKGtnZDJrZmRfaW5pdCk7Cj4+Pj4+Pj4gICB2b2lk IGtnZDJrZmRfZXhpdCh2b2lkKQo+Pj4+Pj4+ICAgewo+Pj4+Pj4+ICsgICAga2ZkMmtnZCA9IE5V TEw7Cj4+Pj4+Pj4gICB9Cj4+Pj4+Pj4gICBzdGF0aWMgaW50IF9faW5pdCBrZmRfbW9kdWxlX2lu aXQodm9pZCkKPj4+Pj4+PiAgIHsKPj4+Pj4+PiAgICAgICBpbnQgZXJyOwo+Pj4+Pj4+IC0gICAg a2ZkMmtnZCA9IE5VTEw7Cj4+Pj4+Pj4gLQo+Pj4+Pj4+ICAgICAgIC8qIFZlcmlmeSBtb2R1bGUg cGFyYW1ldGVycyAqLwo+Pj4+Pj4+ICAgICAgIGlmICgoc2NoZWRfcG9saWN5IDwgS0ZEX1NDSEVE X1BPTElDWV9IV1MpIHx8Cj4+Pj4+Pj4gICAgICAgICAgIChzY2hlZF9wb2xpY3kgPiBLRkRfU0NI RURfUE9MSUNZX05PX0hXUykpIHsKPj4+Pj4+Cj4+Pj4KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBkcmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4+ PiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4+PiBodHRwOi8vbGlzdHMuZnJlZWRl c2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCj4KPiAtLQo+IFRvIHVuc3Vic2Ny aWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1rZXJu ZWwiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5v cmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9y ZG9tby1pbmZvLmh0bWwKPiBQbGVhc2UgcmVhZCB0aGUgRkFRIGF0ICBodHRwOi8vd3d3LnR1eC5v cmcvbGttbC8KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K ZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0 dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751985AbaLUQDX (ORCPT ); Sun, 21 Dec 2014 11:03:23 -0500 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:50336 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751141AbaLUQDW convert rfc822-to-8bit (ORCPT ); Sun, 21 Dec 2014 11:03:22 -0500 X-WSS-ID: 0NGXWLE-08-83Y-02 X-M-MSG: Message-ID: <5496EF34.70302@amd.com> Date: Sun, 21 Dec 2014 18:03:00 +0200 From: Oded Gabbay Organization: AMD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , CC: , , Joerg Roedel Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init References: <1419108374-7020-1-git-send-email-oded.gabbay@amd.com> <1419108374-7020-2-git-send-email-oded.gabbay@amd.com> <5496AEAD.3090003@vodafone.de> <5496B04C.50502@amd.com> <5496BAE0.5090901@vodafone.de> <5496C5EA.7050200@amd.com> <5496CA0F.8000800@amd.com> <5496EDF1.7080106@vodafone.de> In-Reply-To: <5496EDF1.7080106@vodafone.de> Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [10.20.0.84] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=Oded.Gabbay@amd.com; X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(428002)(377454003)(199003)(24454002)(189002)(51704005)(479174004)(65806001)(83506001)(31966008)(20776003)(4396001)(1720100001)(87936001)(101416001)(77096005)(19580395003)(84676001)(21056001)(64706001)(2950100001)(33656002)(47776003)(19580405001)(15975445007)(50466002)(46102003)(68736005)(106466001)(23676002)(105586002)(93886004)(107046002)(97736003)(50986999)(65816999)(77156002)(62966003)(64126003)(99396003)(120916001)(15395725005)(36756003)(76176999)(92566001)(54356999)(86362001)(2101003);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR02MB194;H:atltwp02.amd.com;FPR:;SPF:None;MLV:sfv;PTR:InfoDomainNonexistent;A:3;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR02MB194; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:BLUPR02MB194; X-Forefront-PRVS: 0432A04947 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR02MB194; X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2014 16:03:18.3950 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.222] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB194 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/21/2014 05:57 PM, Christian König wrote: >> There should be, but when the modules are compiled in, they are loaded based on >> link order only, if they are in the same group, and the groups are loaded by a >> pre-defined order. > Is that really still up to date? I've seen effort to change that something like > 10+ years ago when Rusty reworked the module system. And it is comming up on the > lists again from time to time. From what I can see in the Makefile rules, code and google, yes, that's still the situation. If someone will prove me wrong I will be more than happy to correct my code. > >> I don't want to move iommu before gpu, so I don't have a solution for the >> order between amdkfd and amd_iommu_v2. > Why not? That's still better than creating a kernel workqueue, scheduling one > work item on it, rescheduling the task until everything is completed and you can > continue. Because I don't know the consequences of moving an entire subsystem in front of another one. In addition, even if everyone agrees, I'm pretty sure that Linus won't be happy to do that in -rc stages. So maybe this is something to consider for 3.20 merge window, but I would still like to provide a solution for 3.19. Oded > > Christian. > > Am 21.12.2014 um 14:24 schrieb Oded Gabbay: >> >> >> On 12/21/2014 03:06 PM, Oded Gabbay wrote: >>> >>> >>> On 12/21/2014 02:19 PM, Christian König wrote: >>>> Am 21.12.2014 um 12:34 schrieb Oded Gabbay: >>>>> >>>>> >>>>> On 12/21/2014 01:27 PM, Christian König wrote: >>>>>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay: >>>>>>> When amdkfd and radeon are compiled inside the kernel image (not as >>>>>>> modules), >>>>>>> radeon will load before amdkfd and will set *kfd2kgd to its interface >>>>>>> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded >>>>>>> because it will override radeon's initialization and cause kernel BUG. >>>>>>> >>>>>>> Signed-off-by: Oded Gabbay >>>>>> >>>>>> You should probably rather fix the dependency between the two modules to >>>>>> get an >>>>>> determined load order instead of doing such nasty workarounds. >>>>>> >>>>>> Christian. >>>>> >>>>> The problem is that when modules are compiled inside the kernel, there is NO >>>>> determined load order and there is no mechanism to enforce that. If there >>>>> is/was such a mechanism, I would of course prefer to use it. >>>> >>>> There should be an determined order based on the symbol use, otherwise >>>> initializing most of the kernel modules wouldn't work as expected. For example >>>> radeon depends on the drm module must be loaded before radeon is loaded. >>> There should be, but when the modules are compiled in, they are loaded based on >>> link order only, if they are in the same group, and the groups are loaded by a >>> pre-defined order. >>> The groups are: pure, core, postcore, arch, subsys, fs, device (which represents >>> all the modules) and late. See init.h >>> >>> So radeon, amdkfd and amd_iommu_v2 are all in device group, and in the group >>> they are ordered by their link order. >>> >>> Yes, radeon loads after drm, because drm*.o are before radeon*.o in the >>> Makefile. See >>> http://stackoverflow.com/questions/5669647/linux-order-of-statically-linked-module-loading >>> >>> >> >> So I tried moving amdkfd inside the Makefile before radeon, and that made >> amdkfd load before radeon did. This solves my first problem - order between >> amdkfd and radeon. However, amd_iommu_v2 doesn't belong to the drm Makefile, >> and I don't want to move iommu before gpu, so I don't have a solution for the >> order between amdkfd and amd_iommu_v2. >> >> Oded >>> >>> >>>> >>>>> >>>>> Actually, I don't understand why the kernel doesn't enforce the order >>>>> according to the use of exported symbols, like it does with modules. >>>> >>>> Yeah, that's indeed rather strange. There must be something in the amdkfd code >>>> which broke that somehow. >>> IMO, that's a far-fetched guess. Could you point to something more specific ? >>> >>>> >>>> As far as I understand you the desired init order is radeon and amd_iommu_v2 >>>> first and then amdkfd, right? >>> Actually no. The preferred order is amd_iommu_v2, amdkfd and radeon last. This >>> is the order that happens when all three are built as modules. More accurately, >>> radeon inits, but its init triggers amdkfd init, which triggers amd_iommu_v2 >>> init. So before radeon reaches its probe stage, all the modules were >>> initialized. >>> >>> So what happens when you boot with radeon, >>>> amd_iommu_v2 and amdkfd blacklisted for automatically load and only load amdkfd >>>> manually? >>> As said above, that's ok. >>>> >>>>> There will always be dependencies between kgd (radeon) and amdkfd and between >>>>> amdkfd and amd_iommu_v2. I don't think I can eliminate those dependencies, not >>>>> without a very complex solution. And the fact that this complex solution >>>>> occurs only in a very specific use case (all modules compiled in), makes me >>>>> less inclined to do that. >>>>> >>>>> So I don't see it as a "nasty workaround". I would call it just a "workaround" >>>>> for a specific use case, which should be solved by a generic solution to the >>>>> kernel enforcing load orders. >>>> >>>> The normal kernel module handling already should provide the correct init >>>> order, >>>> so I would still call this a rather nasty workaround because we couldn't find >>>> the underlying problem. >>> Well, the normal kernel module handling doesn't work when all modules are >>> compiled in. I'm not a huge expert on this issue so I had Joerg Roedel help me >>> analyze this (thanks Joerg) and he agreed that there is no enforcement of order >>> in this case. >>> >>>> >>>> Christian. >>>> >>>>> >>>>> Oded >>>>>> >>>>>>> --- >>>>>>> drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++--- >>>>>>> 1 file changed, 2 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c >>>>>>> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c >>>>>>> index 95d5af1..236562f 100644 >>>>>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c >>>>>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c >>>>>>> @@ -34,7 +34,7 @@ >>>>>>> #define KFD_DRIVER_MINOR 7 >>>>>>> #define KFD_DRIVER_PATCHLEVEL 0 >>>>>>> -const struct kfd2kgd_calls *kfd2kgd; >>>>>>> +const struct kfd2kgd_calls *kfd2kgd = NULL; >>>>>>> static const struct kgd2kfd_calls kgd2kfd = { >>>>>>> .exit = kgd2kfd_exit, >>>>>>> .probe = kgd2kfd_probe, >>>>>>> @@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init); >>>>>>> void kgd2kfd_exit(void) >>>>>>> { >>>>>>> + kfd2kgd = NULL; >>>>>>> } >>>>>>> static int __init kfd_module_init(void) >>>>>>> { >>>>>>> int err; >>>>>>> - kfd2kgd = NULL; >>>>>>> - >>>>>>> /* Verify module parameters */ >>>>>>> if ((sched_policy < KFD_SCHED_POLICY_HWS) || >>>>>>> (sched_policy > KFD_SCHED_POLICY_NO_HWS)) { >>>>>> >>>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/