Hi Quentin,
On 5/10/21 12:09 PM, Quentin Perret wrote:
Hi Alexandre,
On Friday 07 May 2021 at 17:15:20 (+0200), Alexandre TORGUE wrote:
Did you get time to continue some tests on this issue ?
I did try a few things, but still fail to reproduced :/
On my side this DT is not working:
memory@c0000000 {
reg = <0xc0000000 0x20000000>;
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
gpu_reserved: gpu@d4000000 {
reg = <0xd4000000 0x4000000>;
no-map;
};
};
So this does change how memory appears in /proc/iomem for me switching
from 5.4.101 to v5.4.102 -- for the former d4000000-d7ffffff doesn't
appear at all, and for the latter it appears as 'reserved'.
But still, it never gets accounted as System RAM for me ...
Let me know if I can help.
Could you please confirm you get a correct behaviour with 5.10.31 like
Florian? If so, then bisecting to figure out what we're missing in older
LTSes would help, but again it feels like we should just revert -- this
wasn't really a fix in the first place.
We saw that patches [1] and [2] cause issue on stable version (at least
for 5.4). As you said issue can be seen with above device tree and check
in /proc/iomem than gpu_reserved region is taken by the kernel as
"System RAM".
On v5.10 stream there are no issues seen taking patches [1]&[2] and the
reason is linked to patches [3]&[4] which have been introduced in
v5.10.0. Reverting them give me the same behavior than on stable version.
[1] of/fdt: Make sure no-map does not remove already reserved regions
[2] fdt: Properly handle "no-map" field in the memory region
[3] arch, drivers: replace for_each_membock() with for_each_mem_range()
[4] memblock: use separate iterators for memory and reserved regions
regards
Alex
Thanks,
Quentin
