[PATCH 11/12] powerpc: wiiu: don't enforce flat memory

[Pali Rohár]

+ linux-mm

Do you know what are requirements for kernel to support non-contiguous
memory support and what is needed to enable it for 32-bit powerpc?

Currently powerpc arch code does not support "memblock.memory.cnt > 1"
except for WII which seems like a hack... See below.

On Friday 20 May 2022 20:44:04 Ash Logan wrote:
> On 20/5/22 18:04, Pali Rohár wrote:
> > On Friday 20 May 2022 13:41:04 Ash Logan wrote:
> >> On 14/5/22 08:43, Pali Rohár wrote:
> >>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote:
> >>>> pgtable_32.c:mapin_ram loops over each valid memory range, which means
> >>>> non-contiguous memory just works.
> >>>
> >>> Hello! Does it mean that non-contiguous memory works for any 32-bit
> >>> powerpc platform, and not only for wiiu? If yes, should not be
> >>> non-contiguous memory support enabled for all 32-bit ppc boards then?
> >>
> >> Hi! Sorry for my delayed response. As best I can tell, it does indeed
> >> Just Work, but I have only been able to test on wiiu which is missing a
> >> lot of features other boards have (like PCI) - so it's possible there's
> >> still an assumption elsewhere in the kernel that I haven't hit.
> >>
> >> As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards
> >> out there where it's even possible to have non-contiguous memory.
> > 
> > What is the reason that those two boards are the **only**? Is there some
> > specific requirement from bootloader or hardware to "enable"
> > non-contiguous memory support?
> 
> Not that I know of, I was just saying that I was only aware of those two
> boards where the memory map isn't contiguous, and that is the only place
> where it has been tested. Evidently you know of another board!
> 
> > I'm interested in enabling non-contiguous memory support for P2020-based
> > board as it has gaps in its 32-bit memory layout and which could be used
> > for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB).
> 
> If it's like the Wii or Wii U (some memory at 0, a gap for MMIO or
> whatever, then more memory at a higher address) then you should try a
> patch along these lines, because barring the unknowns I mentioned before
> it should work. At least as far as I'm aware ;)
> 
> >>>> Signed-off-by: Ash Logan <ash at heyquark.com>
> >>>> ---
> >>>>  arch/powerpc/mm/init_32.c | 4 ++--
> >>>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
> >>>> index 3d690be48e84..59a84629d9a0 100644
> >>>> --- a/arch/powerpc/mm/init_32.c
> >>>> +++ b/arch/powerpc/mm/init_32.c
> >>>> @@ -125,10 +125,10 @@ void __init MMU_init(void)
> >>>>  	 * lowmem_end_addr is initialized below.
> >>>>  	 */
> >>>>  	if (memblock.memory.cnt > 1) {
> >>>> -#ifndef CONFIG_WII
> >>>> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU)
> >>>>  		memblock_enforce_memory_limit(memblock.memory.regions[0].size);
> >>>>  		pr_warn("Only using first contiguous memory region\n");
> >>>> -#else
> >>>> +#elif defined(CONFIG_WII)
> >>>>  		wii_memory_fixups();
> >>>>  #endif
> >>>>  	}
> >>>> -- 
> >>>> 2.35.1
> >>>>