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 -- 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
