From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 16 Aug 2016 17:36:15 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:32924 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S23992378AbcHPPgI3Gted (ORCPT ); Tue, 16 Aug 2016 17:36:08 +0200 Received: from scotty.linux-mips.net (localhost.localdomain [127.0.0.1]) by scotty.linux-mips.net (8.15.2/8.14.8) with ESMTP id u7GFa7Do006312; Tue, 16 Aug 2016 17:36:07 +0200 Received: (from ralf@localhost) by scotty.linux-mips.net (8.15.2/8.15.2/Submit) id u7GFa7OO006311; Tue, 16 Aug 2016 17:36:07 +0200 Date: Tue, 16 Aug 2016 17:36:07 +0200 From: Ralf Baechle To: James Hogan Cc: Paul Burton , linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] MIPS: Memory setup tweaks Message-ID: <20160816153606.GF3894@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 54571 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Tue, Aug 09, 2016 at 01:21:47PM +0100, James Hogan wrote: > Here are a couple of tweaks for MIPS memory setup, primarily in order to > handle memory which extends right up to the end of physical memory on > 32-bit systems with 32-bit phys_addr_t. More specifically we omit the > final page of physical memory to avoid the overflow (see patch 1 for > details). > > Patch 2 improves the rounding in the MAAR setup, so as to include the > first full page of an already aligned region, and to avoid a BUG_ON for > regions with non 64-KByte aligned end addresses (which I happened to hit > while working on a different version of patch 1 which wasn't correctly > merging the kernel data section into the main RAM region). There's a DMA issue with one of the system controllers on Malta which afair only affects one endianess and can be worked around by not using the last bit of memory. That isn't the only platform having such issues I've seen and debugging has always been very painful so I'm wondering if as a general precaution we should just leave the last page of memory unused. Ralf