Re: [PATCH 0/7] ACPI: Memory Mapped I/O (MMIO) pre-mapping

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Thursday, October 21, 2010 09:16:12 pm Shaohua Li wrote:
> On Fri, 2010-10-22 at 10:57 +0800, Huang, Ying wrote:
> > On Fri, 2010-10-22 at 10:43 +0800, Li, Shaohua wrote:
> > > On Fri, 2010-10-22 at 04:23 +0800, Myron Stowe wrote:
> > > > ACPI's system event related IRQ handing accesses specific fixed
> > > > hardware registers; namely PM1a event, PM1b event, GPE0, and GPE1
> > > > which are declared in the FADT.  If these registers are backed by
> > > > MMIO, as opposed to I/O port space, accessing them within interrupt
> > > > context will incur a panic since acpi_read() and acpi_write() end up
> > > > calling ioremap(), which may block to allocate memory - BZ 18012.
> > > since you just access several bytes mmio in interrupt context, can't you
> > > use kmap_atomic_pfn() here?
> > 
> > On x86_64, kmap_atomic_pfn() is defined as kmap_atomic(), which requires
> > struct page for the physical address. But the MMIO address may have no
> > struct page.

I really like this idea because we could get rid of the list and
all the RCU stuff, but I don't see how to make it work yet.

On ia64 (which also uses ACPI), kmap_atomic_pfn() also requires
a struct page.  An ia64-specific version that doesn't need a struct
page would be trivial, but I still don't know how to make it work on
x86_64.

> ok, can we add a new entry in fix map and the entry is dedicated for
> mmio mapping? The ioremap list looks like a hack.

Fixmap is arch-specific and there's no ia64 implementation, so I
don't think we can use it here.

Bjorn