* [3/5] replace CONFIG_POWER4 by CONFIG_PPC64
From: Marvin @ 2008-07-21 6:45 UTC (permalink / raw)
To: linuxppc-dev
This patch replaces all occurrences of CONFIG_POWER4 by CONFIG_PPC64 since it
is redundant.
Subject: [PATCH] replace CONFIG_POWER4 by CONFIG_PPC64
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/configs/cell_defconfig | 1 -
arch/powerpc/configs/celleb_defconfig | 1 -
arch/powerpc/configs/g5_defconfig | 1 -
arch/powerpc/configs/iseries_defconfig | 1 -
arch/powerpc/configs/maple_defconfig | 1 -
arch/powerpc/configs/pasemi_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/ps3_defconfig | 1 -
arch/powerpc/configs/pseries_defconfig | 1 -
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 4 ---
arch/powerpc/platforms/powermac/feature.c | 42 +++++++++++++---------------
include/asm-powerpc/cputable.h | 2 +-
include/asm-powerpc/mmu_context.h | 6 +---
15 files changed, 25 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 9155c93..624a896 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -118,7 +118,7 @@ endif
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
-cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
+cpu-as-$(CONFIG_PPC64) += -Wa,-maltivec
cpu-as-$(CONFIG_E500) += -Wa,-me500
cpu-as-$(CONFIG_E200) += -Wa,-me200
diff --git a/arch/powerpc/configs/cell_defconfig
b/arch/powerpc/configs/cell_defconfig
index 579e996..42290e8 100644
--- a/arch/powerpc/configs/cell_defconfig
+++ b/arch/powerpc/configs/cell_defconfig
@@ -10,7 +10,6 @@ CONFIG_PPC64=y
#
# CONFIG_POWER4_ONLY is not set
CONFIG_BATS64=y
-CONFIG_POWER4=y
CONFIG_TUNE_CELL=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/configs/celleb_defconfig
b/arch/powerpc/configs/celleb_defconfig
index c2761a7..a405836 100644
--- a/arch/powerpc/configs/celleb_defconfig
+++ b/arch/powerpc/configs/celleb_defconfig
@@ -10,7 +10,6 @@ CONFIG_PPC64=y
#
# CONFIG_POWER4_ONLY is not set
CONFIG_BATS64=y
-CONFIG_POWER4=y
CONFIG_TUNE_CELL=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/configs/g5_defconfig
b/arch/powerpc/configs/g5_defconfig
index 0ccc6e4..747088a 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -9,7 +9,6 @@ CONFIG_PPC64=y
# Processor support
#
CONFIG_POWER4_ONLY=y
-CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/configs/iseries_defconfig
b/arch/powerpc/configs/iseries_defconfig
index 5237a6b..1b46033 100644
--- a/arch/powerpc/configs/iseries_defconfig
+++ b/arch/powerpc/configs/iseries_defconfig
@@ -10,7 +10,6 @@ CONFIG_PPC64=y
#
# CONFIG_POWER4_ONLY is not set
CONFIG_BATS64=y
-CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
# CONFIG_ALTIVEC is not set
diff --git a/arch/powerpc/configs/maple_defconfig
b/arch/powerpc/configs/maple_defconfig
index 7a166a3..4becb7b 100644
--- a/arch/powerpc/configs/maple_defconfig
+++ b/arch/powerpc/configs/maple_defconfig
@@ -9,7 +9,6 @@ CONFIG_PPC64=y
# Processor support
#
CONFIG_POWER4_ONLY=y
-CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
# CONFIG_ALTIVEC is not set
diff --git a/arch/powerpc/configs/pasemi_defconfig
b/arch/powerpc/configs/pasemi_defconfig
index 199e5f5..d816a3a 100644
--- a/arch/powerpc/configs/pasemi_defconfig
+++ b/arch/powerpc/configs/pasemi_defconfig
@@ -9,7 +9,6 @@ CONFIG_PPC64=y
# Processor support
#
CONFIG_POWER4_ONLY=y
-CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index 953d840..22276d2 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -10,7 +10,6 @@ CONFIG_PPC64=y
#
# CONFIG_POWER4_ONLY is not set
CONFIG_BATS64=y
-CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/configs/ps3_defconfig
b/arch/powerpc/configs/ps3_defconfig
index 2015c69..52a0895 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -10,7 +10,6 @@ CONFIG_PPC64=y
#
# CONFIG_POWER4_ONLY is not set
CONFIG_BATS64=y
-CONFIG_POWER4=y
CONFIG_TUNE_CELL=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/configs/pseries_defconfig
b/arch/powerpc/configs/pseries_defconfig
index e163059..e0194e7 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -10,7 +10,6 @@ CONFIG_PPC64=y
#
# CONFIG_POWER4_ONLY is not set
CONFIG_BATS64=y
-CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index c53145f..c3509c8 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -74,7 +74,7 @@ unsigned long p_mapped_by_bats(phys_addr_t pa)
unsigned long __init mmu_mapin_ram(void)
{
-#ifdef CONFIG_POWER4
+#ifdef CONFIG_PPC64
return 0;
#else
unsigned long tot, bl, done;
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index b343fdb..5af2123 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -119,10 +119,6 @@ config BATS64
depends on PPC64
def_bool y if !POWER4_ONLY
-config POWER4
- depends on PPC64
- def_bool y
-
config POWER4_ONLY
depends on PPC64
def_bool y if TUNE_POWER4 && OPT_EXCLUSIVE
diff --git a/arch/powerpc/platforms/powermac/feature.c
b/arch/powerpc/platforms/powermac/feature.c
index 5169ecc..608b793 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -155,7 +155,7 @@ static inline int simple_feature_tweak(struct device_node
*node, int type,
return 0;
}
-#ifndef CONFIG_POWER4
+#ifndef CONFIG_PPC64
static long ohare_htw_scc_enable(struct device_node *node, long param,
long value)
@@ -1315,7 +1315,7 @@ intrepid_aack_delay_enable(struct device_node *node,
long param, long value)
}
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
static long
core99_read_gpio(struct device_node *node, long param, long value)
@@ -1335,7 +1335,7 @@ core99_write_gpio(struct device_node *node, long param,
long value)
return 0;
}
-#ifdef CONFIG_POWER4
+#ifdef CONFIG_PPC64
static long g5_gmac_enable(struct device_node *node, long param, long value)
{
struct macio_chip *macio = &macio_chips[0];
@@ -1547,9 +1547,9 @@ void g5_phy_disable_cpu1(void)
if (uninorth_maj == 3)
UN_OUT(U3_API_PHY_CONFIG_1, 0);
}
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
-#ifndef CONFIG_POWER4
+#ifndef CONFIG_PPC64
#ifdef CONFIG_PM
@@ -1861,7 +1861,7 @@ core99_sleep_state(struct device_node *node, long param,
long value)
return 0;
}
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
static long
generic_dev_can_wake(struct device_node *node, long param, long value)
@@ -1903,7 +1903,7 @@ static struct feature_table_entry any_features[] = {
{ 0, NULL }
};
-#ifndef CONFIG_POWER4
+#ifndef CONFIG_PPC64
/* OHare based motherboards. Currently, we only use these on the
* 2400,3400 and 3500 series powerbooks. Some older desktops seem
@@ -2053,7 +2053,7 @@ static struct feature_table_entry intrepid_features[] =
{
{ 0, NULL }
};
-#else /* CONFIG_POWER4 */
+#else /* CONFIG_PPC64 */
/* G5 features
*/
@@ -2071,10 +2071,10 @@ static struct feature_table_entry g5_features[] = {
{ 0, NULL }
};
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
static struct pmac_mb_def pmac_mb_defs[] = {
-#ifndef CONFIG_POWER4
+#ifndef CONFIG_PPC64
/*
* Desktops
*/
@@ -2335,12 +2335,11 @@ static struct pmac_mb_def pmac_mb_defs[] = {
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
},
-#else /* CONFIG_POWER4 */
+#else /* CONFIG_PPC64 */
{ "PowerMac7,2", "PowerMac G5",
PMAC_TYPE_POWERMAC_G5, g5_features,
0,
},
-#ifdef CONFIG_PPC64
{ "PowerMac7,3", "PowerMac G5",
PMAC_TYPE_POWERMAC_G5, g5_features,
0,
@@ -2366,7 +2365,6 @@ static struct pmac_mb_def pmac_mb_defs[] = {
0,
},
#endif /* CONFIG_PPC64 */
-#endif /* CONFIG_POWER4 */
};
/*
@@ -2434,7 +2432,7 @@ static int __init probe_motherboard(void)
/* Fallback to selection depending on mac-io chip type */
switch(macio->type) {
-#ifndef CONFIG_POWER4
+#ifndef CONFIG_PPC64
case macio_grand_central:
pmac_mb.model_id = PMAC_TYPE_PSURGE;
pmac_mb.model_name = "Unknown PowerSurge";
@@ -2468,7 +2466,7 @@ static int __init probe_motherboard(void)
pmac_mb.model_name = "Unknown Intrepid-based";
pmac_mb.features = intrepid_features;
break;
-#else /* CONFIG_POWER4 */
+#else /* CONFIG_PPC64 */
case macio_keylargo2:
pmac_mb.model_id = PMAC_TYPE_UNKNOWN_K2;
pmac_mb.model_name = "Unknown K2-based";
@@ -2479,13 +2477,13 @@ static int __init probe_motherboard(void)
pmac_mb.model_name = "Unknown Shasta-based";
pmac_mb.features = g5_features;
break;
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
default:
ret = -ENODEV;
goto done;
}
found:
-#ifndef CONFIG_POWER4
+#ifndef CONFIG_PPC64
/* Fixup Hooper vs. Comet */
if (pmac_mb.model_id == PMAC_TYPE_HOOPER) {
u32 __iomem * mach_id_ptr = ioremap(0xf3000034, 4);
@@ -2539,9 +2537,9 @@ found:
*/
powersave_lowspeed = 1;
-#else /* CONFIG_POWER4 */
+#else /* CONFIG_PPC64 */
powersave_nap = 1;
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
@@ -2772,7 +2770,7 @@ set_initial_features(void)
MACIO_BIS(OHARE_FCR, OH_IOBUS_ENABLE);
}
-#ifdef CONFIG_POWER4
+#ifdef CONFIG_PPC64
if (macio_chips[0].type == macio_keylargo2 ||
macio_chips[0].type == macio_shasta) {
#ifndef CONFIG_SMP
@@ -2812,7 +2810,7 @@ set_initial_features(void)
np = of_find_node_by_name(np, "firewire");
}
}
-#else /* CONFIG_POWER4 */
+#else /* CONFIG_PPC64 */
if (macio_chips[0].type == macio_keylargo ||
macio_chips[0].type == macio_pangea ||
@@ -2882,7 +2880,7 @@ set_initial_features(void)
MACIO_BIC(HEATHROW_FCR, HRW_SOUND_POWER_N);
}
-#endif /* CONFIG_POWER4 */
+#endif /* CONFIG_PPC64 */
/* On all machines, switch modem & serial ports off */
for_each_node_by_name(np, "ch-a")
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 0ef9abc..97fdbaf 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -257,7 +257,7 @@ extern void do_feature_fixups(unsigned long value, void
*fixup_start,
#endif
#define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \
- !defined(CONFIG_POWER4) && !defined(CONFIG_BOOKE))
+ !defined(CONFIG_PPC64) && !defined(CONFIG_BOOKE))
#define CPU_FTRS_PPC601 (CPU_FTR_COMMON | CPU_FTR_601 | CPU_FTR_HPTE_TABLE |
\
CPU_FTR_COHERENT_ICACHE | CPU_FTR_UNIFIED_ID_CACHE)
diff --git a/include/asm-powerpc/mmu_context.h
b/include/asm-powerpc/mmu_context.h
index 9102b8b..bc4386b 100644
--- a/include/asm-powerpc/mmu_context.h
+++ b/include/asm-powerpc/mmu_context.h
@@ -173,9 +173,7 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
#ifdef CONFIG_ALTIVEC
if (cpu_has_feature(CPU_FTR_ALTIVEC))
asm volatile ("dssall;\n"
-#ifndef CONFIG_POWER4
- "sync;\n" /* G4 needs a sync here, G5 apparently not */
-#endif
+ "sync;\n" /* G4 needs a sync here */
: : );
#endif /* CONFIG_ALTIVEC */
@@ -201,7 +199,7 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
extern void mmu_context_init(void);
-#else
+#else /* CONFIG_PPC64 */
#include <linux/kernel.h>
#include <linux/mm.h>
--
1.5.6.2
^ permalink raw reply related
* [1/5] add tune options to Kconfig.cputypes
From: Marvin @ 2008-07-20 17:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200807201927.24198.marvin24@gmx.de>
This patch adds tuning options similar to ppc32. In addition one can choose to
compile exclusive for the selected (and higher) cpus.
Subject: [PATCH] add tune options to Kconfig.cputypes
---
arch/powerpc/platforms/Kconfig.cputype | 79 ++++++++++++++++++++++++-------
1 files changed, 61 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 5bc4b61..88e6ce2 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -54,35 +54,78 @@ config E200
endchoice
-config POWER4_ONLY
- bool "Optimize for POWER4"
+choice
+ prompt "Processor Type"
depends on PPC64
+ default TUNE_POWER4
+ help
+ There are serveral families of 64 bit PowerPC chips supported.
+ These include the RS64, Power3 to Power6 series, 970, and
+ Cell BE based CPUs made be IBM.
+
+ If unsure, select Power4.
+
+config TUNE_RS64
+ bool "RS64"
+
+config TUNE_POWER3
+ bool "Power3"
+
+config TUNE_POWER4
+ bool "Power4"
+
+config TUNE_970
+ bool "970/G5"
+
+config TUNE_POWER5
+ bool "Power5"
+
+config TUNE_POWER6
+ bool "Power6"
+
+config TUNE_CELL
+ bool "Cell Broadband Engine"
+ help
+ Cause the compiler to optimize for the PPE of the Cell Broadband
+ Engine. This will make the code run considerably faster on Cell
+ but somewhat slower on other machines. If the resulting kernel is
+ built to run only on Cell BE machines, select also OPT_EXCLUSIVE.
+
+endchoice
+
+config OPT_EXCLUSIVE
+ bool "Optimize to run exclusive on selected CPU"
default n
- ---help---
- Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
- The resulting binary will not work on POWER3 or RS64 processors
- when compiled with binutils 2.15 or later.
+ help
+ Cause the compiler to optimize to run exclusive on the selected
+ CPU. The resulting binary will probably not work on older CPUs,
+ but should work on newer ones.
+
+ See the following chart for supported PPC64 CPU generations.
+
+ older <------------------------------> newer
+
+ RS64 -> POWER3 -> POWER4 -> POWER5 -> POWER6
+ 970/G5
+ CELL BE
+ PA6T
+
+ If the compiler/binutils combination does not support the exclusive
+ optimization, it will try to tune only or fail.
+
+ If you are unsure, select no.
config POWER3
- bool
depends on PPC64
- default y if !POWER4_ONLY
+ def_bool y if !POWER4_ONLY
config POWER4
depends on PPC64
def_bool y
-config TUNE_CELL
- bool "Optimize for Cell Broadband Engine"
+config POWER4_ONLY
depends on PPC64
- help
- Cause the compiler to optimize for the PPE of the Cell Broadband
- Engine. This will make the code run considerably faster on Cell
- but somewhat slower on other machines. This option only changes
- the scheduling of instructions, not the selection of instructions
- itself, so the resulting kernel will keep running on all other
- machines. When building a kernel that is supposed to run only
- on Cell, you should also select the POWER4_ONLY option.
+ def_bool y if TUNE_POWER4 && OPT_EXCLUSIVE
config 6xx
bool
--
1.5.6.2
^ permalink raw reply related
* [5/5] include tuning options into Makefile
From: Marvin @ 2008-07-21 7:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200807210857.08892.marvin24@gmx.de>
This patch finally adds mcpu/mtune options to the Makefile using the
previous introduced tuning mechanism.
Subject: [PATCH] include tuning options into Makefile
---
arch/powerpc/Makefile | 41 +++++++++++++++++++++++------------------
1 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 9629c5e..09f81a7 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -75,30 +75,35 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS
+= -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
ifeq ($(CONFIG_PPC64),y)
-GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y";
fi)
-ifeq ($(CONFIG_TUNE_POWER4),y)
-ifeq ($(CONFIG_OPT_EXCLUSIVE),y)
-ifeq ($(CONFIG_ALTIVEC),y)
-ifeq ($(GCC_BROKEN_VEC),y)
- KBUILD_CFLAGS += $(call cc-option,-mcpu=970)
+ifeq ($(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y"; fi),y)
+ P4CPU := power4
else
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
+ P4CPU := 970
endif
-else
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
-else
- KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
-endif
- KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
+
+# optimize for specific cpu
+ifeq ($(CONFIG_TUNE_RS64),y)
+ KBUILD_CFLAGS += $(call cc-option,-mcpu=rs64)
+else ifeq ($(CONFIG_TUNE_POWER3),y)
+ KBUILD_CFLAGS += $(call cc-option,-mcpu=power3)
+else ifeq ($(CONFIG_TUNE_POWER4),y)
+ KBUILD_CFLAGS += $(call cc-option,-mcpu=$(P4CPU))
+else ifeq ($(CONFIG_TUNE_CELL),y)
+ KBUILD_CFLAGS += $(call cc-option,-mcpu=cell,-mtune=cell)
+else ifeq ($(CONFIG_TUNE_POWER5),y)
+ KBUILD_CFLAGS += $(call cc-option,-mcpu=power5,-mtune=power5)
+else ifeq ($(CONFIG_TUNE_POWER6),y)
+ KBUILD_CFLAGS += $(call cc-option,-mcpu=power6,-mtune=power6)
endif
-else
-LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
+
+ifneq ($(CONFIG_OPT_EXCLUSIVE),y)
+ KBUILD_CFLAGS := $(subst mcpu,mtune,$(KBUILD_CFLAGS))
endif
-ifeq ($(CONFIG_TUNE_CELL),y)
- KBUILD_CFLAGS += $(call cc-option,-mtune=cell)
+else
+# !PPC64
+ LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
endif
# No AltiVec instruction when building kernel
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
From: Stephen Rothwell @ 2008-07-21 4:09 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Nathan Lynch, Sean MacLennan
In-Reply-To: <20080720234756.03b602ca@lappy.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
Hi Sean,
On Sun, 20 Jul 2008 23:47:56 -0400 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> I guess I am too x86 centric. On the x86 an msleep does not give up the
> CPU. It does a busy wait.
I think you must be thinking of mdelay().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
From: Sean MacLennan @ 2008-07-21 3:47 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <20080720201708.GP9594@localdomain>
On Sun, 20 Jul 2008 15:17:08 -0500
"Nathan Lynch" <ntl@pobox.com> wrote:
> Sean MacLennan wrote:
>
> > Why can you not msleep within a spinlock? And when was this change
> > brought in?
>
> Giving up the cpu while holding a spinlock risks locking up the system
> in the worst case -- if another task tries to acquire the held lock it
> can spin indefinitely.
I guess I am too x86 centric. On the x86 an msleep does not give up the
CPU. It does a busy wait.
So what sleep do you use on the PowerPC when you need a delay for
hardware reasons?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: Andrew Morton @ 2008-07-21 3:40 UTC (permalink / raw)
To: benh
Cc: John Reiser, linux-kernel, linuxppc-dev, Nathan Lynch, torvalds,
roland
In-Reply-To: <1216610655.11027.80.camel@pasglop>
On Mon, 21 Jul 2008 13:24:15 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2008-07-18 at 13:28 -0500, Nathan Lynch wrote:
> > John Reiser wrote:
> > > Andrew Morton wrote:
> > > > On Thu, 17 Jul 2008 17:19:32 -0500
> > > > Nathan Lynch <ntl@pobox.com> wrote:
> > > >
> > > >
> > > >> [snip]
> > > >> A new aux vector entry, AT_BASE_PLATFORM, will denote the actual hardware.
> > > [snip]
> > >
> > > > OK.
> > > >
> > > > But it conflicts directly with the already-queued
> > > > execve-filename-document-and-export-via-auxiliary-vector.patch
> >
> > Okay, I can rebase on -mm.
>
> Andrew, we have one other patch (the powerpc bits) on top of that one.
> Do you want to carry both in -mm on top of John's patch ? We would like
> that in .27 though, I don't know what your merge plans are for John's
> patch.
>
How about I send John's patch Linuswards right now?
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: Benjamin Herrenschmidt @ 2008-07-21 3:24 UTC (permalink / raw)
To: Andrew Morton
Cc: John Reiser, linux-kernel, linuxppc-dev, Nathan Lynch, torvalds,
roland
In-Reply-To: <20080718182850.GO9594@localdomain>
On Fri, 2008-07-18 at 13:28 -0500, Nathan Lynch wrote:
> John Reiser wrote:
> > Andrew Morton wrote:
> > > On Thu, 17 Jul 2008 17:19:32 -0500
> > > Nathan Lynch <ntl@pobox.com> wrote:
> > >
> > >
> > >> [snip]
> > >> A new aux vector entry, AT_BASE_PLATFORM, will denote the actual hardware.
> > [snip]
> >
> > > OK.
> > >
> > > But it conflicts directly with the already-queued
> > > execve-filename-document-and-export-via-auxiliary-vector.patch
>
> Okay, I can rebase on -mm.
Andrew, we have one other patch (the powerpc bits) on top of that one.
Do you want to carry both in -mm on top of John's patch ? We would like
that in .27 though, I don't know what your merge plans are for John's
patch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] elf loader support for auxvec base platform string
From: Benjamin Herrenschmidt @ 2008-07-21 3:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev, Andrew Morton, Nathan Lynch, linux-kernel, roland
In-Reply-To: <alpine.LFD.1.10.0807170908060.2959@woody.linux-foundation.org>
On Thu, 2008-07-17 at 09:10 -0700, Linus Torvalds wrote:
>
> On Thu, 17 Jul 2008, Benjamin Herrenschmidt wrote:
> >
> > Should I seek somebody's ack before merging a patch like the one below ?
> >
> > I'm a bit reluctant to merge via the powerpc.git tree some changes to
> > generic files without at least an ack from somebody else :-)
>
> Gaah. Generally we don't, but you're right to ask. The ELF loading keeps
> on accumulating these things, and I'm not sure we have the right process
> for things like this. They're all individually small and insignificant,
> and they are all individually never going away and making the ELF loader
> messier and messier.
Yeah, annoying. Oh well, this one at least is now getting Andrew's
scrutinity...
Cheers,
Ben.
^ permalink raw reply
* Re: [patch] powerpc: implement pte_special for 64K pages
From: Benjamin Herrenschmidt @ 2008-07-21 1:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: Nick Piggin, linuxppc-dev, Dave Kleikamp
In-Reply-To: <20080720181658.02651e2f.akpm@linux-foundation.org>
On Sun, 2008-07-20 at 18:16 -0700, Andrew Morton wrote:
> On Mon, 21 Jul 2008 10:57:55 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > On Thu, 2008-07-17 at 12:44 +0200, Nick Piggin wrote:
> > > This can be folded into powerpc-implement-pte_special.patch
> > >
> > > --
> > > Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
> > >
> > > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > > ---
> >
> > Ack.
> >
> > Andrew, will you merge this or do you want me to ?
>
> I can do so.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch] powerpc: implement pte_special for 64K pages
From: Andrew Morton @ 2008-07-21 1:16 UTC (permalink / raw)
To: benh; +Cc: Nick Piggin, linuxppc-dev, Dave Kleikamp
In-Reply-To: <1216601875.11027.59.camel@pasglop>
On Mon, 21 Jul 2008 10:57:55 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2008-07-17 at 12:44 +0200, Nick Piggin wrote:
> > This can be folded into powerpc-implement-pte_special.patch
> >
> > --
> > Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
> >
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > ---
>
> Ack.
>
> Andrew, will you merge this or do you want me to ?
I can do so.
^ permalink raw reply
* Re: [patch] powerpc: implement pte_special for 64K pages
From: Benjamin Herrenschmidt @ 2008-07-21 0:57 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Andrew Morton, Dave Kleikamp
In-Reply-To: <20080717104426.GA25083@wotan.suse.de>
On Thu, 2008-07-17 at 12:44 +0200, Nick Piggin wrote:
> This can be folded into powerpc-implement-pte_special.patch
>
> --
> Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> ---
Ack.
Andrew, will you merge this or do you want me to ?
Cheers,
Ben.
> Index: linux-2.6/include/asm-powerpc/pgtable-64k.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/pgtable-64k.h 2008-07-17 18:53:03.000000000 +1000
> +++ linux-2.6/include/asm-powerpc/pgtable-64k.h 2008-07-17 20:30:06.000000000 +1000
> @@ -70,11 +70,12 @@
> #define PGDIR_MASK (~(PGDIR_SIZE-1))
>
> /* Additional PTE bits (don't change without checking asm in hash_low.S) */
> +#define __HAVE_ARCH_PTE_SPECIAL
> +#define _PAGE_SPECIAL 0x00000400 /* software: special page */
> #define _PAGE_HPTE_SUB 0x0ffff000 /* combo only: sub pages HPTE bits */
> #define _PAGE_HPTE_SUB0 0x08000000 /* combo only: first sub page */
> #define _PAGE_COMBO 0x10000000 /* this is a combo 4k page */
> #define _PAGE_4K_PFN 0x20000000 /* PFN is for a single 4k page */
> -#define _PAGE_SPECIAL 0x0 /* don't have enough room for this yet */
>
> /* For 64K page, we don't have a separate _PAGE_HASHPTE bit. Instead,
> * we set that to be the whole sub-bits mask. The C code will only
^ permalink raw reply
* Re: [2.6 patch] powerpc/boot/Makefile: change spaces to tabs
From: Benjamin Herrenschmidt @ 2008-07-21 0:59 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <20080717181854.GB18326@cs181140183.pp.htv.fi>
On Thu, 2008-07-17 at 21:18 +0300, Adrian Bunk wrote:
> For C code spaces versus tabs is just a religious issue,
> but for Makefiles it actually matters.
>
> This patch fixes he following errors:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:166: *** missing separator. Stop.
> /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:171: *** missing separator. Stop.
>
> Since this was inside an ifdef DTC_GENPARSER it was not a problem unless
> someone wanted to regenerate the shipped generated files.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
And that too :-)
Cheers,
Ben.
> ---
>
> arch/powerpc/boot/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -163,12 +163,12 @@ quiet_cmd_flex = FLEX $@
> cmd_flex = $(FLEX) -o$@ $<; cp $@ $@_shipped
>
> $(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE
> - $(call if_changed,bison)
> + $(call if_changed,bison)
>
> $(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c
>
> $(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE
> - $(call if_changed,flex)
> + $(call if_changed,flex)
> endif
>
> #############
^ permalink raw reply
* Re: [2.6 patch] powerpc: remove duplicate 6xx option
From: Benjamin Herrenschmidt @ 2008-07-21 0:58 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080717181828.GA18326@cs181140183.pp.htv.fi>
On Thu, 2008-07-17 at 21:18 +0300, Adrian Bunk wrote:
> The real option is above in the same Kconfig file.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
Thanks, I'll pick that up.
Cheers,
Ben.
> ---
> 2251e74345df51309579a0a5fd8339e2f14762b9
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 5bc4b61..6489d57 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -84,9 +84,6 @@ config TUNE_CELL
> machines. When building a kernel that is supposed to run only
> on Cell, you should also select the POWER4_ONLY option.
>
> -config 6xx
> - bool
> -
> # this is temp to handle compat with arch=ppc
> config 8xx
> bool
^ permalink raw reply
* Re: jumping to code in RAM in a MPC55xx
From: Tehn Yit Chin @ 2008-07-20 23:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <bf04f99c0807172329m7ec94580n194e02b708bf7597@mail.gmail.com>
I am just going to answer my own questions for future reference.
I did some searching on the internet and came across this note on the
the usenet comp.sys.powerpc.tech
http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.powerpc.tech/2005-11/msg00015.html
In summary, it performs a indirect jump to code via the CTR register.
The following code snippet show how it is done.
lis 9,0xFC00 /* Function is at 0xFC000000 */
mtctr 9
bctrl
On Fri, Jul 18, 2008 at 4:29 PM, Tehn Yit Chin <tehn.yit.chin@gmail.com> wrote:
>
> Hi,
>
> This question is not directly related to linux, but a question on how to execute code from.
>
> My test code is as follows..
>
> void ram(unsigned int cat) __attribute__ ((section(".ram_code")));
> void ram1(void) __attribute__ ((section(".ram_code")));
> void flash(void) __attribute__ ((section(".text")));
> void flash1(unsigned int y) __attribute__ ((section(".text")));
>
> void ram(unsigned int cat)
> {
> unsigned int abc;
>
> abc += 12;
> abc += cat;
> }
>
> void ram1(void)
> {
> ram(123);
> }
>
>
> void flash1(unsigned int y)
> {
> unsigned int x;
>
> x = x + y;
>
> }
>
> void flash(void)
> {
> unsigned int def;
>
> def += 12;
>
> asm (" bel ram1\n\t");
> }
>
> I have the section .ram_code mapped into the internal SRAM of the MPC55xx, which starts at 0x40000000. Code in .text are mapped into MPC55xx's internal FLASH, starting at 0x00000000.
>
> When I attempt to link the code together, I get the error
>
> U:\src\applications\comms/fatdog.c(35,1): relocation truncated to fit: R_PPC_REL24 against symbol `ram1' defined in .ram_code section in U:\src\applications\comms\fatdog.o
>
> I googled the error and I think it means that the ram1() is too far away and the branch address has been truncated to fit into the binary.
>
> Other than assembler bel instruction, I have also tried bl, b and bea and all of them gave the same link error.
>
> I was wondering if anyone can give some insight on how I can get the MPC55xx to branch between FLASH and SRAM?
>
> Many thanks,
> Tehn Yit Chin
>
^ permalink raw reply
* Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
From: Linas Vepstas @ 2008-07-20 23:19 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080720203333.GQ9594@localdomain>
2008/7/20 Nathan Lynch <ntl@pobox.com>:
> Mike Mason wrote:
>>
>> This patch changes the EEH_MAX_FAILS action from panic to printing
>> an error message. Panicking under under this condition is too
>> harsh.
>> /* re-read the slot reset state */
>> if (read_slot_reset_state(pdn, rets) != 0)
>> rets[0] = -1; /* reset state unknown */
>
> While I tend to agree that panic() is unnecessary, don't we want a
> stack dump unconditionally (i.e. not bracketed in #ifdef DEBUG)?
Probably. This stack trace would reveal a point inside the
inf loop, which can then be analyzed and fixed.
> I'd prefer just removing the code instead of adding #ifdef's in the
> middle of this function. eeh.c needs less #ifdef DEBUG, not more :)
I didn't know that there was a lot of ifdef DEBUG in there.
Yes, we don't need an ifdef DEBUG for this.
Pending these changes, I'd happily add:
Acked-by: Linas Vepstas <linasvepstas@gmail.com>
--linas
^ permalink raw reply
* Re: dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Benjamin Herrenschmidt @ 2008-07-20 21:35 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <488385A7.4010509@s5r6.in-berlin.de>
On Sun, 2008-07-20 at 20:36 +0200, Stefan Richter wrote:
> Hi all,
>
> I have to implement a workaround for a PCI device which gets into
> trouble if descriptors are located at 32bit addresses, while 31bit
> addresses are fine. I would like to avoid this workaround on machines
> on which dma_alloc_coherent() won't ever go at memory above 2 GB.
>
> Is defined(CONFIG_PPC32) a safe test for this? I'm under the impression
> that defined(CONFIG_X86_32) is safe.
CONFIG_PPC32 -may- be safe today... the current implementation
for DMA coherent machines seem to have been copied from x86 or so :-) It
sets GFP_DMA if the coherent_dma_mask < 32 bits, but we don't have
separate ZONE_NORMAL and ZONE_DMA anyway, so that is irrelevant. In any
case, it won't give you memory in highmem, so you should be safe.
In the non-DMA coherent case, make sure you don't pass __GFP_HIGHMEM.
There's some work in progress to support swiotlb and more advanced DMA
mapping ops for PPC32 (using function pointers like PPC64), so things
will probably change. However, the need for 31 bits DMA seem to be
common enough that we should probably do something specific about it,
for example, ensure that lowmem is never > 2G (shouldn't be a big deal)
and thus make dma masks < 32 bits always clear __GFP_HIGHMEM from the
allocation mask.
Ben.
^ permalink raw reply
* Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
From: Nathan Lynch @ 2008-07-20 20:33 UTC (permalink / raw)
To: Mike Mason; +Cc: linasvepstas, paulus, linuxppc-dev
In-Reply-To: <488383D4.9000602@us.ibm.com>
Mike Mason wrote:
>
> This patch changes the EEH_MAX_FAILS action from panic to printing
> an error message. Panicking under under this condition is too
> harsh. Although performance will be affected and the device may not
> recover, the system is still running, which at the very least,
> should allow for a more graceful shutdown. The panic() is now
> wrapped in a DEBUG statement for development purposes. The patch
> also removes the msleep() within a spinlock, which is not allowed.
> @@ -509,18 +510,24 @@
For ease of review, please try to use diff -p to generate patches.
> rc = 1;
> if (pdn->eeh_mode & EEH_MODE_ISOLATED) {
> pdn->eeh_check_count ++;
> - if (pdn->eeh_check_count >= EEH_MAX_FAILS) {
> - printk (KERN_ERR "EEH: Device driver ignored %d bad reads, panicing\n",
> - pdn->eeh_check_count);
> + if (pdn->eeh_check_count % EEH_MAX_FAILS == 0) {
> + location = (char *) of_get_property(dn, "ibm,loc-code", NULL);
Unneeded cast here, I think.
> + printk (KERN_ERR "EEH: %d reads ignored for recovering device at "
> + "location=%s driver=%s pci addr=%s\n",
> + pdn->eeh_check_count, location,
> + dev->driver->name, pci_name(dev));
> + printk (KERN_ERR "EEH: Might be infinite loop in %s driver\n",
> + dev->driver->name);
> +#ifdef DEBUG
> dump_stack();
> - msleep(5000);
> -
> +
> /* re-read the slot reset state */
> if (read_slot_reset_state(pdn, rets) != 0)
> rets[0] = -1; /* reset state unknown */
>
> /* If we are here, then we hit an infinite loop. Stop. */
> panic("EEH: MMIO halt (%d) on device:%s\n", rets[0], pci_name(dev));
> +#endif
While I tend to agree that panic() is unnecessary, don't we want a
stack dump unconditionally (i.e. not bracketed in #ifdef DEBUG)?
I'd prefer just removing the code instead of adding #ifdef's in the
middle of this function. eeh.c needs less #ifdef DEBUG, not more :)
^ permalink raw reply
* Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
From: Nathan Lynch @ 2008-07-20 20:17 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080720145858.5be92934@lappy.seanm.ca>
Sean MacLennan wrote:
> On Sun, 20 Jul 2008 11:28:36 -0700
> "Mike Mason" <mmlnx@us.ibm.com> wrote:
>
> > This patch changes the EEH_MAX_FAILS action from panic to printing an
> > error message. Panicking under under this condition is too harsh.
> > Although performance will be affected and the device may not recover,
> > the system is still running, which at the very least, should allow
> > for a more graceful shutdown. The panic() is now wrapped in a DEBUG
> > statement for development purposes. The patch also removes the
> > msleep() within a spinlock, which is not allowed.
>
> Why can you not msleep within a spinlock? And when was this change
> brought in?
Giving up the cpu while holding a spinlock risks locking up the system
in the worst case -- if another task tries to acquire the held lock it
can spin indefinitely.
^ permalink raw reply
* Re: dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Stefan Richter @ 2008-07-20 20:11 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080720123900.02677e6e@infradead.org>
Arjan van de Ven wrote:
> On Sun, 20 Jul 2008 21:25:51 +0200
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> if (dev->needs_dma_mask_workaround)
>> pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
>> allocate_something_special;
>> if (dev->needs_dma_mask_workaround)
>> pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
...
> something like this.
> But realistically, how many consistent/coherent allocations do you have?
> some ring buffers and other one time stuff surely... but not after that?
It's for DMA programs (i.e. lists of descriptors), not for the data DMA
buffers themselves. FireWire controllers have several DMA contexts for
isochronous and asynchronous reception and transmission, and some
others. Only context programs for isochronous reception need the
workaround.
We are dynamically appending new descriptors during runtime. I.e. the
affected allocations happen during setup of the DMA context and
sometimes while the DMA context is active. Particularly, in
drivers/firewire/fw-ohci.c:
ohci_allocate_iso_context
context_init
context_add_buffer <--
and
ohci_queue_iso
ohci_queue_iso_receive_dualbuffer
context_get_descriptors
context_add_buffer <--
The other unaffected context types use context_add_buffer too.
--
Stefan Richter
-=====-==--- -=== =-=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Stefan Richter @ 2008-07-20 19:25 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080720114358.6c88e048@infradead.org>
Arjan van de Ven wrote:
> On Sun, 20 Jul 2008 20:36:23 +0200
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
>> PS: I don't want to set the DMA mask of this device to
>> DMA_31BIT_MASK because that would be detrimental to other functions
>> of the device. It's a TI TSB43AB22A FireWire controller.
>
> Hi,
>
> just want to mention that you can set the coherent mask separately from
> the generic mask... is that sufficient for your load?
> (you can even set it just for this allocation..)
Hmm. Would that be done this way?
During probe:
if (chip_is_tsb43ab22a) {
if (dma_supported(dev, DMA_31BIT_MASK))
chip->needs_dma_mask_workaround = 1;
else
chip->needs_some_other_workaround = 1;
}
Later on:
if (dev->needs_dma_mask_workaround)
pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
allocate_something_special;
if (dev->needs_dma_mask_workaround)
pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
Or is there a variant of dma_alloc_coherent() which directly accepts a
mask argument?
--
Stefan Richter
-=====-==--- -=== =-=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Arjan van de Ven @ 2008-07-20 19:48 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4883913F.9040706@s5r6.in-berlin.de>
On Sun, 20 Jul 2008 21:25:51 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Arjan van de Ven wrote:
> > On Sun, 20 Jul 2008 20:36:23 +0200
> > Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> >
> >> PS: I don't want to set the DMA mask of this device to
> >> DMA_31BIT_MASK because that would be detrimental to other functions
> >> of the device. It's a TI TSB43AB22A FireWire controller.
> >
> > Hi,
> >
> > just want to mention that you can set the coherent mask separately
> > from the generic mask... is that sufficient for your load?
> > (you can even set it just for this allocation..)
>
> Hmm. Would that be done this way?
> During probe:
>
> if (chip_is_tsb43ab22a) {
> if (dma_supported(dev, DMA_31BIT_MASK))
> chip->needs_dma_mask_workaround = 1;
> else
> chip->needs_some_other_workaround = 1;
> }
btw it might be nicer to make this
chip->something_special_mask = DMA_31BIT_MASK;
then you can just use the mask from this struct rather than another
check
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Arjan van de Ven @ 2008-07-20 19:39 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4883913F.9040706@s5r6.in-berlin.de>
On Sun, 20 Jul 2008 21:25:51 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> Later on:
>
> if (dev->needs_dma_mask_workaround)
> pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
> allocate_something_special;
> if (dev->needs_dma_mask_workaround)
> pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
>
> Or is there a variant of dma_alloc_coherent() which directly accepts a
> mask argument?
something like this.
But realistically, how many consistent/coherent allocations do you have?
some ring buffers and other one time stuff surely... but not after that?
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: [PATCH] Don't panic when EEH_MAX_FAILS is exceeded
From: Sean MacLennan @ 2008-07-20 18:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <488383D4.9000602@us.ibm.com>
On Sun, 20 Jul 2008 11:28:36 -0700
"Mike Mason" <mmlnx@us.ibm.com> wrote:
> This patch changes the EEH_MAX_FAILS action from panic to printing an
> error message. Panicking under under this condition is too harsh.
> Although performance will be affected and the device may not recover,
> the system is still running, which at the very least, should allow
> for a more graceful shutdown. The panic() is now wrapped in a DEBUG
> statement for development purposes. The patch also removes the
> msleep() within a spinlock, which is not allowed.
Why can you not msleep within a spinlock? And when was this change
brought in?
Cheers,
Sean
^ permalink raw reply
* dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Stefan Richter @ 2008-07-20 18:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
Hi all,
I have to implement a workaround for a PCI device which gets into
trouble if descriptors are located at 32bit addresses, while 31bit
addresses are fine. I would like to avoid this workaround on machines
on which dma_alloc_coherent() won't ever go at memory above 2 GB.
Is defined(CONFIG_PPC32) a safe test for this? I'm under the impression
that defined(CONFIG_X86_32) is safe.
Are there any other means to detect when the workaround can be omitted,
at compile time or at runtime?
PS: I don't want to set the DMA mask of this device to DMA_31BIT_MASK
because that would be detrimental to other functions of the device. It's
a TI TSB43AB22A FireWire controller.
--
Stefan Richter
-=====-==--- -=== =-=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: dma_alloc_coherent() on PPC32: physical addresses above 2G possible?
From: Arjan van de Ven @ 2008-07-20 18:43 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <488385A7.4010509@s5r6.in-berlin.de>
On Sun, 20 Jul 2008 20:36:23 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> PS: I don't want to set the DMA mask of this device to
> DMA_31BIT_MASK because that would be detrimental to other functions
> of the device. It's a TI TSB43AB22A FireWire controller.
Hi,
just want to mention that you can set the coherent mask separately from
the generic mask... is that sufficient for your load?
(you can even set it just for this allocation..)
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox