On Tue, Jan 23, 2018 at 11:58:06PM +1100, Michael Ellerman wrote:
> Jonathan Neuschäfer <j.neuschaefer@xxxxxxx> writes:
>
> > On the Nintendo Wii, there are two ranges of physical memory, and MMIO
> > in between, but Linux on ppc32 doesn't support discontiguous memory.
> > Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
> > ioremap within reserved memory regions") and commit de32400dd26e ("wii:
> > use both mem1 and mem2 as ram"):
> >
> > - Treat the area from the start of the first memory area (MEM1) to the
> > end of the second (MEM2) as one big memory area, but mark the part
> > that doesn't belong to MEM1 or MEM2 as reserved.
> > - Only on the Wii, allow ioremap to be used on reserved memory.
> >
> > This hack, however, doesn't account for the "resource"-based API in
> > kernel/resource.c, because __request_region performs its own checks.
> >
> > Extend the hack to kernel/resource.c, to allow more drivers to allocate
> > their MMIO regions on the Wii.
>
> Hi Jonathan,
>
> Sorry but I can't merge a hack like this in generic code.
Makes sense.
> Has anyone looked at adding proper discontig mem support to PPC32?
I'm not aware of any such effort.
Do you have any pointer on how to implement discontiguous memory
support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant.
> Or can we punch a hole in the resource in the right place? Maybe from
> add_system_ram_resources() ?
Not sure. add_system_ram_resources would need the original memblock
table, which is overwritten in wii_memory_fixups, if I read the code
correctly.
If a proper solution doesn't take an overwhelming amount of work, I'd
prefer a proper solution.
Thanks,
Jonathan Neuschäfer
Attachment:
signature.asc
Description: PGP signature
