On Wed, May 29, 2019 at 02:40:53PM +1200, Michael Schmitz wrote: > Hi Mike, > > sorry, haven't had time to test this one yet. > > Thanks for updating the description - note that the case of out-of-order > memory chunks does not only apply to ST-RAM/Fast-RAM on Atari. AFAIK it can > also happen with certain memory expansion boards for Amiga. > > What would be required to enable use of such out-of-order chunks? From my > tests with the prior series, commenting out the 'ignoring memory chunk' > part in paging_init() already does get the previously ignored chunk mapped, > with virtual addresses after the ones for the first chunk (which starts at > va zero). This probably still leaves the ioremapped screen buffer mapped > twice though. I didn't look into that, but beside the frame buffer issues that might arise, it could be that mapping low physical addresses at higher virtual address would break __pa()/__va() conversion.
> With out-of-order chunks, taking the lowest physical address from > m68k_memory[0].addr (in m68k_free_area_init()) is probably the reason for > the low-address chunk still being reported as mapped? Might make more sense > to pass the correct min_addr explicitly ... I'll give that a try. > > Cheers, > > Michael > > > On 29/05/19 1:24 AM, Mike Rapoport wrote: > > >Hi, > > > >Any comments on this? > > > >On Thu, May 16, 2019 at 09:03:18AM +0300, Mike Rapoport wrote: > >>Hi, > >> > >>These pacthes replace DISCONTIGMEM with SPARSEMEM on m68k for systems with > >>!SINGLE_MEMORY_CHUNK set. > >> > >>With SPARSEMEM there is a single node for the entire physical memory and to > >>cope with holes in the physical address space it is divided to sections of > >>up to 16M. > >> > >>Each section has it's own memory map which size depends on actual populated > >>memory. > >> > >>The section size of 16M was chosen pretty much arbitrarily as I couldn't > >>find specs for systems with e.g. Zorro memory extensions. > >> > >>For the systems with ST-RAM and FastRAM, the switch to SPARSEMEM does not > >>change the limitation that if the kernel is loaded into the FastRam the > >>ST-RAM remains unmapped. It only ensures that if the kernel is loaded in > >>ST-RAM, the memory map is allocated from high physical addresses and then > >>atari/stram.c is able to reserve the frame buffer memory. If the kernel is > >>loaded to FastRAM, the ST-RAM remains unmapped as with DISCONTIGMEM and the > >>atari/stram.c maps it as IOMEM. > >> > >>v2 changes: > >>* rebase on the current upstream > >>* make ColdFire MMU select SINGLE_MEMORY_CHUNK in Kconfig.cpu > >> > >>Mike Rapoport (3): > >> m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM > >> m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM > >> m68k/mm: switch from DISCONTIGMEM to SPARSEMEM > >> > >> arch/m68k/Kconfig.cpu | 14 ++++++-- > >> arch/m68k/include/asm/page.h | 2 ++ > >> arch/m68k/include/asm/page_mm.h | 6 +++- > >> arch/m68k/include/asm/sparsemem.h | 8 +++++ > >> arch/m68k/include/asm/virtconvert.h | 2 +- > >> arch/m68k/mm/init.c | 8 ++--- > >> arch/m68k/mm/motorola.c | 64 > >> ++++++++++++++++++++++++++++++------- > >> 7 files changed, 84 insertions(+), 20 deletions(-) > >> create mode 100644 arch/m68k/include/asm/sparsemem.h > >> > >>-- > >>2.7.4 > >> > -- Sincerely yours, Mike.
