From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oded Gabbay Subject: Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd Date: Thu, 8 Jan 2015 16:15:42 +0200 Message-ID: <54AE910E.5060803@amd.com> References: <1419246435-7050-1-git-send-email-oded.gabbay@amd.com> <1621810.aTt9O4Ghzs@avalon> <549FEB52.4020103@amd.com> <1678486.9ZXZnn5och@avalon> <54A12028.7020303@amd.com> <20150105154657.GJ12010@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20150105154657.GJ12010@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding , =?UTF-8?B?Q2hyaXN0aWFuIEvDtg==?= =?UTF-8?B?bmln?= Cc: Arnd Bergmann , Geert Uytterhoeven , Greg Kroah-Hartman , Will Deacon , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, Laurent Pinchart , Alexander Deucher List-Id: iommu@lists.linux-foundation.org SGkgVGhpZXJyeSwKR2VuZXJhbGx5IEkgYWdyZWUgd2l0aCB0aGUgaXNzdWVzIHlvdSBkZXNjcmli ZSBpbiB0aGUgY3VycmVudCBkZXNpZ24uCk9uZSB0YXNrIGluIG91ciAyMDE1IHdvcmtwbGFuIGlz IHRvIGNoYW5nZSB0aGUgd2hvbGUgbWV0aG9kIGFtZGtmZCBpcyBsb2FkZWQsIHNvIAppdCBjYW4g aW5kZXBlbmRlbnRseSBsb2FkIGF0IGFueSB0aW1lLCByZWdhcmRsZXNzIG9mIHRoZSBvcmRlciBv ZiBsb2FkaW5nIApiZXR3ZWVuIGl0IGFuZCByYWRlb24gYW5kIGFtZF9pb21tdV92Mi4gVG8gcmVh Y2ggdGhhdCBnb2FsLCBJIGFzc3VtZSB3ZSB3aWxsIApoYXZlIHRvIHVzZSBzb21lIGZvcm0gb2Yg ZGVmZXJyZWQgcHJvYmluZy4KCkhvd2V2ZXIsIGZvciB0aGUgbW9tZW50LCB0aGlzIGlzIHRoZSBi ZXN0IGJhbmQtYWlkIEkgY291bGQgdGhpbmsgb2YsIGFuZCAKY2hvb3NpbmcgYmV0d2VlbiB0aGlz IGJhbmQtYWlkIG9yIG5vIGJhbmQtYWlkIGF0IGFsbCwgSSBwcmVmZXIgdGhlIGZvcm1lciBhbnkg ZGF5LgoKCU9kZWQKCgpPbiAwMS8wNS8yMDE1IDA1OjQ2IFBNLCBUaGllcnJ5IFJlZGluZyB3cm90 ZToKPiBPbiBNb24sIERlYyAyOSwgMjAxNCBhdCAxMDozNDozMkFNICswMTAwLCBDaHJpc3RpYW4g S8O2bmlnIHdyb3RlOgo+PiBBbSAyOS4xMi4yMDE0IHVtIDA5OjE2IHNjaHJpZWIgTGF1cmVudCBQ aW5jaGFydDoKPj4+IEhpIE9kZWQsCj4+Pgo+Pj4gT24gU3VuZGF5IDI4IERlY2VtYmVyIDIwMTQg MTM6MzY6NTAgT2RlZCBHYWJiYXkgd3JvdGU6Cj4+Pj4gT24gMTIvMjYvMjAxNCAxMToxOSBBTSwg TGF1cmVudCBQaW5jaGFydCB3cm90ZToKPj4+Pj4gT24gVGh1cnNkYXkgMjUgRGVjZW1iZXIgMjAx NCAxNDoyMDo1OSBUaGllcnJ5IFJlZGluZyB3cm90ZToKPj4+Pj4+IE9uIE1vbiwgRGVjIDIyLCAy MDE0IGF0IDAxOjA3OjEzUE0gKzAyMDAsIE9kZWQgR2FiYmF5IHdyb3RlOgo+Pj4+Pj4+IFRoaXMg c21hbGwgcGF0Y2gtc2V0LCB3YXMgY3JlYXRlZCB0byBzb2x2ZSB0aGUgYnVnIGRlc2NyaWJlZCBh dAo+Pj4+Pj4+IGh0dHBzOi8vYnVnemlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODk2 NjEgKEtlcm5lbCBwYW5pYyB3aGVuCj4+Pj4+Pj4gdHJ5aW5nIHVzZSBhbWRrZmQgZHJpdmVyIG9u IEthdmVyaSkuIEl0IHJlcGxhY2VzIHRoZSBwcmV2aW91cyBwYXRjaC1zZXQKPj4+Pj4+PiBjYWxs ZWQgW1BBVENIIDAvM10gVXNlIHdvcmtxdWV1ZSBmb3IgZGV2aWNlIGluaXQgaW4gYW1ka2ZkCj4+ Pj4+Pj4gKGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvYXJjaGl2ZXMvZHJpLWRldmVsLzIw MTQtRGVjZW1iZXIvMDc0NDAxLmh0Cj4+Pj4+Pj4gbWwpCj4+Pj4+Pj4KPj4+Pj4+PiBUaGF0IGJ1 ZyBhcHBlYXJzIG9ubHkgd2hlbiByYWRlb24sIGFtZGtmZCBhbmQgYW1kX2lvbW11X3YyIGFyZSBj b21waWxlZAo+Pj4+Pj4+IGluc2lkZSB0aGUga2VybmVsIChub3QgYXMgbW9kdWxlcykuIEluIHRo YXQgY2FzZSwgdGhlIGNvcnJlY3QgbG9hZGluZwo+Pj4+Pj4+IG9yZGVyLCBhcyBkZXRlcm1pbmVk IGJ5IHRoZSBleHBvcnRlZCBzeW1ib2wgdXNlZCBieSBlYWNoIGRyaXZlciwgaXMKPj4+Pj4+PiBu b3QgZW5mb3JjZWQgYW55bW9yZSBhbmQgdGhlIGtlcm5lbCBsb2FkcyB0aGVtIGJhc2VkIG9uIHdo byB3YXMgbGlua2VkCj4+Pj4+Pj4gZmlyc3QuIFRoYXQgbWFrZXMgcmFkZW9uIGxvYWQgZmlyc3Qs IGFtZGtmZCBzZWNvbmQgYW5kIGFtZF9pb21tdV92Mgo+Pj4+Pj4+IHRoaXJkLgo+Pj4+Pj4+Cj4+ Pj4+Pj4gQmVjYXVzZSB0aGUgaW5pdGlhbGl6YXRpb24gb2YgYSBkZXZpY2UgaW4gYW1ka2ZkIGlz IGluaXRpYXRlZCBieSByYWRlb24sCj4+Pj4+Pj4gYW5kIGNhbiBvbmx5IGJlIGNvbXBsZXRlZCBp ZiBhbWRrZmQgYW5kIGFtZF9pb21tdV92MiB3ZXJlIGxvYWRlZCBhbmQKPj4+Pj4+PiBpbml0aWFs aXplZCwgdGhlbiBpbiB0aGUgY2FzZSBtZW50aW9uZWQgYWJvdmUsIHRoaXMgaW5pdGFsaXphdGlv biBmYWlscwo+Pj4+Pj4+IGFuZCB0aGVyZSBpcyBhIGtlcm5lbCBwYW5pYyBhcyBzb21lIHBvaW50 ZXJzIGFyZSBub3QgaW5pdGlhbGl6ZWQgYnV0Cj4+Pj4+Pj4gdXNlZCBub250aGVsZXNzLgo+Pj4+ Pj4+Cj4+Pj4+Pj4gVG8gc29sdmUgdGhpcyBidWcsIHRoaXMgcGF0Y2gtc2V0IG1vdmVzIGlvbW11 LyBiZWZvcmUgZ3B1LyBpbgo+Pj4+Pj4+IGRyaXZlcnMvTWFrZWZpbGUgYW5kIGFsc28gbW92ZXMg YW1ka2ZkLyBiZWZvcmUgcmFkZW9uLyBpbgo+Pj4+Pj4+IGRyaXZlcnMvZ3B1L2RybS9NYWtlZmls ZS4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoZSByYXRpb25hbGUgaXMgdGhhdCBpbiBnZW5lcmFsLCBBTUQg R1BVIGRldmljZXMgYXJlIGRlcGVuZGVudCBvbiBBTUQKPj4+Pj4+PiBJT01NVSBjb250cm9sbGVy IGZ1bmN0aW9uYWxpdHkgdG8gYWxsb3cgdGhlIEdQVSB0byBhY2Nlc3MgYSBwcm9jZXNzJ3MKPj4+ Pj4+PiB2aXJ0dWFsIG1lbW9yeSBhZGRyZXNzIHNwYWNlLCB3aXRob3V0IHRoZSBuZWVkIGZvciBw aW5uaW5nIHRoZSBtZW1vcnkuCj4+Pj4+Pj4gVGhhdCdzIHdoeSBpdCBtYWtlcyBzZW5zZSB0byBp bml0aWFsaXplIHRoZSBpb21tdS8gc3Vic3lzdGVtIGFoZWFkIG9mCj4+Pj4+Pj4gdGhlIGdwdS8g c3Vic3lzdGVtLgo+Pj4+Pj4gSSBzdHJvbmdseSBvYmplY3QgdG8gdGhpcyBwYXRjaCBzZXQuIFRo aXMgbWFrZXMgYXNzdW1wdGlvbnMgYWJvdXQgaG93Cj4+Pj4+PiB0aGUgYnVpbGQgc3lzdGVtIGlu Zmx1ZW5jZXMgcHJvYmUgb3JkZXIuIFRoYXQncyBiYWQgYmVjYXVzZSBzZWVtaW5nbHkKPj4+Pj4+ IHVucmVsYXRlZCBjaGFuZ2VzIGNvdWxkIGVhc2lseSBicmVhayB0aGlzIGluIHRoZSBmdXR1cmUu Cj4+Pj4+Pgo+Pj4+Pj4gV2UgYWxyZWFkeSBoYXZlIHdheXMgdG8gc29sdmUgdGhpcyBraW5kIG9m IGRlcGVuZGVuY3kgKGRyaXZlciBwcm9iZQo+Pj4+Pj4gZGVmZXJyYWwpLCBhbmQgSSB0aGluayB5 b3Ugc2hvdWxkIGJlIHVzaW5nIGl0IHRvIHNvbHZlIHRoaXMgcGFydGljdWxhcgo+Pj4+Pj4gcHJv YmxlbSByYXRoZXIgdGhhbiBzb21lIGxpbmtpbmcgb3JkZXIgaGFjay4KPj4+Pj4gV2hpbGUgSSBh Z3JlZSB3aXRoIHlvdSB0aGF0IHByb2JlIGRlZmVycmFsIGlzIHRoZSB3YXkgdG8gZ28sIEkgYmVs aWV2ZQo+Pj4+PiBsaW5rYWdlIG9yZGVyaW5nIGNhbiBzdGlsbCBiZSB1c2VkIGFzIGFuIG9wdGlt aXphdGlvbiB0byBhdm9pZCBkZWZlcnJpbmcKPj4+Pj4gcHJvYmUgaW4gdGhlIG1vc3QgY29tbW9u IGNhc2VzLiBJJ20gdGh1cyBub3Qgb3Bwb3NlZCB0byBtb3ZpbmcgaW9tbXUvCj4+Pj4+IGVhcmxp ZXIgaW4gbGluayBvcmRlciAocHJvdmlkZWQgd2UgY2FuIHByb3Blcmx5IHRlc3QgZm9yIHNpZGUg ZWZmZWN0cywgYXMKPj4+Pj4gdGhlIGp1bXAgaXMgcHJldHR5IGxhcmdlKSwgYnV0IG5vdCBhcyBh IHJlcGxhY2VtZW50IGZvciBwcm9iZSBkZWZlcnJhbC4KPj4+PiBNeSB0aG91Z2h0cyBleGFjdGx5 LiBJZiB0aGlzIHdhcyBzb21lIGV4dHJlbWUgdXNlIGNhc2UsIHRoYW4gaXQgd291bGQgYmUKPj4+ PiBqdXN0aWZpZWQgdG8gc29sdmUgaXQgd2l0aCBwcm9iZSBkZWZlcnJhbC4gQnV0IEkgdGhpbmsg dGhhdCBmb3IgbW9zdCBjb21tb24KPj4+PiBjYXNlcywgR1BVIGFyZSBkZXBlbmRlbnQgb24gSU9N TVUgYW5kICpub3QqIHZpY2UtdmVyc2EuCj4+Cj4+IEZpeGluZyB0aGlzIHRocm91Z2ggZGVmZXJy ZWQgcHJvYmluZyBzb3VuZHMgbGlrZSB0aGUgY29ycmVjdCBsb25nIHRlcm0KPj4gc29sdXRpb24g dG8gbWUgYXMgd2VsbC4KPj4KPj4gQnV0IHdoYXQgVGhpZXJyeSBpcyByZWZlcnJpbmcgdG8gaGVy ZSBpcyBwcm9iYWJseSB0aGUgYXBwcm9hY2ggb2YgcmV0dXJuaW5nCj4+IC1FQUdBSU4gZnJvbSB0 aGUgcHJvYmUgbWV0aG9kIChhdCBsZWFzdCB0aGF0IHdhcyB0aGUgbGFzdCBzdGF0dXMgd2hlbiBJ Cj4+IGxvb2tlZCBpbnRvIHRoaXMpLgo+Cj4gLUVQUk9CRV9ERUZFUiB3b3VsZCBiZSB0aGUgb25l IHRoYXQgSSB3YXMgcmVmZXJyaW5nIHRvLgo+Cj4+IFRoZSBwcm9ibGVtIHdpdGggdGhpcyBhcHBy b2FjaCBpcyB0aGUgaW50ZXJmYWNlIGRlc2lnbiBiZXR3ZWVuIHJhZGVvbiBhbmQKPj4gYW1ka2Zk LiBhbWRrZmQgc2ltcGx5IGRvZXNuJ3QgaGF2ZSBhIHByb2JlIG1ldGhvZCB3aGljaCBnZXRzIGNh bGxlZCB3aGVuIHRoZQo+PiBoYXJkd2FyZSBpcyBkZXRlY3RlZCBhbmQgY2FuIHJldHVybiAtRUFH QUlOLiBJbnN0ZWFkIGFtZGtmZCBpcyBjYWxsZWQgYnkKPj4gcmFkZW9uIGFmdGVyIGhhcmR3YXJl IGluaXRpYWxpemF0aW9uIHdoZW4gaXQgaXMgd2F5IHRvIGxhdGUgZm9yIHN1Y2ggYQo+PiB0aGlu Zy4KPgo+IFRoYXQgc291bmRzIGxpa2UgYSBwcmV0dHkgYnJpdHRsZSBkZXNpZ24uIEl0IHNvdW5k cyBsaWtlIG5vd2hlcmUgaW4gdGhlCj4gY29kZSB5b3UndmUgZW5jb2RlZCB0aGlzIGRlcGVuZGVu Y3kgYW5kIHlvdSByZWx5IG9uIHN5bWJvbHMgb25seSB0bwo+IGVuc3VyZSBwcm9iZSBvcmRlcmlu Zy4KPgo+IENvdWxkbid0IHlvdSBzaW1wbHkgbWFrZSByYWRlb24gY2hlY2sgZm9yIGF2YWlsYWJp bGl0eSBvZiB0aGUgSU9NTVUKPiBlYXJseSBhbmQgZGVmZXIgcHJvYmluZyBpZiBpdCdzIG5vdCB0 aGVyZSB5ZXQ/IE9yIGlmIHJhZGVvbiBkZXBlbmRzIG9uCj4gdGhlIElPTU1VIHZpYSBhbWRrZmQs IHRoZW4gcGVyaGFwcyBjYWxsaW5nIGludG8gYW1ka2ZkIHRvIGNoZWNrIGZvciB0aGUKPiBhdmFp bGFiaWxpdHkgb2YgdGhlIElPTU1VIHdvdWxkIGJlIGEgbW9yZSBjb3JyZWN0IHJlcHJlc2VudGF0 aW9uIG9mIHRoZQo+IGRlcGVuZGVuY3kuCj4KPj4+PiBCVFcsIG15IGZpcnN0IHRyeSBhdCBzb2x2 aW5nIHRoaXMgd2FzIHRvIHVzZSBwcm9iZSBkZWZlcnJhbCAodXNpbmcKPj4+PiB3b3JrcXVldWUp LCBidXQgdGhlIGZlZWRiYWNrIEkgZ290IGZyb20gQ2hyaXN0aWFuIGFuZCBEYXZlIHdhcyB0aGF0 IG1vdmluZwo+Pj4+IGlvbW11LyBsaW5rYWdlIGJlZm9yZSBncHUvIHdhcyBhIG11Y2ggbW9yZSBz aW1wbGVyIHNvbHV0aW9uLgo+Pj4gVG8gY2xhcmlmeSBteSBwb3NpdGlvbiwgSSBiZWxpZXZlIGNo YW5naW5nIHRoZSBsaW5rIG9yZGVyIGNhbiBiZSBhIHdvcnRod2hpbGUKPj4+IG9wdGltaXphdGlv biwgYnV0IEknbSB1bmNlcnRhaW4gYWJvdXQgdGhlIGxvbmcgdGVybSB2aWFiaWxpdHkgb2YgdGhh dCBjaGFuZ2UKPj4+IGFzIGEgZml4LiBQcm9iZSBkZWZlcnJhbCBoYXMgYmVlbiBpbnRyb2R1Y2Vk IGJlY2F1c2Ugbm90IGFsbCBwcm9iZSBvcmRlcmluZwo+Pj4gaXNzdWVzIGNhbiBiZSBmaXhlZCB0 aHJvdWdoIGxpbmsgb3JkZXJpbmcsIHNvIHdlIHNob3VsZCBmaXggdGhlIHByb2JsZW0KPj4+IHBy b3Blcmx5Lgo+Pj4KPj4+IFRoaXMgYmVpbmcgc2FpZCwgaWYgbW9kaWZ5aW5nIHRoZSBsaW5rIG9y ZGVyIGNhbiBoZWxwIGZvciBub3cgd2l0aG91dAo+Pj4gaW50cm9kdWNpbmcgbmVnYXRpdmUgc2lk ZSBlZmZlY3RzLCBpdCB3b3VsZCBvbmx5IHBvc3Rwb25lIHRoZSByZWFsIGZpeCwgc28gSSdtCj4+ PiBub3Qgb3Bwb3NlZCB0byBpdC4KPj4KPj4gWWVhaCwgdGhhdCBzb3VuZHMgbGlrZSB0aGUgcmln aHQgYXBwcm9hY2ggdG8gbWUgYXMgd2VsbC4KPgo+IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGEgZ29v ZCBhcHByb2FjaCBhdCBhbGwuIEl0IGRvZXNuJ3QgZW5jb2RlIHRoZQo+IGRlcGVuZGVuY3kgYW55 d2hlcmUuIEFsbCB5b3UgaGF2ZSBpcyBzb21lIE1ha2VmaWxlIHRoYXQgbGlzdHMgYSBidW5jaCBv Zgo+IGRpcmVjdG9yaWVzLiBXaGF0IGhhcHBlbnMgaWYgYW55Ym9keSB3YXMgdG8gY2hhbmdlIHRo YXQgb3JkZXIgZm9yIHNvbWUKPiBvdGhlciByZWFzb24/IElmIHlvdSdyZSBub3QgQ2MnZWQgb24g dGhlIHBhdGNoIGFuZCBub2JvZHkgZWxzZSBOQUsncyBpdAo+IGJlY2F1c2UgdGhleSBhcmUgYWNj aWRlbnRhbGx5IGF3YXJlIG9mIHRoZSBkZXBlbmRlbmN5IHRoYXQgcGF0Y2ggaXMKPiBnb2luZyB0 byBicmVhayByYWRlb24uCj4KPj4gSW4gZ2VuZXJhbCBJIHdvdWxkIHByZWZlciB0aGF0IG1vZHVs ZXMgY29tcGlsZWQgaW50byB0aGUga2VybmVsIGxvYWQKPj4gYnkgdGhlIG9yZGVyIG9mIHRoZWly IHN5bWJvbCBkZXBlbmRlbmN5IGp1c3QgbGlrZSBzdGFuZGFsb25lIG1vZHVsZXMKPj4gZG8uCj4K PiBUaGF0IEkgZ2VuZXJhbGx5IGFncmVlIHdpdGguIEJ1dCBpdCBjYW4ndCBiZSBhIHJlcGxhY2Vt ZW50IGZvciBwcm9wZXJseQo+IGRlc2NyaWJpbmcgdGhlIHJ1bnRpbWUgZGVwZW5kZW5jaWVzIGJl dHdlZW4gbW9kdWxlcy4gVGhlcmUgY2FuIGJlIG90aGVyCj4gcmVhc29ucyB0aGFuIGxpbmsgb3Jk ZXIgdGhhdCBpbmZsdWVuY2UgcHJvYmUgb3JkZXJpbmcuIFdoYXQgaWYgdGhlIElPTU1VCj4gZHJp dmVyIGZvciBzb21lIHJlYXNvbiBnYWlucyBkZWZlcnJlZCBwcm9iZSBzdXBwb3J0IGFuZCB0aGVy ZWZvcmUKPiBkb2Vzbid0IHN1Y2NlZWQgb24gdGhlIGZpcnN0IHByb2JlPyBPciBvbmx5IHNvbWV0 aW1lcy4KPgo+IFByb3Blcmx5IGRlc2NyaWJpbmcgdGhlIGRlcGVuZGVuY3kgaXMgdGhlIG9ubHkg d2F5IHRvIHByZXZlbnQgYW55IG9mCj4gdGhhdC4KPgo+IFRoaWVycnkKPgoKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxp c3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0 b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755733AbbAHOQG (ORCPT ); Thu, 8 Jan 2015 09:16:06 -0500 Received: from mail-bn1bon0116.outbound.protection.outlook.com ([157.56.111.116]:60928 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752422AbbAHOQD convert rfc822-to-8bit (ORCPT ); Thu, 8 Jan 2015 09:16:03 -0500 X-WSS-ID: 0NHV3MH-08-1EQ-02 X-M-MSG: Message-ID: <54AE910E.5060803@amd.com> Date: Thu, 8 Jan 2015 16:15:42 +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: Thierry Reding , =?UTF-8?B?Q2hyaXN0aWFuIEvDtg==?= =?UTF-8?B?bmln?= CC: Laurent Pinchart , David Airlie , Greg Kroah-Hartman , "Geert Uytterhoeven" , Dana Elifaz , , , "Alexander Deucher" , , "Arnd Bergmann" , Will Deacon Subject: Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd References: <1419246435-7050-1-git-send-email-oded.gabbay@amd.com> <1621810.aTt9O4Ghzs@avalon> <549FEB52.4020103@amd.com> <1678486.9ZXZnn5och@avalon> <54A12028.7020303@amd.com> <20150105154657.GJ12010@ulmo.nvidia.com> In-Reply-To: <20150105154657.GJ12010@ulmo.nvidia.com> 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)(189002)(51444003)(51704005)(479174004)(377454003)(199003)(24454002)(92566001)(101416001)(33656002)(4396001)(106466001)(59896002)(76176999)(23676002)(105586002)(93886004)(87266999)(50986999)(65816999)(54356999)(99396003)(84676001)(21056001)(87936001)(107046002)(36756003)(120916001)(83506001)(80316001)(19580395003)(68736005)(77096005)(64706001)(47776003)(20776003)(65806001)(97736003)(50466002)(62966003)(65956001)(64126003)(86362001)(77156002)(2950100001)(31966008)(46102003)(15975445007)(129583001);DIR:OUT;SFP:1102;SCL:1;SRVR:CO1PR02MB208;H:atltwp02.amd.com;FPR:;SPF:None;MLV:sfv;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR02MB208; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:CO1PR02MB208; X-Forefront-PRVS: 0450A714CB X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB208; X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2015 14:15:57.8828 (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: CO1PR02MB208 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thierry, Generally I agree with the issues you describe in the current design. One task in our 2015 workplan is to change the whole method amdkfd is loaded, so it can independently load at any time, regardless of the order of loading between it and radeon and amd_iommu_v2. To reach that goal, I assume we will have to use some form of deferred probing. However, for the moment, this is the best band-aid I could think of, and choosing between this band-aid or no band-aid at all, I prefer the former any day. Oded On 01/05/2015 05:46 PM, Thierry Reding wrote: > On Mon, Dec 29, 2014 at 10:34:32AM +0100, Christian König wrote: >> Am 29.12.2014 um 09:16 schrieb Laurent Pinchart: >>> Hi Oded, >>> >>> On Sunday 28 December 2014 13:36:50 Oded Gabbay wrote: >>>> On 12/26/2014 11:19 AM, Laurent Pinchart wrote: >>>>> On Thursday 25 December 2014 14:20:59 Thierry Reding wrote: >>>>>> On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote: >>>>>>> This small patch-set, was created to solve the bug described at >>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when >>>>>>> trying use amdkfd driver on Kaveri). It replaces the previous patch-set >>>>>>> called [PATCH 0/3] Use workqueue for device init in amdkfd >>>>>>> (http://lists.freedesktop.org/archives/dri-devel/2014-December/074401.ht >>>>>>> ml) >>>>>>> >>>>>>> That bug appears only when radeon, amdkfd and amd_iommu_v2 are compiled >>>>>>> inside the kernel (not as modules). In that case, the correct loading >>>>>>> order, as determined by the exported symbol used by each driver, is >>>>>>> not enforced anymore and the kernel loads them based on who was linked >>>>>>> first. That makes radeon load first, amdkfd second and amd_iommu_v2 >>>>>>> third. >>>>>>> >>>>>>> Because the initialization of a device in amdkfd is initiated by radeon, >>>>>>> and can only be completed if amdkfd and amd_iommu_v2 were loaded and >>>>>>> initialized, then in the case mentioned above, this initalization fails >>>>>>> and there is a kernel panic as some pointers are not initialized but >>>>>>> used nontheless. >>>>>>> >>>>>>> To solve this bug, this patch-set moves iommu/ before gpu/ in >>>>>>> drivers/Makefile and also moves amdkfd/ before radeon/ in >>>>>>> drivers/gpu/drm/Makefile. >>>>>>> >>>>>>> The rationale is that in general, AMD GPU devices are dependent on AMD >>>>>>> IOMMU controller functionality to allow the GPU to access a process's >>>>>>> virtual memory address space, without the need for pinning the memory. >>>>>>> That's why it makes sense to initialize the iommu/ subsystem ahead of >>>>>>> the gpu/ subsystem. >>>>>> I strongly object to this patch set. This makes assumptions about how >>>>>> the build system influences probe order. That's bad because seemingly >>>>>> unrelated changes could easily break this in the future. >>>>>> >>>>>> We already have ways to solve this kind of dependency (driver probe >>>>>> deferral), and I think you should be using it to solve this particular >>>>>> problem rather than some linking order hack. >>>>> While I agree with you that probe deferral is the way to go, I believe >>>>> linkage ordering can still be used as an optimization to avoid deferring >>>>> probe in the most common cases. I'm thus not opposed to moving iommu/ >>>>> earlier in link order (provided we can properly test for side effects, as >>>>> the jump is pretty large), but not as a replacement for probe deferral. >>>> My thoughts exactly. If this was some extreme use case, than it would be >>>> justified to solve it with probe deferral. But I think that for most common >>>> cases, GPU are dependent on IOMMU and *not* vice-versa. >> >> Fixing this through deferred probing sounds like the correct long term >> solution to me as well. >> >> But what Thierry is referring to here is probably the approach of returning >> -EAGAIN from the probe method (at least that was the last status when I >> looked into this). > > -EPROBE_DEFER would be the one that I was referring to. > >> The problem with this approach is the interface design between radeon and >> amdkfd. amdkfd simply doesn't have a probe method which gets called when the >> hardware is detected and can return -EAGAIN. Instead amdkfd is called by >> radeon after hardware initialization when it is way to late for such a >> thing. > > That sounds like a pretty brittle design. It sounds like nowhere in the > code you've encoded this dependency and you rely on symbols only to > ensure probe ordering. > > Couldn't you simply make radeon check for availability of the IOMMU > early and defer probing if it's not there yet? Or if radeon depends on > the IOMMU via amdkfd, then perhaps calling into amdkfd to check for the > availability of the IOMMU would be a more correct representation of the > dependency. > >>>> BTW, my first try at solving this was to use probe deferral (using >>>> workqueue), but the feedback I got from Christian and Dave was that moving >>>> iommu/ linkage before gpu/ was a much more simpler solution. >>> To clarify my position, I believe changing the link order can be a worthwhile >>> optimization, but I'm uncertain about the long term viability of that change >>> as a fix. Probe deferral has been introduced because not all probe ordering >>> issues can be fixed through link ordering, so we should fix the problem >>> properly. >>> >>> This being said, if modifying the link order can help for now without >>> introducing negative side effects, it would only postpone the real fix, so I'm >>> not opposed to it. >> >> Yeah, that sounds like the right approach to me as well. > > I don't think that's a good approach at all. It doesn't encode the > dependency anywhere. All you have is some Makefile that lists a bunch of > directories. What happens if anybody was to change that order for some > other reason? If you're not Cc'ed on the patch and nobody else NAK's it > because they are accidentally aware of the dependency that patch is > going to break radeon. > >> In general I would prefer that modules compiled into the kernel load >> by the order of their symbol dependency just like standalone modules >> do. > > That I generally agree with. But it can't be a replacement for properly > describing the runtime dependencies between modules. There can be other > reasons than link order that influence probe ordering. What if the IOMMU > driver for some reason gains deferred probe support and therefore > doesn't succeed on the first probe? Or only sometimes. > > Properly describing the dependency is the only way to prevent any of > that. > > Thierry >