From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753669AbdARTy1 (ORCPT ); Wed, 18 Jan 2017 14:54:27 -0500 Received: from mail-pg0-f47.google.com ([74.125.83.47]:33202 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753568AbdARTyW (ORCPT ); Wed, 18 Jan 2017 14:54:22 -0500 From: Kevin Hilman To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Neil Armstrong , Olof Johansson , "devicetree\@vger.kernel.org" , xypron.glpk@gmx.de, "linux-kernel\@vger.kernel.org" , Carlo Caione , linux-amlogic@lists.infradead.org, "linux-arm-kernel\@lists.infradead.org" Subject: Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range Organization: BayLibre References: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com> <7fcb8d94-840a-de2c-f43b-9123ccc65514@baylibre.com> <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> Date: Wed, 18 Jan 2017 11:54:20 -0800 In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> ("Andreas =?utf-8?Q?F=C3=A4rber=22's?= message of "Wed, 18 Jan 2017 01:00:50 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v0IJske2019068 Andreas Färber writes: > Hi Neil, > > Am 17.01.2017 um 09:21 schrieb Neil Armstrong: >> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that >> overrides the reg property that is changed by the bootloader to provide the "real" memory size. > > Yes, exactly. It assured that 0..0x01000000 was always unavailable, as > intended, but at the same time it ignored any lowered or heightened > upper limit coming from the bootloader side. > > As a rule of thumb, any nodes that have device_type set can be expected > to be modified during boot. > >> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide >> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here. >> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved. >> >> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory >> zones, > > Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;) > >> but I also got the issue while running a fully fledged Desktop Environment thanks to the >> recently merged DRM driver. > > I'll happily test once HDMI is ready. :) > >> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM : >> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce >> But it should be confirmed. > > Confirming no issues on three runs on meson-gxm-rbox-pro: > > boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s & > [1] 2528 > boxer:~ # stress-ng: info: [2528] dispatching hogs: 4 vm > stress-ng: info: [2528] cache allocate: default cache size: 256K > stress-ng: info: [2528] successful run completed in 10.07s > > [1]+ Done stress-ng --vm 4 --vm-bytes 128M --timeout 10s > boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s > stress-ng: info: [2537] dispatching hogs: 4 vm > stress-ng: info: [2537] cache allocate: default cache size: 256K > stress-ng: info: [2537] successful run completed in 10.07s > boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s > stress-ng: info: [2546] dispatching hogs: 4 vm > stress-ng: info: [2546] cache allocate: default cache size: 256K > stress-ng: info: [2546] successful run completed in 10.07s > boxer:~ # > >> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but >> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error. >> >> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size >> fixup for a future DTS cleanup. >> >> Andreas, is this ok for you ? > > Yes, sounds fine to me, thanks. I'll note a few more nits to consider. > > Kevin, I noticed that this supposedly applied patch did not show up in > linux-next for testing - could you merge your fixes branch into for-next > please for those of us working on new stuff? Any fixes I have queued are always in my for-mext branch (which is included i linux-next.) This fix was there as well, but was removed due to objections shortly after I added it, so it never quite made it to linux-next (or may have for one day, I'm not sure.) Kevin