* [PATCH 1/4] powerpc: Require gcc 4.0 on 64-bit
From: Anton Blanchard @ 2012-04-18 4:42 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Older versions of gcc had issues with using -maltivec together with
-mcpu of a non altivec capable CPU. We work around it by specifying
-mcpu=970, but the logic is complicated.
In preparation for adding more -mcpu targets, remove the workaround
and just require gcc 4.0 for 64-bit builds.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
4.0 came out in 2005 and the gcc on RHEL5 and SLES10 looks to be 4.1.
I highly doubt a ppc64 kernel will build these days on either RHEL4 or
SLES9.
Anything else we have to worry about?
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 11:59:31.444220933 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 11:59:58.860721391 +1000
@@ -234,10 +234,11 @@ archprepare: checkbin
# Use the file '.tmp_gas_check' for binutils tests, as gas won't output
# to stdout and these checks are run even on install targets.
TOUT := .tmp_gas_check
-# Ensure this is binutils 2.12.1 (or 2.12.90.0.7) or later for altivec
-# instructions.
-# gcc-3.4 and binutils-2.14 are a fatal combination.
+# Check gcc and binutils versions:
+# - gcc-3.4 and binutils-2.14 are a fatal combination
+# - Require gcc 4.0 or above on 64-bit
+# - gcc-4.2.0 has issues compiling modules on 64-bit
checkbin:
@if test "$(call cc-version)" = "0304" ; then \
if ! /bin/echo mftb 5 | $(AS) -v -mppc -many -o $(TOUT) >/dev/null 2>&1 ; then \
@@ -247,6 +248,12 @@ checkbin:
false; \
fi ; \
fi
+ @if test "$(call cc-version)" -lt "0400" \
+ && test "x${CONFIG_PPC64}" = "xy" ; then \
+ echo -n "Sorry, GCC v4.0 or above is required to build " ; \
+ echo "the 64-bit powerpc kernel." ; \
+ false ; \
+ fi
@if test "$(call cc-fullversion)" = "040200" \
&& test "x${CONFIG_MODULES}${CONFIG_PPC64}" = "xyy" ; then \
echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \
^ permalink raw reply
* [PATCH 2/4] powerpc: Remove altivec fix for gcc versions before 4.0
From: Anton Blanchard @ 2012-04-18 4:44 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
Now we require gcc 4.0 on 64-bit we can remove the pre gcc 4.0
-maltivec workaround.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 07:49:24.024963656 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 11:58:18.278885496 +1000
@@ -77,18 +77,8 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
ifeq ($(CONFIG_PPC64),y)
-GCC_BROKEN_VEC := $(call cc-ifversion, -lt, 0400, y)
-
ifeq ($(CONFIG_POWER4_ONLY),y)
-ifeq ($(CONFIG_ALTIVEC),y)
-ifeq ($(GCC_BROKEN_VEC),y)
- KBUILD_CFLAGS += $(call cc-option,-mcpu=970)
-else
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
-else
KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
else
KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
endif
^ permalink raw reply
* [PATCH 3/4] powerpc: Add 64-bit CPU targets for gcc
From: Anton Blanchard @ 2012-04-18 4:45 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
Add a menu to select various 64-bit CPU targets for gcc. We
default to -mtune=power7 and if gcc doesn't understand that we
fallback to -mtune=power4.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 14:31:31.614666419 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 14:37:08.680708678 +1000
@@ -69,6 +69,16 @@ LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=no -mcall-aixdesc
CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple
+
+CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,-mtune=power4)
+CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
+CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4)
+CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5)
+CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6)
+CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7)
+
+CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell)
+
KBUILD_CPPFLAGS += -Iarch/$(ARCH)
KBUILD_AFLAGS += -Iarch/$(ARCH)
KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
@@ -76,22 +86,11 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
-ifeq ($(CONFIG_PPC64),y)
-ifeq ($(CONFIG_POWER4_ONLY),y)
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-else
- KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
-endif
-endif
-
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
-ifeq ($(CONFIG_TUNE_CELL),y)
- KBUILD_CFLAGS += $(call cc-option,-mtune=cell)
-endif
-
-# No AltiVec instruction when building kernel
+# No AltiVec or VSX instructions when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
+KBUILD_CFLAGS += $(call cc-option,-mno-vsx)
# No SPE instruction when building kernel
# (We use all available options to help semi-broken compilers)
Index: linux-build/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:31:25.134549903 +1000
+++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:36:40.576207829 +1000
@@ -78,6 +78,36 @@ config PPC_BOOK3E_64
endchoice
+choice
+ prompt "CPU selection"
+ depends on PPC64
+ default GENERIC_CPU
+ help
+ This will create a kernel which is optimised for a particular CPU.
+ The resulting kernel may not run on other CPUs, so use this with care.
+
+ If unsure, select Generic.
+
+config GENERIC_CPU
+ bool "Generic"
+
+config CELL_CPU
+ bool "Cell Broadband Engine"
+
+config POWER4_CPU
+ bool "POWER4"
+
+config POWER5_CPU
+ bool "POWER5"
+
+config POWER6_CPU
+ bool "POWER6"
+
+config POWER7_CPU
+ bool "POWER7"
+
+endchoice
+
config PPC_BOOK3S
def_bool y
depends on PPC_BOOK3S_32 || PPC_BOOK3S_64
^ permalink raw reply
* [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Anton Blanchard @ 2012-04-18 4:46 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120418144254.3286ce94@kryten>
Remove CONFIG_POWER4_ONLY, the option is badly named and only does two
things:
- It wraps the MMU segment table code. With feature fixups there is
little downside to compiling this in.
- It uses the newer mtocrf instruction in various assembly functions.
Instead of making this a compile option just do it at runtime via
a feature fixup.
I had to expose CPU_FTR_PPCAS_ARCH_V2 to assembly since I key off
that.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/configs/g5_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/g5_defconfig 2012-04-18 14:36:40.568207687 +1000
+++ linux-build/arch/powerpc/configs/g5_defconfig 2012-04-18 14:37:46.125376070 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_ALTIVEC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
Index: linux-build/arch/powerpc/configs/maple_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/maple_defconfig 2012-04-18 14:36:40.556207473 +1000
+++ linux-build/arch/powerpc/configs/maple_defconfig 2012-04-18 14:37:46.125376070 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
Index: linux-build/arch/powerpc/configs/pasemi_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/pasemi_defconfig 2012-04-18 14:36:40.560207544 +1000
+++ linux-build/arch/powerpc/configs/pasemi_defconfig 2012-04-18 14:37:46.125376070 +1000
@@ -1,5 +1,4 @@
CONFIG_PPC64=y
-CONFIG_POWER4_ONLY=y
CONFIG_ALTIVEC=y
# CONFIG_VIRT_CPU_ACCOUNTING is not set
CONFIG_SMP=y
Index: linux-build/arch/powerpc/kernel/exceptions-64s.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 14:36:40.548207330 +1000
+++ linux-build/arch/powerpc/kernel/exceptions-64s.S 2012-04-18 14:37:46.125376070 +1000
@@ -94,12 +94,10 @@ machine_check_pSeries_1:
data_access_pSeries:
HMT_MEDIUM
SET_SCRATCH0(r13)
-#ifndef CONFIG_POWER4_ONLY
BEGIN_FTR_SECTION
b data_access_check_stab
data_access_not_stab:
END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
-#endif
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common, EXC_STD,
KVMTEST, 0x300)
@@ -301,7 +299,6 @@ machine_check_fwnmi:
EXC_STD, KVMTEST, 0x200)
KVM_HANDLER_SKIP(PACA_EXMC, EXC_STD, 0x200)
-#ifndef CONFIG_POWER4_ONLY
/* moved from 0x300 */
data_access_check_stab:
GET_PACA(r13)
@@ -328,7 +325,6 @@ do_stab_bolted_pSeries:
GET_SCRATCH0(r10)
std r10,PACA_EXSLB+EX_R13(r13)
EXCEPTION_PROLOG_PSERIES_1(.do_stab_bolted, EXC_STD)
-#endif /* CONFIG_POWER4_ONLY */
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_STD, 0x300)
KVM_HANDLER_SKIP(PACA_EXSLB, EXC_STD, 0x380)
Index: linux-build/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:36:40.576207829 +1000
+++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 14:37:46.125376070 +1000
@@ -116,15 +116,6 @@ config PPC_BOOK3E
def_bool y
depends on PPC_BOOK3E_64
-config POWER4_ONLY
- bool "Optimize for POWER4"
- depends on PPC64 && PPC_BOOK3S
- 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.
-
config 6xx
def_bool y
depends on PPC32 && PPC_BOOK3S
Index: linux-build/arch/powerpc/include/asm/asm-compat.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/asm-compat.h 2012-04-18 14:36:40.540207188 +1000
+++ linux-build/arch/powerpc/include/asm/asm-compat.h 2012-04-18 14:37:46.125376070 +1000
@@ -29,18 +29,9 @@
#define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh)
#define PPC_STLCX stringify_in_c(stdcx.)
#define PPC_CNTLZL stringify_in_c(cntlzd)
+#define PPC_MTOCRF(FXM, RS) MTOCRF((FXM), (RS))
#define PPC_LR_STKOFF 16
#define PPC_MIN_STKFRM 112
-
-/* Move to CR, single-entry optimized version. Only available
- * on POWER4 and later.
- */
-#ifdef CONFIG_POWER4_ONLY
-#define PPC_MTOCRF stringify_in_c(mtocrf)
-#else
-#define PPC_MTOCRF stringify_in_c(mtcrf)
-#endif
-
#else /* 32-bit */
/* operations for longs and pointers */
Index: linux-build/arch/powerpc/lib/copyuser_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/copyuser_64.S 2012-04-18 14:36:40.504206546 +1000
+++ linux-build/arch/powerpc/lib/copyuser_64.S 2012-04-18 14:37:46.125376070 +1000
@@ -30,7 +30,7 @@ _GLOBAL(__copy_tofrom_user_base)
dcbt 0,r4
beq .Lcopy_page_4K
andi. r6,r6,7
- PPC_MTOCRF 0x01,r5
+ PPC_MTOCRF(0x01,r5)
blt cr1,.Lshort_copy
/* Below we want to nop out the bne if we're on a CPU that has the
* CPU_FTR_UNALIGNED_LD_STD bit set and the CPU_FTR_CP_USE_DCBTZ bit
@@ -186,7 +186,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
blr
.Ldst_unaligned:
- PPC_MTOCRF 0x01,r6 /* put #bytes to 8B bdry into cr7 */
+ PPC_MTOCRF(0x01,r6) /* put #bytes to 8B bdry into cr7 */
subf r5,r6,r5
li r7,0
cmpldi cr1,r5,16
@@ -201,7 +201,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
2: bf cr7*4+1,3f
37: lwzx r0,r7,r4
83: stwx r0,r7,r3
-3: PPC_MTOCRF 0x01,r5
+3: PPC_MTOCRF(0x01,r5)
add r4,r6,r4
add r3,r6,r3
b .Ldst_aligned
Index: linux-build/arch/powerpc/lib/memcpy_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/memcpy_64.S 2012-04-18 14:36:40.512206689 +1000
+++ linux-build/arch/powerpc/lib/memcpy_64.S 2012-04-18 14:37:46.129376142 +1000
@@ -12,7 +12,7 @@
.align 7
_GLOBAL(memcpy)
std r3,48(r1) /* save destination pointer for return value */
- PPC_MTOCRF 0x01,r5
+ PPC_MTOCRF(0x01,r5)
cmpldi cr1,r5,16
neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
andi. r6,r6,7
@@ -154,7 +154,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
blr
.Ldst_unaligned:
- PPC_MTOCRF 0x01,r6 # put #bytes to 8B bdry into cr7
+ PPC_MTOCRF(0x01,r6) # put #bytes to 8B bdry into cr7
subf r5,r6,r5
li r7,0
cmpldi cr1,r5,16
@@ -169,7 +169,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
2: bf cr7*4+1,3f
lwzx r0,r7,r4
stwx r0,r7,r3
-3: PPC_MTOCRF 0x01,r5
+3: PPC_MTOCRF(0x01,r5)
add r4,r6,r4
add r3,r6,r3
b .Ldst_aligned
Index: linux-build/arch/powerpc/lib/mem_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/mem_64.S 2012-04-18 14:36:40.508206617 +1000
+++ linux-build/arch/powerpc/lib/mem_64.S 2012-04-18 14:37:46.129376142 +1000
@@ -19,7 +19,7 @@ _GLOBAL(memset)
rlwimi r4,r4,16,0,15
cmplw cr1,r5,r0 /* do we get that far? */
rldimi r4,r4,32,0
- PPC_MTOCRF 1,r0
+ PPC_MTOCRF(1,r0)
mr r6,r3
blt cr1,8f
beq+ 3f /* if already 8-byte aligned */
@@ -49,7 +49,7 @@ _GLOBAL(memset)
bdnz 4b
5: srwi. r0,r5,3
clrlwi r5,r5,29
- PPC_MTOCRF 1,r0
+ PPC_MTOCRF(1,r0)
beq 8f
bf 29,6f
std r4,0(r6)
@@ -65,7 +65,7 @@ _GLOBAL(memset)
std r4,0(r6)
addi r6,r6,8
8: cmpwi r5,0
- PPC_MTOCRF 1,r5
+ PPC_MTOCRF(1,r5)
beqlr+
bf 29,9f
stw r4,0(r6)
Index: linux-build/arch/powerpc/include/asm/ppc_asm.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/ppc_asm.h 2012-04-18 14:36:40.532207045 +1000
+++ linux-build/arch/powerpc/include/asm/ppc_asm.h 2012-04-18 14:37:46.129376142 +1000
@@ -369,7 +369,15 @@ BEGIN_FTR_SECTION \
END_FTR_SECTION_IFCLR(CPU_FTR_601)
#endif
-
+#ifdef CONFIG_PPC64
+#define MTOCRF(FXM, RS) \
+ BEGIN_FTR_SECTION_NESTED(487); \
+ mtcrf (FXM), (RS); \
+ FTR_SECTION_ELSE_NESTED(487); \
+ mtocrf (FXM), (RS); \
+ ALT_FTR_SECTION_END_NESTED_IFCLR((CPU_FTR_PPCAS_ARCH_V2), 487)
+#endif
+
/*
* This instruction is not implemented on the PPC 603 or 601; however, on
* the 403GCX and 405GP tlbia IS defined and tlbie is not.
Index: linux-build/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/cputable.h 2012-04-18 14:36:40.520206831 +1000
+++ linux-build/arch/powerpc/include/asm/cputable.h 2012-04-18 14:37:46.129376142 +1000
@@ -203,10 +203,10 @@ extern const char *powerpc_base_platform
#define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000000000000000)
#define CPU_FTR_VMX_COPY LONG_ASM_CONST(0x2000000000000000)
-#ifndef __ASSEMBLY__
-
#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN)
+#ifndef __ASSEMBLY__
+
#define MMU_FTR_PPCAS_ARCH_V2 (MMU_FTR_SLB | MMU_FTR_TLBIEL | \
MMU_FTR_16M_PAGE)
^ permalink raw reply
* [PATCH] powerpc: Use WARN instead of dump_stack when printing EEH error backtrace
From: Anton Blanchard @ 2012-04-18 5:16 UTC (permalink / raw)
To: benh, paulus, shangw, linuxppc-dev
When we get an EEH error we just print a backtrace with dump_stack
which is rather cryptic. We really should print something before
spewing out the backtrace.
Also switch from dump_stack to WARN so we get more information about
the fail - what modules were loaded, what process was running etc.
This was useful information when debugging a recent EEH subsystem bug.
The standard WARN output should also get picked up by monitoring
tools like kerneloops.
The register dump is of questionable value here but I figured it was
better to use something standard and not roll my own.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-build.orig/arch/powerpc/platforms/pseries/eeh.c 2012-04-13 10:29:53.576534339 +1000
+++ linux-build/arch/powerpc/platforms/pseries/eeh.c 2012-04-13 10:51:22.592822459 +1000
@@ -489,7 +489,7 @@ int eeh_dn_check_failure(struct device_n
* a stack trace will help the device-driver authors figure
* out what happened. So print that out.
*/
- dump_stack();
+ WARN(1, "EEH: failure detected\n");
return 1;
dn_unlock:
^ permalink raw reply
* [PATCH] powerpc: Remove old powerpc specific ptrace getregs/setregs calls
From: Anton Blanchard @ 2012-04-18 5:36 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
PowerPC has non standard getregs calls that only dump the GPRs or
FPRs and have their arguments reversed. commit e17666ba48f7 (ptrace
updates & new, better requests) in 2.6.3 deprecated them and introduced
more standard versions.
It's been about 5 years and I know of no users of the old calls so
lets remove them.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/include/asm/ptrace.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/ptrace.h 2012-04-12 11:36:25.784215556 +1000
+++ linux-build/arch/powerpc/include/asm/ptrace.h 2012-04-12 11:36:48.000619966 +1000
@@ -354,12 +354,6 @@ static inline unsigned long regs_get_ker
#define PTRACE_GETREGS64 22
#define PTRACE_SETREGS64 23
-/* (old) PTRACE requests with inverted arguments */
-#define PPC_PTRACE_GETREGS 0x99 /* Get GPRs 0 - 31 */
-#define PPC_PTRACE_SETREGS 0x98 /* Set GPRs 0 - 31 */
-#define PPC_PTRACE_GETFPREGS 0x97 /* Get FPRs 0 - 31 */
-#define PPC_PTRACE_SETFPREGS 0x96 /* Set FPRs 0 - 31 */
-
/* Calls to trace a 64bit program from a 32bit program */
#define PPC_PTRACE_PEEKTEXT_3264 0x95
#define PPC_PTRACE_PEEKDATA_3264 0x94
Index: linux-build/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/ptrace.c 2012-04-12 11:36:25.796215776 +1000
+++ linux-build/arch/powerpc/kernel/ptrace.c 2012-04-12 11:36:48.004620039 +1000
@@ -1432,40 +1432,6 @@ static long ppc_del_hwdebug(struct task_
#endif
}
-/*
- * Here are the old "legacy" powerpc specific getregs/setregs ptrace calls,
- * we mark them as obsolete now, they will be removed in a future version
- */
-static long arch_ptrace_old(struct task_struct *child, long request,
- unsigned long addr, unsigned long data)
-{
- void __user *datavp = (void __user *) data;
-
- switch (request) {
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- return copy_regset_to_user(child, &user_ppc_native_view,
- REGSET_GPR, 0, 32 * sizeof(long),
- datavp);
-
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- return copy_regset_from_user(child, &user_ppc_native_view,
- REGSET_GPR, 0, 32 * sizeof(long),
- datavp);
-
- case PPC_PTRACE_GETFPREGS: /* Get FPRs 0 - 31. */
- return copy_regset_to_user(child, &user_ppc_native_view,
- REGSET_FPR, 0, 32 * sizeof(double),
- datavp);
-
- case PPC_PTRACE_SETFPREGS: /* Set FPRs 0 - 31. */
- return copy_regset_from_user(child, &user_ppc_native_view,
- REGSET_FPR, 0, 32 * sizeof(double),
- datavp);
- }
-
- return -EPERM;
-}
-
long arch_ptrace(struct task_struct *child, long request,
unsigned long addr, unsigned long data)
{
@@ -1687,14 +1653,6 @@ long arch_ptrace(struct task_struct *chi
datavp);
#endif
- /* Old reverse args ptrace callss */
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- case PPC_PTRACE_GETFPREGS: /* Get FPRs 0 - 31. */
- case PPC_PTRACE_SETFPREGS: /* Get FPRs 0 - 31. */
- ret = arch_ptrace_old(child, request, addr, data);
- break;
-
default:
ret = ptrace_request(child, request, addr, data);
break;
Index: linux-build/arch/powerpc/kernel/ptrace32.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/ptrace32.c 2012-04-12 11:36:25.816216138 +1000
+++ linux-build/arch/powerpc/kernel/ptrace32.c 2012-04-12 11:37:33.725452160 +1000
@@ -39,30 +39,6 @@
* in exit.c or in signal.c.
*/
-/*
- * Here are the old "legacy" powerpc specific getregs/setregs ptrace calls,
- * we mark them as obsolete now, they will be removed in a future version
- */
-static long compat_ptrace_old(struct task_struct *child, long request,
- long addr, long data)
-{
- switch (request) {
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- return copy_regset_to_user(child,
- task_user_regset_view(current), 0,
- 0, 32 * sizeof(compat_long_t),
- compat_ptr(data));
-
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- return copy_regset_from_user(child,
- task_user_regset_view(current), 0,
- 0, 32 * sizeof(compat_long_t),
- compat_ptr(data));
- }
-
- return -EPERM;
-}
-
/* Macros to workout the correct index for the FPR in the thread struct */
#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
#define FPRHALF(i) (((i) - PT_FPR0) & 1)
@@ -308,8 +284,6 @@ long compat_arch_ptrace(struct task_stru
case PTRACE_SETVSRREGS:
case PTRACE_GETREGS64:
case PTRACE_SETREGS64:
- case PPC_PTRACE_GETFPREGS:
- case PPC_PTRACE_SETFPREGS:
case PTRACE_KILL:
case PTRACE_SINGLESTEP:
case PTRACE_DETACH:
@@ -322,12 +296,6 @@ long compat_arch_ptrace(struct task_stru
ret = arch_ptrace(child, request, addr, data);
break;
- /* Old reverse args ptrace callss */
- case PPC_PTRACE_GETREGS: /* Get GPRs 0 - 31. */
- case PPC_PTRACE_SETREGS: /* Set GPRs 0 - 31. */
- ret = compat_ptrace_old(child, request, addr, data);
- break;
-
default:
ret = compat_ptrace_request(child, request, addr, data);
break;
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 6:35 UTC (permalink / raw)
To: o jordan; +Cc: linuxppc-dev
In-Reply-To: <BAY163-W54EBB2437ED2068EF5AF5D03F0@phx.gbl>
On Die, 2012-04-17 at 20:49 +0100, o jordan wrote:=20
>=20
> I've been trying to get Kernel Mode Setting working on my iBook with
> Ubuntu 12.04. I can only get it working by forcing PCI mode
> (agpmode=3D-1). Setting agpmode=3D1 or a higher number just results in
> freezing and a flashing screen.
At which point? When radeon KMS initializes, or only when X starts?
> I've tried the Debian experimental kernel with the same results. I
> notice with Fedora 16 they also recommend setting agpmode=3D-1 with a
> radeon card. So I'm guessing there is no easy fix??
Probably not (AGP is flaky in general, but in particular with older
UniNorth bridges), but it might be interesting to see some kernel output
from booting without agpmode=3D-1. If you can't get it via ssh, maybe you
can via netconsole or so.
> With Userspace Mode Setting there is nolonger any 3D hardware
> acceleration
> (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 )
=46rom the Mesa upstream POV, the drivers from the 7.11 branch could be
used for this.
> CONFIG_DRM_RADEON_KMS=3Dy
> CONFIG_FB_RADEON=3Dy
Not sure it's a good idea to set both of these =3Dy: It will prevent the
radeon driver from initializing at all by default if radeonfb is active.
If you want CONFIG_FB_RADEON=3Dy, I'd suggest leaving
CONFIG_DRM_RADEON_KMS disabled. KMS can always be enabled at boot time
with radeon.modeset=3D1.
> CONFIG_FB_ATY128=3Dy
> CONFIG_FB_ATY=3Dy
There's no KMS for pre-Radeon ATI cards yet, so these are not directly
related.
> I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or
> built in. =20
I think it would only need to be built in if the radeon driver was built
in, which is not recommended.
P.S. The dri-devel list at freedesktop.org might be better for this, at
least in addition to linuxppc-dev.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Benjamin Herrenschmidt @ 2012-04-18 6:46 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20120418144629.3f02e897@kryten>
On Wed, 2012-04-18 at 14:46 +1000, Anton Blanchard wrote:
> + ALT_FTR_SECTION_END_NESTED_IFCLR((CPU_FTR_PPCAS_ARCH_V2), 487)
So if I remember properly, this means you key off if both
CPU_FTR_NOEXECUTE and CPU_FTR_NODISRALIGN are clear... is
there a point ? You make the patch simpler by only keying
on NO_EXECUTE which afaik is a power4 or later only feature no ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Anton Blanchard @ 2012-04-18 6:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1334731564.1159.2.camel@pasglop>
Hi Ben,
> So if I remember properly, this means you key off if both
> CPU_FTR_NOEXECUTE and CPU_FTR_NODISRALIGN are clear... is
> there a point ? You make the patch simpler by only keying
> on NO_EXECUTE which afaik is a power4 or later only feature no ?
Was going to do that, but noticed ARCH_V2 was used elsewhere:
arch/powerpc/kernel/sysfs.c: if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
I'm ok either way, should I respin to use CPU_FTR_NO_EXECUTE?
Anton
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Remove CONFIG_POWER4_ONLY
From: Benjamin Herrenschmidt @ 2012-04-18 6:57 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20120418165116.4bdcbbfe@kryten>
On Wed, 2012-04-18 at 16:51 +1000, Anton Blanchard wrote:
>
> arch/powerpc/kernel/sysfs.c: if
> (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
>
> I'm ok either way, should I respin to use CPU_FTR_NO_EXECUTE?
Yeah, that sysfs bit will be true if -either- of the two bits is true,
which is yet another different logic, better avoid it I think.
Cheers,
Ben.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 6:59 UTC (permalink / raw)
To: o jordan; +Cc: linuxppc-dev
In-Reply-To: <BAY163-W54EBB2437ED2068EF5AF5D03F0@phx.gbl>
On Tue, 2012-04-17 at 20:49 +0100, o jordan wrote:
> Hi list,
>
>
> Firstly let me say thanks for the great work you do!!!
>
>
> I've been trying to get Kernel Mode Setting working on my iBook with
> Ubuntu 12.04. I can only get it working by forcing PCI mode
> (agpmode=-1). Setting agpmode=1 or a higher number just results in
> freezing and a flashing screen. Does anybody know how to get it
> working fully with agp?
>
Note also that KMS doesn't afaik have the power management code that
radeonfb has for those old Mac chipsets, so suspend/resume won't work.
Cheers,
Ben.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 7:42 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334730915.5989.265.camel__41553.0639271767$1334731329$gmane$org@thor.local>
Michel Dänzer <michel@daenzer.net> writes:
> Not sure it's a good idea to set both of these =y: It will prevent the
> radeon driver from initializing at all by default if radeonfb is active.
You can say video=radeonfb:off.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 7:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334732346.1159.5.camel__22339.9641145535$1334732429$gmane$org@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Note also that KMS doesn't afaik have the power management code that
> radeonfb has for those old Mac chipsets, so suspend/resume won't work.
How hard would it be to add it?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* RE: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
From: Huang Changming-R66093 @ 2012-04-18 7:46 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVBb-CHa=PPa5446aVdQ323aBdv-9UTXx1SbkY2ArT14Q@mail.gmail.com>
Yes, I tested with the latest Linux kernel, with my patch, the NOR and NAND=
MTD can work well.
Best Regards
Jerry Huang
> -----Original Message-----
> From: Tabi Timur-B04825
> Sent: Wednesday, April 18, 2012 2:10 AM
> To: Huang Changming-R66093
> Cc: linuxppc-dev@lists.ozlabs.org; Kumar Gala
> Subject: Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds
> flash
>=20
> On Tue, Apr 17, 2012 at 4:15 AM, <Chang-Ming.Huang@freescale.com> wrote:
>=20
> > diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
> > b/arch/powerpc/platforms/85xx/p1022_ds.c
> > index e74b7cd..0db3a7e 100644
> > --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> > +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> > @@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
> > =A0static struct of_device_id __initdata p1022_ds_ids[] =3D {
> > =A0 =A0 =A0 =A0/* So that the DMA channel nodes can be probed individua=
lly: */
> > =A0 =A0 =A0 =A0{ .compatible =3D "fsl,eloplus-dma", },
> > + =A0 =A0 =A0 { .compatible =3D "fsl,p1022-elbc", },
> > =A0 =A0 =A0 =A0{},
> > =A0};
>=20
>=20
> Have you actually tested this with an upstream kernel? p1022_ds_ids[] is
> broken upstream, so adding a new line won't work.
>=20
> Take a look at http://patchwork.ozlabs.org/patch/128533/
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 7:52 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m2ty0hbi4j.fsf@igel.home>
On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > Not sure it's a good idea to set both of these =3Dy: It will prevent th=
e
> > radeon driver from initializing at all by default if radeonfb is active=
.
>=20
> You can say video=3Dradeonfb:off.
I know, I'm referring to the default behaviour without any relevant
kernel command line options.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Andreas Schwab @ 2012-04-18 7:54 UTC (permalink / raw)
To: Michel Dänzer; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334730915.5989.265.camel__41553.0639271767$1334731329$gmane$org@thor.local>
Michel Dänzer <michel@daenzer.net> writes:
> Probably not (AGP is flaky in general, but in particular with older
> UniNorth bridges), but it might be interesting to see some kernel output
> from booting without agpmode=-1. If you can't get it via ssh, maybe you
> can via netconsole or so.
While logging into KDE:
radeon 0000:00:10.0: GPU lockup CP stall for more than 10064msec
GPU lockup (waiting for 0x000003EE last fence id 0x000003ED)
radeon: wait for empty RBBM fifo failed ! Bad things might happen.
Failed to wait GUI idle while programming pipes. Bad things might happen.
radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: GPU reset succeed
radeon 0000:00:10.0: GPU reset succeed
radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137
radeon 0000:00:10.0: GPU reset succeed
radeon: wait for empty RBBM fifo failed ! Bad things might happen.
Failed to wait GUI idle while programming pipes. Bad things might happen.
After that is is dead. GPU lockup appears to be a common problem with
the radeon driver.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 8:02 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m2liltbhkp.fsf@igel.home>
On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote:=20
> Michel D=C3=A4nzer <michel@daenzer.net> writes:
>=20
> > Probably not (AGP is flaky in general, but in particular with older
> > UniNorth bridges), but it might be interesting to see some kernel outpu=
t
> > from booting without agpmode=3D-1. If you can't get it via ssh, maybe y=
ou
> > can via netconsole or so.
>=20
> While logging into KDE:
>=20
> radeon 0000:00:10.0: GPU lockup CP stall for more than 10064msec
> GPU lockup (waiting for 0x000003EE last fence id 0x000003ED)
> radeon: wait for empty RBBM fifo failed ! Bad things might happen.
> Failed to wait GUI idle while programming pipes. Bad things might happen.
> radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: GPU reset succeed
> radeon 0000:00:10.0: GPU reset succeed
> radeon 0000:00:10.0: (r300_asic_reset:414) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:433) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: (r300_asic_reset:445) RBBM_STATUS=3D0x8802C137
> radeon 0000:00:10.0: GPU reset succeed
> radeon: wait for empty RBBM fifo failed ! Bad things might happen.
> Failed to wait GUI idle while programming pipes. Bad things might happen.
That's even with agpmode=3D1?
Note that I'm interested in seeing the full dmesg or at least all
agp/drm/radeon related messages.
> After that is is dead.
The whole machine? That's probably due to something going wrong (e.g. an
MCE) while trying to reset the GPU. I fixed one such problem recently,
but it's still not as reliable as on x86 unfortunately.
> GPU lockup appears to be a common problem with the radeon driver.
It's what happens when anything goes wrong with the GPU. If it doesn't
happen with agpmode=3D-1, it's probably an AGP related coherency issue.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* RE: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
From: Huang Changming-R66093 @ 2012-04-18 8:02 UTC (permalink / raw)
To: Huang Changming-R66093, Tabi Timur-B04825; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C079D0B@039-SN1MPN1-002.039d.mgd.msft.net>
But, I observed the Call Trace, but the partition can be parsed correctly.
Maybe your patch can fix this Call Trace.
Best Regards
Jerry Huang
> -----Original Message-----
> From: linuxppc-dev-bounces+r66093=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+r66093=3Dfreescale.com@lists.ozlabs.org] On
> Behalf Of Huang Changming-R66093
> Sent: Wednesday, April 18, 2012 3:47 PM
> To: Tabi Timur-B04825
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds
> flash
>=20
> Yes, I tested with the latest Linux kernel, with my patch, the NOR and
> NAND MTD can work well.
>=20
> Best Regards
> Jerry Huang
>=20
>=20
> > -----Original Message-----
> > From: Tabi Timur-B04825
> > Sent: Wednesday, April 18, 2012 2:10 AM
> > To: Huang Changming-R66093
> > Cc: linuxppc-dev@lists.ozlabs.org; Kumar Gala
> > Subject: Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for
> > p1022ds flash
> >
> > On Tue, Apr 17, 2012 at 4:15 AM, <Chang-Ming.Huang@freescale.com>
> wrote:
> >
> > > diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
> > > b/arch/powerpc/platforms/85xx/p1022_ds.c
> > > index e74b7cd..0db3a7e 100644
> > > --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> > > +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> > > @@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
> > > =A0static struct of_device_id __initdata p1022_ds_ids[] =3D {
> > > =A0 =A0 =A0 =A0/* So that the DMA channel nodes can be probed individ=
ually:
> > > */
> > > =A0 =A0 =A0 =A0{ .compatible =3D "fsl,eloplus-dma", },
> > > + =A0 =A0 =A0 { .compatible =3D "fsl,p1022-elbc", },
> > > =A0 =A0 =A0 =A0{},
> > > =A0};
> >
> >
> > Have you actually tested this with an upstream kernel? p1022_ds_ids[]
> > is broken upstream, so adding a new line won't work.
> >
> > Take a look at http://patchwork.ozlabs.org/patch/128533/
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
From: Valentin Ilie @ 2012-04-18 9:33 UTC (permalink / raw)
To: geoff; +Cc: cbe-oss-dev, Valentin Ilie, linuxppc-dev, linux-kernel
Fixed some checkpatch warnings. (review)
Last patch didn't compile.
Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com>
---
drivers/ps3/ps3av.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index a409fa0..636e618 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -338,7 +338,7 @@ int ps3av_do_pkt(u32 cid, u16 send_len, size_t usr_buf_size,
mutex_unlock(&ps3av->mutex);
return 0;
- err:
+err:
mutex_unlock(&ps3av->mutex);
printk(KERN_ERR "%s: failed cid:%x res:%d\n", __func__, cid, res);
return res;
@@ -477,7 +477,6 @@ int ps3av_set_audio_mode(u32 ch, u32 fs, u32 word_bits, u32 format, u32 source)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_audio_mode);
static int ps3av_set_videomode(void)
@@ -870,21 +869,18 @@ int ps3av_set_video_mode(int id)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
int ps3av_get_auto_mode(void)
{
return ps3av_auto_videomode(&ps3av->av_hw_conf);
}
-
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
int ps3av_get_mode(void)
{
return ps3av ? ps3av->ps3av_mode : 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_get_mode);
/* get resolution by video_mode */
@@ -902,7 +898,6 @@ int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
*yres = video_mode_table[id].y;
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mode2res);
/* mute */
@@ -911,7 +906,6 @@ int ps3av_video_mute(int mute)
return ps3av_set_av_video_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mute);
/* mute analog output only */
@@ -935,7 +929,6 @@ int ps3av_audio_mute(int mute)
return ps3av_set_audio_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int __devinit ps3av_probe(struct ps3_system_bus_device *dev)
--
1.7.9.5
^ permalink raw reply related
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 10:20 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334736133.5989.278.camel@thor.local>
On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
>
> > GPU lockup appears to be a common problem with the radeon driver.
>
> It's what happens when anything goes wrong with the GPU. If it doesn't
> happen with agpmode=-1, it's probably an AGP related coherency issue.
I had some success hacking the DRM to do an in_le32 from the ring head
after writing it. Just a gross hack but it seemed to help on a G5.
I suspect there's a fundamental design issue with apple bridge in that
the CPU to memory path isn't coherent at all with the GPU to memory path
ie. even vs. cache flush instructions (ie buffers in the memory
controllers can still be out of sync).
Darwin does some gross hacks to work around that, some of them visible
in the AGP drivers, some burried in the Apple driver, I don't know for
sure. It's possible that they end up mapping all AGP memory as cache
inhibited, but we can't do that because of our linear mapping.
Cheers,
Ben.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 10:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334744414.3143.2.camel@pasglop>
On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:=20
> On Wed, 2012-04-18 at 10:02 +0200, Michel D=C3=A4nzer wrote:
> >=20
> > > GPU lockup appears to be a common problem with the radeon driver.
> >=20
> > It's what happens when anything goes wrong with the GPU. If it doesn't
> > happen with agpmode=3D-1, it's probably an AGP related coherency issue.=
=20
>=20
> I had some success hacking the DRM to do an in_le32 from the ring head
> after writing it. Just a gross hack but it seemed to help on a G5.
AFAICT radeon_ring_commit() does that already:
DRM_MEMORYBARRIER();
WREG32(ring->wptr_reg, (ring->wptr << ring->ptr_reg_shift) & ring->=
ptr_reg_mask);
(void)RREG32(ring->wptr_reg);
We added the readback about a decade ago. :)
> I suspect there's a fundamental design issue with apple bridge in that
> the CPU to memory path isn't coherent at all with the GPU to memory path
> ie. even vs. cache flush instructions (ie buffers in the memory
> controllers can still be out of sync).
>=20
> Darwin does some gross hacks to work around that, some of them visible
> in the AGP drivers, some burried in the Apple driver, I don't know for
> sure. It's possible that they end up mapping all AGP memory as cache
> inhibited, but we can't do that because of our linear mapping.
We are doing that though...
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 10:35 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <m2pqb5bhyo.fsf@igel.home>
On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Note also that KMS doesn't afaik have the power management code that
> > radeonfb has for those old Mac chipsets, so suspend/resume won't work.
>
> How hard would it be to add it?
The code itself is relatively self contained, but the KMS power
management side is a bit ... messy :-) So the real deal is to figure out
how best to "hook it up" there.
There's some duplication
Cheers,
Ben.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Benjamin Herrenschmidt @ 2012-04-18 10:37 UTC (permalink / raw)
To: Andreas Schwab; +Cc: o jordan, linuxppc-dev
In-Reply-To: <1334745338.3143.3.camel@pasglop>
On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> >
> > > Note also that KMS doesn't afaik have the power management code that
> > > radeonfb has for those old Mac chipsets, so suspend/resume won't work.
> >
> > How hard would it be to add it?
>
> The code itself is relatively self contained, but the KMS power
> management side is a bit ... messy :-) So the real deal is to figure out
> how best to "hook it up" there.
>
> There's some duplication
Argh... bloody x220 touchpad...
So I was saying, there's also some duplication in the area of dynamic
clocks configuration. Some of this could be an issue as afaik, to work
reliably, the suspend/resume code really wants the stuff to be setup
exactly the way the code in radeon_pm does....
But it's definitely worth trying to port it over.
Cheers,
Ben.
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andreas Schwab, o jordan, linuxppc-dev
In-Reply-To: <1334745292.5989.291.camel@thor.local>
On Mit, 2012-04-18 at 12:34 +0200, Michel D=C3=A4nzer wrote:=20
> On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:=20
> >=20
> > I suspect there's a fundamental design issue with apple bridge in that
> > the CPU to memory path isn't coherent at all with the GPU to memory pat=
h
> > ie. even vs. cache flush instructions (ie buffers in the memory
> > controllers can still be out of sync).
> >=20
> > Darwin does some gross hacks to work around that, some of them visible
> > in the AGP drivers, some burried in the Apple driver, I don't know for
> > sure. It's possible that they end up mapping all AGP memory as cache
> > inhibited, but we can't do that because of our linear mapping.
>=20
> We are doing that though...
This reminded me, I've been running with the patch below, but I'm not
sure it makes any difference. Maybe Andreas or Jordan can try it.
diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.=
h
index 416e12c..eb34fa5 100644
--- a/arch/powerpc/include/asm/agp.h
+++ b/arch/powerpc/include/asm/agp.h
@@ -2,9 +2,12 @@
#define _ASM_POWERPC_AGP_H
#ifdef __KERNEL__
=20
+#include <asm/cacheflush.h>
#include <asm/io.h>
=20
-#define map_page_into_agp(page)
+#define map_page_into_agp(page) \
+ flush_dcache_range((unsigned long)page_address(page), \
+ (unsigned long)page_address(page) + PAGE_SIZE)
#define unmap_page_from_agp(page)
#define flush_agp_cache() mb()
=20
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-18 10:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, o jordan, Andreas Schwab
In-Reply-To: <1334745439.3143.5.camel@pasglop>
On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote:=20
> On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote:
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> > >=20
> > > > Note also that KMS doesn't afaik have the power management code tha=
t
> > > > radeonfb has for those old Mac chipsets, so suspend/resume won't wo=
rk.
> > >=20
> > > How hard would it be to add it?
> >=20
> > The code itself is relatively self contained, but the KMS power
> > management side is a bit ... messy :-)
That's an interesting way to put it, given the hacks to make it work
between radeonfb and uninorth_agp. :) (Which are complicating making at
least hibernation work with KMS on uninorth_agp)
In contrast, radeon KMS uses the standard Linux device suspend/resume
hooks.
> > So the real deal is to figure out how best to "hook it up" there.
> >=20
> > There's some duplication=20
>=20
> Argh... bloody x220 touchpad...
>=20
> So I was saying, there's also some duplication in the area of dynamic
> clocks configuration. Some of this could be an issue as afaik, to work
> reliably, the suspend/resume code really wants the stuff to be setup
> exactly the way the code in radeon_pm does....
Are you referring to radeon_pm in radeonfb or radeon KMS?
Most of the latter isn't used on PPC laptops because it relies on an x86
video BIOS.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ 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