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