Re: [patch] x86, voyager: fix ioremap_nocache()

From: H. Peter Anvin
Date: Wed Apr 30 2008 - 18:43:22 EST


James Bottomley wrote:

OK, but look; this is why you broke me.

The former meaning of ioremap() was give me whatever caching the mtrrs
set up (assuming you actually have mtrrs. For voyager, we don't so it
always meant give me cached memory).


Pre-686 generations of x86 had chipset logic (KEN logic) that did the equivalent. The only change in the 686 was moving this logic into the CPU itself. So no, it didn't always mean "give me cached memory".

The change broke the QIC ioremap area because it absolutely *requires*
cached memory. It drops performance on the Q720 SCSI cards because
caching was used essentially like write combining to reduce the
unbursted traffic across the MCA bus.

When the Voyagers were designed, the only way to get them better
performace with the slow bus technology was to do a massive amount of
caching, so they're optimised to the point where every element on the
voyager bus (sort of like the intel frontside bus) is a primary
participant in the caching algorithm, and this includes the MCA
controllers. So for me, I want every invocation of ioremap to mean
ioremap_cached() otherwise I don't benefit from the added caches.

I can fully understand that bus technology has got worse in terms of
caching since the voyager heydays. However, I'd rather not be penalised
for everyone else's hardware failings. Since the old ioremap is only
used in the IORESOURCE_CACHABLE case for PCI, and since that used to
defer to the mtrr settings anyway, it probably does make sense to keep
it as ioremap_cache() as long as that still defers to the mtrr settings.

I suppose I could think about an ioremap platform override for voyager
since, by and large, ioremap_nocache() is the wrong thing on the
platform.

Sounds like it, or you should just do a global replace of ioremap() with ioremap_cache() for the Voyager drivers.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/