James Bottomley wrote:
quoted text
> 
> 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".

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/