* [PATCH] memblock: Fix memblock_is_region_reserved() to return a boolean
From: Benjamin Herrenschmidt @ 2010-08-04 4:19 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Russell King, linuxppc-dev, linux-arm-kernel@lists.infradead.org,
linux-mm@kvack.org
All callers expect a boolean result which is true if the region
overlaps a reserved region. However, the implementation actually
returns -1 if there is no overlap, and a region index (0 based)
if there is.
Make it behave as callers (and common sense) expect.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Taking that out of my memblock rework branch as it should go in
now regardless of whether my stuff goes or not (which is still
under discussion, I'm fixing ARM up now).
I'll send this fix to Linus tomorrow along with powerpc.git if there
is no adverse comment.
diff --git a/mm/memblock.c b/mm/memblock.c
index 3024eb3..43840b3 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -504,7 +504,7 @@ int __init memblock_is_reserved(u64 addr)
int memblock_is_region_reserved(u64 base, u64 size)
{
- return memblock_overlaps_region(&memblock.reserved, base, size);
+ return memblock_overlaps_region(&memblock.reserved, base, size) >= 0;
}
/*
^ permalink raw reply related
* Re: ramdisk size is larger than 4MB
From: Shawn Jin @ 2010-08-04 6:00 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <AANLkTimWYeRtN+Bcw-vG2G1j-D3FFmaUW7cnpvL+e=yN@mail.gmail.com>
> I did more debugging and something is really weird though. When the
> link address is changed to 0x800000, when stepping through the kernel,
> I actually got the kernel boot successfully. However I let the kernel
> run through it would just crash. After crash the BDI2000 shows it
> stopped at __delay().
Well, actually it's nothing to do with gdb.
When the link address is changed to 0x800000, if the PPC_EARLY_DEBUG
and PPC_EARLY_DEBUG_CPM are on, the built kernel can boot
successfully. But without these EARLY_DEBUG, the kernel fails to boot.
=> bootm 5000000
## Booting image at 05000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1757354 Bytes = 1.7 MB
Load Address: 00800000
Entry Point: 00800554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00800000 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080c000:0x00bd702c)...done 0x3886ec bytes
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
^^^^^^^^^^^^^^^^^^The kernel stopped here.
=> bootm 5000000
## Booting image at 05000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1757742 Bytes = 1.7 MB
Load Address: 00800000
Entry Point: 00800554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00800000 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080c000:0x00bd702c)...done 0x3886ec bytes
Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using My MPC870 machine description
Linux version 2.6.33.5 (shanw@ubuntu) (gcc version 4.2.2) #5 Tue Aug 3
21:24:40 PDT 2010
bootconsole [udbg0] enabled
^^^^^^^^^The kernel continued booting.
With the EARLY_DEBUG turned on, the link address is changed to
0x1000000, the built kernel can also boot successfully.
However if the link address is changed to 0x2000000 or 0x4000000, the
built kernel fails to boot.
I think the kernel failure may be caused by some memory corruption.
But will the bootwrapper relocation corrupt the kernel code?
Thanks,
-Shawn.
^ permalink raw reply
* Booting MPC8377ERBD from NAND flash
From: Ravi Gupta @ 2010-08-04 11:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
Hi,
I am trying to boot MPC8377ERBD freescale board from NAND flash. As per its
specifications, it supports NAND boot but it there is no support for NAND
boot in the BSP(confirmed with freescale also). Now I decided to modify BSP
myself to support NAND boot and I am confused that from where should I
start. Please suggest.
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 377 bytes --]
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: Badness at lib/dma-debug.c:902, Call Trace & Instruction Dump during boot
From: Roedel, Joerg @ 2010-08-04 13:16 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: sachinp@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
santil@us.ibm.com, Linuxppc-dev@ozlabs.org, devilbis@us.ibm.com,
James.Bottomley@suse.de, sleddog@us.ibm.com,
brking@linux.vnet.ibm.com, tj@kernel.org,
subrata@linux.vnet.ibm.com, dipraksh@linux.vnet.ibm.com
In-Reply-To: <20100802205404C.fujita.tomonori@lab.ntt.co.jp>
On Mon, Aug 02, 2010 at 07:55:03AM -0400, FUJITA Tomonori wrote:
> I guess that this driver does a partial sync with
> dma_sync_single_for_* API. dma-debug can't handle it properly. It's
> likely that this is a false warning.
If this turns out to be true it is not trivial to fix. I prepare a patch
to test for you.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-08-04 13:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <1279837509.1970.24.camel@pasglop>
On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:
>>
>> 1) How can the preempt_count() get mangled across the H_CEDE hcall?
>> 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
>
> The preempt count is on the thread info at the bottom of the stack.
>
> Can you check the stack pointers ?
Hi Ben, sorry if I didn't get back to you on this already. I checked the
stack pointer before and after the cede call and they match.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: Badness at lib/dma-debug.c:902, Call Trace & Instruction Dump during boot
From: FUJITA Tomonori @ 2010-08-04 14:18 UTC (permalink / raw)
To: Joerg.Roedel
Cc: sachinp, linux-kernel, santil, fujita.tomonori, Linuxppc-dev,
devilbis, James.Bottomley, sleddog, brking, tj, subrata, dipraksh
In-Reply-To: <20100804131634.GX26098@amd.com>
On Wed, 4 Aug 2010 15:16:34 +0200
"Roedel, Joerg" <Joerg.Roedel@amd.com> wrote:
> On Mon, Aug 02, 2010 at 07:55:03AM -0400, FUJITA Tomonori wrote:
> > I guess that this driver does a partial sync with
> > dma_sync_single_for_* API. dma-debug can't handle it properly. It's
> > likely that this is a false warning.
>
> If this turns out to be true it is not trivial to fix. I prepare a patch
> to test for you.
I've not looked at the details of this driver, but there are drivers
that do such. So dma-debug needs to be fixed anyway; you can't assume
that a DMA address that dma_map_single returned is passed to
dma_sync_single_for API.
^ permalink raw reply
* Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
From: Neil Horman @ 2010-08-04 14:49 UTC (permalink / raw)
To: linux-kernel, kexec, vgoyal, hbabu, benh, paulus, linuxppc-dev
In-Reply-To: <20100713134609.GA14514@hmsreliant.think-freely.org>
On Tue, Jul 13, 2010 at 09:46:09AM -0400, Neil Horman wrote:
> Hey all-
> About 2 years ago now, I sent this patch upstream to allow makedumpfile
> to properly filter cores on ppc64:
> http://www.mail-archive.com/kexec@lists.infradead.org/msg02426.html
> It got acks from the kexec folks so I pulled it into RHEL, but I never checked
> back here to make sure it ever made it in, which apparently it didn't. It still
> needs to be included, so I'm reposting it here, making sure to copy all the ppc
> folks this time. I've retested it on the latest linus kernel and it works fine,
> allowing makedumpfile to find all the symbols it needs to properly strip a
> vmcore on ppc64.
>
> Neil
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> machine_kexec.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
>
> diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> index bb3d893..0df7031 100644
> --- a/arch/powerpc/kernel/machine_kexec.c
> +++ b/arch/powerpc/kernel/machine_kexec.c
> @@ -45,6 +45,18 @@ void machine_kexec_cleanup(struct kimage *image)
> ppc_md.machine_kexec_cleanup(image);
> }
>
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +
> +#ifdef CONFIG_NEED_MULTIPLE_NODES
> + VMCOREINFO_SYMBOL(node_data);
> + VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
> +#endif
> +#ifndef CONFIG_NEED_MULTIPLE_NODES
> + VMCOREINFO_SYMBOL(contig_page_data);
> +#endif
> +}
> +
> /*
> * Do not allocate memory (or fail in any way) in machine_kexec().
> * We are past the point of no return, committed to rebooting now.
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
Ping yet again. Ben, This needs review/acceptance from you or Paul
Neil
^ permalink raw reply
* RE: Booting MPC8377ERBD from NAND flash
From: Jenkins, Clive @ 2010-08-04 14:34 UTC (permalink / raw)
To: Ravi Gupta, linuxppc-dev
In-Reply-To: <AANLkTinfQz3PuZK6urnYyh03JuuSt5mFrv8ykNQmg9nD@mail.gmail.com>
> I am trying to boot MPC8377ERBD freescale board from NAND flash.
> As per its specifications, it supports NAND boot but it there is
> no support for NAND boot in the BSP(confirmed with freescale also).
> Now I decided to modify BSP myself to support NAND boot and I am
> confused that from where should I start. Please suggest.
Read this
http://www.freescale.com/files/32bit/doc/app_note/AN3201.pdf
and other documentation on the Freescale site
=20
Clive=20
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Subrata Modak @ 2010-08-04 14:56 UTC (permalink / raw)
To: Peter Zijlstra, Li Zefan, Linuxppc-dev
Cc: sachinp, linux-kernel, DIVYA PRAKASH
In-Reply-To: <1280739132.15317.9.camel@subratamodak.linux.ibm.com>
Peter/Li,
Did you get a chance to see this ?
Regards--
Subrata
On Mon, 2010-08-02 at 14:22 +0530, Subrata Modak wrote:
> Hi,
>
> The following suspicious rcu_dereference_check() usage is detected
> during 2.6.35-stable boot on my ppc64/p7 machine:
>
> ==================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 0
> 1 lock held by swapper/1:
> #0: (&rq->lock){-.....}, at: [<c0000000007ca2f8>] .init_idle+0x78/0x4a8
> stack backtrace:
> Call Trace:
> [c000000f392bf990] [c000000000014f04] .show_stack+0xb0/0x1a0 (unreliable)
> [c000000f392bfa50] [c0000000007c87b4] .dump_stack+0x28/0x3c
> [c000000f392bfad0] [c000000000103e1c] .lockdep_rcu_dereference+0xbc/0xe4
> [c000000f392bfb70] [c0000000007ca434] .init_idle+0x1b4/0x4a8
> [c000000f392bfc30] [c0000000007cad04] .fork_idle+0xa4/0xd0
> [c000000f392bfe30] [c000000000aefaac] .smp_prepare_cpus+0x23c/0x2f4
> [c000000f392bfed0] [c000000000ae1424] .kernel_init+0xec/0x32c
> [c000000f392bff90] [c000000000033f40] .kernel_thread+0x54/0x70
> ==================================================
>
> Please note that this was reported earlier on 2.6.34-rc6:
> http://marc.info/?l=linux-kernel&m=127313031922395&w=2,
> The issue was fixed with:
> commit 1ce7e4ff24fe338438bc7837e02780f202bf202b
> Author: Li Zefan <lizf@cn.fujitsu.com>
> Date: Fri Apr 23 10:35:52 2010 +0800
> cgroup: Check task_lock in task_subsys_state()
>
> According to:
> http://lkml.org/lkml/2010/7/1/883,
> commit dc61b1d65e353d638b2445f71fb8e5b5630f2415
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Tue Jun 8 11:40:42 2010 +0200
> sched: Fix PROVE_RCU vs cpu_cgroup
> should have fixed this. But this is reproducible on 2.6.35-stable.
>
> Please also see the config file attached.
>
> Regards--
> Subrata
>
^ permalink raw reply
* Re: Booting MPC8377ERBD from NAND flash
From: Scott Wood @ 2010-08-04 16:16 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: Ravi Gupta, linuxppc-dev
In-Reply-To: <929D3CED81F34E43887A393170D66FB9030B2DBA@GBRSUN01MS002.eu.xerox.net>
On Wed, 4 Aug 2010 15:34:59 +0100
"Jenkins, Clive" <Clive.Jenkins@xerox.com> wrote:
> > I am trying to boot MPC8377ERBD freescale board from NAND flash.
> > As per its specifications, it supports NAND boot but it there is
> > no support for NAND boot in the BSP(confirmed with freescale also).
> > Now I decided to modify BSP myself to support NAND boot and I am
> > confused that from where should I start. Please suggest.
>
> Read this
> http://www.freescale.com/files/32bit/doc/app_note/AN3201.pdf
> and other documentation on the Freescale site
That's a bit outdated on the software side. Look under the nand_spl
directory in u-boot; you should see several boards to use as examples.
If possible, I suggest working with the latest upstream u-boot rather
than what comes with the BSP.
If you have further questions, ask at u-boot@lists.denx.de.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/85xx: Fix SWIOTLB initalization for MPC85xxMDS boards
From: Kumar Gala @ 2010-08-04 19:15 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100608195540.GA11446@oksana.dev.rtsoft.ru>
On Jun 8, 2010, at 2:55 PM, Anton Vorontsov wrote:
> The code inside '#ifdef CONFIG_QUICC_ENGINE' makes the
> mpc85xx_mds_setup_arch() return early if no QE nodes present,
> and so SWIOTLB is never initialized.
>
> This patch fixes the issue by moving SWIOTLB code above
> QE.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/85xx: Fix booting for P1021MDS boards
From: Kumar Gala @ 2010-08-04 19:15 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100608195550.GB11446@oksana.dev.rtsoft.ru>
On Jun 8, 2010, at 2:55 PM, Anton Vorontsov wrote:
> P1021 processors have no dedicated ROM to store the QE microcode,
> so the fimrware is stored externally, and it is U-Boot responsibility
> to load it. It might be that the board is booting without QE, e.g.
> currently U-Boot doesn't support QE for P1021MDS boards, which means
> that QE isn't initialized, and so the board hangs early at boot.
>=20
> This patch fixes the issue by marking QE as disabled and checking the
> state in the probing code. U-Boot should fixup the state if it
> initialized the QE.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
> arch/powerpc/boot/dts/p1021mds.dts | 1 +
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 43 =
+++++++++++++++++++++++++----
> 2 files changed, 38 insertions(+), 6 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/85xx: Cleanup QE initialization for MPC85xxMDS boards
From: Kumar Gala @ 2010-08-04 19:15 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100608195557.GC11446@oksana.dev.rtsoft.ru>
On Jun 8, 2010, at 2:55 PM, Anton Vorontsov wrote:
> The mpc85xx_mds_setup_arch() function is incomprehensible
> and unmaintainable. Factor out all QE specific stuff into
> mpc85xx_mds_qe_init() and mpc85xx_mds_reset_ucc_phys().
>=20
> Also move QE stuff out of mpc85xx_mds_pic_init().
>=20
> The diff is unreadable, but only because the code was so. ;-)
> It should be better now, and less indented.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 272 =
+++++++++++++++--------------
> 1 files changed, 143 insertions(+), 129 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/2] fsl_pci: add quirk for mpc8308 pcie bridge
From: Kumar Gala @ 2010-08-04 19:18 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, wd, dzu
In-Reply-To: <1278619839-23998-2-git-send-email-yanok@emcraft.com>
On Jul 8, 2010, at 3:10 PM, Ilya Yanok wrote:
> This patch adds the quirk for PCIE controller found on Freescale MPC8308.
> The quirk is the same as for other MPC83xx processors.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 1 +
> include/linux/pci_ids.h | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/2] mpc8308rdb: support for MPC8308RDB board from Freescale
From: Kumar Gala @ 2010-08-04 19:18 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, wd, dzu
In-Reply-To: <1278619839-23998-3-git-send-email-yanok@emcraft.com>
On Jul 8, 2010, at 3:10 PM, Ilya Yanok wrote:
> This patch adds support for MPC8308RDB development board from
> Freescale.
> Supported devices:
> DUART
> Dual Ethernet
> NOR and NAND flashes
> I2C
> USB in peripheral mode
>=20
> PCIE support is broken by the commit 3da34aa ("powerpc/fsl: Support
> unique MSI addresses per PCIe Root Complex"). Works after revert.
>=20
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/powerpc/boot/dts/mpc8308rdb.dts | 303 =
+++++++++++++++++++++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 8 +
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/mpc830x_rdb.c | 94 +++++++++
> 4 files changed, 406 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8308rdb.dts
> create mode 100644 arch/powerpc/platforms/83xx/mpc830x_rdb.c
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/2] tqm85xx: update PCI interrupt-map attribute
From: Kumar Gala @ 2010-08-04 19:21 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1279744404-10171-2-git-send-email-dbaryshkov@gmail.com>
On Jul 21, 2010, at 3:33 PM, Dmitry Eremin-Solenikov wrote:
> Update PCI IRQ mapping on TQM85xx platforms: include INTC and INTD on PCI-X
> slot and add INTA/INTB mapping for PCMCIA bridge.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/tqm8540.dts | 9 ++++++++-
> arch/powerpc/boot/dts/tqm8541.dts | 9 ++++++++-
> arch/powerpc/boot/dts/tqm8548-bigflash.dts | 9 ++++++++-
> arch/powerpc/boot/dts/tqm8548.dts | 9 ++++++++-
> arch/powerpc/boot/dts/tqm8555.dts | 9 ++++++++-
> arch/powerpc/boot/dts/tqm8560.dts | 9 ++++++++-
> 6 files changed, 48 insertions(+), 6 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/2] tqm85xx: add a quirk for ti1520 PCMCIA bridge
From: Kumar Gala @ 2010-08-04 19:21 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1279744404-10171-3-git-send-email-dbaryshkov@gmail.com>
On Jul 21, 2010, at 3:33 PM, Dmitry Eremin-Solenikov wrote:
> By default ti1520 bridge expects an input clock on CLOCK pin (to control
> power chip). However on this boards CLOCK should be generated by PCI1520
> itself. Add a quirk that enables internal 16 KHz clock generation on
> this pin.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/platforms/85xx/tqm85xx.c | 21 +++++++++++++++++++++
> 1 files changed, 21 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] [v2] powerpc: introduce basic support for the Freescale P1022DS reference board
From: Kumar Gala @ 2010-08-04 19:23 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1278109503-7604-1-git-send-email-timur@freescale.com>
On Jul 2, 2010, at 5:25 PM, Timur Tabi wrote:
> Introduce basic support for the Freescale P1022DS reference board, =
based on the
> Freescale BSP for this board. This patch excludes the DIU, SSI, and =
MMC/SD
> drivers. Only a 36-bit DTS is provided.
>=20
> Update mpc86xx_smp_defconfig and mpc85xx_defconfig to support the =
P1022DS.
> This means enabling 64-bit physical address support, increasing the =
maximum
> zone order to 12 (to allow the DIU driver to allocate large chunks), =
and
> clean up the audio options to disable the deprecated OSS support.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This patch is for 2.6.36.
>=20
> arch/powerpc/boot/dts/p1022ds.dts | 633 =
++++++++++++++++++++++++++++
> arch/powerpc/configs/mpc85xx_defconfig | 34 +-
> arch/powerpc/configs/mpc85xx_smp_defconfig | 34 +-
> arch/powerpc/platforms/85xx/Kconfig | 8 +
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/p1022_ds.c | 148 +++++++
> 6 files changed, 814 insertions(+), 44 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
> create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 2/2] tqm85xx: add a quirk for ti1520 PCMCIA bridge
From: Kumar Gala @ 2010-08-04 19:23 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1279744404-10171-3-git-send-email-dbaryshkov@gmail.com>
On Jul 21, 2010, at 3:33 PM, Dmitry Eremin-Solenikov wrote:
> By default ti1520 bridge expects an input clock on CLOCK pin (to control
> power chip). However on this boards CLOCK should be generated by PCI1520
> itself. Add a quirk that enables internal 16 KHz clock generation on
> this pin.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/platforms/85xx/tqm85xx.c | 21 +++++++++++++++++++++
> 1 files changed, 21 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH v2 1/2] DTS: Change deprecated binding for 85xx-based boards
From: Kumar Gala @ 2010-08-04 19:23 UTC (permalink / raw)
To: Bradley Hughes; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinaSEyVowG4103g5q-FmFMMMHuXJUeCV2oiSu5-@mail.gmail.com>
On Jul 21, 2010, at 5:04 PM, Bradley Hughes wrote:
> The "fsl,85..." style compatible binding was to be deprecated
> some time ago. This patch corrects existing occurrences of
> the incorrect binding. The memory-controller and
> l2-cache-controller are the only affected nodes.
>
> Signed-off-by: Bradley Hughes <bhughes@silicontkx.com>
> ---
> arch/powerpc/boot/dts/mpc8540ads.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8541cds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8544ds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8548cds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8555cds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8560ads.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8568mds.dts | 4 ++--
> 7 files changed, 14 insertions(+), 14 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH v2 0/2] Adding DTS for the STx GP3-SSA MPC8555 board
From: Kumar Gala @ 2010-08-04 19:23 UTC (permalink / raw)
To: Bradley Hughes; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimMb_PshxAIDvbfFdbCqHrlY13Qiz9g2eZ1vw1E@mail.gmail.com>
On Jul 21, 2010, at 5:04 PM, Bradley Hughes wrote:
> This version uses "fsl,mpc8555..." instead of "fsl,85..." notation.
>=20
> There is also an 8541 version of this board so DTS for this board
> is specific to the 8555 processor.
>=20
> Another patch is coming to fix-up other DTS that use old notation.
>=20
> Signed-off-by: Bradley Hughes <bhughes@silicontkx.com>
> ---
> arch/powerpc/boot/dts/stxssa8555.dts | 380 =
++++++++++++++++++++++++++++++++++
> 1 files changed, 380 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/stxssa8555.dts
applied to next
- k=
^ permalink raw reply
* Re: powerpc, 8xx: Add support for the MPC8xx based boards from TQC
From: Kumar Gala @ 2010-08-04 19:25 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4BA8744D.6030503@denx.de>
On Mar 23, 2010, at 2:57 AM, Heiko Schocher wrote:
> Supported SMC1 (serial console), SCC1 Ethernet (10Mbps HD).
> FEC Ethernet, 8MB NOR CFI Flash.
>=20
> Tested on STK8xx with TQM860L (with FEC)
> and with TQM855M (without FEC).
>=20
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> - based against =
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
> commit bca14dd14f3b0c5e3e2d1d314679f85b67871365
> - checked with checkpatch
> $ scripts/checkpatch.pl =
0001-powerpc-8xx-Add-support-for-the-MPC8xx-based-board.patch
> total: 0 errors, 0 warnings, 1278 lines checked
>=20
> 0001-powerpc-8xx-Add-support-for-the-MPC8xx-based-board.patch has no =
obvious style problems and is ready for submission.
> $
>=20
> arch/powerpc/boot/dts/tqm8xx.dts | 172 ++++++
> arch/powerpc/configs/tqm8xx_defconfig | 934 =
+++++++++++++++++++++++++++++
> arch/powerpc/platforms/8xx/Kconfig | 6 +
> arch/powerpc/platforms/8xx/Makefile | 1 +
> arch/powerpc/platforms/8xx/tqm8xx_setup.c | 156 +++++
> 5 files changed, 1269 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/tqm8xx.dts
> create mode 100644 arch/powerpc/configs/tqm8xx_defconfig
> create mode 100644 arch/powerpc/platforms/8xx/tqm8xx_setup.c
applied to next
- k=
^ permalink raw reply
* Re: [RT,RFC] Hacks allowing -rt to run on POWER7 / Powerpc.
From: Will Schmidt @ 2010-08-04 21:45 UTC (permalink / raw)
To: Milton Miller; +Cc: Darren Hart, rt-users, LKML, linuxppc-dev, Thomas Gleixner
In-Reply-To: <1278834594_17749@mail4.comsite.net>
On Sun, 2010-07-11 at 02:49 -0500, Milton Miller wrote:
> On Fri, 09 Jul 2010 about 08:55:01 -0000, Will Schmidt wrote:
> > We've been seeing some issues with userspace randomly SIGSEGV'ing while
> > running the -RT kernels on POWER7 based systems. After lots of
> > debugging, head scratching, and experimental changes to the code, the
> > problem has been narrowed down such that we can avoid the problems by
> > disabling the TLB batching.
> >
> > After some input from Ben and further debug, we've found that the
> > restoration of the batch->active value near the end of __switch_to()
> > seems to be the key. ( The -RT related changes within
> > arch/powerpc/kernel/processor.c __switch_to() do the equivalent of a
> > arch_leave_lazy_mmu_mode() before calling _switch, use a hadbatch flag
> > to indicate if batching was active, and then restore that batch->active
> > value on the way out after the call to _switch_to. That particular
> > code is in the -RT branch, and not found in mainline )
> >
> > Deferring to Ben (or others in the know) for whether this is the proper
> > solution or if there is something deeper, but..
I believe this is still on Ben's list of things to look at. Between
then and now, I'll see if I can get Thomas to pick this up for the -RT
tree to keep RT functional on P7 in the mean-time.
A bit more debug info below.
>
>
> I looked at the patch and noticed 2 changes:
> 1) the batch is checked and cleared after local_irq_save
> 2) enabling the batch is skipped
>
> I talked to Will and had him try moving the local_irq_save above the
> check for the active batch. That alone did not seem to be enough.
> However, he confirmed that we are setting batch to active when it is
> already active in lazy_mmu_enter, meaning that batching is being turned
> on recursively. I suggested debug to check that irqs are off after the
> restore when re-enabling when our debug session timed out.
Based on some of the debug suggestions from Milton:
A WARN_ON for (!irqs_disabled) after local_irq_restore() did not show
any hits. (while otherwise continuing to suffer from the tlb batching
troubles).
---><----
hard_irq_disable();
last = _switch(old_thread, new_thread);
local_irq_restore(flags);
WARN_ON(!irqs_disabled()); <<<<----------
#if defined(CONFIG_PPC64) && defined(CONFIG_PREEMPT_RT) && 1
if (hadbatch) {
batch = &__get_cpu_var(ppc64_tlb_batch);
batch->active = 1;
}
#endif
----><----
Another assortment of WARN_ONs in the arch_{enter,leave}_lazy_mmu_mode
functions. As Milton stated above, the check for batch->active on the
way into the arch_enter_* function did generate lots of hits, the other
warn_ons did not.
-----><-------
static inline void arch_enter_lazy_mmu_mode(void)
{
struct ppc64_tlb_batch *batch = &get_cpu_var(ppc64_tlb_batch);
//|-----WARN_ON(batch->active); /* lots of hits if enabled */
|-------WARN_ON(irqs_disabled()); /* nothing.... */
|-------batch->active = 1;
....
static inline void arch_leave_lazy_mmu_mode(void)
{
|-------struct ppc64_tlb_batch *batch = &get_cpu_var(ppc64_tlb_batch);
|-------WARN_ON(!batch->active); /* nothing.....*/
|-------WARN_ON(irqs_disabled()); /* nothing.... */
....
>
> milton
>
> >
> > diff -aurp linux-2.6.33.5-rt23.orig/arch/powerpc/kernel/process.c linux-2.6.33.5-rt23.exp/arch/powerpc/kernel/process.c
> > --- linux-2.6.33.5-rt23.orig/arch/powerpc/kernel/process.c 2010-06-21 11:41:34.402513904 -0500
> > +++ linux-2.6.33.5-rt23.exp/arch/powerpc/kernel/process.c 2010-07-09 13:15:13.533269904 -0500
> > @@ -304,10 +304,6 @@ struct task_struct *__switch_to(struct t
> > struct thread_struct *new_thread, *old_thread;
> > unsigned long flags;
> > struct task_struct *last;
> > -#if defined(CONFIG_PPC64) && defined (CONFIG_PREEMPT_RT)
> > - struct ppc64_tlb_batch *batch;
> > - int hadbatch;
> > -#endif
> >
> > #ifdef CONFIG_SMP
> > /* avoid complexity of lazy save/restore of fpu
> > @@ -401,16 +397,6 @@ struct task_struct *__switch_to(struct t
> > new_thread->start_tb = current_tb;
> > }
> >
> > -#ifdef CONFIG_PREEMPT_RT
> > - batch = &__get_cpu_var(ppc64_tlb_batch);
> > - if (batch->active) {
> > - hadbatch = 1;
> > - if (batch->index) {
> > - __flush_tlb_pending(batch);
> > - }
> > - batch->active = 0;
> > - }
> > -#endif /* #ifdef CONFIG_PREEMPT_RT */
> > #endif
> >
> > local_irq_save(flags);
> > @@ -425,16 +411,13 @@ struct task_struct *__switch_to(struct t
> > * of sync. Hard disable here.
> > */
> > hard_irq_disable();
> > - last = _switch(old_thread, new_thread);
> > -
> > - local_irq_restore(flags);
> >
> > #if defined(CONFIG_PPC64) && defined(CONFIG_PREEMPT_RT)
> > - if (hadbatch) {
> > - batch = &__get_cpu_var(ppc64_tlb_batch);
> > - batch->active = 1;
> > - }
> > + arch_leave_lazy_mmu_mode();
> > #endif
> > + last = _switch(old_thread, new_thread);
> > +
> > + local_irq_restore(flags);
> >
> > return last;
> > }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 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
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2010-08-04 22:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
The following changes since commit e8e5c2155b0035b6e04f29be67f6444bc914005b:
Matt Evans (1):
powerpc/kexec: Fix orphaned offline CPUs across kexec
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Anton Vorontsov (3):
powerpc/85xx: Fix SWIOTLB initalization for MPC85xxMDS boards
powerpc/85xx: Fix booting for P1021MDS boards
powerpc/85xx: Cleanup QE initialization for MPC85xxMDS boards
Bradley Hughes (2):
powerpc/85xx: Change deprecated binding for 85xx-based boards
powerpc/85xx: Adding DTS for the STx GP3-SSA MPC8555 board
Dmitry Eremin-Solenikov (2):
powerpc/tqm85xx: update PCI interrupt-map attribute
powerpc/tqm85xx: add a quirk for ti1520 PCMCIA bridge
Heiko Schocher (1):
powerpc/8xx: Add support for the MPC8xx based boards from TQC
Ilya Yanok (2):
powerpc/fsl_pci: add quirk for mpc8308 pcie bridge
powerpc/mpc8308rdb: support for MPC8308RDB board from Freescale
Matthew McClintock (1):
powerpc/85xx: kexec for SMP 85xx BookE systems
Timur Tabi (1):
powerpc/85xx: Introduce support for the Freescale P1022DS reference board
arch/powerpc/Kconfig | 10 +-
arch/powerpc/boot/dts/mpc8308rdb.dts | 303 +++++++++
arch/powerpc/boot/dts/mpc8540ads.dts | 4 +-
arch/powerpc/boot/dts/mpc8541cds.dts | 4 +-
arch/powerpc/boot/dts/mpc8544ds.dts | 4 +-
arch/powerpc/boot/dts/mpc8548cds.dts | 4 +-
arch/powerpc/boot/dts/mpc8555cds.dts | 4 +-
arch/powerpc/boot/dts/mpc8560ads.dts | 4 +-
arch/powerpc/boot/dts/mpc8568mds.dts | 4 +-
arch/powerpc/boot/dts/p1021mds.dts | 1 +
arch/powerpc/boot/dts/p1022ds.dts | 633 +++++++++++++++++++
arch/powerpc/boot/dts/stxssa8555.dts | 380 +++++++++++
arch/powerpc/boot/dts/tqm8540.dts | 9 +-
arch/powerpc/boot/dts/tqm8541.dts | 9 +-
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 9 +-
arch/powerpc/boot/dts/tqm8548.dts | 9 +-
arch/powerpc/boot/dts/tqm8555.dts | 9 +-
arch/powerpc/boot/dts/tqm8560.dts | 9 +-
arch/powerpc/boot/dts/tqm8xx.dts | 172 +++++
arch/powerpc/configs/mpc85xx_defconfig | 34 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 34 +-
arch/powerpc/configs/tqm8xx_defconfig | 934 ++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/Kconfig | 8 +
arch/powerpc/platforms/83xx/Makefile | 1 +
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 94 +++
arch/powerpc/platforms/85xx/Kconfig | 8 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 279 +++++----
arch/powerpc/platforms/85xx/p1022_ds.c | 148 +++++
arch/powerpc/platforms/85xx/smp.c | 63 ++
arch/powerpc/platforms/85xx/tqm85xx.c | 21 +
arch/powerpc/platforms/8xx/Kconfig | 6 +
arch/powerpc/platforms/8xx/Makefile | 1 +
arch/powerpc/platforms/8xx/tqm8xx_setup.c | 156 +++++
arch/powerpc/sysdev/fsl_pci.c | 1 +
include/linux/pci_ids.h | 1 +
36 files changed, 3185 insertions(+), 186 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8308rdb.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
create mode 100644 arch/powerpc/boot/dts/stxssa8555.dts
create mode 100644 arch/powerpc/boot/dts/tqm8xx.dts
create mode 100644 arch/powerpc/configs/tqm8xx_defconfig
create mode 100644 arch/powerpc/platforms/83xx/mpc830x_rdb.c
create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c
create mode 100644 arch/powerpc/platforms/8xx/tqm8xx_setup.c
^ permalink raw reply
* [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
From: Timur Tabi @ 2010-08-04 22:51 UTC (permalink / raw)
To: alsa-devel, linuxppc-dev, lrg, broonie, kumar.gala
Add support for adding "status = disabled" to an SSI node to incidate that it
is not wired on the board. This replaces the not-so-intuitive previous method
of omitting a codec-handle property.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
Kumar, would you please ACK the device-tree portion of this patch? I want
it to go through the ALSA tree.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 1 +
sound/soc/fsl/fsl_ssi.c | 13 ++++++++++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 9535ce6..83c3218 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -286,6 +286,7 @@
ssi@16100 {
compatible = "fsl,mpc8610-ssi";
+ status = "disabled";
cell-index = <1>;
reg = <0x16100 0x100>;
interrupt-parent = <&mpic>;
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index a0e18b8..45d27b1 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -636,12 +636,19 @@ static int __devinit fsl_ssi_probe(struct of_device *of_dev,
struct resource res;
char name[64];
- /* We are only interested in SSIs with a codec phandle in them, so let's
- * make sure this SSI has one.
+ /* SSIs that are not connected on the board should have a
+ * status = "disabled"
+ * property in their device tree nodes.
*/
- if (!of_get_property(np, "codec-handle", NULL))
+ if (!of_device_is_available(np))
return -ENODEV;
+ /* Check for a codec-handle property. */
+ if (!of_get_property(np, "codec-handle", NULL)) {
+ dev_err(&of_dev->dev, "missing codec-handle property\n");
+ return -ENODEV;
+ }
+
/* We only support the SSI in "I2S Slave" mode */
sprop = of_get_property(np, "fsl,mode", NULL);
if (!sprop || strcmp(sprop, "i2s-slave")) {
--
1.7.0.1
^ permalink raw reply related
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