From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25755C433ED for ; Wed, 21 Apr 2021 10:23:43 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7BD4661449 for ; Wed, 21 Apr 2021 10:23:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BD4661449 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6N0OnOr0zEuu/eWZK4ov7+v5UfPC8WiZUsktaLB8LXo=; b=mb8p0YADn/DJae1C5SpdD06aD IBFTSf/hHTECX20VLS5gJguAZ2k3PWndbQ98U9IhTJ50eG7MPdELBY1tnwwT/Uwq+YBPXEvu8vyAJ Qay54xvJcBh+vm/5uQs/91pUQ+H86J6CcYgz6xrm8Jhcv4sGpRBbS5cn5SfKs8sFM06IXB7tQBR+O oFLiEmJoZzmpTFrlq/wHqIq7lM//jJkBt319bgVibt/gu2vffVoNUudnNXqmGYrH2vZ0j0EJFOcgI 8X6XeiiRWPTpG5qqOyjf/2Aw+2HB8uqGNiclOAI81nIApaSzOwXtvPh0AyGSxvrv2JKYlfEKsZn3E hRO7tBzXQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZA1A-00EDdD-Rc; Wed, 21 Apr 2021 10:23:37 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZA18-00EDd2-Ra for linux-rockchip@desiato.infradead.org; Wed, 21 Apr 2021 10:23:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Sender:Reply-To:Content-ID:Content-Description; bh=Uf1OSNVynd2vMw1Yu/aIOQFf9HhftXqWtnJao9F4d2g=; b=RoES9ipIekVgshKc/IpepTCsYA SmyQERpvyrJsKhxX35DWv4C9GGrF1Ip+ZCiJC3uZYFQaF2e2XoDQV9W48YNZf7TKU9DI8inbt2uSX Llgy470aG/fADz5w1NVkMkxtRh5T6qk0xlUgugWunnTArfzzP6MRgvTmsWhIfaNuAkhai1r0x1ADP bGc9QASkYGgSLTOOunw0jl2RlW89t2soDUcyIBVi2cqc1OSriFKGXcQS5yDdW9fRKMwB1VWB03EIY OumbGS63Z0tOxDtwZkmUkYT6/eoqTHumO5DNoSniWAJeMpQuZThdIe8tlg4ULi3I/R6zrUa8ehzQB 9ynfPvzA==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZA15-00Cnwh-N5 for linux-rockchip@lists.infradead.org; Wed, 21 Apr 2021 10:23:33 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 52E4B61445; Wed, 21 Apr 2021 10:23:30 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lZA12-008f1C-1U; Wed, 21 Apr 2021 11:23:28 +0100 Date: Wed, 21 Apr 2021 11:23:27 +0100 Message-ID: <874kg0q6lc.wl-maz@kernel.org> From: Marc Zyngier To: Kever Yang Cc: Peter Geis , Thomas Gleixner , "open list:ARM/Rockchip SoC..." , Linux Kernel Mailing List , Heiko =?UTF-8?B?U3Q=?= =?UTF-8?B?w7xibmVy?= Subject: Re: [RFC] ITS fails to allocate on rk3568/rk3566 In-Reply-To: <2791594e-db60-e1d0-88e5-7e5bbd98ae4d@rock-chips.com> References: <871rbeo7wf.wl-maz@kernel.org> <87y2dmmggt.wl-maz@kernel.org> <87tuoambdb.wl-maz@kernel.org> <871rbdt4tu.wl-maz@kernel.org> <678e9950-dd85-abb2-a104-07a4db1fad49@rock-chips.com> <87k0p4m0gm.wl-maz@kernel.org> <8d2e22f5-1c1b-e795-8757-ae078446d961@rock-chips.com> <878s5i2qyw.wl-maz@kernel.org> <2791594e-db60-e1d0-88e5-7e5bbd98ae4d@rock-chips.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: kever.yang@rock-chips.com, pgwipeout@gmail.com, tglx@linutronix.de, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, heiko@sntech.de X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210421_032331_845189_59DD3767 X-CRM114-Status: GOOD ( 80.10 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org T24gV2VkLCAyMSBBcHIgMjAyMSAwMjo0MDoyNiArMDEwMCwKS2V2ZXIgWWFuZyA8a2V2ZXIueWFu Z0Byb2NrLWNoaXBzLmNvbT4gd3JvdGU6Cj4gCj4gSGkgTWFyYywKPiAKPiBPbiAyMDIxLzQvMTYg 5LiL5Y2IMTE6MjMsIE1hcmMgWnluZ2llciB3cm90ZToKPiA+IE9uIEZyaSwgMTYgQXByIDIwMjEg MDI6MTM6MzggKzAxMDAsCj4gPiBLZXZlciBZYW5nIDxrZXZlci55YW5nQHJvY2stY2hpcHMuY29t PiB3cm90ZToKPiA+PiBIaSBNYXJjLAo+ID4+IAo+ID4+IE9uIDIwMjEvNC8xNSDkuIvljYg0OjEx LCBNYXJjIFp5bmdpZXIgd3JvdGU6Cj4gPj4+IEhpIEtldmVyLAo+ID4+PiAKPiA+Pj4gT24gVGh1 LCAxNSBBcHIgMjAyMSAwODoyNDozMyArMDEwMCwKPiA+Pj4gS2V2ZXIgWWFuZyA8a2V2ZXIueWFu Z0Byb2NrLWNoaXBzLmNvbT4gd3JvdGU6Cj4gPj4+PiBIaSBNYXJjLCBQZXRlciwKPiA+Pj4+IAo+ ID4+Pj4gICDCoMKgwqAgUkszNTZ4IEdJQyBoYXMgdHdvIGlzc3VlczoKPiA+Pj4+IAo+ID4+Pj4g MS4gR0lDIG9ubHkgc3VwcG9ydCAzMmJpdCBhZGRyZXNzIHdoaWxlIHJrMzU2eCBzdXBwb3J0cyA4 R0IgRERSIFNEUkFNLAo+ID4+Pj4gc28gd2UgdXNlIFpPTkVfRE1BMzIgdG8gZml4IHRoaXMgaXNz dWU7Cj4gPj4+IFdoYXQgdHJhbnNhY3Rpb25zIGRvZXMgdGhpcyBhZmZlY3QgZXhhY3RseT8KPiA+ PiBUaGUgR0lDIG9uIHJrMzU2eCBpcyBhIDMyYml0IG1hc3Rlciwgd2hpY2ggbWVhbnMgYWxsIHRo ZSBzcGFjZSBpdHMKPiA+PiBsb2dpYyBuZWVkIHRvIGFjY2VzcyBzaG91bGQgYmUgaW4gdGhlIDRH QiByYW5nZS4KPiA+IFdlbGwsIGF0IGxlYXN0IHRoaXMgaXMgY29uc2lzdGVudGx5IGJyb2tlbi4K PiAKPiBUaGVyZSBhcmUgbWFueSBsZWdhY3kgSVBzIHdoaWNoIG9ubHkgc3VwcG9ydCAzMmJpdCBi dXMsIHdlIGhhdmUgdG8KPiB1c2UgdGhlbSBhcyBpcyBpbiB0aGUgbmV3IDY0Yml0IFNvQ3MsIEkg dGhpbmsgdGhlIDMyYml0IEdJQyBjYW4gYmUKPiBjb25zaWRlcmVkIHRoZSBzYW1lIGFzIHRob3Nl IGNhc2UsIGNhbiB3ZSBhZGQgQ09ORklHX1pPTkVfRE1BMzIKPiBzdXBwb3J0IGluIEdJQyBkcml2 ZXI/CgpPbmx5IGFzIGFuIGVycmF0dW0gd29ya2Fyb3VuZC4gVGhlIEdJQyBpc24ndCBzb21lIHJh bmRvbSBkZXZpY2UgdGhhdApjYW4gbGl2ZSBiZWhpbmQgYW4gSU9NTVUgdGhhdCB3aWxsIHNvcnQg dGhlIG1hcHBpbmcgcHJvYmxlbSBmb3IKeW91LiBCeSBkZXNpZ24sIGl0IG11c3QgYmUgdW50cmFu c2xhdGVkLCBzbyBsaW1pdGluZyBpdCB0byBvbmx5IGEKcG9ydGlvbiBvZiB0aGUgcGh5c2ljYWwg YWRkcmVzcyBzcGFjZSBpcyBhIGJ1ZywgZnVsbCBzdG9wLgoKPiBlZy4gT3RoZXIgcGVyaXBoZXJh bCBkcml2ZXIgdXNlIGRtYV9hbGxvY19jb2hlcmVudCgpIGluc3RlYWQgb2YKPiBhbGxvY19wYWdl cygpLCBzbyB0aGVuIGNhbiBzdXBwb3J0IFpPTkVfRE1BMzIgd2l0aG91dCBhbnkgY29kZQo+IGNo YW5nZS4KCllvdSBkbyByZWFsaXNlIHRoYXQgZG1hX2FsbG9jX2NvaGVyZW50KCkgcmVxdWlyZXMg dGhlIHVzZSBvZiBhIHN0cnVjdApkZXZpY2UsIGFuZCB0aGF0IHRoZSBHSUMgaXMgcmVxdWlyZWQg dG8gYmUgdXAgYW5kIHJ1bm5pbmcgbG9uZyBiZWZvcmUKdGhlIGRldmljZSBtb2RlbCBpcyBhdmFp bGFibGUsIHJpZ2h0PwoKPiA+Pj4gT25seSBzb21lIElUUyB0YWJsZXM/IE9yCj4gPj4+IGFsbCBv ZiB0aGVtLCBpbmNsdWRpbmcgdGhlIGNvbW1hbmQgcXVldWU/IFdoYXQgYWJvdXQgdGhlIGNvbmZp Z3VyYXRpb24KPiA+Pj4gYW5kIHBlbmRpbmcgdGFibGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVk aXN0cmlidXRvcnM/Cj4gPj4+IAo+ID4+Pj4gMi4gR0lDIHZlcnNpb24gaXMgcjFwNi0wMHJlbDAs IFJLMzU2eCBpbnRlcmNvbm5lY3QgZG9lcyBub3Qgc3VwcG9ydAo+ID4+Pj4gR0lDIGFuZCBDUFUg c25vb3AgdG8gZWFjaCBvdGhlciwgaGVuY2UgdGhlIEdJQyBkb2VzIG5vdCBzdXBwb3J0IHRoZQo+ ID4+Pj4gc2hhcmVhYmlsaXR5IGZlYXR1cmUuwqAgVGhlIHJlYWQgb2YgcmVnaXN0ZXIgdmFsdWUg Zm9yIHNoYXJlYWJpbGl0eQo+ID4+Pj4gZmVhdHVyZSBkb2VzIG5vdCByZXR1cm4gYXMgZXhwZWN0 IGluIEdJQ1IgYW5kIEdJVFMsIHNvIHdlIGhhdmUgdG8KPiA+Pj4+IHdvcmthcm91bmQgZm9yIGl0 Lgo+ID4+PiBIb3cgYWJvdXQgdGhlIGNhY2hlYWJpbGl0eSBhdHRyaWJ1dGU/IENhbiB5b3UgcGxl YXNlIHByb3ZpZGUgdGhlIGV4YWN0Cj4gPj4+IHNldCBvZiBhdHRyaWJ1dGVzIHRoYXQgdGhpcyBz eXN0ZW0gYWN0dWFsbHkgc3VwcG9ydHMgZm9yIGVhY2ggb2YgdGhlCj4gPj4+IElUUyBhbmQgcmVk aXN0cmlidXRvciBiYXNlIHJlZ2lzdGVycz8KPiA+PiBUaGUgc2hhcmVhYmlsaXR5IGF0dHJpYnV0 ZXMgaW4gR0lDUl9QRU5EQkFTRUVSLCBHSUNSX1BST1BCQVNFUiwKPiA+PiBHSVRTX0JBU0VSbiwg R0lUU19DQkFTRVIgZGVmYXVsdCB2YWx1ZSBpcyAwYjAwLCB3aGVuIHdlIHNldCAwYjAxIHRoZW4K PiA+PiByZWFkIHJldHVybnMgMGIwMS4KPiA+IEFuZCBJIGNsYWltIHRoYXQgdGhpcyBpcyBhIHBl cmZlY3RseSBicm9rZW4gYmVoYXZpb3VyLiBIb3cgZG8geW91Cj4gPiBleHBlY3Qgc29mdHdhcmUg dG8gZmluZCBhYm91dCB0aGUgZ29yeSBkZXRhaWxzIG9mIHRoZSBpbnRlZ3JhdGlvbj8KPiA+IFRo YXQncyB0aGUgb25seSB3YXkgZm9yIFNXIHRvIGZpbmQgb3V0IHdoYXQgdGhlIEhXIGlzIGNhcGFi bGUgb2YuLi4KPiAKPiBBcyBhIHNvZnR3YXJlIGVuZ2luZWVyLCBJIHRvdGFsbHkgYWdyZWUgd2l0 aCB5b3Ugb24gdGhpcyBwb2ludCwgYnV0Cj4gd2hlbiB3ZSBiYWNrIHRvIHRoZSB0cnV0aCwgd2Ug c2hvdWxkIGtub3cgdGhhdCB0aGVzZSByZWdpc3RlcnMgaGFzCj4gbmV2ZXIgYmVlbiBkZWZpbmVk IGFzICJtb2R1bGUgY2FwYWJpbGl0eSBmb3Igc2hhcmVhYmlsaXR5IgoKU2F5cyB3aG8/IElmIFNX IGNhbm5vdCBkaXNjb3ZlciB0aGUgY2FwYWJpbGl0eSBvZiB0aGUgSFcsIHRoZW4gbm90aGluZwp3 b3Jrcy4KCj4gaW4gaGFyZHdhcmUuIFRoZSBzb2Z0d2FyZSB1c2UgaXQgYXMgY2FwYWJpbGl0eSBk ZXRlY3QsIGFuZCBpdCB3b3Jrcwo+IGJlZm9yZSwgYnV0IG5vdCBtZWFucyBtYXRjaCB0aGUgb3Jp Z2luYWwgaGFyZHdhcmUgZGVzaWduLCBpbiB0aGlzCj4gY2FzZSB0aGUgbmV3IGhhcmR3YXJlIG1h eSBub3QgZm9sbG93IHRoZSBkZXNpZ24gYmVjYXVzZSBpdCdzIG5vdCBhCj4gc3RhbmRhcmQgb3Ig YSBjbGVhciBlbm91Z2ggZ3VpZGUgZm9yIGl0LgoKVGhlIHNwZWMgaGFzIGJlZW4gY2xlYXIgZW5v dWdoIGZvciAqZXZlcnlvbmUqIHNvIGZhciwgYW5kIG90aGVyIEdJQzYwMAppbXBsZW1lbnRhdGlv bnMgZ290IGl0IHBlcmZlY3RseSByaWdodC4gVGhlcmUgaGFzIGJlZW4gKm9uZSoKZXhjZXB0aW9u LCB3aGljaCBpcyBkb2N1bWVudGVkIGFuZCBoYW5kbGVkIGFzIGEgcXVpcmsuCgo+IFRoZSBjYXBh YmlsaXR5IHJlZ2lzdGVyIHNob3VsZCBhbHdheXMgcmVhZC1vbmx5IGluc3RlYWQgb2YKPiByZWFk LXdyaXRlLCB0aGUgdW5kZXJzdGFuZGluZyBzb2Z0d2FyZSBlbmdpbmVlciBhbmQgZnJvbSBoYXJk d2FyZQo+IGVuZ2luZWVyIGFsd2F5cyBoYXZlIGEgZ2FwLgo+IAo+IEkgd291bGQgcHJvcG9zYWwg dG8gYWRkIGEgb3B0aW9uYWwgZHRzIHByb3BlcnR5IGZvciBkcml2ZXIgdG8KPiBpZGVudGlmeSBp ZiB0aGUgYm9hcmQncyBHSUMgc2hhcmVhYmlsaXR5IG9yIG5vdCwgd2hpY2ggaXMgYSBtZXRob2QK PiB1c2VkIGJ5IG1hbnkgb3RoZXIgbW9kdWxlIGRyaXZlcnMuCgpBcmUgeW91IGFsc28gZ29pbmcg dG8gcHJvcG9zZSBhbmQgc3VwcG9ydCBhbiBBQ1BJIHNwZWNpZmljYXRpb24gdXBkYXRlCnRvIGNv cGUgd2l0aCBzaW1pbGFybHkgYnJva2VuIGRldmljZXM/IEVpdGhlciB0aGlzIGlzIHNvbWV0aGlu ZyB0aGF0CmlzIGF2YWlsYWJsZSBhY3Jvc3MgdGhlIHZhcmlvdXMgZmlybXdhcmUgaW1wbGVtZW50 YXRpb25zLCBvciBpdApkb2Vzbid0IGV4aXN0LgoKPgo+ID4+IFNpbmNlIHRoZXJlIGlzIG5vIEFD RSBjb2hlcmVuY3kgaW50ZXJmYWNlIGZvciB0aGlzIEdJQyBjb250cm9sbGVyLCBhbGwKPiA+PiB0 aGUgY2FjaGVhYmlsaXR5IGluIHRoZSBHSUMgaXMgbm90IHN1cHBvcnQgaW4gaGFyZHdhcmUuCj4g Pj4gCj4gPj4+IEFsc28sIHBsZWFzZSBwcm92aWRlIGVycmF0YSBudW1iZXJzIGZvciB0aGVzZSB0 d28gaXNzdWVzIHNvIHRoYXQgd2UKPiA+Pj4gY2FuIHByb3Blcmx5IGRvY3VtZW50IHRoZW0gYW5k IHRyYWNrIHRoZSB3b3JrYXJvdW5kcy4KPiA+PiBXaGF0IGtpbmQgb2YgZXJyYXRhIGRvIHlvdSBu ZWVkLCBjb3VsZCB5b3UgcGxlYXNlIHNoYXJlIGFueSBraW5kIG9mCj4gPj4gZXhhbXBsZSBjbG9z ZSB0byB0aGlzIGNhc2U/Cj4gPiBJIHdvdWxkIGxpa2Ugc29tZXRoaW5nIHRoYXQgc2F5czoKPiA+ IAo+ID4gIlJPQ0tDSElQX0VSUkFUVU1fMTIzNDU2OiBUaGUgR0lDNjAwIGludGVncmF0aW9uIGlu IFJLMzU2eCBkb2Vzbid0Cj4gPiAgIHN1cHBvcnQgYW55IG9mIHRoZSBzaGFyZWFiaWxpdHkgb3Ig Y2FjaGVhYmlsaXR5IGF0dHJpYnV0ZXMsIGFuZAo+ID4gICByZXF1aXJlcyBib3RoIHZhbHVlcyB0 byBiZSBzZXQgdG8gMGIwMCBmb3IgYWxsIHRoZSBJVFMgYW5kCj4gPiAgIFJlZGlzdHJpYnV0b3Ig dGFibGVzLiIKPiA+IAo+ID4gVGhpcyBpcyBwcmV0dHkgc2ltaWxhciB0byB0aGUgYnVnIGFmZmVj dGluZyBUaHVuZGVyWCB3aXRoIGl0cyAiZXJyYXR1bQo+ID4gMjQzMTMiIChjb3ZlcmVkIGJ5IENP TkZJR19DQVZJVU1fRVJSQVRVTV8yMjM3NSksIHdoZXJlIHRoZSB0YWJsZXMgaGF2ZQo+ID4gdG8g YmUgZmxhZ2dlZCBhcyBub24tY2FjaGVhYmxlLiBUaGUgUm9ja2NoaXAgb25lIGlzIGp1c3Qgd29y c2UuCj4gPiAKPiA+IFdlIG5lZWQgYW4gb2ZmaWNpYWwgZXJyYXR1bSBudW1iZXIgc28gdGhhdCB3 ZSBjYW4gcmVmZXIgdG8gaXQgaW4gdGhlCj4gPiBzb3VyY2UsIGNvbW1pdCBsb2cgYW5kIGRvY3Vt ZW50YXRpb24sIGFzIHdlbGwgYXMgY3Jvc3MtcmVmZXJlbmNlIGl0Cj4gPiB3aXRoIHRoZSBUUk0u IFRoaXMgbnVtYmVyIHdpbGwgYmUgcGFydCBvZiBhIGNvbmZpZ3VyYXRpb24gc3ltYm9sIHRoYXQK PiA+IHdpbGwgbWFrZSB0aGUgY29tcGlsYXRpb24gY29uZGl0aW9uYWwgc28gdGhhdCBwZW9wbGUg ZG9uJ3QgaGF2ZSB0bwo+ID4gY2FycnkgdGhlIGV4dHJhIGJ1cmRlbiBnZW5lcmF0ZWQgYnkgdGhp cyBidWcgaWYgdGhleSBkb24ndCBuZWVkIHRvLgo+ID4gCj4gPiBTYW1lIHRoaW5nIGdvZXMgZm9y IHRoZSAzMmJpdCBidWcuCj4gPiAKPiA+PiBXZSBjb25zaWRlciB0aGlzIGFzIGEgU29DIGltcGxl bWVudCBkZXNpZ24gaW5zdGVhZCBvZiBhIGJ1Zywgc28gd2UKPiA+PiB3aWxsIGFkZCBkb2N1bWVu dCBpbiBSSzM1NljCoCBUUk0gdG8gZGVzY3JpYmUgdGhlIEdJQyBkZXNpZ24sIGJ1dCBubwo+ID4+ IGlkZWEgaG93IHRvIHByb3ZpZGUgdGhlIGVycmF0YS4KPiA+PiAKPiA+PiBIZXJlIGlzIHRoZSBz aGFyZWFiaWx5IGF0dHJpYnV0ZSBmcm9tIEFSTSBHSUMgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYXRp b246Cj4gPj4gU2hhcmVhYmlsaXR5LCBiaXRzIFsxMToxMF0gKGZyb20gR0lUU19DQkFTRVIpCj4g Pj4gSW5kaWNhdGVzIHRoZSBTaGFyZWFiaWxpdHkgYXR0cmlidXRlcyBvZiBhY2Nlc3NlcyB0byB0 aGUgY29tbWFuZAo+ID4+IHF1ZXVlLiBUaGUgcG9zc2libGUgdmFsdWVzIG9mIHRoaXMgZmllbGQg YXJlOgo+ID4+IDBiMDAgTm9uLXNoYXJlYWJsZS4KPiA+PiAwYjAxIElubmVyIFNoYXJlYWJsZS4K PiA+PiAwYjEwIE91dGVyIFNoYXJlYWJsZS4KPiA+PiAwYjExIFJlc2VydmVkLiBUcmVhdGVkIGFz IDBiMDAuCj4gPj4gSXQgaXMgSU1QTEVNRU5UQVRJT04gREVGSU5FRCB3aGV0aGVyIHRoaXMgZmll bGQgaGFzIGEgZml4ZWQgdmFsdWUgb3IKPiA+PiBjYW4gYmUgcHJvZ3JhbW1lZCBieSBzb2Z0d2Fy ZS4gSW1wbGVtZW50aW5nIHRoaXMgZmllbGQgd2l0aCBhIGZpeGVkCj4gPj4gdmFsdWUgaXMgZGVw cmVjYXRlZC4KPiA+PiBPbiBhIFdhcm0gcmVzZXQsIHRoaXMgZmllbGQgcmVzZXRzIHRvIGFuIGFy Y2hpdGVjdHVyYWxseSBVTktOT1dOIHZhbHVlCj4gPj4gCj4gPj4gQXMgeW91IGNhbiBzZWUsICJJ bXBsZW1lbnRpbmcgdGhpcyBmaWVsZCB3aXRoIGEgZml4ZWQgdmFsdWUgaXMKPiA+PiBkZXByZWNh dGVkIiwgc28gc29mdHdhcmUgc2hvdWxkIHByb2dyYW0gdGhpcyBmaWVsZCB0byAnMGIwMAo+ID4+ IE5vbi1zaGFyZWFibGUnIGlmIHRoZSBTb0MgZGVzaWduIGRvZXMgbm90IHN1cHBvcnQgdGhlIGNh Y2hlCj4gPj4gc2hhcmVhYmlsaXR5Lgo+ID4gW0kgcmVhbGx5IGZlZWwgc3BlY2lhbCB3aGVuIHBl b3BsZSBxdW90ZSB0aGUgR0lDIHNwZWMgYXQgbWVdCj4gPiAKPiA+IFRoYXQgaXNuJ3Qgd2hhdCBp dCBzYXlzLiBIYXJkY29kaW5nIHRoZSBmaWVsZCB3aXRoIGEgZml4ZWQgdmFsdWUgaXMKPiA+IGlu ZGVlZCBkZXByZWNhdGVkLCBidXQgdGhhdCBkb2Vzbid0IG1lYW4gdGhpcyBmaWVsZCBzaG91bGQg YWNjZXB0Cj4gPiB2YWx1ZXMgdGhhdCB0aGUgSFcgY2Fubm90IHN1cHBvcnQuIElmIGFueXRoaW5n LCB3aGF0IHRoaXMgc2F5cyBpcyAidHJ5Cj4gPiBhbmQgaW1wbGVtZW50IHRoZSBvcHRpb25zIHRo YXQgU1cgaXMgZ29pbmcgdG8gdXNlIi4KPiA+IAo+ID4gQnV0IHlvdSBuZWVkIHRvIGdpdmUgU1cg YW4gaW5kaWNhdGlvbiBvZiB3aGF0IGlzIHVzYWJsZSwgYmVjYXVzZSB0aGVyZQo+ID4gaXMgbm8g b3RoZXIgd2F5IHRvICpkaXNjb3Zlciogd2hhdCB0aGUgU29DIGlzIGNhcGFibGUgb2YgYXQgcnVu dGltZS4KPiA+IE90aGVyd2lzZSwgd2Ugd291bGQgbmVlZCB0byBjYXJyeSBhIHBlci1Tb0MgbGlz dCBvZiB3aGF0IHRoZSBIVwo+ID4gc3VwcG9ydHMuIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHRoZSBy aWdodCB0aGluZyB0byBkbyAoYW5kIHlvdSdyZSBhYm91dAo+ID4gOCB5ZWFycyB0b28gbGF0ZSBh bnl3YXkpLgo+ID4gCj4gPiBPdGhlciBHSUM2MDAgaW50ZWdyYXRpb25zIGdvdCBpdCBwZXJmZWN0 bHkgcmlnaHQsIGJ5IHRoZSB3YXkuIFNhbWUgZm9yCj4gPiBvdGhlciBHSUMgaW1wbGVtZW50YXRp b25zLCB3aXRoIHRoZSBub3RhYmxlIGV4Y2VwdGlvbiBvZiBDYXZpdW0gYW5kCj4gPiB0aGVpciBm aXJzdCBHSUMgaW4gVGh1bmRlclgsIGFzIGRlc2NyaWJlZCBhYm92ZS4KPiAKPiBJJ20gbm90IHN1 cmUgaWYgeW91IHN0aWxsIHdvcmsgZm9yIEFSTSBvciBub3QsIGJ1dCB3ZSBkbyBoYXZlIGRvdWJs ZQoKSSBkb24ndCB0aGluayB3aG9ldmVyIHBheXMgbXkgc2FsYXJ5IGlzIHJlbGV2YW50IGluIHRo aXMgY29udGV4dC4gSSBhbQp3cml0aW5nIGFzIHRoZSBndXkgd2hvIG1haW50YWlucyB0aGUgR0lD IGFyY2hpdGVjdHVyZSBpbiBMaW51eCwgYW5kCnRoZSBmYWN0IHRoYXQgSSBoYXZlIHdvcmtlZCwg d29yaywgb3Igd2lsbCB3b3JrIGZvciBBUk0gb3Igbm90IGhhcyBubwpiZWFyaW5nIG9uIHdoYXQg SSBhbSBzYXlpbmcgaGVyZS4KCj4gY2hlY2sgYWdhaW4gYW5kIGFnYWluIHdpdGggSVAgdmVuZG9y IGFib3V0IHRoaXMgcG9pbnQsIHRoZSBHSUM1MDAKPiB3b3JrcyBiZWNhdXNlIGl0J3MgaGFyZHdh cmUgYmluZCB0byBhIGZpeCB2YWx1ZSBpbnNpZGUgdGhlIElQLCBidXQKPiBHSUM2MDAgZG9lcyBu b3QgZG8gdGhlIHNhbWUgYmluZGluZywgYW5kIHRoZXJlIGlzIG5vIGFueSBjb25maWcKPiBvcHRp b24gdG8gaGFyZGNvZGUgdGhlIHJlZyBmaWVsZCB0byBhIGZpeGVkIHZhbHVlIGluIHRoZSBJUCB3 aGVuCj4gd2UgZG9uJ3QgbmVlZCB0aGUgQUNFLWxpdGUuCj4gCj4gVGhpcyBpcyB3aHkgSSBpbnNp c3QgdGhhdCB0aGlzIGlzIGEgZGlmZmVyZW50IFNvQyBpbXBsZW1lbnRhdGlvbgo+IGluc3RlYWQg b2YgYSBTb0MgYnVnLCB3ZSBzaG91bGQgYWRkIHRoZSBzdXBwb3J0IGluIHRoZSBHSUMgZHJpdmVy Cj4gZm9yIGRpZmZlcmVudCBoYXJkd2FyZSBjYXNlLgo+IAo+IFdoZW4geW91IHNheSB3ZSdyZSBh Ym91dCA4IHllYXJzIHRvbyBsYXRlLCBJIHRoaW5rIHRoZXJlIHN0aWxsIG5vdAo+IG11Y2ggU29D cyB1c2luZyBHSUM2MDAsIG1heWJlIHRoZSBHSUM2MDAgSVAgaXMgYXZhaWxhYmxlIGZvciB1c2Vy IGF0Cj4gbWlkIG9mIDIwMTc/CgpJJ20gbm90IHN1cmUgd2hhdCB0aGUgeWVhciAyMDE3IGRvZXMg aGVyZS4gU1cgd3JpdHRlbiBhcyBlYXJseSBhcyAyMDEzCmFuZCBjb21wbGlhbnQgd2l0aCB0aGUg YXJjaGl0ZWN0dXJlIHN0aWxsIHdvcmtzIG9uIEdJQzYwMCB3aGVuIGl0IGlzCnByb3Blcmx5IGlu dGVncmF0ZWQuIExpbnV4IGFsc28gaGFzIHNwZWNpZmljIHJlcXVpcmVtZW50cywgYW5kIHlvdQpo YXZlIGRlY2lkZWQgdG8gaWdub3JlIHRoZW0uIFRoYXQncyB5b3VyIGNob2ljZS4gQnV0IHlvdSBh bHNvIGdldCB0bwprZWVwIHRoZSBwaWVjZXMgd2hlbiB0aGluZ3MgYnJlYWsuCgpOb3csIHRoaXMg ZGlzY3Vzc2lvbiBoYXMgbGFzdGVkIGxvbmcgZW5vdWdoLCBhbmQgaXNuJ3QgZ29pbmcgYW55d2hl cmUuCklmIHlvdSB3YW50IHVwc3RyZWFtIHN1cHBvcnQgZm9yIHlvdXIgSFcsIEkgaGF2ZSBleHBs YWluZWQgd2hhdCBuZWVkcwp0byBiZSBkb25lOiBkb2N1bWVudCB0aGUgdHdvIHByb2JsZW1zLCBp bXBsZW1lbnQgdGhlIHdvcmthcm91bmRzIHVzaW5nCnRoZSBHSUMgcXVpcmsgaW5mcmFzdHJ1Y3R1 cmUganVzdCBsaWtlIGFueSBvdGhlciBzaWxpY29uIHZlbmRvciBoYXMKZG9uZSBvdmVyIHRoZSBw YXN0IDggeWVhcnMuCgpJZiB5b3UgZG9uJ3Qgd2FudCB0byBkbyBpdCwgaXQgc3VpdHMgbWUganVz dCBhcyB3ZWxsLiBJIHdvbid0IGhhdmUgdG8KbWFpbnRhaW4geWV0IGFub3RoZXIgc2V0IG9mIFNv Qy1zcGVjaWZpYyB3b3JrYXJvdW5kcy4KClRoYW5rcywKCglNLgoKLS0gCldpdGhvdXQgZGV2aWF0 aW9uIGZyb20gdGhlIG5vcm0sIHByb2dyZXNzIGlzIG5vdCBwb3NzaWJsZS4KCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4LXJvY2tjaGlwIG1haWxp bmcgbGlzdApMaW51eC1yb2NrY2hpcEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5p bmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcm9ja2NoaXAK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55DB9C433B4 for ; Wed, 21 Apr 2021 10:23:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1E0F361427 for ; Wed, 21 Apr 2021 10:23:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239172AbhDUKYJ convert rfc822-to-8bit (ORCPT ); Wed, 21 Apr 2021 06:24:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:58198 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235231AbhDUKYD (ORCPT ); Wed, 21 Apr 2021 06:24:03 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 52E4B61445; Wed, 21 Apr 2021 10:23:30 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lZA12-008f1C-1U; Wed, 21 Apr 2021 11:23:28 +0100 Date: Wed, 21 Apr 2021 11:23:27 +0100 Message-ID: <874kg0q6lc.wl-maz@kernel.org> From: Marc Zyngier To: Kever Yang Cc: Peter Geis , Thomas Gleixner , "open list:ARM/Rockchip SoC..." , Linux Kernel Mailing List , Heiko =?UTF-8?B?U3Q=?= =?UTF-8?B?w7xibmVy?= Subject: Re: [RFC] ITS fails to allocate on rk3568/rk3566 In-Reply-To: <2791594e-db60-e1d0-88e5-7e5bbd98ae4d@rock-chips.com> References: <871rbeo7wf.wl-maz@kernel.org> <87y2dmmggt.wl-maz@kernel.org> <87tuoambdb.wl-maz@kernel.org> <871rbdt4tu.wl-maz@kernel.org> <678e9950-dd85-abb2-a104-07a4db1fad49@rock-chips.com> <87k0p4m0gm.wl-maz@kernel.org> <8d2e22f5-1c1b-e795-8757-ae078446d961@rock-chips.com> <878s5i2qyw.wl-maz@kernel.org> <2791594e-db60-e1d0-88e5-7e5bbd98ae4d@rock-chips.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: kever.yang@rock-chips.com, pgwipeout@gmail.com, tglx@linutronix.de, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, heiko@sntech.de X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Apr 2021 02:40:26 +0100, Kever Yang wrote: > > Hi Marc, > > On 2021/4/16 下午11:23, Marc Zyngier wrote: > > On Fri, 16 Apr 2021 02:13:38 +0100, > > Kever Yang wrote: > >> Hi Marc, > >> > >> On 2021/4/15 下午4:11, Marc Zyngier wrote: > >>> Hi Kever, > >>> > >>> On Thu, 15 Apr 2021 08:24:33 +0100, > >>> Kever Yang wrote: > >>>> Hi Marc, Peter, > >>>> > >>>>     RK356x GIC has two issues: > >>>> > >>>> 1. GIC only support 32bit address while rk356x supports 8GB DDR SDRAM, > >>>> so we use ZONE_DMA32 to fix this issue; > >>> What transactions does this affect exactly? > >> The GIC on rk356x is a 32bit master, which means all the space its > >> logic need to access should be in the 4GB range. > > Well, at least this is consistently broken. > > There are many legacy IPs which only support 32bit bus, we have to > use them as is in the new 64bit SoCs, I think the 32bit GIC can be > considered the same as those case, can we add CONFIG_ZONE_DMA32 > support in GIC driver? Only as an erratum workaround. The GIC isn't some random device that can live behind an IOMMU that will sort the mapping problem for you. By design, it must be untranslated, so limiting it to only a portion of the physical address space is a bug, full stop. > eg. Other peripheral driver use dma_alloc_coherent() instead of > alloc_pages(), so then can support ZONE_DMA32 without any code > change. You do realise that dma_alloc_coherent() requires the use of a struct device, and that the GIC is required to be up and running long before the device model is available, right? > >>> Only some ITS tables? Or > >>> all of them, including the command queue? What about the configuration > >>> and pending tables associated with the redistributors? > >>> > >>>> 2. GIC version is r1p6-00rel0, RK356x interconnect does not support > >>>> GIC and CPU snoop to each other, hence the GIC does not support the > >>>> shareability feature.  The read of register value for shareability > >>>> feature does not return as expect in GICR and GITS, so we have to > >>>> workaround for it. > >>> How about the cacheability attribute? Can you please provide the exact > >>> set of attributes that this system actually supports for each of the > >>> ITS and redistributor base registers? > >> The shareability attributes in GICR_PENDBASEER, GICR_PROPBASER, > >> GITS_BASERn, GITS_CBASER default value is 0b00, when we set 0b01 then > >> read returns 0b01. > > And I claim that this is a perfectly broken behaviour. How do you > > expect software to find about the gory details of the integration? > > That's the only way for SW to find out what the HW is capable of... > > As a software engineer, I totally agree with you on this point, but > when we back to the truth, we should know that these registers has > never been defined as "module capability for shareability" Says who? If SW cannot discover the capability of the HW, then nothing works. > in hardware. The software use it as capability detect, and it works > before, but not means match the original hardware design, in this > case the new hardware may not follow the design because it's not a > standard or a clear enough guide for it. The spec has been clear enough for *everyone* so far, and other GIC600 implementations got it perfectly right. There has been *one* exception, which is documented and handled as a quirk. > The capability register should always read-only instead of > read-write, the understanding software engineer and from hardware > engineer always have a gap. > > I would proposal to add a optional dts property for driver to > identify if the board's GIC shareability or not, which is a method > used by many other module drivers. Are you also going to propose and support an ACPI specification update to cope with similarly broken devices? Either this is something that is available across the various firmware implementations, or it doesn't exist. > > >> Since there is no ACE coherency interface for this GIC controller, all > >> the cacheability in the GIC is not support in hardware. > >> > >>> Also, please provide errata numbers for these two issues so that we > >>> can properly document them and track the workarounds. > >> What kind of errata do you need, could you please share any kind of > >> example close to this case? > > I would like something that says: > > > > "ROCKCHIP_ERRATUM_123456: The GIC600 integration in RK356x doesn't > > support any of the shareability or cacheability attributes, and > > requires both values to be set to 0b00 for all the ITS and > > Redistributor tables." > > > > This is pretty similar to the bug affecting ThunderX with its "erratum > > 24313" (covered by CONFIG_CAVIUM_ERRATUM_22375), where the tables have > > to be flagged as non-cacheable. The Rockchip one is just worse. > > > > We need an official erratum number so that we can refer to it in the > > source, commit log and documentation, as well as cross-reference it > > with the TRM. This number will be part of a configuration symbol that > > will make the compilation conditional so that people don't have to > > carry the extra burden generated by this bug if they don't need to. > > > > Same thing goes for the 32bit bug. > > > >> We consider this as a SoC implement design instead of a bug, so we > >> will add document in RK356X  TRM to describe the GIC design, but no > >> idea how to provide the errata. > >> > >> Here is the shareabily attribute from ARM GIC architecture specification: > >> Shareability, bits [11:10] (from GITS_CBASER) > >> Indicates the Shareability attributes of accesses to the command > >> queue. The possible values of this field are: > >> 0b00 Non-shareable. > >> 0b01 Inner Shareable. > >> 0b10 Outer Shareable. > >> 0b11 Reserved. Treated as 0b00. > >> It is IMPLEMENTATION DEFINED whether this field has a fixed value or > >> can be programmed by software. Implementing this field with a fixed > >> value is deprecated. > >> On a Warm reset, this field resets to an architecturally UNKNOWN value > >> > >> As you can see, "Implementing this field with a fixed value is > >> deprecated", so software should program this field to '0b00 > >> Non-shareable' if the SoC design does not support the cache > >> shareability. > > [I really feel special when people quote the GIC spec at me] > > > > That isn't what it says. Hardcoding the field with a fixed value is > > indeed deprecated, but that doesn't mean this field should accept > > values that the HW cannot support. If anything, what this says is "try > > and implement the options that SW is going to use". > > > > But you need to give SW an indication of what is usable, because there > > is no other way to *discover* what the SoC is capable of at runtime. > > Otherwise, we would need to carry a per-SoC list of what the HW > > supports. I don't think that's the right thing to do (and you're about > > 8 years too late anyway). > > > > Other GIC600 integrations got it perfectly right, by the way. Same for > > other GIC implementations, with the notable exception of Cavium and > > their first GIC in ThunderX, as described above. > > I'm not sure if you still work for ARM or not, but we do have double I don't think whoever pays my salary is relevant in this context. I am writing as the guy who maintains the GIC architecture in Linux, and the fact that I have worked, work, or will work for ARM or not has no bearing on what I am saying here. > check again and again with IP vendor about this point, the GIC500 > works because it's hardware bind to a fix value inside the IP, but > GIC600 does not do the same binding, and there is no any config > option to hardcode the reg field to a fixed value in the IP when > we don't need the ACE-lite. > > This is why I insist that this is a different SoC implementation > instead of a SoC bug, we should add the support in the GIC driver > for different hardware case. > > When you say we're about 8 years too late, I think there still not > much SoCs using GIC600, maybe the GIC600 IP is available for user at > mid of 2017? I'm not sure what the year 2017 does here. SW written as early as 2013 and compliant with the architecture still works on GIC600 when it is properly integrated. Linux also has specific requirements, and you have decided to ignore them. That's your choice. But you also get to keep the pieces when things break. Now, this discussion has lasted long enough, and isn't going anywhere. If you want upstream support for your HW, I have explained what needs to be done: document the two problems, implement the workarounds using the GIC quirk infrastructure just like any other silicon vendor has done over the past 8 years. If you don't want to do it, it suits me just as well. I won't have to maintain yet another set of SoC-specific workarounds. Thanks, M. -- Without deviation from the norm, progress is not possible.