True. Although for simplicity's sake I wasn't talking about the mapping
tricks, this was just for writing/erasing flash chips without doing any
paging - it you're mapping different chips into the same hole you need the
same cache-flush tricks even for read-only chips.
> What you want is the "memory_went_away_from_us()" kind of cache flush,
> which has nothing at all to do with cache coherency. And it should be
> explicitly and clearly named THAT
As you wish. How about:
void memory_went_away_from_us(void);
and
void memory_range_went_away_from_us(unsigned long start, unsigned long len);
Where 'start' is an ioremap cookie.
> and you should not blame the fact that x86 is always 100% cache coherent
> and that the normal cache coherency routines should _never_ be anything
> but a nop.
Indeed. That's eminently sane - it was just the nomenclature and the
documentation which was less so.
> Also note that wbinvd is known to corrupted the caches and lead to
> lockups on certain x86 cores. You need to be a _lot_ more careful than
> just doing it indiscriminately from a driver.
Yeah - but x86 isn't a particularly interesting architecture in this
context. If you can't selectively flush a range, you'll probably find that
you haven't gained enough from being able to do burst reads to offset the
cost of the complete cache flushes.
-- 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/