From: Joakim Tjernlund <Joakim.Tjernlund@lumentis.se>
To: linux-mtd@lists.infradead.org
Subject: Re: Fwd: Cache mappings and invalidate
Date: Mon, 26 Nov 2001 10:08:05 +0200 [thread overview]
Message-ID: <0111260908050D.28381@jocke.lumentis.se> (raw)
In-Reply-To: <0111131653040B.28381@jocke.lumentis.se>
Hi all
Finally I got to enable burst read from flash, but my tests shows no performance gain.
There is no difference when I mont my JFFS2 FS or
if I do 'cp /dev/mtdblock4 /dev/null' or 'cp /dev/mtd4 /dev/null'. Even
if I remove the dma_cache_inv() call there is no performance gain.
It is almost like burst reads are disabled, but if I mess with the burst HW init sequence,
I get a lot of errors, so I take it that burst reads are enabled.
I have a custom MPC860 board(4k icache, 4k dcache) running at 80 MHz
(bus is 40 Mhz), 128 MB Ram.
Any Ideas?
Jocke
On Tuesday 13 November 2001 16:53, Joakim Tjernlund wrote:
> Hi again
>
> I did some changes since the first attempt didn't work very well. I
> removed the changes in cfi_cmdset_0001.c and changed the copy_from()
> function to:
>
> void lumentis_copy_from(struct map_info *map, void *to, unsigned long from,
> ssize_t len) {
> #ifdef USE_DCACHE
> dma_cache_inv(map->map_priv_2 + from, len);
> memcpy_fromio(to, (void *)(map->map_priv_2 + from), len);
> #else
> memcpy_fromio(to, (void *)(map->map_priv_1 + from), len);
> #endif
> }
>
> This seems to work(no CRC errors so far) and has no visible impact on
> performance. When I get around to enable burst reads form my flash I hope
> to see a performance gain.
>
> Anybody care to comment on my experiment so far?
>
> Jocke
>
> ---------- Forwarded Message ----------
> Subject: Cache mappings and invalidate
> Date: Mon, 12 Nov 2001 14:14:14 +0200
> From: Joakim Tjernlund <Joakim.Tjernlund@lumentis.se>
> To: linux-mtd@lists.infradead.org
>
>
> Hi all
>
> I am trying to make copy_from use cahced memory by assignig
> map_priv_2 = (unsigned long)__ioremap(flash_addr, flash_size, 0);
> and then change copy_from routine to:
> +#ifndef NO_CACHE
> + memcpy_fromio(to, (void *)(map->map_priv_2 + from), len);
> +#else
> memcpy_fromio(to, (void *)(map->map_priv_1 + from), len);
> +#endif
>
> There are no cache invalidations in my map file, instead I have
> added invalidate_dcache_range() calls to
> drivers/mtd/chips/cfi_cmdset_0001.c(see below) in do_write_oneword(),
> do_write_buffer() and do_erase_oneblock(). Note that this is just a quick
> hack to try out my theory. Does this look sane or should I use another
> invalidate_dcache_range() and/or place the invalidate calls somewhere
> else?
>
> I am not using burst reads yet, that will come later once i have gotten the
> cached mapping to work.
>
> Joakim
>
>
>
> --- drivers/mtd/chips/cfi_cmdset_0001.c 2001/10/25 12:11:10 1.3
> +++ drivers/mtd/chips/cfi_cmdset_0001.c 2001/11/12 12:02:33
> @@ -502,6 +502,10 @@
> cfi_udelay(chip->word_write_time);
> spin_lock_bh(chip->mutex);
>
> +#ifndef NO_CACHE
> + invalidate_dcache_range(map->map_priv_2 + adr, map->map_priv_2 +
> adr + 4); /* on a 32 bit bus */ +#endif
> +
> timeo = jiffies + (HZ/2);
> z = 0;
> for (;;) {
> @@ -691,7 +695,7 @@
> wbufsize = CFIDEV_INTERLEAVE << cfi->cfiq->MaxBufWriteSize;
> adr += chip->start;
> cmd_adr = adr & ~(wbufsize-1);
> -
> +
> /* Let's determine this according to the interleave only once */
> status_OK = CMD(0x80);
>
> @@ -790,6 +794,10 @@
> cfi_udelay(chip->buffer_write_time);
> spin_lock_bh(chip->mutex);
>
> +#ifndef NO_CACHE
> + invalidate_dcache_range(map->map_priv_2 + adr, map->map_priv_2 +
> adr + len); +#endif
> +
> timeo = jiffies + (HZ/2);
> z = 0;
> for (;;) {
> @@ -994,6 +1002,10 @@
> spin_unlock_bh(chip->mutex);
> schedule_timeout(HZ);
> spin_lock_bh(chip->mutex);
> +
> +#ifndef NO_CACHE
> + invalidate_dcache_range(map->map_priv_2 + adr, map->map_priv_2 +
> adr + 0x40000); /* 0x40000 is my erase size */
> +#endif
>
> /* FIXME. Use a timer to check this, and return immediately. */
> /* Once the state machine's known to be working I'll do that */
>
> -------------------------------------------------------
next prev parent reply other threads:[~2001-11-26 7:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-13 15:53 Fwd: Cache mappings and invalidate Joakim Tjernlund
2001-11-13 16:08 ` David Woodhouse
2001-11-13 17:05 ` Joakim Tjernlund
2001-11-13 17:09 ` David Woodhouse
2001-11-14 1:15 ` Bjorn Wesen
2001-11-13 23:35 ` David Woodhouse
2001-11-26 8:08 ` Joakim Tjernlund [this message]
2001-11-27 11:07 ` David Woodhouse
2001-11-27 12:58 ` Joakim Tjernlund
2001-12-01 9:36 ` David Woodhouse
2001-12-03 10:24 ` Joakim Tjernlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0111260908050D.28381@jocke.lumentis.se \
--to=joakim.tjernlund@lumentis.se \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox