* 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
* Using the BDI3k with the P4040
From: Mark Pearson @ 2011-05-31 15:47 UTC (permalink / raw)
To: linuxppc-dev
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 really interested but I
was mainly interested if anybody had tried this combo before and if they
knew of any gotcha's, example BDI configs etc.
At the moment suspecting HW issue around the reset but of course the HW
team would like us to check that we're not doing dumb things from the
SW/BDI side of things too.
Thanks in advance
Mark Pearson
^ permalink raw reply
* Re: [RFC][PATCH] Kexec support for PPC440x
From: Sebastian Andrzej Siewior @ 2011-05-31 15:15 UTC (permalink / raw)
To: Suzuki Poulose; +Cc: kexec@lists.infradead.org, linux ppc dev, lkml
In-Reply-To: <4DE345B0.8020505@in.ibm.com>
Suzuki Poulose wrote:
> Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
> ===================================================================
> --- /dev/null
> +++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
....
> + *
> + */
> + bl nxtins /* Find our address */
> +nxtins: mflr r5 /* Make it accessible */
Please don't mix labels and instructions.
> + tlbsx r23,0,r5 /* Find entry we are in */
using tabs instead of spaces would make it look nice. Please also separate
the arguments of the instruction i.e.
tlbsx r23, 0, r5
> Index: powerpc/arch/powerpc/kernel/misc_32.S
> ===================================================================
> --- powerpc.orig/arch/powerpc/kernel/misc_32.S
> +++ powerpc/arch/powerpc/kernel/misc_32.S
> @@ -736,6 +736,28 @@ relocate_new_kernel:
> mr r5, r31
>
> li r0, 0
> +#elif defined(CONFIG_44x) && !defined(CONFIG_47x)
> +
> + mr r29, r3
> + mr r30, r4
> + mr r31, r5
> +
> +#include "44x_kexec_mapping.S"
The way you setup the 1:1 mapping should be close to what you are doing on
kernel entry. Isn't it possible to include the file here and in the entry
code?
Sebastian
^ 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