Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux