From patchwork Thu Aug 6 17:33:32 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Heiko_St=C3=BCbner?= X-Patchwork-Id: 6961621 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 38CF0C05AC for ; Thu, 6 Aug 2015 17:37:27 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5A31120628 for ; Thu, 6 Aug 2015 17:37:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BAD1320623 for ; Thu, 6 Aug 2015 17:37:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZNP6Z-00017J-P1; Thu, 06 Aug 2015 17:37:23 +0000 Received: from gloria.sntech.de ([95.129.55.99]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZNP6R-0000zQ-OF; Thu, 06 Aug 2015 17:37:21 +0000 Received: from [95.91.148.129] (helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZNP65-0007JE-Kj; Thu, 06 Aug 2015 19:36:53 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Douglas Anderson , Alexandru Stan Subject: [PATCH v2 1/2] ARM: dts: rockchip: reserve unusable memory region on rk3288 Date: Thu, 06 Aug 2015 19:33:32 +0200 Message-ID: <1763907.pckMEaRNPs@diego> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150806_103716_135946_D42C2030 X-CRM114-Status: GOOD ( 11.33 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The all current Rockchip SoCs supporting 4GB of ram have problems accessing the memory region 0xfe000000~0xff000000. This also seems to includes the rk3368 arm64 soc. All current code handling dma memory oddities I could find, seem to involve soc-specific code (zone-dma or so) while this issue is shared between arm32 and arm64 socs from Rockchip, which would need to have this described in the soc devicetree on both socs. Limiting the dma-zone alone also does not solve the issue and as the dma-masks need to be a power-of-two in the kernel, the next lower dma-mask brings memory usable for dma down to 2GB. So as a stop-gap block off the affected region to prevent its use by devices with 4GB of memory, like some recent Chromebooks. Signed-off-by: Heiko Stuebner Reviewed-by: Douglas Anderson --- changes since v1: - expand reasons for the reserved memory arch/arm/boot/dts/rk3288.dtsi | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index 47a15aa..118fe74 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -169,6 +169,26 @@ }; }; + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + /* + * The rk3288 cannot use the memory area above 0xfe000000 + * for dma operations for some reason. While there is + * probably a better solution available somewhere, we + * haven't found it yet and while devices with 2GB of ram + * are not affected, this issue prevents 4GB from booting. + * So to make these devices at least bootable, block + * this area for the time being until the real solution + * is found. + */ + dma-unusable@fe000000 { + reg = <0xfe000000 0x1000000>; + }; + }; + xin24m: oscillator { compatible = "fixed-clock"; clock-frequency = <24000000>;