Messages in this thread | | | Date | Sun, 27 Apr 2008 16:14:15 -0700 | From | Arjan van de Ven <> | Subject | Re: [patch] x86, voyager: fix ioremap_nocache() |
| |
On Sun, 27 Apr 2008 19:02:05 -0400 Jeff Garzik <jeff@garzik.org> wrote:
> H. Peter Anvin wrote: > > Jeff Garzik wrote: > >> > >> Understood. > >> > >> I guess I am more annoyed that this stealth semantics change > >> appears to have broken everything that depends on pci_iomap(), > >> including 90%+ of all libata drivers, unless I am missing > >> something. > >> > >> That one piece of code (pci_iomap) was correct under the old > >> semantics, on x86 and elsewhere. It's tested and working nicely, > >> and depended upon by many drivers. > >> > > > > That one piece of code has had no effective change. Under both the > > old and the new code, both branches functionally because > > ioremap_nocache(), in one case because of MTRR and in one case > > because of PAT. > > OK good... libata uses it for controller registers exclusively, so > that should be fine from an operational standpoint. > > at the very least I > could have pointed out that lib/iomap.c wanted an update, and the 2.5 > yo discussion could have resurfaced. >
btw as a technical point: ioremap_cached() isn't guaranteed to give you cached memory. In fact, on a PC, if you use ioremap_cached() on PCI bars, you will STILL get uncached access, just because right now, it's not possible to give a cached mapping out!
We might want to try to change that in the future (by rewriting the MTRRs), but that would need a LOT of auditing of ioremap (ab)users to make sure they actually mean "cached" when they ask for cached (pci_iomap... I'm not convinced it's users really can deal with cached) and it also will take a LOT of testing.
-- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org
| |