[RFC/PATCH] map drivers. DCACHE option for physmap and mphysmap drivers

Josh Boyer 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 mailing list