[RFC/PATCH] map drivers. DCACHE option for physmap and mphysmap drivers
jwboyer at gmail.com
Fri Jan 27 14:51:14 EST 2006
On 1/27/06, Jared Hulbert <jaredeh at gmail.com> wrote:
> > > Is this a read-only caching? I know several architectures and
> > > hardware configurations that would quickly throw a machine check if
> > > trying to flush the cache back to flash since they don't support
> > > bursted writes.
> > >
> > In general case not. I've never heard about the such issue. Is there
> > any way to define has platform flash devices with bursted writes or not?
> > What architectures have this problem?
> When I first did a patch like this I used a very platform dependent
> embedded assembly loop to _invalidate_ NOT _flush_ the specific
> cachelines possibly affected by the flash program or erase.
Yep, that would be better.
> In this case the point is the flash was changed by a program or erase
> that does not change the state of possible contents of the cache so
> the flash and cache are out of sync. We don't care what the cache
> contents that point to the affected regions of cache are, we don't
> ever want to read them again, so we mark them as invalid and wait for
> those lines to be replaced.
> Flushing the caches back _could_ be a very bad thing, it could cause
> flash to do many bad things because you would be write arbitrary data
> back to the flash bus. I'm not sure why it would machine check. If
> your processor was configured properly I'm not sure why flushing would
> trigger burst writes to a memory not capable of bursting, but then
> hardware can have its mysterious ways. Either way you would likely do
I didn't say it was sane hardware :). But some ppc 4xx boards can't
handle bursted writes to the EBCs. I'm not sure if they've all been
fixed out there or not.
> bad things to the flash by flushing garbage back to it. However, from
> a higher level look at it you should never be writing directly to the
> cached mapping of flash as only the mtd really knows about it and only
> uses it read. Therefore the cachelines are always clean and don't get
> written back so it's not really a problem.
I agree. As long as things are getting invalidated instead of
flushed, then there should be no issue. flushing == bad, invalidating
== sane :)
More information about the linux-mtd