From: Kevin Cernekee <cernekee@gmail.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: <macro@linux-mips.org>, <skuribay@pobox.com>,
<raiko@niisi.msk.ru>, <linux-mips@linux-mips.org>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH v2 1/6] MIPS: Sync after cacheflush on BMIPS processors
Date: Thu, 13 Jan 2011 17:52:12 -0800 [thread overview]
Message-ID: <491015d51e5d3d36c517da09e038ecaf@localhost> (raw)
On BMIPS processors, cache writeback operations may complete before the
data has actually been written out to memory. Subsequent uncached reads
(or I/O operations) may see stale data unless a sync instruction is
executed after the writeback loop.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/include/asm/hazards.h | 21 +++++++++++++++++++++
arch/mips/mm/c-r4k.c | 5 +++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/asm/hazards.h b/arch/mips/include/asm/hazards.h
index 4e33216..655da05 100644
--- a/arch/mips/include/asm/hazards.h
+++ b/arch/mips/include/asm/hazards.h
@@ -270,4 +270,25 @@ ASMMACRO(disable_fpu_hazard,
)
#endif
+/*
+ * Some processors will "pipeline" cache writeback operations, and need an
+ * extra sync instruction to ensure that they are actually flushed out to
+ * memory. Performing an uncached read (or an I/O operation) without the
+ * flush may cause stale data to be fetched.
+ */
+
+#if defined(CONFIG_CPU_BMIPS3300) || defined(CONFIG_CPU_BMIPS4350) || \
+ defined(CONFIG_CPU_BMIPS4380) || defined(CONFIG_CPU_BMIPS5000)
+
+#define cacheflush_hazard() \
+do { \
+ __sync(); \
+} while (0)
+
+#else
+
+#define cacheflush_hazard() do { } while (0)
+
+#endif
+
#endif /* _ASM_HAZARDS_H */
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index b4923a7..6c113cd 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -33,6 +33,7 @@
#include <asm/mmu_context.h>
#include <asm/war.h>
#include <asm/cacheflush.h> /* for run_uncached() */
+#include <asm/hazards.h>
/*
@@ -604,6 +605,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size)
r4k_blast_scache();
else
blast_scache_range(addr, addr + size);
+ cacheflush_hazard();
return;
}
@@ -620,6 +622,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size)
}
bc_wback_inv(addr, size);
+ cacheflush_hazard();
}
static void r4k_dma_cache_inv(unsigned long addr, unsigned long size)
@@ -647,6 +650,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size)
(addr + size - 1) & almask);
blast_inv_scache_range(addr, addr + size);
}
+ cacheflush_hazard();
return;
}
@@ -663,6 +667,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size)
}
bc_inv(addr, size);
+ cacheflush_hazard();
}
#endif /* CONFIG_DMA_NONCOHERENT */
--
1.7.0.4
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Cernekee <cernekee@gmail.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: macro@linux-mips.org, skuribay@pobox.com, raiko@niisi.msk.ru,
linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/6] MIPS: Sync after cacheflush on BMIPS processors
Date: Thu, 13 Jan 2011 17:52:12 -0800 [thread overview]
Message-ID: <491015d51e5d3d36c517da09e038ecaf@localhost> (raw)
Message-ID: <20110114015212.jOgM2AGYHApeDz1NbttYKVacPz2BXJgx-G9WmJtfA4Q@z> (raw)
On BMIPS processors, cache writeback operations may complete before the
data has actually been written out to memory. Subsequent uncached reads
(or I/O operations) may see stale data unless a sync instruction is
executed after the writeback loop.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/include/asm/hazards.h | 21 +++++++++++++++++++++
arch/mips/mm/c-r4k.c | 5 +++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/asm/hazards.h b/arch/mips/include/asm/hazards.h
index 4e33216..655da05 100644
--- a/arch/mips/include/asm/hazards.h
+++ b/arch/mips/include/asm/hazards.h
@@ -270,4 +270,25 @@ ASMMACRO(disable_fpu_hazard,
)
#endif
+/*
+ * Some processors will "pipeline" cache writeback operations, and need an
+ * extra sync instruction to ensure that they are actually flushed out to
+ * memory. Performing an uncached read (or an I/O operation) without the
+ * flush may cause stale data to be fetched.
+ */
+
+#if defined(CONFIG_CPU_BMIPS3300) || defined(CONFIG_CPU_BMIPS4350) || \
+ defined(CONFIG_CPU_BMIPS4380) || defined(CONFIG_CPU_BMIPS5000)
+
+#define cacheflush_hazard() \
+do { \
+ __sync(); \
+} while (0)
+
+#else
+
+#define cacheflush_hazard() do { } while (0)
+
+#endif
+
#endif /* _ASM_HAZARDS_H */
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index b4923a7..6c113cd 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -33,6 +33,7 @@
#include <asm/mmu_context.h>
#include <asm/war.h>
#include <asm/cacheflush.h> /* for run_uncached() */
+#include <asm/hazards.h>
/*
@@ -604,6 +605,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size)
r4k_blast_scache();
else
blast_scache_range(addr, addr + size);
+ cacheflush_hazard();
return;
}
@@ -620,6 +622,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size)
}
bc_wback_inv(addr, size);
+ cacheflush_hazard();
}
static void r4k_dma_cache_inv(unsigned long addr, unsigned long size)
@@ -647,6 +650,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size)
(addr + size - 1) & almask);
blast_inv_scache_range(addr, addr + size);
}
+ cacheflush_hazard();
return;
}
@@ -663,6 +667,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size)
}
bc_inv(addr, size);
+ cacheflush_hazard();
}
#endif /* CONFIG_DMA_NONCOHERENT */
--
1.7.0.4
next reply other threads:[~2011-01-14 1:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 1:52 Kevin Cernekee [this message]
2011-01-14 1:52 ` [PATCH v2 1/6] MIPS: Sync after cacheflush on BMIPS processors Kevin Cernekee
2011-01-14 1:52 ` [PATCH v2 2/6] MIPS: pfn_valid() is broken on low memory HIGHMEM systems Kevin Cernekee
2011-01-14 1:52 ` Kevin Cernekee
2011-01-14 1:52 ` [PATCH v2 RESEND 3/6] MIPS: Move FIXADDR_TOP into spaces.h Kevin Cernekee
2011-01-14 1:52 ` Kevin Cernekee
2011-01-14 1:52 ` [PATCH v4 RESEND 4/6] MIPS: HIGHMEM DMA on noncoherent MIPS32 processors Kevin Cernekee
2011-01-14 1:52 ` Kevin Cernekee
2011-01-14 1:52 ` [PATCH RESEND 5/6] MIPS: Install handlers for BMIPS software IRQs Kevin Cernekee
2011-01-14 1:52 ` Kevin Cernekee
2011-01-14 1:52 ` [PATCH RESEND 6/6] MIPS: Limit fixrange_init() to the FIXMAP region Kevin Cernekee
2011-01-14 1:52 ` Kevin Cernekee
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=491015d51e5d3d36c517da09e038ecaf@localhost \
--to=cernekee@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=raiko@niisi.msk.ru \
--cc=ralf@linux-mips.org \
--cc=skuribay@pobox.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.