* 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 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 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: 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: 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: 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: [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: 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][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: 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
* 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: 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
* [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: [PATCH 2/3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-08-04 3:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Lan Chunhe-B25806, linuxppc-dev, Gala Kumar-B11780
In-Reply-To: <CB6DDAC6-620C-4FF1-B006-3E4F3E7A4E17@kernel.crashing.org>
=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Tuesday, August 03, 2010 20:58 PM
> To: Zang Roy-R61911
> Cc: linuxppc-dev@ozlabs.org list; Lan Chunhe-B25806; Gala Kumar-B11780
> Subject: Re: [PATCH 2/3] P4080/mtd: Only make elbc nand=20
> driver detect nand flash partitions
>=20
>=20
> On Aug 2, 2010, at 11:45 PM, Roy Zang wrote:
>=20
> > From: Lan Chunhe-B25806 <b25806@freescale.com>
> >=20
> > The former driver had the two functions:
> >=20
> > 1. detecting nand flash partitions;
> > 2. registering elbc interrupt.
> >=20
> > Now, second function is removed to fsl_lbc.c.
> >=20
> > Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > ---
> > drivers/mtd/nand/Kconfig | 1 +
> > drivers/mtd/nand/fsl_elbc_nand.c | 464=20
> ++++++++++++++------------------------
> > 2 files changed, 170 insertions(+), 295 deletions(-)
>=20
> mtd list and maintainer should be CC'd on these.
Make sense.
I will forward these patch to mtd list.
Thanks.
Roy
^ permalink raw reply
* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-04 2:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-mmc
In-Reply-To: <20100803164346.69a63557.akpm@linux-foundation.org>
=20
> -----Original Message-----
> From: Andrew Morton [mailto:akpm@linux-foundation.org]=20
> Sent: Wednesday, August 04, 2010 7:44 AM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> On Tue, 3 Aug 2010 11:11:10 +0800
> Roy Zang <tie-fei.zang@freescale.com> wrote:
>=20
> > --- a/drivers/mmc/host/sdhci.h
> > +++ b/drivers/mmc/host/sdhci.h
> > @@ -240,6 +240,8 @@ struct sdhci_host {
> > #define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (1<<25)
> > /* Controller cannot support End Attribute in NOP ADMA=20
> descriptor */
> > #define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
> > +/* Controller uses Auto CMD12 command to stop the transfer */
> > +#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
>=20
> This becomes 1<<29 in my tree.
It also works.
>=20
> We're about to run out. =20
:-(
>What happens then?
Rewrite the code to extend some bits, I suppose.
Roy
^ permalink raw reply
* Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Andrew Morton @ 2010-08-03 23:43 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, linux-mmc
In-Reply-To: <1280805072-26112-1-git-send-email-tie-fei.zang@freescale.com>
On Tue, 3 Aug 2010 11:11:10 +0800
Roy Zang <tie-fei.zang@freescale.com> wrote:
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -240,6 +240,8 @@ struct sdhci_host {
> #define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (1<<25)
> /* Controller cannot support End Attribute in NOP ADMA descriptor */
> #define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
> +/* Controller uses Auto CMD12 command to stop the transfer */
> +#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
This becomes 1<<29 in my tree.
We're about to run out. What happens then?
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Optimise 64bit csum_partial
From: Segher Boessenkool @ 2010-08-03 23:39 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20100803231114.GP29316@kryten>
>
> Hi Segher,
>
>> Not really. Do you know how many 16/32-bit words you can add before a
>> 64-bit register can overflow? :-)
>
> Thats a very good point. I thought about using 32bit adds when writing
> the copy and checksum routine, but came to the conclusion that it wouldn't
> go
> any faster than one using addes.
Well, you now have one 64-bit word in two cycles, using one load and
an adde.
You can do 64-bits with two loads and two integer insns instead, or
one load and three integer insns. It depends on your pipeline structure
what is best, I don't remember what POWER6/7 have exactly, but I bet
you do :-)
If you don't have to deal with the carry, you don't have to care about
the latency of your insns either, since you can just software pipeline it.
> The checksum only routine was the same
> loop
> without the stores.
The stores are just to copy, right? So two loads/two stores/two integer
(per 64-bit), which probably works out to two cycles; or one load/
one store/ three integer, which is one or one and a half cycle.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/kdump: Stop all other CPUs before running crash handlers
From: Matt Evans @ 2010-08-03 23:12 UTC (permalink / raw)
To: Anton Blanchard; +Cc: mikey, linuxppc-dev
In-Reply-To: <20100803063941.GM29316@kryten>
Anton Blanchard wrote:
> During kdump we run the crash handlers first then stop all other CPUs.
> We really want to stop all CPUs as close to the fail as possible and also
> have a very controlled environment for running the crash handlers, so it
> makes sense to reverse the order.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Looks like a sensible idea!
Acked-by: Matt Evans <matt@ozlabs.org>
> ---
>
> Index: powerpc.git/arch/powerpc/kernel/crash.c
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/kernel/crash.c 2010-07-15 20:49:39.941991306 +1000
> +++ powerpc.git/arch/powerpc/kernel/crash.c 2010-08-03 16:36:08.451991018 +1000
> @@ -402,6 +402,18 @@ void default_machine_crash_shutdown(stru
> */
> hard_irq_disable();
>
> + /*
> + * Make a note of crashing cpu. Will be used in machine_kexec
> + * such that another IPI will not be sent.
> + */
> + crashing_cpu = smp_processor_id();
> + crash_save_cpu(regs, crashing_cpu);
> + crash_kexec_prepare_cpus(crashing_cpu);
> + cpu_set(crashing_cpu, cpus_in_crash);
> +#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
> + crash_kexec_wait_realmode(crashing_cpu);
> +#endif
> +
> for_each_irq(i) {
> struct irq_desc *desc = irq_to_desc(i);
>
> @@ -438,18 +450,8 @@ void default_machine_crash_shutdown(stru
> crash_shutdown_cpu = -1;
> __debugger_fault_handler = old_handler;
>
> - /*
> - * Make a note of crashing cpu. Will be used in machine_kexec
> - * such that another IPI will not be sent.
> - */
> - crashing_cpu = smp_processor_id();
> - crash_save_cpu(regs, crashing_cpu);
> - crash_kexec_prepare_cpus(crashing_cpu);
> - cpu_set(crashing_cpu, cpus_in_crash);
> crash_kexec_stop_spus();
> -#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
> - crash_kexec_wait_realmode(crashing_cpu);
> -#endif
> +
> if (ppc_md.kexec_cpu_down)
> ppc_md.kexec_cpu_down(1, 0);
> }
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Optimise 64bit csum_partial
From: Anton Blanchard @ 2010-08-03 23:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: paulus, linuxppc-dev
In-Reply-To: <1C2B156C-E6C9-47CC-B5BF-6AA603581EC3@kernel.crashing.org>
Hi Segher,
> Not really. Do you know how many 16/32-bit words you can add before a
> 64-bit register can overflow? :-)
Thats a very good point. I thought about using 32bit adds when writing
the copy and checksum routine, but came to the conclusion that it wouldn't go
any faster than one using addes. The checksum only routine was the same loop
without the stores.
We rarely use csum_partial now we have copy and checksum to and from user
now, but I'll take a look at speeding it up in a follow on patch. Thanks!
Anton
^ permalink raw reply
* Re: [PATCH 8/9] arch/powerpc/kernel: Drop unnecessary null test
From: Grant Likely @ 2010-08-03 22:00 UTC (permalink / raw)
To: Dan Carpenter, Julia Lawall, Benjamin Herrenschmidt,
Paul Mackerras, Grant Likely, linuxppc-dev, linux-kernel,
devicetree-discuss, kernel-janitors
In-Reply-To: <20100803215137.GU26313@bicker>
On Tue, Aug 3, 2010 at 3:51 PM, Dan Carpenter <error27@gmail.com> wrote:
> On Tue, Aug 03, 2010 at 11:35:17PM +0200, Julia Lawall wrote:
>> diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci=
_of_scan.c
>> index 6ddb795..62dd363 100644
>> --- a/arch/powerpc/kernel/pci_of_scan.c
>> +++ b/arch/powerpc/kernel/pci_of_scan.c
>> @@ -336,8 +336,7 @@ static void __devinit __of_scan_bus(struct device_no=
de *node,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (dev->hdr_type =3D=3D PCI_HEADER_TYPE_BRI=
DGE ||
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev->hdr_type =3D=3D PCI_HEADER_TYPE=
_CARDBUS) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct device_node *child =
=3D pci_device_to_OF_node(dev);
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (dev)
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_scan_pci_br=
idge(child, dev);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_scan_pci_bridge(child, dev)=
;
>
> The intention was probably to check "child" instead of "dev".
> pci_device_to_OF_node() can return NULL. =A0On the other hand the code
> has been this way for a year and no one has complained...
Still, it should be fixed. It is likely that I'll be generalizing
this code for other architectures in the near future. I'll spin a
patch.
g.
^ permalink raw reply
* Re: [PATCH 8/9] arch/powerpc/kernel: Drop unnecessary null test
From: Dan Carpenter @ 2010-08-03 21:51 UTC (permalink / raw)
To: Julia Lawall
Cc: devicetree-discuss, kernel-janitors, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.1008032334420.20393@ask.diku.dk>
On Tue, Aug 03, 2010 at 11:35:17PM +0200, Julia Lawall wrote:
> diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
> index 6ddb795..62dd363 100644
> --- a/arch/powerpc/kernel/pci_of_scan.c
> +++ b/arch/powerpc/kernel/pci_of_scan.c
> @@ -336,8 +336,7 @@ static void __devinit __of_scan_bus(struct device_node *node,
> if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
> dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
> struct device_node *child = pci_device_to_OF_node(dev);
> - if (dev)
> - of_scan_pci_bridge(child, dev);
> + of_scan_pci_bridge(child, dev);
The intention was probably to check "child" instead of "dev".
pci_device_to_OF_node() can return NULL. On the other hand the code
has been this way for a year and no one has complained...
regards,
dan carpenter
> }
> }
> }
^ permalink raw reply
* [PATCH 8/9] arch/powerpc/kernel: Drop unnecessary null test
From: Julia Lawall @ 2010-08-03 21:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Grant Likely,
linuxppc-dev, linux-kernel, devicetree-discuss, kernel-janitors
From: Julia Lawall <julia@diku.dk>
list_for_each_entry binds its first argument to a non-null value, and thus
any null test on the value of that argument is superfluous.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
iterator I;
expression x,E,E1,E2;
statement S,S1,S2;
@@
I(x,...) { <...
- if (x != NULL || ...)
S
...> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/kernel/pci_of_scan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 6ddb795..62dd363 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -336,8 +336,7 @@ static void __devinit __of_scan_bus(struct device_node *node,
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
struct device_node *child = pci_device_to_OF_node(dev);
- if (dev)
- of_scan_pci_bridge(child, dev);
+ of_scan_pci_bridge(child, dev);
}
}
}
^ permalink raw reply related
* [PATCH 4/9] arch/powerpc/platforms/powermac: Drop unnecessary null test
From: Julia Lawall @ 2010-08-03 21:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Grant Likely,
linuxppc-dev, linux-kernel, devicetree-discuss, kernel-janitors
From: Julia Lawall <julia@diku.dk>
for_each_node_by_name binds its first argument to a non-null value, and
thus any null test on the value of that argument is superfluous.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
iterator I;
expression x,E;
@@
I(x,...) { <...
(
- (x != NULL) &&
E
...> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/platforms/powermac/feature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index 9e1b9fd..537957b 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2867,7 +2867,7 @@ set_initial_features(void)
/* Switch airport off */
for_each_node_by_name(np, "radio") {
- if (np && np->parent == macio_chips[0].of_node) {
+ if (np->parent == macio_chips[0].of_node) {
macio_chips[0].flags |= MACIO_FLAG_AIRPORT_ON;
core99_airport_enable(np, 0, 0);
}
^ permalink raw reply related
* [PATCH] arch/powerpc: Drop unnecessary of_node_put
From: Julia Lawall @ 2010-08-03 19:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Grant Likely,
linuxppc-dev, linux-kernel, devicetree-discuss, kernel-janitors
From: Julia Lawall <julia@diku.dk>
for_each_node_by_name only exits when its first argument is NULL, and a
subsequent call to of_node_put on that argument is unnecessary.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
iterator name for_each_node_by_name;
expression np,E;
identifier l;
@@
for_each_node_by_name(np,...) {
... when != break;
when != goto l;
}
... when != np = E
- of_node_put(np);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/platforms/powermac/feature.c | 1 -
arch/powerpc/platforms/powermac/pci.c | 2 --
2 files changed, 3 deletions(-)
diff -u -p a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2872,7 +2872,6 @@ set_initial_features(void)
core99_airport_enable(np, 0, 0);
}
}
- of_node_put(np);
}
/* On all machines that support sound PM, switch sound off */
diff -u -p a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -1155,13 +1155,11 @@ void __init pmac_pcibios_after_init(void
pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, nd, 0, 0);
}
}
- of_node_put(nd);
for_each_node_by_name(nd, "ethernet") {
if (nd->parent && of_device_is_compatible(nd, "gmac")
&& of_device_is_compatible(nd->parent, "uni-north"))
pmac_call_feature(PMAC_FTR_GMAC_ENABLE, nd, 0, 0);
}
- of_node_put(nd);
}
void pmac_pci_fixup_cardbus(struct pci_dev* dev)
^ permalink raw reply
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Wolfgang Denk @ 2010-08-03 19:11 UTC (permalink / raw)
To: galak, Kim Phillips; +Cc: linuxppc-dev, Ilya Yanok
In-Reply-To: <20100729212043.4258C152397@gemini.denx.de>
Hello Kumar, hello Kim,
can you _please_ comment? Thanks.
In message <20100729212043.4258C152397@gemini.denx.de> I wrote:
> Dear Kumar & Kim,
>
> any comments on this issue?
>
> Thanks.
>
> In message <4C48B384.1020006@emcraft.com> Ilya Yanok wrote:
> > Hi Kumar, Kim, Josh, everybody,
> >
> > I hope to disturb you but I haven't got any reply for my first posting...
> >
> > I've found that MSI work correctly with older kernels on my MPC8308RDB
> > board and don't work with newer ones. After bisecting I've found that
> > the source of the problem is commit 3da34aa:
> >
> > commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> > Author: Kumar Gala <galak@kernel.crashing.org>
> > Date: Tue May 12 15:51:56 2009 -0500
> >
> > powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
> >
> > Its feasible based on how the PCI address map is setup that the region
> > of PCI address space used for MSIs differs for each PHB on the same SoC.
> >
> > Instead of assuming that the address mappes to CCSRBAR 1:1 we read
> > PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on.
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> >
> > I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx
> > neigher in the kernel nor in U-Boot (that makes me think that all 83xx
> > can be affected).
> > I'm not actually an PCI expert so I've just tried to write IMMR base
> > address to the BAR0 register from the U-Boot to get the correct address
> > but this doesn't help.
> > Please direct me how to init 83xx PCIE controller to make it compatible
> > with this patch.
> >
> > Kim, I think MPC8315E is affected too, could you please test it?
> >
> > Thanks in advance.
> >
> > Regards, Ilya.
>
> Best regards,
>
> Wolfgang Denk
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In the beginning, there was nothing, which exploded.
- Terry Pratchett, _Lords and Ladies_
^ 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