From: Grant Likely <grant.likely@secretlab.ca>
To: galak@kernel.crashing.org, benh@kernel.crashing.org,
linuxppc-dev@ozlabs.org
Subject: [RFC] powerpc/8xxx: Clean up setting of CPU_FTR_NEED_COHERENT
Date: Mon, 16 Mar 2009 22:59:07 -0600 [thread overview]
Message-ID: <20090317045815.27319.62728.stgit@localhost.localdomain> (raw)
From: Grant Likely <grant.likely@secretlab.ca>
Method used to set CPU_FTR_NEED_COHERENT was unfriendly for multiplatform
kernels. This patch cleans it up.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
I haven't even compile tested this. But I want to see if there are any
objections before I do the legwork.
g.
arch/powerpc/include/asm/cputable.h | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 48d7f5f..a36494e 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -242,8 +242,7 @@ extern const char *powerpc_base_platform;
* 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
* require it for PCI "streaming/prefetch" to work properly.
*/
-#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
- || defined(CONFIG_PPC_83xx) || defined(CONFIG_8260)
+#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE)
#define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
#else
#define CPU_FTR_COMMON 0
@@ -347,7 +346,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_SPEC7450 | CPU_FTR_NAP_DISABLE_L2_PR | \
CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
#define CPU_FTRS_82XX (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_NEED_COHERENT)
#if defined(CONFIG_PPC_MPC52xx)
#define CPU_FTRS_G2_LE (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
@@ -359,10 +358,10 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_E300 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_COMMON)
+ CPU_FTR_COMMON | CPU_FTR_NEED_COHERENT)
#define CPU_FTRS_E300C2 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE)
+ CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE | CPU_FTR_NEED_COHERENT)
#define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | CPU_FTR_USE_TB)
#define CPU_FTRS_8XX (CPU_FTR_USE_TB)
#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
next reply other threads:[~2009-03-17 4:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 4:59 Grant Likely [this message]
2009-03-18 0:42 ` [RFC] powerpc/8xxx: Clean up setting of CPU_FTR_NEED_COHERENT Benjamin Herrenschmidt
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=20090317045815.27319.62728.stgit@localhost.localdomain \
--to=grant.likely@secretlab.ca \
--cc=benh@kernel.crashing.org \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
/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.