All of lore.kernel.org
 help / color / mirror / Atom feed
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 =?utf-8?Q?F=C3=A4rber=22'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

WARNING: multiple messages have this Message-ID (diff)
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 =?utf-8?Q?F=C3=A4rber=22'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

WARNING: multiple messages have this Message-ID (diff)
From: khilman@baylibre.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [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 =?utf-8?Q?F=C3=A4rber=22'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

WARNING: multiple messages have this Message-ID (diff)
From: khilman@baylibre.com (Kevin Hilman)
To: linus-amlogic@lists.infradead.org
Subject: [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 =?utf-8?Q?F=C3=A4rber=22'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

  parent reply	other threads:[~2017-01-18 19:54 UTC|newest]

Thread overview: 48+ 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-11 10:10 ` Neil Armstrong
2017-01-11 10:10 ` Neil Armstrong
2017-01-13 20:03 ` Kevin Hilman
2017-01-13 20:03   ` Kevin Hilman
2017-01-13 20:03   ` Kevin Hilman
2017-01-15 14:43   ` Andreas Färber
2017-01-15 14:43     ` Andreas Färber
2017-01-15 14:43     ` Andreas Färber
2017-01-15 14:43     ` Andreas Färber
2017-01-16 10:39     ` Neil Armstrong
2017-01-16 10:39       ` Neil Armstrong
2017-01-16 10:39       ` Neil Armstrong
2017-01-16 10:39       ` Neil Armstrong
2017-01-16 15:06       ` Andreas Färber
2017-01-16 15:06         ` Andreas Färber
2017-01-16 15:06         ` Andreas Färber
2017-01-16 15:06         ` Andreas Färber
2017-01-17  6:07       ` Olof Johansson
2017-01-17  6:07         ` Olof Johansson
2017-01-17  6:07         ` Olof Johansson
2017-01-17  8:21         ` Neil Armstrong
2017-01-17  8:21           ` Neil Armstrong
2017-01-17  8:21           ` Neil Armstrong
2017-01-18  0:00           ` Andreas Färber
2017-01-18  0:00             ` Andreas Färber
2017-01-18  0:00             ` Andreas Färber
2017-01-18  0:00             ` Andreas Färber
2017-01-18  0:27             ` Andreas Färber
2017-01-18  0:27               ` Andreas Färber
2017-01-18  0:27               ` Andreas Färber
2017-01-18  0:27               ` Andreas Färber
2017-01-18 10:58               ` Neil Armstrong
2017-01-18 10:58                 ` Neil Armstrong
2017-01-18 10:58                 ` Neil Armstrong
2017-01-18 10:58                 ` Neil Armstrong
2017-01-18 10:57             ` Neil Armstrong
2017-01-18 10:57               ` Neil Armstrong
2017-01-18 10:57               ` Neil Armstrong
2017-01-18 10:57               ` Neil Armstrong
2017-01-18 19:54             ` Kevin Hilman [this message]
2017-01-18 19:54               ` Kevin Hilman
2017-01-18 19:54               ` Kevin Hilman
2017-01-18 19:54               ` Kevin Hilman
2017-01-18  0:09 ` Andreas Färber
2017-01-18  0:09   ` Andreas Färber
2017-01-18  0:09   ` Andreas Färber
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.