* Re: [v3 PATCH 1/1] powerpc/4xx: enable and fix pcie gen1/gen2 on the 460sx
From: Tony Breeds @ 2011-07-21 0:59 UTC (permalink / raw)
To: Ayman Elkhashab
Cc: Ayman El-Khashab, Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1311166949-2543-2-git-send-email-aymane@elkhashab.com>
On Wed, Jul 20, 2011 at 08:02:29AM -0500, Ayman Elkhashab wrote:
> From: Ayman El-Khashab <ayman@elkhashab.com>
>
> Adds a register to the config space for the 460sx. Changes the vc0
> detect to a pll detect. maps configuration space to test the link
> status. changes the setup to enable gen2 devices to operate at gen2
> speeds. fixes mapping that was not correct for the 460sx. added
> bit definitions for the OMRxMSKL registers. Removed reserved bit
> that was set incorrectly in the OMR2MSKL register.
FWIW Looks good to me.
Yours Tony
^ permalink raw reply
* Fwd: perf PPC: kernel panic with callchains and context switch events
From: David Ahern @ 2011-07-20 22:13 UTC (permalink / raw)
To: linuxppc-dev
[suggestion to try this mailing list as well]
-------- Original Message --------
Subject: perf PPC: kernel panic with callchains and context switch events
Date: Wed, 20 Jul 2011 15:57:51 -0600
From: David Ahern <dsahern@gmail.com>
To: Anton Blanchard <anton@samba.org>, Paul Mackerras
<paulus@samba.org>, linux-perf-users@vger.kernel.org, LKML
<linux-kernel@vger.kernel.org>
I am hoping someone familiar with PPC can help understand a panic that
is generated when capturing callchains with context switch events.
Call trace is below. The short of it is that walking the callchain
generates a page fault. To handle the page fault the mmap_sem is needed,
but it is currently held by setup_arg_pages. setup_arg_pages calls
shift_arg_pages with the mmap_sem held. shift_arg_pages then calls
move_page_tables which has a cond_resched at the top of its for loop. If
the cond_resched() is removed from move_page_tables everything works
beautifully - no panics.
So, the question: is it normal for walking the stack to trigger a page
fault on PPC? The panic is not seen on x86 based systems.
[<b0180e00>]rb_erase+0x1b4/0x3e8
[<b00430f4>]__dequeue_entity+0x50/0xe8
[<b0043304>]set_next_entity+0x178/0x1bc
[<b0043440>]pick_next_task_fair+0xb0/0x118
[<b02ada80>]schedule+0x500/0x614
[<b02afaa8>]rwsem_down_failed_common+0xf0/0x264
[<b02afca0>]rwsem_down_read_failed+0x34/0x54
[<b02aed4c>]down_read+0x3c/0x54
[<b0023b58>]do_page_fault+0x114/0x5e8
[<b001e350>]handle_page_fault+0xc/0x80
[<b0022dec>]perf_callchain+0x224/0x31c
[<b009ba70>]perf_prepare_sample+0x240/0x2fc
[<b009d760>]__perf_event_overflow+0x280/0x398
[<b009d914>]perf_swevent_overflow+0x9c/0x10c
[<b009db54>]perf_swevent_ctx_event+0x1d0/0x230
[<b009dc38>]do_perf_sw_event+0x84/0xe4
[<b009dde8>]perf_sw_event_context_switch+0x150/0x1b4
[<b009de90>]perf_event_task_sched_out+0x44/0x2d4
[<b02ad840>]schedule+0x2c0/0x614
[<b0047dc0>]__cond_resched+0x34/0x90
[<b02adcc8>]_cond_resched+0x4c/0x68
[<b00bccf8>]move_page_tables+0xb0/0x418
[<b00d7ee0>]setup_arg_pages+0x184/0x2a0
[<b0110914>]load_elf_binary+0x394/0x1208
[<b00d6e28>]search_binary_handler+0xe0/0x2c4
[<b00d834c>]do_execve+0x1bc/0x268
[<b0015394>]sys_execve+0x84/0xc8
[<b001df10>]ret_from_syscall+0x0/0x3c
Thanks,
David
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Peter Zijlstra @ 2011-07-20 16:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mahesh, linux-kernel, Anton Blanchard, mingo, linuxppc-dev
In-Reply-To: <CA+55aFxpH9-4rkH6CRXbjFCQMGNYGRMKgdgHUEthefQPumFKVg@mail.gmail.com>
On Wed, 2011-07-20 at 09:04 -0700, Linus Torvalds wrote:
> On Wed, Jul 20, 2011 at 7:58 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> =
wrote:
> >
> > Right, so we can either merge my scary patches now and have 3.0 boot on
> > 16+ node machines (and risk breaking something), or delay them until
> > 3.0.1 and have 16+ node machines suffer a little.
>=20
> So how much impact does your scary patch have on machines that don't
> have multiple nodes? If it's a "the code isn't even called by normal
> machines" kind of setup, I don't think I care a lot.
Hmm, it does get called, but it looks relatively straight forward to
make it so that it doesn't. Let me try that.
Yes, the below works nicely (on top of the previous two).
Built and boot tested on a single-node and multi-node x86_64.
---
Subject: sched: Avoid creating superfluous domains
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Wed Jul 20 18:34:30 CEST 2011
When creating sched_domains, stop when we've covered the entire target
span instead of continuing to create domains, only to later find
they're redundant and throw them away again.
This avoids single node systems from touching funny NUMA sched_domain
creation code.
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/kernel/sched.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -7436,6 +7436,8 @@ static int build_sched_domains(const str
sd =3D build_sched_domain(tl, &d, cpu_map, attr, sd, i);
if (tl->flags & SDTL_OVERLAP || sched_feat(FORCE_SD_OVERLAP))
sd->flags |=3D SD_OVERLAP;
+ if (cpumask_equal(cpu_map, sched_domain_span(sd)))
+ break;
}
=20
while (sd->child)
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Ingo Molnar @ 2011-07-20 16:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, mahesh, linux-kernel, Anton Blanchard,
linuxppc-dev
In-Reply-To: <CA+55aFxpH9-4rkH6CRXbjFCQMGNYGRMKgdgHUEthefQPumFKVg@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Jul 20, 2011 at 7:58 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > Right, so we can either merge my scary patches now and have 3.0
> > boot on 16+ node machines (and risk breaking something), or delay
> > them until 3.0.1 and have 16+ node machines suffer a little.
>
> So how much impact does your scary patch have on machines that
> don't have multiple nodes? If it's a "the code isn't even called by
> normal machines" kind of setup, I don't think I care a lot.
NUMA systems will trigger the new code - not just 'weird NUMA
systems' - but i still think we could try the patches, the code looks
straightforward and i booted them on NUMA systems and it all seems
fine so far.
Anyway, i'll push the new sched/urgent branch out in a few minutes
and then you'll see the full patches in the commit notifications.
Thanks,
Ingo
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Linus Torvalds @ 2011-07-20 16:04 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: mahesh, linux-kernel, Anton Blanchard, mingo, linuxppc-dev
In-Reply-To: <1311173910.5345.94.camel@twins>
On Wed, Jul 20, 2011 at 7:58 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> Right, so we can either merge my scary patches now and have 3.0 boot on
> 16+ node machines (and risk breaking something), or delay them until
> 3.0.1 and have 16+ node machines suffer a little.
So how much impact does your scary patch have on machines that don't
have multiple nodes? If it's a "the code isn't even called by normal
machines" kind of setup, I don't think I care a lot.
Linus
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Peter Zijlstra @ 2011-07-20 14:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mahesh, linux-kernel, Anton Blanchard, mingo, linuxppc-dev
In-Reply-To: <CA+55aFxzaaMj8OUaust90c_hYKzg8NpRfmX4SzJ9SMwXzg5ocA@mail.gmail.com>
On Wed, 2011-07-20 at 07:40 -0700, Linus Torvalds wrote:
> On Wed, Jul 20, 2011 at 5:14 AM, Anton Blanchard <anton@samba.org> wrote:
> >
> >> So with that fix the patch makes the machine happy again?
> >
> > Yes, the machine looks fine with the patches applied. Thanks!
>=20
> Ok, so what's the situation for 3.0 (I'm waiting for some RCU
> resolution now)? Anton's patch may be small, but that's just the tiny
> fixup patch to Peter's much scarier one ;)
Right, so we can either merge my scary patches now and have 3.0 boot on
16+ node machines (and risk breaking something), or delay them until
3.0.1 and have 16+ node machines suffer a little.
The alternative quick hack is simply to disable the node domain, but
that'll be detrimental to regular machines in that the top domain used
to have NODE sd_flags will now have ALL_NODE sd_flags which are much
less aggressive.
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Darren Hart @ 2011-07-20 14:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tony.luck, Peter Zijlstra, Shan Hai, Peter Zijlstra, linux-kernel,
cmetcalf, dhowells, paulus, tglx, walken, linuxppc-dev, akpm
In-Reply-To: <1311049762.25044.392.camel@pasglop>
Obviously no objection from the futex side of things, looks good. Couple
nits on the function comment:
On 07/18/2011 09:29 PM, Benjamin Herrenschmidt wrote:
...
> -/**
> +/*
> + * fixup_user_fault() - manually resolve a user page fault
s/ fault/ fault/
> + * @tsk: the task_struct to use for page fault accounting, or
> + * NULL if faults are not to be recorded.
> + * @mm: mm_struct of target mm
> + * @address: user address
> + * @fault_flags:flags to pass down to handle_mm_fault()
> + *
> + * This is meant to be called in the specific scenario where for
> + * locking reasons we try to access user memory in atomic context
> + * (within a pagefault_disable() section), this returns -EFAULT,
> + * and we want to resolve the user fault before trying again.
> + *
> + * Typically this is meant to be used by the futex code.
> + *
> + * The main difference with get_user_pages() is that this function
> + * will unconditionally call handle_mm_fault() which will in turn
> + * perform all the necessary SW fixup of the dirty and young bits
> + * in the PTE, while handle_mm_fault() only guarantees to update
> + * these in the struct page.
> + *
> + * This is important for some architectures where those bits also
> + * gate the access permission to the page because their are
s/their/they/
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Linus Torvalds @ 2011-07-20 14:40 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Peter Zijlstra, mahesh, linux-kernel, mingo, linuxppc-dev
In-Reply-To: <20110720221420.153b0830@kryten>
On Wed, Jul 20, 2011 at 5:14 AM, Anton Blanchard <anton@samba.org> wrote:
>
>> So with that fix the patch makes the machine happy again?
>
> Yes, the machine looks fine with the patches applied. Thanks!
Ok, so what's the situation for 3.0 (I'm waiting for some RCU
resolution now)? Anton's patch may be small, but that's just the tiny
fixup patch to Peter's much scarier one ;)
Linus
^ permalink raw reply
* Re: [PATCH] powerpc: Fix build dependencies for epapr.c which needs libfdt.h
From: David Gibson @ 2011-07-20 13:49 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1311092564-10102-1-git-send-email-msm@freescale.com>
On Tue, Jul 19, 2011 at 11:22:44AM -0500, Matthew McClintock wrote:
> Currently, the build can (very rarely) fail to build because libfdt.h has
> not been created or is in the process of being copied.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
Looks sane to me.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2011-07-20 13:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110712204156.GD4203@zod.rchland.ibm.com>
On Tue, Jul 12, 2011 at 4:41 PM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wr=
ote:
> Hi Ben,
>
> A few fixes from Tony/Dave, a DTS update from Stefan, and a MAINTAINERS
> update.
>
> josh
>
> The following changes since commit af9719c3062dfe216a0c3de3fa52be6d22b445=
6c:
>
> =A0powerpc: Use -mtraceback=3Dno (2011-07-01 13:49:27 +1000)
>
> are available in the git repository at:
> =A0ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.g=
it next
Ben, ping?
josh
^ permalink raw reply
* [v3 PATCH 1/1] powerpc/4xx: enable and fix pcie gen1/gen2 on the 460sx
From: Ayman Elkhashab @ 2011-07-20 13:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Breeds, linuxppc-dev,
linux-kernel
Cc: Ayman El-Khashab
In-Reply-To: <1311166949-2543-1-git-send-email-aymane@elkhashab.com>
From: Ayman El-Khashab <ayman@elkhashab.com>
Adds a register to the config space for the 460sx. Changes the vc0
detect to a pll detect. maps configuration space to test the link
status. changes the setup to enable gen2 devices to operate at gen2
speeds. fixes mapping that was not correct for the 460sx. added
bit definitions for the OMRxMSKL registers. Removed reserved bit
that was set incorrectly in the OMR2MSKL register.
tested on the 460sx eiger and custom board
Signed-off-by: Ayman El-Khashab <ayman@elkhashab.com>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 89 ++++++++++++++++++++++++++++++-------
arch/powerpc/sysdev/ppc4xx_pci.h | 12 +++++
2 files changed, 84 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index ad330fe..eeeeb12 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1092,6 +1092,10 @@ static int __init ppc460sx_pciex_core_init(struct device_node *np)
mtdcri(SDR0, PESDR1_460SX_HSSSLEW, 0xFFFF0000);
mtdcri(SDR0, PESDR2_460SX_HSSSLEW, 0xFFFF0000);
+ /* Set HSS PRBS enabled */
+ mtdcri(SDR0, PESDR0_460SX_HSSCTLSET, 0x00001130);
+ mtdcri(SDR0, PESDR2_460SX_HSSCTLSET, 0x00001130);
+
udelay(100);
/* De-assert PLLRESET */
@@ -1132,9 +1136,6 @@ static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
0, 0x01000000);
- /*Gen-1*/
- mtdcri(SDR0, port->sdr_base + PESDRn_460SX_RCEI, 0x08000000);
-
dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET,
(PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL),
PESDRx_RCSSET_RSTPYN);
@@ -1148,14 +1149,42 @@ static int ppc460sx_pciex_init_utl(struct ppc4xx_pciex_port *port)
{
/* Max 128 Bytes */
out_be32 (port->utl_base + PEUTL_PBBSZ, 0x00000000);
+ /* Assert VRB and TXE - per datasheet turn off addr validation */
+ out_be32(port->utl_base + PEUTL_PCTL, 0x80800000);
return 0;
}
+static void __init ppc460sx_pciex_check_link(struct ppc4xx_pciex_port *port)
+{
+ void __iomem *mbase;
+ int attempt = 50;
+
+ port->link = 0;
+
+ mbase = ioremap(port->cfg_space.start + 0x10000000, 0x1000);
+ if (mbase == NULL) {
+ printk(KERN_ERR "%s: Can't map internal config space !",
+ port->node->full_name);
+ goto done;
+ }
+
+ while (attempt && (0 == (in_le32(mbase + PECFG_460SX_DLLSTA)
+ & PECFG_460SX_DLLSTA_LINKUP))) {
+ attempt--;
+ mdelay(10);
+ }
+ if (attempt)
+ port->link = 1;
+done:
+ iounmap(mbase);
+
+}
+
static struct ppc4xx_pciex_hwops ppc460sx_pcie_hwops __initdata = {
.core_init = ppc460sx_pciex_core_init,
.port_init_hw = ppc460sx_pciex_init_port_hw,
.setup_utl = ppc460sx_pciex_init_utl,
- .check_link = ppc4xx_pciex_check_link_sdr,
+ .check_link = ppc460sx_pciex_check_link,
};
#endif /* CONFIG_44x */
@@ -1338,15 +1367,15 @@ static int __init ppc4xx_pciex_port_init(struct ppc4xx_pciex_port *port)
if (rc != 0)
return rc;
- if (ppc4xx_pciex_hwops->check_link)
- ppc4xx_pciex_hwops->check_link(port);
-
/*
* Initialize mapping: disable all regions and configure
* CFG and REG regions based on resources in the device tree
*/
ppc4xx_pciex_port_init_mapping(port);
+ if (ppc4xx_pciex_hwops->check_link)
+ ppc4xx_pciex_hwops->check_link(port);
+
/*
* Map UTL
*/
@@ -1360,13 +1389,23 @@ static int __init ppc4xx_pciex_port_init(struct ppc4xx_pciex_port *port)
ppc4xx_pciex_hwops->setup_utl(port);
/*
- * Check for VC0 active and assert RDY.
+ * Check for VC0 active or PLL Locked and assert RDY.
*/
if (port->sdr_base) {
- if (port->link &&
- ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS,
- 1 << 16, 1 << 16, 5000)) {
- printk(KERN_INFO "PCIE%d: VC0 not active\n", port->index);
+ if (of_device_is_compatible(port->node,
+ "ibm,plb-pciex-460sx")){
+ if (port->link && ppc4xx_pciex_wait_on_sdr(port,
+ PESDRn_RCSSTS,
+ 1 << 12, 1 << 12, 5000)) {
+ printk(KERN_INFO "PCIE%d: PLL not locked\n",
+ port->index);
+ port->link = 0;
+ }
+ } else if (port->link &&
+ ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS,
+ 1 << 16, 1 << 16, 5000)) {
+ printk(KERN_INFO "PCIE%d: VC0 not active\n",
+ port->index);
port->link = 0;
}
@@ -1573,8 +1612,15 @@ static int __init ppc4xx_setup_one_pciex_POM(struct ppc4xx_pciex_port *port,
dcr_write(port->dcrs, DCRO_PEGPL_OMR1BAH, lah);
dcr_write(port->dcrs, DCRO_PEGPL_OMR1BAL, lal);
dcr_write(port->dcrs, DCRO_PEGPL_OMR1MSKH, 0x7fffffff);
- /* Note that 3 here means enabled | single region */
- dcr_write(port->dcrs, DCRO_PEGPL_OMR1MSKL, sa | 3);
+ /*Enabled and single region */
+ if (of_device_is_compatible(port->node, "ibm,plb-pciex-460sx"))
+ dcr_write(port->dcrs, DCRO_PEGPL_OMR1MSKL,
+ sa | DCRO_PEGPL_460SX_OMR1MSKL_UOT
+ | DCRO_PEGPL_OMRxMSKL_VAL);
+ else
+ dcr_write(port->dcrs, DCRO_PEGPL_OMR1MSKL,
+ sa | DCRO_PEGPL_OMR1MSKL_UOT
+ | DCRO_PEGPL_OMRxMSKL_VAL);
break;
case 1:
out_le32(mbase + PECFG_POM1LAH, pciah);
@@ -1582,8 +1628,8 @@ static int __init ppc4xx_setup_one_pciex_POM(struct ppc4xx_pciex_port *port,
dcr_write(port->dcrs, DCRO_PEGPL_OMR2BAH, lah);
dcr_write(port->dcrs, DCRO_PEGPL_OMR2BAL, lal);
dcr_write(port->dcrs, DCRO_PEGPL_OMR2MSKH, 0x7fffffff);
- /* Note that 3 here means enabled | single region */
- dcr_write(port->dcrs, DCRO_PEGPL_OMR2MSKL, sa | 3);
+ dcr_write(port->dcrs, DCRO_PEGPL_OMR2MSKL,
+ sa | DCRO_PEGPL_OMRxMSKL_VAL);
break;
case 2:
out_le32(mbase + PECFG_POM2LAH, pciah);
@@ -1592,7 +1638,9 @@ static int __init ppc4xx_setup_one_pciex_POM(struct ppc4xx_pciex_port *port,
dcr_write(port->dcrs, DCRO_PEGPL_OMR3BAL, lal);
dcr_write(port->dcrs, DCRO_PEGPL_OMR3MSKH, 0x7fffffff);
/* Note that 3 here means enabled | IO space !!! */
- dcr_write(port->dcrs, DCRO_PEGPL_OMR3MSKL, sa | 3);
+ dcr_write(port->dcrs, DCRO_PEGPL_OMR3MSKL,
+ sa | DCRO_PEGPL_OMR3MSKL_IO
+ | DCRO_PEGPL_OMRxMSKL_VAL);
break;
}
@@ -1693,6 +1741,9 @@ static void __init ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
if (res->flags & IORESOURCE_PREFETCH)
sa |= 0x8;
+ if (of_device_is_compatible(port->node, "ibm,plb-pciex-460sx"))
+ sa |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+
out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
@@ -1854,6 +1905,10 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
}
out_le16(mbase + 0x202, val);
+ /* Enable Bus master, memory, and io space */
+ if (of_device_is_compatible(port->node, "ibm,plb-pciex-460sx"))
+ out_le16(mbase + 0x204, 0x7);
+
if (!port->endpoint) {
/* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
out_le32(mbase + 0x208, 0x06040001);
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h b/arch/powerpc/sysdev/ppc4xx_pci.h
index 56d9e5d..61b3659 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.h
+++ b/arch/powerpc/sysdev/ppc4xx_pci.h
@@ -464,6 +464,18 @@
#define PECFG_POM2LAL 0x390
#define PECFG_POM2LAH 0x394
+/* 460sx only */
+#define PECFG_460SX_DLLSTA 0x3f8
+
+/* 460sx Bit Mappings */
+#define PECFG_460SX_DLLSTA_LINKUP 0x00000010
+#define DCRO_PEGPL_460SX_OMR1MSKL_UOT 0x00000004
+
+/* PEGPL Bit Mappings */
+#define DCRO_PEGPL_OMRxMSKL_VAL 0x00000001
+#define DCRO_PEGPL_OMR1MSKL_UOT 0x00000002
+#define DCRO_PEGPL_OMR3MSKL_IO 0x00000002
+
/* SDR Bit Mappings */
#define PESDRx_RCSSET_HLDPLB 0x10000000
#define PESDRx_RCSSET_RSTGU 0x01000000
--
1.7.4.3
^ permalink raw reply related
* [v3 PATCH 0/1] powerpc/4xx: enable and fix pcie gen1/gen2 on the 460sx
From: Ayman Elkhashab @ 2011-07-20 13:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Breeds, linuxppc-dev,
linux-kernel
Cc: Ayman El-Khashab
In-Reply-To: <1310603611-8960-2-git-send-email-ayman@elkhashab.com>
From: Ayman El-Khashab <ayman@elkhashab.com>
Changes from v1->v2
Added definitions for the bits in the OMRxMSKL registers
Refactored the setting of the OMRxMSKL registers for the 460SX
Added bit defines for the PECFG_460SX_DLLSTA register
Changes from v2->v3
Fixed commit message to be more clear as to what was done
Ayman El-Khashab (1):
powerpc/4xx: enable and fix pcie gen1/gen2 on the 460sx
arch/powerpc/sysdev/ppc4xx_pci.c | 89 ++++++++++++++++++++++++++++++-------
arch/powerpc/sysdev/ppc4xx_pci.h | 12 +++++
2 files changed, 84 insertions(+), 17 deletions(-)
--
1.7.4.3
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Anton Blanchard @ 2011-07-20 12:14 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: mahesh, linuxppc-dev, linux-kernel, mingo, torvalds
In-Reply-To: <1311158708.5345.12.camel@twins>
Hi Peter,
> So with that fix the patch makes the machine happy again?
Yes, the machine looks fine with the patches applied. Thanks!
Anton
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Peter Zijlstra @ 2011-07-20 10:45 UTC (permalink / raw)
To: Anton Blanchard; +Cc: mahesh, linuxppc-dev, linux-kernel, mingo, torvalds
In-Reply-To: <20110720201436.19e9689a@kryten>
On Wed, 2011-07-20 at 20:14 +1000, Anton Blanchard wrote:
> > That looks very strange indeed.. up to node 23 there is the normal
> > symmetric matrix with all the trace elements on 10 (as we would expect
> > for local access), and some 4x4 sub-matrix stacked around the trace
> > with 20, suggesting a single hop distance, and the rest on 40 being
> > out-there.
>=20
> I retested with the latest version of numactl, and get correct results.
One less thing to worry about ;-)
> I worked out why the patches don't boot, we weren't allocating any
> space for the cpumask and ran off the end of the allocation.
Gah! that's not the first time I made that particular mistake :/
> Should we also use cpumask_copy instead of open coding it? I added that
> too.
Probably, I looked for cpumask_assign() and on failing to find that used
the direct assignment.
So with that fix the patch makes the machine happy again?
Thanks!
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Anton Blanchard @ 2011-07-20 10:14 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: mahesh, linuxppc-dev, linux-kernel, mingo, torvalds
In-Reply-To: <1311070894.13765.180.camel@twins>
Hi Peter,
> That looks very strange indeed.. up to node 23 there is the normal
> symmetric matrix with all the trace elements on 10 (as we would expect
> for local access), and some 4x4 sub-matrix stacked around the trace
> with 20, suggesting a single hop distance, and the rest on 40 being
> out-there.
I retested with the latest version of numactl, and get correct results.
I worked out why the patches don't boot, we weren't allocating any
space for the cpumask and ran off the end of the allocation.
Should we also use cpumask_copy instead of open coding it? I added that
too.
Anton
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c 2011-07-20 01:54:08.191668781 -0500
+++ linux-2.6/kernel/sched.c 2011-07-20 04:45:36.203750525 -0500
@@ -7020,8 +7020,8 @@
if (cpumask_test_cpu(i, covered))
continue;
- sg = kzalloc_node(sizeof(struct sched_group), GFP_KERNEL,
- cpu_to_node(i));
+ sg = kzalloc_node(sizeof(struct sched_group) + cpumask_size(),
+ GFP_KERNEL, cpu_to_node(i));
if (!sg)
goto fail;
@@ -7031,7 +7031,7 @@
child = *per_cpu_ptr(sdd->sd, i);
if (child->child) {
child = child->child;
- *sg_span = *sched_domain_span(child);
+ cpumask_copy(sg_span, sched_domain_span(child));
} else
cpumask_set_cpu(i, sg_span);
^ permalink raw reply
* RE: [PATCH 2/3] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Zang Roy-R61911 @ 2011-07-20 9:29 UTC (permalink / raw)
To: S, Venkatraman; +Cc: Xu Lei-B33228, linux-mmc, akpm, linuxppc-dev
In-Reply-To: <CANfBPZ-V3+NFDVuftXfpTwUGwmXC-sFiUhG8LKCLROse6xT3=Q@mail.gmail.com>
> -----Original Message-----
> From: S, Venkatraman [mailto:svenkatr@ti.com]
> Sent: Tuesday, July 19, 2011 23:58 PM
> To: Zang Roy-R61911
> Cc: linux-mmc; linuxppc-dev; cbouatmailru; akpm; Xu Lei-B33228; Kumar Gal=
a
> Subject: Re: [PATCH 2/3] eSDHC: Fix errors when booting kernel with fsl e=
sdhc
>=20
> On Mon, Jul 18, 2011 at 11:31 AM, Zang Roy-R61911 <r61911@freescale.com> =
wrote:
> >
> >
> >> -----Original Message-----
> >> From: S, Venkatraman [mailto:svenkatr@ti.com]
> >> Sent: Tuesday, July 05, 2011 14:17 PM
> >> To: Zang Roy-R61911
> >> Cc: linux-mmc; linuxppc-dev; cbouatmailru; akpm; Xu Lei-B33228; Kumar =
Gala
> >> Subject: Re: [PATCH 2/3] eSDHC: Fix errors when booting kernel with fs=
l esdhc
> >>
> >> On Tue, Jul 5, 2011 at 9:49 AM, Roy Zang <tie-fei.zang@freescale.com> =
wrote:
> >> > From: Xu lei <B33228@freescale.com>
> >> >
> >> > When esdhc module was enabled in p5020, there were following errors:
> >> >
> >> > mmc0: Timeout waiting for hardware interrupt.
> >> > mmc0: error -110 whilst initialising SD card
> >> > mmc0: Unexpected interrupt 0x02000000.
> >> > mmc0: Timeout waiting for hardware interrupt.
> >> > mmc0: error -110 whilst initialising SD card
> >> > mmc0: Unexpected interrupt 0x02000000.
> >> >
> >> > It is because ESDHC controller has different bit setting for PROCTL
> >> > register, when kernel sets Power Control Register by method for stan=
dard
> >> > SD Host Specification, it would overwritten FSL ESDHC PROCTL[DMAS];
> >> > when it set Host Control Registers[DMAS], it sets PROCTL[EMODE] and
> >> > PROCTL[D3CD]. These operations will set bad bits for PROCTL Register
> >> > on FSL ESDHC Controller and cause errors, so this patch will make es=
dhc
> >> > driver access FSL PROCTL Register according to block guide instead o=
f
> >> > standard SD Host Specification.
> >> >
> >> > For some FSL chips, such as MPC8536/P2020, PROCTL[VOLT_SEL] and PROC=
TL[DMAS]
> >> > bits are reserved and even if they are set to wrong bits there is no=
error.
> >> > But considering that all FSL ESDHC Controller register map is not fu=
lly
> >> > compliant to standard SD Host Specification, we put the patch to all=
of
> >> > FSL ESDHC Controllers.
> >> >
> >> > Signed-off-by: Lei Xu <B33228@freescale.com>
> >> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> >> > ---
> >> > =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A03 ++
> >> > =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 62 +++++++++++++++=
+++++++++++++++----
> -
> >> --
> >> > =A0include/linux/mmc/sdhci.h =A0 =A0 =A0 =A0| =A0 =A06 ++-
> >> > =A03 files changed, 57 insertions(+), 14 deletions(-)
> > [snip]
> >
> >> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >> > index 58d5436..77174e5 100644
> >> > --- a/drivers/mmc/host/sdhci.c
> >> > +++ b/drivers/mmc/host/sdhci.c
> >> > @@ -674,7 +674,7 @@ static void sdhci_set_transfer_irqs(struct sdhci=
_host
> >> *host)
> >> > =A0static void sdhci_prepare_data(struct sdhci_host *host, struct mm=
c_command
> >> *cmd)
> >> > =A0{
> >> > =A0 =A0 =A0 =A0u8 count;
> >> > - =A0 =A0 =A0 u8 ctrl;
> >> > + =A0 =A0 =A0 u32 ctrl;
> >> > =A0 =A0 =A0 =A0struct mmc_data *data =3D cmd->data;
> >> > =A0 =A0 =A0 =A0int ret;
> >> >
> >> > @@ -807,14 +807,28 @@ static void sdhci_prepare_data(struct sdhci_ho=
st
> *host,
> >> struct mmc_command *cmd)
> >> > =A0 =A0 =A0 =A0 * is ADMA.
> >> > =A0 =A0 =A0 =A0 */
> >> > =A0 =A0 =A0 =A0if (host->version >=3D SDHCI_SPEC_200) {
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl =3D sdhci_readb(host, SDHCI_HOST_=
CONTROL);
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl &=3D ~SDHCI_CTRL_DMA_MASK;
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((host->flags & SDHCI_REQ_USE_DMA) =
&&
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (host->flags & SDHCI_U=
SE_ADMA))
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D SDHCI_CTRL_A=
DMA32;
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctrl |=3D SDHCI_CTRL_S=
DMA;
> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 sdhci_writeb(host, ctrl, SDHCI_HOST_CO=
NTROL);
> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks & SDHCI_QUIRK_QORIQ_P=
ROCTL_WEIRD) {
> >> > +#define ESDHCI_PROCTL_DMAS_MASK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x00=
000300
> >> > +#define ESDHCI_PROCTL_ADMA32 =A0 =A0 =A0 =A0 =A0 0x00000200
> >> > +#define ESDHCI_PROCTL_SDMA =A0 =A0 =A0 =A0 =A0 =A0 0x00000000
> >>
> >> Breaks the code flow / readability. Can be moved to top of the file ?
> > The defines are only used in the following section. Why it will break
> > the readability?
> > I can also see this kind of define in the file
> > ...
> > #define SAMPLE_COUNT =A0 =A05
> >
> > static int sdhci_get_ro(struct mmc_host *mmc)
> > ...
> >
> > Any rule should follow?
> >
> >
> > [snip]
> >> > @@ -1162,6 +1189,17 @@ static void sdhci_set_power(struct sdhci_host=
*host,
> >> unsigned short power)
> >> >
> >> > =A0 =A0 =A0 =A0host->pwr =3D pwr;
> >> >
> >> > + =A0 =A0 =A0 /* Now FSL ESDHC Controller has no Bus Power bit,
> >> > + =A0 =A0 =A0 =A0* and PROCTL[21] bit is for voltage selection */
> >>
> >> Multiline comment style needed..
> > Will update.
> > please help to explain your previous comment.
> > Thanks.
> > Roy
>=20
> There aren't very hard rules on this. Simple #defines are good, as a
> one off usage.
> These bit mask fields are very verbose, and they tend to grow more
> than a screenful.
> The remaining bits will never be defined ?
The mask fields and bits are only for some WERID defines. I do not think
they will grow more than a screen.
The remain bits will have little chance to be defined.
Thanks for the suggestion. I will update the comment style and post again.
Roy
^ permalink raw reply
* Re: [PATCH] net: ibm_newemac: Don't start autonegotiation when disabled in BMCR (genmii)
From: Stefan Roese @ 2011-07-20 7:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, netdev
In-Reply-To: <1311078570.25044.421.camel@pasglop>
On Tuesday 19 July 2011 14:29:30 Benjamin Herrenschmidt wrote:
> > I feel that this BMCR_ANENABLE bit should be evaluated, but I have no
> > strong preference here. If you prefer that this should be handled via a
> > new dt property (phy-aneg = "disabled" ?), I can implement it this way.
> > Just let me know.
>
> Don't we already have some bindings for PHY with a fixed setting ? I
> don't remember off hand, we need to dbl check.
The only related PHY property I found is "fixed-link" used in fs_enet-main.c.
None in the emac driver. Here the description for "fixed-link":
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt:
- fixed-link : <a b c d e> where a is emulated phy id - choose any,
but unique to the all specified fixed-links, b is duplex - 0 half,
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
But what I really want to achieve, is to skip auto-negotiation (use the
strapped configuration). And not to define this fixed configuration (again) in
the device-tree. So I would prefer something like phy-aneg = "disabled".
What do you think?
Thanks,
Stefan
^ permalink raw reply
* Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
From: Anton Blanchard @ 2011-07-20 2:03 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: mahesh, linuxppc-dev, linux-kernel, mingo, torvalds
In-Reply-To: <1311070894.13765.180.camel@twins>
Hi,
> That looks very strange indeed.. up to node 23 there is the normal
> symmetric matrix with all the trace elements on 10 (as we would expect
> for local access), and some 4x4 sub-matrix stacked around the trace
> with 20, suggesting a single hop distance, and the rest on 40 being
> out-there.
>
> But row 24-27 and column 28-31 are way weird, how can that ever be?
> Aren't the inter-connects symmetric and thus mandating a fully
> symmetric matrix? That is, how can traffic from node 23 (row) to node
> 28 (column) have inf bandwidth (0) yet traffic from node 28 (row) to
> node 23 (column) have a multi-hop distance of 40.
Good point, it definitely makes no sense. It looks like a bug in
numactl, the raw data looks reasonable:
# cat /sys/devices/system/node/node?/distance node??/distance
10 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
20 10 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
20 20 10 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
20 20 20 10 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 10 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 20 10 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 20 20 10 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 20 20 20 10 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 10 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 20 10 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 20 20 10 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 20 20 20 10 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 10 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 20 10 20 20 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 20 20 10 20 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 20 20 20 10 40 40 40 40 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 10 20 20 20 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 10 20 20 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 20 10 20 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 20 20 10 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 10 20 20 20 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 10 20 20 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 20 10 20 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 20 20 10 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 10 20 20 20
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 10 20 20
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 20 10 20
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 20 20 20 10
Yet another bug to track down :(
> So the idea I had to generate numa sched domains from the node
> distance ( http://marc.info/?l=linux-kernel&m=130218515520540 ),
> would that still work for you? [it does assume a symmetric matrix ]
It should work for us and it makes our NUMA memory and scheduler
domains more consistent. Nice!
Anton
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Enable lockup and hung task detectors in pseriesand ppc64 defeconfigs
From: Anton Blanchard @ 2011-07-19 23:46 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8ADE3@saturn3.aculab.com>
Hi David,
> > As a result of changes to Kconfig files, we no longer enable
> > the lockup and hung task detectors. Both are very light weight
> > and provide useful information in the event of a hang, so
> > reenable them.
> ...
> > +CONFIG_LOCKUP_DETECTOR=y
> > +CONFIG_DETECT_HUNG_TASK=y
>
> Is one of thise responsible for generating a kernel stack traceback
> when a process has been sleeping uninterruptably for a 'long' time?
>
> We have a kernel subsystem that has several 'worker' threads,
> these always sleep uninterruptable (they are shut down by explicit
> request) and, at times, can be idle for long periods.
>
> Perhaps it should be possible to disable the check either on
> a per-process of per sleep basis?
I don't see any runtime options other than disabling it completely via:
/proc/sys/kernel/hung_task_timeout_secs
Anton
^ permalink raw reply
* Re: setbat() in udbg_init_cpm() required to avoid driver lockup
From: Scott Wood @ 2011-07-19 18:24 UTC (permalink / raw)
To: Daniel Ng2; +Cc: linuxppc-dev
In-Reply-To: <32088424.post@talk.nabble.com>
On Mon, 18 Jul 2011 22:39:01 -0700
Daniel Ng2 <daniel.ng1234@gmail.com> wrote:
>
> Our USB Device Controller (UDC) driver seems to get stuck in a loop waiting
> for the CPM Command Register to indicate that the CPM has finished executing
> a command. (It should do this by setting the cpmcr 'Command Done' bit).
>
> This only happens if I disable the 'Early Debug' Kernel Hacking .config
> parameter. If Early Debug is enabled, then the problem goes away.
>
> I've narrowed it down to this line in udbg_init_cpm(void):
>
> setbat(1, 0xf0000000, 0xf0000000, 0x40000, PAGE_KERNEL_NCG);
>
> -without this line, the driver gets stuck in the loop.
>
> Can anyone suggest why?
Is your USB driver accessing effective addresses from 0xf0000000 to
0xf0040000? It should be using ioremap().
> Also, what undesireable effects might there be of keeping the above call to
> setbat()?
It's squatting on a chunk of virtual address space without properly
reserving it. This is bad enough for a debug hack (and should be fixed).
Don't extend it to normal operation -- especially not as a substitute for
understanding the root cause of your problem.
-Scott
^ permalink raw reply
* Re: [PATCH 13/14] 85xx: consolidate of_platform_bus_probe calls
From: Scott Wood @ 2011-07-19 17:54 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Paul Mackerras, Linux PPC Development
In-Reply-To: <1311065631-3429-14-git-send-email-dbaryshkov@gmail.com>
On Tue, 19 Jul 2011 12:53:50 +0400
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote:
> +static struct of_device_id __initdata mpc85xx_common_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + { .compatible = "simple-bus", },
> + { .compatible = "gianfar", },
> + { .compatible = "fsl,qe", },
> + { .compatible = "fsl,cpm2", },
> + {},
> +};
Same comment as for 83xx regarding localbus and compatibility with old
device trees.
-Scott
^ permalink raw reply
* Re: [PATCH 04/14] 83xx/mpc834x_itx: drop pq2pro-localbus-specific code
From: Scott Wood @ 2011-07-19 16:55 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Paul Mackerras, Linux PPC Development
In-Reply-To: <1311065631-3429-5-git-send-email-dbaryshkov@gmail.com>
On Tue, 19 Jul 2011 12:53:41 +0400
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote:
> As localbus on mpc8349e-mitx now provides simple-bus compatibility, we
> can drop code asking for pq2pro-localbus devices on mpc834x_itx boards.
Do we have a good reason for breaking compatibility with older device trees?
-Scott
^ permalink raw reply
* [PATCH] powerpc: Fix build dependencies for epapr.c which needs libfdt.h
From: Matthew McClintock @ 2011-07-19 16:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock
Currently, the build can (very rarely) fail to build because libfdt.h has
not been created or is in the process of being copied.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
I think this fixes this build error. Please comment as it's really hard to
reproduce this build error. I've seen this happen a few times now on our
automated build server.
BOOTCC arch/powerpc/boot/ep8248e.o
BOOTCC arch/powerpc/boot/cuboot-warp.o
BOOTCC arch/powerpc/boot/cuboot-85xx-cpm2.o
In file included from arch/powerpc/boot/epapr.c:20:0:
arch/powerpc/boot/libfdt.h:382:1: error: unterminated comment
arch/powerpc/boot/libfdt.h:1:0: error: unterminated #ifndef
BOOTCC arch/powerpc/boot/cuboot-yosemite.o
make[1]: *** [arch/powerpc/boot/epapr.o] Error 1
make[1]: *** Waiting for unfinished jobs....
BOOTCC arch/powerpc/boot/simpleboot.o
make: *** [uImage] Error 2
Build step 'Execute shell' marked build as failure
arch/powerpc/boot/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c26200b..ac6705e 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -58,7 +58,7 @@ $(addprefix $(obj)/,$(zlib) cuboot-c2k.o gunzip_util.o main.o prpmc2800.o): \
libfdt := fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
libfdtheader := fdt.h libfdt.h libfdt_internal.h
-$(addprefix $(obj)/,$(libfdt) libfdt-wrapper.o simpleboot.o): \
+$(addprefix $(obj)/,$(libfdt) libfdt-wrapper.o simpleboot.o epapr.o): \
$(addprefix $(obj)/,$(libfdtheader))
src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
--
1.7.5
^ permalink raw reply related
* Re: [PATCH 00/14] Consolidation of 83xx/85xx board files
From: Kumar Gala @ 2011-07-19 14:29 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Linux PPC Development, Paul Mackerras
In-Reply-To: <1311065631-3429-1-git-send-email-dbaryshkov@gmail.com>
On Jul 19, 2011, at 3:53 AM, Dmitry Eremin-Solenikov wrote:
> I think it's already too late for this merge window, so this should =
stay
> for 3.2 merge window. Board files for mpc83xx platforms show lots of =
common
> code. Same goes for mpc85xx boards. This patchset is an initial =
attempt
> to merge some (most) of the common code. Based on the tree by Kumar =
Gala.
>=20
> The following changes since commit =
6471fc6630a507fd54fdaceceee1ddaf3c917cde:
>=20
> powerpc: Dont require a dma_ops struct to set dma mask (2011-07-08 =
00:21:36 -0500)
>=20
> Dmitry Eremin-Solenikov (14):
> 83xx: consolidate init_IRQ functions
> 83xx: consolidate of_platform_bus_probe calls
> mpc8349emitx: mark localbus as compatible with simple-bus
> 83xx/mpc834x_itx: drop pq2pro-localbus-specific code
> 83xx: headers cleanup
> 85xx/sbc8560: correct compilation if CONFIG_PHYS_ADDR_T_64BIT is =
set
> 85xx/ksi8560: declare that localbus is compatbile with simple-bus
> 85xx/sbc8560: declare that localbus is compatbile with simple-bus
> 85xx/sbc8548: read hardware revision when it's required for first =
time
> 85xx/mpc85xx_rdb: merge p1020_rdb and p2020_rdb machine entries
> 85xx: merge 32-bit QorIQ with DPA boards support
> 85xx/mpc85xx_ds,ads,cds: move .pci_exclude_device setting to =
machine definitions
> 85xx: consolidate of_platform_bus_probe calls
> 85xx: separate cpm2 pic init
So for next round can you split this into two groups. One for 83xx and =
one for 85xx.
- k=
^ permalink raw reply
* Re: [PATCH 03/14] mpc8349emitx: mark localbus as compatible with simple-bus
From: Kumar Gala @ 2011-07-19 14:23 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Linux PPC Development, Paul Mackerras
In-Reply-To: <1311065631-3429-4-git-send-email-dbaryshkov@gmail.com>
On Jul 19, 2011, at 3:53 AM, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
applied to next-3.2
- k
^ 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