[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLEANMARKER obsolete, last-ic cache.
> > What I think I'll do next is preread the whole erase block at the
> > beginning of jffs2_scan_eraseblock() instead of reading it all in
> > little pieces to little buffers. In jffs2_scan_medium() we can
> > vmalloc() an eraseblock-sized space for this. I don't think that's
> > too evil.
> Hmm, I have 256KB EB, but also plenty of RAM. This would probably be
> an improvement.
Given up on that for today - not awake enough. I'm looking at merging the
mess that 2.5 made of my code and doing pre-allocated zlib workspaces.
> no, not a direct pointer. That will bust my Burst Read.
Why? When you get a 'point' request, you have to lock the chip so nobody
else can write/erase anyway, till the 'unpoint'. Isn't it sufficient just
to return a cached mapping to the chip?
> Right now I invalidate the data cache, for the address range in question,
> before the copyfrom() call. I think there has to be some sort of wrapper
One way to do it is to set a flag on any word write, and in copy_from you
flush only if the flag is set. A slightly better way might be to educate
the chip driver about caches, and have it pass a flag to copy_from() if a
cache flush is required.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org