On Tue, May 31, 2011 at 5:35 AM, Paul Mackerras wrote:
> On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
>
>> Thinking about the testability of this a bit more ... how much
>> effort would it be to get this code running on a 970MP with SLOF?
>> There should only be a few POWER7 spe
We have a TQM5200 board, which has GPIO lines hooked up to an SM501.
I've managed to come up with the following patch to the tqm5200 device
tree, which manages to convince the sm501 driver to attach an sm501-fb:
--- a/arch/powerpc/boot/dts/tqm5200.dts 2009-11-23 03:13:27.0 -0800
+++ b/arc
On Wed, Jun 01, 2011 at 12:34:43AM +0200, Segher Boessenkool wrote:
> There's a loop of 128 iterations of 3 insns.
>
> I'm not saying it is actually bad, just that that 50 is slightly off ;-)
That would be the TLB invalidation. On POWER7 we only need to do that
if the virtual cpu last ran on a
On Tue, May 31, 2011 at 02:50:20PM +0200, Alexander Graf wrote:
>
> On 31.05.2011, at 14:35, Paul Mackerras wrote:
>
> > On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
> >
> >> Thinking about the testability of this a bit more ... how much
> >> effort would it be to get this cod
Not sure how I would know -- But with my eiger kit, I got a
cd from amcc that had a patched 2.6.30 or something kernel
in it to support the 460SX. The pci code was basically
subverted by adding a "port->link=1" at the very end of the
link check to always force it to succeed. However this code
ne
The interesting question of course is whether that 460SX stuff is the
same as what we're using internally :-)
[marri] Sometimes open-source and internal releases may not be the same
Because of open-source standards.
Can we fix that ?
[marri] Sure I will take a look at it.
_
On Tue, 2011-05-31 at 20:02 -0700, Christian Kujau wrote:
> (Cc'in Linus)
>
> On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
> > In the meantime, "git bisect" behaves kinda weird, I don't know what went
> > wrong here:
> >
> > $ git bisect start
> > $ git bisect good # Linux 2.6.
Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
system call numbering for execve and selecting HAVE_SECCOMP_FILTER.
Signed-off-by: Will Drewry
---
arch/powerpc/Kconfig |1 +
arch/powerpc/include/asm/seccomp.h |2 ++
2 files changed, 3 insertions(+), 0
(Cc'in Linus)
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
> In the meantime, "git bisect" behaves kinda weird, I don't know what went
> wrong here:
>
> $ git bisect start
> $ git bisect good # Linux 2.6.39
> $ git bisect bad v3.0-rc1 # Linux 3.0-rc1
> $ git bisect bad
Back in 2006 the "udbg-immortal" kernel option has been introduced:
> commit 3b5e905ee3bd23e9311951890aba57a0dbc81ca4
> Author: Benjamin Herrenschmidt
> Date: Wed Jun 7 12:06:20 2006 +1000
>
> [PATCH] powerpc: Add udbg-immortal kernel option
...but I could not find it documented any
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
> On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
> > Hrm, I had it working on a pair of powerbooks yesterday. Can you try
> > something like "udbg-immortal" on your kernel command line to see if
> > that makes a difference in the outp
On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
> Hrm, I had it working on a pair of powerbooks yesterday. Can you try
> something like "udbg-immortal" on your kernel command line to see if
> that makes a difference in the output ?
I'll try in a minute.
In the meantime, "git bisect" be
On Tue, 2011-05-31 at 16:50 -0700, Christian Kujau wrote:
> Hi,
>
> trying to boot 3.0-rc1 on powerpc32 only progresses until:
>
> > Kernel virtual memory layout:
> > * 0xfffcf000..0xf000 : fixmap
>
> And then the system hangs, does not respond to keyboard (sysrq does not
> seem to w
Hi,
trying to boot 3.0-rc1 on powerpc32 only progresses until:
> Kernel virtual memory layout:
> * 0xfffcf000..0xf000 : fixmap
And then the system hangs, does not respond to keyboard (sysrq does not
seem to work on this PowerBook G4). But after a while the system reboots
itself, so
Sure, but that shouldn't happen with HDEC during the odd 50
instructions that it takes to enter the guest :)
It's more like 500 insns, including some ptesync, so lots of cycles
too.
I don't think its actually that bad.
There's a loop of 128 iterations of 3 insns.
I'm not saying it is actua
31.05.2011 02:17, Benjamin Herrenschmidt пишет:
On Mon, 2011-05-30 at 17:11 -0500, kevin diggs wrote:
Hi,
This is an SMP machine ? If not, does it work with a UP kernel ?
Cheers,
Ben.
??? Even if it is SMP, you can run non-SMP kernel on it, right?
Yes, I was asking whether the bug also occ
On May 27, 2011, at 9:07 PM, Segher Boessenkool wrote:
If HDEC expires when interrupts are off, the HDEC interrupt stays
pending until interrupts get re-enabled. I'm not sure exactly what
the conditions are that cause an HDEC interrupt to get lost, but they
seem to involve at
On May 31, 2011, at 8:50 AM, Alexander Graf wrote:
>
> On 31.05.2011, at 14:35, Paul Mackerras wrote:
>
>> On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
>>
>>> Thinking about the testability of this a bit more ... how much
>>> effort would it be to get this code running on a
On 5/31/11, Kumar Gala wrote:
>
> On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote:
>
>> Hello,
>>
>> Long time ago (around July of 2010), I've reported a problem of binding
>> pci error reporting driver to the hardware (See
>> http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant
On Tue, 31 May 2011 14:19:02 -0500
Meador Inge wrote:
> This binding documents how the message register blocks found in some FSL
> MPIC implementations shall be represented in a device tree.
>
> Signed-off-by: Meador Inge
> Cc: Hollis Blanchard
> Cc: Grant Likely
> Cc: Benjamin Herrenschmidt
On 05/26/2011 03:06 PM, Scott Wood wrote:
>> > +- interrupts: Specifies a list of interrupt source and level-sense
>> > pairs.
>> > + The type shall be . The length shall be equal
>> > to
>> > + the number of bits set in the 'msg-receive-mask' property value.
> Oh, just noticed --
Some MPIC implementations contain one or more blocks of message registers
that are used to send messages between cores via IPIs. A simple API has
been added to access (get/put, read, write, etc ...) these message registers.
The available message registers are initially discovered via nodes in the
This binding documents how the message register blocks found in some FSL
MPIC implementations shall be represented in a device tree.
Signed-off-by: Meador Inge
Cc: Hollis Blanchard
Cc: Grant Likely
Cc: Benjamin Herrenschmidt
Cc: Scott Wood
---
.../devicetree/bindings/powerpc/fsl/mpic-msgr.tx
This patch set defines a binding for FSL MPIC message registers and implements
an API for accessing those message registers. Testing was done on a MPC8572DS
in an Linux-Linux AMP setup using OpenMCAPI (www.openmcapi.org) to communicate
between OS instances. The message register API is used by the
On Tue, May 31, 2011 at 7:17 AM, Dmitry Eremin-Solenikov
wrote:
> Hello,
>
> Long time ago (around July of 2010), I've reported a problem of binding
> pci error reporting driver to the hardware (See
> http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
> come with a patch to cre
On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> Long time ago (around July of 2010), I've reported a problem of binding
> pci error reporting driver to the hardware (See
> http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
> come with a patch to creat
Andreas Schwab writes:
> Larry Finger writes:
>
>> On 05/31/2011 10:54 AM, Andreas Schwab wrote:
>>> Larry Finger writes:
>>>
From the traceback, it must be the serdes_pll_device read that failed.
>>>
>>> Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
>>
>> Mainly because the
Larry Finger writes:
> On 05/31/2011 10:54 AM, Andreas Schwab wrote:
>> Larry Finger writes:
>>
>>> From the traceback, it must be the serdes_pll_device read that failed.
>>
>> Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
>
> Mainly because the last two steps in the traceback are
On 05/31/2011 10:54 AM, Andreas Schwab wrote:
Larry Finger writes:
From the traceback, it must be the serdes_pll_device read that failed.
Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
Mainly because the last two steps in the traceback are
[c2ca5c40] [f2146244] ssb_pcie_read
On Fri, May 27, 2011 at 8:25 AM, Thomas De Schampheleire
wrote:
> Although I realize that what I need to achieve is unconventional, what
> is the correct way of mapping a certain address range into memory, and
> be able to execute from it?
Can you look at using mpic_reset_core in arch/powerpc/sys
Larry Finger writes:
> From the traceback, it must be the serdes_pll_device read that failed.
Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for som
Hi,
Apologies if this is the wrong forum for this message but I figured it was
a good place to start.
We have a new P4040 based board and are having lots of fun trying to get
our BDI3k to work with it. The BDI isn't able to get control/halt the
processor. I can go into more details if anybody is
On 05/31/2011 04:37 AM, Andreas Schwab wrote:
Rafał Miłecki writes:
+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
+{
+ return (ssb_pcie_rea
Suzuki Poulose wrote:
Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
===
--- /dev/null
+++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
+ *
+ */
+blnxtins/* Find our address */
+nxtins:
Hello,
Long time ago (around July of 2010), I've reported a problem of binding
pci error reporting driver to the hardware (See
http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
come with a patch to create platform devices (of_platform at that time),
for device_nodes which have
On 31.05.2011, at 14:35, Paul Mackerras wrote:
> On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
>
>> Thinking about the testability of this a bit more ... how much
>> effort would it be to get this code running on a 970MP with SLOF?
>> There should only be a few POWER7 specific
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
> Thinking about the testability of this a bit more ... how much
> effort would it be to get this code running on a 970MP with SLOF?
> There should only be a few POWER7 specific pieces, right?
Do you have a 970MP that has a usable hy
On 31.05.2011, at 08:40, Paul Mackerras wrote:
> The following series of patches enable KVM to exploit the hardware
> hypervisor mode on 64-bit Power ISA Book3S machines. At present only
> POWER7 is supported, but it would be easy to add other processors.
>
> Running the KVM host in hypervisor
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 th
Doing so means that we don't have to save the flags anywhere and gets
rid of the last reference to to_book3s(vcpu) in arch/powerpc/kvm/book3s.c.
Doing so is OK because a program interrupt won't be generated at the
same time as any other synchronous interrupt. If a program interrupt
and an asynchr
This adds the infrastructure for handling PAPR hcalls in the kernel,
either early in the guest exit path while we are still in real mode,
or later once the MMU has been turned back on and we are in the full
kernel context. The advantage of handling hcalls in real mode if
possible is that we avoid
This arranges for the top-level arch/powerpc/kvm/powerpc.c file to
pass down some of the calls it gets to the lower-level subarchitecture
specific code. The lower-level implementations (in booke.c and book3s.c)
are no-ops. The coming book3s_hv.c will need this.
Signed-off-by: Paul Mackerras
---
In hypervisor mode, the LPCR controls several aspects of guest
partitions, including virtual partition memory mode, and also controls
whether the hypervisor decrementer interrupts are enabled. This sets
up LPCR at boot time so that guest partitions will use a virtual real
memory area (VRMA) compos
Instead of doing the kvm_guest_enter/exit() and local_irq_dis/enable()
calls in powerpc.c, this moves them down into the subarch-specific
book3s_pr.c and booke.c. This eliminates an extra local_irq_enable()
call in book3s_pr.c, and will be needed for when we do SMT4 guest
support in the book3s hyp
Instead of branching out-of-line with the DO_KVM macro to check if we
are in a KVM guest at the time of an interrupt, this moves the KVM
check inline in the first-level interrupt handlers. This speeds up
the non-KVM case and makes sure that none of the interrupt handlers
are missing the check.
Be
There are several fields in struct kvmppc_book3s_shadow_vcpu that
temporarily store bits of host state while a guest is running,
rather than anything relating to the particular guest or vcpu.
This splits them out into a new kvmppc_host_state structure and
modifies the definitions in asm-offsets.c t
From: David Gibson
This improves I/O performance for guests using the PAPR
paravirtualization interface by making the H_PUT_TCE hcall faster, by
implementing it in real mode. H_PUT_TCE is used for updating virtual
IOMMU tables, and is used both for virtual I/O and for real I/O in the
PAPR interf
Rafał Miłecki writes:
> +/**
> + * Workarounds.
> + **/
> +
> +static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
> +{
> + return (ssb_pcie_read(pc, 0x204) & 0x10) ? 0xC0 : 0x80;
> +
This moves the slb field, which represents the state of the emulated
SLB, from the kvmppc_vcpu_book3s struct to the kvm_vcpu_arch, and the
hpte_hash_[v]pte[_long] fields from kvm_vcpu_arch to kvmppc_vcpu_book3s.
This is in accord with the principle that the kvm_vcpu_arch struct
represents the state
The following series of patches enable KVM to exploit the hardware
hypervisor mode on 64-bit Power ISA Book3S machines. At present only
POWER7 is supported, but it would be easy to add other processors.
Running the KVM host in hypervisor mode means that the guest can use
both supervisor mode and
The Apple custom PIC only exist in some earlier machine models,
anything with an MPIC will crash on suspend if we register those
syscore ops unconditionally.
This is a regression caused by:
f5a592f7d74e38c5007876c731e6bf5580072e63
PM / PowerPC: Use struct syscore_ops instead of sysdevs for PM
Si
51 matches
Mail list logo
