From patchwork Wed Mar 6 10:23:34 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Petazzoni X-Patchwork-Id: 225472 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E92B92C0388 for ; Wed, 6 Mar 2013 21:27:56 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UDBWB-0003j8-Ug; Wed, 06 Mar 2013 10:24:16 +0000 Received: from mail.free-electrons.com ([94.23.35.102]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UDBVk-0003dY-3K for linux-arm-kernel@lists.infradead.org; Wed, 06 Mar 2013 10:23:50 +0000 Received: by mail.free-electrons.com (Postfix, from userid 106) id 257341130; Wed, 6 Mar 2013 11:23:49 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.free-electrons.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.3.2 Received: from localhost (col31-4-88-188-83-94.fbx.proxad.net [88.188.83.94]) by mail.free-electrons.com (Postfix) with ESMTPSA id 726B97DE; Wed, 6 Mar 2013 11:23:48 +0100 (CET) From: Thomas Petazzoni To: Jason Cooper , Andrew Lunn , Gregory Clement Subject: [PATCH 2/4] arm: plat-orion: fix address decoding when > 4GB is used Date: Wed, 6 Mar 2013 11:23:34 +0100 Message-Id: <1362565416-15718-3-git-send-email-thomas.petazzoni@free-electrons.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1362565416-15718-1-git-send-email-thomas.petazzoni@free-electrons.com> References: <1362565416-15718-1-git-send-email-thomas.petazzoni@free-electrons.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130306_052348_618954_233A4121 X-CRM114-Status: GOOD ( 19.18 ) X-Spam-Score: -2.5 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.5 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Lior Amsalem , Maen Suleiman , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org During the system initialization, the orion_setup_cpu_mbus_target() function reads the SDRAM address decoding registers to find out how many chip-selects of SDRAM have been enabled, and builds a small array with one entry per chip-select. This array is then used by device drivers (XOR, Ethernet, etc.) to configure their own address decoding windows to the SDRAM. However, devices can only access the first 32 bits of the physical memory. Even though LPAE is not supported for now, some Marvell boards are now showing up with 8 GB of RAM, configured using two SDRAM address decoding windows: the first covering the first 4 GB, the second covering the last 4 GB. The array built by orion_setup_cpu_mbus_target() has therefore two entries, and device drivers try to set up two address decoding windows to the SDRAM. However, in the device registers for the address decoding, the base address is only 32 bits, so those two windows overlap each other, and the devices do not work at all. This patch makes sure that the array built by orion_setup_cpu_mbus_target() only contains the SDRAM decoding windows that correspond to the first 4 GB of the memory. To do that, it ignores the SDRAM decoding windows for which the 4 low-order bits are not zero (the 4 low-order bits of the base register are used to store bits 32:35 of the base address, so they actually indicate whether the base address is above 4 GB). This patch allows the newly introduced armada-xp-gp board to properly operate when it is mounted with more than 4 GB of RAM. Without that, all devices doing DMA (for example XOR and Ethernet) do not work at all. Signed-off-by: Thomas Petazzoni Tested-by: Ezequiel Garcia --- This is a slightly updated version compared to the one sent on February 27th on LAKML. The earlier version was looking at the three low-order bits, but in fact there are four low-order bits to encode the high bits of the base address. So the mask was changed from 0x7 to 0xF. Since I've changed the patch, I haven't kept the Tested-by from Lior Amsalem, Grégory Clement and Ezequiel Garcia. --- arch/arm/plat-orion/addr-map.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-orion/addr-map.c b/arch/arm/plat-orion/addr-map.c index febe386..807ac8e 100644 --- a/arch/arm/plat-orion/addr-map.c +++ b/arch/arm/plat-orion/addr-map.c @@ -157,9 +157,12 @@ void __init orion_setup_cpu_mbus_target(const struct orion_addr_map_cfg *cfg, u32 size = readl(ddr_window_cpu_base + DDR_SIZE_CS_OFF(i)); /* - * Chip select enabled? + * We only take care of entries for which the chip + * select is enabled, and that don't have high base + * address bits set (devices can only access the first + * 32 bits of the memory). */ - if (size & 1) { + if ((size & 1) && !(base & 0xF)) { struct mbus_dram_window *w; w = &orion_mbus_dram_info.cs[cs++];