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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
