David S. Miller writes:
> 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
David S. Miller writes:
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
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote:
> I don't know about the CRIS (never heard of it, what is it?)
I wondered about that too. From Documentation/cris:
What is CRIS ?
--
CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU
architecture in Axis
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote:
> > - even when it works, it is necessarily very very very slow. Not to be
> >used lightly. As you can imagine, the work-around is even slower.
>
> i've measured it once, IIRC it was around 10-15 millisecs on normal
> pentiums,
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote:
> I don't know about the CRIS (never heard of it, what is it?), but on
> an Athlon when benchmarking stuff, I could still see L1 cache hits
> from data that was 15 seconds old under certain work-loads (obviously
> not gcc!). Does
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,
[EMAIL PROTECTED] 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
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
[EMAIL PROTECTED] 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
-
To unsubscribe from
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.
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
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
On 4 Jun 2001, Linus Torvalds wrote:
> - even when it works, it is necessarily very very very slow. Not to be
>used lightly. As you can imagine, the work-around is even slower.
i've measured it once, IIRC it was around 10-15 millisecs on normal
pentiums, so while it's indeed the slowest
On 4 Jun 2001, Linus Torvalds wrote:
- even when it works, it is necessarily very very very slow. Not to be
used lightly. As you can imagine, the work-around is even slower.
i've measured it once, IIRC it was around 10-15 millisecs on normal
pentiums, so while it's indeed the slowest x86
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.
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();
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
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote:
I don't know about the CRIS (never heard of it, what is it?), but on
an Athlon when benchmarking stuff, I could still see L1 cache hits
from data that was 15 seconds old under certain work-loads (obviously
not gcc!). Does anyone
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote:
- even when it works, it is necessarily very very very slow. Not to be
used lightly. As you can imagine, the work-around is even slower.
i've measured it once, IIRC it was around 10-15 millisecs on normal
pentiums, so while
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote:
I don't know about the CRIS (never heard of it, what is it?)
I wondered about that too. From Documentation/cris:
What is CRIS ?
--
CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU
architecture in Axis
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
-
To unsubscribe from this
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
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
In article <[EMAIL PROTECTED]>,
Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>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
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
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
[EMAIL PROTECTED] 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
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 |
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
[EMAIL PROTECTED] 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
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()?
In article [EMAIL PROTECTED],
Chris Wedgwood [EMAIL PROTECTED] wrote:
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
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
34 matches
Mail list logo
