[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CLEANMARKER obsolete, last-ic cache.
> firstname.lastname@example.org 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 email@example.com