AGP and ACPI are the cases which already use it. Of course if it was
x86-only code it wouldn't matter if we kept on calling it wbinvd().
The case which originally drew my attention was something which hasn't been
implemented yet - flash drivers where you need a cached mapping in order to
do burst reads from the chip, but obviously you still need to be able to
flush the cache on demand.
In fact, this is something we probably won't do on x86 - only on other
architectures. You need both cached and uncached mappings of the chip to
make this work (although often you have physical aliases so even on x86 you
can map one address cached and another uncached), and also you don't have
fine-grained flushes of selected ranges on x86 so it's likely to have a very
noticeable effect on performance - so much so that it's probably worth just
doing it all uncached in the first place.
But x86 isn't particularly interesting - it'd be useful to have a
flush_dcache_range() which actually works across other architectures anyway.
> Regardless, the purpose of the cachetlb.txt interfaces is for the
> generic VM subsystem of the kernel. Nothing more.
So they should probably have less misleading names, perchance including the
letter 'v' and the letter 'm' somewhere? And they should _certainly_ have
less misleading documentation. :)
-- dwmw2
- 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/