From: Cho KyongHo
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa
Tested-by: Grant
From: Cho KyongHo pullip@samsung.com
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa
From: Cho KyongHo
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa
Tested-by: Grant
From: Cho KyongHo pullip@samsung.com
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa
age entries
> in exynos_iommu_unmap(). Missing cache flush of removed page table
> entries can cause missing page fault interrupt when a master IP
> accesses an unmapped area.
>
> Reviewed-by: Tomasz Figa
> Tested-by: Grant Grundler
> Signed-off-by: Cho KyongHo
> ---
>
small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Tested-by: Grant Grundler grund...@chromium.org
Signed-off
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa
Tested-by: Grant Grundler
Signed-off
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Tested-by: Grant Grundler
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa
Tested-by: Grant Grundler
Signed-off
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Tested-by: Grant Grundler
On Thu, 08 Aug 2013 15:44:09 +0200, Tomasz Figa wrote:
> On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote:
> > This commit adds cache flush for removed small and large page entries
> > in exynos_iommu_unmap(). Missing cache flush of removed page table
> > entries c
On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote:
> This commit adds cache flush for removed small and large page entries
> in exynos_iommu_unmap(). Missing cache flush of removed page table
> entries can cause missing page fault interrupt when a master IP
> accesses an u
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Tested-by: Grant Grundler
Signed-off-by: Cho KyongHo
---
drivers
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Tested-by: Grant Grundler grund...@chromium.org
Signed-off-by: Cho
On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote:
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area
On Thu, 08 Aug 2013 15:44:09 +0200, Tomasz Figa wrote:
On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote:
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault
On Fri, Jul 26, 2013 at 4:26 AM, Cho KyongHo wrote:
> This commit adds cache flush for removed small and large page entries
> in exynos_iommu_unmap(). Missing cache flush of removed page table
> entries can cause missing page fault interrupt when a master IP
> accesses an u
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Signed-off-by: Cho KyongHo
---
drivers/iommu/exynos-iommu.c |2
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Signed-off-by: Cho KyongHo pullip@samsung.com
---
drivers/iommu
On Fri, Jul 26, 2013 at 4:26 AM, Cho KyongHo pullip@samsung.com wrote:
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses
On Mon, Jul 8, 2013 at 11:21 AM, Grant Grundler wrote:
> On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo wrote:
> ...
>> I am still working on the patch set when I am free.
>> Implementation of the updated patch set has been finished but not tested yet.
>>
>> I will post the patches after simple
On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo wrote:
...
> I am still working on the patch set when I am free.
> Implementation of the updated patch set has been finished but not tested yet.
>
> I will post the patches after simple test :)
Ok - thanks Cho!
If you'd like me to test, please post a
On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo pullip@samsung.com wrote:
...
I am still working on the patch set when I am free.
Implementation of the updated patch set has been finished but not tested yet.
I will post the patches after simple test :)
Ok - thanks Cho!
If you'd like me to
On Mon, Jul 8, 2013 at 11:21 AM, Grant Grundler grund...@chromium.org wrote:
On Thu, Jul 4, 2013 at 4:20 AM, Cho KyongHo pullip@samsung.com wrote:
...
I am still working on the patch set when I am free.
Implementation of the updated patch set has been finished but not tested yet.
I will
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Signed-off-by: Cho KyongHo
---
drivers/iommu/exynos-iommu.c |2
This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
Signed-off-by: Cho KyongHo pullip@samsung.com
---
drivers/iommu
all page and large page
> >> entries in exynos_iommu_unmap(). Missing cache flush of removed page
> >> table entries can cause missing page fault interrupt when a master IP
> >> accesses an unmapped area.
> >
> > KyongHo,
> > It appears this patch was never applie
in exynos_iommu_unmap(). Missing cache flush of removed page
table entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.
KyongHo,
It appears this patch was never applied and got caught up in the
device tree binding discussion. AFAICT, this patch is still
Ping?
On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler wrote:
> On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote:
>> This commit adds cache flush for removed small page and large page
>> entries in exynos_iommu_unmap(). Missing cache flush of removed
>> p
Ping?
On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler grund...@chromium.org wrote:
On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote:
This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table
-linux-arm (wrong email address - sorry)
On Mon, Jul 1, 2013 at 6:49 PM, Grant Grundler wrote:
> On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote:
>> This commit adds cache flush for removed small page and large page
>> entries in exynos_iommu_unmap(). Miss
On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote:
> This commit adds cache flush for removed small page and large page
> entries in exynos_iommu_unmap(). Missing cache flush of removed
> page table entries can cause missing page fault interrupt when a
> master
On Tuesday, December 25, 2012 6:00:01 PM UTC-8, Cho KyongHo wrote:
This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped
cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped area.
KyongHo,
It appears this patch was never applied and got caught up in the
device tree binding discussion. AFAICT, this patch is still necessary.
Can you resubmit
This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped area.
Signed-off-by: KyongHo Cho
---
drivers/iommu/exynos-iommu.c
This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped area.
Signed-off-by: KyongHo Cho pullip@samsung.com
---
drivers
This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped area.
Signed-off-by: KyongHo Cho
---
drivers/iommu/exynos-iommu.c
This commit adds cache flush for removed small page and large page
entries in exynos_iommu_unmap(). Missing cache flush of removed
page table entries can cause missing page fault interrupt when a
master IP accesses an unmapped area.
Signed-off-by: KyongHo Cho pullip@samsung.com
---
drivers
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 |
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
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
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
74 matches
Mail list logo
