[PATCH 1/2] powerpc: Remove empty giveup_altivec function on book3e CPUs
Use an empty inline instead of an empty function to implement
giveup_altivec on book3e CPUs, similar to flush_altivec_to_thread.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux-build/arch/powerpc/include/asm/switch_to.h
===
--- linux-build.orig/arch/powerpc/include/asm/switch_to.h 2012-04-16
12:56:11.0 +1000
+++ linux-build/arch/powerpc/include/asm/switch_to.h2012-04-16
12:56:45.149313158 +1000
@@ -21,7 +21,6 @@ extern void disable_kernel_fp(void);
extern void enable_kernel_fp(void);
extern void flush_fp_to_thread(struct task_struct *);
extern void enable_kernel_altivec(void);
-extern void giveup_altivec(struct task_struct *);
extern void load_up_altivec(struct task_struct *);
extern int emulate_altivec(struct pt_regs *);
extern void __giveup_vsx(struct task_struct *);
@@ -40,10 +39,14 @@ static inline void discard_lazy_cpu_stat
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
+extern void giveup_altivec(struct task_struct *);
#else
static inline void flush_altivec_to_thread(struct task_struct *t)
{
}
+static inline void giveup_altivec(struct task_struct *t)
+{
+}
#endif
#ifdef CONFIG_VSX
Index: linux-build/arch/powerpc/kernel/head_44x.S
===
--- linux-build.orig/arch/powerpc/kernel/head_44x.S 2012-04-16
12:56:11.976708702 +1000
+++ linux-build/arch/powerpc/kernel/head_44x.S 2012-04-16 12:56:45.153313231
+1000
@@ -778,14 +778,6 @@ _GLOBAL(__fixup_440A_mcheck)
blr
/*
- * extern void giveup_altivec(struct task_struct *prev)
- *
- * The 44x core does not have an AltiVec unit.
- */
-_GLOBAL(giveup_altivec)
- blr
-
-/*
* extern void giveup_fpu(struct task_struct *prev)
*
* The 44x core does not have an FPU.
Index: linux-build/arch/powerpc/kernel/head_fsl_booke.S
===
--- linux-build.orig/arch/powerpc/kernel/head_fsl_booke.S 2012-04-16
12:56:11.940708046 +1000
+++ linux-build/arch/powerpc/kernel/head_fsl_booke.S2012-04-16
12:56:45.153313231 +1000
@@ -874,14 +874,6 @@ _GLOBAL(__setup_e500mc_ivors)
sync
blr
-/*
- * extern void giveup_altivec(struct task_struct *prev)
- *
- * The e500 core does not have an AltiVec unit.
- */
-_GLOBAL(giveup_altivec)
- blr
-
#ifdef CONFIG_SPE
/*
* extern void giveup_spe(struct task_struct *prev)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Optimise enable_kernel_altivec
Add two optimisations to enable_kernel_altivec:
- enable_kernel_altivec has already determined if we need to
save the previous task's state but we call giveup_altivec
in both cases, requiring an extra branch in giveup_altivec. Create
giveup_altivec_notask which only turns on the VMX bit in the
MSR.
- We write the VMX MSR bit each time we call enable_kernel_altivec
even it was already set. Check the bit and branch out if we have
already set it. The classic case for this is vectored IO
where we have to copy multiple buffers to or from userspace.
The following testcase was used to confirm this patch improves
performance:
http://ozlabs.org/~anton/junkcode/copy_to_user.c
Since the current breakpoint for using VMX in copy_tofrom_user is
4096 bytes, I'm using buffers of 4096 + 1 cacheline (4224) bytes.
A benchmark of 16 entry readvs (-s 16):
time copy_to_user -l 4224 -s 16 -i 100
completes 5.2% faster on a POWER7 PS700.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux-build/arch/powerpc/kernel/process.c
===
--- linux-build.orig/arch/powerpc/kernel/process.c 2012-04-16
11:35:19.0 +1000
+++ linux-build/arch/powerpc/kernel/process.c 2012-04-16 12:56:47.489355793
+1000
@@ -124,7 +124,7 @@ void enable_kernel_altivec(void)
if (current-thread.regs (current-thread.regs-msr MSR_VEC))
giveup_altivec(current);
else
- giveup_altivec(NULL); /* just enable AltiVec for kernel -
force */
+ giveup_altivec_notask();
#else
giveup_altivec(last_task_used_altivec);
#endif /* CONFIG_SMP */
Index: linux-build/arch/powerpc/kernel/vector.S
===
--- linux-build.orig/arch/powerpc/kernel/vector.S 2012-04-12
20:06:21.0 +1000
+++ linux-build/arch/powerpc/kernel/vector.S2012-04-16 12:56:47.489355793
+1000
@@ -89,6 +89,16 @@ _GLOBAL(load_up_altivec)
/* restore registers and return */
blr
+_GLOBAL(giveup_altivec_notask)
+ mfmsr r3
+ andis. r4,r3,MSR_VEC@h
+ bnelr /* Already enabled? */
+ orisr3,r3,MSR_VEC@h
+ SYNC
+ MTMSRD(r3) /* enable use of VMX now */
+ isync
+ blr
+
/*
* giveup_altivec(tsk)
* Disable VMX for the task given as the argument,
Index: linux-build/arch/powerpc/include/asm/switch_to.h
===
--- linux-build.orig/arch/powerpc/include/asm/switch_to.h 2012-04-16
12:56:45.149313158 +1000
+++ linux-build/arch/powerpc/include/asm/switch_to.h2012-04-16
12:56:47.489355793 +1000
@@ -40,6 +40,7 @@ static inline void discard_lazy_cpu_stat
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
extern void giveup_altivec(struct task_struct *);
+extern void giveup_altivec_notask(void);
#else
static inline void flush_altivec_to_thread(struct task_struct *t)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
On Sun, Apr 15, 2012 at 11:52 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h provide a Kconfig symbol which architectures must select in order to include gpio.h and for other architectures just provide the trivial implementation directly. This makes it much easier to do gpiolib updates and is also a step towards making gpiolib APIs available on every architecture. For architectures with existing boilerplate code leave a stub header in place which warns on direct inclusion of asm/gpio.h and includes linux/gpio.h to catch code that's doing this. Direct inclusion of asm/gpio.h has long been deprecated. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- arch/alpha/include/asm/gpio.h | 59 ++ arch/arm/Kconfig | 1 + arch/avr32/Kconfig | 1 + arch/blackfin/Kconfig | 1 + arch/ia64/include/asm/gpio.h | 59 ++ arch/m68k/Kconfig.cpu | 1 + arch/microblaze/include/asm/gpio.h | 57 ++--- arch/mips/Kconfig | 1 + arch/openrisc/include/asm/gpio.h | 69 ++- arch/powerpc/include/asm/gpio.h | 57 ++--- arch/sh/Kconfig | 1 + arch/sparc/include/asm/gpio.h | 40 ++--- arch/unicore32/Kconfig | 1 + arch/x86/include/asm/gpio.h | 57 ++--- arch/xtensa/include/asm/gpio.h | 60 ++- drivers/gpio/Kconfig | 8 include/linux/gpio.h | 34 + 17 files changed, 81 insertions(+), 426 deletions(-) This looks good but I think we need to page the alpha, ia64, m68k, microblaze, openrisc etc subarch maintainers on this patch so they have their say. Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [44x][KEXEC] Fix/Initialize PID to kernel PID before the TLB search
Initialize the PID register with kernel pid (0) before we start setting the TLB mapping for KEXEC. Also set the MMUCR[TID] to kernel PID. This was spotted while testing the kexec on ISS for 47x. ISS doesn't return a successful tlbsx for a kernel address with PID set to a user PID. Though the hardware/qemu/simics work fine. This patch is harmless and initializes the PID to 0 (kernel PID) which is usually the case during a normal kernel boot. This would fix the kexec on ISS for 440. I have tested this patch on sequoia board. Signed-off-by: Suzuki K Poulose suz...@in.ibm.com Cc: Josh Boyer jwbo...@us.ibm.com --- arch/powerpc/kernel/misc_32.S |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 7cd07b4..d7e05d2 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -761,8 +761,12 @@ relocate_new_kernel: mr r30, r4 mr r31, r5 - /* Load our MSR_IS and TID to MMUCR for TLB search */ - mfspr r3,SPRN_PID + /* +* Load the PID with kernel PID (0). +* Also load our MSR_IS and TID to MMUCR for TLB search. +*/ + li r3, 0 + mtspr SPRN_PID, r3 mfmsr r4 andi. r4,r4,MSR_IS@l beq wmmucr ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
On Mon, Apr 16, 2012 at 09:21:58AM +0200, Linus Walleij wrote: This looks good but I think we need to page the alpha, ia64, m68k, microblaze, openrisc etc subarch maintainers on this patch so they have their say. That's why I CCed linux-arch, to get all the architecture maintainers included. vger would get upset if I CCed everyone individually. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
On Mon, Apr 16, 2012 at 10:15 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Apr 16, 2012 at 09:21:58AM +0200, Linus Walleij wrote: This looks good but I think we need to page the alpha, ia64, m68k, microblaze, openrisc etc subarch maintainers on this patch so they have their say. That's why I CCed linux-arch, to get all the architecture maintainers included. vger would get upset if I CCed everyone individually. Oh I missed it. I looped in a few maintainers and arch lists anyway. Acked-by: Linus Walleij linus.wall...@linaro.org Thanks! Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] Kdump support for 47x
The following series implements Kexec/Kdump support for PPC_47x based platforms. Doesn't support SMP yet. I have tested these patches on the following simulators: 1) simics 2) IBM ISS for ppc476. Changes since V1: * Initialize the SPRN_PID to kernel pid (0) before the TLB operations in setup_map_47x --- Suzuki K. Poulose (2): [47x] Enable CRASH_DUMP [47x] Kernel support for KEXEC arch/powerpc/Kconfig |4 - arch/powerpc/kernel/misc_32.S | 195 - 2 files changed, 191 insertions(+), 8 deletions(-) -- Suzuki K. Poulose ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] [47x] Kernel support for KEXEC
This patch adds support for creating 1:1 mapping for the PPC_47x during a KEXEC. The implementation is similar to that of the PPC440x which is described here : http://patchwork.ozlabs.org/patch/104323/ PPC_47x MMU : The 47x uses Unified TLB 1024 entries, with 4-way associative mapping (4 x 256 entries). The index to be used is calculated by the MMU by hashing the PID, EPN and TS. The software can choose to specify the way by setting bit 0(enable way select) and the way in bits 1-2 in the TLB Word 0. Implementation: The patch erases all the UTLB entries which includes the tlb covering the mapping for our code. The shadow TLB caches the mapping for the running code which helps us to continue the execution until we do isync/rfi. We then create a tmp mapping for the current code in the other address space (TS) and switch to it. Then we create a 1:1 mapping(EPN=RPN) for 0-2GiB in the original address space and switch to the new mapping. TODO: Add SMP support. Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com --- arch/powerpc/Kconfig |2 arch/powerpc/kernel/misc_32.S | 195 - 2 files changed, 190 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 613eacf..4f64860 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -351,7 +351,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE config KEXEC bool kexec system call (EXPERIMENTAL) - depends on (PPC_BOOK3S || FSL_BOOKE || (44x !SMP !PPC_47x)) EXPERIMENTAL + depends on (PPC_BOOK3S || FSL_BOOKE || (44x !SMP)) EXPERIMENTAL help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index d7e05d2..386d57f 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -738,8 +738,23 @@ relocate_new_kernel: mr r5, r31 li r0, 0 -#elif defined(CONFIG_44x) !defined(CONFIG_PPC_47x) +#elif defined(CONFIG_44x) + /* Save our parameters */ + mr r29, r3 + mr r30, r4 + mr r31, r5 + +#ifdef CONFIG_PPC_47x + /* Check for 47x cores */ + mfspr r3,SPRN_PVR + srwir3,r3,16 + cmplwi cr0,r3,PVR_476@h + beq setup_map_47x + cmplwi cr0,r3,PVR_476_ISS@h + beq setup_map_47x +#endif /* CONFIG_PPC_47x */ + /* * Code for setting up 1:1 mapping for PPC440x for KEXEC * @@ -753,13 +768,8 @@ relocate_new_kernel: * 5) Invalidate the tmp mapping. * * - Based on the kexec support code for FSL BookE - * - Doesn't support 47x yet. * */ - /* Save our parameters */ - mr r29, r3 - mr r30, r4 - mr r31, r5 /* * Load the PID with kernel PID (0). @@ -904,6 +914,179 @@ next_tlb: li r3, 0 tlbwe r3, r24, PPC44x_TLB_PAGEID sync + b ppc44x_map_done + +#ifdef CONFIG_PPC_47x + + /* 1:1 mapping for 47x */ + +setup_map_47x: + + /* +* Load the kernel pid (0) to PID and also to MMUCR[TID]. +* Also set the MSR IS-MMUCR STS +*/ + li r3, 0 + mtspr SPRN_PID, r3/* Set PID */ + mfmsr r4 /* Get MSR */ + andi. r4, r4, MSR_IS@l/* TS=1? */ + beq 1f /* If not, leave STS=0 */ + orisr3, r3, PPC47x_MMUCR_STS@h /* Set STS=1 */ +1: mtspr SPRN_MMUCR, r3 /* Put MMUCR */ + sync + + /* Find the entry we are running from */ + bl 2f +2: mflrr23 + tlbsx r23, 0, r23 + tlbre r24, r23, 0 /* TLB Word 0 */ + tlbre r25, r23, 1 /* TLB Word 1 */ + tlbre r26, r23, 2 /* TLB Word 2 */ + + + /* +* Invalidates all the tlb entries by writing to 256 RPNs(r4) +* of 4k page size in all 4 ways (0-3 in r3). +* This would invalidate the entire UTLB including the one we are +* running from. However the shadow TLB entries would help us +* to continue the execution, until we flush them (rfi/isync). +*/ + addis r3, 0, 0x8000 /* specify the way */ + addir4, 0, 0/* TLB Word0 = (EPN=0, VALID = 0) */ + addir5, 0, 0 + b clear_utlb_entry + + /* Align the loop to speed things up. from head_44x.S */ + .align 6 + +clear_utlb_entry: + + tlbwe r4, r3, 0 + tlbwe r5, r3, 1 + tlbwe r5, r3, 2 + addis r3, r3, 0x2000 /* Increment the way */ + cmpwi r3, 0 + bne clear_utlb_entry + addis r3, 0, 0x8000 + addis r4, r4, 0x100
[PATCH 2/2] [47x] Enable CRASH_DUMP
Now that we have KEXEC and relocatable kernel working on 47x (!SMP) enable CRASH_DUMP. Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com --- arch/powerpc/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 4f64860..629543a 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -368,7 +368,7 @@ config KEXEC config CRASH_DUMP bool Build a kdump crash kernel - depends on PPC64 || 6xx || FSL_BOOKE || (44x !SMP !PPC_47x) + depends on PPC64 || 6xx || FSL_BOOKE || (44x !SMP) select RELOCATABLE if PPC64 || 44x select DYNAMIC_MEMSTART if FSL_BOOKE help ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]
Paul Gortmaker paul.gortma...@windriver.com wrote: The following shows up in chroma_defconfig: CC arch/powerpc/sysdev/scom.o arch/powerpc/sysdev/scom.c: In function 'scom_debug_init': arch/powerpc/sysdev/scom.c:182:36: error: 'powerpc_debugfs_root' undeclared (first use in this function) arch/powerpc/sysdev/scom.c:182:36: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [arch/powerpc/sysdev/scom.o] Error 1 make[1]: *** [arch/powerpc/sysdev/scom.o] Error 2 A bisect leads to commit 9ffc93f203c18a70623f21950f1dd473c9ec48cd Remove all #inclusions of asm/system.h Add the debug header which contains powerpc_debugfs_root. Cc: David Howells dhowe...@redhat.com Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com Acked-by: David Howells dhowe...@redhat.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 13/17] KVM: PPC: Allow book3s_hv guests to use SMT processor modes
On 29.06.2011, at 12:23, Paul Mackerras wrote: This lifts the restriction that book3s_hv guests can only run one hardware thread per core, and allows them to use up to 4 threads per core on POWER7. The host still has to run single-threaded. This capability is advertised to qemu through a new KVM_CAP_PPC_SMT capability. The return value of the ioctl querying this capability is the number of vcpus per virtual CPU core (vcore), currently 4. To use this, the host kernel should be booted with all threads active, and then all the secondary threads should be offlined. This will put the secondary threads into nap mode. KVM will then wake them from nap mode and use them for running guest code (while they are still offline). To wake the secondary threads, we send them an IPI using a new xics_wake_cpu() function, implemented in arch/powerpc/sysdev/xics/icp-native.c. In other words, at this stage we assume that the platform has a XICS interrupt controller and we are using icp-native.c to drive it. Since the woken thread will need to acknowledge and clear the IPI, we also export the base physical address of the XICS registers using kvmppc_set_xics_phys() for use in the low-level KVM book3s code. When a vcpu is created, it is assigned to a virtual CPU core. The vcore number is obtained by dividing the vcpu number by the number of threads per core in the host. This number is exported to userspace via the KVM_CAP_PPC_SMT capability. If qemu wishes to run the guest in single-threaded mode, it should make all vcpu numbers be multiples of the number of threads per core. We distinguish three states of a vcpu: runnable (i.e., ready to execute the guest), blocked (that is, idle), and busy in host. We currently implement a policy that the vcore can run only when all its threads are runnable or blocked. This way, if a vcpu needs to execute elsewhere in the kernel or in qemu, it can do so without being starved of CPU by the other vcpus. When a vcore starts to run, it executes in the context of one of the vcpu threads. The other vcpu threads all go to sleep and stay asleep until something happens requiring the vcpu thread to return to qemu, or to wake up to run the vcore (this can happen when another vcpu thread goes from busy in host state to blocked). It can happen that a vcpu goes from blocked to runnable state (e.g. because of an interrupt), and the vcore it belongs to is already running. In that case it can start to run immediately as long as the none of the vcpus in the vcore have started to exit the guest. We send the next free thread in the vcore an IPI to get it to start to execute the guest. It synchronizes with the other threads via the vcore-entry_exit_count field to make sure that it doesn't go into the guest if the other vcpus are exiting by the time that it is ready to actually enter the guest. Note that there is no fixed relationship between the hardware thread number and the vcpu number. Hardware threads are assigned to vcpus as they become runnable, so we will always use the lower-numbered hardware threads in preference to higher-numbered threads if not all the vcpus in the vcore are runnable, regardless of which vcpus are runnable. Signed-off-by: Paul Mackerras pau...@samba.org [...] diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h index 5616e39..0d6d569 100644 --- a/arch/powerpc/include/asm/kvm_host.h +++ b/arch/powerpc/include/asm/kvm_host.h @@ -25,10 +25,14 @@ #include linux/interrupt.h #include linux/types.h #include linux/kvm_types.h +#include linux/threads.h +#include linux/spinlock.h #include linux/kvm_para.h #include asm/kvm_asm.h +#include asm/processor.h -#define KVM_MAX_VCPUS 1 +#define KVM_MAX_VCPUSNR_CPUS +#define KVM_MAX_VCORES NR_CPUS Hey Paul, While trying to trace down why some BookE systems were only able to do as many guest vcpus as there were host cpus available, we stumbled over this one. Is there any limitation on book3s_hv that would limit the available vcpus to configured host vcpus? Or could we just make this a static define like on x86? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [ORLinux] [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h
Acked-by: Jonas Bonn jo...@southpole.se (for OpenRISC) On Mon, 2012-04-16 at 09:21 +0200, Linus Walleij wrote: On Sun, Apr 15, 2012 at 11:52 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h provide a Kconfig symbol which architectures must select in order to include gpio.h and for other architectures just provide the trivial implementation directly. This makes it much easier to do gpiolib updates and is also a step towards making gpiolib APIs available on every architecture. For architectures with existing boilerplate code leave a stub header in place which warns on direct inclusion of asm/gpio.h and includes linux/gpio.h to catch code that's doing this. Direct inclusion of asm/gpio.h has long been deprecated. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- arch/alpha/include/asm/gpio.h | 59 ++ arch/arm/Kconfig |1 + arch/avr32/Kconfig |1 + arch/blackfin/Kconfig |1 + arch/ia64/include/asm/gpio.h | 59 ++ arch/m68k/Kconfig.cpu |1 + arch/microblaze/include/asm/gpio.h | 57 ++--- arch/mips/Kconfig |1 + arch/openrisc/include/asm/gpio.h | 69 ++- arch/powerpc/include/asm/gpio.h| 57 ++--- arch/sh/Kconfig|1 + arch/sparc/include/asm/gpio.h | 40 ++--- arch/unicore32/Kconfig |1 + arch/x86/include/asm/gpio.h| 57 ++--- arch/xtensa/include/asm/gpio.h | 60 ++- drivers/gpio/Kconfig |8 include/linux/gpio.h | 34 + 17 files changed, 81 insertions(+), 426 deletions(-) This looks good but I think we need to page the alpha, ia64, m68k, microblaze, openrisc etc subarch maintainers on this patch so they have their say. Yours, Linus Walleij ___ Linux mailing list li...@lists.openrisc.net http://lists.openrisc.net/listinfo/linux ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 13/17] KVM: PPC: Allow book3s_hv guests to use SMT processor modes
On Mon, Apr 16, 2012 at 11:45:44AM +0200, Alexander Graf wrote: While trying to trace down why some BookE systems were only able to do as many guest vcpus as there were host cpus available, we stumbled over this one. Is there any limitation on book3s_hv that would limit the available vcpus to configured host vcpus? Or could we just make this a static define like on x86? There is no limitation. I did it like that so that we would be able to have a large number of vcpus on kernels configured for large systems, while not using up large amounts of memory if the kernel is configured for a small system. The memory consumption is 8 bytes per vcore in each struct kvm if book3s_hv is configured. We can make it a fixed constant if you like, but then the question is how do you choose that constant so as to allow us to have many vcpus on large systems but still not waste too much memory on small systems. Or it could be max(N, NR_CPUS) for a suitable N (e.g. 16 or 32). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 13/17] KVM: PPC: Allow book3s_hv guests to use SMT processor modes
On 16.04.2012, at 14:13, Paul Mackerras wrote: On Mon, Apr 16, 2012 at 11:45:44AM +0200, Alexander Graf wrote: While trying to trace down why some BookE systems were only able to do as many guest vcpus as there were host cpus available, we stumbled over this one. Is there any limitation on book3s_hv that would limit the available vcpus to configured host vcpus? Or could we just make this a static define like on x86? There is no limitation. I did it like that so that we would be able to have a large number of vcpus on kernels configured for large systems, while not using up large amounts of memory if the kernel is configured for a small system. The memory consumption is 8 bytes per vcore in each struct kvm if book3s_hv is configured. 8 * 256 = 2048. So for a limit similar to that of x86 we'd waste 2kb per VM. Doesn't sound all too horrible to me. We can make it a fixed constant if you like, but then the question is how do you choose that constant so as to allow us to have many vcpus on large systems but still not waste too much memory on small systems. Or it could be max(N, NR_CPUS) for a suitable N (e.g. 16 or 32). Hrm. Usually we have 2 machine types: 1) Small system with very low NR_CPUS. These systems should be able to do some overcommit at least. I'd go with a static number here, like 16 or 64. 2) Big systems with very high NR_CPUS. Here going larger than NR_CPUS doesn't make all that much sense anymore. I'd use NR_CPUS as limit. So how about something like #if NR_CPUS 64 #define KVM_MAX_VCPUS NR_CPUS #else #define KVM_MAX_VCPUS 64 #endif That way everyone should be happy and we have a reasonable limit. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] KVM: PPC: Use clockevent multiplier and shifter for decrementer
On 09.04.2012, at 06:33, Bharat Bhushan wrote:
Time for which the hrtimer is started for decrementer emulation is calculated
using tb_ticks_per_usec. While hrtimer uses the clockevent for DEC
reprogramming (if needed) and which calculate timebase ticks using the
multiplier and shifter mechanism implemented within clockevent layer. It was
observed that this conversion (timebase-time-timebase) are not correct
because the mechanism are not consistent. In our setup it adds 2% jitter.
With this patch clockevent multiplier and shifter mechanism are used when
starting hrtimer for decrementer emulation. Now the jitter is 0.5%.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2:
- decrementer_clockevent is made non-static rather than a seprate API to get
mult/shift
arch/powerpc/include/asm/time.h |1 +
arch/powerpc/kernel/time.c |2 +-
arch/powerpc/kvm/emulate.c |5 +++--
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 7eb10fb..b3c7959 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -28,6 +28,7 @@
extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
+extern struct clock_event_device decrementer_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 567dd7c..e237225 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -105,7 +105,7 @@ static int decrementer_set_next_event(unsigned long evt,
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev);
-static struct clock_event_device decrementer_clockevent = {
+struct clock_event_device decrementer_clockevent = {
This one also needs a EXPORT_SYMBOL ...
.name = decrementer,
.rating = 200,
.irq= 0,
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index afc9154..c8b5206 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -23,6 +23,7 @@
#include linux/types.h
#include linux/string.h
#include linux/kvm_host.h
+#include linux/clockchips.h
#include asm/reg.h
#include asm/time.h
@@ -104,8 +105,8 @@ void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
*/
dec_time = vcpu-arch.dec;
- dec_time *= 1000;
- do_div(dec_time, tb_ticks_per_usec);
+ dec_time = dec_time decrementer_clockevent.shift;
+ do_div(dec_time, decrementer_clockevent.mult);
... because emulate.c can be built as a module.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC / USB: kernel hangs in warm boot on 8513 in fsl-ehci
On Sun, Apr 15, 2012 at 10:45:50PM -0600, Anthony Foiani wrote: I could try the latest kernels, but due to our vendor not upstreaming their patches, there could be some pain in that transition. I would push back on that vendor, as this is their support issue, not ours :) Seriously, that's the best way forward, they are the ones providing your kernel, so they need to handle this, and they can do so better than we can, right? good luck, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC / USB: kernel hangs in warm boot on 8513 in fsl-ehci
On 04/15/2012 11:45 PM, Anthony Foiani wrote: But I'm still seeing the hang. (And I realize, now that I'm not head down on the project, that the snooping fixes are probably irrelevant for a single-core system like mine.) Snooping is still relevant on single-core systems for DMA. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl_pmc: update device bindings
On Thu, Mar 15, 2012 at 11:31:02PM -, chenhui zhao wrote: diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt index 07256b7..d296e88 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt @@ -9,22 +9,26 @@ Properties: fsl,mpc8548-pmc should be listed for any chip whose PMC is compatible. fsl,mpc8536-pmc should also be listed for any chip - whose PMC is compatible, and implies deep-sleep capability. + whose PMC is compatible, and implies deep-sleep capability and + wake on user defined packet(wakeup on ARP). fsl,p1022-pmc s/packet(wakeup/packet (wakeup/ + should be listed for any chip whose PMC is compatible, and + implies lossless Ethernet capability during sleep or deep sleep. fsl,p1022-pmc also implies that deep sleep exists. It should also imply JOG support, though so should fsl,mpc8536-pmc. Hopefully nothing has yet claimed compatibility with fsl,mpc8536-pmc that doesn't have JOG (this writeup shouldn't be considered exhaustive regarding what compatibility means). fsl,mpc8641d-pmc should be listed for any chip whose PMC is compatible; all statements below that apply to fsl,mpc8548-pmc also apply to fsl,mpc8641d-pmc. Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these - bit assignments are indicated via the sleep specifier in each device's - sleep property. + bit assignments are indicated via the clock nodes. Device which has a Devices which have or A device which has + controllable clock source should have a fsl,pmc-handle property pointing + to the clock node. - reg: For devices compatible with fsl,mpc8349-pmc, the first resource is the PMC block, and the second resource is the Clock Configuration block. - For devices compatible with fsl,mpc8548-pmc, the first resource - is a 32-byte block beginning with DEVDISR. + For devices compatible with fsl,mpc8548-pmc, the resource is a 32-byte + block beginning with the register DEVDISR. What is this change for? There's no requirement that other bindings which are compatible with this one limit themselves to one resource. - interrupts: For fsl,mpc8349-pmc-compatible devices, the first resource is the PMC block interrupt. @@ -33,31 +37,42 @@ Properties: this is a phandle to an fsl,gtm node on which timer 4 can be used as a wakeup source from deep sleep. -Sleep specifiers: - - fsl,mpc8349-pmc: Sleep specifiers consist of one cell. For each bit - that is set in the cell, the corresponding bit in SCCR will be saved - and cleared on suspend, and restored on resume. This sleep controller - supports disabling and resuming devices at any time. - - fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of - which will be ORed into PMCDR upon suspend, and cleared from PMCDR - upon resume. The first two cells are as described for fsl,mpc8578-pmc. - This sleep controller only supports disabling devices during system - sleep, or permanently. +Clock nodes: +The clock nodes are to describe the masks in PM controller registers for each +soc clock. +- fsl,pmcdr-mask: For fsl,mpc8548-pmc-compatible devices, some blocks as + wake-up sources can run in low power mode. If a block used as a wake-up + source in low power mode, the corresponding bit in the register PMCDR should + be cleared on suspend and set on resume. If setting bits of the mask, + the corresponding blocks will be used as wake-up sources. How about: fsl,pmcdr: For fsl,mpc8548-pmc-compatible devices. Some blocks can run in low power mode as wake-up sources. When entering low power mode, no bit set in the fsl,pmcdr property of any device to be used as a wakeup source shall be set in PMCDR. - fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the - first of which will be ORed into DEVDISR (and the second into - DEVDISR2, if present -- this cell should be zero or absent if the - hardware does not have DEVDISR2) upon a request for permanent device - disabling. This sleep controller does not support configuring devices - to disable during system sleep (unless supported by another compatible - match), or dynamically. +- fsl,sccr-mask: For fsl,mpc8349-pmc-compatible devices, the corresponding + bit specified by the mask in SCCR will be saved and cleared on suspend, and + restored on resume. fsl,sccr: For fsl,mpc8349-pmc-compatible devices. The bits set in a device's fsl,sccr property must be set in the SCCR register whenever that device is to be clocked. -Example: +- fsl,devdisr-mask: Contain one or two cells, depending on the availability of + DEVDISR2 register. For compatible devices, the mask will be ORed into DEVDISR + or DEVDISR2 when the clock should be permenently disabled. fsl,devdisr: Contains two cells if DEVDISR2 is available,
Re: [PATCH v4 1/4] powerpc/85xx: add HOTPLUG_CPU support
On 03/16/2012 04:22 AM, Zhao Chenhui wrote:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4eecaaa..3d4c497 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -219,7 +219,8 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
-(PPC_85xx !SMP) || PPC_86xx || PPC_PSERIES || 44x || 40x
+(PPC_85xx !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
+|| 44x || 40x
config PPC_DCR_NATIVE
bool
@@ -330,7 +331,8 @@ config SWIOTLB
config HOTPLUG_CPU
bool Support for enabling/disabling CPUs
- depends on SMP HOTPLUG EXPERIMENTAL (PPC_PSERIES || PPC_PMAC
|| PPC_POWERNV)
+ depends on SMP HOTPLUG EXPERIMENTAL (PPC_PSERIES || \
+ PPC_PMAC || PPC_POWERNV || PPC_85xx)
No e500mc exclusion on HOTPLUG_CPU? I don't see where this depends on
ARCH_SUSPEND_POSSIBLE.
---help---
Say Y here to be able to disable and re-enable individual
CPUs at runtime on SMP machines.
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index ab9e402..57b5dd7 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -30,6 +30,12 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping) do { } while (0)
#define flush_dcache_mmap_unlock(mapping)do { } while (0)
+#ifdef CONFIG_FSL_BOOKE
+extern void flush_disable_L1(void);
+#else
+#define flush_disable_L1() do { } while (0)
+#endif
When would we want this to be a no-op? Shouldn't you get an error if
you try to do this without an implementation, rather than silently
corrupt your cache?
There's an existing __flush_disable_L1() for 6xx. Let's not introduce a
different spelling of the same thing for no good reason -- even if those
leading underscores are annoying and pointless. :-)
+#ifdef CONFIG_HOTPLUG_CPU
+ /* Corresponding to generic_set_cpu_dead() */
+ generic_set_cpu_up(nr);
+
+ if (system_state == SYSTEM_RUNNING) {
+ out_be32(spin_table-addr_l, 0);
+
+ /*
+ * We don't set the BPTR register here upon it points
+ * to the boot page properly.
+ */
+ mpic_reset_core(hw_cpu);
What if we don't have an MPIC? What if MPIC support isn't present in
the kernel, even if we never run this code?
Also, can you limit the hard core reset to cases that really need it?
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
-#ifdef CONFIG_KEXEC
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_disable= generic_cpu_disable,
+ .cpu_die= generic_cpu_die,
+#endif
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
-#endif
};
We need to stop using smp_generic_give/take_timebase, not expand its
use. This stuff breaks under hypervisors where timebase can't be
written. It wasn't too bad before since we generally didn't enable
CONFIG_KEXEC, but we're more likely to want CONFIG_HOTPLUG_CPU.
Do the timebase sync the way U-Boot does -- if you find the appropriate
guts node in the device tree.
#ifdef CONFIG_KEXEC
@@ -218,8 +283,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage
*image)
}
#endif /* CONFIG_KEXEC */
-static void __init
-smp_85xx_setup_cpu(int cpu_nr)
+static void __cpuinit smp_85xx_setup_cpu(int cpu_nr)
{
if (smp_85xx_ops.probe == smp_mpic_probe)
mpic_setup_this_cpu();
@@ -249,6 +313,10 @@ void __init mpc85xx_smp_init(void)
smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
}
+#ifdef CONFIG_HOTPLUG_CPU
+ ppc_md.cpu_die = smp_85xx_mach_cpu_die;
+#endif
Do not set this unconditionally without checking that you're on
e500v1/e500v2 (or at least that you have the NAP cputable flag, and an
MPIC if you're going to rely on that).
The kconfig exclusion is at best a temporary hack.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses
NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but
NR_IRQs could be smaller than the number of hardware irqs that
ppc_cached_irq_mask tracks.
Also, while fixing that problem, it became apparent that the interrupt
controller only supports 32 interrupt numbers, but it is written as if
it supports multiple register banks which is more complicated.
This patch pulls out the buggy reference to NR_IRQs and fixes the size
of the ppc_cached_irq_mask to match the number of HW irqs. It also
drops the now-unnecessary code since ppc_cached_irq_mask is no longer
an array.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/sysdev/mpc8xx_pic.c | 61 +-
1 file changed, 21 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
index d5f5416..91cade8 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -18,69 +18,47 @@
extern int cpm_get_irq(struct pt_regs *regs);
static struct irq_domain *mpc8xx_pic_host;
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-static unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
+static unsigned long ppc_cached_irq_mask;
static sysconf8xx_t __iomem *siu_reg;
int cpm_get_irq(struct pt_regs *regs);
-static void mpc8xx_unmask_irq(struct irq_data *d)
+static inline unsigned long mpc8xx_irqd_to_bit(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
+ return 0x8000 irqd_to_hwirq(d);
+}
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+static void mpc8xx_unmask_irq(struct irq_data *d)
+{
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_mask_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] = ~(1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask = ~mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_ack(struct irq_data *d)
{
- int bit;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- out_be32(siu_reg-sc_sipend, 1 (31-bit));
+ out_be32(siu_reg-sc_sipend, mpc8xx_irqd_to_bit(d));
}
static void mpc8xx_end_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static int mpc8xx_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- if (flow_type IRQ_TYPE_EDGE_FALLING) {
- irq_hw_number_t hw = (unsigned int)irqd_to_hwirq(d);
+ /* only external IRQ senses are programmable */
+ if ((flow_type IRQ_TYPE_EDGE_FALLING) !(irqd_to_hwirq(d) 1)) {
unsigned int siel = in_be32(siu_reg-sc_siel);
-
- /* only external IRQ senses are programmable */
- if ((hw 1) == 0) {
- siel |= (0x8000 hw);
- out_be32(siu_reg-sc_siel, siel);
- __irq_set_handler_locked(d-irq, handle_edge_irq);
- }
+ siel |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_siel, siel);
+ __irq_set_handler_locked(d-irq, handle_edge_irq);
}
return 0;
}
@@ -132,6 +110,9 @@ static int mpc8xx_pic_host_xlate(struct irq_domain *h,
struct device_node *ct,
IRQ_TYPE_EDGE_FALLING,
};
+ if (intspec[0] 0x1f)
+ return 0;
+
*out_hwirq = intspec[0];
if (intsize 1 intspec[1] 4)
*out_flags = map_pic_senses[intspec[1]];
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] irqdomain/powerpc: Fix broken NR_IRQ references
The switch from using irq_map to irq_alloc_desc*() for managing irq
number allocations introduced new bugs in some of the powerpc
interrupt code. Several functions rely on the value of NR_IRQS to
determine the maximum irq number that could get allocated. However,
with sparse_irq and using irq_alloc_desc*() the maximum possible irq
number is now specified with 'nr_irqs' which may be a number larger
than NR_IRQS. This has caused breakage on powermac when
CONFIG_NR_IRQS is set to 32.
This patch removes most of the direct references to NR_IRQS in the
powerpc code and replaces them with either a nr_irqs reference or by
using the common for_each_irq_desc() macro. The powerpc-specific
for_each_irq() macro is removed at the same time.
Also, the Cell axon_msi driver is refactored to remove the global
build assumption on the size of NR_IRQS and instead add a limit to the
maximum irq number when calling irq_domain_add_nomap().
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/irq.h |4
arch/powerpc/kernel/irq.c|6 +-
arch/powerpc/kernel/machine_kexec.c |7 ++-
arch/powerpc/platforms/cell/axon_msi.c |7 ++-
arch/powerpc/platforms/cell/beat_interrupt.c |2 +-
arch/powerpc/platforms/powermac/pic.c|6 +++---
arch/powerpc/sysdev/cpm2_pic.c |3 +--
arch/powerpc/sysdev/xics/xics-common.c |7 +++
8 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index e648af9..0e40843 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -18,10 +18,6 @@
#include linux/atomic.h
-/* Define a way to iterate across irqs. */
-#define for_each_irq(i) \
- for ((i) = 0; (i) NR_IRQS; ++(i))
-
extern atomic_t ppc_n_lost_interrupts;
/* This number is used when no interrupt has been assigned */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5ec1b23..43eb74f 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -330,14 +330,10 @@ void migrate_irqs(void)
alloc_cpumask_var(mask, GFP_KERNEL);
- for_each_irq(irq) {
+ for_each_irq_desc(irq, desc) {
struct irq_data *data;
struct irq_chip *chip;
- desc = irq_to_desc(irq);
- if (!desc)
- continue;
-
data = irq_desc_get_irq_data(desc);
if (irqd_is_per_cpu(data))
continue;
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index c957b12..5df 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -23,14 +23,11 @@
void machine_kexec_mask_interrupts(void) {
unsigned int i;
+ struct irq_desc *desc;
- for_each_irq(i) {
- struct irq_desc *desc = irq_to_desc(i);
+ for_each_irq_desc(i, desc) {
struct irq_chip *chip;
- if (!desc)
- continue;
-
chip = irq_desc_get_chip(desc);
if (!chip)
continue;
diff --git a/arch/powerpc/platforms/cell/axon_msi.c
b/arch/powerpc/platforms/cell/axon_msi.c
index d09f3e8..fc9df1a 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -114,7 +114,7 @@ static void axon_msi_cascade(unsigned int irq, struct
irq_desc *desc)
pr_devel(axon_msi: woff %x roff %x msi %x\n,
write_offset, msic-read_offset, msi);
- if (msi NR_IRQS irq_get_chip_data(msi) == msic) {
+ if (msi nr_irqs irq_get_chip_data(msi) == msic) {
generic_handle_irq(msi);
msic-fifo_virt[idx] = cpu_to_le32(0x);
} else {
@@ -276,9 +276,6 @@ static int axon_msi_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
if (rc)
return rc;
- /* We rely on being able to stash a virq in a u16 */
- BUILD_BUG_ON(NR_IRQS 65536);
-
list_for_each_entry(entry, dev-msi_list, list) {
virq = irq_create_direct_mapping(msic-irq_domain);
if (virq == NO_IRQ) {
@@ -392,7 +389,7 @@ static int axon_msi_probe(struct platform_device *device)
}
memset(msic-fifo_virt, 0xff, MSIC_FIFO_SIZE_BYTES);
- msic-irq_domain = irq_domain_add_nomap(dn, 0, msic_host_ops, msic);
+ msic-irq_domain = irq_domain_add_nomap(dn, 65536, msic_host_ops,
msic);
if (!msic-irq_domain) {
printk(KERN_ERR axon_msi: couldn't allocate irq_domain for
%s\n,
dn-full_name);
diff --git a/arch/powerpc/platforms/cell/beat_interrupt.c
[EDAC PATCH v13 7/7] edac: Change internal representation to work with layers
Change the EDAC internal representation to work with non-csrow based memory controllers. There are lots of those memory controllers nowadays, and more are coming. So, the EDAC internal representation needs to be changed, in order to work with those memory controllers, while preserving backward compatibility with the old ones. The edac core were written with the idea that memory controllers are able to directly access csrows, and that the channels are used inside a csrows select. This is not true for FB-DIMM and RAMBUS memory controllers. Also, some recent advanced memory controllers don't present a per-csrows view. Instead, they view memories as DIMM's, instead of ranks, accessed via csrow/channel. So, change the allocation and error report routines to allow them to work with all types of architectures. This will allow the removal of several hacks on FB-DIMM and RAMBUS memory controllers on the next patches. Also, several tests were done on different platforms using different x86 drivers. TODO: a multi-rank DIMM's are currently represented by multiple DIMM entries at struct dimm_info. That means that changing a label for one rank won't change the same label for the other ranks at the same dimm. Such bug is there since the beginning of the EDAC, so it is not a big deal. However, on several drivers, it is possible to fix this issue, but it should be a per-driver fix, as the csrow = DIMM arrangement may not be equal for all. So, don't try to fix it here yet. PS.: I tried to make this patch as short as possible, preceding it with several other patches that simplified the logic here. Yet, as the internal API changes, all drivers need changes. The changes are generally bigger on the drivers for FB-DIMM's. FIXME: while the FB-DIMMs are not converted to use the new design, uncorrected errors will show just one channel. In the past, all changes were on a big patch with about 150K. As it needed to be split, in order to be accepted by the EDAC ML at vger, we've opted to have this small drawback. As an advantage, it is now easier to review the patch series. Cc: Aristeu Rozanski aroza...@redhat.com Cc: Doug Thompson nor...@yahoo.com Cc: Borislav Petkov borislav.pet...@amd.com Cc: Mark Gross mark.gr...@intel.com Cc: Jason Uhlenkott juhle...@akamai.com Cc: Tim Small t...@buttersideup.com Cc: Ranganathan Desikan r...@jetztechnologies.com Cc: Arvind R. arvin...@gmail.com Cc: Olof Johansson o...@lixom.net Cc: Egor Martovetsky e...@pasemi.com Cc: Chris Metcalf cmetc...@tilera.com Cc: Michal Marek mma...@suse.cz Cc: Jiri Kosina jkos...@suse.cz Cc: Joe Perches j...@perches.com Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Hitoshi Mitake h.mit...@gmail.com Cc: Andrew Morton a...@linux-foundation.org Cc: Niklas Söderlund niklas.soderl...@ericsson.com Cc: Shaohui Xie shaohui@freescale.com Cc: Josh Boyer jwbo...@gmail.com Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/edac/edac_core.h | 92 ++- drivers/edac/edac_mc.c | 682 -- include/linux/edac.h | 40 ++- 3 files changed, 526 insertions(+), 288 deletions(-) diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h index e48ab31..7201bb1 100644 --- a/drivers/edac/edac_core.h +++ b/drivers/edac/edac_core.h @@ -447,8 +447,13 @@ static inline void pci_write_bits32(struct pci_dev *pdev, int offset, #endif /* CONFIG_PCI */ -extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, - unsigned nr_chans, int edac_index); +struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, + unsigned nr_chans, int edac_index); +struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index, + unsigned n_layers, + struct edac_mc_layer *layers, + bool rev_order, + unsigned sz_pvt); extern int edac_mc_add_mc(struct mem_ctl_info *mci); extern void edac_mc_free(struct mem_ctl_info *mci); extern struct mem_ctl_info *edac_mc_find(int idx); @@ -467,24 +472,80 @@ extern int edac_mc_find_csrow_by_page(struct mem_ctl_info *mci, * reporting logic and function interface - reduces conditional * statement clutter and extra function arguments. */ -extern void edac_mc_handle_ce(struct mem_ctl_info *mci, + +void edac_mc_handle_error(const enum hw_event_mc_err_type type, + struct mem_ctl_info *mci, + const unsigned long page_frame_number, + const unsigned long offset_in_page, + const unsigned long syndrome, + const int layer0, + const int layer1, + const int layer2, +
[EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
The number of pages is a dimm property. Move it to the dimm struct.
After this change, it is possible to add sysfs nodes for the DIMM's that
will properly represent the DIMM stick properties, including its size.
A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
the memory controller represents the memory via chip select rows.
Reviewed-by: Aristeu Rozanski aroza...@redhat.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Borislav Petkov borislav.pet...@amd.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/amd64_edac.c | 12 +++--
drivers/edac/amd76x_edac.c |6 ++--
drivers/edac/cell_edac.c |8 --
drivers/edac/cpc925_edac.c |8 --
drivers/edac/e752x_edac.c |6 +++-
drivers/edac/e7xxx_edac.c |5 ++-
drivers/edac/edac_mc.c | 16 -
drivers/edac/edac_mc_sysfs.c | 47
drivers/edac/i3000_edac.c |6 +++-
drivers/edac/i3200_edac.c |3 +-
drivers/edac/i5000_edac.c | 14 ++-
drivers/edac/i5100_edac.c | 22 +++---
drivers/edac/i5400_edac.c |9 ++-
drivers/edac/i7300_edac.c | 22 +-
drivers/edac/i7core_edac.c | 10 ++--
drivers/edac/i82443bxgx_edac.c |2 +-
drivers/edac/i82860_edac.c |2 +-
drivers/edac/i82875p_edac.c|5 ++-
drivers/edac/i82975x_edac.c| 11 ++--
drivers/edac/mpc85xx_edac.c|3 +-
drivers/edac/mv64x60_edac.c|3 +-
drivers/edac/pasemi_edac.c | 14 ++--
drivers/edac/ppc4xx_edac.c |5 ++-
drivers/edac/r82600_edac.c |3 +-
drivers/edac/sb_edac.c |8 +-
drivers/edac/tile_edac.c |2 +-
drivers/edac/x38_edac.c|4 +-
include/linux/edac.h |8 --
28 files changed, 144 insertions(+), 120 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 0be3f29..8804ac8 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2126,12 +2126,6 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt,
u8 dct, int csrow_nr)
nr_pages = pvt-ops-dbam_to_cs(pvt, dct, cs_mode) (20 - PAGE_SHIFT);
- /*
-* If dual channel then double the memory size of single channel.
-* Channel count is 1 or 2
-*/
- nr_pages = (pvt-channel_count - 1);
-
debugf0( (csrow=%d) DBAM map index= %d\n, csrow_nr, cs_mode);
debugf0(nr_pages= %u channel-count = %d\n,
nr_pages, pvt-channel_count);
@@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
int i, j, empty = 1;
enum mem_type mtype;
enum edac_type edac_mode;
+ int nr_pages;
amd64_read_pci_cfg(pvt-F3, NBCFG, val);
@@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
i, pvt-mc_node_id);
empty = 0;
- csrow-nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
+ nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
get_cs_base_and_mask(pvt, i, 0, base, mask);
/* 8 bytes of resolution */
mtype = amd64_determine_memory_type(pvt, i);
debugf1( for MC node %d csrow %d:\n, pvt-mc_node_id, i);
- debugf1(nr_pages: %u\n, csrow-nr_pages);
+ debugf1(nr_pages: %u\n, nr_pages);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
@@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
for (j = 0; j pvt-channel_count; j++) {
csrow-channels[j].dimm-mtype = mtype;
csrow-channels[j].dimm-edac_mode = edac_mode;
+ csrow-channels[j].dimm-nr_pages = nr_pages;
}
}
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 2a63ed0..1532750 100644
--- a/drivers/edac/amd76x_edac.c
+++ b/drivers/edac/amd76x_edac.c
@@ -205,10 +205,10 @@ static void amd76x_init_csrows(struct mem_ctl_info *mci,
struct pci_dev *pdev,
mba_mask = ((mba 0xff80)
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
Ben, I can take these two patches via my irqdomain tree if you prefer.
g.
On Mon, Apr 16, 2012 at 2:13 PM, Grant Likely grant.lik...@secretlab.ca wrote:
The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses
NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but
NR_IRQs could be smaller than the number of hardware irqs that
ppc_cached_irq_mask tracks.
Also, while fixing that problem, it became apparent that the interrupt
controller only supports 32 interrupt numbers, but it is written as if
it supports multiple register banks which is more complicated.
This patch pulls out the buggy reference to NR_IRQs and fixes the size
of the ppc_cached_irq_mask to match the number of HW irqs. It also
drops the now-unnecessary code since ppc_cached_irq_mask is no longer
an array.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/sysdev/mpc8xx_pic.c | 61
+-
1 file changed, 21 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c
b/arch/powerpc/sysdev/mpc8xx_pic.c
index d5f5416..91cade8 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -18,69 +18,47 @@
extern int cpm_get_irq(struct pt_regs *regs);
static struct irq_domain *mpc8xx_pic_host;
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-static unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
+static unsigned long ppc_cached_irq_mask;
static sysconf8xx_t __iomem *siu_reg;
int cpm_get_irq(struct pt_regs *regs);
-static void mpc8xx_unmask_irq(struct irq_data *d)
+static inline unsigned long mpc8xx_irqd_to_bit(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
+ return 0x8000 irqd_to_hwirq(d);
+}
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+static void mpc8xx_unmask_irq(struct irq_data *d)
+{
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_mask_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] = ~(1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask = ~mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_ack(struct irq_data *d)
{
- int bit;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- out_be32(siu_reg-sc_sipend, 1 (31-bit));
+ out_be32(siu_reg-sc_sipend, mpc8xx_irqd_to_bit(d));
}
static void mpc8xx_end_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static int mpc8xx_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- if (flow_type IRQ_TYPE_EDGE_FALLING) {
- irq_hw_number_t hw = (unsigned int)irqd_to_hwirq(d);
+ /* only external IRQ senses are programmable */
+ if ((flow_type IRQ_TYPE_EDGE_FALLING) !(irqd_to_hwirq(d) 1)) {
unsigned int siel = in_be32(siu_reg-sc_siel);
-
- /* only external IRQ senses are programmable */
- if ((hw 1) == 0) {
- siel |= (0x8000 hw);
- out_be32(siu_reg-sc_siel, siel);
- __irq_set_handler_locked(d-irq, handle_edge_irq);
- }
+ siel |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_siel, siel);
+ __irq_set_handler_locked(d-irq, handle_edge_irq);
}
return 0;
}
@@ -132,6 +110,9 @@ static int mpc8xx_pic_host_xlate(struct irq_domain *h,
struct device_node *ct,
IRQ_TYPE_EDGE_FALLING,
};
+ if (intspec[0] 0x1f)
+ return 0;
+
*out_hwirq = intspec[0];
if (intsize 1 intspec[1] 4)
*out_flags = map_pic_senses[intspec[1]];
--
1.7.9.5
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[EDAC_ABI PATCH v13 20/26] pasemi_edac: convert driver to use the new edac ABI
The legacy edac ABI is going to be removed. Port the driver to use
and benefit from the new API functionality.
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/pasemi_edac.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/pasemi_edac.c b/drivers/edac/pasemi_edac.c
index 3fcefda..addf893 100644
--- a/drivers/edac/pasemi_edac.c
+++ b/drivers/edac/pasemi_edac.c
@@ -110,15 +110,16 @@ static void pasemi_edac_process_error_info(struct
mem_ctl_info *mci, u32 errsta)
/* uncorrectable/multi-bit errors */
if (errsta (MCDEBUG_ERRSTA_MBE_STATUS |
MCDEBUG_ERRSTA_RFL_STATUS)) {
- edac_mc_handle_ue(mci, mci-csrows[cs].first_page, 0,
- cs, mci-ctl_name);
+ edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
+mci-csrows[cs].first_page, 0, 0,
+cs, 0, -1, mci-ctl_name, , NULL);
}
/* correctable/single-bit errors */
- if (errsta MCDEBUG_ERRSTA_SBE_STATUS) {
- edac_mc_handle_ce(mci, mci-csrows[cs].first_page, 0,
- 0, cs, 0, mci-ctl_name);
- }
+ if (errsta MCDEBUG_ERRSTA_SBE_STATUS)
+ edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci,
+mci-csrows[cs].first_page, 0, 0,
+cs, 0, -1, mci-ctl_name, , NULL);
}
static void pasemi_edac_check(struct mem_ctl_info *mci)
@@ -191,6 +192,7 @@ static int __devinit pasemi_edac_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct mem_ctl_info *mci = NULL;
+ struct edac_mc_layer layers[2];
u32 errctl1, errcor, scrub, mcen;
pci_read_config_dword(pdev, MCCFG_MCEN, mcen);
@@ -207,9 +209,14 @@ static int __devinit pasemi_edac_probe(struct pci_dev
*pdev,
MCDEBUG_ERRCTL1_RFL_LOG_EN;
pci_write_config_dword(pdev, MCDEBUG_ERRCTL1, errctl1);
- mci = edac_mc_alloc(0, PASEMI_EDAC_NR_CSROWS, PASEMI_EDAC_NR_CHANS,
- system_mmc_id++);
-
+ layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
+ layers[0].size = PASEMI_EDAC_NR_CSROWS;
+ layers[0].is_csrow = true;
+ layers[1].type = EDAC_MC_LAYER_CHANNEL;
+ layers[1].size = PASEMI_EDAC_NR_CHANS;
+ layers[1].is_csrow = false;
+ mci = new_edac_mc_alloc(system_mmc_id++, ARRAY_SIZE(layers), layers,
false,
+ 0);
if (mci == NULL)
return -ENOMEM;
--
1.7.8
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[EDAC ABI v13 24/25] edac: change the mem allocation scheme to make Documentation/kobject.txt happy
Kernel kobjects have rigid rules: each container object should be
dynamically allocated, and can't be allocated into a single kmalloc.
EDAC never obeyed this rule: it has a single malloc function that
allocates all needed data into a single kzalloc.
As this is not accepted anymore, change the allocation schema of the
EDAC *_info structs to enforce this Kernel standard.
Cc: Aristeu Rozanski aroza...@redhat.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Borislav Petkov borislav.pet...@amd.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Shaohui Xie shaohui@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/amd64_edac.c |8 +-
drivers/edac/amd76x_edac.c |8 +-
drivers/edac/cell_edac.c |8 +-
drivers/edac/cpc925_edac.c |8 +-
drivers/edac/e752x_edac.c |4 +-
drivers/edac/e7xxx_edac.c |4 +-
drivers/edac/edac_mc.c | 105 +
drivers/edac/edac_mc_sysfs.c | 126 +++-
drivers/edac/i3000_edac.c |6 +-
drivers/edac/i3200_edac.c |4 +-
drivers/edac/i5400_edac.c |6 +-
drivers/edac/i82443bxgx_edac.c |4 +-
drivers/edac/i82860_edac.c |6 +-
drivers/edac/i82875p_edac.c|6 +-
drivers/edac/i82975x_edac.c| 10 ++--
drivers/edac/mpc85xx_edac.c|6 +-
drivers/edac/mv64x60_edac.c|4 +-
drivers/edac/pasemi_edac.c |8 +-
drivers/edac/r82600_edac.c |4 +-
drivers/edac/tile_edac.c |4 +-
drivers/edac/x38_edac.c|4 +-
include/linux/edac.h | 31 ++
22 files changed, 216 insertions(+), 158 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 321b838..ee7c060 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2197,7 +2197,7 @@ static int init_csrows(struct mem_ctl_info *mci)
!!(val NBCFG_CHIPKILL), !!(val NBCFG_ECC_ENABLE));
for_each_chip_select(i, 0, pvt) {
- csrow = mci-csrows[i];
+ csrow = mci-csrows[i];
if (!csrow_enabled(i, 0, pvt)) {
debugf1(CSROW %d EMPTY for node %d\n, i,
@@ -2228,9 +2228,9 @@ static int init_csrows(struct mem_ctl_info *mci)
edac_mode = EDAC_NONE;
for (j = 0; j pvt-channel_count; j++) {
- csrow-channels[j].dimm-mtype = mtype;
- csrow-channels[j].dimm-edac_mode = edac_mode;
- csrow-channels[j].dimm-nr_pages = nr_pages;
+ csrow-channels[j]-dimm-mtype = mtype;
+ csrow-channels[j]-dimm-edac_mode = edac_mode;
+ csrow-channels[j]-dimm-nr_pages = nr_pages;
}
}
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 9a34c5f..99d8d56 100644
--- a/drivers/edac/amd76x_edac.c
+++ b/drivers/edac/amd76x_edac.c
@@ -146,7 +146,7 @@ static int amd76x_process_error_info(struct mem_ctl_info
*mci,
if (handle_errors) {
row = (info-ecc_mode_status 4) 0xf;
edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
-mci-csrows[row].first_page, 0, 0,
+mci-csrows[row]-first_page, 0, 0,
row, 0, -1,
mci-ctl_name, , NULL);
}
@@ -161,7 +161,7 @@ static int amd76x_process_error_info(struct mem_ctl_info
*mci,
if (handle_errors) {
row = info-ecc_mode_status 0xf;
edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci,
-mci-csrows[row].first_page, 0, 0,
+mci-csrows[row]-first_page, 0, 0,
row, 0, -1,
mci-ctl_name, , NULL);
}
@@ -194,8 +194,8 @@ static void amd76x_init_csrows(struct mem_ctl_info *mci,
struct pci_dev *pdev,
int index;
for (index = 0; index mci-nr_csrows; index++) {
- csrow = mci-csrows[index];
- dimm = csrow-channels[0].dimm;
+ csrow =
[EDAC ABI v13 07/25] edac: Rename the parent dev to pdev
As EDAC doesn't use struct device itself, it created a parent dev
pointer called as pdev. Now that we'll be converting it to use
struct device, instead of struct devsys, this needs to be fixed.
No functional changes.
Reviewed-by: Aristeu Rozanski aroza...@redhat.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Borislav Petkov borislav.pet...@amd.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/amd64_edac.c |2 +-
drivers/edac/amd76x_edac.c |4 ++--
drivers/edac/cell_edac.c | 12 ++--
drivers/edac/cpc925_edac.c |2 +-
drivers/edac/e752x_edac.c |2 +-
drivers/edac/e7xxx_edac.c |2 +-
drivers/edac/edac_mc.c |8
drivers/edac/edac_mc_sysfs.c |2 +-
drivers/edac/i3000_edac.c |4 ++--
drivers/edac/i3200_edac.c |6 +++---
drivers/edac/i5000_edac.c |2 +-
drivers/edac/i5100_edac.c |2 +-
drivers/edac/i5400_edac.c |2 +-
drivers/edac/i7300_edac.c |2 +-
drivers/edac/i7core_edac.c |4 ++--
drivers/edac/i82443bxgx_edac.c |4 ++--
drivers/edac/i82860_edac.c |4 ++--
drivers/edac/i82875p_edac.c|4 ++--
drivers/edac/i82975x_edac.c|4 ++--
drivers/edac/mpc85xx_edac.c|4 ++--
drivers/edac/mv64x60_edac.c|2 +-
drivers/edac/pasemi_edac.c |6 +++---
drivers/edac/ppc4xx_edac.c |8
drivers/edac/r82600_edac.c |4 ++--
drivers/edac/sb_edac.c |4 ++--
drivers/edac/tile_edac.c |4 ++--
drivers/edac/x38_edac.c|6 +++---
include/linux/edac.h |2 +-
28 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 445ff03..b26fc06 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2572,7 +2572,7 @@ static int amd64_init_one_instance(struct pci_dev *F2)
goto err_siblings;
mci-pvt_info = pvt;
- mci-dev = pvt-F2-dev;
+ mci-pdev = pvt-F2-dev;
setup_mci_misc_attrs(mci, fam_type);
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 0184e90..9a34c5f 100644
--- a/drivers/edac/amd76x_edac.c
+++ b/drivers/edac/amd76x_edac.c
@@ -105,7 +105,7 @@ static void amd76x_get_error_info(struct mem_ctl_info *mci,
{
struct pci_dev *pdev;
- pdev = to_pci_dev(mci-dev);
+ pdev = to_pci_dev(mci-pdev);
pci_read_config_dword(pdev, AMD76X_ECC_MODE_STATUS,
info-ecc_mode_status);
@@ -257,7 +257,7 @@ static int amd76x_probe1(struct pci_dev *pdev, int dev_idx)
return -ENOMEM;
debugf0(%s(): mci = %p\n, __func__, mci);
- mci-dev = pdev-dev;
+ mci-pdev = pdev-dev;
mci-mtype_cap = MEM_FLAG_RDDR;
mci-edac_ctl_cap = EDAC_FLAG_NONE | EDAC_FLAG_EC | EDAC_FLAG_SECDED;
mci-edac_cap = ems_mode ?
diff --git a/drivers/edac/cell_edac.c b/drivers/edac/cell_edac.c
index 39616a3..9e53917 100644
--- a/drivers/edac/cell_edac.c
+++ b/drivers/edac/cell_edac.c
@@ -36,7 +36,7 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci, int
chan, u64 ar)
struct csrow_info *csrow = mci-csrows[0];
unsigned long address, pfn, offset, syndrome;
- dev_dbg(mci-dev, ECC CE err on node %d, channel %d, ar = 0x%016llx\n,
+ dev_dbg(mci-pdev, ECC CE err on node %d, channel %d, ar =
0x%016llx\n,
priv-node, chan, ar);
/* Address decoding is likely a bit bogus, to dbl check */
@@ -59,7 +59,7 @@ static void cell_edac_count_ue(struct mem_ctl_info *mci, int
chan, u64 ar)
struct csrow_info *csrow = mci-csrows[0];
unsigned long address, pfn, offset;
- dev_dbg(mci-dev, ECC UE err on node %d, channel %d, ar = 0x%016llx\n,
+ dev_dbg(mci-pdev, ECC UE err on node %d, channel %d, ar =
0x%016llx\n,
priv-node, chan, ar);
/* Address decoding is likely a bit bogus, to dbl check */
@@ -83,7 +83,7 @@ static void cell_edac_check(struct mem_ctl_info *mci)
fir = in_be64(priv-regs-mic_fir);
#ifdef DEBUG
if (fir != priv-prev_fir) {
-
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Mon, 2012-04-16 at 14:13 -0600, Grant Likely wrote:
The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses
NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but
NR_IRQs could be smaller than the number of hardware irqs that
ppc_cached_irq_mask tracks.
Also, while fixing that problem, it became apparent that the interrupt
controller only supports 32 interrupt numbers, but it is written as if
it supports multiple register banks which is more complicated.
This patch pulls out the buggy reference to NR_IRQs and fixes the size
of the ppc_cached_irq_mask to match the number of HW irqs. It also
drops the now-unnecessary code since ppc_cached_irq_mask is no longer
an array.
Can you rename ppc_cached_irq_mask while at it ? I think it was written
that way because it was all copy/pasted from powermac/pic.c which -does-
need it to be an array (and has the same bugs btw) :-)
I wonder if we can get rid of the cached mask alltogether... I have the
feeling that we could just rely on the irq_desc fields nowadays for
that... this code is ancient.
Cheers,
Ben.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/sysdev/mpc8xx_pic.c | 61
+-
1 file changed, 21 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c
b/arch/powerpc/sysdev/mpc8xx_pic.c
index d5f5416..91cade8 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -18,69 +18,47 @@
extern int cpm_get_irq(struct pt_regs *regs);
static struct irq_domain *mpc8xx_pic_host;
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-static unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
+static unsigned long ppc_cached_irq_mask;
static sysconf8xx_t __iomem *siu_reg;
int cpm_get_irq(struct pt_regs *regs);
-static void mpc8xx_unmask_irq(struct irq_data *d)
+static inline unsigned long mpc8xx_irqd_to_bit(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
+ return 0x8000 irqd_to_hwirq(d);
+}
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+static void mpc8xx_unmask_irq(struct irq_data *d)
+{
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_mask_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] = ~(1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask = ~mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_ack(struct irq_data *d)
{
- int bit;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- out_be32(siu_reg-sc_sipend, 1 (31-bit));
+ out_be32(siu_reg-sc_sipend, mpc8xx_irqd_to_bit(d));
}
static void mpc8xx_end_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static int mpc8xx_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- if (flow_type IRQ_TYPE_EDGE_FALLING) {
- irq_hw_number_t hw = (unsigned int)irqd_to_hwirq(d);
+ /* only external IRQ senses are programmable */
+ if ((flow_type IRQ_TYPE_EDGE_FALLING) !(irqd_to_hwirq(d) 1)) {
unsigned int siel = in_be32(siu_reg-sc_siel);
-
- /* only external IRQ senses are programmable */
- if ((hw 1) == 0) {
- siel |= (0x8000 hw);
- out_be32(siu_reg-sc_siel, siel);
- __irq_set_handler_locked(d-irq, handle_edge_irq);
- }
+ siel |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_siel, siel);
+ __irq_set_handler_locked(d-irq, handle_edge_irq);
}
return 0;
}
@@ -132,6 +110,9 @@ static int mpc8xx_pic_host_xlate(struct irq_domain *h,
struct device_node *ct,
IRQ_TYPE_EDGE_FALLING,
};
+ if (intspec[0] 0x1f)
+ return 0;
+
*out_hwirq = intspec[0];
if (intsize 1 intspec[1] 4)
*out_flags = map_pic_senses[intspec[1]];
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Mon, 2012-04-16 at 14:13 -0600, Grant Likely wrote:
Ben, I can take these two patches via my irqdomain tree if you prefer.
Let me give them a test run first.
Cheers,
Ben.
g.
On Mon, Apr 16, 2012 at 2:13 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses
NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but
NR_IRQs could be smaller than the number of hardware irqs that
ppc_cached_irq_mask tracks.
Also, while fixing that problem, it became apparent that the interrupt
controller only supports 32 interrupt numbers, but it is written as if
it supports multiple register banks which is more complicated.
This patch pulls out the buggy reference to NR_IRQs and fixes the size
of the ppc_cached_irq_mask to match the number of HW irqs. It also
drops the now-unnecessary code since ppc_cached_irq_mask is no longer
an array.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/sysdev/mpc8xx_pic.c | 61
+-
1 file changed, 21 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c
b/arch/powerpc/sysdev/mpc8xx_pic.c
index d5f5416..91cade8 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -18,69 +18,47 @@
extern int cpm_get_irq(struct pt_regs *regs);
static struct irq_domain *mpc8xx_pic_host;
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-static unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
+static unsigned long ppc_cached_irq_mask;
static sysconf8xx_t __iomem *siu_reg;
int cpm_get_irq(struct pt_regs *regs);
-static void mpc8xx_unmask_irq(struct irq_data *d)
+static inline unsigned long mpc8xx_irqd_to_bit(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
+ return 0x8000 irqd_to_hwirq(d);
+}
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+static void mpc8xx_unmask_irq(struct irq_data *d)
+{
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_mask_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] = ~(1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask = ~mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static void mpc8xx_ack(struct irq_data *d)
{
- int bit;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- out_be32(siu_reg-sc_sipend, 1 (31-bit));
+ out_be32(siu_reg-sc_sipend, mpc8xx_irqd_to_bit(d));
}
static void mpc8xx_end_irq(struct irq_data *d)
{
- int bit, word;
- unsigned int irq_nr = (unsigned int)irqd_to_hwirq(d);
-
- bit = irq_nr 0x1f;
- word = irq_nr 5;
-
- ppc_cached_irq_mask[word] |= (1 (31-bit));
- out_be32(siu_reg-sc_simask, ppc_cached_irq_mask[word]);
+ ppc_cached_irq_mask |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_simask, ppc_cached_irq_mask);
}
static int mpc8xx_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- if (flow_type IRQ_TYPE_EDGE_FALLING) {
- irq_hw_number_t hw = (unsigned int)irqd_to_hwirq(d);
+ /* only external IRQ senses are programmable */
+ if ((flow_type IRQ_TYPE_EDGE_FALLING) !(irqd_to_hwirq(d) 1))
{
unsigned int siel = in_be32(siu_reg-sc_siel);
-
- /* only external IRQ senses are programmable */
- if ((hw 1) == 0) {
- siel |= (0x8000 hw);
- out_be32(siu_reg-sc_siel, siel);
- __irq_set_handler_locked(d-irq, handle_edge_irq);
- }
+ siel |= mpc8xx_irqd_to_bit(d);
+ out_be32(siu_reg-sc_siel, siel);
+ __irq_set_handler_locked(d-irq, handle_edge_irq);
}
return 0;
}
@@ -132,6 +110,9 @@ static int mpc8xx_pic_host_xlate(struct irq_domain *h,
struct device_node *ct,
IRQ_TYPE_EDGE_FALLING,
};
+ if (intspec[0] 0x1f)
+ return 0;
+
*out_hwirq = intspec[0];
if (intsize 1 intspec[1] 4)
*out_flags = map_pic_senses[intspec[1]];
--
1.7.9.5
___
Linuxppc-dev mailing list
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Mon, Apr 16, 2012 at 5:03 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2012-04-16 at 14:13 -0600, Grant Likely wrote: Ben, I can take these two patches via my irqdomain tree if you prefer. Let me give them a test run first. Yes of course. I won't merge before they've been checked out. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Mon, Apr 16, 2012 at 5:03 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2012-04-16 at 14:13 -0600, Grant Likely wrote: The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but NR_IRQs could be smaller than the number of hardware irqs that ppc_cached_irq_mask tracks. Also, while fixing that problem, it became apparent that the interrupt controller only supports 32 interrupt numbers, but it is written as if it supports multiple register banks which is more complicated. This patch pulls out the buggy reference to NR_IRQs and fixes the size of the ppc_cached_irq_mask to match the number of HW irqs. It also drops the now-unnecessary code since ppc_cached_irq_mask is no longer an array. Can you rename ppc_cached_irq_mask while at it ? I think it was written that way because it was all copy/pasted from powermac/pic.c which -does- need it to be an array (and has the same bugs btw) :-) I wonder if we can get rid of the cached mask alltogether... I have the feeling that we could just rely on the irq_desc fields nowadays for that... this code is ancient. The irq_desc fields aren't ideal because they are per-irq and would need to be 'ed together for each mask/unmask/ack operation. We could store something in the irq_domain I suppose, but I'm not convinced it is worth it for an interrupt controller that will only ever have one instance in the system. If I were to refactor any deeper than I have, then I'm move this driver over to use irq_generic_chip instead. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Mon, 2012-04-16 at 14:13 -0600, Grant Likely wrote: Ben, I can take these two patches via my irqdomain tree if you prefer. Let me give them a test run first. Hi Ben If you are going to test 8xx, could you revert e0908085fc2391c85b85fb814ae1df377c8e0dcb, powerpc/8xx: Fix regression introduced by cache coherency rewrite ? It should not be needed after I fixed up the 8xx TLB code and added a workaround for buggy dcbX instructions. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Tue, 2012-04-17 at 02:03 +0200, Joakim Tjernlund wrote: If you are going to test 8xx, could you revert e0908085fc2391c85b85fb814ae1df377c8e0dcb, powerpc/8xx: Fix regression introduced by cache coherency rewrite ? It should not be needed after I fixed up the 8xx TLB code and added a workaround for buggy dcbX instructions. Have you actually verified that things still work after reverting it ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/21] EEH reorganization
I just hit this on mainline from today (3.4.0-rc2-00065-gf549e08). Haven't had a chance to narrow it down yet. Thanks for the information. I'll try to reproduce the issue on Firebird-L today. By the way, it seems that mstmread is some user-level application accessing the config space while the problem happened? Looking closer, it was caused by an EEH error at boot. It looks like the Mellanox infiniband card gets an error when probed by their firmware tool (mstmread), but only if the kernel driver is not loaded. I see this EEH error back on 3.0, so it's not new. The question now is why we oops in the EEH code on mainline. It seems the crash was caused by something like WARN_ON(). I checked the function pointed by the backtrace (eeh_dn_check_failure) and I didn't find any place has called WARN_ON() staff. Maybe I missed something here. Anyway, I'll try to reproduce it on Firebird-L machine first of all and then narrow it down. Anton Thanks, Gavin [ cut here ] WARNING: at arch/powerpc/platforms/pseries/eeh.c:492 Modules linked in: NIP: c0056cc4 LR: c0056cc0 CTR: c051dd60 REGS: c01f3953f6a0 TRAP: 0700 Not tainted (3.4.0-rc2-00065-gf549e08-dirty) MSR: 80029032 SF,EE,ME,IR,DR,RI CR: 28004482 XER: 000f SOFTE: 0 CFAR: c074ea30 TASK = c01f39685040[19058] 'mstmread' THREAD: c01f3953c000 CPU: 38 GPR00: c0056cc0 c01f3953f920 c0bd3a28 0021 GPR04: 000323f7 GPR08: 6365203c c0b10a20 0002 c0a74cc0 GPR12: 24004422 ceda8500 3a58582e 583a5858 GPR16: 2f585858 69636573 2f646576 10003b48 GPR20: 0fffc7a3d17c 0058 0004 c01f3953fb90 GPR24: c0c77088 c03e6fffeee8 GPR28: c0d82680 c0c770d0 NIP [c0056cc4] .eeh_dn_check_failure+0x304/0x320 LR [c0056cc0] .eeh_dn_check_failure+0x300/0x320 Call Trace: [c01f3953f920] [c0056cc0] .eeh_dn_check_failure+0x300/0x320 (unreliable) [c01f3953f9d0] [c002717c] .rtas_read_config+0x13c/0x1b0 [c01f3953fa70] [c03d543c] .pci_user_read_config_dword+0xcc/0x150 [c01f3953fb20] [c03e19d8] .pci_read_config+0xe8/0x2a0 [c01f3953fc00] [c022d330] .read+0x130/0x210 [c01f3953fce0] [c01a723c] .vfs_read+0xec/0x1e0 [c01f3953fd80] [c01a73ec] .SyS_pread64+0xbc/0xd0 [c01f3953fe30] [c0009780] syscall_exit+0x0/0x7c Instruction dump: 7f83e378 48001909 6000 2fbf 419e002c e89f00d8 2fa4 409e0008 e89f0098 e8629fb8 486f7d39 6000 0fe0 3b21 4bfffdb4 e8829fa8 ---[ end trace a6e6d788c9869e00 ]--- EEH: Detected PCI bus error on device 0006:01:00.0 EEH: This PCI device has failed 1 times in the last hour: EEH: Bus location=U78AB.001.WZSGRFL-P1-C4-T1 driver= pci addr=0006:01:00.0 EEH: Device location=U78AB.001.WZSGRFL-P1-C4-T1 driver= pci addr=0006:01:00.0 EEH: of node=/pci@8002203/pci1014,415@0 EEH: PCI device/vendor: 673c15b3 EEH: PCI cmd/status register: 00100140 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/21] EEH reorganization
Hi, Thanks for the information. I'll try to reproduce the issue on Firebird-L today. By the way, it seems that mstmread is some user-level application accessing the config space while the problem happened? The EEH error is caused by the Melanox firmware tools. It seems the crash was caused by something like WARN_ON(). I checked the function pointed by the backtrace (eeh_dn_check_failure) and I didn't find any place has called WARN_ON() staff. Maybe I missed something here. No. I replaced that backtrace in eeh_dn_check_failure with a WARN_ON() because the backtrace doesn't give us enough info. I'm submitting a patch for that today. Bottom line is mstmread has been causing an EEH error since at least 3.0, but in 3.4 we now oops instead of recovering. The signs all point to the EEH rework in 3.4. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/mpc85xx: p1022ds support the MTD for NOR and NAND flash
From: Jerry Huang chang-ming.hu...@freescale.com
The compatilbe 'simple-bus' is removed from the latest DTS for NAND and
NOR flash partition, so we must add the new compatilbe support for p1022ds,
otherwise, the kernel can't parse the partition of NOR and NAND flash.
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
---
arch/powerpc/platforms/85xx/p1022_ds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 6c8ff8b..8948293 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -379,6 +379,7 @@ static struct of_device_id __initdata p1022_ds_ids[] = {
{ .compatible = gianfar, },
/* So that the DMA channel nodes can be probed individually: */
{ .compatible = fsl,eloplus-dma, },
+ { .compatible = fsl,p1022-elbc, },
{},
};
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/p1022ds/DTS: Add RTC support
From: Jerry Huang chang-ming.hu...@freescale.com
Add the RTC support for p1022ds
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
---
arch/powerpc/boot/dts/p1022ds.dtsi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi
b/arch/powerpc/boot/dts/p1022ds.dtsi
index 2b0d9e9..904b653 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -42,6 +42,10 @@
* the clock is enabled.
*/
};
+ rtc@68 {
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ };
};
spi@7000 {
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/21] EEH reorganization
On Tue, 2012-04-17 at 11:37 +1000, Anton Blanchard wrote: No. I replaced that backtrace in eeh_dn_check_failure with a WARN_ON() because the backtrace doesn't give us enough info. I'm submitting a patch for that today. Bottom line is mstmread has been causing an EEH error since at least 3.0, but in 3.4 we now oops instead of recovering. The signs all point to the EEH rework in 3.4. More precisely, the original oops reported by Anton decodes as such: Oops: Kernel access of bad area, sig: 11 [#1] This is typically a bad memory access.. SMP NR_CPUS=1024 NUMA pSeries Modules linked in: NIP: c0055af8 LR: c0033204 CTR: REGS: c01f42fb7990 TRAP: 0300 Tainted: GW (3.4.0-rc2-00065-gf549e08-dirty) TRAP: 300 means that it's the result of a data access interrupts, ie, load or store to a bad address MSR: 80009032 SF,EE,ME,IR,DR,RI CR: 24008084 XER: SOFTE: 1 CFAR: 49b8 DAR: 0070, DSISR: 4000 Here the DAR tells us what address was accessed. 0x70 is a strong indication that this was an access to a NULL pointer (at offset 0x70 from that pointer). It -might- be something else (such as a NULL passed to a list head or such) but the idea that there's a NULL floating around is a good hint. TASK = c01f6c7dfc40[19010] 'eehd' THREAD: c01f42fb4000 CPU: 6 GPR00: 0001 c01f42fb7c10 c0bd3a28 c01f80ab0800 GPR04: c01f7c57d418 0380 c01f7c57e070 c0ed5360 GPR08: c0c77088 0001 GPR12: 44008088 ceda1500 019ffa78 00a7 GPR16: 00bb c0a9f754 c0963230 005e GPR20: 01b37e80 00bb c0b0ad90 GPR24: c0b10588 0001 c01f80ab0800 GPR28: c01f80ab0828 c01f7ee1 NIP [c0055af8] .eeh_add_device_tree_late+0x58/0xf0 This is the function where it happened (eeh_add_device_tree_late) LR [c0033204] .pcibios_finish_adding_to_bus+0x34/0x50 Call Trace: [c01f42fb7c10] [fdff] 0xfdff (unreliable) [c01f42fb7ca0] [c0033204] .pcibios_finish_adding_to_bus+0x34/0x50 [c01f42fb7d20] [c0059a5c] .pcibios_add_pci_devices+0x7c/0x190 [c01f42fb7db0] [c0057a6c] .eeh_reset_device+0xfc/0x1a0 [c01f42fb7e50] [c0057e18] .handle_eeh_events+0x308/0x480 [c01f42fb7f00] [c00584dc] .eeh_event_handler+0x13c/0x1d0 [c01f42fb7f90] [c002099c] .kernel_thread+0x54/0x70 And your backtrace. You can see that you got an eeh event, which triggered an eeh reset, which triggered a pcibios_add_pci_devices() etc... Instruction dump: 48a8 6000 ebff 7fbfe800 419e0098 2fbf 419e005c e9229eb0 80090008 2f80 419e004c ebdf01d0 e81e0070 7fbf 3160 7d2b0110 Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3]KVM: PPC: Use clockevent multiplier and shifter for decrementer
Time for which the hrtimer is started for decrementer emulation is calculated
using tb_ticks_per_usec. While hrtimer uses the clockevent for DEC
reprogramming (if needed) and which calculate timebase ticks using the
multiplier and shifter mechanism implemented within clockevent layer. It was
observed that this conversion (timebase-time-timebase) are not correct
because the mechanism are not consistent. In our setup it adds 2% jitter.
With this patch clockevent multiplier and shifter mechanism are used when
starting hrtimer for decrementer emulation. Now the jitter is 0.5%.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v3:
- decrementer_clockevent symbol exported.
arch/powerpc/include/asm/time.h |1 +
arch/powerpc/kernel/time.c |3 ++-
arch/powerpc/kvm/emulate.c |5 +++--
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 7eb10fb..b3c7959 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -28,6 +28,7 @@
extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
+extern struct clock_event_device decrementer_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 567dd7c..4f7a285 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -105,7 +105,7 @@ static int decrementer_set_next_event(unsigned long evt,
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev);
-static struct clock_event_device decrementer_clockevent = {
+struct clock_event_device decrementer_clockevent = {
.name = decrementer,
.rating = 200,
.irq= 0,
@@ -113,6 +113,7 @@ static struct clock_event_device decrementer_clockevent = {
.set_mode = decrementer_set_mode,
.features = CLOCK_EVT_FEAT_ONESHOT,
};
+EXPORT_SYMBOL(decrementer_clockevent);
DEFINE_PER_CPU(u64, decrementers_next_tb);
static DEFINE_PER_CPU(struct clock_event_device, decrementers);
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index afc9154..c8b5206 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -23,6 +23,7 @@
#include linux/types.h
#include linux/string.h
#include linux/kvm_host.h
+#include linux/clockchips.h
#include asm/reg.h
#include asm/time.h
@@ -104,8 +105,8 @@ void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
*/
dec_time = vcpu-arch.dec;
- dec_time *= 1000;
- do_div(dec_time, tb_ticks_per_usec);
+ dec_time = dec_time decrementer_clockevent.shift;
+ do_div(dec_time, decrementer_clockevent.mult);
dec_nsec = do_div(dec_time, NSEC_PER_SEC);
hrtimer_start(vcpu-arch.dec_timer,
ktime_set(dec_time, dec_nsec), HRTIMER_MODE_REL);
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/21] EEH reorganization
Ben, thanks a lot for the backtrace to help narrowing down the root
cause. Also thanks a lot for how to parse the backtrace and register
staff printed by oops ;-)
Finally, I successfully reproduced the issue on Firebird-L machine
without loading the corresponding device driver for Emulex ethernet
by disable the corresponding config options in .config. With injected
config space data parity error destined to the Emulex ethernet MAC,
I saw following backtrace. The problem came from following piece of
code. Actually, the EEH device should be retrieve from OF node instead
of PCI device since the PCI device didn't trace the corresponding
EEH device yet at that time. I'll send one patch against it soon even
it only need 1 line of code change ;-)
(gdb) p (((struct eeh_dev *)0)-pdev)
$1 = (struct pci_dev **) 0x70
static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct eeh_dev *edev;
if (!dev || !eeh_subsystem_enabled)
return;
dn = pci_device_to_OF_node(dev);
edev = pci_dev_to_eeh_dev(dev); edev should be NULL
if (edev-pdev == dev) { data access fault here.
pr_debug(EEH: Already referenced !\n);
return;
}
WARN_ON(edev-pdev);
:
:
}
[ 176.972046] Unable to handle kernel paging request for data at address
0x0070
[ 176.972054] Faulting instruction address: 0xc0055ecc
[ 176.972064] Oops: Kernel access of bad area, sig: 11 [#1]
[ 176.972070] SMP NR_CPUS=1024 NUMA pSeries
[ 176.972078] Modules linked in:
[ 176.972086] NIP: c0055ecc LR: c0055ec8 CTR: c005babc
[ 176.972102] REGS: c00f4d913970 TRAP: 0300 Not tainted (3.4.0-rc2+)
[ 176.972109] MSR: 80009032 SF,EE,ME,IR,DR,RI CR: 2884 XER:
0009
[ 176.972129] SOFTE: 1
[ 176.972133] CFAR: c0005080
[ 176.972138] DAR: 0070, DSISR: 4000
[ 176.972146] TASK = c00f4d8c3600[1038] 'eehd' THREAD: c00f4d91
CPU: 24
[ 176.972155] GPR00: c0055ec8 c00f4d913bf0 c147ed90
001e
[ 176.972170] GPR04:
[ 176.972183] GPR08: 4f4e450d c0c44208 00036710
00ec
[ 176.972197] GPR12: 2882 cff25400
0106c9c8
[ 176.972212] GPR16: 0228 02e5acf0 01aff9a4
0060
[ 176.972227] GPR20:
c1345c78
[ 176.972241] GPR24: c1345c70
c0851ac0
[ 176.972256] GPR28: c0a95ad3 c00f529f2c28 c00f529f2c00
c00f4d88
[ 176.972276] NIP [c0055ecc] .eeh_add_device_tree_late+0x17c/0x2c4
[ 176.972286] LR [c0055ec8] .eeh_add_device_tree_late+0x178/0x2c4
[ 176.972294] Call Trace:
[ 176.972300] [c00f4d913bf0] [c0055ec8]
.eeh_add_device_tree_late+0x178/0x2c4 (unreliable)
[ 176.972316] [c00f4d913ca0] [c0036bc8]
.pcibios_finish_adding_to_bus+0x74/0x90
[ 176.972328] [c00f4d913d20] [c0059b50]
.pcibios_add_pci_devices+0x12c/0x150
[ 176.972339] [c00f4d913db0] [c0057c60]
.eeh_reset_device+0x10c/0x140
[ 176.972350] [c00f4d913e50] [c0057ee4]
.handle_eeh_events+0x250/0x42c
[ 176.972361] [c00f4d913f10] [c0058560]
.eeh_event_handler+0xe4/0x178
[ 176.972372] [c00f4d913f90] [c0021550] .kernel_thread+0x54/0x70
[ 176.972380] Instruction dump:
[ 176.972384] eb82a1f0 7f83e378 487dd2e9 6000 e862a1f8 7f64db78 487dd2d9
6000
[ 176.972400] eb5f02c0 7f83e378 487dd2c9 6000 e81a0070 7fa0f800 40de0028
e862a188
Thanks,
Gavin
More precisely, the original oops reported by Anton decodes as such:
Oops: Kernel access of bad area, sig: 11 [#1]
This is typically a bad memory access..
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c0055af8 LR: c0033204 CTR:
REGS: c01f42fb7990 TRAP: 0300 Tainted: GW
(3.4.0-rc2-00065-gf549e08-dirty)
TRAP: 300 means that it's the result of a data access interrupts, ie,
load or store to a bad address
MSR: 80009032 SF,EE,ME,IR,DR,RI CR: 24008084 XER:
SOFTE: 1
CFAR: 49b8
DAR: 0070, DSISR: 4000
Here the DAR tells us what address was accessed. 0x70 is a strong indication
that this was an access to a NULL pointer (at offset 0x70 from that pointer).
It -might- be something else (such as a NULL passed to a list head or such)
but the idea that there's a NULL floating around is a good hint.
TASK = c01f6c7dfc40[19010] 'eehd' THREAD: c01f42fb4000 CPU: 6
GPR00: 0001 c01f42fb7c10 c0bd3a28 c01f80ab0800
GPR04: c01f7c57d418 0380 c01f7c57e070 c0ed5360
GPR08: c0c77088
Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 2012/04/17 03:00:40: On Tue, 2012-04-17 at 02:03 +0200, Joakim Tjernlund wrote: If you are going to test 8xx, could you revert e0908085fc2391c85b85fb814ae1df377c8e0dcb, powerpc/8xx: Fix regression introduced by cache coherency rewrite ? It should not be needed after I fixed up the 8xx TLB code and added a workaround for buggy dcbX instructions. Have you actually verified that things still work after reverting it ? Nope, I haven't moved our 8xx to 3.x. We are still on 2.4 and it works there. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/eeh: crash caused by null eeh_dev
The problem was reported by Anton Blanchard. While EEH error
happened to the PCI device without the corresponding device
driver, kernel crash was seen. Eventually, I successfully
reproduced the problem on Firebird-L machine with utility
errinjct. Initially, the device driver for Emulex ethernet
MAC has been disabled from .config and force data parity on
the Emulex ethernet MAC with help of errinjct. Eventually,
I saw the kernel crash after issueing couple of lspci -v
command.
The root cause behind is that the PCI device, including the
reference to the corresponding eeh device, will be removed
from the system while EEH does recovery. Afterwards, the
PCI device will be probed again and added into the system
accordingly. So it's not safe to retrieve the eeh device from
the corresponding PCI device after the PCI device has been removed
and not added again.
The patch fixes the issue and retrieve the eeh device from OF node
instead of PCI device after the PCI device has been removed.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/eeh.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c
b/arch/powerpc/platforms/pseries/eeh.c
index 309d38e..a75e37d 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -1076,7 +1076,7 @@ static void eeh_add_device_late(struct pci_dev *dev)
pr_debug(EEH: Adding device %s\n, pci_name(dev));
dn = pci_device_to_OF_node(dev);
- edev = pci_dev_to_eeh_dev(dev);
+ edev = of_node_to_eeh_dev(dn);
if (edev-pdev == dev) {
pr_debug(EEH: Already referenced !\n);
return;
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
