From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init Date: Sun, 21 Dec 2014 16:57:37 +0100 Message-ID: <5496EDF1.7080106@vodafone.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 3EAE96E30E for ; Sun, 21 Dec 2014 07:58:16 -0800 (PST) In-Reply-To: <5496CA0F.8000800@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Oded Gabbay , dri-devel@lists.freedesktop.org Cc: Alexander.Deucher@amd.com, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org PiBUaGVyZSBzaG91bGQgYmUsIGJ1dCB3aGVuIHRoZSBtb2R1bGVzIGFyZSBjb21waWxlZCBpbiwg dGhleSBhcmUgbG9hZGVkIAo+IGJhc2VkIG9uCj4gbGluayBvcmRlciBvbmx5LCBpZiB0aGV5IGFy ZSBpbiB0aGUgc2FtZSBncm91cCwgYW5kIHRoZSBncm91cHMgYXJlIAo+IGxvYWRlZCBieSBhCj4g cHJlLWRlZmluZWQgb3JkZXIuIApJcyB0aGF0IHJlYWxseSBzdGlsbCB1cCB0byBkYXRlPyBJJ3Zl IHNlZW4gZWZmb3J0IHRvIGNoYW5nZSB0aGF0IApzb21ldGhpbmcgbGlrZSAxMCsgeWVhcnMgYWdv IHdoZW4gUnVzdHkgcmV3b3JrZWQgdGhlIG1vZHVsZSBzeXN0ZW0uIEFuZCAKaXQgaXMgY29tbWlu ZyB1cCBvbiB0aGUgbGlzdHMgYWdhaW4gZnJvbSB0aW1lIHRvIHRpbWUuCgo+IEkgZG9uJ3Qgd2Fu dCB0byBtb3ZlIGlvbW11IGJlZm9yZSBncHUsIHNvIEkgZG9uJ3QgaGF2ZSBhIHNvbHV0aW9uIGZv ciAKPiB0aGUgb3JkZXIgYmV0d2VlbiBhbWRrZmQgYW5kIGFtZF9pb21tdV92Mi4gCldoeSBub3Q/ IFRoYXQncyBzdGlsbCBiZXR0ZXIgdGhhbiBjcmVhdGluZyBhIGtlcm5lbCB3b3JrcXVldWUsIApz Y2hlZHVsaW5nIG9uZSB3b3JrIGl0ZW0gb24gaXQsIHJlc2NoZWR1bGluZyB0aGUgdGFzayB1bnRp bCBldmVyeXRoaW5nIAppcyBjb21wbGV0ZWQgYW5kIHlvdSBjYW4gY29udGludWUuCgpDaHJpc3Rp YW4uCgpBbSAyMS4xMi4yMDE0IHVtIDE0OjI0IHNjaHJpZWIgT2RlZCBHYWJiYXk6Cj4KPgo+IE9u IDEyLzIxLzIwMTQgMDM6MDYgUE0sIE9kZWQgR2FiYmF5IHdyb3RlOgo+Pgo+Pgo+PiBPbiAxMi8y MS8yMDE0IDAyOjE5IFBNLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+Pj4gQW0gMjEuMTIuMjAx NCB1bSAxMjozNCBzY2hyaWViIE9kZWQgR2FiYmF5Ogo+Pj4+Cj4+Pj4KPj4+PiBPbiAxMi8yMS8y MDE0IDAxOjI3IFBNLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+Pj4+PiBBbSAyMC4xMi4yMDE0 IHVtIDIxOjQ2IHNjaHJpZWIgT2RlZCBHYWJiYXk6Cj4+Pj4+PiBXaGVuIGFtZGtmZCBhbmQgcmFk ZW9uIGFyZSBjb21waWxlZCBpbnNpZGUgdGhlIGtlcm5lbCBpbWFnZSAobm90IAo+Pj4+Pj4gYXMg bW9kdWxlcyksCj4+Pj4+PiByYWRlb24gd2lsbCBsb2FkIGJlZm9yZSBhbWRrZmQgYW5kIHdpbGwg c2V0ICprZmQya2dkIHRvIGl0cyAKPj4+Pj4+IGludGVyZmFjZQo+Pj4+Pj4gc3RydWN0dXJlLiBU aGVyZWZvcmUsIHdlIG11c3Qgbm90IHNldCAqa2ZkMmtnZCB0byBOVUxMIHdoZW4gCj4+Pj4+PiBh bWRrZmQgaXMgbG9hZGVkCj4+Pj4+PiBiZWNhdXNlIGl0IHdpbGwgb3ZlcnJpZGUgcmFkZW9uJ3Mg aW5pdGlhbGl6YXRpb24gYW5kIGNhdXNlIGtlcm5lbCAKPj4+Pj4+IEJVRy4KPj4+Pj4+Cj4+Pj4+ PiBTaWduZWQtb2ZmLWJ5OiBPZGVkIEdhYmJheSA8b2RlZC5nYWJiYXlAYW1kLmNvbT4KPj4+Pj4K Pj4+Pj4gWW91IHNob3VsZCBwcm9iYWJseSByYXRoZXIgZml4IHRoZSBkZXBlbmRlbmN5IGJldHdl ZW4gdGhlIHR3byAKPj4+Pj4gbW9kdWxlcyB0byBnZXQgYW4KPj4+Pj4gZGV0ZXJtaW5lZCBsb2Fk IG9yZGVyIGluc3RlYWQgb2YgZG9pbmcgc3VjaCBuYXN0eSB3b3JrYXJvdW5kcy4KPj4+Pj4KPj4+ Pj4gQ2hyaXN0aWFuLgo+Pj4+Cj4+Pj4gVGhlIHByb2JsZW0gaXMgdGhhdCB3aGVuIG1vZHVsZXMg YXJlIGNvbXBpbGVkIGluc2lkZSB0aGUga2VybmVsLCAKPj4+PiB0aGVyZSBpcyBOTwo+Pj4+IGRl dGVybWluZWQgbG9hZCBvcmRlciBhbmQgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGVuZm9yY2Ug dGhhdC4gSWYgCj4+Pj4gdGhlcmUKPj4+PiBpcy93YXMgc3VjaCBhIG1lY2hhbmlzbSwgSSB3b3Vs ZCBvZiBjb3Vyc2UgcHJlZmVyIHRvIHVzZSBpdC4KPj4+Cj4+PiBUaGVyZSBzaG91bGQgYmUgYW4g ZGV0ZXJtaW5lZCBvcmRlciBiYXNlZCBvbiB0aGUgc3ltYm9sIHVzZSwgb3RoZXJ3aXNlCj4+PiBp bml0aWFsaXppbmcgbW9zdCBvZiB0aGUga2VybmVsIG1vZHVsZXMgd291bGRuJ3Qgd29yayBhcyBl eHBlY3RlZC4gCj4+PiBGb3IgZXhhbXBsZQo+Pj4gcmFkZW9uIGRlcGVuZHMgb24gdGhlIGRybSBt b2R1bGUgbXVzdCBiZSBsb2FkZWQgYmVmb3JlIHJhZGVvbiBpcyAKPj4+IGxvYWRlZC4KPj4gVGhl cmUgc2hvdWxkIGJlLCBidXQgd2hlbiB0aGUgbW9kdWxlcyBhcmUgY29tcGlsZWQgaW4sIHRoZXkg YXJlIAo+PiBsb2FkZWQgYmFzZWQgb24KPj4gbGluayBvcmRlciBvbmx5LCBpZiB0aGV5IGFyZSBp biB0aGUgc2FtZSBncm91cCwgYW5kIHRoZSBncm91cHMgYXJlIAo+PiBsb2FkZWQgYnkgYQo+PiBw cmUtZGVmaW5lZCBvcmRlci4KPj4gVGhlIGdyb3VwcyBhcmU6IHB1cmUsIGNvcmUsIHBvc3Rjb3Jl LCBhcmNoLCBzdWJzeXMsIGZzLCBkZXZpY2UgKHdoaWNoIAo+PiByZXByZXNlbnRzCj4+IGFsbCB0 aGUgbW9kdWxlcykgYW5kIGxhdGUuIFNlZSBpbml0LmgKPj4KPj4gU28gcmFkZW9uLCBhbWRrZmQg YW5kIGFtZF9pb21tdV92MiBhcmUgYWxsIGluIGRldmljZSBncm91cCwgYW5kIGluIAo+PiB0aGUg Z3JvdXAKPj4gdGhleSBhcmUgb3JkZXJlZCBieSB0aGVpciBsaW5rIG9yZGVyLgo+Pgo+PiBZZXMs IHJhZGVvbiBsb2FkcyBhZnRlciBkcm0sIGJlY2F1c2UgZHJtKi5vIGFyZSBiZWZvcmUgcmFkZW9u Ki5vIGluIHRoZQo+PiBNYWtlZmlsZS4gU2VlCj4+IGh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9x dWVzdGlvbnMvNTY2OTY0Ny9saW51eC1vcmRlci1vZi1zdGF0aWNhbGx5LWxpbmtlZC1tb2R1bGUt bG9hZGluZyAKPj4KPj4KPgo+IFNvIEkgdHJpZWQgbW92aW5nIGFtZGtmZCBpbnNpZGUgdGhlIE1h a2VmaWxlIGJlZm9yZSByYWRlb24sIGFuZCB0aGF0IAo+IG1hZGUgYW1ka2ZkIGxvYWQgYmVmb3Jl IHJhZGVvbiBkaWQuIFRoaXMgc29sdmVzIG15IGZpcnN0IHByb2JsZW0gLSAKPiBvcmRlciBiZXR3 ZWVuIGFtZGtmZCBhbmQgcmFkZW9uLiBIb3dldmVyLCBhbWRfaW9tbXVfdjIgZG9lc24ndCBiZWxv bmcgCj4gdG8gdGhlIGRybSBNYWtlZmlsZSwgYW5kIEkgZG9uJ3Qgd2FudCB0byBtb3ZlIGlvbW11 IGJlZm9yZSBncHUsIHNvIEkgCj4gZG9uJ3QgaGF2ZSBhIHNvbHV0aW9uIGZvciB0aGUgb3JkZXIg YmV0d2VlbiBhbWRrZmQgYW5kIGFtZF9pb21tdV92Mi4KPgo+ICAgICBPZGVkCj4+Cj4+Cj4+Pgo+ Pj4+Cj4+Pj4gQWN0dWFsbHksIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIGtlcm5lbCBkb2Vz bid0IGVuZm9yY2UgdGhlIG9yZGVyCj4+Pj4gYWNjb3JkaW5nIHRvIHRoZSB1c2Ugb2YgZXhwb3J0 ZWQgc3ltYm9scywgbGlrZSBpdCBkb2VzIHdpdGggbW9kdWxlcy4KPj4+Cj4+PiBZZWFoLCB0aGF0 J3MgaW5kZWVkIHJhdGhlciBzdHJhbmdlLiBUaGVyZSBtdXN0IGJlIHNvbWV0aGluZyBpbiB0aGUg Cj4+PiBhbWRrZmQgY29kZQo+Pj4gd2hpY2ggYnJva2UgdGhhdCBzb21laG93Lgo+PiBJTU8sIHRo YXQncyBhIGZhci1mZXRjaGVkIGd1ZXNzLiBDb3VsZCB5b3UgcG9pbnQgdG8gc29tZXRoaW5nIG1v cmUgCj4+IHNwZWNpZmljID8KPj4KPj4+Cj4+PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHlvdSB0 aGUgZGVzaXJlZCBpbml0IG9yZGVyIGlzIHJhZGVvbiBhbmQgCj4+PiBhbWRfaW9tbXVfdjIKPj4+ IGZpcnN0IGFuZCB0aGVuIGFtZGtmZCwgcmlnaHQ/Cj4+IEFjdHVhbGx5IG5vLiBUaGUgcHJlZmVy cmVkIG9yZGVyIGlzIGFtZF9pb21tdV92MiwgYW1ka2ZkIGFuZCByYWRlb24gCj4+IGxhc3QuIFRo aXMKPj4gaXMgdGhlIG9yZGVyIHRoYXQgaGFwcGVucyB3aGVuIGFsbCB0aHJlZSBhcmUgYnVpbHQg YXMgbW9kdWxlcy4gTW9yZSAKPj4gYWNjdXJhdGVseSwKPj4gcmFkZW9uIGluaXRzLCBidXQgaXRz IGluaXQgdHJpZ2dlcnMgYW1ka2ZkIGluaXQsIHdoaWNoIHRyaWdnZXJzIAo+PiBhbWRfaW9tbXVf djIKPj4gaW5pdC4gU28gYmVmb3JlIHJhZGVvbiByZWFjaGVzIGl0cyBwcm9iZSBzdGFnZSwgYWxs IHRoZSBtb2R1bGVzIHdlcmUgCj4+IGluaXRpYWxpemVkLgo+Pgo+PiBTbyB3aGF0IGhhcHBlbnMg d2hlbiB5b3UgYm9vdCB3aXRoIHJhZGVvbiwKPj4+IGFtZF9pb21tdV92MiBhbmQgYW1ka2ZkIGJs YWNrbGlzdGVkIGZvciBhdXRvbWF0aWNhbGx5IGxvYWQgYW5kIG9ubHkgCj4+PiBsb2FkIGFtZGtm ZAo+Pj4gbWFudWFsbHk/Cj4+IEFzIHNhaWQgYWJvdmUsIHRoYXQncyBvay4KPj4+Cj4+Pj4gVGhl cmUgd2lsbCBhbHdheXMgYmUgZGVwZW5kZW5jaWVzIGJldHdlZW4ga2dkIChyYWRlb24pIGFuZCBh bWRrZmQgCj4+Pj4gYW5kIGJldHdlZW4KPj4+PiBhbWRrZmQgYW5kIGFtZF9pb21tdV92Mi4gSSBk b24ndCB0aGluayBJIGNhbiBlbGltaW5hdGUgdGhvc2UgCj4+Pj4gZGVwZW5kZW5jaWVzLCBub3QK Pj4+PiB3aXRob3V0IGEgdmVyeSBjb21wbGV4IHNvbHV0aW9uLiBBbmQgdGhlIGZhY3QgdGhhdCB0 aGlzIGNvbXBsZXggCj4+Pj4gc29sdXRpb24KPj4+PiBvY2N1cnMgb25seSBpbiBhIHZlcnkgc3Bl Y2lmaWMgdXNlIGNhc2UgKGFsbCBtb2R1bGVzIGNvbXBpbGVkIGluKSwgCj4+Pj4gbWFrZXMgbWUK Pj4+PiBsZXNzIGluY2xpbmVkIHRvIGRvIHRoYXQuCj4+Pj4KPj4+PiBTbyBJIGRvbid0IHNlZSBp dCBhcyBhICJuYXN0eSB3b3JrYXJvdW5kIi4gSSB3b3VsZCBjYWxsIGl0IGp1c3QgYSAKPj4+PiAi d29ya2Fyb3VuZCIKPj4+PiBmb3IgYSBzcGVjaWZpYyB1c2UgY2FzZSwgd2hpY2ggc2hvdWxkIGJl IHNvbHZlZCBieSBhIGdlbmVyaWMgCj4+Pj4gc29sdXRpb24gdG8gdGhlCj4+Pj4ga2VybmVsIGVu Zm9yY2luZyBsb2FkIG9yZGVycy4KPj4+Cj4+PiBUaGUgbm9ybWFsIGtlcm5lbCBtb2R1bGUgaGFu ZGxpbmcgYWxyZWFkeSBzaG91bGQgcHJvdmlkZSB0aGUgY29ycmVjdCAKPj4+IGluaXQgb3JkZXIs Cj4+PiBzbyBJIHdvdWxkIHN0aWxsIGNhbGwgdGhpcyBhIHJhdGhlciBuYXN0eSB3b3JrYXJvdW5k IGJlY2F1c2Ugd2UgCj4+PiBjb3VsZG4ndCBmaW5kCj4+PiB0aGUgdW5kZXJseWluZyBwcm9ibGVt Lgo+PiBXZWxsLCB0aGUgbm9ybWFsIGtlcm5lbCBtb2R1bGUgaGFuZGxpbmcgZG9lc24ndCB3b3Jr IHdoZW4gYWxsIG1vZHVsZXMgCj4+IGFyZQo+PiBjb21waWxlZCBpbi4gSSdtIG5vdCBhIGh1Z2Ug ZXhwZXJ0IG9uIHRoaXMgaXNzdWUgc28gSSBoYWQgSm9lcmcgCj4+IFJvZWRlbCBoZWxwIG1lCj4+ IGFuYWx5emUgdGhpcyAodGhhbmtzIEpvZXJnKSBhbmQgaGUgYWdyZWVkIHRoYXQgdGhlcmUgaXMg bm8gCj4+IGVuZm9yY2VtZW50IG9mIG9yZGVyCj4+IGluIHRoaXMgY2FzZS4KPj4KPj4+Cj4+PiBD aHJpc3RpYW4uCj4+Pgo+Pj4+Cj4+Pj4gICAgIE9kZWQKPj4+Pj4KPj4+Pj4+IC0tLQo+Pj4+Pj4g ICBkcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMgfCA1ICsrLS0tCj4+Pj4+ PiAgIDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCj4+Pj4+ Pgo+Pj4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9hbWQvYW1ka2ZkL2tmZF9tb2R1 bGUuYwo+Pj4+Pj4gYi9kcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMKPj4+ Pj4+IGluZGV4IDk1ZDVhZjEuLjIzNjU2MmYgMTAwNjQ0Cj4+Pj4+PiAtLS0gYS9kcml2ZXJzL2dw dS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMKPj4+Pj4+ICsrKyBiL2RyaXZlcnMvZ3B1L2Ry bS9hbWQvYW1ka2ZkL2tmZF9tb2R1bGUuYwo+Pj4+Pj4gQEAgLTM0LDcgKzM0LDcgQEAKPj4+Pj4+ ICAgI2RlZmluZSBLRkRfRFJJVkVSX01JTk9SICAgIDcKPj4+Pj4+ICAgI2RlZmluZSBLRkRfRFJJ VkVSX1BBVENITEVWRUwgICAgMAo+Pj4+Pj4gLWNvbnN0IHN0cnVjdCBrZmQya2dkX2NhbGxzICpr ZmQya2dkOwo+Pj4+Pj4gK2NvbnN0IHN0cnVjdCBrZmQya2dkX2NhbGxzICprZmQya2dkID0gTlVM TDsKPj4+Pj4+ICAgc3RhdGljIGNvbnN0IHN0cnVjdCBrZ2Qya2ZkX2NhbGxzIGtnZDJrZmQgPSB7 Cj4+Pj4+PiAgICAgICAuZXhpdCAgICAgICAgPSBrZ2Qya2ZkX2V4aXQsCj4+Pj4+PiAgICAgICAu cHJvYmUgICAgICAgID0ga2dkMmtmZF9wcm9iZSwKPj4+Pj4+IEBAIC04NCwxNCArODQsMTMgQEAg RVhQT1JUX1NZTUJPTChrZ2Qya2ZkX2luaXQpOwo+Pj4+Pj4gICB2b2lkIGtnZDJrZmRfZXhpdCh2 b2lkKQo+Pj4+Pj4gICB7Cj4+Pj4+PiArICAgIGtmZDJrZ2QgPSBOVUxMOwo+Pj4+Pj4gICB9Cj4+ Pj4+PiAgIHN0YXRpYyBpbnQgX19pbml0IGtmZF9tb2R1bGVfaW5pdCh2b2lkKQo+Pj4+Pj4gICB7 Cj4+Pj4+PiAgICAgICBpbnQgZXJyOwo+Pj4+Pj4gLSAgICBrZmQya2dkID0gTlVMTDsKPj4+Pj4+ IC0KPj4+Pj4+ICAgICAgIC8qIFZlcmlmeSBtb2R1bGUgcGFyYW1ldGVycyAqLwo+Pj4+Pj4gICAg ICAgaWYgKChzY2hlZF9wb2xpY3kgPCBLRkRfU0NIRURfUE9MSUNZX0hXUykgfHwKPj4+Pj4+ICAg ICAgICAgICAoc2NoZWRfcG9saWN5ID4gS0ZEX1NDSEVEX1BPTElDWV9OT19IV1MpKSB7Cj4+Pj4+ Cj4+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ PiBkcmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4+IGRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5v cmcKPj4gaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1k ZXZlbAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJp LWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751639AbaLUP6R (ORCPT ); Sun, 21 Dec 2014 10:58:17 -0500 Received: from pegasos-out.vodafone.de ([80.84.1.38]:59551 "EHLO pegasos-out.vodafone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751162AbaLUP6Q (ORCPT ); Sun, 21 Dec 2014 10:58:16 -0500 X-Spam-Flag: NO X-Spam-Score: 0.157 Authentication-Results: rohrpostix2.prod.vfnet.de (amavisd-new); dkim=softfail (invalid, public key: DNS query timeout for mail._domainkey.vodafone.de) header.i=@vodafone.de X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de 6B4D1674CF Message-ID: <5496EDF1.7080106@vodafone.de> Date: Sun, 21 Dec 2014 16:57:37 +0100 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Oded Gabbay , dri-devel@lists.freedesktop.org CC: Alexander.Deucher@amd.com, linux-kernel@vger.kernel.org, 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> In-Reply-To: <5496CA0F.8000800@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. > 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. 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