ACPI tables limited to 4k in size

[Graeme Gregory]

On arm currently because acpi_map() eventually ends at kmap() function our maximum table size is currently limited to 4k.

Tables also cannot cross a 4k boundary.

There is currently a hack in mab (Make Arm Blob) to make sure a table never crosses a 4k boundary, but we need to fix this properly in kernel sometime.

[Graeme Gregory (graeme-gregory)]

The relevant code from osl.c

#ifndef CONFIG_IA64
#define should_use_kmap(pfn) page_is_ram(pfn)
#else
/* ioremap will take care of cache attributes */
#define should_use_kmap(pfn) 0
#endif

static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz)
{
 unsigned long pfn;

 pfn = pg_off >> PAGE_SHIFT;
 if (should_use_kmap(pfn)) {
  if (pg_sz > PAGE_SIZE)
   return NULL;
  return (void __iomem __force *)kmap(pfn_to_page(pfn));
 } else
  return acpi_os_ioremap(pg_off, pg_sz);
}

static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
{
 unsigned long pfn;

 pfn = pg_off >> PAGE_SHIFT;
 if (should_use_kmap(pfn))
  kunmap(pfn_to_page(pfn));
 else
  iounmap(vaddr);
}

[Al Stone (ahs3)]

Correct, the osl.c code is the starting point. There are two phases to these mappings within ACPI: (1) very early in the boot when it is assumed the tables are at physical addresses, and then (2) a second pass that tries to put the tables in a final location. I've got a patch that gets into the second phase but is not yet mapping the tables correctly -- will continue working that out and post here for testing eventually.

[Al Stone (ahs3)]

NB: changing priority since this also affects being able to make UEFI and ACPI work together well.

[Al Stone (ahs3)]

Changed the ACPI work to use the new early_ioremap function instead of kmap. This removes the 4K restriction completely.

Tested and verified with ACPI and leg-kernel sources tree as of 2013-10-04, with u-boot, UEFI, boot-wrapper on RTSM ARMv7 and RTSM ARMv8, the ARMv8 Foundation model and the Arndale board.