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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
+++
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
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
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
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
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
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
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
---
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
42 matches
Mail list logo
