* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Benjamin Herrenschmidt @ 2011-06-01 3:49 UTC (permalink / raw)
To: Christian Kujau; +Cc: Linus Torvalds, linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1105311959000.21697@trent.utfs.org>
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.39
> > $ git bisect bad v3.0-rc1 # Linux 3.0-rc1
> > $ git bisect bad # c44dead70a...
> > $ git bisect bad # d93515611b..
> >
> > ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2.
> > Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?
>
> Hm, I tried again, from a clean v3.0-rc1 (git reset --hard), but after the
> 2nd "git bad" I'm at 2.6.39-rc2 again - while I /should/ be somwhere
> inbetween v2.6.39..v3.0-rc1, right?
Kernel version is totally irrelevant when bisecting. You are not walking
through a linear series of patches but a complex tree of merges which
might have forked off different versions in the first place.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v3 11/13] powerpc: select HAVE_SECCOMP_FILTER and provide seccomp_execve
From: Will Drewry @ 2011-06-01 3:10 UTC (permalink / raw)
To: linux-kernel
Cc: Will Drewry, linuxppc-dev, jmorris, rostedt, tglx, Paul Mackerras,
kees.cook, torvalds, mingo
In-Reply-To: <BANLkTimNcag-ZmVTXjUoTyiuJm6jtW0DgA@mail.gmail.com>
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 <wad@chromium.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/seccomp.h | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8f4d50b..0bd4574 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -137,6 +137,7 @@ config PPC
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select HAVE_GENERIC_HARDIRQS
select HAVE_SPARSE_IRQ
+ select HAVE_SECCOMP_FILTER
select IRQ_PER_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h
index 00c1d91..3cb9cc1 100644
--- a/arch/powerpc/include/asm/seccomp.h
+++ b/arch/powerpc/include/asm/seccomp.h
@@ -7,10 +7,12 @@
#define __NR_seccomp_write __NR_write
#define __NR_seccomp_exit __NR_exit
#define __NR_seccomp_sigreturn __NR_rt_sigreturn
+#define __NR_seccomp_execve __NR_execve
#define __NR_seccomp_read_32 __NR_read
#define __NR_seccomp_write_32 __NR_write
#define __NR_seccomp_exit_32 __NR_exit
#define __NR_seccomp_sigreturn_32 __NR_sigreturn
+#define __NR_seccomp_execve_32 __NR_execve
#endif /* _ASM_POWERPC_SECCOMP_H */
--
1.7.0.4
^ permalink raw reply related
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-01 3:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linus Torvalds, linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1105311744000.21697@trent.utfs.org>
(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 # c44dead70a...
> $ git bisect bad # d93515611b..
>
> ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2.
> Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?
Hm, I tried again, from a clean v3.0-rc1 (git reset --hard), but after the
2nd "git bad" I'm at 2.6.39-rc2 again - while I /should/ be somwhere
inbetween v2.6.39..v3.0-rc1, right?
Help, please!
Christian.
[0] http://nerdbynature.de/bits/3.0-rc1/
--
BOFH excuse #54:
Evil dogs hypnotised the night shift
^ permalink raw reply
* [PATCH] document udbg-immortal
From: Christian Kujau @ 2011-06-01 1:22 UTC (permalink / raw)
To: linuxppc-dev
Back in 2006 the "udbg-immortal" kernel option has been introduced:
> commit 3b5e905ee3bd23e9311951890aba57a0dbc81ca4
> Author: Benjamin Herrenschmidt <benh@au1.ibm.com>
> Date: Wed Jun 7 12:06:20 2006 +1000
>
> [PATCH] powerpc: Add udbg-immortal kernel option
...but I could not find it documented anywhere in the sources.
This patch adds it to Documentation/kernel-parameters.txt.
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index cc85a92..5d0df23 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2520,6 +2520,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
<port#>,<js1>,<js2>,<js3>,<js4>,<js5>,<js6>,<js7>
See also Documentation/input/joystick-parport.txt
+ udbg-immortal [PPC] When debugging early kernel crashes that
+ happen after console_init() and before a proper
+ console driver takes over, this boot options might
+ help "seeing" what's going on.
+
uhash_entries= [KNL,NET]
Set number of hash buckets for UDP/UDP-Lite connections
Thanks,
Christian.
--
BOFH excuse #45:
virus attack, luser responsible
^ permalink raw reply related
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-01 1:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1105311744000.21697@trent.utfs.org>
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 output ?
>
> I'll try in a minute.
Wow, it really did make a difference:
http://nerdbynature.de/bits/3.0-rc1/
* linux-3.0_powerpc_2.jpg
* linux-3.0_powerpc_2.mp4 (only a few(!) seconds long,
best to view with the slider in VLC oder Quicktime, to
get at least a grasp what lead to linux-3.0_powerpc_2.jpg)
Thanks,
Christian.
--
BOFH excuse #45:
virus attack, luser responsible
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-06-01 0:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux ppc dev, LKML
In-Reply-To: <1306887942.29297.10.camel@pasglop>
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" 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 # c44dead70a...
$ git bisect bad # d93515611b..
...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2.
Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?
Christian.
[0] http://nerdbynature.de/bits/3.0-rc1/
--
BOFH excuse #383:
Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet.
^ permalink raw reply
* Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Benjamin Herrenschmidt @ 2011-06-01 0:25 UTC (permalink / raw)
To: Christian Kujau; +Cc: linux ppc dev, LKML
In-Reply-To: <alpine.DEB.2.01.1105311644010.21697@trent.utfs.org>
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..0xfffff000 : 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 I guess the machine panicked but did not print anything on the
> screen.
>
> Full messages (picture), config & (working) dmesg:
>
> http://nerdbynature.de/bits/3.0-rc1/
>
> I'm currently trying to bisect this, so far I have:
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 ?
Cheers,
Ben.
> ----------------------
> git bisect start
> # good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf
> # bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1
> git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c
> # bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next'
> of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
> git bisect bad c44dead70a841d90ddc01968012f323c33217c9e
> # bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if
> lowerdev in a bond
> git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9
> ----------------------
>
> Any ideas?
>
> Thanks,
> Christian.
^ permalink raw reply
* 3.0-rc1: powerpc hangs at Kernel virtual memory layout
From: Christian Kujau @ 2011-05-31 23:50 UTC (permalink / raw)
To: LKML; +Cc: linux ppc dev
Hi,
trying to boot 3.0-rc1 on powerpc32 only progresses until:
> Kernel virtual memory layout:
> * 0xfffcf000..0xfffff000 : 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 I guess the machine panicked but did not print anything on the
screen.
Full messages (picture), config & (working) dmesg:
http://nerdbynature.de/bits/3.0-rc1/
I'm currently trying to bisect this, so far I have:
----------------------
git bisect start
# good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf
# bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1
git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c
# bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
git bisect bad c44dead70a841d90ddc01968012f323c33217c9e
# bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if
lowerdev in a bond
git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9
----------------------
Any ideas?
Thanks,
Christian.
--
BOFH excuse #263:
It's stuck in the Web.
^ permalink raw reply
* Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode
From: Segher Boessenkool @ 2011-05-31 22:34 UTC (permalink / raw)
To: Jimi Xenidis
Cc: kvm-ppc, Linuxppc-dev, Paul Mackerras, Alexander Graf, KVM list
In-Reply-To: <A052DEF7-7DA0-4573-89EC-0A685ED4B498@pobox.com>
>>> 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 actually bad, just that that 50 is slightly off ;-)
Segher
^ permalink raw reply
* Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
From: Andrey Gusev @ 2011-05-31 20:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kevin diggs, Tabi Timur-B04825, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1306793824.7481.622.camel@pasglop>
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 occured with an UP kernel.
>
> Cheers,
> Ben.
>
>
I checked the kernel without HOT PLUG CPU support, it works.
I checked the kernel without SMP support, it works.
I ckecked the final kernel without HOTPLUG CPU support it doesn't work.
There are a diff of the configuration files:
--- old_config 2011-05-31 20:35:23.459100951 +0400
+++ .config 2011-05-31 20:36:02.962653880 +0400
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux/powerpc 2.6.39-rc1 Kernel Configuration
-# Sun May 29 23:00:54 2011
+# Tue May 31 20:36:02 2011
#
# CONFIG_PPC64 is not set
@@ -310,8 +310,7 @@
CONFIG_BINFMT_MISC=m
# CONFIG_IOMMU_HELPER is not set
# CONFIG_SWIOTLB is not set
-CONFIG_HOTPLUG_CPU=y
-CONFIG_ARCH_CPU_PROBE_RELEASE=y
+# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
@@ -1875,7 +1874,6 @@
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
-# CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
--- old_config 2011-05-31 20:35:23.459100951 +0400
+++ .config 2011-05-31 22:32:07.595559180 +0400
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux/powerpc 2.6.39-rc1 Kernel Configuration
-# Sun May 29 23:00:54 2011
+# Tue May 31 22:32:07 2011
#
# CONFIG_PPC64 is not set
@@ -23,8 +23,7 @@
# CONFIG_PPC_MM_SLICES is not set
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
+# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_32BIT=y
CONFIG_WORD_SIZE=32
@@ -42,7 +41,6 @@
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
-CONFIG_GENERIC_LOCKBREAK=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
@@ -55,7 +53,7 @@
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
# CONFIG_PPC_UDBG_16550 is not set
-CONFIG_GENERIC_TBSYNC=y
+# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
@@ -73,6 +71,7 @@
# General setup
#
CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
@@ -105,6 +104,8 @@
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
+# CONFIG_TINY_RCU is not set
+# CONFIG_TINY_PREEMPT_RCU is not set
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
@@ -188,7 +189,6 @@
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
-CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
@@ -206,7 +206,6 @@
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
-CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
CONFIG_BLK_DEV_BSG=y
@@ -249,7 +248,7 @@
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
-CONFIG_MUTEX_SPIN_ON_OWNER=y
+# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y
#
@@ -265,6 +264,8 @@
# CONFIG_PQ2ADS is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
+# CONFIG_EMBEDDED6xx is not set
+# CONFIG_AMIGAONE is not set
# CONFIG_KVM_GUEST is not set
CONFIG_PPC_NATIVE=y
CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
@@ -310,14 +311,11 @@
CONFIG_BINFMT_MISC=m
# CONFIG_IOMMU_HELPER is not set
# CONFIG_SWIOTLB is not set
-CONFIG_HOTPLUG_CPU=y
-CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
-CONFIG_IRQ_ALL_CPUS=y
CONFIG_MAX_ACTIVE_REGIONS=32
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
@@ -336,6 +334,7 @@
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
+CONFIG_NEED_PER_CPU_KM=y
CONFIG_PPC_4K_PAGES=y
CONFIG_FORCE_MAX_ZONEORDER=11
# CONFIG_CMDLINE_BOOL is not set
@@ -472,9 +471,6 @@
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
-CONFIG_RPS=y
-CONFIG_RFS_ACCEL=y
-CONFIG_XPS=y
#
# Network testing
@@ -744,7 +740,6 @@
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
-CONFIG_MULTICORE_RAID456=y
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=y
@@ -1813,7 +1808,6 @@
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
-CONFIG_CPU_RMAP=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
# CONFIG_AVERAGE is not set
@@ -1875,7 +1869,6 @@
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
-# CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
@@ -1902,7 +1895,6 @@
CONFIG_PRINT_STACK_DEPTH=64
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
-# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_PPC_EMULATED_STATS is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
@@ -1954,7 +1946,6 @@
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
-# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
Andrey
^ permalink raw reply
* Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode
From: Jimi Xenidis @ 2011-05-31 20:26 UTC (permalink / raw)
To: Segher Boessenkool
Cc: kvm-ppc, Linuxppc-dev, Paul Mackerras, Alexander Graf, KVM list
In-Reply-To: <10cc079a31947ec4b6d39f30f2ac50f2@kernel.crashing.org>
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 least a partition switch.
>>>=20
>>> On some CPUs, if the top bit of the decrementer is 0 again when you =
re-enable
>>> the interrupt, the interrupt is lost (so it is actually =
level-triggered).
>>> The arch books talk a bit about this AFAIR.
>>=20
>> Sure, but that shouldn't happen with HDEC during the odd 50 =
instructions that it takes to enter the guest :)
>=20
> It's more like 500 insns, including some ptesync, so lots of cycles =
too.
I don't think its actually that bad.
IIRC the problem is mostly due to another interrupt of a higher priority =
that sets MSR[HV] is pending.
This could also be a synchronous instruction on or near the HSRR0 (like =
a hypercall).
Since almost everything _is_ of a higher priority, externals, VRMA-ish, =
emulation, that will occur first (or at the same time).
This extends the window where the HDEC could go +ve.
Another way around this is to check, on HV switch, if the HDEC is ever =
bigger then it should _ever_ be, but what paulus has in his code is =
actually best, although the value (10?) may be too small.
> Can another hardware thread be running at the same time?
I'll leave this question to someone else.
-JX
>=20
>=20
> Segher
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
From: Jimi Xenidis @ 2011-05-31 19:59 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Paul Mackerras, kvm-ppc, kvm
In-Reply-To: <A857E6BF-D88C-46E3-BF09-268A43B7F7CF@suse.de>
On May 31, 2011, at 8:50 AM, Alexander Graf wrote:
>=20
> On 31.05.2011, at 14:35, Paul Mackerras wrote:
>=20
>> On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
>>=20
>>> 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?
>>=20
>> Do you have a 970MP that has a usable hypervisor mode, i.e. not an
>> Apple machine? The 970s in Apple machines have the HV hard-wired to
>> 1, which means they do have a hypervisor mode but it isn't any use.
>>=20
>> If you do have such a machine, then we would have to look at some
>> details like the instruction sequence for the partition switch, and
>> make sure we don't try to use SMT4 mode. Also, I believe we will =
have
>> to flush the TLB on partition switches, since Power processors prior
>> to POWER7 didn't tag the TLB entries with the partition ID.
>>=20
>> So it should be quite feasible if you have a non-Apple machine.
>> I will check whether the 970MP machines that Terrasoft were
>> distributing would be suitable. We have one of them in the lab.
>=20
> That's the one I was thinking of and yes, I have one available. That =
way I could test 99% of your code, you don't have to release hardware, =
and everyone's happy :).
>=20
Be aware that on 970s (off the top of my head):
- did not have the LPCR architected so you'll have to access individual =
HID registers.
- old style RMOR is supported, not VRMA
- no MEDiated interrupt
=20
-jx
>=20
> Alex
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PCI EDAC on MPC85xx
From: Dmitry Eremin-Solenikov @ 2011-05-31 19:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <7373D079-743D-4D49-BDC6-2BEAF14C43DF@kernel.crashing.org>
On 5/31/11, Kumar Gala <galak@kernel.crashing.org> 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 Likely has
>> come with a patch to create platform devices (of_platform at that time),
>> for device_nodes which have "compatible" properties
>> (http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981).
>>
>> The patch was not applied at that time and the problem still arises at
>> 3.0-rc1. Should the patch in question be applied, or is there any new
>> solution?
>> Current version of that patch which I have in my tree is attached
>> to this mail (no original signoff by Grant).
>>
>> --
>> With best wishes
>> Dmitry
>>
>> <0001-of-device-Register-children-with-a-compatible-value-.patch>
>
> I think the desired solution here was to create a new node in the fsl_pci
> code that the edac code would bind against.
Sorry, got mistaken then by Grant=B4s patch. Will provide an update on this=
topic
soon.
--=20
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc: document the FSL MPIC message register binding
From: Scott Wood @ 2011-05-31 19:23 UTC (permalink / raw)
To: Meador Inge
Cc: devicetree-discuss, Hollis Blanchard, openmcapi-dev, linuxppc-dev
In-Reply-To: <1306869543-18812-2-git-send-email-meador_inge@mentor.com>
On Tue, 31 May 2011 14:19:02 -0500
Meador Inge <meador_inge@mentor.com> 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 <meador_inge@mentor.com>
> Cc: Hollis Blanchard <hollis_blanchard@mentor.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Scott Wood <scottwood@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++++++++
> 1 files changed, 62 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
ACK
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc: document the FSL MPIC message register binding
From: Meador Inge @ 2011-05-31 19:19 UTC (permalink / raw)
To: Scott Wood
Cc: openmcapi-dev, Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110526150643.3e01f9a6@schlenkerla.am.freescale.net>
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 <prop-encoded-array>. The length shall be equal to
>> > + the number of bits set in the 'msg-receive-mask' property value.
> Oh, just noticed -- mismatch between msg-receive-mask here...
>
>> > +
>> > +Optional properties:
>> > +
>> > + - mpic-msgr-receive-mask: Specifies what registers in the containing block
>> > + are allowed to receive interrupts. The value is a bit mask where a set
>> > + bit at bit 'n' indicates that message register 'n' can receive interrupts.
>> > + The type shall be <prop-encoded-array>. If not present, then all of
>> > + the message registers in the block are available.
> ...and mpic-msgr-receive-mask here.
>
> Might want to just say "equal to the number of registers that are
> available for receiving interrupts", to more clearly apply to the case where
> mpic-msgr-receive-mask is missing.
>
Thanks; fixed.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
^ permalink raw reply
* [PATCH v3 2/2] powerpc: add support for MPIC message register API
From: Meador Inge @ 2011-05-31 19:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: openmcapi-dev, devicetree-discuss, Hollis Blanchard
In-Reply-To: <1306869543-18812-1-git-send-email-meador_inge@mentor.com>
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
device tree. A separate commit contains a binding for the message register
nodes.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Hollis Blanchard <hollis_blanchard@mentor.com>
---
arch/powerpc/include/asm/mpic_msgr.h | 35 +++++
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/sysdev/Makefile | 3 +-
arch/powerpc/sysdev/mpic_msgr.c | 279 ++++++++++++++++++++++++++++++++++
4 files changed, 324 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpic_msgr.h
create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
diff --git a/arch/powerpc/include/asm/mpic_msgr.h b/arch/powerpc/include/asm/mpic_msgr.h
new file mode 100644
index 0000000..370dcb4
--- /dev/null
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#ifndef _ASM_MPIC_MSGR_H
+#define _ASM_MPIC_MSGR_H
+
+#include <linux/types.h>
+
+struct mpic_msgr {
+ u32 __iomem *addr;
+ u32 __iomem *mer;
+ u32 __iomem *msr;
+ int irq;
+ atomic_t in_use;
+ int num;
+};
+
+extern struct mpic_msgr* mpic_msgr_get(unsigned int reg_num);
+extern void mpic_msgr_put(struct mpic_msgr* msgr);
+extern void mpic_msgr_enable(struct mpic_msgr *msgr);
+extern void mpic_msgr_disable(struct mpic_msgr *msgr);
+extern void mpic_msgr_write(struct mpic_msgr *msgr, u32 message);
+extern u32 mpic_msgr_read(struct mpic_msgr *msgr);
+extern void mpic_msgr_clear(struct mpic_msgr *msgr);
+extern void mpic_msgr_set_destination(struct mpic_msgr *msgr, u32 cpu_num);
+extern int mpic_msgr_get_irq(struct mpic_msgr *msgr);
+
+#endif
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index f7b0772..4d65593 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -78,6 +78,14 @@ config MPIC_WEIRD
bool
default n
+config MPIC_MSGR
+ bool "MPIC message register support"
+ depends on MPIC
+ default n
+ help
+ Enables support for the MPIC message registers. These
+ registers are used for inter-processor communication.
+
config PPC_I8259
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 1e0c933..6d40185 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -3,7 +3,8 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
-obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+mpic-msgr-obj-$(CONFIG_MPIC_MSGR) += mpic_msgr.o
+obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
new file mode 100644
index 0000000..bfa0612
--- /dev/null
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * Some ideas based on un-pushed work done by Vivek Mahajan, Jason Jin, and
+ * Mingkai Hu from Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/list.h>
+#include <linux/of_platform.h>
+#include <linux/errno.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include <asm/mpic_msgr.h>
+
+#define MPIC_MSGR_REGISTERS_PER_BLOCK 4
+#define MSGR_INUSE 0
+#define MSGR_FREE 1
+
+/* Internal structure used *only* for IO mapping register blocks. */
+struct mpic_msgr_block {
+ struct msgr {
+ u32 msgr;
+ u8 res[12];
+ } msgrs[MPIC_MSGR_REGISTERS_PER_BLOCK];
+ u8 res0[192];
+ u32 mer;
+ u8 res1[12];
+ u32 msr;
+};
+
+static struct mpic_msgr **mpic_msgrs = 0;
+static unsigned int mpic_msgr_count = 0;
+
+struct mpic_msgr* mpic_msgr_get(unsigned int reg_num)
+{
+ struct mpic_msgr* msgr;
+
+ if (reg_num >= mpic_msgr_count)
+ return ERR_PTR(-ENODEV);
+
+ msgr = mpic_msgrs[reg_num];
+
+ if (atomic_cmpxchg(&msgr->in_use, MSGR_FREE, MSGR_INUSE) == MSGR_FREE)
+ return msgr;
+
+ return ERR_PTR(-EBUSY);
+}
+EXPORT_SYMBOL(mpic_msgr_get);
+
+void mpic_msgr_put(struct mpic_msgr* msgr)
+{
+ atomic_set(&msgr->in_use, MSGR_FREE);
+}
+EXPORT_SYMBOL(mpic_msgr_put);
+
+void mpic_msgr_enable(struct mpic_msgr *msgr)
+{
+ out_be32(msgr->mer, in_be32(msgr->mer) | (1 << msgr->num));
+}
+EXPORT_SYMBOL(mpic_msgr_enable);
+
+void mpic_msgr_disable(struct mpic_msgr *msgr)
+{
+ out_be32(msgr->mer, in_be32(msgr->mer) & ~(1 << msgr->num));
+}
+EXPORT_SYMBOL(mpic_msgr_disable);
+
+void mpic_msgr_write(struct mpic_msgr *msgr, u32 message)
+{
+ out_be32(msgr->addr, message);
+}
+EXPORT_SYMBOL(mpic_msgr_write);
+
+u32 mpic_msgr_read(struct mpic_msgr *msgr)
+{
+ return in_be32(msgr->addr);
+}
+EXPORT_SYMBOL(mpic_msgr_read);
+
+void mpic_msgr_clear(struct mpic_msgr *msgr)
+{
+ (void) mpic_msgr_read(msgr);
+}
+EXPORT_SYMBOL(mpic_msgr_clear);
+
+void mpic_msgr_set_destination(struct mpic_msgr *msgr, u32 cpu_num)
+{
+ out_be32(msgr->addr, 1 << cpu_num);
+}
+EXPORT_SYMBOL(mpic_msgr_set_destination);
+
+int mpic_msgr_get_irq(struct mpic_msgr *msgr)
+{
+ return msgr->irq;
+}
+EXPORT_SYMBOL(mpic_msgr_get_irq);
+
+/* The following three functions are used to compute the order and number of
+ * the message register blocks. They are clearly very inefficent. However,
+ * they are called *only* a few times during device initialization.
+ */
+static unsigned int mpic_msgr_number_of_blocks(void)
+{
+ unsigned int count;
+ struct device_node *aliases;
+
+ count = 0;
+ aliases = of_find_node_by_name(NULL, "aliases");
+
+ if (aliases) {
+ char buf[32];
+
+ for (;;) {
+ snprintf(buf, sizeof(buf), "mpic-msgr-block%d", count);
+ if (!of_find_property(aliases, buf, NULL))
+ break;
+
+ count += 1;
+ }
+ }
+
+ return count;
+}
+
+static unsigned int mpic_msgr_number_of_registers(void)
+{
+ return mpic_msgr_number_of_blocks() * MPIC_MSGR_REGISTERS_PER_BLOCK;
+}
+
+static int mpic_msgr_block_number(struct device_node *node)
+{
+ struct device_node *aliases;
+ unsigned int index, number_of_blocks;
+ char buf[64];
+
+ number_of_blocks = mpic_msgr_number_of_blocks();
+ aliases = of_find_node_by_name(NULL, "aliases");
+ if (!aliases)
+ return -1;
+
+ for (index = 0; index < number_of_blocks; ++index) {
+ struct property *prop;
+
+ snprintf(buf, sizeof(buf), "mpic-msgr-block%d", index);
+ prop = of_find_property(aliases, buf, NULL);
+ if (node == of_find_node_by_path(prop->value))
+ break;
+ }
+
+ return index == number_of_blocks ? -1 : index;
+}
+
+/* The probe function for a single message register block.
+ */
+static __devinit int mpic_msgr_probe(struct platform_device *dev)
+{
+ struct mpic_msgr_block __iomem *msgr_block;
+ int block_number;
+ struct resource rsrc;
+ unsigned int i;
+ unsigned int irq_index;
+ struct device_node *np = dev->dev.of_node;
+ unsigned int receive_mask;
+ const unsigned int *prop;
+
+ if (!np) {
+ dev_err(&dev->dev, "Device OF-Node is NULL");
+ return -EFAULT;
+ }
+
+ /* Allocate the message register array upon the first device
+ * registered.
+ */
+ if (!mpic_msgrs) {
+ mpic_msgr_count = mpic_msgr_number_of_registers();
+ dev_info(&dev->dev, "Found %d message registers\n", mpic_msgr_count);
+
+ mpic_msgrs = kzalloc(sizeof(struct mpic_msgr) * mpic_msgr_count,
+ GFP_KERNEL);
+ if (!mpic_msgrs) {
+ dev_err(&dev->dev, "No memory for message register blocks\n");
+ return -ENOMEM;
+ }
+ }
+ dev_info(&dev->dev, "Of-device full name %s\n", np->full_name);
+
+ /* IO map the message register block. */
+ of_address_to_resource(np, 0, &rsrc);
+ msgr_block = ioremap(rsrc.start, rsrc.end - rsrc.start);
+ if (!msgr_block) {
+ dev_err(&dev->dev, "Failed to iomap MPIC message registers");
+ return -EFAULT;
+ }
+
+ /* Ensure the block has a defined order. */
+ block_number = mpic_msgr_block_number(np);
+ if (block_number < 0) {
+ dev_err(&dev->dev, "Failed to find message register block alias\n");
+ return -ENODEV;
+ }
+ dev_info(&dev->dev, "Setting up message register block %d\n", block_number);
+
+ /* Grab the receive mask which specifies what registers can receive
+ * interrupts.
+ */
+ prop = of_get_property(np, "mpic-msgr-receive-mask", NULL);
+ receive_mask = (prop) ? *prop : 0xF;
+
+ /* Build up the appropriate message register data structures. */
+ for (i = 0, irq_index = 0; i < MPIC_MSGR_REGISTERS_PER_BLOCK; ++i) {
+ struct mpic_msgr *msgr;
+ unsigned int reg_number;
+
+ msgr = kzalloc(sizeof(struct mpic_msgr), GFP_KERNEL);
+ if (!msgr) {
+ dev_err(&dev->dev, "No memory for message register\n");
+ return -ENOMEM;
+ }
+
+ reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + i;
+ msgr->addr = &msgr_block->msgrs[i].msgr;
+ msgr->mer = &msgr_block->mer;
+ msgr->msr = &msgr_block->msr;
+ atomic_set(&msgr->in_use, MSGR_FREE);
+ msgr->num = reg_number;
+
+ if (receive_mask & (1 << i)) {
+ struct resource irq;
+
+ if (of_irq_to_resource(np, irq_index, &irq) == NO_IRQ) {
+ dev_err(&dev->dev, "Missing interrupt specifier");
+ kfree(msgr);
+ return -EFAULT;
+ }
+ msgr->irq = irq.start;
+ irq_index += 1;
+ } else {
+ msgr->irq = NO_IRQ;
+ }
+
+ mpic_msgrs[reg_number] = msgr;
+ mpic_msgr_disable(msgr);
+ dev_info(&dev->dev, "Register %d initialized: irq %d\n",
+ msgr->num, msgr->irq);
+
+ }
+
+ return 0;
+}
+
+static const struct of_device_id mpic_msgr_ids[] = {
+ {
+ .compatible = "fsl,mpic-v3.1-msgr",
+ .data = NULL,
+ },
+ {}
+};
+
+static struct platform_driver mpic_msgr_driver = {
+ .driver = {
+ .name = "mpic-msgr",
+ .owner = THIS_MODULE,
+ .of_match_table = mpic_msgr_ids,
+ },
+ .probe = mpic_msgr_probe,
+};
+
+static __init int mpic_msgr_init(void)
+{
+ return platform_driver_register(&mpic_msgr_driver);
+}
+subsys_initcall(mpic_msgr_init);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 1/2] powerpc: document the FSL MPIC message register binding
From: Meador Inge @ 2011-05-31 19:19 UTC (permalink / raw)
To: linuxppc-dev
Cc: devicetree-discuss, Hollis Blanchard, Scott Wood, openmcapi-dev
In-Reply-To: <1306869543-18812-1-git-send-email-meador_inge@mentor.com>
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 <meador_inge@mentor.com>
Cc: Hollis Blanchard <hollis_blanchard@mentor.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
new file mode 100644
index 0000000..e1c19b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
@@ -0,0 +1,62 @@
+* FSL MPIC Message Registers
+
+This binding specifies what properties must be available in the device tree
+representation of the message register blocks found in some FSL MPIC
+implementations.
+
+Required properties:
+
+ - compatible: Specifies the compatibility list for the message register
+ block. The type shall be <string> and the value shall be of the form
+ "fsl,mpic-v<version>-msgr", where <version> is the version number of
+ the MPIC containing the message registers.
+
+ - reg: Specifies the base physical address(s) and size(s) of the
+ message register block's addressable register space. The type shall be
+ <prop-encoded-array>.
+
+ - interrupts: Specifies a list of interrupt source and level-sense pairs.
+ The type shall be <prop-encoded-array>. The length shall be equal to
+ the number of registers that are available for receiving interrupts.
+
+Optional properties:
+
+ - mpic-msgr-receive-mask: Specifies what registers in the containing block
+ are allowed to receive interrupts. The value is a bit mask where a set
+ bit at bit 'n' indicates that message register 'n' can receive interrupts.
+ The type shall be <prop-encoded-array>. If not present, then all of
+ the message registers in the block are available.
+
+Aliases:
+
+ An alias should be created for every message register block. They are not
+ required, though. However, a particular implementation of this binding
+ may require aliases to be present. Aliases are of the form
+ 'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
+ Numbers shall start at 0.
+
+Example:
+
+ aliases {
+ mpic-msgr-block0 = &mpic_msgr_block0;
+ mpic-msgr-block1 = &mpic_msgr_block1;
+ };
+
+ mpic_msgr_block0: mpic-msgr-block@41400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x41400 0x200>;
+ // Message registers 0 and 2 in this block can receive interrupts on
+ // sources 0xb0 and 0xb2, respectively.
+ interrupts = <0xb0 2 0xb2 2>;
+ mpic-msgr-receive-mask = <0x5>;
+ };
+
+ mpic_msgr_block1: mpic-msgr-block@42400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x42400 0x200>;
+ // Message registers 0 and 2 in this block can receive interrupts on
+ // sources 0xb4 and 0xb6, respectively.
+ interrupts = <0xb4 2 0xb6 2>;
+ mpic-msgr-receive-mask = <0x5>;
+ };
+
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 0/2] powerpc: define and implement MPIC message register support
From: Meador Inge @ 2011-05-31 19:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: openmcapi-dev, devicetree-discuss, Hollis Blanchard
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 OpenMCAPI shared
memory driver to send notifications between cores.
* v3 - Clarified a point in the binding concerning the length of the
'interrupts' property. Pointed out by Scott Wood.
* v2 - Incorporate feedback from Scott Wood
* Make binding less implementation specific.
* Add 'mpic-' prefix to message register node properties and aliases.
* Remove 'interrupt-parent' from binding.
* Fixed some example bugs with receive masks.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
Cc: Hollis Blanchard <hollis_blanchard@mentor.com>
Meador Inge (2):
powerpc: document the FSL MPIC message register binding
powerpc: add support for MPIC message register API
.../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 +++++
arch/powerpc/include/asm/mpic_msgr.h | 35 +++
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/sysdev/Makefile | 3 +-
arch/powerpc/sysdev/mpic_msgr.c | 279 ++++++++++++++++++++
5 files changed, 386 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
create mode 100644 arch/powerpc/include/asm/mpic_msgr.h
create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
^ permalink raw reply
* Re: PCI EDAC on MPC85xx
From: Grant Likely @ 2011-05-31 19:12 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110531131737.GA29164@doriath.ww600.siemens.net>
On Tue, May 31, 2011 at 7:17 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> 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 create platform devices (of_platform at that time),
> for device_nodes which have "compatible" properties
> (http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981).
>
> The patch was not applied at that time and the problem still arises at
> 3.0-rc1. Should the patch in question be applied, or is there any new
> solution?
> Current version of that patch which I have in my tree is attached
> to this mail (no original signoff by Grant).
Hi Dmitry,
I've since looked at the problem more, and I've been working on
refactoring both of_platform_bus_probe(), and creating a new function,
of_platform_populate(), which implements the symantics that I think
are needed for your use case. The work isn't done yet, but it has
gone out for at least one round of review, and I hope to get it into
the 3.1 merge window.
g.
^ permalink raw reply
* Re: PCI EDAC on MPC85xx
From: Kumar Gala @ 2011-05-31 18:41 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110531131737.GA29164@doriath.ww600.siemens.net>
On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote:
> Hello,
>=20
> 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 "compatible" properties
> (http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981).
>=20
> The patch was not applied at that time and the problem still arises at
> 3.0-rc1. Should the patch in question be applied, or is there any new
> solution?
> Current version of that patch which I have in my tree is attached
> to this mail (no original signoff by Grant).
>=20
> --=20
> With best wishes
> Dmitry
>=20
> <0001-of-device-Register-children-with-a-compatible-value-.patch>
I think the desired solution here was to create a new node in the =
fsl_pci code that the edac code would bind against.
- k=
^ permalink raw reply
* Re: [PATCH] ssb: pci: implement serdes workaround
From: Andreas Schwab @ 2011-05-31 17:32 UTC (permalink / raw)
To: Larry Finger
Cc: Rafał Miłecki, Michael Büsch,
public-b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linuxppc-dev,
John W. Linville, public-linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m239jukddk.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
>> On 05/31/2011 10:54 AM, Andreas Schwab wrote:
>>> Larry Finger<Larry.Finger@lwfinger.net> 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+0x4c/0x54 [ssb]
>> [c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]
>
> Which exactly is what ssb_pcicore_polarity_workaround is doing.
0000022c <ssb_pcicore_serdes_workaround>:
22c: 94 21 ff e0 stwu r1,-32(r1)
230: 7c 08 02 a6 mflr r0
234: 38 80 02 04 li r4,516
238: 90 01 00 24 stw r0,36(r1)
23c: bf a1 00 14 stmw r29,20(r1)
240: 7c 7f 1b 78 mr r31,r3
244: 4b ff fd bd bl 0 <ssb_pcie_read>
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] ssb: pci: implement serdes workaround
From: Andreas Schwab @ 2011-05-31 17:07 UTC (permalink / raw)
To: Larry Finger
Cc: Rafał Miłecki, Michael Büsch,
public-b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linuxppc-dev,
John W. Linville, public-linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4DE51487.1000808@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 05/31/2011 10:54 AM, Andreas Schwab wrote:
>> Larry Finger<Larry.Finger@lwfinger.net> 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+0x4c/0x54 [ssb]
> [c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]
Which exactly is what ssb_pcicore_polarity_workaround is doing.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] ssb: pci: implement serdes workaround
From: Larry Finger @ 2011-05-31 16:17 UTC (permalink / raw)
To: Andreas Schwab
Cc: Rafał Miłecki, Michael Büsch,
public-b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linuxppc-dev,
John W. Linville, public-linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m3wrh6hnmn.fsf@linux-m68k.org>
On 05/31/2011 10:54 AM, Andreas Schwab wrote:
> Larry Finger<Larry.Finger@lwfinger.net> 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+0x4c/0x54 [ssb]
[c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]
Larry
^ permalink raw reply
* Re: Mapping an executable page
From: McClintock Matthew-B29882 @ 2011-05-31 16:01 UTC (permalink / raw)
To: Thomas De Schampheleire; +Cc: linuxppc-dev
In-Reply-To: <BANLkTikd3ZtNRcz=ZWSsDL9OoeV0Wndy1g@mail.gmail.com>
On Fri, May 27, 2011 at 8:25 AM, Thomas De Schampheleire
<patrickdepinguin+linuxppc@gmail.com> 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/sysdev/mpic.c?
kexec on 85xx uses this to reset other cores the the hold off spin
loop.
-M=
^ permalink raw reply
* Re: [PATCH] ssb: pci: implement serdes workaround
From: Andreas Schwab @ 2011-05-31 15:54 UTC (permalink / raw)
To: Larry Finger
Cc: Rafał Miłecki, Michael Büsch,
public-b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linuxppc-dev,
John W. Linville, public-linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4DE505C6.8020601@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox