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
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
all 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-by: 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 Grundler
Signed-off-by
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-by
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
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
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 test
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 "
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
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 applied a
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
-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(). Missing
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
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
---
drivers/iommu/exynos-iommu.c
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
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 Commu
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
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 any
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
[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
f
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 circ
[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 t
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
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 chi
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 x8
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 era
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
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?
[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 | Echelon
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 r
37 matches
Mail list logo
