* Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Scott Wood @ 2011-12-08 18:00 UTC (permalink / raw)
To: Liu Shengzhou-B36685
Cc: Wood Scott-B07421, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <3F453DDFF675A64A89321A1F352810216B089C@039-SN1MPN1-005.039d.mgd.msft.net>
On 12/07/2011 09:36 PM, Liu Shengzhou-B36685 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Thursday, December 08, 2011 1:17 AM
>> To: Liu Shengzhou-B36685
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
>> mtd@lists.infradead.org; dwmw2@infradead.org; Gala Kumar-B11780
>> Subject: Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of
>> Freescale NAND controller
>>
>> On 12/07/2011 12:30 AM, Liu Shengzhou-B36685 wrote:
>>> [Shengzhou] This patch doesn't change the way ECCM is handled, it's
>> still same as before, just make sure CWTO timeout is set to maximum.
>>
>> It does change it. It used to use the existing value in FMR, and now it
>> sets it based on ORn[PGS].
>>
>> -Scott
>
> [Shengzhou]
> In u-boot:
> #ifdef CONFIG_FSL_ELBC_FMR
> priv->fmr = CONFIG_FSL_ELBC_FMR;
> #else
> priv->fmr = (15 << FMR_CWTO_SHIFT) | (2 << FMR_AL_SHIFT);
> or = in_be32(&elbc_ctrl->regs->bank[priv->bank].or);
> if (or & OR_FCM_PGS)
> priv->fmr |= FMR_ECCM;
> #endif
>
> In kernel: It used to be " priv->fmr = in_be32(&lbc->fmr) & FMR_ECCM
> ", so fmr was always 0x100(or 0,depend on ORn[PGS]), CWTO was
> 0(timeout was minimum). In this patch, for not relying on
> bootloader, fmr is initialized as what u-boot does, except
> FMR_AL_SHIFT is handled in fsl_elbc_chip_init_tail and without
> definition of CONFIG_FSL_ELBC_FMR.
>
> So, it doesn't change it.
You're assuming that the above U-Boot code is always run. This depends
on whether the NAND driver is enabled in U-Boot.
In the future, though, it might also depend on whether a NAND command is
actually run in U-Boot -- this makes the setting of FMR
non-deterministic between boots, which is worse than a one-time breakage
of an unusual setup (driver not enabled in U-Boot at all).
So it is a change, but I now think it's a change we should make. The
changelog should mention that this is happening, though.
> Do we still need CONFIG_FSL_ELBC_FMR in kernel?
We do not want such a compile-time constant in the kernel. Use ORn[PGS]
as the patch currently does.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-08 18:43 UTC (permalink / raw)
To: LiuShuo
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EE09526.5040705@freescale.com>
On 12/08/2011 04:44 AM, LiuShuo wrote:
> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8808=E6=97=A5 03:11, Scott Wood =E5=86=99=
=E9=81=93:
>> And if we do want to make such assumptions, we could rip out all usage
>> of index/column here, and just handle "oob" and "full page" cases.
> The function nand_do_write_ops() in nandbase.c is a Nand internal
> interface.
> It always is called when application write to nand flash. (e.g. dd)
> In this function, partial page write is dealt with by filling '0xff' to
> buffer before data copy.
> (nand_do_write_oob() is similar)
> So I don't think we need to do it in our controller driver again, it
> should be a job of upper layer.
If this is to be considered part of the interface contract, then perhaps
do a WARN_ON() if we see an unexpected index/column? And after that,
only consider full-page or full-oob possibilities.
-Scott
^ permalink raw reply
* [linux-3.2-rc4 PPC64] Series of "Section Mismatch" warnings, are they expected ?
From: Subrata Modak @ 2011-12-08 19:10 UTC (permalink / raw)
To: Linuxppc-dev
Cc: Mark Wizner, Naveed, LKML, Manas k Nayak, Pavaman, Vishu,
divya.vikas
Hello,
While compiling linux-3.2-rc4 on PPC64, i get the following set of
warning series. I wanted to know if they are expected, or, they need to
be fixed:
LD arch/powerpc/sysdev/xics/built-in.o
WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x136c): Section
mismatch in reference from the function .ics_rtas_init() to the
function .init.text:.xics_register_ics()
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.
LD arch/powerpc/sysdev/built-in.o
WARNING: arch/powerpc/sysdev/built-in.o(.text+0x99d4): Section mismatch
in reference from the function .ics_rtas_init() to the
function .init.text:.xics_register_ics()
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x29914): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.call_prom()
The function .prom_query_opal() references
the function __init .call_prom().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .call_prom is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x2993c): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.call_prom()
The function .prom_query_opal() references
the function __init .call_prom().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .call_prom is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x2994c): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.prom_printf()
The function .prom_query_opal() references
the function __init .prom_printf().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x299a8): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.prom_printf()
The function .prom_query_opal() references
the function __init .prom_printf().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x299cc): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.prom_printf()
The function .prom_query_opal() references
the function __init .prom_printf().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x29d00): Section mismatch
in reference from the function .prom_opal_takeover() to the
function .init.text:.prom_printf()
The function .prom_opal_takeover() references
the function __init .prom_printf().
This is often because .prom_opal_takeover lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x29d04): Section mismatch
in reference from the function .prom_opal_takeover() to the
function .init.text:.prom_close_stdin()
The function .prom_opal_takeover() references
the function __init .prom_close_stdin().
This is often because .prom_opal_takeover lacks a __init
annotation or the annotation of .prom_close_stdin is wrong.
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x90be): Section mismatch in reference from the
variable generic_secondary_common_init to the
variable .init.data:spinning_secondaries
The function generic_secondary_common_init() references
the variable __initdata spinning_secondaries.
This is often because generic_secondary_common_init lacks a __initdata
annotation or the annotation of spinning_secondaries is wrong.
WARNING: vmlinux.o(.text+0x93e4): Section mismatch in reference from the
function .start_secondary_prolog() to the
function .devinit.text:.start_secondary()
The function .start_secondary_prolog() references
the function __devinit .start_secondary().
This is often because .start_secondary_prolog lacks a __devinit
annotation or the annotation of .start_secondary is wrong.
WARNING: vmlinux.o(.text+0x93f8): Section mismatch in reference from the
function .start_secondary_resume() to the
function .devinit.text:.start_secondary()
The function .start_secondary_resume() references
the function __devinit .start_secondary().
This is often because .start_secondary_resume lacks a __devinit
annotation or the annotation of .start_secondary is wrong.
WARNING: vmlinux.o(.text+0x23034): Section mismatch in reference from
the function .early_setup_secondary() to the
function .cpuinit.text:.early_init_mmu_secondary()
The function .early_setup_secondary() references
the function __cpuinit .early_init_mmu_secondary().
This is often because .early_setup_secondary lacks a __cpuinit
annotation or the annotation of .early_init_mmu_secondary is wrong.
WARNING: vmlinux.o(.text+0x349ac): Section mismatch in reference from
the function .prom_query_opal() to the function .init.text:.call_prom()
The function .prom_query_opal() references
the function __init .call_prom().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .call_prom is wrong.
WARNING: vmlinux.o(.text+0x349d4): Section mismatch in reference from
the function .prom_query_opal() to the function .init.text:.call_prom()
The function .prom_query_opal() references
the function __init .call_prom().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .call_prom is wrong.
WARNING: vmlinux.o(.text+0x349e4): Section mismatch in reference from
the function .prom_query_opal() to the
function .init.text:.prom_printf()
The function .prom_query_opal() references
the function __init .prom_printf().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: vmlinux.o(.text+0x34a40): Section mismatch in reference from
the function .prom_query_opal() to the
function .init.text:.prom_printf()
The function .prom_query_opal() references
the function __init .prom_printf().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: vmlinux.o(.text+0x34a64): Section mismatch in reference from
the function .prom_query_opal() to the
function .init.text:.prom_printf()
The function .prom_query_opal() references
the function __init .prom_printf().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: vmlinux.o(.text+0x34d98): Section mismatch in reference from
the function .prom_opal_takeover() to the
function .init.text:.prom_printf()
The function .prom_opal_takeover() references
the function __init .prom_printf().
This is often because .prom_opal_takeover lacks a __init
annotation or the annotation of .prom_printf is wrong.
WARNING: vmlinux.o(.text+0x34d9c): Section mismatch in reference from
the function .prom_opal_takeover() to the
function .init.text:.prom_close_stdin()
The function .prom_opal_takeover() references
the function __init .prom_close_stdin().
This is often because .prom_opal_takeover lacks a __init
annotation or the annotation of .prom_close_stdin is wrong.
WARNING: vmlinux.o(.text+0x3b024): Section mismatch in reference from
the function .kexec_prepare_cpus() to the
function .cpuinit.text:.cpu_up()
The function .kexec_prepare_cpus() references
the function __cpuinit .cpu_up().
This is often because .kexec_prepare_cpus lacks a __cpuinit
annotation or the annotation of .cpu_up is wrong.
WARNING: vmlinux.o(.text+0x4c760): Section mismatch in reference from
the function .mark_reserved_regions_for_nid() to the
function .meminit.text:.early_pfn_to_nid()
The function .mark_reserved_regions_for_nid() references
the function __meminit .early_pfn_to_nid().
This is often because .mark_reserved_regions_for_nid lacks a __meminit
annotation or the annotation of .early_pfn_to_nid is wrong.
WARNING: vmlinux.o(.text+0x4c780): Section mismatch in reference from
the function .mark_reserved_regions_for_nid() to the
function .init.text:.work_with_active_regions()
The function .mark_reserved_regions_for_nid() references
the function __init .work_with_active_regions().
This is often because .mark_reserved_regions_for_nid lacks a __init
annotation or the annotation of .work_with_active_regions is wrong.
WARNING: vmlinux.o(.text+0x4c7d4): Section mismatch in reference from
the function .mark_reserved_regions_for_nid() to the
function .meminit.text:.early_pfn_to_nid()
The function .mark_reserved_regions_for_nid() references
the function __meminit .early_pfn_to_nid().
This is often because .mark_reserved_regions_for_nid lacks a __meminit
annotation or the annotation of .early_pfn_to_nid is wrong.
WARNING: vmlinux.o(.text+0x4c7f0): Section mismatch in reference from
the function .mark_reserved_regions_for_nid() to the
function .init.text:.work_with_active_regions()
The function .mark_reserved_regions_for_nid() references
the function __init .work_with_active_regions().
This is often because .mark_reserved_regions_for_nid lacks a __init
annotation or the annotation of .work_with_active_regions is wrong.
WARNING: vmlinux.o(.text+0x4c828): Section mismatch in reference from
the function .mark_reserved_regions_for_nid() to the
function .init.text:.reserve_bootmem_node()
The function .mark_reserved_regions_for_nid() references
the function __init .reserve_bootmem_node().
This is often because .mark_reserved_regions_for_nid lacks a __init
annotation or the annotation of .reserve_bootmem_node is wrong.
WARNING: vmlinux.o(.text+0x5ba24): Section mismatch in reference from
the function .ics_rtas_init() to the
function .init.text:.xics_register_ics()
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.
WARNING: vmlinux.o(.text+0x6e3ec): Section mismatch in reference from
the function .pci_dn_reconfig_notifier() to the
function .devinit.text:.update_dn_pci_info()
The function .pci_dn_reconfig_notifier() references
the function __devinit .update_dn_pci_info().
This is often because .pci_dn_reconfig_notifier lacks a __devinit
annotation or the annotation of .update_dn_pci_info is wrong.
WARNING: vmlinux.o(.text+0x71f28): Section mismatch in reference from
the function .dlpar_online_cpu() to the function .cpuinit.text:.cpu_up()
The function .dlpar_online_cpu() references
the function __cpuinit .cpu_up().
This is often because .dlpar_online_cpu lacks a __cpuinit
annotation or the annotation of .cpu_up is wrong.
WARNING: vmlinux.o(.text+0x77248): Section mismatch in reference from
the function .pcibios_add_pci_devices() to the
function .devinit.text:.pcibios_setup_bus_devices()
The function .pcibios_add_pci_devices() references
the function __devinit .pcibios_setup_bus_devices().
This is often because .pcibios_add_pci_devices lacks a __devinit
annotation or the annotation of .pcibios_setup_bus_devices is wrong.
WARNING: vmlinux.o(.text+0x77298): Section mismatch in reference from
the function .pcibios_add_pci_devices() to the
function .devinit.text:.pci_scan_bridge()
The function .pcibios_add_pci_devices() references
the function __devinit .pci_scan_bridge().
This is often because .pcibios_add_pci_devices lacks a __devinit
annotation or the annotation of .pci_scan_bridge is wrong.
WARNING: vmlinux.o(.text+0x772d0): Section mismatch in reference from
the function .pcibios_add_pci_devices() to the
function .devinit.text:.of_rescan_bus()
The function .pcibios_add_pci_devices() references
the function __devinit .of_rescan_bus().
This is often because .pcibios_add_pci_devices lacks a __devinit
annotation or the annotation of .of_rescan_bus is wrong.
WARNING: vmlinux.o(.text+0x3a3fe0): Section mismatch in reference from
the function .dlpar_remove_slot() to the
function .devinit.text:.vio_unregister_device()
The function .dlpar_remove_slot() references
the function __devinit .vio_unregister_device().
This is often because .dlpar_remove_slot lacks a __devinit
annotation or the annotation of .vio_unregister_device is wrong.
WARNING: vmlinux.o(.text+0x3a40a8): Section mismatch in reference from
the function .dlpar_add_pci_slot() to the
function .devinit.text:.pcibios_map_io_space()
The function .dlpar_add_pci_slot() references
the function __devinit .pcibios_map_io_space().
This is often because .dlpar_add_pci_slot lacks a __devinit
annotation or the annotation of .pcibios_map_io_space is wrong.
WARNING: vmlinux.o(.text+0x3a4148): Section mismatch in reference from
the function .dlpar_add_pci_slot() to the
function .devinit.text:.of_scan_pci_bridge()
The function .dlpar_add_pci_slot() references
the function __devinit .of_scan_pci_bridge().
This is often because .dlpar_add_pci_slot lacks a __devinit
annotation or the annotation of .of_scan_pci_bridge is wrong.
WARNING: vmlinux.o(.text+0x3a4300): Section mismatch in reference from
the function .dlpar_add_slot() to the
function .devinit.text:.init_phb_dynamic()
The function .dlpar_add_slot() references
the function __devinit .init_phb_dynamic().
This is often because .dlpar_add_slot lacks a __devinit
annotation or the annotation of .init_phb_dynamic is wrong.
WRAP arch/powerpc/boot/zImage.pmac
WARNING: drivers/spi/spi-gpio.o(.devinit.text+0x8c): Section mismatch in
reference from the function .spi_gpio_probe() to the
function .init.text:.spi_gpio_alloc()
The function __devinit .spi_gpio_probe() references
a function __init .spi_gpio_alloc().
If .spi_gpio_alloc is only used by .spi_gpio_probe then
annotate .spi_gpio_alloc with a matching annotation.
WARNING: drivers/spi/spi-gpio.o(.devinit.text+0x210): Section mismatch
in reference from the function .spi_gpio_probe() to the
function .init.text:.spi_gpio_alloc()
The function __devinit .spi_gpio_probe() references
a function __init .spi_gpio_alloc().
If .spi_gpio_alloc is only used by .spi_gpio_probe then
annotate .spi_gpio_alloc with a matching annotation.
WARNING: drivers/spi/spi-gpio.o(.devinit.text+0x244): Section mismatch
in reference from the function .spi_gpio_probe() to the
function .init.text:.spi_gpio_alloc()
The function __devinit .spi_gpio_probe() references
a function __init .spi_gpio_alloc().
If .spi_gpio_alloc is only used by .spi_gpio_probe then
annotate .spi_gpio_alloc with a matching annotation.
Regards--
Subrata
^ permalink raw reply
* Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
From: Benjamin Herrenschmidt @ 2011-12-08 19:40 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Michael Neuling, paulus, sukadev, linuxppc-dev
In-Reply-To: <20111208170450.22247a4b@kryten>
On Thu, 2011-12-08 at 17:04 +1100, Anton Blanchard wrote:
> Hi,
>
> > I hate the idea of having a POWER7 FTR bit. Every loon will (and has
> > tried to in the past) attach every POWER7 related thing to it, rather
> > than thinking about what the feature really is for.
> >
> > What about other processors which could also benefit from this copy
> > loop? Turning on CPU_FTR_POWER7 for them is gonna look a bit silly.
>
> As we discussed online, we could call it CPU_FTR_VMX_COPY and start
> thinking about a better way to solve the CPU feature bit mess.
>
> One idea would be to have a structure of function pointers for each
> CPU that gets runtime patched into the right places, similar to how we
> do some of the MMU fixups.
Or the vdso... we have a table of some sort which is used to patch
symbols.
But it's keyed off cpu features.
I'm reluctant to adding another table of PVRs, it needs to deal with the
pseudo-PVRs from pHyp, and things will get out of sync.
CPU features are the way to go, tho we can use them to key off a branch
patching mechanism if we want to. It's easy to add new bitmasks for
in-kernel features at least (it's the user features which are more nasty
but they are a separate thing).
So if we have to we can split cpu feature into another separate mask
like I did for mmu features with the same macros etc... For example, the
debug features could be moved out, or whatever.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 01/16 v3] pmac_zilog: fix unexpected irq
From: Benjamin Herrenschmidt @ 2011-12-08 19:44 UTC (permalink / raw)
To: Finn Thain; +Cc: linuxppc-dev, linux-m68k, Geert Uytterhoeven, linux-serial
In-Reply-To: <alpine.LNX.2.00.1112082128330.2357@nippy.intranet>
On Thu, 2011-12-08 at 22:26 +1100, Finn Thain wrote:
>
> Maybe the modem wants a transition on DTR or similar, but it hasn't had
> time to initialise when that happens during SCC resumption.
>
> If so, calling pmz_shutdown() then pmz_startup() from the tail of
> pmz_resume() without delay should probably fail to revive it...
Well, we power the modem down and back up... but it's possible that we
fail to re-enable something, I'll check. That used to work (at least
with macserial, maybe I never tried this specific torture with pmz...).
I'll figure it out eventually.
Cheers,
Ben.
^ permalink raw reply
* Re: cpu idle time going backward
From: kevin diggs @ 2011-12-08 19:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2fwgvnwlm.fsf@igel.home>
On 12/8/11, Andreas Schwab <schwab@linux-m68k.org> wrote:
> There seems to be something wrong with cpu idle time accounting at least
> on G5. The value as reported in the cpu lines in /proc/stat seems to be
> stuck in the interval [100000,210000] for each cpu, jumping back at
> random points. Any idea what could be the problem?
>
> Andreas.
>
> --
What kernel versions?
kevin
^ permalink raw reply
* [PATCH] [v2] powerpc/85xx: create 32-bit DTS for the P1022DS
From: Timur Tabi @ 2011-12-08 21:50 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
Create a 32-bit address space version of p1022ds.dts. To avoid confusion,
p1022ds.dts is renamed to p1022ds_36b.dts. We also create p1022ds.dtsi
to store some common nodes.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
fix pixis interrupt property and added tbi node
arch/powerpc/boot/dts/p1022ds.dts | 270 ---------------------------------
arch/powerpc/boot/dts/p1022ds.dtsi | 116 ++++++++++++++
arch/powerpc/boot/dts/p1022ds_32b.dts | 218 ++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1022ds_36b.dts | 218 ++++++++++++++++++++++++++
4 files changed, 552 insertions(+), 270 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/p1022ds.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds.dtsi
create mode 100644 arch/powerpc/boot/dts/p1022ds_32b.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds_36b.dts
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
deleted file mode 100644
index a54dd13..0000000
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ /dev/null
@@ -1,270 +0,0 @@
-/*
- * P1022 DS 36Bit Physical Address Map Device Tree Source
- *
- * Copyright 2010 Freescale Semiconductor, Inc.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-/include/ "fsl/p1022si-pre.dtsi"
-/ {
- model = "fsl,P1022DS";
- compatible = "fsl,P1022DS";
-
- memory {
- device_type = "memory";
- };
-
- lbc: localbus@fffe05000 {
- reg = <0xf 0xffe05000 0 0x1000>;
- ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
- 0x1 0x0 0xf 0xe0000000 0x08000000
- 0x2 0x0 0xf 0xff800000 0x00040000
- 0x3 0x0 0xf 0xffdf0000 0x00008000>;
-
- /*
- * This node is used to access the pixis via "indirect" mode,
- * which is done by writing the pixis register index to chip
- * select 0 and the value to/from chip select 1. Indirect
- * mode is the only way to access the pixis when DIU video
- * is enabled. Note that this assumes that the first column
- * of the 'ranges' property above is the chip select number.
- */
- board-control@0,0 {
- compatible = "fsl,p1022ds-indirect-pixis";
- reg = <0x0 0x0 1 /* CS0 */
- 0x1 0x0 1>; /* CS1 */
- };
-
- nor@0,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "cfi-flash";
- reg = <0x0 0x0 0x8000000>;
- bank-width = <2>;
- device-width = <1>;
-
- partition@0 {
- reg = <0x0 0x03000000>;
- label = "ramdisk-nor";
- read-only;
- };
-
- partition@3000000 {
- reg = <0x03000000 0x00e00000>;
- label = "diagnostic-nor";
- read-only;
- };
-
- partition@3e00000 {
- reg = <0x03e00000 0x00200000>;
- label = "dink-nor";
- read-only;
- };
-
- partition@4000000 {
- reg = <0x04000000 0x00400000>;
- label = "kernel-nor";
- read-only;
- };
-
- partition@4400000 {
- reg = <0x04400000 0x03b00000>;
- label = "jffs2-nor";
- };
-
- partition@7f00000 {
- reg = <0x07f00000 0x00080000>;
- label = "dtb-nor";
- read-only;
- };
-
- partition@7f80000 {
- reg = <0x07f80000 0x00080000>;
- label = "u-boot-nor";
- read-only;
- };
- };
-
- nand@2,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,elbc-fcm-nand";
- reg = <0x2 0x0 0x40000>;
-
- partition@0 {
- reg = <0x0 0x02000000>;
- label = "u-boot-nand";
- read-only;
- };
-
- partition@2000000 {
- reg = <0x02000000 0x10000000>;
- label = "jffs2-nand";
- };
-
- partition@12000000 {
- reg = <0x12000000 0x10000000>;
- label = "ramdisk-nand";
- read-only;
- };
-
- partition@22000000 {
- reg = <0x22000000 0x04000000>;
- label = "kernel-nand";
- };
-
- partition@26000000 {
- reg = <0x26000000 0x01000000>;
- label = "dtb-nand";
- read-only;
- };
-
- partition@27000000 {
- reg = <0x27000000 0x19000000>;
- label = "reserved-nand";
- };
- };
-
- board-control@3,0 {
- compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
- reg = <3 0 0x30>;
- interrupt-parent = <&mpic>;
- /*
- * IRQ8 is generated if the "EVENT" switch is pressed
- * and PX_CTL[EVESEL] is set to 00.
- */
- interrupts = <8 8 0 0>;
- };
- };
-
- soc: soc@fffe00000 {
- ranges = <0x0 0xf 0xffe00000 0x100000>;
-
- i2c@3100 {
- wm8776:codec@1a {
- compatible = "wlf,wm8776";
- reg = <0x1a>;
- /*
- * clock-frequency will be set by U-Boot if
- * the clock is enabled.
- */
- };
- };
-
- spi@7000 {
- flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "spansion,s25sl12801";
- reg = <0>;
- spi-max-frequency = <40000000>; /* input clock */
-
- partition@0 {
- label = "u-boot-spi";
- reg = <0x00000000 0x00100000>;
- read-only;
- };
- partition@100000 {
- label = "kernel-spi";
- reg = <0x00100000 0x00500000>;
- read-only;
- };
- partition@600000 {
- label = "dtb-spi";
- reg = <0x00600000 0x00100000>;
- read-only;
- };
- partition@700000 {
- label = "file system-spi";
- reg = <0x00700000 0x00900000>;
- };
- };
- };
-
- ssi@15000 {
- fsl,mode = "i2s-slave";
- codec-handle = <&wm8776>;
- fsl,ssi-asynchronous;
- };
-
- usb@22000 {
- phy_type = "ulpi";
- };
-
- usb@23000 {
- status = "disabled";
- };
-
- mdio@24000 {
- phy0: ethernet-phy@0 {
- interrupts = <3 1 0 0>;
- reg = <0x1>;
- };
- phy1: ethernet-phy@1 {
- interrupts = <9 1 0 0>;
- reg = <0x2>;
- };
- };
-
- ethernet@b0000 {
- phy-handle = <&phy0>;
- phy-connection-type = "rgmii-id";
- };
-
- ethernet@b1000 {
- phy-handle = <&phy1>;
- phy-connection-type = "rgmii-id";
- };
- };
-
- pci0: pcie@fffe09000 {
- reg = <0xf 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
- pcie@0 {
- ranges = <0x2000000 0x0 0xe0000000
- 0x2000000 0x0 0xe0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci1: pcie@fffe0a000 {
- reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x40000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x10000>;
- pcie@0 {
- reg = <0x0 0x0 0x0 0x0 0x0>;
- ranges = <0x2000000 0x0 0xe0000000
- 0x2000000 0x0 0xe0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci2: pcie@fffe0b000 {
- reg = <0xf 0xffe0b000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
- pcie@0 {
- ranges = <0x2000000 0x0 0xe0000000
- 0x2000000 0x0 0xe0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-};
-
-/include/ "fsl/p1022si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi b/arch/powerpc/boot/dts/p1022ds.dtsi
new file mode 100644
index 0000000..c82cfc9
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -0,0 +1,116 @@
+/*
+ * P1022 DS Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&board_soc {
+ i2c@3100 {
+ wm8776:codec@1a {
+ compatible = "wlf,wm8776";
+ reg = <0x1a>;
+ /*
+ * clock-frequency will be set by U-Boot if
+ * the clock is enabled.
+ */
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <40000000>; /* input clock */
+
+ partition@0 {
+ label = "u-boot-spi";
+ reg = <0x00000000 0x00100000>;
+ read-only;
+ };
+ partition@100000 {
+ label = "kernel-spi";
+ reg = <0x00100000 0x00500000>;
+ read-only;
+ };
+ partition@600000 {
+ label = "dtb-spi";
+ reg = <0x00600000 0x00100000>;
+ read-only;
+ };
+ partition@700000 {
+ label = "file system-spi";
+ reg = <0x00700000 0x00900000>;
+ };
+ };
+ };
+
+ ssi@15000 {
+ fsl,mode = "i2s-slave";
+ codec-handle = <&wm8776>;
+ fsl,ssi-asynchronous;
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ usb@23000 {
+ status = "disabled";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupts = <3 1 0 0>;
+ reg = <0x1>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <9 1 0 0>;
+ reg = <0x2>;
+ };
+ tbi-phy@2 {
+ device_type = "tbi-phy";
+ reg = <0x2>;
+ };
+ };
+
+ ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@b1000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+};
+
diff --git a/arch/powerpc/boot/dts/p1022ds_32b.dts b/arch/powerpc/boot/dts/p1022ds_32b.dts
new file mode 100644
index 0000000..03c94e1
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds_32b.dts
@@ -0,0 +1,218 @@
+/*
+ * P1022 DS 32-bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1022si-pre.dtsi"
+/ {
+ model = "fsl,P1022DS";
+ compatible = "fsl,P1022DS";
+
+ memory {
+ device_type = "memory";
+ };
+
+ lbc: localbus@ffe05000 {
+ reg = <0x0 0xffe05000 0 0x1000>;
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x1 0x0 0x0 0xe0000000 0x08000000
+ 0x2 0x0 0x0 0xff800000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000>;
+
+ /*
+ * This node is used to access the pixis via "indirect" mode,
+ * which is done by writing the pixis register index to chip
+ * select 0 and the value to/from chip select 1. Indirect
+ * mode is the only way to access the pixis when DIU video
+ * is enabled. Note that this assumes that the first column
+ * of the 'ranges' property above is the chip select number.
+ */
+ board-control@0,0 {
+ compatible = "fsl,p1022ds-indirect-pixis";
+ reg = <0x0 0x0 1 /* CS0 */
+ 0x1 0x0 1>; /* CS1 */
+ };
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ read-only;
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ read-only;
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "jffs2-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ read-only;
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "jffs2-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x10000000>;
+ label = "ramdisk-nand";
+ read-only;
+ };
+
+ partition@22000000 {
+ reg = <0x22000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@26000000 {
+ reg = <0x26000000 0x01000000>;
+ label = "dtb-nand";
+ read-only;
+ };
+
+ partition@27000000 {
+ reg = <0x27000000 0x19000000>;
+ label = "reserved-nand";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
+ reg = <3 0 0x30>;
+ interrupt-parent = <&mpic>;
+ /*
+ * IRQ8 is generated if the "EVENT" switch is pressed
+ * and PX_CTL[EVESEL] is set to 00.
+ */
+ interrupts = <8 0 0 0>;
+ };
+ };
+
+ board_soc: soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ reg = <0x0 0xffe09000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xe0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg = <0 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xe0000000 0 0xc0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci2: pcie@ffe0b000 {
+ reg = <0 0xffe0b000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xe0000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "fsl/p1022si-post.dtsi"
+/include/ "p1022ds.dtsi"
diff --git a/arch/powerpc/boot/dts/p1022ds_36b.dts b/arch/powerpc/boot/dts/p1022ds_36b.dts
new file mode 100644
index 0000000..2893bfa
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds_36b.dts
@@ -0,0 +1,218 @@
+/*
+ * P1022 DS 36-bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1022si-pre.dtsi"
+/ {
+ model = "fsl,P1022DS";
+ compatible = "fsl,P1022DS";
+
+ memory {
+ device_type = "memory";
+ };
+
+ lbc: localbus@fffe05000 {
+ reg = <0xf 0xffe05000 0 0x1000>;
+ ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
+ 0x1 0x0 0xf 0xe0000000 0x08000000
+ 0x2 0x0 0xf 0xff800000 0x00040000
+ 0x3 0x0 0xf 0xffdf0000 0x00008000>;
+
+ /*
+ * This node is used to access the pixis via "indirect" mode,
+ * which is done by writing the pixis register index to chip
+ * select 0 and the value to/from chip select 1. Indirect
+ * mode is the only way to access the pixis when DIU video
+ * is enabled. Note that this assumes that the first column
+ * of the 'ranges' property above is the chip select number.
+ */
+ board-control@0,0 {
+ compatible = "fsl,p1022ds-indirect-pixis";
+ reg = <0x0 0x0 1 /* CS0 */
+ 0x1 0x0 1>; /* CS1 */
+ };
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ read-only;
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ read-only;
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "jffs2-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ read-only;
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "jffs2-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x10000000>;
+ label = "ramdisk-nand";
+ read-only;
+ };
+
+ partition@22000000 {
+ reg = <0x22000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@26000000 {
+ reg = <0x26000000 0x01000000>;
+ label = "dtb-nand";
+ read-only;
+ };
+
+ partition@27000000 {
+ reg = <0x27000000 0x19000000>;
+ label = "reserved-nand";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
+ reg = <3 0 0x30>;
+ interrupt-parent = <&mpic>;
+ /*
+ * IRQ8 is generated if the "EVENT" switch is pressed
+ * and PX_CTL[EVESEL] is set to 00.
+ */
+ interrupts = <8 0 0 0>;
+ };
+ };
+
+ board_soc: soc: soc@fffe00000 {
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe09000 {
+ reg = <0xf 0xffe09000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x40000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci2: pcie@fffe0b000 {
+ reg = <0xf 0xffe0b000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "fsl/p1022si-post.dtsi"
+/include/ "p1022ds.dtsi"
--
1.7.3.4
^ permalink raw reply related
* Re: [linux-3.2-rc4 PPC64] Series of "Section Mismatch" warnings, are they expected ?
From: Tony Breeds @ 2011-12-08 22:00 UTC (permalink / raw)
To: Subrata Modak
Cc: Mark Wizner, Naveed, LKML, Manas k Nayak, Pavaman, Vishu,
Linuxppc-dev, divya.vikas
In-Reply-To: <1323371433.23534.8.camel@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
On Fri, Dec 09, 2011 at 12:40:32AM +0530, Subrata Modak wrote:
> Hello,
>
> While compiling linux-3.2-rc4 on PPC64, i get the following set of
> warning series. I wanted to know if they are expected, or, they need to
> be fixed:
If you have time they should be fixed.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [patch] powerpc, mm: fix section mismatch for mark_reserved_regions_for_nid
From: David Rientjes @ 2011-12-08 22:33 UTC (permalink / raw)
To: Subrata Modak, Benjamin Herrenschmidt, Paul Mackerras
Cc: Mark Wizner, Naveed, linux-kernel, Manas k Nayak, Pavaman,
Anton Blanchard, Vishu, linuxppc-dev, divya.vikas
In-Reply-To: <1323371433.23534.8.camel@subratamodak.linux.ibm.com>
On Fri, 9 Dec 2011, Subrata Modak wrote:
> WARNING: vmlinux.o(.text+0x4c760): Section mismatch in reference from
> the function .mark_reserved_regions_for_nid() to the
> function .meminit.text:.early_pfn_to_nid()
> The function .mark_reserved_regions_for_nid() references
> the function __meminit .early_pfn_to_nid().
> This is often because .mark_reserved_regions_for_nid lacks a __meminit
> annotation or the annotation of .early_pfn_to_nid is wrong.
>
> WARNING: vmlinux.o(.text+0x4c780): Section mismatch in reference from
> the function .mark_reserved_regions_for_nid() to the
> function .init.text:.work_with_active_regions()
> The function .mark_reserved_regions_for_nid() references
> the function __init .work_with_active_regions().
> This is often because .mark_reserved_regions_for_nid lacks a __init
> annotation or the annotation of .work_with_active_regions is wrong.
>
> WARNING: vmlinux.o(.text+0x4c7d4): Section mismatch in reference from
> the function .mark_reserved_regions_for_nid() to the
> function .meminit.text:.early_pfn_to_nid()
> The function .mark_reserved_regions_for_nid() references
> the function __meminit .early_pfn_to_nid().
> This is often because .mark_reserved_regions_for_nid lacks a __meminit
> annotation or the annotation of .early_pfn_to_nid is wrong.
>
> WARNING: vmlinux.o(.text+0x4c7f0): Section mismatch in reference from
> the function .mark_reserved_regions_for_nid() to the
> function .init.text:.work_with_active_regions()
> The function .mark_reserved_regions_for_nid() references
> the function __init .work_with_active_regions().
> This is often because .mark_reserved_regions_for_nid lacks a __init
> annotation or the annotation of .work_with_active_regions is wrong.
>
> WARNING: vmlinux.o(.text+0x4c828): Section mismatch in reference from
> the function .mark_reserved_regions_for_nid() to the
> function .init.text:.reserve_bootmem_node()
> The function .mark_reserved_regions_for_nid() references
> the function __init .reserve_bootmem_node().
> This is often because .mark_reserved_regions_for_nid lacks a __init
> annotation or the annotation of .reserve_bootmem_node is wrong.
>
Wow, lots of ibm folks on the cc :) I can only talk about the mm related
section mismatches, but these five can easily be solved with the
following.
powerpc, mm: fix section mismatch for mark_reserved_regions_for_nid
mark_reserved_regions_for_nid() is only called from do_init_bootmem(),
which is in .init.text, so it must be in the same section to avoid a
section mismatch warning.
Reported-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: David Rientjes <rientjes@google.com>
---
arch/powerpc/mm/numa.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -969,7 +969,7 @@ static struct notifier_block __cpuinitdata ppc64_numa_nb = {
.priority = 1 /* Must run before sched domains notifier. */
};
-static void mark_reserved_regions_for_nid(int nid)
+static void __init mark_reserved_regions_for_nid(int nid)
{
struct pglist_data *node = NODE_DATA(nid);
struct memblock_region *reg;
^ permalink raw reply
* [patch] powerpc, mm: fix section mismatch for read_n_cells
From: David Rientjes @ 2011-12-08 22:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Mark Wizner, Naveed, linuxppc-dev, linux-kernel, Manas k Nayak,
Pavaman, Anton Blanchard, Vishu, Subrata Modak, divya.vikas
In-Reply-To: <alpine.DEB.2.00.1112081428290.28693@chino.kir.corp.google.com>
read_n_cells() cannot be marked as .devinit.text since it is referenced
from two functions that are not in that section: of_get_lmb_size() and
hot_add_drconf_scn_to_nid().
Signed-off-by: David Rientjes <rientjes@google.com>
---
arch/powerpc/mm/numa.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -406,7 +406,7 @@ static void __init get_n_mem_cells(int *n_addr_cells, int *n_size_cells)
of_node_put(memory);
}
-static unsigned long __devinit read_n_cells(int n, const unsigned int **buf)
+static unsigned long read_n_cells(int n, const unsigned int **buf)
{
unsigned long result = 0;
^ permalink raw reply
* Re: ibm_newemac tx problem with jumbo frame enabled
From: Benjamin Herrenschmidt @ 2011-12-08 22:59 UTC (permalink / raw)
To: Prashant Bhole; +Cc: Tirumala Marri, linuxppc-dev
In-Reply-To: <CAD6p20eC22MUMjbnDW55mfkojrBTWLwvMDjpM-DPZYcgxKTbZg@mail.gmail.com>
On Thu, 2011-12-08 at 18:31 +0530, Prashant Bhole wrote:
>
> I checked RX descriptor status and TX descriptor status and ethtool
> output.
> However I don't know about pause packet/frame, how do I check if pause
> frames are properly negotiated on both sides?
> I need to try changing pause and FIFO thresholds.
>
> ethtool output after disconnection is as follows:
> # ethtool -S eth0
> NIC statistics:
> rx_packets: 330939
> rx_bytes: 804963241
> tx_packets: 248554
> tx_bytes: 798853638
> rx_packets_csum: 330716
> tx_packets_csum: 179526
> tx_undo: 0
.../...
Ok so none of the error counters seem to trip, odd. No idea what's up,
you may want to ask the folks at APM (CCed Tirumala).
I wonder also if we are properly enabling the reporting of error
interrupts... if we got that wrong we may never detect FIFO overruns.
What you describe really looks like a fifo overrun to me.
Additionally, look at emac_configure(), sees how it configures the pause
packet thresholds, maybe you can tweak the watermark to be more
aggressive. Also check that pause is actually enabled (with ethtool) and
that the PHY negociated it properly (that the link partner supports
pause frames).
Cheers,
Ben.
^ permalink raw reply
* RE: ibm_newemac tx problem with jumbo frame enabled
From: Tirumala Marri @ 2011-12-08 23:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Prashant Bhole; +Cc: linuxppc-dev
In-Reply-To: <1323385148.19891.5.camel@pasglop>
Hi Ben,
>-----Original Message-----
>From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>Sent: Thursday, December 08, 2011 2:59 PM
>To: Prashant Bhole
>Cc: linuxppc-dev@ozlabs.org; Tirumala Marri
>Subject: Re: ibm_newemac tx problem with jumbo frame enabled
>
>On Thu, 2011-12-08 at 18:31 +0530, Prashant Bhole wrote:
>
>>
>> I checked RX descriptor status and TX descriptor status and ethtool
>> output.
>> However I don't know about pause packet/frame, how do I check if pause
>> frames are properly negotiated on both sides?
>> I need to try changing pause and FIFO thresholds.
>>
>> ethtool output after disconnection is as follows:
>> # ethtool -S eth0
>> NIC statistics:
>> rx_packets: 330939
>> rx_bytes: 804963241
>> tx_packets: 248554
>> tx_bytes: 798853638
>> rx_packets_csum: 330716
>> tx_packets_csum: 179526
>> tx_undo: 0
>
> .../...
>
>Ok so none of the error counters seem to trip, odd. No idea what's up,
>you may want to ask the folks at APM (CCed Tirumala).
>
>I wonder also if we are properly enabling the reporting of error
>interrupts... if we got that wrong we may never detect FIFO overruns.
>What you describe really looks like a fifo overrun to me.
>
>Additionally, look at emac_configure(), sees how it configures the pause
>packet thresholds, maybe you can tweak the watermark to be more
>aggressive. Also check that pause is actually enabled (with ethtool) and
>that the PHY negociated it properly (that the link partner supports
>pause frames).
>
I will take a look.
Thx,
Marri
^ permalink raw reply
* linux-next bad Kconfig for drivers/hid
From: Tony Breeds @ 2011-12-09 1:27 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Jiri Kosina, LinuxPPC-dev, Linux Kernel ML
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Commit 4f5ca836bef3 (HID: hid-input: add support for HID devices
reporting Battery Strength) went into linux-next on Dec 1st since then a
ppc6xx_defconfig has been failing with:
---
drivers/built-in.o: In function `hidinput_cleanup_battery':
/scratch/tony/working/drivers/hid/hid-input.c:351: undefined reference to `power_supply_unregister'
drivers/built-in.o: In function `hidinput_setup_battery':
/scratch/tony/working/drivers/hid/hid-input.c:338: undefined reference to `power_supply_register'
make[1]: *** [.tmp_vmlinux1] Error 1
---
http://kisskb.ellerman.id.au/kisskb/buildresult/5012563/
vs
http://kisskb.ellerman.id.au/kisskb/buildresult/5017366/
The defconfig in question doens't mention either option
(CONFIG_POWER_SUPPLY or CONFIG_HID_BATTERY_STRENGTH) and kbuild is
genertaing
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_POWER_SUPPLY=m
which clearly isn't going to work.
The following change to HID_BATTERY_STRENGTH Kconfig "works" but seems a
little gross.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 5ed64f6..d2a94e6 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -33,7 +33,7 @@ config HID
config HID_BATTERY_STRENGTH
bool
- depends on POWER_SUPPLY
+ depends on POWER_SUPPLY=y
default y
config HIDRAW
Any chance we can get a fix into linux-next?
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* linux-next: manual merge of the 4xx tree with the powerpc tree
From: Stephen Rothwell @ 2011-12-09 1:38 UTC (permalink / raw)
To: Josh Boyer
Cc: linux-kernel, linux-next, Paul Mackerras, Tanmay Inamdar,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Hi Josh,
Today's linux-next merge of the 4xx tree got a conflict in
arch/powerpc/platforms/40x/ppc40x_simple.c between commit 11eab297f57b
("powerpc: Add support for OpenBlockS 600") from the powerpc tree and
commit d5b9ee7b514e ("powerpc/40x: Add APM8018X SOC support") from the
4xx tree.
I fixed it up (see below) and can carry the fix as necessary.
[Josh: I have changed you contact address to the above]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/powerpc/platforms/40x/ppc40x_simple.c
index ecac237,2f8fde6..0000000
--- a/arch/powerpc/platforms/40x/ppc40x_simple.c
+++ b/arch/powerpc/platforms/40x/ppc40x_simple.c
@@@ -55,8 -55,8 +55,9 @@@ static const char *board[] __initdata
"amcc,haleakala",
"amcc,kilauea",
"amcc,makalu",
+ "apm,klondike",
- "est,hotfoot"
+ "est,hotfoot",
+ "plathome,obs600"
};
static int __init ppc40x_probe(void)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] powerpc: fix compile error with 85xx/p1010rdb.c
From: Tony Breeds @ 2011-12-09 1:39 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, Michael Ellerman, linux-next, Paul Mackerras, Kyle Moffett,
linuxppc-dev
In-Reply-To: <7679.1323324654@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
Current linux-next compiled with mpc85xx_defconfig causes this:
arch/powerpc/platforms/85xx/p1010rdb.c:41:14: error: 'np' undeclared (first use in this function)
arch/powerpc/platforms/85xx/p1023_rds.c:102:14: error: 'np' undeclared (first use in this function)
Introduced in:
commit 996983b75cebb1bc1c2c545f20336f24ebfa17af
Author: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Date: Fri Dec 2 06:28:02 2011 +0000
powerpc/mpic: Search for open-pic device-tree node if NULL
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Mikey already posted a fix for p1023_rds.c. I think this is the last
one.
arch/powerpc/platforms/85xx/p1010rdb.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85x
index 894f1e8..538bc3f 100644
--- a/arch/powerpc/platforms/85xx/p1010rdb.c
+++ b/arch/powerpc/platforms/85xx/p1010rdb.c
@@ -38,10 +38,8 @@ void __init p1010_rdb_pic_init(void)
0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
- of_node_put(np);
mpic_init(mpic);
-
}
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: manual merge of the 4xx tree with the powerpc tree
From: Josh Boyer @ 2011-12-09 1:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, linux-next, Paul Mackerras, Tanmay Inamdar,
linuxppc-dev
In-Reply-To: <20111209123811.12cf28971f21a309976f31bb@canb.auug.org.au>
On Thu, Dec 8, 2011 at 8:38 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Josh,
>
> Today's linux-next merge of the 4xx tree got a conflict in
> arch/powerpc/platforms/40x/ppc40x_simple.c between commit 11eab297f57b
> ("powerpc: Add support for OpenBlockS 600") from the powerpc tree and
> commit d5b9ee7b514e ("powerpc/40x: Add APM8018X SOC support") from the
> 4xx tree.
I blame BenH. I sent him a pull request with d5b9ee7b514e in it
before he went and updated his tree. Still not pulled afaik. Guess
I'll be rebasing my next branch tomorrow to pick up a series from Tony
Breeds, unless Ben handles the outstanding pull before I wake up :).
> I fixed it up (see below) and can carry the fix as necessary.
Looks correct to me. Hopefully you won't have to carry it long.
>
> [Josh: I have changed you contact address to the above]
Thank you.
josh
^ permalink raw reply
* Re: linux-next: manual merge of the 4xx tree with the powerpc tree
From: Stephen Rothwell @ 2011-12-09 1:51 UTC (permalink / raw)
To: Josh Boyer
Cc: linux-kernel, linux-next, Paul Mackerras, Tanmay Inamdar,
linuxppc-dev
In-Reply-To: <CA+5PVA5vVC=e24imM0QxbT10kBAF4v=kwheKs7cOHKKcC+if=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
Hi Josh,
On Thu, 8 Dec 2011 20:46:39 -0500 Josh Boyer <jwboyer@gmail.com> wrote:
>
> I blame BenH. I sent him a pull request with d5b9ee7b514e in it
> before he went and updated his tree. Still not pulled afaik. Guess
> I'll be rebasing my next branch tomorrow to pick up a series from Tony
> Breeds, unless Ben handles the outstanding pull before I wake up :).
Don't bother rebasing, let Ben handle the conflict in the merge.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the 4xx tree with the powerpc tree
From: Benjamin Herrenschmidt @ 2011-12-09 4:41 UTC (permalink / raw)
To: Josh Boyer
Cc: Stephen Rothwell, linux-kernel, linux-next, Paul Mackerras,
Tanmay Inamdar, linuxppc-dev
In-Reply-To: <CA+5PVA5vVC=e24imM0QxbT10kBAF4v=kwheKs7cOHKKcC+if=A@mail.gmail.com>
On Thu, 2011-12-08 at 20:46 -0500, Josh Boyer wrote:
> On Thu, Dec 8, 2011 at 8:38 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Josh,
> >
> > Today's linux-next merge of the 4xx tree got a conflict in
> > arch/powerpc/platforms/40x/ppc40x_simple.c between commit 11eab297f57b
> > ("powerpc: Add support for OpenBlockS 600") from the powerpc tree and
> > commit d5b9ee7b514e ("powerpc/40x: Add APM8018X SOC support") from the
> > 4xx tree.
>
> I blame BenH. I sent him a pull request with d5b9ee7b514e in it
> before he went and updated his tree. Still not pulled afaik. Guess
> I'll be rebasing my next branch tomorrow to pick up a series from Tony
> Breeds, unless Ben handles the outstanding pull before I wake up :).
Don't bother rebasing, I can deal with a minor merge conflict like
that :-)
> > I fixed it up (see below) and can carry the fix as necessary.
>
> Looks correct to me. Hopefully you won't have to carry it long.
> >
> > [Josh: I have changed you contact address to the above]
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next bad Kconfig for drivers/hid
From: Jeremy Fitzhardinge @ 2011-12-09 5:33 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Herrenschmidt, LinuxPPC-dev,
Linux Kernel ML
In-Reply-To: <20111209012746.GC20353@thor.bakeyournoodle.com>
On 12/08/2011 05:27 PM, Tony Breeds wrote:
> Commit 4f5ca836bef3 (HID: hid-input: add support for HID devices
> reporting Battery Strength) went into linux-next on Dec 1st since then a
> ppc6xx_defconfig has been failing with:
>
> ---
> drivers/built-in.o: In function `hidinput_cleanup_battery':
> /scratch/tony/working/drivers/hid/hid-input.c:351: undefined reference to `power_supply_unregister'
> drivers/built-in.o: In function `hidinput_setup_battery':
> /scratch/tony/working/drivers/hid/hid-input.c:338: undefined reference to `power_supply_register'
> make[1]: *** [.tmp_vmlinux1] Error 1
> ---
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/5012563/
> vs
> http://kisskb.ellerman.id.au/kisskb/buildresult/5017366/
>
> The defconfig in question doens't mention either option
> (CONFIG_POWER_SUPPLY or CONFIG_HID_BATTERY_STRENGTH) and kbuild is
> genertaing
> CONFIG_HID_BATTERY_STRENGTH=y
> CONFIG_POWER_SUPPLY=m
> which clearly isn't going to work.
>
> The following change to HID_BATTERY_STRENGTH Kconfig "works" but seems a
> little gross.
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 5ed64f6..d2a94e6 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -33,7 +33,7 @@ config HID
>
> config HID_BATTERY_STRENGTH
> bool
> - depends on POWER_SUPPLY
> + depends on POWER_SUPPLY=y
> default y
>
> config HIDRAW
>
> Any chance we can get a fix into linux-next?
Hm. How about making it "depends on HID && POWER_SUPPLY"? I think that
would needlessly disable it if HID is also modular, but I'm not sure how
to fix that. "depends on HID && POWER_SUPPLY && HID == POWER_SUPPLY"?
J
^ permalink raw reply
* RE: Linuxppc-dev Digest, Vol 88, Issue 24
From: Liu Shengzhou-B36685 @ 2011-12-09 9:27 UTC (permalink / raw)
To: Liu Shuo-B35362; +Cc: Liu Shengzhou-B36685, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <mailman.5273.1323013984.15294.linuxppc-dev@lists.ozlabs.org>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gDQo+IE1lc3NhZ2U6IDQNCj4gRGF0
ZTogU3VuLCA0IERlYyAyMDExIDEyOjMxOjM4ICswODAwDQo+IEZyb206IDxzaHVvLmxpdUBmcmVl
c2NhbGUuY29tPg0KPiBUbzogPGR3bXcyQGluZnJhZGVhZC5vcmc+LCA8QXJ0ZW0uQml0eXV0c2tp
eUBub2tpYS5jb20+LA0KPiAJPHNjb3R0d29vZEBmcmVlc2NhbGUuY29tPg0KPiBDYzogbGludXgt
a2VybmVsQHZnZXIua2VybmVsLm9yZywgc2h1by5saXVAZnJlZXNjYWxlLmNvbSwNCj4gCWxpbnV4
LW10ZEBsaXN0cy5pbmZyYWRlYWQub3JnLCBha3BtQGxpbnV4LWZvdW5kYXRpb24ub3JnLA0KPiAJ
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogW1BBVENIIDMvM10gbXRk
L25hbmQgOiB3b3JrYXJvdW5kIGZvciBGcmVlc2NhbGUgRkNNIHRvDQo+IAlzdXBwb3J0IGxhcmdl
LXBhZ2UgTmFuZCBjaGlwDQo+IE1lc3NhZ2UtSUQ6IDwxMzIyOTczMDk4LTI1MjgtMy1naXQtc2Vu
ZC1lbWFpbC1zaHVvLmxpdUBmcmVlc2NhbGUuY29tPg0KPiBDb250ZW50LVR5cGU6IHRleHQvcGxh
aW4NCj4gDQo+IEZyb206IExpdSBTaHVvIDxzaHVvLmxpdUBmcmVlc2NhbGUuY29tPg0KPiANCj4g
RnJlZXNjYWxlIEZDTSBjb250cm9sbGVyIGhhcyBhIDJLIHNpemUgbGltaXRhdGlvbiBvZiBidWZm
ZXIgUkFNLiBJbiBvcmRlcg0KPiB0byBzdXBwb3J0IHRoZSBOYW5kIGZsYXNoIGNoaXAgd2hvc2Ug
cGFnZSBzaXplIGlzIGxhcmdlciB0aGFuIDJLIGJ5dGVzLA0KPiB3ZSByZWFkL3dyaXRlIDJrIGRh
dGEgcmVwZWF0ZWRseSBieSBpc3N1aW5nIEZJUl9PUF9SQi9GSVJfT1BfV0IgYW5kIHNhdmUNCj4g
dGhlbSB0byBhIGxhcmdlIGJ1ZmZlci4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IExpdSBTaHVvIDxz
aHVvLmxpdUBmcmVlc2NhbGUuY29tPg0KPiAtLS0NCj4gdjM6DQo+ICAgICAtcmVtb3ZlIHBhZ2Vf
c2l6ZSBvZiBzdHJ1Y3QgZnNsX2VsYmNfbXRkLg0KPiAgICAgLWRvIGEgb29iIHdyaXRlIGJ5IE5B
TkRfQ01EX1JORElOLg0KPiANCj4gIGRyaXZlcnMvbXRkL25hbmQvZnNsX2VsYmNfbmFuZC5jIHwg
IDI0Mw0KPiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLQ0KPiAgMSBmaWxl
cyBjaGFuZ2VkLCAyMTggaW5zZXJ0aW9ucygrKSwgMjUgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZm
IC0tZ2l0IGEvZHJpdmVycy9tdGQvbmFuZC9mc2xfZWxiY19uYW5kLmMNCj4gYi9kcml2ZXJzL210
ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiBpbmRleCBkNjM0YzVmLi5hOTI0MTFhIDEwMDY0NA0K
PiAtLS0gYS9kcml2ZXJzL210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiArKysgYi9kcml2ZXJz
L210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KDQpbU05JUF0NCg0KPiBAQCAtNTAwLDYgKzY1NCw3
IEBAIHN0YXRpYyB2b2lkIGZzbF9lbGJjX2NtZGZ1bmMoc3RydWN0IG10ZF9pbmZvICptdGQsDQo+
IHVuc2lnbmVkIGludCBjb21tYW5kLA0KPiAgCQkgKiB3cml0ZS1wcm90ZWN0ZWQsIGV2ZW4gd2hl
biBpdCBpcyBub3QuDQo+ICAJCSAqLw0KPiAgCQlzZXRiaXRzOChlbGJjX2ZjbV9jdHJsLT5hZGRy
LCBOQU5EX1NUQVRVU19XUCk7DQo+ICsJCWVsYmNfZmNtX2N0cmwtPmJ1ZmZlclswXSA9IGluXzgo
ZWxiY19mY21fY3RybC0+YWRkcik7DQoNCltTaGVuZ3pob3VdIGFkZCBpZiAobXRkLT53cml0ZXNp
emUgPiAyMDQ4KSANCg0KPiAgCQlyZXR1cm47DQo+IA0KPiAgCS8qIFJFU0VUIHdpdGhvdXQgd2Fp
dGluZyBmb3IgdGhlIHJlYWR5IGxpbmUgKi8NCj4gQEAgLTU0OCw3ICs3MDMsMTQgQEAgc3RhdGlj
IHZvaWQgZnNsX2VsYmNfd3JpdGVfYnVmKHN0cnVjdCBtdGRfaW5mbyAqbXRkLA0KPiBjb25zdCB1
OCAqYnVmLCBpbnQgbGVuKQ0KPiAgCQlsZW4gPSBidWZzaXplIC0gZWxiY19mY21fY3RybC0+aW5k
ZXg7DQo+ICAJfQ0KPiANCj4gLQltZW1jcHlfdG9pbygmZWxiY19mY21fY3RybC0+YWRkcltlbGJj
X2ZjbV9jdHJsLT5pbmRleF0sIGJ1ZiwgbGVuKTsNCj4gKwlpZiAobXRkLT53cml0ZXNpemUgPiAy
MDQ4KSB7DQo+ICsJCW1lbWNweSgmZWxiY19mY21fY3RybC0+YnVmZmVyW2VsYmNfZmNtX2N0cmwt
PmluZGV4XSwNCj4gKwkJCQlidWYsIGxlbik7DQo+ICsJfSBlbHNlIHsNCj4gKwkJbWVtY3B5X3Rv
aW8oJmVsYmNfZmNtX2N0cmwtPmFkZHJbZWxiY19mY21fY3RybC0+aW5kZXhdLA0KPiArCQkJCWJ1
ZiwgbGVuKTsNCj4gKwl9DQo+ICsNCj4gIAkJc2V0Yml0czMyKCZsYmMtPmJhbmtbcHJpdi0+YmFu
a10ub3IsIE9SX0ZDTV9QR1MpOw0KPiAgCQkvKiBhZGp1c3QgZWNjIHNldHVwIGlmIG5lZWRlZCAq
Lw0KPiAgCQlpZiAoKGluX2JlMzIoJmxiYy0+YmFua1twcml2LT5iYW5rXS5icikgJiBCUl9ERUND
KSA9PQ0KPiBAQCAtODkxLDYgKzEwNzAsMTkgQEAgc3RhdGljIGludCBfX2RldmluaXQgZnNsX2Vs
YmNfbmFuZF9wcm9iZShzdHJ1Y3QNCj4gcGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiAgCQkJZ290
byBlcnI7DQo+ICAJCX0NCj4gIAkJZWxiY19mY21fY3RybC0+Y291bnRlcisrOw0KPiArCQkvKg0K
PiArCQkgKiBGcmVlc2NhbGUgRkNNIGNvbnRyb2xsZXIgaGFzIGEgMksgc2l6ZSBsaW1pdGF0aW9u
IG9mDQo+IGJ1ZmZlcg0KPiArCQkgKiBSQU0sIHNvIGVsYmNfZmNtX2N0cmwtPmJ1ZmZlciBoYXZl
IHRvIGJlIHVzZWQgaWYgd3JpdGVzaXplDQo+ICsJCSAqIG9mIGNoaXAgaXMgZ3JlYXRlciB0aGFu
IDIwNDguDQo+ICsJCSAqIFdlIG1hbGxvYyBhIGxhcmdlIGVub3VnaCBidWZmZXIgKG1heGltdW0g
cGFnZSBzaXplIGlzIDE2SykuDQo+ICsJCSAqLw0KPiArCQllbGJjX2ZjbV9jdHJsLT5idWZmZXIg
PSBrbWFsbG9jKDEwMjQgKiAxNiArIDEwMjQsIEdGUF9LRVJORUwpOw0KPiArCQlpZiAoIWVsYmNf
ZmNtX2N0cmwtPmJ1ZmZlcikgew0KPiArCQkJZGV2X2VycihkZXYsICJmYWlsZWQgdG8gYWxsb2Nh
dGUgbWVtb3J5XG4iKTsNCj4gKwkJCW11dGV4X3VubG9jaygmZnNsX2VsYmNfbmFuZF9tdXRleCk7
DQo+ICsJCQlyZXQgPSAtRU5PTUVNOw0KPiArCQkJZ290byBlcnI7DQo+ICsJCX0NCj4gDQpbU2hl
bmd6aG91XSANCkJlZm9yZSBjYWxsaW5nIG5hbmRfc2Nhbl9pZGVudCgpLCB3ZSBjYW4gc3RpbGwg
dXNlIDJrIEZDTSBSQU0sIG5vdCBuZWVkIGEgYnVmZmVyIGdyZWF0ZXIgdGhhbiAya6OsDQpBZnRl
ciBuYW5kX3NjYW5faWRlbnQoKSwgIGlmIHdyaXRlc2l6ZSA+IDIwNDgsIHRoZW4gYWxsb2NhdGUg
YSBsYXJnZSBidWZmZXIuDQpXZSBjYW4gZG8gaXQgaW4gZnNsX2VsYmNfY2hpcF9pbml0X3RhaWwo
KQ0KICBpZiAobXRkLT53cml0ZXNpemUgPiAyMDQ4KQ0KICAgICAgY3RybC0+YnVmZmVyID0ga21h
bGxvYyhtdGQtPndyaXRlc2l6ZSArIG10ZC0+b29ic2l6ZSwgR0ZQX0tFUk5FTCk7DQoNCg==
^ permalink raw reply
* Re: cpu idle time going backward
From: Andreas Schwab @ 2011-12-09 9:52 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <CAKTLLVTHHSDTxybfJn3r0JOeRGtxgzJyCwAFf8w8gDxqbuXbyA__24208.5847691216$1323374038$gmane$org@mail.gmail.com>
kevin diggs <diggskevin38@gmail.com> writes:
> On 12/8/11, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> There seems to be something wrong with cpu idle time accounting at least
>> on G5. The value as reported in the cpu lines in /proc/stat seems to be
>> stuck in the interval [100000,210000] for each cpu, jumping back at
>> random points. Any idea what could be the problem?
>>
>> Andreas.
>>
>> --
> What kernel versions?
It started with 3.2-rc1. Will try to bisect.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH 1/2] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
From: shuo.liu @ 2011-12-09 9:42 UTC (permalink / raw)
To: dwmw2, Artem.Bityutskiy, scottwood
Cc: linux-kernel, shuo.liu, linux-mtd, akpm, linuxppc-dev
From: Liu Shuo <b35362@freescale.com>
If we use the Nand flash chip whose number of pages in a block is greater
than 64(for large page), we must treat the low bit of FBAR as being the
high bit of the page address due to the limitation of FCM, it simply uses
the low 6-bits (for large page) of the combined block/page address as the
FPAR component, rather than considering the actual block size.
Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: Tang Yuantian <b29983@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 7db573e..d29479a 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -166,15 +166,22 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob)
elbc_fcm_ctrl->page = page_addr;
- out_be32(&lbc->fbar,
- page_addr >> (chip->phys_erase_shift - chip->page_shift));
-
if (priv->page_size) {
+ /*
+ * large page size chip : FPAR[PI] save the lowest 6 bits,
+ * FBAR[BLK] save the other bits.
+ */
+ out_be32(&lbc->fbar, page_addr >> 6);
out_be32(&lbc->fpar,
((page_addr << FPAR_LP_PI_SHIFT) & FPAR_LP_PI) |
(oob ? FPAR_LP_MS : 0) | column);
buf_num = (page_addr & 1) << 2;
} else {
+ /*
+ * small page size chip : FPAR[PI] save the lowest 5 bits,
+ * FBAR[BLK] save the other bits.
+ */
+ out_be32(&lbc->fbar, page_addr >> 5);
out_be32(&lbc->fpar,
((page_addr << FPAR_SP_PI_SHIFT) & FPAR_SP_PI) |
(oob ? FPAR_SP_MS : 0) | column);
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2 v4] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: shuo.liu @ 2011-12-09 9:42 UTC (permalink / raw)
To: dwmw2, Artem.Bityutskiy, scottwood
Cc: linux-kernel, shuo.liu, linux-mtd, akpm, linuxppc-dev
In-Reply-To: <1323423775-26951-1-git-send-email-shuo.liu@freescale.com>
From: Liu Shuo <shuo.liu@freescale.com>
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip whose page size is larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Signed-off-by: Liu Shuo <shuo.liu@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
v4 : allocate (8+1)k buffer for large page chip.
drivers/mtd/nand/fsl_elbc_nand.c | 246 ++++++++++++++++++++++++++++++++++----
1 files changed, 221 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index d29479a..9f58e78 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -55,7 +55,6 @@ struct fsl_elbc_mtd {
struct device *dev;
int bank; /* Chip select bank number */
u8 __iomem *vbase; /* Chip select base virtual address */
- int page_size; /* NAND page size (0=512, 1=2048) */
unsigned int fmr; /* FCM Flash Mode Register value */
};
@@ -75,6 +74,8 @@ struct fsl_elbc_fcm_ctrl {
unsigned int use_mdr; /* Non zero if the MDR is to be set */
unsigned int oob; /* Non zero if operating on OOB data */
unsigned int counter; /* counter for the initializations */
+
+ char *buffer; /* just be used when pagesize > 2048 */
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -150,6 +151,42 @@ static struct nand_bbt_descr bbt_mirror_descr = {
};
/*=================================*/
+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd->priv;
+ struct fsl_elbc_mtd *priv = chip->priv;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
+ void *src, *dst;
+ int len = (oob ? 64 : 2048);
+
+ if (oob)
+ dst = elbc_fcm_ctrl->buffer + mtd->writesize + subpage * 64;
+ else
+ dst = elbc_fcm_ctrl->buffer + subpage * 2048;
+
+ src = elbc_fcm_ctrl->addr + (oob ? 2048 : 0);
+ memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd->priv;
+ struct fsl_elbc_mtd *priv = chip->priv;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
+ void *src, *dst;
+ int len = (oob ? 64 : 2048);
+
+ if (oob)
+ src = elbc_fcm_ctrl->buffer + mtd->writesize + subpage * 64;
+ else
+ src = elbc_fcm_ctrl->buffer + subpage * 2048;
+
+ dst = elbc_fcm_ctrl->addr + (oob ? 2048 : 0);
+ memcpy_toio(dst, src, len);
+
+ /* See the in_8() in fsl_elbc_write_buf() */
+ in_8(elbc_fcm_ctrl->addr + (oob ? 2111 : 2047));
+}
/*
* Set up the FCM hardware block and page address fields, and the fcm
@@ -166,7 +203,7 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob)
elbc_fcm_ctrl->page = page_addr;
- if (priv->page_size) {
+ if (mtd->writesize >= 2048) {
/*
* large page size chip : FPAR[PI] save the lowest 6 bits,
* FBAR[BLK] save the other bits.
@@ -193,7 +230,7 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob)
/* for OOB data point to the second half of the buffer */
if (oob)
- elbc_fcm_ctrl->index += priv->page_size ? 2048 : 512;
+ elbc_fcm_ctrl->index += mtd->writesize;
dev_vdbg(priv->dev, "set_addr: bank=%d, "
"elbc_fcm_ctrl->addr=0x%p (0x%p), "
@@ -272,13 +309,14 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
return 0;
}
-static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
+static void fsl_elbc_do_read(struct mtd_info *mtd, int oob)
{
+ struct nand_chip *chip = mtd->priv;
struct fsl_elbc_mtd *priv = chip->priv;
struct fsl_lbc_ctrl *ctrl = priv->ctrl;
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
- if (priv->page_size) {
+ if (mtd->writesize >= 2048) {
out_be32(&lbc->fir,
(FIR_OP_CM0 << FIR_OP0_SHIFT) |
(FIR_OP_CA << FIR_OP1_SHIFT) |
@@ -311,6 +349,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
struct fsl_lbc_ctrl *ctrl = priv->ctrl;
struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+ int i, n;
elbc_fcm_ctrl->use_mdr = 0;
@@ -337,8 +376,30 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
elbc_fcm_ctrl->read_bytes = mtd->writesize + mtd->oobsize;
elbc_fcm_ctrl->index += column;
- fsl_elbc_do_read(chip, 0);
+ fsl_elbc_do_read(mtd, 0);
fsl_elbc_run_command(mtd);
+
+ if (mtd->writesize <= 2048)
+ return;
+
+ /* Continue to read the rest bytes if writesize > 2048 */
+ io_to_buffer(mtd, 0, 0);
+ io_to_buffer(mtd, 0, 1);
+
+ /*
+ * Maybe there are some reasons of FCM hardware timing,
+ * we must insert a FIR_OP_NOP(0x00) before FIR_OP_RB.
+ */
+ out_be32(&lbc->fir, (FIR_OP_NOP << FIR_OP0_SHIFT) |
+ (FIR_OP_RB << FIR_OP1_SHIFT));
+
+ n = mtd->writesize / 2048;
+ for (i = 1; i < n; i++) {
+ fsl_elbc_run_command(mtd);
+ io_to_buffer(mtd, i, 0);
+ io_to_buffer(mtd, i, 1);
+ }
+
return;
/* READOOB reads only the OOB because no ECC is performed. */
@@ -347,13 +408,38 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
"fsl_elbc_cmdfunc: NAND_CMD_READOOB, page_addr:"
" 0x%x, column: 0x%x.\n", page_addr, column);
- out_be32(&lbc->fbcr, mtd->oobsize - column);
- set_addr(mtd, column, page_addr, 1);
+ if (mtd->writesize <= 2048) {
+ out_be32(&lbc->fbcr, mtd->oobsize - column);
+ set_addr(mtd, column, page_addr, 1);
+ } else {
+ out_be32(&lbc->fbcr, 64);
+ set_addr(mtd, 0, page_addr, 1);
+ elbc_fcm_ctrl->index += column;
+ }
elbc_fcm_ctrl->read_bytes = mtd->writesize + mtd->oobsize;
- fsl_elbc_do_read(chip, 1);
+ fsl_elbc_do_read(mtd, 1);
fsl_elbc_run_command(mtd);
+
+ if (mtd->writesize <= 2048)
+ return;
+
+ if (column < 64)
+ io_to_buffer(mtd, 0, 1);
+
+ out_be32(&lbc->fbcr, 2112);
+ out_be32(&lbc->fpar, in_be32(&lbc->fpar) & ~FPAR_LP_MS);
+ out_be32(&lbc->fir, (FIR_OP_NOP << FIR_OP0_SHIFT) |
+ (FIR_OP_RB << FIR_OP1_SHIFT));
+
+ n = mtd->writesize / 2048;
+ for (i = 1; i < n; i++) {
+ fsl_elbc_run_command(mtd);
+ if (column < (64 * (i + 1)))
+ io_to_buffer(mtd, i, 1);
+ }
+
return;
/* READID must read all 5 possible bytes while CEB is active */
@@ -429,7 +515,17 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
(NAND_CMD_SEQIN << FCR_CMD2_SHIFT) |
(NAND_CMD_PAGEPROG << FCR_CMD3_SHIFT);
- if (priv->page_size) {
+ if (mtd->writesize > 2048) {
+ /* writesize > 2048 */
+ out_be32(&lbc->fir,
+ (FIR_OP_CM2 << FIR_OP0_SHIFT) |
+ (FIR_OP_CA << FIR_OP1_SHIFT) |
+ (FIR_OP_PA << FIR_OP2_SHIFT) |
+ (FIR_OP_WB << FIR_OP3_SHIFT));
+
+ if (elbc_fcm_ctrl->oob)
+ fcr |= NAND_CMD_RNDIN << FCR_CMD0_SHIFT;
+ } else if (mtd->writesize == 2048) {
out_be32(&lbc->fir,
(FIR_OP_CM2 << FIR_OP0_SHIFT) |
(FIR_OP_CA << FIR_OP1_SHIFT) |
@@ -464,6 +560,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
/* PAGEPROG reuses all of the setup from SEQIN and adds the length */
case NAND_CMD_PAGEPROG: {
+ int pos;
dev_vdbg(priv->dev,
"fsl_elbc_cmdfunc: NAND_CMD_PAGEPROG "
"writing %d bytes.\n", elbc_fcm_ctrl->index);
@@ -473,13 +570,74 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
* write so the HW generates the ECC.
*/
if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
- elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
- out_be32(&lbc->fbcr,
- elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
- else
+ elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) {
+ if (elbc_fcm_ctrl->oob && mtd->writesize > 2048) {
+ out_be32(&lbc->fbcr, 64);
+ } else {
+ out_be32(&lbc->fbcr, elbc_fcm_ctrl->index
+ - elbc_fcm_ctrl->column);
+ }
+ } else {
out_be32(&lbc->fbcr, 0);
+ }
+
+ if (mtd->writesize > 2048) {
+ if (!elbc_fcm_ctrl->oob)
+ buffer_to_io(mtd, 0, 0);
+ buffer_to_io(mtd, 0, 1);
+ }
fsl_elbc_run_command(mtd);
+
+ if (mtd->writesize <= 2048)
+ return;
+
+ n = mtd->writesize / 2048;
+
+ if (elbc_fcm_ctrl->oob) {
+ pos = 2048;
+ out_be32(&lbc->fir,
+ (FIR_OP_CM0 << FIR_OP0_SHIFT) |
+ (FIR_OP_UA << FIR_OP1_SHIFT) |
+ (FIR_OP_UA << FIR_OP2_SHIFT) |
+ (FIR_OP_WB << FIR_OP3_SHIFT));
+
+ for (i = 1; i < n; i++) {
+ pos += 2112;
+ elbc_fcm_ctrl->mdr = pos;
+ elbc_fcm_ctrl->use_mdr = 1;
+ if (i == n - 1) {
+ out_be32(&lbc->fir,
+ (FIR_OP_NOP << FIR_OP0_SHIFT) |
+ (FIR_OP_CM0 << FIR_OP1_SHIFT) |
+ (FIR_OP_UA << FIR_OP2_SHIFT) |
+ (FIR_OP_UA << FIR_OP3_SHIFT) |
+ (FIR_OP_WB << FIR_OP4_SHIFT) |
+ (FIR_OP_CM3 << FIR_OP5_SHIFT) |
+ (FIR_OP_CW1 << FIR_OP6_SHIFT) |
+ (FIR_OP_RS << FIR_OP7_SHIFT));
+ }
+ buffer_to_io(mtd, i, 1);
+ fsl_elbc_run_command(mtd);
+ }
+ } else {
+ out_be32(&lbc->fir, FIR_OP_WB << FIR_OP1_SHIFT);
+ for (i = 1; i < n; i++) {
+ if (i == n - 1) {
+ elbc_fcm_ctrl->use_mdr = 1;
+ out_be32(&lbc->fir,
+ (FIR_OP_NOP << FIR_OP0_SHIFT) |
+ (FIR_OP_WB << FIR_OP1_SHIFT) |
+ (FIR_OP_CM3 << FIR_OP2_SHIFT) |
+ (FIR_OP_CW1 << FIR_OP3_SHIFT) |
+ (FIR_OP_RS << FIR_OP4_SHIFT));
+ }
+ buffer_to_io(mtd, i, 0);
+ buffer_to_io(mtd, i, 1);
+ fsl_elbc_run_command(mtd);
+ }
+ }
+
return;
}
@@ -500,6 +658,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
* write-protected, even when it is not.
*/
setbits8(elbc_fcm_ctrl->addr, NAND_STATUS_WP);
+ elbc_fcm_ctrl->buffer[0] = in_8(elbc_fcm_ctrl->addr);
return;
/* RESET without waiting for the ready line */
@@ -548,7 +707,14 @@ static void fsl_elbc_write_buf(struct mtd_info *mtd, const u8 *buf, int len)
len = bufsize - elbc_fcm_ctrl->index;
}
- memcpy_toio(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], buf, len);
+ if (mtd->writesize > 2048) {
+ memcpy(&elbc_fcm_ctrl->buffer[elbc_fcm_ctrl->index],
+ buf, len);
+ } else {
+ memcpy_toio(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index],
+ buf, len);
+ }
+
/*
* This is workaround for the weird elbc hangs during nand write,
* Scott Wood says: "...perhaps difference in how long it takes a
@@ -572,8 +738,13 @@ static u8 fsl_elbc_read_byte(struct mtd_info *mtd)
struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
/* If there are still bytes in the FCM, then use the next byte. */
- if (elbc_fcm_ctrl->index < elbc_fcm_ctrl->read_bytes)
- return in_8(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index++]);
+ if (elbc_fcm_ctrl->index < elbc_fcm_ctrl->read_bytes) {
+ int index = elbc_fcm_ctrl->index++;
+ if (mtd->writesize > 2048)
+ return elbc_fcm_ctrl->buffer[index];
+ else
+ return in_8(&elbc_fcm_ctrl->addr[index]);
+ }
dev_err(priv->dev, "read_byte beyond end of buffer\n");
return ERR_BYTE;
@@ -594,7 +765,13 @@ static void fsl_elbc_read_buf(struct mtd_info *mtd, u8 *buf, int len)
avail = min((unsigned int)len,
elbc_fcm_ctrl->read_bytes - elbc_fcm_ctrl->index);
- memcpy_fromio(buf, &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], avail);
+ if (mtd->writesize > 2048) {
+ memcpy(buf, &elbc_fcm_ctrl->buffer[elbc_fcm_ctrl->index],
+ avail);
+ } else {
+ memcpy_fromio(buf, &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index],
+ avail);
+ }
elbc_fcm_ctrl->index += avail;
if (len > avail)
@@ -630,10 +807,17 @@ static int fsl_elbc_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
return -EINVAL;
}
- for (i = 0; i < len; i++)
- if (in_8(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index + i])
- != buf[i])
- break;
+ if (mtd->writesize > 2048) {
+ for (i = 0; i < len; i++)
+ if (elbc_fcm_ctrl->buffer[elbc_fcm_ctrl->index + i]
+ != buf[i])
+ break;
+ } else {
+ for (i = 0; i < len; i++)
+ if (in_8(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index + i])
+ != buf[i])
+ break;
+ }
elbc_fcm_ctrl->index += len;
return i == len && elbc_fcm_ctrl->status == LTESR_CC ? 0 : -EIO;
@@ -714,10 +898,8 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
/* adjust Option Register and ECC to match Flash page size */
if (mtd->writesize == 512) {
- priv->page_size = 0;
clrbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
- } else if (mtd->writesize == 2048) {
- priv->page_size = 1;
+ } else if (mtd->writesize >= 2048 && mtd->writesize <= 8192) {
setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
/* adjust ecc setup if needed */
if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
@@ -891,6 +1073,19 @@ static int __devinit fsl_elbc_nand_probe(struct platform_device *pdev)
goto err;
}
elbc_fcm_ctrl->counter++;
+ /*
+ * Freescale FCM controller has a 2K size limitation of buffer
+ * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
+ * of chip is greater than 2048.
+ * We malloc a large enough buffer (maximum page size is 8K).
+ */
+ elbc_fcm_ctrl->buffer = kmalloc(1024 * 8 + 1024, GFP_KERNEL);
+ if (!elbc_fcm_ctrl->buffer) {
+ dev_err(dev, "failed to allocate memory\n");
+ mutex_unlock(&fsl_elbc_nand_mutex);
+ ret = -ENOMEM;
+ goto err;
+ }
spin_lock_init(&elbc_fcm_ctrl->controller.lock);
init_waitqueue_head(&elbc_fcm_ctrl->controller.wq);
@@ -960,6 +1155,7 @@ static int fsl_elbc_nand_remove(struct platform_device *pdev)
elbc_fcm_ctrl->counter--;
if (!elbc_fcm_ctrl->counter) {
fsl_lbc_ctrl_dev->nand = NULL;
+ kfree(elbc_fcm_ctrl->buffer);
kfree(elbc_fcm_ctrl);
}
mutex_unlock(&fsl_elbc_nand_mutex);
--
1.7.1
^ permalink raw reply related
* Unable to connect via Ethernet on P1022RDK
From: Arshad, Farrukh @ 2011-12-09 11:19 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 4529 bytes --]
Greetings All,
I am doing a dual boot on P1022RDK with following configuration
Core 0: Linux RT: Running fine, ethernet@B0000 is working fine.
Core 1: Linux: Crashing at following, ethernet@B1000 is not creating a link
I have allocated ethernet1 to core 1 in its DTS file but when I boot my kernel over NFS there seems no link and kernel crashes at following
[ 2.812122] rxbd[7]: addr,vaddr=0x1f70fc00,0xcf70fc00
[ 3.821896] IP-Config: Guessing netmask 255.255.0.0
[ 3.826931] IP-Config: Complete:
[ 3.829992] device=eth0, addr=137.202.156.128, mask=255.255.0.0, gw=137.202.156.191,
[ 3.838109] host=137.202.156.128, domain=, nis-domain=(none),
[ 3.844292] bootserver=255.255.255.255, rootserver=137.202.156.191, rootpath=
[ 3.852308] Looking up port of RPC 100003/2 on 137.202.156.191
OK
[ 38.857888] rpcbind: server 137.202.156.191 not responding, timed out
[ 38.864387] Root-NFS: Unable to get nfsd port number from server, using default
[ 38.871708] Looking up port of RPC 100005/1 on 137.202.156.191
[ 73.873886] rpcbind: server 137.202.156.191 not responding, timed out
[ 73.880382] Root-NFS: Unable to get mountd port number from server, using default
Given is my DTS files for both cores.
Core 1 DTS: ethernet1 is not creating a link
mdio@25000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,etsec2-mdio";
reg = <0x25000 0x1000 0xb1030 0x4>;
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <9 1>;
reg = <0x2>;
};
};
enet1: ethernet@B1000 {
#address-cells = <1>;
#size-cells = <1>;
cell-index = <0>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
clk-handle = <&etsec2_clk>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
//fixed-link = <1 1 1000 0 0>;
fixed-link = <1 1 100 0 0>;
//phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
queue-group@0{
#address-cells = <1>;
#size-cells = <1>;
reg = <0xB1000 0x1000>;
interrupts = <35 2 36 2 40 2>;
};
queue-group@1{
#address-cells = <1>;
#size-cells = <1>;
reg = <0xB5000 0x1000>;
interrupts = <51 2 52 2 67 2>;
};
};
Core 0 DTS file. Running smooth
mdio@24000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,etsec2-mdio";
reg = <0x24000 0x1000 0xb0030 0x4>;
phy0: ethernet-phy@0 {
interrupts = <3 1>;
reg = <0x1>;
};
};
enet0: ethernet@B0000 {
#address-cells = <1>;
#size-cells = <1>;
cell-index = <0>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
fsl,wake-on-filer;
clk-handle = <&etsec1_clk>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
phy-connection-type = "rgmii-id";
queue-group@0{
#address-cells = <1>;
#size-cells = <1>;
reg = <0xB0000 0x1000>;
interrupts = <29 2 30 2 34 2>;
};
queue-group@1{
#address-cells = <1>;
#size-cells = <1>;
reg = <0xB4000 0x1000>;
interrupts = <17 2 18 2 24 2>;
};
};
Any thoughts on what I am doing wrong.
Best Regards
Farrukh Arshad
[-- Attachment #2: Type: text/html, Size: 23047 bytes --]
^ permalink raw reply
* [PATCH v4 0/7] Kudmp support for PPC440x
From: Suzuki K. Poulose @ 2011-12-09 11:43 UTC (permalink / raw)
To: Josh Boyer, Benjamin Herrenschmidt
Cc: Scott Wood, Josh Poimboeuf, linux ppc dev
The following series implements:
* Generic framework for relocatable kernel on PPC32, based on processing
the dynamic relocation entries.
* Relocatable kernel support for 44x
* Kdump support for 44x. Doesn't support 47x yet, as the kexec
support is missing.
Changes from V3:
* Added a new config - NONSTATIC_KERNEL - to group different types of relocatable
kernel. (Suggested by: Josh Boyer)
* Added supported ppc relocation types in relocs_check.pl for verifying the
relocations used in the kernel.
Changes from V2:
* Renamed old style mapping based RELOCATABLE on BookE to DYNAMIC_MEMSTART.
Suggested by: Scott Wood
* Added support for DYNAMIC_MEMSTART on PPC440x
* Reverted back to RELOCATABLE and RELOCATABLE_PPC32 from RELOCATABLE_PPC32_PIE
for relocation based on processing dynamic reloc entries for PPC32.
* Ensure the modified instructions are flushed and the i-cache invalidated at
the end of relocate(). - Reported by : Josh Poimboeuf
Changes from V1:
* Splitted patch 'Enable CONFIG_RELOCATABLE for PPC44x' to move some
of the generic bits to a new patch.
* Renamed RELOCATABLE_PPC32 to RELOCATABLE_PPC32_PIE and provided options to
retained old style mapping. (Suggested by: Scott Wood)
* Added support for avoiding the overlapping of uncompressed kernel
with boot wrapper for PPC images.
The patches are based on -next tree for ppc.
I have tested these patches on Ebony, Sequoia and Virtex(QEMU Emulated).
I haven't tested the RELOCATABLE bits on PPC_47x yet, as I don't have access
to one. However, RELOCATABLE should work fine there as we only depend on the
runtime address and the XLAT entry setup by the boot loader. It would be great if
somebody could test these patches on a 47x.
---
Suzuki K. Poulose (7):
[boot] Change the load address for the wrapper to fit the kernel
[44x] Enable CRASH_DUMP for 440x
[44x] Enable CONFIG_RELOCATABLE for PPC44x
[ppc] Define virtual-physical translations for RELOCATABLE
[ppc] Process dynamic relocations for kernel
[44x] Enable DYNAMIC_MEMSTART for 440x
[booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
arch/powerpc/Kconfig | 46 +++++++++--
arch/powerpc/Makefile | 6 +
arch/powerpc/boot/wrapper | 20 +++++
arch/powerpc/configs/44x/iss476-smp_defconfig | 2
arch/powerpc/include/asm/kdump.h | 4 -
arch/powerpc/include/asm/page.h | 89 ++++++++++++++++++++-
arch/powerpc/kernel/Makefile | 2
arch/powerpc/kernel/crash_dump.c | 4 -
arch/powerpc/kernel/head_44x.S | 105 +++++++++++++++++++++++++
arch/powerpc/kernel/head_fsl_booke.S | 2
arch/powerpc/kernel/machine_kexec.c | 2
arch/powerpc/kernel/prom_init.c | 2
arch/powerpc/kernel/vmlinux.lds.S | 8 ++
arch/powerpc/mm/44x_mmu.c | 2
arch/powerpc/mm/init_32.c | 7 ++
arch/powerpc/relocs_check.pl | 7 ++
16 files changed, 282 insertions(+), 26 deletions(-)
--
Suzuki
^ 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