[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CLEANMARKER obsolete, last-ic cache.

joakim.tjernlund@xxxxxxx.se said:
> > 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
> function. 

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 majordomo@xxxxxxx.com