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: Mon, 22 Dec 2014 09:57:50 +0100 Message-ID: <5497DD0E.7040400@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> <5496EDF1.7080106@vodafone.de> <5496EF34.70302@amd.com> <5496F0DD.40903@vodafone.de> <5497C98C.2080208@amd.com> <5497CB91.2080306@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 B8C516E1F0 for ; Mon, 22 Dec 2014 00:58:30 -0800 (PST) In-Reply-To: <5497CB91.2080306@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 , Dave Airlie Cc: "Deucher, Alexander" , "Elifaz, Dana" , LKML , dri-devel List-Id: dri-devel@lists.freedesktop.org QW0gMjIuMTIuMjAxNCB1bSAwODo0MyBzY2hyaWViIE9kZWQgR2FiYmF5Ogo+Cj4KPiBPbiAxMi8y Mi8yMDE0IDA5OjQwIEFNLCBEYXZlIEFpcmxpZSB3cm90ZToKPj4+Pj4+PiBUaGVyZSBzaG91bGQg YmUsIGJ1dCB3aGVuIHRoZSBtb2R1bGVzIGFyZSBjb21waWxlZCBpbiwgdGhleSBhcmUgCj4+Pj4+ Pj4gbG9hZGVkCj4+Pj4+Pj4gYmFzZWQgb24KPj4+Pj4+PiBsaW5rIG9yZGVyIG9ubHksIGlmIHRo ZXkgYXJlIGluIHRoZSBzYW1lIGdyb3VwLCBhbmQgdGhlIGdyb3VwcyBhcmUKPj4+Pj4+PiBsb2Fk ZWQgYnkgYQo+Pj4+Pj4+IHByZS1kZWZpbmVkIG9yZGVyLgo+Pj4+Pj4KPj4+Pj4+IElzIHRoYXQg cmVhbGx5IHN0aWxsIHVwIHRvIGRhdGU/IEkndmUgc2VlbiBlZmZvcnQgdG8gY2hhbmdlIHRoYXQK Pj4+Pj4+IHNvbWV0aGluZyBsaWtlCj4+Pj4+PiAxMCsgeWVhcnMgYWdvIHdoZW4gUnVzdHkgcmV3 b3JrZWQgdGhlIG1vZHVsZSBzeXN0ZW0uIEFuZCBpdCBpcyAKPj4+Pj4+IGNvbW1pbmcKPj4+Pj4+ IHVwIG9uIHRoZQo+Pj4+Pj4gbGlzdHMgYWdhaW4gZnJvbSB0aW1lIHRvIHRpbWUuCj4+Pj4+Cj4+ Pj4+ICBGcm9tIHdoYXQgSSBjYW4gc2VlIGluIHRoZSBNYWtlZmlsZSBydWxlcywgY29kZSBhbmQg Z29vZ2xlLCB5ZXMsIAo+Pj4+PiB0aGF0J3MKPj4+Pj4gc3RpbGwKPj4+Pj4gdGhlIHNpdHVhdGlv bi4gSWYgc29tZW9uZSB3aWxsIHByb3ZlIG1lIHdyb25nIEkgd2lsbCBiZSBtb3JlIHRoYW4gCj4+ Pj4+IGhhcHB5Cj4+Pj4+IHRvCj4+Pj4+IGNvcnJlY3QgbXkgY29kZS4KPj4+Pj4+Cj4+Pj4+Pgo+ Pj4+Pj4+IEkgZG9uJ3Qgd2FudCB0byBtb3ZlIGlvbW11IGJlZm9yZSBncHUsIHNvIEkgZG9uJ3Qg aGF2ZSBhIAo+Pj4+Pj4+IHNvbHV0aW9uIGZvcgo+Pj4+Pj4+IHRoZQo+Pj4+Pj4+IG9yZGVyIGJl dHdlZW4gYW1ka2ZkIGFuZCBhbWRfaW9tbXVfdjIuCj4+Pj4+Pgo+Pj4+Pj4gV2h5IG5vdD8gVGhh dCdzIHN0aWxsIGJldHRlciB0aGFuIGNyZWF0aW5nIGEga2VybmVsIHdvcmtxdWV1ZSwKPj4+Pj4+ IHNjaGVkdWxpbmcgb25lCj4+Pj4+PiB3b3JrIGl0ZW0gb24gaXQsIHJlc2NoZWR1bGluZyB0aGUg dGFzayB1bnRpbCBldmVyeXRoaW5nIGlzIAo+Pj4+Pj4gY29tcGxldGVkIGFuZAo+Pj4+Pj4geW91 IGNhbgo+Pj4+Pj4gY29udGludWUuCj4+Pj4+Cj4+Pj4+IEJlY2F1c2UgSSBkb24ndCBrbm93IHRo ZSBjb25zZXF1ZW5jZXMgb2YgbW92aW5nIGFuIGVudGlyZSAKPj4+Pj4gc3Vic3lzdGVtIGluCj4+ Pj4+IGZyb250Cj4+Pj4+IG9mIGFub3RoZXIgb25lLiBJbiBhZGRpdGlvbiwgZXZlbiBpZiBldmVy eW9uZSBhZ3JlZXMsIEknbSBwcmV0dHkgc3VyZQo+Pj4+PiB0aGF0Cj4+Pj4+IExpbnVzIHdvbid0 IGJlIGhhcHB5IHRvIGRvIHRoYXQgaW4gLXJjIHN0YWdlcy4gU28gbWF5YmUgdGhpcyBpcyAKPj4+ Pj4gc29tZXRoaW5nCj4+Pj4+IHRvCj4+Pj4+IGNvbnNpZGVyIGZvciAzLjIwIG1lcmdlIHdpbmRv dywgYnV0IEkgd291bGQgc3RpbGwgbGlrZSB0byBwcm92aWRlIGEKPj4+Pj4gc29sdXRpb24KPj4+ Pj4gZm9yIDMuMTkuCj4+Pj4KPj4+Pgo+Pj4+IFllYWgsIHRydWUgaW5kZWVkLiBIb3cgYWJvdXQg ZGVwZW5kaW5nIG9uIGV2ZXJ5dGhpbmcgYmVpbmcgY29tcGlsZWQgYXMKPj4+PiBtb2R1bGUKPj4+ PiBmb3IgMy4xOSB0aGVuPyBTdGlsbCBiZXR0ZXIgdGhhbiBoYXZpbmcgc3VjaCBhIGhhY2sgaW4g dGhlIGRyaXZlciAKPj4+PiBmb3IgYXMgYQo+Pj4+IHRlbXBvcmFyeSB3b3JrYXJvdW5kIGZvciBv bmUgcmVsZWFzZS4KPj4+Pgo+Pj4gSSB0aG91Z2h0IGFib3V0IGl0LCBidXQgYmVjYXVzZSB0aGlz IHByb2JsZW0gd2FzIG9yaWdpbmFsbHkgcmVwb3J0ZWQgCj4+PiBieSBhCj4+PiB1c2VyIHRoYXQg dG9sZCB1cyBoZSBjb3VsZG4ndCB1c2UgbW9kdWxlcyBiZWNhdXNlIG9mIGhpcyBzZXR1cCwgSSAK Pj4+IGRlY2lkZWQKPj4+IG5vdCB0by4KPj4+IEkgYXNzdW1lIHRoZXJlIGFyZSBvdGhlciB1c2Vy cyBvdXQgdGhlcmUgd2hvIG5lZWRzIHRoaXMgb3B0aW9uIAo+Pj4gKGNvbXBpbGVkCj4+PiBldmVy eXRoaW5nIGluIHRoZSBrZXJuZWwgLSBlbWJlZGRlZCA/KSwgc28gSSBkb24ndCB3YW50IHRvIG1h a2UgCj4+PiB0aGVpciBsaWZlCj4+PiBoYXJkZXIuCj4+Pgo+Pj4gSW4gYWRkaXRpb24sIHNheWlu ZyBpdCBpcyBhIHdvcmthcm91bmQgZm9yIG9uZSByZWxlYXNlIGlzIHRydWUgaW4gY2FzZQo+Pj4g bW92aW5nIGlvbW11IHN1YnN5c3RlbSBpbiBmcm9udCBvZiBncHUgc3Vic3lzdGVtIGlzIGFjY2Vw dGFibGUgYW5kIAo+Pj4gZG9lc24ndAo+Pj4gY2F1c2Ugb3RoZXIgcHJvYmxlbXMsIHVua25vd24g YXQgdGhpcyBwb2ludC4KPj4+Cj4+PiBCb3R0b20gbGluZSwgbXkgcGVyc29uYWwgcHJlZmVyZW5j ZSBpcyB0byBoZWxwIHRoZSB1c2VycyBfbm93XyBhbmQgaWYgYQo+Pj4gYmV0dGVyIGZpeCBpcyBm b3VuZCBpbiB0aGUgZnV0dXJlLCBjaGFuZ2UgdGhlIGNvZGUgYWNjb3JkaW5nbHkuCj4+Cj4+IE15 IGd1ZXNzIGlzIG1vdmluZyB0aGUgaW9tbXUgc3Vic3lzdGVtIGluIGZyb250IG9mIHRoZSBHUFUg d291bGQgYmUgCj4+IHJhdGlvbmFsLgo+Pgo+PiBJdCBkb2VzIHNlZW0gbGlrZSBpdCB3b3VsZCBn ZW5lcmFsbHkgaGF2ZSBhIGRlcGVuZCBpbiB0aGF0IG9yZGVyLgo+Pgo+PiBEYXZlLgo+Pgo+IERh dmUsCj4gSSBhZ3JlZSwgYnV0IGRvbid0IHlvdSB0aGluayBpdCBpcyB0b28gcmlza3kgZm9yIC1y YyBzdGFnZXMgPwo+IElmIG5vdCwgSSBjYW4gdHJ5IGl0IGFuZCBpZiBpdCB3b3JrcyBvbiBLViwg SSBjYW4gc3VibWl0IGEgcGF0Y2guCj4gQnV0IGlmIHlvdSBkbyB0aGluayBpdCBpcyByaXNreSwg d2hhdCBkbyB5b3UgcmVjb21tZW5kIGZvciAzLjE5ID8gRG8gCj4gdGhlIGZpeCBJIHN1Z2dlc3Rl ZCBvciBkaXNhYmxlIGJ1aWxkLWluIGNvbXBpbGF0aW9uIG9wdGlvbiA/CgpJIHdvdWxkIHNheSBj cmVhdGUgdGhlIHBhdGNoIG9mIGNoYW5naW5nIHRoZSBvcmRlciAoc2hvdWxkIGJlIHRyaXZpYWwp LCAKZGVzY3JpYmUgaW4gZGV0YWlsIGluIHRoZSBjb21taXQgbWVzc2FnZSB3aGF0IHRoaXMgaXMg c3VwcG9zZWQgdG8gZml4IAphbmQgd2h5IHN1Y2ggYW4gc2V2ZXJlIGNoYW5nZSB3YXMgZG9uZSBp biAtcmMxIGFuZCBzdWJtaXQgaXQgdXBzdHJlYW0uCgpXZSBjYW4gc3RpbGwgcmV2ZXJ0IGl0IGlu IC1yYzIgaWYgaXQgYnJlYWtzIGFueXRoaW5nLgoKQ2hyaXN0aWFuLgoKPgo+ICAgICBPZGVkCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwg bWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754084AbaLVI6b (ORCPT ); Mon, 22 Dec 2014 03:58:31 -0500 Received: from pegasos-out.vodafone.de ([80.84.1.38]:40493 "EHLO pegasos-out.vodafone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753974AbaLVI6a (ORCPT ); Mon, 22 Dec 2014 03:58:30 -0500 X-Spam-Flag: NO X-Spam-Score: 0.157 Authentication-Results: rohrpostix1.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 BF8B92602E3 Message-ID: <5497DD0E.7040400@vodafone.de> Date: Mon, 22 Dec 2014 09:57:50 +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 , Dave Airlie CC: dri-devel , "Deucher, Alexander" , "Elifaz, Dana" , LKML 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> <5497C98C.2080208@amd.com> <5497CB91.2080306@amd.com> In-Reply-To: <5497CB91.2080306@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 22.12.2014 um 08:43 schrieb Oded Gabbay: > > > On 12/22/2014 09:40 AM, Dave Airlie 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. >> >> My guess is moving the iommu subsystem in front of the GPU would be >> rational. >> >> It does seem like it would generally have a depend in that order. >> >> Dave. >> > Dave, > I agree, but don't you think it is too risky for -rc stages ? > If not, I can try it and if it works on KV, I can submit a patch. > But if you do think it is risky, what do you recommend for 3.19 ? Do > the fix I suggested or disable build-in compilation option ? I would say create the patch of changing the order (should be trivial), describe in detail in the commit message what this is supposed to fix and why such an severe change was done in -rc1 and submit it upstream. We can still revert it in -rc2 if it breaks anything. Christian. > > Oded