Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
On Wed, Feb 21, 2018 at 04:02:25PM +0100, Christophe LEROY wrote: [...] > > > 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, , 0); > > Can't we just fix that ? Turns out I was completely wrong about this. memblock_set_node as called above only assigns all memory to node 0 and merges *adjacent* memblocks. It doesn't merge the memblocks on the Wii, which are far apart. So now I actually have a working patchset (coming soon), that's a good deal shorter than this patchset, and hopefully won't break CONFIG_HIGHMEM in the same way. Thanks for your input! :) Jonathan Neuschäfer signature.asc Description: PGP signature
Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
On Wed, Feb 21, 2018 at 04:02:25PM +0100, Christophe LEROY wrote: [...] > > > 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, , 0); > > Can't we just fix that ? I'll give it a try. Thanks, Jonathan Neuschäfer signature.asc Description: PGP signature
Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
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, , 0); Can't we just fix that ? Christophe Thanks, Jonathan Neuschäfer
Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
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, , 0); Thanks, Jonathan Neuschäfer signature.asc Description: PGP signature
Re: [PATCH 0/6] DISCONTIGMEM support for PPC32
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 ? Christophe Some parts of this patchset are probably not ideal (I'm thinking of my implementation of pfn_to_nid here), and will require some discussion/ changes. [1]: https://www.spinics.net/lists/devicetree/msg213956.html Jonathan Neuschäfer (6): powerpc/mm/32: Use pfn_valid to check if pointer is in RAM powerpc: numa: Fix overshift on PPC32 powerpc: numa: Use the right #ifdef guards around functions powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems powerpc: Implement DISCONTIGMEM and allow selection on PPC32 powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is set arch/powerpc/Kconfig | 5 - arch/powerpc/include/asm/mmzone.h| 21 + arch/powerpc/mm/numa.c | 18 +++--- arch/powerpc/mm/pgtable_32.c | 2 +- arch/powerpc/platforms/embedded6xx/wii.c | 10 +++--- 5 files changed, 48 insertions(+), 8 deletions(-)
[PATCH 0/6] DISCONTIGMEM support for PPC32
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. Some parts of this patchset are probably not ideal (I'm thinking of my implementation of pfn_to_nid here), and will require some discussion/ changes. [1]: https://www.spinics.net/lists/devicetree/msg213956.html Jonathan Neuschäfer (6): powerpc/mm/32: Use pfn_valid to check if pointer is in RAM powerpc: numa: Fix overshift on PPC32 powerpc: numa: Use the right #ifdef guards around functions powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems powerpc: Implement DISCONTIGMEM and allow selection on PPC32 powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is set arch/powerpc/Kconfig | 5 - arch/powerpc/include/asm/mmzone.h| 21 + arch/powerpc/mm/numa.c | 18 +++--- arch/powerpc/mm/pgtable_32.c | 2 +- arch/powerpc/platforms/embedded6xx/wii.c | 10 +++--- 5 files changed, 48 insertions(+), 8 deletions(-) -- 2.16.1
