* Re: Missing cache flush.
From: Vipin Malik @ 2001-06-05 14:22 UTC (permalink / raw)
To: Bjorn Wesen; +Cc: David Woodhouse, linux-kernel, linux-mtd
In-Reply-To: <Pine.LNX.4.21.0106051105110.1078-100000@godzilla.axis.se>
Bjorn Wesen wrote:
>
> I'd agree that to be really certain, a "flush_dcache()" function
> should be implemented and used when an erase finishes. Like David Miller
> wrote somewhere in the thread, one way is to use your knowledge of the
> arch's cache and do suitable dummy accesses to flush it, if there is no
> explicit command to do it. But that's just up to the arch coders..
>
Here's a stupid question: Are there any processors out there that have a cache
but no explicit cache-flush command?
If not (i.e. no such "funny" processors), then what's wrong with the arch
dependent include through a define to execute the
arch specific asm command?
The only issue (besides knowing the cache size at run time) that I can think
about the "dummy" eviction scheme is that you now need to xfer potentially 3
times the cache
size data to and from memory:
#1. The dummy read
#2. The eviction of the entire cache data being evicted
#3. The refilling of the cache with good data again, as the dummy data cannot
really represent anything useful.
Is my thinking here completely non coherent with others? ;)
Vipin
^ permalink raw reply
* success with JFFS2 as root filesystem on YOPY
From: Daniel R Risacher @ 2001-06-05 13:32 UTC (permalink / raw)
To: Yopy-general; +Cc: linux-mtd
I just thought I'd mention that I did manage to get the YOPY to boot
with JFFS2 as the root filesystem with the 2.4.2-yopy1 kernel (which
is based on 2.4.2-rmk2-np2). I needed to modify mtd/sa1100-flash.c to
use all the available flash space on the device.
--
"If I have been able to see further,
it was only because I was surrounded by dwarves."
-- Risto A. Paju
Daniel Risacher magnus@alum.mit.edu
^ permalink raw reply
* Re: erasesize
From: David Woodhouse @ 2001-06-05 13:12 UTC (permalink / raw)
To: Frederic Giasson; +Cc: Abraham vd Merwe, MTD for Linux
In-Reply-To: <F1BED55F35F4D3118C0F00E0295CFF4D995484@mail.mediatrix.com>
fgiasson@mediatrix.com said:
> ... Maybe it should be passed through the arg pointer in the ioctl(),
> in a 2 u_long sized structure?
I don't fully understand the question. The 'len' member of the struct
erase_info contains the total length of the erase requested by the user of
the MTD device. The only connexion with the device's erase size(s) is that
obviously the range to be erase must start and end on an eraseblock
boundary.
cfi_amdstd_erase_varsize() is an internal function intended to issue the
magic erase commands only to a certain address on the chip - it doesn't
know anything about the erase size at that address, or care about the
length field, does it?
--
dwmw2
^ permalink raw reply
* RE: erasesize
From: Frederic Giasson @ 2001-06-05 13:03 UTC (permalink / raw)
To: Frederic Giasson, 'David Woodhouse', Abraham vd Merwe
Cc: MTD for Linux
... Maybe it should be passed through the arg pointer in the
ioctl(), in a 2 u_long sized structure?
Frédéric Giasson
-----Original Message-----
From: Frederic Giasson [mailto:fgiasson@mediatrix.com]
Sent: Tuesday, June 05, 2001 8:49 AM
To: 'David Woodhouse'; Abraham vd Merwe
Cc: MTD for Linux
Subject: RE: erasesize
I have a question too about the erase->len ( erasesize ). I have a
flash chip with variable block sizes, and I am using cfi_cmdset_0002. Where
should that ->len be set? When I printk the value held by erase->len just
before calling do_erase_oneblock() in cfi_amdstd_erase_varsize(), I get a
dummy value. I suspect that it should be set according to the
mtd_erase_region_info structure, but it is not done.
Does anyone has a clue about it?
Thanks!
Frédéric Giasson
-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tuesday, June 05, 2001 8:30 AM
To: Abraham vd Merwe
Cc: MTD for Linux
Subject: Re: erasesize
abraham@2d3d.co.za said:
> What should I set erasesize to when the flash chips have multiple
> erase sizes (and therefor I use eraseregions to get erasesize info)?
> Is 0 acceptable or should I set it to something else - it doesn't
> really make sense to put any value in this after all...
See the other Intel driver. Set the erase size to the 'major' erase size
for the device, then fill in the appropriate structure to represent the
other regions.
--
dwmw2
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* RE: erasesize
From: Frederic Giasson @ 2001-06-05 12:49 UTC (permalink / raw)
To: 'David Woodhouse', Abraham vd Merwe; +Cc: MTD for Linux
I have a question too about the erase->len ( erasesize ). I have a
flash chip with variable block sizes, and I am using cfi_cmdset_0002. Where
should that ->len be set? When I printk the value held by erase->len just
before calling do_erase_oneblock() in cfi_amdstd_erase_varsize(), I get a
dummy value. I suspect that it should be set according to the
mtd_erase_region_info structure, but it is not done.
Does anyone has a clue about it?
Thanks!
Frédéric Giasson
-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tuesday, June 05, 2001 8:30 AM
To: Abraham vd Merwe
Cc: MTD for Linux
Subject: Re: erasesize
abraham@2d3d.co.za said:
> What should I set erasesize to when the flash chips have multiple
> erase sizes (and therefor I use eraseregions to get erasesize info)?
> Is 0 acceptable or should I set it to something else - it doesn't
> really make sense to put any value in this after all...
See the other Intel driver. Set the erase size to the 'major' erase size
for the device, then fill in the appropriate structure to represent the
other regions.
--
dwmw2
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: Missing cache flush.
From: David Woodhouse @ 2001-06-05 12:52 UTC (permalink / raw)
To: David S. Miller
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <15132.54565.311995.865807@pizda.ninka.net>
davem@redhat.com said:
> How about flush_cache_range_force() instead?
> I want something in the name that tells the reader "this flushes the
> caches, even though under every other ordinary circumstance you would
> not need to".
OL, then. I would have thought it made more sense to have the
flush_dcache_range() unconditionally do what its name implies, and to have a
separate flush_dcache_range_for_dma() function which is optional. But that
decision was already made - I suppose we can't change the semantics now.
--
dwmw2
^ permalink raw reply
* Re: Missing cache flush.
From: David S. Miller @ 2001-06-05 12:48 UTC (permalink / raw)
To: David Woodhouse
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <14071.991744970@redhat.com>
David Woodhouse writes:
> > Call it flush_ecache_full() or something.
>
> Strange name. Why? How about __flush_cache_range()?
How about flush_cache_range_force() instead?
I want something in the name that tells the reader "this flushes the
caches, even though under every other ordinary circumstance you would
not need to".
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: Missing cache flush.
From: David Woodhouse @ 2001-06-05 12:42 UTC (permalink / raw)
To: David S. Miller
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <15132.41562.879696.484467@pizda.ninka.net>
davem@redhat.com said:
> David Woodhouse writes:
> > What shall we call this function? The intuitive "flush_dcache_range"
> > appears to have already been taken.
> Call it flush_ecache_full() or something.
Strange name. Why? How about __flush_cache_range()?
--
dwmw2
^ permalink raw reply
* Re: erasesize
From: David Woodhouse @ 2001-06-05 12:30 UTC (permalink / raw)
To: Abraham vd Merwe; +Cc: MTD for Linux
In-Reply-To: <20010605125233.A31929@crystal.2d3d.co.za>
abraham@2d3d.co.za said:
> What should I set erasesize to when the flash chips have multiple
> erase sizes (and therefor I use eraseregions to get erasesize info)?
> Is 0 acceptable or should I set it to something else - it doesn't
> really make sense to put any value in this after all...
See the other Intel driver. Set the erase size to the 'major' erase size
for the device, then fill in the appropriate structure to represent the
other regions.
--
dwmw2
^ permalink raw reply
* erasesize
From: Abraham vd Merwe @ 2001-06-05 10:52 UTC (permalink / raw)
To: MTD for Linux
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
Hi!
What should I set erasesize to when the flash chips have multiple erase
sizes (and therefor I use eraseregions to get erasesize info)? Is 0
acceptable or should I set it to something else - it doesn't really make
sense to put any value in this after all...
--
Regards
Abraham
Will Rogers never met you.
__________________________________________________________
Abraham vd Merwe - 2d3D, Inc.
Device Driver Development, Outsourcing, Embedded Systems
Cell: +27 82 565 4451 Snailmail:
Tel: +27 21 761 7549 Block C, Antree Park
Fax: +27 21 761 7648 Doncaster Road
Email: abraham@2d3d.co.za Kenilworth, 7700
Http: http://www.2d3d.com South Africa
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Missing cache flush.
From: Johan Adolfsson @ 2001-06-05 9:43 UTC (permalink / raw)
To: David Woodhouse, David S. Miller
Cc: Chris Wedgwood, Jeff Garzik, bjorn.wesen, linux-kernel, linux-mtd
In-Reply-To: <25587.991730769@redhat.com>
Possibly saying something extremly stupid here,
how about simply "fakewriting" 0xFF to the flash
after an erase to update any caches?
> 2. Flash. A few writes of magic data to magic addresses and a whole erase
> block suddenly contains 0xFF. The CPU doesn't notice that either.
do_erase_stuff();
/* While verifying, update cache */
for (address = adr; address < (adr + size); address++) {
if ((verify = map->read8(map, address)) != 0xFF) {
error = 1;
break;
}
/* "Fake" write 0xFF's to the erased sector so that
caches are updated
* after we verified that uncached data is ok
*/
*(unsigned char*)CACHED(address) = 0xFF;
}
/Johan
^ permalink raw reply
* Re: Missing cache flush.
From: kira brown @ 2001-06-05 9:29 UTC (permalink / raw)
To: David Woodhouse
Cc: David S. Miller, Chris Wedgwood, Jeff Garzik, bjornw,
linux-kernel, linux-mtd
In-Reply-To: <25587.991730769@redhat.com>
On Tue, 5 Jun 2001, David Woodhouse wrote:
>
> davem@redhat.com said:
> > Chris Wedgwood writes:
> > > What if the memory is erased underneath the CPU being aware of
> > > this? In such a way ig generates to bus traffic...
>
> > This doesn't happen on x86. The processor snoops all transactions
> > done by other agents to/from main memory. The processor caches are
> > always up to date.
>
> No. My original mail presented two situations in which this assumption is
> false.
>
> 1. Bank-switched RAM. You want to force a writeback before switching pages.
> I _guarantee_ you that the CPU isn't snooping my access to the I/O port
> which sets the latch that drives the upper few address bits of the RAM
> chips.
>
> 2. Flash. A few writes of magic data to magic addresses and a whole erase
> block suddenly contains 0xFF. The CPU doesn't notice that either.
3. Buggy implementations like the Cyrix 486es that don't properly maintain
cache coherency.
kira.
^ permalink raw reply
* Re: Missing cache flush.
From: Bjorn Wesen @ 2001-06-05 9:17 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, linux-mtd
In-Reply-To: <13942.991696607@redhat.com>
On Tue, 5 Jun 2001, David Woodhouse wrote:
> The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached
> mapping of the flash chips for bulk reads, but obviously an uncached mapping
> for sending commands and reading status when we're actually writing to or
> erasing parts of the chip.
>
> However, it fails to flush the dcache for the range used when the flash is
> accessed through the uncached mapping. So after an erase or write, we may
> read old data from the cache for the changed area.
I'll start by saying that axisflashmap.c was not meant to be used by any
other archs, that's why it's in arch/cris. But if anyone find it useful,
that's great. Just be aware that it's not _designed_ for general use and
something like this might be just what that might mean.
CRIS is cache coherent just like the x86 cache and does not need any
explicit cache flushes for the write case. Even when doing cache bypass
writing, if a cacheline already exist with the referenced memory, the
cacheline is updated.
In the erase case though, yes there should be a flush. However during the
1-2 seconds it takes to erase a sector, you can with very high certainity
guarantee that the direct-mapped unified 8 kB cache on the CRIS is
flushed from any flash references at all.. I mean, it's one-way
associative, during 1-2 seconds it executes potentially 200 million
instructions. So we haven't really bothered to think about the problem..
For other CPU's it might be more dangerous, although I don't hold my
breath.. 1-2 seconds is a long time when talking about L1 caches.
> However, I can't see a cache operation which performs this function.
> flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most
> architectures. On other architectures, there's dma_cache_wback_inv(), but
> that also seems to be a NOP on i386, to pick a random example.
I'd agree that to be really certain, a "flush_dcache()" function
should be implemented and used when an erase finishes. Like David Miller
wrote somewhere in the thread, one way is to use your knowledge of the
arch's cache and do suitable dummy accesses to flush it, if there is no
explicit command to do it. But that's just up to the arch coders..
-bw
^ permalink raw reply
* Re: Missing cache flush.
From: David S. Miller @ 2001-06-05 9:11 UTC (permalink / raw)
To: David Woodhouse
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <25831.991731935@redhat.com>
David Woodhouse writes:
> What shall we call this function? The intuitive "flush_dcache_range" appears
> to have already been taken.
Call it flush_ecache_full() or something.
Many architectures need to implement this anyways if they have
parity error exception handling. Most platforms sadly do not.
Sparc64 is one of the exceptions here...
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: Missing cache flush.
From: David Woodhouse @ 2001-06-05 9:05 UTC (permalink / raw)
To: David S. Miller
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <15132.40298.80954.434805@pizda.ninka.net>
davem@redhat.com said:
> One way to do this, (even portably :-) is via displacement flushes.
> Linus mentioned this.
> Basically if you know the L2 cache size and the assosciativity you can
> do this as long as you can get a "2 * L2 cache size * assosciativity"
> piece of contiguous physical memory. When you need this "simon says"
> flush, you basically read this physical memory span and this will
> guarentee that all dirty data has exited the L2 cache.
Fine. So it should be possible to do it on all architectures with
physically-indexed caches - that's good. Architectures with
virtually-indexed caches are going to have explicit cache management
functionality anyway, presumably :)
Obviously the algorithm you describe should not be implemented in
arch-independent drivers. It should be in include/asm-*, for those
architectures which _can't_ do it with a single cache management instruction
(or loop of same).
What shall we call this function? The intuitive "flush_dcache_range" appears
to have already been taken.
--
dwmw2
^ permalink raw reply
* Re: acceptable chip driver limitations
From: David Woodhouse @ 2001-06-05 9:00 UTC (permalink / raw)
To: Abraham vd Merwe; +Cc: MTD for Linux
In-Reply-To: <20010605105729.A26674@crystal.2d3d.co.za>
abraham@2d3d.co.za said:
> No, I'm talking about mtd->read() and mtd->write. Surely they can
> return errors? If not, what about physical write/read errors?
Sorry, I misunderstood. No, that is not acceptable. You must accept
unaligned and odd-sized writes. You can just special-case the first and
last read/write cycles, padding writes with 0xFF. See how the existing
driver for Intel chips does it.
--
dwmw2
^ permalink raw reply
* Re: acceptable chip driver limitations
From: Abraham vd Merwe @ 2001-06-05 8:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: MTD for Linux
In-Reply-To: <25630.991730918@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
Hi David!
> > Is it allright if my chip driver read/write's only accept 32-bit to/
> > from/len's?
>
> > I.e. if I return with -EINVAL if somebody tries to read/write a single
> > byte or tries to read from a non-dword boundary, is that acceptable or
> > should the driver cater for word/byte read/writes as well?
>
> Leave them NULL. You can't return an error value from them - there's no
> possible value you can return that isn't a valid return from an actual read.
>
> They should never get called is the buswidth doesn't match them.
No, I'm talking about mtd->read() and mtd->write. Surely they can return
errors? If not, what about physical write/read errors?
--
Regards
Abraham
Visit beautiful Vergas, Minnesota.
__________________________________________________________
Abraham vd Merwe - 2d3D, Inc.
Device Driver Development, Outsourcing, Embedded Systems
Cell: +27 82 565 4451 Snailmail:
Tel: +27 21 761 7549 Block C, Antree Park
Fax: +27 21 761 7648 Doncaster Road
Email: abraham@2d3d.co.za Kenilworth, 7700
Http: http://www.2d3d.com South Africa
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Missing cache flush.
From: David S. Miller @ 2001-06-05 8:50 UTC (permalink / raw)
To: David Woodhouse
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <25587.991730769@redhat.com>
David Woodhouse writes:
> What I want is a function like simon_says_flush_page_to_ram(). In
> this case, I _do_ know better than the CPU. It is _not_ coherent
> with these devices.
One way to do this, (even portably :-) is via displacement flushes.
Linus mentioned this.
Basically if you know the L2 cache size and the assosciativity you can
do this as long as you can get a "2 * L2 cache size * assosciativity"
piece of contiguous physical memory. When you need this "simon says"
flush, you basically read this physical memory span and this will
guarentee that all dirty data has exited the L2 cache.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: Missing cache flush.
From: David Woodhouse @ 2001-06-05 8:46 UTC (permalink / raw)
To: David S. Miller
Cc: Chris Wedgwood, Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <15132.22933.859130.119059@pizda.ninka.net>
davem@redhat.com said:
> Chris Wedgwood writes:
> > What if the memory is erased underneath the CPU being aware of
> > this? In such a way ig generates to bus traffic...
> This doesn't happen on x86. The processor snoops all transactions
> done by other agents to/from main memory. The processor caches are
> always up to date.
No. My original mail presented two situations in which this assumption is
false.
1. Bank-switched RAM. You want to force a writeback before switching pages.
I _guarantee_ you that the CPU isn't snooping my access to the I/O port
which sets the latch that drives the upper few address bits of the RAM
chips.
2. Flash. A few writes of magic data to magic addresses and a whole erase
block suddenly contains 0xFF. The CPU doesn't notice that either.
What I want is a function like simon_says_flush_page_to_ram(). In this
case, I _do_ know better than the CPU. It is _not_ coherent with these
devices.
I'm actually working on a MIPS box at the moment - the particular problems
with doing it on i386 don't interest me too much. To be honest, I could do
it by sticking asm instructions inside ifdefs in what is otherwise
arch-independent code. I'd rather not do it like that, though.
Surely stuff like that should be exported by the arch-specific code or
include files somehow. Possibly with a #define or function I can use to tell
whether a selective flush is actually available on the current CPU. If it's
not possible to flush the dcache selectively, then the cost of doing a full
flush probably outweighs the benefit¹ of running the flash cached in the
first place. But it should still be possible to do it from arch-independent
code without manually inserting asm instructions to do it.
--
dwmw2
¹ The _assumed_ benefit, admittedly. I should get some benchmarks to back up
the comment about molasses in arch/cris/drivers/axisflashmap.c
^ permalink raw reply
* acceptable chip driver limitations
From: Abraham vd Merwe @ 2001-06-05 8:42 UTC (permalink / raw)
To: MTD for Linux
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
Hi!
Is it allright if my chip driver read/write's only accept 32-bit
to/from/len's?
I.e. if I return with -EINVAL if somebody tries to read/write a single byte
or tries to read from a non-dword boundary, is that acceptable or should the
driver cater for word/byte read/writes as well?
If this is the case, it complicates things a lot because for instance in my
case the flash device can only handle 32-bit read/write's and smaller
accesses will have to be emulated.
--
Regards
Abraham
First study the enemy. Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2
__________________________________________________________
Abraham vd Merwe - 2d3D, Inc.
Device Driver Development, Outsourcing, Embedded Systems
Cell: +27 82 565 4451 Snailmail:
Tel: +27 21 761 7549 Block C, Antree Park
Fax: +27 21 761 7648 Doncaster Road
Email: abraham@2d3d.co.za Kenilworth, 7700
Http: http://www.2d3d.com South Africa
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Missing cache flush.
From: David S. Miller @ 2001-06-05 4:01 UTC (permalink / raw)
To: Chris Wedgwood
Cc: Jeff Garzik, David Woodhouse, bjornw, linux-kernel, linux-mtd
In-Reply-To: <20010605155550.C22741@metastasis.f00f.org>
Chris Wedgwood writes:
> On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote:
>
> The x86 doesn't have dumb caches, therefore it really doesn't
> need to flush anything. Maybe a mb(), but that is it.
>
> What if the memory is erased underneath the CPU being aware of this?
> In such a way ig generates to bus traffic...
This doesn't happen on x86. The processor snoops all transactions
done by other agents to/from main memory. The processor caches are
always up to date.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: Missing cache flush.
From: David S. Miller @ 2001-06-05 2:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: Jeff Garzik, bjornw, linux-kernel, linux-mtd
In-Reply-To: <14147.991697362@redhat.com>
David Woodhouse writes:
> > What should it do on i386? mb()?
>
> For it to have any use in the situation I described, it would need to
> writeback and invalidate the dcache for the affected range. It doesn't seem
> to do so, so it seems that it isn't what I require.
It only needs to do that on cpus where the cache is not consistent
with the rest of the system. x86 caches are fully consistent with the
rest of the system, thus no flushing necessary.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: Missing cache flush.
From: David S. Miller @ 2001-06-05 2:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Woodhouse, bjornw, linux-kernel, linux-mtd
In-Reply-To: <3B1C1872.8D8F1529@mandrakesoft.com>
Jeff Garzik writes:
> David Woodhouse wrote:
> > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very
> > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on
> > i386 shows that it doesn't do what's required anyway.
>
> What should it do on i386? mb()?
The x86 doesn't have dumb caches, therefore it really doesn't need to
flush anything. Maybe a mb(), but that is it.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: Missing cache flush.
From: David Woodhouse @ 2001-06-04 23:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bjornw, linux-kernel, linux-mtd
In-Reply-To: <3B1C1872.8D8F1529@mandrakesoft.com>
jgarzik@mandrakesoft.com said:
> > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem
> > very helpful - it's very PCI-specific, and a quick perusal of
> > pci_dma_sync() on i386 shows that it doesn't do what's required anyway.
> What should it do on i386? mb()?
For it to have any use in the situation I described, it would need to
writeback and invalidate the dcache for the affected range. It doesn't seem
to do so, so it seems that it isn't what I require.
The situation is simple - I have a paged RAM setup and I need it cached.
All I want to do is flush and invalidate the cache when I'm about to waggle
whatever I/O ports I waggle to change pages.
There are other situations in which I need the cache flushed, but the above
is one of the simplest.
Even flush_page_to_ram() doesn't seem to do what its name implies, on most
architectures.
--
dwmw2
^ permalink raw reply
* Re: Missing cache flush.
From: Jeff Garzik @ 2001-06-04 23:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: bjornw, linux-kernel, linux-mtd
In-Reply-To: <13942.991696607@redhat.com>
David Woodhouse wrote:
> I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very
> helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on
> i386 shows that it doesn't do what's required anyway.
What should it do on i386? mb()?
--
Jeff Garzik | Echelon words of the day, from The Register:
Building 1024 | FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26
MandrakeSoft | Steak Knife Kill the President anarchy echelon
| nuclear assassinate Roswell Waco World Trade Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox