[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.

Good idea, I should probably do the same(Can't think very well, with a sore throat,
cold and a fever.

> > 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?

Hmm, that should work, but my mind isn't working too well right now.

> > 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.

Tried that, but I never got I to work properly and it was less efficient. Must have forgotten something.
I posted to the list about my tries. Anyhow my current method works great and only affects 
my map file.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com