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: Mon, 22 Dec 2014 09:34:36 +0200 Message-ID: <5497C98C.2080208@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> <5496EF34.70302@amd.com> <5496F0DD.40903@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0138.outbound.protection.outlook.com [157.56.110.138]) by gabe.freedesktop.org (Postfix) with ESMTP id 8514D6E1BE for ; Sun, 21 Dec 2014 23:34:58 -0800 (PST) In-Reply-To: <5496F0DD.40903@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, "Elifaz, Dana" , linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org CgpPbiAxMi8yMS8yMDE0IDA2OjEwIFBNLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+IEFtIDIx LjEyLjIwMTQgdW0gMTc6MDMgc2NocmllYiBPZGVkIEdhYmJheToKPj4KPj4KPj4gT24gMTIvMjEv MjAxNCAwNTo1NyBQTSwgQ2hyaXN0aWFuIEvDtm5pZyB3cm90ZToKPj4+PiBUaGVyZSBzaG91bGQg YmUsIGJ1dCB3aGVuIHRoZSBtb2R1bGVzIGFyZSBjb21waWxlZCBpbiwgdGhleSBhcmUgbG9hZGVk IGJhc2VkIG9uCj4+Pj4gbGluayBvcmRlciBvbmx5LCBpZiB0aGV5IGFyZSBpbiB0aGUgc2FtZSBn cm91cCwgYW5kIHRoZSBncm91cHMgYXJlIGxvYWRlZCBieSBhCj4+Pj4gcHJlLWRlZmluZWQgb3Jk ZXIuCj4+PiBJcyB0aGF0IHJlYWxseSBzdGlsbCB1cCB0byBkYXRlPyBJJ3ZlIHNlZW4gZWZmb3J0 IHRvIGNoYW5nZSB0aGF0IHNvbWV0aGluZyBsaWtlCj4+PiAxMCsgeWVhcnMgYWdvIHdoZW4gUnVz dHkgcmV3b3JrZWQgdGhlIG1vZHVsZSBzeXN0ZW0uIEFuZCBpdCBpcyBjb21taW5nIHVwIG9uIHRo ZQo+Pj4gbGlzdHMgYWdhaW4gZnJvbSB0aW1lIHRvIHRpbWUuCj4+IEZyb20gd2hhdCBJIGNhbiBz ZWUgaW4gdGhlIE1ha2VmaWxlIHJ1bGVzLCBjb2RlIGFuZCBnb29nbGUsIHllcywgdGhhdCdzIHN0 aWxsCj4+IHRoZSBzaXR1YXRpb24uIElmIHNvbWVvbmUgd2lsbCBwcm92ZSBtZSB3cm9uZyBJIHdp bGwgYmUgbW9yZSB0aGFuIGhhcHB5IHRvCj4+IGNvcnJlY3QgbXkgY29kZS4KPj4+Cj4+Pj4gSSBk b24ndCB3YW50IHRvIG1vdmUgaW9tbXUgYmVmb3JlIGdwdSwgc28gSSBkb24ndCBoYXZlIGEgc29s dXRpb24gZm9yIHRoZQo+Pj4+IG9yZGVyIGJldHdlZW4gYW1ka2ZkIGFuZCBhbWRfaW9tbXVfdjIu Cj4+PiBXaHkgbm90PyBUaGF0J3Mgc3RpbGwgYmV0dGVyIHRoYW4gY3JlYXRpbmcgYSBrZXJuZWwg d29ya3F1ZXVlLCBzY2hlZHVsaW5nIG9uZQo+Pj4gd29yayBpdGVtIG9uIGl0LCByZXNjaGVkdWxp bmcgdGhlIHRhc2sgdW50aWwgZXZlcnl0aGluZyBpcyBjb21wbGV0ZWQgYW5kIHlvdSBjYW4KPj4+ IGNvbnRpbnVlLgo+PiBCZWNhdXNlIEkgZG9uJ3Qga25vdyB0aGUgY29uc2VxdWVuY2VzIG9mIG1v dmluZyBhbiBlbnRpcmUgc3Vic3lzdGVtIGluIGZyb250Cj4+IG9mIGFub3RoZXIgb25lLiBJbiBh ZGRpdGlvbiwgZXZlbiBpZiBldmVyeW9uZSBhZ3JlZXMsIEknbSBwcmV0dHkgc3VyZSB0aGF0Cj4+ IExpbnVzIHdvbid0IGJlIGhhcHB5IHRvIGRvIHRoYXQgaW4gLXJjIHN0YWdlcy4gU28gbWF5YmUg dGhpcyBpcyBzb21ldGhpbmcgdG8KPj4gY29uc2lkZXIgZm9yIDMuMjAgbWVyZ2Ugd2luZG93LCBi dXQgSSB3b3VsZCBzdGlsbCBsaWtlIHRvIHByb3ZpZGUgYSBzb2x1dGlvbgo+PiBmb3IgMy4xOS4K Pgo+IFllYWgsIHRydWUgaW5kZWVkLiBIb3cgYWJvdXQgZGVwZW5kaW5nIG9uIGV2ZXJ5dGhpbmcg YmVpbmcgY29tcGlsZWQgYXMgbW9kdWxlCj4gZm9yIDMuMTkgdGhlbj8gU3RpbGwgYmV0dGVyIHRo YW4gaGF2aW5nIHN1Y2ggYSBoYWNrIGluIHRoZSBkcml2ZXIgZm9yIGFzIGEKPiB0ZW1wb3Jhcnkg d29ya2Fyb3VuZCBmb3Igb25lIHJlbGVhc2UuCj4KSSB0aG91Z2h0IGFib3V0IGl0LCBidXQgYmVj YXVzZSB0aGlzIHByb2JsZW0gd2FzIG9yaWdpbmFsbHkgcmVwb3J0ZWQgYnkgYSB1c2VyIAp0aGF0 IHRvbGQgdXMgaGUgY291bGRuJ3QgdXNlIG1vZHVsZXMgYmVjYXVzZSBvZiBoaXMgc2V0dXAsIEkg ZGVjaWRlZCBub3QgdG8uCkkgYXNzdW1lIHRoZXJlIGFyZSBvdGhlciB1c2VycyBvdXQgdGhlcmUg d2hvIG5lZWRzIHRoaXMgb3B0aW9uIChjb21waWxlZCAKZXZlcnl0aGluZyBpbiB0aGUga2VybmVs IC0gZW1iZWRkZWQgPyksIHNvIEkgZG9uJ3Qgd2FudCB0byBtYWtlIHRoZWlyIGxpZmUgaGFyZGVy LgoKSW4gYWRkaXRpb24sIHNheWluZyBpdCBpcyBhIHdvcmthcm91bmQgZm9yIG9uZSByZWxlYXNl IGlzIHRydWUgaW4gY2FzZSBtb3ZpbmcgCmlvbW11IHN1YnN5c3RlbSBpbiBmcm9udCBvZiBncHUg c3Vic3lzdGVtIGlzIGFjY2VwdGFibGUgYW5kIGRvZXNuJ3QgY2F1c2Ugb3RoZXIgCnByb2JsZW1z LCB1bmtub3duIGF0IHRoaXMgcG9pbnQuCgpCb3R0b20gbGluZSwgbXkgcGVyc29uYWwgcHJlZmVy ZW5jZSBpcyB0byBoZWxwIHRoZSB1c2VycyBfbm93XyBhbmQgaWYgYSBiZXR0ZXIgCmZpeCBpcyBm b3VuZCBpbiB0aGUgZnV0dXJlLCBjaGFuZ2UgdGhlIGNvZGUgYWNjb3JkaW5nbHkuCgoJT2RlZAoK PiBDaHJpc3RpYW4uCj4KPj4KPj4gICAgIE9kZWQKPj4+Cj4+PiBDaHJpc3RpYW4uCj4+Pgo+Pj4g QW0gMjEuMTIuMjAxNCB1bSAxNDoyNCBzY2hyaWViIE9kZWQgR2FiYmF5Ogo+Pj4+Cj4+Pj4KPj4+ PiBPbiAxMi8yMS8yMDE0IDAzOjA2IFBNLCBPZGVkIEdhYmJheSB3cm90ZToKPj4+Pj4KPj4+Pj4K Pj4+Pj4gT24gMTIvMjEvMjAxNCAwMjoxOSBQTSwgQ2hyaXN0aWFuIEvDtm5pZyB3cm90ZToKPj4+ Pj4+IEFtIDIxLjEyLjIwMTQgdW0gMTI6MzQgc2NocmllYiBPZGVkIEdhYmJheToKPj4+Pj4+Pgo+ Pj4+Pj4+Cj4+Pj4+Pj4gT24gMTIvMjEvMjAxNCAwMToyNyBQTSwgQ2hyaXN0aWFuIEvDtm5pZyB3 cm90ZToKPj4+Pj4+Pj4gQW0gMjAuMTIuMjAxNCB1bSAyMTo0NiBzY2hyaWViIE9kZWQgR2FiYmF5 Ogo+Pj4+Pj4+Pj4gV2hlbiBhbWRrZmQgYW5kIHJhZGVvbiBhcmUgY29tcGlsZWQgaW5zaWRlIHRo ZSBrZXJuZWwgaW1hZ2UgKG5vdCBhcwo+Pj4+Pj4+Pj4gbW9kdWxlcyksCj4+Pj4+Pj4+PiByYWRl b24gd2lsbCBsb2FkIGJlZm9yZSBhbWRrZmQgYW5kIHdpbGwgc2V0ICprZmQya2dkIHRvIGl0cyBp bnRlcmZhY2UKPj4+Pj4+Pj4+IHN0cnVjdHVyZS4gVGhlcmVmb3JlLCB3ZSBtdXN0IG5vdCBzZXQg KmtmZDJrZ2QgdG8gTlVMTCB3aGVuIGFtZGtmZCBpcwo+Pj4+Pj4+Pj4gbG9hZGVkCj4+Pj4+Pj4+ PiBiZWNhdXNlIGl0IHdpbGwgb3ZlcnJpZGUgcmFkZW9uJ3MgaW5pdGlhbGl6YXRpb24gYW5kIGNh dXNlIGtlcm5lbCBCVUcuCj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogT2RlZCBH YWJiYXkgPG9kZWQuZ2FiYmF5QGFtZC5jb20+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFlvdSBzaG91bGQg cHJvYmFibHkgcmF0aGVyIGZpeCB0aGUgZGVwZW5kZW5jeSBiZXR3ZWVuIHRoZSB0d28gbW9kdWxl cyB0bwo+Pj4+Pj4+PiBnZXQgYW4KPj4+Pj4+Pj4gZGV0ZXJtaW5lZCBsb2FkIG9yZGVyIGluc3Rl YWQgb2YgZG9pbmcgc3VjaCBuYXN0eSB3b3JrYXJvdW5kcy4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gQ2hy aXN0aWFuLgo+Pj4+Pj4+Cj4+Pj4+Pj4gVGhlIHByb2JsZW0gaXMgdGhhdCB3aGVuIG1vZHVsZXMg YXJlIGNvbXBpbGVkIGluc2lkZSB0aGUga2VybmVsLCB0aGVyZSBpcyBOTwo+Pj4+Pj4+IGRldGVy bWluZWQgbG9hZCBvcmRlciBhbmQgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGVuZm9yY2UgdGhh dC4gSWYgdGhlcmUKPj4+Pj4+PiBpcy93YXMgc3VjaCBhIG1lY2hhbmlzbSwgSSB3b3VsZCBvZiBj b3Vyc2UgcHJlZmVyIHRvIHVzZSBpdC4KPj4+Pj4+Cj4+Pj4+PiBUaGVyZSBzaG91bGQgYmUgYW4g ZGV0ZXJtaW5lZCBvcmRlciBiYXNlZCBvbiB0aGUgc3ltYm9sIHVzZSwgb3RoZXJ3aXNlCj4+Pj4+ PiBpbml0aWFsaXppbmcgbW9zdCBvZiB0aGUga2VybmVsIG1vZHVsZXMgd291bGRuJ3Qgd29yayBh cyBleHBlY3RlZC4gRm9yCj4+Pj4+PiBleGFtcGxlCj4+Pj4+PiByYWRlb24gZGVwZW5kcyBvbiB0 aGUgZHJtIG1vZHVsZSBtdXN0IGJlIGxvYWRlZCBiZWZvcmUgcmFkZW9uIGlzIGxvYWRlZC4KPj4+ Pj4gVGhlcmUgc2hvdWxkIGJlLCBidXQgd2hlbiB0aGUgbW9kdWxlcyBhcmUgY29tcGlsZWQgaW4s IHRoZXkgYXJlIGxvYWRlZAo+Pj4+PiBiYXNlZCBvbgo+Pj4+PiBsaW5rIG9yZGVyIG9ubHksIGlm IHRoZXkgYXJlIGluIHRoZSBzYW1lIGdyb3VwLCBhbmQgdGhlIGdyb3VwcyBhcmUgbG9hZGVkIGJ5 IGEKPj4+Pj4gcHJlLWRlZmluZWQgb3JkZXIuCj4+Pj4+IFRoZSBncm91cHMgYXJlOiBwdXJlLCBj b3JlLCBwb3N0Y29yZSwgYXJjaCwgc3Vic3lzLCBmcywgZGV2aWNlICh3aGljaAo+Pj4+PiByZXBy ZXNlbnRzCj4+Pj4+IGFsbCB0aGUgbW9kdWxlcykgYW5kIGxhdGUuIFNlZSBpbml0LmgKPj4+Pj4K Pj4+Pj4gU28gcmFkZW9uLCBhbWRrZmQgYW5kIGFtZF9pb21tdV92MiBhcmUgYWxsIGluIGRldmlj ZSBncm91cCwgYW5kIGluIHRoZSBncm91cAo+Pj4+PiB0aGV5IGFyZSBvcmRlcmVkIGJ5IHRoZWly IGxpbmsgb3JkZXIuCj4+Pj4+Cj4+Pj4+IFllcywgcmFkZW9uIGxvYWRzIGFmdGVyIGRybSwgYmVj YXVzZSBkcm0qLm8gYXJlIGJlZm9yZSByYWRlb24qLm8gaW4gdGhlCj4+Pj4+IE1ha2VmaWxlLiBT ZWUKPj4+Pj4gaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy81NjY5NjQ3L2xpbnV4 LW9yZGVyLW9mLXN0YXRpY2FsbHktbGlua2VkLW1vZHVsZS1sb2FkaW5nCj4+Pj4+Cj4+Pj4+Cj4+ Pj4+Cj4+Pj4KPj4+PiBTbyBJIHRyaWVkIG1vdmluZyBhbWRrZmQgaW5zaWRlIHRoZSBNYWtlZmls ZSBiZWZvcmUgcmFkZW9uLCBhbmQgdGhhdCBtYWRlCj4+Pj4gYW1ka2ZkIGxvYWQgYmVmb3JlIHJh ZGVvbiBkaWQuIFRoaXMgc29sdmVzIG15IGZpcnN0IHByb2JsZW0gLSBvcmRlciBiZXR3ZWVuCj4+ Pj4gYW1ka2ZkIGFuZCByYWRlb24uIEhvd2V2ZXIsIGFtZF9pb21tdV92MiBkb2Vzbid0IGJlbG9u ZyB0byB0aGUgZHJtIE1ha2VmaWxlLAo+Pj4+IGFuZCBJIGRvbid0IHdhbnQgdG8gbW92ZSBpb21t dSBiZWZvcmUgZ3B1LCBzbyBJIGRvbid0IGhhdmUgYSBzb2x1dGlvbiBmb3IgdGhlCj4+Pj4gb3Jk ZXIgYmV0d2VlbiBhbWRrZmQgYW5kIGFtZF9pb21tdV92Mi4KPj4+Pgo+Pj4+ICAgICBPZGVkCj4+ Pj4+Cj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gQWN0dWFsbHksIEkgZG9uJ3QgdW5kZXJz dGFuZCB3aHkgdGhlIGtlcm5lbCBkb2Vzbid0IGVuZm9yY2UgdGhlIG9yZGVyCj4+Pj4+Pj4gYWNj b3JkaW5nIHRvIHRoZSB1c2Ugb2YgZXhwb3J0ZWQgc3ltYm9scywgbGlrZSBpdCBkb2VzIHdpdGgg bW9kdWxlcy4KPj4+Pj4+Cj4+Pj4+PiBZZWFoLCB0aGF0J3MgaW5kZWVkIHJhdGhlciBzdHJhbmdl LiBUaGVyZSBtdXN0IGJlIHNvbWV0aGluZyBpbiB0aGUgYW1ka2ZkCj4+Pj4+PiBjb2RlCj4+Pj4+ PiB3aGljaCBicm9rZSB0aGF0IHNvbWVob3cuCj4+Pj4+IElNTywgdGhhdCdzIGEgZmFyLWZldGNo ZWQgZ3Vlc3MuIENvdWxkIHlvdSBwb2ludCB0byBzb21ldGhpbmcgbW9yZSBzcGVjaWZpYyA/Cj4+ Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB5b3UgdGhlIGRlc2lyZWQg aW5pdCBvcmRlciBpcyByYWRlb24gYW5kIGFtZF9pb21tdV92Mgo+Pj4+Pj4gZmlyc3QgYW5kIHRo ZW4gYW1ka2ZkLCByaWdodD8KPj4+Pj4gQWN0dWFsbHkgbm8uIFRoZSBwcmVmZXJyZWQgb3JkZXIg aXMgYW1kX2lvbW11X3YyLCBhbWRrZmQgYW5kIHJhZGVvbiBsYXN0LiBUaGlzCj4+Pj4+IGlzIHRo ZSBvcmRlciB0aGF0IGhhcHBlbnMgd2hlbiBhbGwgdGhyZWUgYXJlIGJ1aWx0IGFzIG1vZHVsZXMu IE1vcmUKPj4+Pj4gYWNjdXJhdGVseSwKPj4+Pj4gcmFkZW9uIGluaXRzLCBidXQgaXRzIGluaXQg dHJpZ2dlcnMgYW1ka2ZkIGluaXQsIHdoaWNoIHRyaWdnZXJzIGFtZF9pb21tdV92Mgo+Pj4+PiBp bml0LiBTbyBiZWZvcmUgcmFkZW9uIHJlYWNoZXMgaXRzIHByb2JlIHN0YWdlLCBhbGwgdGhlIG1v ZHVsZXMgd2VyZQo+Pj4+PiBpbml0aWFsaXplZC4KPj4+Pj4KPj4+Pj4gU28gd2hhdCBoYXBwZW5z IHdoZW4geW91IGJvb3Qgd2l0aCByYWRlb24sCj4+Pj4+PiBhbWRfaW9tbXVfdjIgYW5kIGFtZGtm ZCBibGFja2xpc3RlZCBmb3IgYXV0b21hdGljYWxseSBsb2FkIGFuZCBvbmx5IGxvYWQKPj4+Pj4+ IGFtZGtmZAo+Pj4+Pj4gbWFudWFsbHk/Cj4+Pj4+IEFzIHNhaWQgYWJvdmUsIHRoYXQncyBvay4K Pj4+Pj4+Cj4+Pj4+Pj4gVGhlcmUgd2lsbCBhbHdheXMgYmUgZGVwZW5kZW5jaWVzIGJldHdlZW4g a2dkIChyYWRlb24pIGFuZCBhbWRrZmQgYW5kCj4+Pj4+Pj4gYmV0d2Vlbgo+Pj4+Pj4+IGFtZGtm ZCBhbmQgYW1kX2lvbW11X3YyLiBJIGRvbid0IHRoaW5rIEkgY2FuIGVsaW1pbmF0ZSB0aG9zZQo+ Pj4+Pj4+IGRlcGVuZGVuY2llcywgbm90Cj4+Pj4+Pj4gd2l0aG91dCBhIHZlcnkgY29tcGxleCBz b2x1dGlvbi4gQW5kIHRoZSBmYWN0IHRoYXQgdGhpcyBjb21wbGV4IHNvbHV0aW9uCj4+Pj4+Pj4g b2NjdXJzIG9ubHkgaW4gYSB2ZXJ5IHNwZWNpZmljIHVzZSBjYXNlIChhbGwgbW9kdWxlcyBjb21w aWxlZCBpbiksIG1ha2VzIG1lCj4+Pj4+Pj4gbGVzcyBpbmNsaW5lZCB0byBkbyB0aGF0Lgo+Pj4+ Pj4+Cj4+Pj4+Pj4gU28gSSBkb24ndCBzZWUgaXQgYXMgYSAibmFzdHkgd29ya2Fyb3VuZCIuIEkg d291bGQgY2FsbCBpdCBqdXN0IGEKPj4+Pj4+PiAid29ya2Fyb3VuZCIKPj4+Pj4+PiBmb3IgYSBz cGVjaWZpYyB1c2UgY2FzZSwgd2hpY2ggc2hvdWxkIGJlIHNvbHZlZCBieSBhIGdlbmVyaWMgc29s dXRpb24gdG8gdGhlCj4+Pj4+Pj4ga2VybmVsIGVuZm9yY2luZyBsb2FkIG9yZGVycy4KPj4+Pj4+ Cj4+Pj4+PiBUaGUgbm9ybWFsIGtlcm5lbCBtb2R1bGUgaGFuZGxpbmcgYWxyZWFkeSBzaG91bGQg cHJvdmlkZSB0aGUgY29ycmVjdCBpbml0Cj4+Pj4+PiBvcmRlciwKPj4+Pj4+IHNvIEkgd291bGQg c3RpbGwgY2FsbCB0aGlzIGEgcmF0aGVyIG5hc3R5IHdvcmthcm91bmQgYmVjYXVzZSB3ZSBjb3Vs ZG4ndCBmaW5kCj4+Pj4+PiB0aGUgdW5kZXJseWluZyBwcm9ibGVtLgo+Pj4+PiBXZWxsLCB0aGUg bm9ybWFsIGtlcm5lbCBtb2R1bGUgaGFuZGxpbmcgZG9lc24ndCB3b3JrIHdoZW4gYWxsIG1vZHVs ZXMgYXJlCj4+Pj4+IGNvbXBpbGVkIGluLiBJJ20gbm90IGEgaHVnZSBleHBlcnQgb24gdGhpcyBp c3N1ZSBzbyBJIGhhZCBKb2VyZyBSb2VkZWwgaGVscCBtZQo+Pj4+PiBhbmFseXplIHRoaXMgKHRo YW5rcyBKb2VyZykgYW5kIGhlIGFncmVlZCB0aGF0IHRoZXJlIGlzIG5vIGVuZm9yY2VtZW50IG9m Cj4+Pj4+IG9yZGVyCj4+Pj4+IGluIHRoaXMgY2FzZS4KPj4+Pj4KPj4+Pj4+Cj4+Pj4+PiBDaHJp c3RpYW4uCj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gICAgIE9kZWQKPj4+Pj4+Pj4KPj4+Pj4+Pj4+ IC0tLQo+Pj4+Pj4+Pj4gICBkcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMg fCA1ICsrLS0tCj4+Pj4+Pj4+PiAgIDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDMg ZGVsZXRpb25zKC0pCj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1 L2RybS9hbWQvYW1ka2ZkL2tmZF9tb2R1bGUuYwo+Pj4+Pj4+Pj4gYi9kcml2ZXJzL2dwdS9kcm0v YW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMKPj4+Pj4+Pj4+IGluZGV4IDk1ZDVhZjEuLjIzNjU2MmYg MTAwNjQ0Cj4+Pj4+Pj4+PiAtLS0gYS9kcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9k dWxlLmMKPj4+Pj4+Pj4+ICsrKyBiL2RyaXZlcnMvZ3B1L2RybS9hbWQvYW1ka2ZkL2tmZF9tb2R1 bGUuYwo+Pj4+Pj4+Pj4gQEAgLTM0LDcgKzM0LDcgQEAKPj4+Pj4+Pj4+ICAgI2RlZmluZSBLRkRf RFJJVkVSX01JTk9SICAgIDcKPj4+Pj4+Pj4+ICAgI2RlZmluZSBLRkRfRFJJVkVSX1BBVENITEVW RUwgICAgMAo+Pj4+Pj4+Pj4gLWNvbnN0IHN0cnVjdCBrZmQya2dkX2NhbGxzICprZmQya2dkOwo+ Pj4+Pj4+Pj4gK2NvbnN0IHN0cnVjdCBrZmQya2dkX2NhbGxzICprZmQya2dkID0gTlVMTDsKPj4+ Pj4+Pj4+ICAgc3RhdGljIGNvbnN0IHN0cnVjdCBrZ2Qya2ZkX2NhbGxzIGtnZDJrZmQgPSB7Cj4+ Pj4+Pj4+PiAgICAgICAuZXhpdCAgICAgICAgPSBrZ2Qya2ZkX2V4aXQsCj4+Pj4+Pj4+PiAgICAg ICAucHJvYmUgICAgICAgID0ga2dkMmtmZF9wcm9iZSwKPj4+Pj4+Pj4+IEBAIC04NCwxNCArODQs MTMgQEAgRVhQT1JUX1NZTUJPTChrZ2Qya2ZkX2luaXQpOwo+Pj4+Pj4+Pj4gICB2b2lkIGtnZDJr ZmRfZXhpdCh2b2lkKQo+Pj4+Pj4+Pj4gICB7Cj4+Pj4+Pj4+PiArICAgIGtmZDJrZ2QgPSBOVUxM Owo+Pj4+Pj4+Pj4gICB9Cj4+Pj4+Pj4+PiAgIHN0YXRpYyBpbnQgX19pbml0IGtmZF9tb2R1bGVf aW5pdCh2b2lkKQo+Pj4+Pj4+Pj4gICB7Cj4+Pj4+Pj4+PiAgICAgICBpbnQgZXJyOwo+Pj4+Pj4+ Pj4gLSAgICBrZmQya2dkID0gTlVMTDsKPj4+Pj4+Pj4+IC0KPj4+Pj4+Pj4+ICAgICAgIC8qIFZl cmlmeSBtb2R1bGUgcGFyYW1ldGVycyAqLwo+Pj4+Pj4+Pj4gICAgICAgaWYgKChzY2hlZF9wb2xp Y3kgPCBLRkRfU0NIRURfUE9MSUNZX0hXUykgfHwKPj4+Pj4+Pj4+ICAgICAgICAgICAoc2NoZWRf cG9saWN5ID4gS0ZEX1NDSEVEX1BPTElDWV9OT19IV1MpKSB7Cj4+Pj4+Pj4+Cj4+Pj4+Pgo+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+PiBk cmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4+Pj4+IGRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5v cmcKPj4+Pj4gaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ry aS1kZXZlbAo+Pj4KPj4+IC0tCj4+PiBUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2Vu ZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgta2VybmVsIiBpbgo+Pj4gdGhlIGJvZHkgb2Yg YSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcKPj4+IE1vcmUgbWFqb3Jkb21v IGluZm8gYXQgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sCj4+PiBQ bGVhc2UgcmVhZCB0aGUgRkFRIGF0ICBodHRwOi8vd3d3LnR1eC5vcmcvbGttbC8KPgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGlu ZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVk ZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754118AbaLVHfA (ORCPT ); Mon, 22 Dec 2014 02:35:00 -0500 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:44529 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751110AbaLVHe6 convert rfc822-to-8bit (ORCPT ); Mon, 22 Dec 2014 02:34:58 -0500 X-WSS-ID: 0NGZ3Q6-07-YR7-02 X-M-MSG: Message-ID: <5497C98C.2080208@amd.com> Date: Mon, 22 Dec 2014 09:34:36 +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 , "Elifaz, Dana" 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> <5496EF34.70302@amd.com> <5496F0DD.40903@vodafone.de> In-Reply-To: <5496F0DD.40903@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.221) smtp.mailfrom=Oded.Gabbay@amd.com; X-Forefront-Antispam-Report: CIP:165.204.84.221;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(428002)(377454003)(199003)(189002)(51704005)(24454002)(479174004)(64706001)(107046002)(4396001)(101416001)(54356999)(50986999)(31966008)(93886004)(50466002)(65956001)(21056001)(15395725005)(47776003)(86362001)(20776003)(65806001)(23676002)(19580405001)(80316001)(83506001)(59896002)(33656002)(19580395003)(105586002)(106466001)(97736003)(46102003)(68736005)(2950100001)(92566001)(76176999)(77096005)(84676001)(87936001)(64126003)(62966003)(77156002)(99396003)(1720100001)(36756003)(87266999)(120916001)(15975445007)(2101003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR02MB199;H:atltwp01.amd.com;FPR:;SPF:None;MLV:sfv;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR02MB199; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:BN1PR02MB199; X-Forefront-PRVS: 0433DB2766 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR02MB199; X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Dec 2014 07:34:55.4305 (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.221] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR02MB199 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/21/2014 06:10 PM, Christian König wrote: > Am 21.12.2014 um 17:03 schrieb Oded Gabbay: >> >> >> 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. > > Yeah, true indeed. How about depending on everything being compiled as module > for 3.19 then? Still better than having such a hack in the driver for as a > temporary workaround for one release. > I thought about it, but because this problem was originally reported by a user that told us he couldn't use modules because of his setup, I decided not to. I assume there are other users out there who needs this option (compiled everything in the kernel - embedded ?), so I don't want to make their life harder. In addition, saying it is a workaround for one release is true in case moving iommu subsystem in front of gpu subsystem is acceptable and doesn't cause other problems, unknown at this point. Bottom line, my personal preference is to help the users _now_ and if a better fix is found in the future, change the code accordingly. Oded > Christian. > >> >> 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/ >