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

[Huang Ying <ying.huang@intel.com>]

On Fri, 2010-10-22 at 11:16 +0800, Li, Shaohua 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.
> 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.

Do ioremap in atomic context is so easy. It is not only just allocating
some virtual address space, you need care about the PAT too to prevent
address is mapped both cached and uncached. Please take a look at
reserve_memtype() which is used in ioremap(). Pre-mapping makes thing
easier in fact.

Best Regards,
Huang Ying