Messages in this thread | | | Subject | Re: [PATCH 0/6] DISCONTIGMEM support for PPC32 | From | Christophe LEROY <> | Date | Wed, 21 Feb 2018 16:02:25 +0100 |
| |
Le 21/02/2018 à 15:42, Jonathan Neuschäfer a écrit : > Hi, > > On Wed, Feb 21, 2018 at 08:06:10AM +0100, Christophe LEROY wrote: >> >> >> Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit : >>> This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is >>> required to properly support the Nintendo Wii's memory layout, in which >>> there are two blocks of RAM and MMIO in the middle. >>> >>> Previously, this memory layout was handled by code that joins the two >>> RAM blocks into one, reserves the MMIO hole, and permits allocations of >>> reserved memory in ioremap. This hack didn't work with resource-based >>> allocation (as used for example in the GPIO driver for Wii[1]), however. >>> >>> After this patchset, users of the Wii can either select CONFIG_FLATMEM >>> to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new >>> behaviour. >> >> My question might me stupid, as I don't know PCC64 in deep, but when looking >> at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling the PPC64 >> implements ram by blocks. Isn't it what you are trying to achieve ? Wouldn't >> it be feasible to map to what's done in PPC64 for PPC32 ? > > Using page_is_ram in __ioremap_caller and the same memblock-based > approach that's used on PPC64 on PPC32 *should* work, but I think due to > the following line in initmem_init, it won't: > > memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock.memory, 0);
Can't we just fix that ?
Christophe
> > > Thanks, > Jonathan Neuschäfer >
| |