On Mon, 3 Jun 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.10-rc4 to v3.10-rc3[3], the summaries are:
> - build errors: +6/-2
> - build warnings: +66/-132
+ arch/powerpc/sysdev/mpic.c: error: case label does not reduce to an integer
constant: => 890:9, 898:9, 886:9, 894:9
pow
On Fri, 2013-05-31 at 17:31 +0100, Grant Likely wrote:
> On Fri, May 31, 2013 at 5:04 PM, Stephen Warren wrote:
> > On 05/31/2013 05:48 AM, Grant Likely wrote:
> >> ---
> >> commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37
> >> Author: Grant Likely
> >> Date: Fri May 31 12:45:18 2013 +0100
> >>
On Sat, Jun 01, 2013 at 07:49:44AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-05-28 at 15:59 +0800, Zhao Chenhui wrote:
> > Some features depend on the boot cpu, for instance, hibernate/suspend.
> > So disable hotplug for the boot cpu.
>
> Don't we have code to "move" the boot CPU around
Currently sys_sigreturn() is transactional memory unaware, hence if we take a
32 bit signal without SIGINFO (non RT) inside a transaction, we don't restore
the signal frame correctly on return.
This checks if the signal frame being restoring is an active transaction, and
if so, it copies the addit
This fixes a warning:
DTC arch/powerpc/boot/virtex440-ml507.dtb
Warning (reg_format): "reg" property in
/plb@0/xps-ll-temac@81c0/ethernet@81c0/phy@7 has invalid length (4
bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-c
Currently I see:
DTC arch/powerpc/boot/kilauea.dtb
Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C1000 has invalid
length (12 bytes) (#address-cells == 1, #size-cells == 1)
It appears that unlike the other plarforms handled by 3fb7933850fa
"powerpc/4xx: Adding PCIe MSI support
Signed-off-by: Ian Campbell
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/boot/.gitignore |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index
the PPC_MPC512x config automatically selected USB_EHCI_BIG_ENDIAN_*
switches, which made Kconfig warn about "unmet direct dependencies":
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (PPC_MPC512x && 440EPX) selects USB_EHCI_BIG_ENDIAN_DESC which has
unmet direct dependencies (USB_SU
> From: Stephen Warren
>
> Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
> could match line-break characters. If the #line directive did not contain
> the optional flags field at the end, this could cause any integer data on
> the next line to be consumed as part of the
On Mon, Jun 03, 2013 at 12:00:24PM +0100, Ian Campbell wrote:
>Currently I see:
> DTC arch/powerpc/boot/kilauea.dtb
>Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C1000 has invalid
>length (12 bytes) (#address-cells == 1, #size-cells == 1)
>
>It appears that unlike the other pla
On Mon, 2013-06-03 at 09:36 -0400, Josh Boyer wrote:
> On Mon, Jun 03, 2013 at 12:00:24PM +0100, Ian Campbell wrote:
> >Currently I see:
> > DTC arch/powerpc/boot/kilauea.dtb
> >Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C1000 has
> >invalid length (12 bytes) (#address-cells
From: Stephen Warren
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line direct
On Mon, 2013-06-03 at 09:36 -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
> could match line-break characters. If the #line directive did not contain
> the optional flags field at the end, this could cause any integ
On 06/01/2013 07:07:20 PM, Kevin Hao wrote:
On Sat, Jun 01, 2013 at 09:47:16PM +1000, Benjamin Herrenschmidt
wrote:
> On Sat, 2013-06-01 at 18:59 +0800, Kevin Hao wrote:
>
> > The effect of this change is that the isa_io_base will be 0 and
the IO
> > resource are equal to the virtual address
Interrupt numbers defined for Book3E follows IVORs definition. Align
BOOKE_INTERRUPT_ALTIVEC_UNAVAIL and BOOKE_INTERRUPT_ALTIVEC_ASSIST to this
rule which also fixes the build breakage.
IVORs 32 and 33 are shared so reflect this in the interrupts naming.
Signed-off-by: Mihai Caraman
---
arch/pow
Add ONE_REG support for AltiVec on Book3E.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 01eb635..019496d 100644
--- a/ar
Rename BOOKE_IRQPRIO_SPE_UNAVAIL and BOOKE_IRQPRIO_SPE_FP_DATA names
to accommodate ALTIVEC. Replace BOOKE_INTERRUPT_SPE_UNAVAIL and
BOOKE_INTERRUPT_SPE_FP_DATA with the common version.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 12 ++--
arch/powerpc/kvm/b
SPE_FP interrupts are shared with ALTIVEC. Refactor SPE_FP exit handling
to detect KVM support for the featured unit at run-time, in order to
accommodate ALTIVEC later.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 80 ++
1 files change
Mihai Caraman (6):
KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage
KVM: PPC: Book3E: Refactor SPE_FP exit handling
KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC
KVM: PPC: Book3E: Add AltiVec support
KVM: PPC: Book3E: Add ONE_REG AltiVec support
KVM: PP
KVM Book3E FPU support gracefully reuse host infrastructure so we do the
same for AltiVec. To keep AltiVec lazy call kvmppc_load_guest_altivec()
just when returning to guest instead of each sched in.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 74 ++
Adopt AltiVec approach to increase laziness by calling kvmppc_load_guest_fp()
just before returning to guest instaed of each sched in.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c |1 +
arch/powerpc/kvm/e500mc.c |2 --
2 files changed, 1 insertions(+), 2 deletions(-)
diff
On 5/29/2013 2:11 PM, Brian King wrote:
On 05/29/2013 10:15 AM, Robert Knight wrote:
Sometime after kernel 3.3.4, Fedora 17 running on an IBM OpenPower
720 stopped being able to read the SCSI disks with an error
concerning a return code -1. In the updates since, it has not
resumed working.
Doe
On Mon, 2013-06-03 at 17:20 -0400, Robert Knight wrote:
> On 5/29/2013 2:11 PM, Brian King wrote:
> > On 05/29/2013 10:15 AM, Robert Knight wrote:
> >> Sometime after kernel 3.3.4, Fedora 17 running on an IBM OpenPower
> >> 720 stopped being able to read the SCSI disks with an error
> >> concerning
On 04/19/2013 05:47:38 AM, Zhao Chenhui wrote:
From: Li Yang
Signed-off-by: Li Yang
Signed-off-by: Zhao Chenhui
---
.../devicetree/bindings/powerpc/fsl/pmc.txt| 59
+++
1 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bind
On Mon, Mar 05, 2012 at 11:10:53PM -, chenhui zhao wrote:
> From: chenhui zhao
>
> The workarounds need to detect the cpu type. Add these macros
> and inline routines to help cpu type detection in runtime.
>
> Signed-off-by: Zhao Chenhui
> Signed-off-by: Li Yang
>
> ---
> arch/powerpc/inc
On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote:
> >Device tree struct 0x0482 -> 0x0484
> >Calling quiesce...
> >returning from prom_init
> >[1.376359] ehci-pci :c8:01.2: can't setup
Can you try adding "debug" to the kernel commandline. We're missin
On 6/3/2013 8:01 PM, Tony Breeds wrote:
On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote:
Device tree struct 0x0482 -> 0x0484
Calling quiesce...
returning from prom_init
[1.376359] ehci-pci :c8:01.2: can't setup
Can you try adding "debug" to the ke
Benh,
Can you take this for 3.10 also?
Mikey
Michael Neuling wrote:
> Some CPUs have a DABR but not DABRX. Configuration are:
> - No 32bit CPUs have DABRX but some have DABR.
> - POWER4+ and below have the DABR but no DABRX.
> - 970 and POWER5 and above have DABR and DABRX.
> - POWER8 has DAWR
On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote:
> On 6/3/2013 8:01 PM, Tony Breeds wrote:
> >On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote:
> >
> >>>Device tree struct 0x0482 -> 0x0484
> >>>Calling quiesce...
> >>>returning from prom_init
> >>
On Tue, Jun 04, 2013 at 01:16:52PM +1000, Tony Breeds wrote:
>On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote:
>> On 6/3/2013 8:01 PM, Tony Breeds wrote:
>> >On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote:
>> >
>> >>>Device tree struct 0x0482 -> 0x0
In commit bc09c21 "Fix finding overflowed PMC in interrupt" we added
a printk() to the PMU exception handler. Unfortunately that is not safe.
The problem is that the PMU exception runs even when interrupts are soft
disabled. We do this so that we can profile parts of the kernel that
have interrupt
Back in commit 89713ed "Add timer, performance monitor and machine check
counts to /proc/interrupts" we added a count of PMU interrupts to the
output of /proc/interrupts.
At the time we named them "CNT" to match x86.
However in commit 89ccf46 "Rename 'performance counter interrupt'", the
x86 guys
32 matches
Mail list logo
