On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> wrote:
> so the culprit appears to be:
>
> b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> commit b705120e4198315f4ae043de06c62f65e0851fd3
> Author: Michael Karcher <kernel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: Sun Jan 23 18:17:17 2011 +0000
>
> drm/i915: Use consistent mappings for OpRegion between ACPI and i915
>
> The opregion is a shared memory region between ACPI and the graphics
> driver. As the ACPI mapping has been changed to cachable in commit
> 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> non-cachable now fails. As no bus-master hardware is involved in the
> opregion, cachable map should do no harm.
>
> Tested on a Fujitsu Lifebook P8010.
>
> Signed-off-by: Michael Karcher <kernel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> [ickle: convert to acpi_os_ioremap for consistency]
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>
>
> thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..42108ab 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
- return ioremap_cache(phys, size);
+ return ioremap_wc(phys, size);
}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
fix your boot issue or do we need to go back to using uncached:
+ return ioremap(phys, size);
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
