From: Kevin Hilman <khilman@baylibre.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
Olof Johansson <olof@lixom.net>,
"devicetree\@vger.kernel.org" <devicetree@vger.kernel.org>,
xypron.glpk@gmx.de,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Carlo Caione <carlo@caione.org>,
linux-amlogic@lists.infradead.org,
"linux-arm-kernel\@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
Date: Wed, 18 Jan 2017 11:54:20 -0800 [thread overview]
Message-ID: <m260lc16vn.fsf@baylibre.com> (raw)
In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de> ("Andreas Färber"'s message of "Wed, 18 Jan 2017 01:00:50 +0100")
Andreas Färber <afaerber@suse.de> 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
next prev parent reply other threads:[~2017-01-18 19:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-11 10:10 [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range Neil Armstrong
2017-01-13 20:03 ` Kevin Hilman
2017-01-15 14:43 ` Andreas Färber
2017-01-16 10:39 ` Neil Armstrong
2017-01-16 15:06 ` Andreas Färber
2017-01-17 6:07 ` Olof Johansson
2017-01-17 8:21 ` Neil Armstrong
2017-01-18 0:00 ` Andreas Färber
2017-01-18 0:27 ` Andreas Färber
2017-01-18 10:58 ` Neil Armstrong
2017-01-18 10:57 ` Neil Armstrong
2017-01-18 19:54 ` Kevin Hilman [this message]
2017-01-18 0:09 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m260lc16vn.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=afaerber@suse.de \
--cc=carlo@caione.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=narmstrong@baylibre.com \
--cc=olof@lixom.net \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox