* emac/zmii link warnings
From: Sean MacLennan @ 2008-01-15 4:15 UTC (permalink / raw)
To: linuxppc-dev
I keep getting these link(?) warnings:
WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
WARNING: vmlinux.o(.init.text+0x16ba8): Section mismatch: reference to .exit.text:zmii_detach (between 'emac_probe' and 'zmii_probe')
WARNING: vmlinux.o(.init.text+0x16bb4): Section mismatch: reference to .exit.text:mal_unregister_commac (between 'emac_probe' and 'zmii_probe')
Any hints as to what might be wrong? Or are they "normal".
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Ensure we only handle PowerMac PCI bus fixup for memory resources
From: Benjamin Herrenschmidt @ 2008-01-15 4:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801142044280.32246@blarg.am.freescale.net>
On Mon, 2008-01-14 at 20:44 -0600, Kumar Gala wrote:
> The fixup code that handles the case for PowerMac's that leave bridge
> windows open over an inaccessible region should only be applied to
> memory resources (IORESOURCE_MEM). If not we can get it trying to fixup
> IORESOURCE_IO on some systems since the other conditions that are used to
> detect the case can easily match for IORESOURCE_IO.
>
> ---
Ack.
> in my git tree.
>
> arch/powerpc/kernel/pci-common.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index d394d41..7d0afd4 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -806,7 +806,8 @@ static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
> * equal to the pci_mem_offset of the host bridge and
> * their size is smaller than 1M.
> */
> - if (res->start == hose->pci_mem_offset &&
> + if (res->flags & IORESOURCE_MEM &&
> + res->start == hose->pci_mem_offset &&
> res->end < 0x100000) {
> printk(KERN_INFO
> "PCI: Closing bogus Apple Firmware"
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fixup transparent P2P resources
From: Benjamin Herrenschmidt @ 2008-01-15 4:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801142045010.32246@blarg.am.freescale.net>
On Mon, 2008-01-14 at 20:45 -0600, Kumar Gala wrote:
> For transparent P2P bridges the first 3 resources may get set from based on
> BAR registers and need to get fixed up. Where as the remainder come from the
> parent bus and have already been fixed up.
Ack.
> ---
>
> in my git tree.
>
> arch/powerpc/kernel/pci-common.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index 7d0afd4..980fe32 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -792,9 +792,10 @@ static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
> for (i = 0; i < PCI_BUS_NUM_RESOURCES; ++i) {
> if ((res = bus->resource[i]) == NULL)
> continue;
> - if (!res->flags || bus->self->transparent)
> + if (!res->flags)
> + continue;
> + if (i >= 3 && bus->self->transparent)
> continue;
> -
> /* On PowerMac, Apple leaves bridge windows open over
> * an inaccessible region of memory space (0...fffff)
> * which is somewhat bogus, but that's what they think
^ permalink raw reply
* Re: [PATCH] [POWERPC] Remove update_bridge_resource
From: Benjamin Herrenschmidt @ 2008-01-15 4:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801142046040.32246@blarg.am.freescale.net>
On Mon, 2008-01-14 at 20:46 -0600, Kumar Gala wrote:
> The 85xx/86xx pci code no longer uses update_bridge_resource and it was the
> only caller.
Ack.
> ---
>
> in my git tree.
>
> arch/powerpc/kernel/pci_32.c | 58 --------------------------------------
> include/asm-powerpc/pci-bridge.h | 3 --
> 2 files changed, 0 insertions(+), 61 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
> index a9c6cb2..1698beb 100644
> --- a/arch/powerpc/kernel/pci_32.c
> +++ b/arch/powerpc/kernel/pci_32.c
> @@ -93,64 +93,6 @@ fixup_cpc710_pci64(struct pci_dev* dev)
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CPC710_PCI64, fixup_cpc710_pci64);
>
> -
> -void __init
> -update_bridge_resource(struct pci_dev *dev, struct resource *res)
> -{
> - u8 io_base_lo, io_limit_lo;
> - u16 mem_base, mem_limit;
> - u16 cmd;
> - resource_size_t start, end, off;
> - struct pci_controller *hose = dev->sysdata;
> -
> - if (!hose) {
> - printk("update_bridge_base: no hose?\n");
> - return;
> - }
> - pci_read_config_word(dev, PCI_COMMAND, &cmd);
> - pci_write_config_word(dev, PCI_COMMAND,
> - cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY));
> - if (res->flags & IORESOURCE_IO) {
> - off = (unsigned long) hose->io_base_virt - isa_io_base;
> - start = res->start - off;
> - end = res->end - off;
> - io_base_lo = (start >> 8) & PCI_IO_RANGE_MASK;
> - io_limit_lo = (end >> 8) & PCI_IO_RANGE_MASK;
> - if (end > 0xffff)
> - io_base_lo |= PCI_IO_RANGE_TYPE_32;
> - else
> - io_base_lo |= PCI_IO_RANGE_TYPE_16;
> - pci_write_config_word(dev, PCI_IO_BASE_UPPER16,
> - start >> 16);
> - pci_write_config_word(dev, PCI_IO_LIMIT_UPPER16,
> - end >> 16);
> - pci_write_config_byte(dev, PCI_IO_BASE, io_base_lo);
> - pci_write_config_byte(dev, PCI_IO_LIMIT, io_limit_lo);
> -
> - } else if ((res->flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH))
> - == IORESOURCE_MEM) {
> - off = hose->pci_mem_offset;
> - mem_base = ((res->start - off) >> 16) & PCI_MEMORY_RANGE_MASK;
> - mem_limit = ((res->end - off) >> 16) & PCI_MEMORY_RANGE_MASK;
> - pci_write_config_word(dev, PCI_MEMORY_BASE, mem_base);
> - pci_write_config_word(dev, PCI_MEMORY_LIMIT, mem_limit);
> -
> - } else if ((res->flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH))
> - == (IORESOURCE_MEM | IORESOURCE_PREFETCH)) {
> - off = hose->pci_mem_offset;
> - mem_base = ((res->start - off) >> 16) & PCI_PREF_RANGE_MASK;
> - mem_limit = ((res->end - off) >> 16) & PCI_PREF_RANGE_MASK;
> - pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, mem_base);
> - pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, mem_limit);
> -
> - } else {
> - DBG(KERN_ERR "PCI: ugh, bridge %s res has flags=%lx\n",
> - pci_name(dev), res->flags);
> - }
> - pci_write_config_word(dev, PCI_COMMAND, cmd);
> -}
> -
> -
> #ifdef CONFIG_PPC_OF
> /*
> * Functions below are used on OpenFirmware machines.
> diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
> index 9b16d3b..d644452 100644
> --- a/include/asm-powerpc/pci-bridge.h
> +++ b/include/asm-powerpc/pci-bridge.h
> @@ -152,9 +152,6 @@ extern void setup_indirect_pci(struct pci_controller* hose,
> resource_size_t cfg_addr,
> resource_size_t cfg_data, u32 flags);
> extern void setup_grackle(struct pci_controller *hose);
> -extern void __init update_bridge_resource(struct pci_dev *dev,
> - struct resource *res);
> -
> #else /* CONFIG_PPC64 */
>
> /*
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fixup use of phys_addr_t in mpic code
From: Benjamin Herrenschmidt @ 2008-01-15 4:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801142058100.32559@blarg.am.freescale.net>
On Mon, 2008-01-14 at 20:58 -0600, Kumar Gala wrote:
> From: Becky Bruce <becky.bruce@freescale.com>
>
> The mpic_map() and __mpic_map_mmio() need to use phys_addr_t for the
> physical address they are passed.
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Ack. (or use resource_size_t, as you prefer).
> ---
> arch/powerpc/sysdev/mpic.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index f88ff09..0da7069 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -267,7 +267,7 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
> */
>
>
> -static void _mpic_map_mmio(struct mpic *mpic, unsigned long phys_addr,
> +static void _mpic_map_mmio(struct mpic *mpic, phys_addr_t phys_addr,
> struct mpic_reg_bank *rb, unsigned int offset,
> unsigned int size)
> {
> @@ -287,7 +287,7 @@ static void _mpic_map_dcr(struct mpic *mpic, struct mpic_reg_bank *rb,
> BUG_ON(!DCR_MAP_OK(rb->dhost));
> }
>
> -static inline void mpic_map(struct mpic *mpic, unsigned long phys_addr,
> +static inline void mpic_map(struct mpic *mpic, phys_addr_t phys_addr,
> struct mpic_reg_bank *rb, unsigned int offset,
> unsigned int size)
> {
^ permalink raw reply
* Re: emac/zmii link warnings
From: Stephen Rothwell @ 2008-01-15 4:27 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478C336D.2080307@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> I keep getting these link(?) warnings:
>
> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
emac_of_bus_notify is marked __devinit and is referred to by
emac_of_bus_notifier (which is not marked thus) (in
drivers/net/ibm_newemac/core.c).
> WARNING: vmlinux.o(.init.text+0x16ba8): Section mismatch: reference to .exit.text:zmii_detach (between 'emac_probe' and 'zmii_probe')
> WARNING: vmlinux.o(.init.text+0x16bb4): Section mismatch: reference to .exit.text:mal_unregister_commac (between 'emac_probe' and 'zmii_probe')
These will be similar but function calls.
> Any hints as to what might be wrong? Or are they "normal".
They need to be fixed.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: emac/zmii link warnings
From: Sean MacLennan @ 2008-01-15 4:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115152748.d0a05e1b.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>> I keep getting these link(?) warnings:
>>
>> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
>>
>
> emac_of_bus_notify is marked __devinit and is referred to by
> emac_of_bus_notifier (which is not marked thus) (in
> drivers/net/ibm_newemac/core.c).
>
Adding the __devinit to emacs_of_bus_notifier causes a problem with
emac_phy_map_lock (a mutex). But removing the __devinit from
emac_of_bus_notify cleans up that warning. Is the __devinit really
necessary?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Stefan Roese @ 2008-01-15 5:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <478BC05C.2080007@pikatech.com>
On Monday 14 January 2008, Sean MacLennan wrote:
> Stefan Roese wrote:
> > And the EBC0_BxCR & EBC0BxAP registers for the CS where the NAND is
> > connected? How are they configured?
>
> EBC0_B1CR d001c000
> EBC0_B1AP 18003c0
>
> Which matches the defines in include/configs/warp.h:
>
> #define CFG_EBC_PB1AP 0x018003c0
> #define CFG_EBC_PB1CR (CFG_NAND_ADDR | 0x1c000)
>
> It also matches the defines in sequoia.h except that we are on CS1 and
> the sequoia is on CS3.
Right. One thing I noticed though is, that you map the NAND to 0xd0000000,
which is reserved for PCI in the 440EP address space. I suggest you map it to
0x90000000 as done on Bamboo. Please give it a try and let me know if this
changes the 32bit access behavior.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Kumar Gala @ 2008-01-15 5:22 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080114000113.GA14801@localhost.localdomain>
On Jan 13, 2008, at 6:01 PM, David Gibson wrote:
> On Fri, Jan 11, 2008 at 02:07:05PM -0600, Scott Wood wrote:
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> [snip]
>> + aliases {
>> + console = &console;
>> + enet0 = ð0;
>> + enet1 = ð1;
>
> I think most other boards are settling on aliases "ethernet0"
> etc. instead of "enet0" (though there's no reason you couldn't have
> both.
We should use ethernet0 since its based on the standard naming
convention.
- k
^ permalink raw reply
* Re: emac/zmii link warnings
From: Stephen Rothwell @ 2008-01-15 5:26 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478C3A5D.5080209@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Mon, 14 Jan 2008 23:45:17 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> Stephen Rothwell wrote:
> > On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
> >
> >> I keep getting these link(?) warnings:
> >>
> >> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
>
> > emac_of_bus_notify is marked __devinit and is referred to by
> > emac_of_bus_notifier (which is not marked thus) (in
> > drivers/net/ibm_newemac/core.c).
>
> Adding the __devinit to emacs_of_bus_notifier causes a problem with
> emac_phy_map_lock (a mutex). But removing the __devinit from
> emac_of_bus_notify cleans up that warning. Is the __devinit really
> necessary?
What problem do you get. The correct fix is to mark emac_of_bus_notifier
as __devinitdata. The __devinit marking of emac_of_bus_notify is not
strictly necessary, but some people care about the size of their kernels.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: emac/zmii link warnings
From: Sean MacLennan @ 2008-01-15 5:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115152748.d0a05e1b.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>> I keep getting these link(?) warnings:
>>
>> WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to .init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and 'emac_phy_map_lock')
>>
>
> emac_of_bus_notify is marked __devinit and is referred to by
> emac_of_bus_notifier (which is not marked thus) (in
> drivers/net/ibm_newemac/core.c).
>
>
The __devinitdata solves this.
>> WARNING: vmlinux.o(.init.text+0x16ba8): Section mismatch: reference to .exit.text:zmii_detach (between 'emac_probe' and 'zmii_probe')
>> WARNING: vmlinux.o(.init.text+0x16bb4): Section mismatch: reference to .exit.text:mal_unregister_commac (between 'emac_probe' and 'zmii_probe')
>>
>
> These will be similar but function calls.
>
>
The problem here is that emac_probe calls zmii_detach. emacs_probe is a
__devinit and zmii_detach is a __devexit. At least I assume that is the
problem.
I am a long time emacs (actually xemacs) user. If I had a nickel for
every time I typed emacs rather than emac, I would be a very rich man.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-15 6:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801150615.19910.sr@denx.de>
Stefan Roese wrote:
>
> Right. One thing I noticed though is, that you map the NAND to 0xd0000000,
> which is reserved for PCI in the 440EP address space. I suggest you map it to
> 0x90000000 as done on Bamboo. Please give it a try and let me know if this
> changes the 32bit access behavior.
>
I think I changed it right. The following code is obviously a hack:
static int warp_setup_nand_flash(void)
{
unsigned data;
mfebc(0x1, data);
printk("EBC0_B1CR %x\n", data); // SAM DBG
data = 0x9001c000;
mtebc(0x1, data);
mfebc(0x1, data);
printk("after EBC0_B1CR %x\n", data); // SAM DBG
mfebc(0x11, data);
printk("EBC0_B1AP %x\n", data); // SAM DBG
platform_device_register(&warp_ndfc_device);
platform_device_register(&warp_nand_device);
return 0;
}
device_initcall(warp_setup_nand_flash);
Then change the NAND base offset to 90000000. This change made no
difference. It still works with 8-bit access and fails with 32-bit. The
mtebc and mfebc macros where taken from u-boot.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Stefan Roese @ 2008-01-15 6:39 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478C5309.7040805@pikatech.com>
On Tuesday 15 January 2008, Sean MacLennan wrote:
> Stefan Roese wrote:
> > Right. One thing I noticed though is, that you map the NAND to
> > 0xd0000000, which is reserved for PCI in the 440EP address space. I
> > suggest you map it to 0x90000000 as done on Bamboo. Please give it a try
> > and let me know if this changes the 32bit access behavior.
>
> I think I changed it right. The following code is obviously a hack:
>
> static int warp_setup_nand_flash(void)
> {
> unsigned data;
>
> mfebc(0x1, data);
> printk("EBC0_B1CR %x\n", data); // SAM DBG
>
> data = 0x9001c000;
> mtebc(0x1, data);
>
> mfebc(0x1, data);
> printk("after EBC0_B1CR %x\n", data); // SAM DBG
>
> mfebc(0x11, data);
> printk("EBC0_B1AP %x\n", data); // SAM DBG
>
> platform_device_register(&warp_ndfc_device);
> platform_device_register(&warp_nand_device);
>
> return 0;
> }
> device_initcall(warp_setup_nand_flash);
>
>
> Then change the NAND base offset to 90000000. This change made no
> difference. It still works with 8-bit access and fails with 32-bit. The
> mtebc and mfebc macros where taken from u-boot.
Bummer! Was worth a try though. I still don't see why this should fail on your
platform. What error/exception do you get upon 32bit access btw?
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-15 7:09 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 277 +++++++++++++++++++++++++++++++++++
1 files changed, 277 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/haleakala.dts
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
new file mode 100644
index 0000000..b8ac021
--- /dev/null
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -0,0 +1,277 @@
+/*
+ * Device Tree Source for AMCC Haleakala (405EXr)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * 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.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,haleakala";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,405EXr";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405exr", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405exr", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405exr";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405exr", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405exr", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <80000000 80000000 10000000
+ ef600000 ef600000 a00000
+ f0000000 f0000000 10000000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405exr", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <200000 200000>;
+ };
+ partition@400000 {
+ label = "user";
+ reg = <400000 3b60000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-405exr", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405exr", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIE0: pciex@0a0000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <a0000000 20000000 /* Config space access */
+ ef000000 00001000>; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 90000000 0 08000000
+ 01000000 0 00000000 e0000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 80000000>;
+
+ /* This drives busses 0x00 to 0x3f */
+ bus-range = <00 3f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC2 0 4 /* swizzled int A */
+ 0000 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0000 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0000 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Stefan Roese @ 2008-01-15 7:09 UTC (permalink / raw)
To: linuxppc-dev
This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
is a 405EX with only one EMAC and only one PCIe interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/kernel/cputable.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index f1928af..dfb84c8 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1178,8 +1178,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.platform = "ppc405",
},
{ /* 405EX */
- .pvr_mask = 0xffff0000,
- .pvr_value = 0x12910000,
+ .pvr_mask = 0xffff0004,
+ .pvr_value = 0x12910004,
.cpu_name = "405EX",
.cpu_features = CPU_FTRS_40X,
.cpu_user_features = PPC_FEATURE_32 |
@@ -1189,6 +1189,18 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_4xx,
.platform = "ppc405",
},
+ { /* 405EXr */
+ .pvr_mask = 0xffff0004,
+ .pvr_value = 0x12910000,
+ .cpu_name = "405EXr",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc405",
+ },
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
--
1.5.4.rc3
^ permalink raw reply related
* Re: Problem booting Linux 2.6 on Virtex-4
From: Enno Lübbers @ 2008-01-15 7:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <440abda90801141614u777edfbndc5d2c61f927dd4f@mail.gmail.com>
Hi David,
Am 15.01.2008 um 01:14 schrieb David Baird:
> Today, I tried a completely fresh design in EDK 9.2i (whereas I had
> been using 9.1i). I tried the design found in
> EDKexamples/Virtex4_PPC_Example_9_2.zip. This design works :-) I am
> not sure why it works (or rather, why the other one did not work), but
> it works.
I'm using EDK 9.1i with the reference design from the Xilinx website (www.xilinx.com/ml403)
. This one is using a PLB BRAM controller for the bootup code section,
not an OCM BRAM. Maybe there's something wrong with the OCM
controller? Though OCM is not cached at all...
Anyway, glad it worked out.
Regards
- Enno
--
Dipl.-Ing. Enno Luebbers
Computer Engineering Group
University of Paderborn
Warburger Str. 100
33098 Paderborn
http://wwwcs.upb.de/cs/ag-platzner
phone: 05251 / 60-5397
fax: 05251 / 60-5377
^ permalink raw reply
* Problems with serial and DHCP when booting from NFS
From: lipeng @ 2008-01-15 8:09 UTC (permalink / raw)
To: Linuxppc-embedded
Hi all,
I am porting a MontaVista Linux for PPC405 and encountering some problems. I hope someone can help me find it out.
1. About the serial port. I have solved this problem, but I don't know why. If I set "Initial Kernel Command String" as "console=ttyS0,19200 ip=on nfsroot=[my_nfsroot] rw", after outputing "Now booting the kernel" in the booting process, the booting kernel seems hanging there. In fact, when I checked the log of DHCP server, I found the PPC had already sent DHCP requests. It can be infered that the kernel had been booted but serial had something wrong, so no other information was output after "Now booting the kernel". If I set "Initial Kernel Command String" as "ip=on nfsroot=[my_nfsroot] rw", the booting information will appear on the terminal window correctly after "Now booting the kernel". I don't know why. I use Uart Lite and the baud rate is 19200.
2. About the DHCP. The kernel is boot from NFS, so I enabled the DHCP. From the information on terminal window, I knew that DHCP requests were always time out and the client kept retrying. But when I checked the log of DHCP server, I found the server had already offered IP to the client kernel. It seems the client kernel has some problem to receive the DHCP offer, has anyone encountered similar problems? How to solve this problem?
Thanks.
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-01-15 10:19 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more bug fixes for powerpc. One is a fix for a recently
introduced regression which means that the kernel doesn't boot on
POWER6 machines. The other is a fix for something that got broken
back in the 2.6.19 timeframe.
Thanks,
Paul.
arch/powerpc/kernel/iommu.c | 17 ++++++++++++++---
arch/powerpc/mm/slb.c | 10 ++--------
arch/powerpc/platforms/pseries/lpar.c | 1 -
include/asm-powerpc/mmu-hash64.h | 1 -
4 files changed, 16 insertions(+), 13 deletions(-)
commit dfbe0d3b6be52596b5694b1bb75b19562e769021
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Jan 15 17:29:33 2008 +1100
[POWERPC] Fix boot failure on POWER6
Commit 473980a99316c0e788bca50996375a2815124ce1 added a call to clear
the SLB shadow buffer before registering it. Unfortunately this means
that we clear out the entries that slb_initialize has previously set in
there. On POWER6, the hypervisor uses the SLB shadow buffer when doing
partition switches, and that means that after the next partition switch,
each non-boot CPU has no SLB entries to map the kernel text and data,
which causes it to crash.
This fixes it by reverting most of 473980a9 and instead clearing the
3rd entry explicitly in slb_initialize. This fixes the problem that
473980a9 was trying to solve, but without breaking POWER6.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d262c32a4bcc3e5fda0325a64e53c25fe1e999d7
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Jan 8 10:34:22 2008 +1100
[POWERPC] Workaround for iommu page alignment
Commit 5d2efba64b231a1733c4048d1708d77e07f26426 changed our iommu code
so that it always uses an iommu page size of 4kB. That means with our
current code, drivers may do a dma_map_sg() of a 64kB page and obtain
a dma_addr_t that is only 4k aligned.
This works fine in most cases except for some infiniband HW it seems,
where they tell the HW about the page size and it ignores the low bits
of the DMA address.
This works around it by making our IOMMU code enforce a PAGE_SIZE alignment
for mappings of objects that are page aligned in the first place and whose
size is larger or equal to a page.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* USB Mass Storare (PCI Based)
From: Ansari @ 2008-01-15 10:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]
Hi,
I want to configure linux kernel for USB Mass Storage device (PCI Based).In that i have few doubts. Can u pls calrify it.
Hardware
---------------
MPC8560 (PCI Host Mode )
MPC8540 (PCI Agent Mode )
ISP1564 (PCI Target - USB Host Controller)
Software
---------------
Uboot 1.1.2
Linux Kernel 2.4.10
Problem
--------------
I am using default pci & usb driver given in uboot and linux kernel.
In my board both MPC8560 (PCI Host), MPC8540 (PCI Agent) should access the ISP1564 USB host controller (PCI Target). All the three PCI devices connected in a single pci bus.
My problem is when i load uboot (with PCI Config) and kernel (with PCI,USB-EHCI,USB Mass storage Config) in MPC8560. Its working properly.
After MPC8560 booted , when i try to load uboot (with PCI support disabled) and kernel (with PCI,USB-EHCI,USB Mass storage Config).
The mass storage is not working in MPC8540 . But its working in MPC8560.
Few oberservation while testing :
1. When i enable PCI support in MPC8540 uboot and not booting kernel. The usb mass storage not working in MPC8560 kernel.
2. When i disable PCI support in MPC8540 uboot and not booting kernel(even if i boot kernel also). The usb mass storage working in MPC8560 kernel.
3. In both the case /proc/bus/pci and /proc/pci not created in MPC8540 kernel.( Note : I have enabled the option of proc file system , virtual file system support in MPC8540 kernel).
Questions
---------------
1. By the above problem defintion can u able to guess . Wht would be the problem ???
2. Why proc entry for pci is not created in MPC8540 kernel ??? . Whether PCI agent mode has any impact on it.??
3. Whether any special changes required in pci uboot/kernel driver of MPC8540. Since PCI of MPC8540 is in Agent Mode.
4. Whether any special changes required in USB kernel driver of MPC8540. Since PCI of MPC8540 is in Agent Mode.
Thanks in Advance
Regards
Haroun Ansari
[-- Attachment #2: Type: text/html, Size: 3081 bytes --]
^ permalink raw reply
* Re: PPC vs POWERPC
From: Matias Sundman @ 2008-01-15 10:38 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <fa686aa40801110652s67b2a05al79f78144c5b527bd@mail.gmail.com>
>>Documentation/powerpc/booting-without-of.txt to find out what is
>>expected in the device tree.
Is there any more information on how the "of_*" ( e.g. of_node_put ,
of_find_node_by_type ) functions should be implemented in the
"arch/powerpc/platforms/myplatform/myboard_setup.c" file
or is the documentation the existing "*.c" c files under
arch/powerpc/platforms ?
Since I have a 82xx board I assume that "myboard_setup.c" file shall be
put under arch/powerpc/platforms/82xx.
Cheers // Matias
Grant Likely skrev:
> On 1/11/08, samppa@sundmangroup.com <samppa@sundmangroup.com> wrote:
>
>> Hi,
>> I want to port a board ( WRS SBC8265 ) from the PPC branch to the POWERPC
>> branch in the Linux Kernel -- do you have any good starting points that
>> describes what I need to pay attention to?
>>
>> I've already made a port of U-boot-1.3.1 and enabled CONFIG_OF_LIBFDT.
>>
>> So I need to create a DTS file, compile it with the DTC compiler and port
>> the current PPC branch to the POWERPC branch to my understanding.
>>
>
> Yes, you're exactly right. Use one of the dts files in
> arch/powerpc/boot/dts as a starting point and read
> Documentation/powerpc/booting-without-of.txt to find out what is
> expected in the device tree.
>
> Cheers,
> g.
>
>
^ permalink raw reply
* [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-15 12:40 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
platforms and not only the TAH equipped ones (440GX). This enables an
MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
---
Eugene & Ben, do you see any problems with this patch? If not, then I'll
send another version for the newemac driver too.
Thanks.
drivers/net/ibm_emac/ibm_emac_core.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..198de44 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#if defined(CONFIG_IBM_EMAC_TAH)
static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
/* BHs disabled */
static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,9 @@ static int __init emac_probe(struct ocp_device *ocpdev)
/* Fill in the driver function table */
ndev->open = &emac_open;
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
--
1.5.4.rc3
^ permalink raw reply related
* psc and spi
From: S. Fricke @ 2008-01-15 13:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hello friends,
I have on the psc3 the spi-interface of a fpga connected.
psc3-0 - MOSI
psc3-1 - MISO
psc3-2 - CLK
psc3-3 - SlaveSelect
psc3-4 - CS-FPGA
psc3-5 - CS Another device
psc3-6 - SPI-SEL0
psc3-7 - SPI-SEL1
psc3-8/9 - Not connected
Can I use the mpc52xx_psc_spi-driver? And if yes, how I have to use this
driver? Or must I write a own spi-master/slave thing? Can anyone point me
to a good start-position?
Best regards,
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] sbc8560: Add device tree source for Wind River SBC8560 board
From: Kumar Gala @ 2008-01-15 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <20080110025622.GE17816@localhost.localdomain>
On Jan 9, 2008, at 8:56 PM, David Gibson wrote:
> On Mon, Jan 07, 2008 at 09:25:29AM -0500, Paul Gortmaker wrote:
>> This adds the device tree source for the Wind River SBC8560 board.
>> The
>> biggest difference between this and the MPC8560ADS reference platform
>> dts is the use of an external 16550 compatible UART instead of the
>> CPM2.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> arch/powerpc/boot/dts/sbc8560.dts | 285 +++++++++++++++++++++++++++
>> ++++++++++
>
> [snip]
>> + epld@fc000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "localbus";
>
> This compatible doesn't look specific enough. It should at least have
> a vendor prefix.
>
>> + ranges = <0 fc000000 00c00000>;
>
> Typically, we've been doing these external bust controller type
> gadgets with address-cells = <2>, the first cell explicitly encoding
> the chipselect. This gets us closer to the ideal of the device tree
> encoding only hardware information, not how the bridge controller is
> configured (although "ranges" will still have to contain configuration
> dependent information).
>
>
>> +
>> + serial0: serial@700000 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <700000 100>;
>> + clock-frequency = <1C2000>;
>> + interrupts = <9 2>;
>> + interrupt-parent = <&mpic>;
>> + };
>> +
>> + serial1: serial@800000 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <800000 100>;
>> + clock-frequency = <1C2000>;
>> + interrupts = <a 2>;
>> + interrupt-parent = <&mpic>;
>> + };
>> +
>> + rtc@900000 {
>> + compatible = "m48t59";
>> + reg = <900000 2000>;
>> + };
>> + };
>> +};
Paul,
any updates here based on David's comments on how we are representing
localbus nodes?
- k
^ permalink raw reply
* Re: [PATCH 1/3] sbc834x: Add support for Wind River SBC834x boards
From: Kumar Gala @ 2008-01-15 14:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <20080109180105.7c745bde.sfr@canb.auug.org.au>
On Jan 9, 2008, at 1:01 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> On Wed, 9 Jan 2008 00:49:30 -0500 Paul Gortmaker <paul.gortmaker@windriver.com
> > wrote:
>>
>> +static void __init sbc834x_init_IRQ(void)
>> +{
>> + struct device_node *np;
>> +
>> + np = of_find_node_by_type(NULL, "ipic");
>> + if (!np)
>> + return;
>> +
>> + ipic_init(np, 0);
>> +
>> + /* Initialize the default interrupt mapping priorities,
>> + * in case the boot rom changed something on us.
>> + */
>> + ipic_set_default_priority();
>> +}
>
> This needs an of_node_put(np) somewhere.
>
>> +static struct of_device_id sbc834x_ids[] = {
>
> __initdata
>
>> +static int __init sbc834x_declare_of_platform_devices(void)
>> +{
>> + if (!machine_is(sbc834x))
>> + return 0;
>> +
>> + of_platform_bus_probe(NULL, sbc834x_ids, NULL);
>> + return 0;
>> +}
>> +device_initcall(sbc834x_declare_of_platform_devices);
>
> machine_device_initcall(sbc834x, ...
Any updates here? While David's .dts comments are probably valid I'm
not going to make you have to deal with them to get into the tree. We
need to fix all the other 83xx platforms w/respect to those things.
- k
^ permalink raw reply
* Re: [PATCH] [SERIAL] qe-uart: add support for Freescale QUICCEngine UART
From: Kumar Gala @ 2008-01-15 14:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <119992170854-git-send-email-timur@freescale.com>
On Jan 9, 2008, at 5:35 PM, Timur Tabi wrote:
> Add file ucc_uart.c, a serial device driver for the Freescale
> QUICCEngine.
> Update the Kconfig and Makefile accordingly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> drivers/serial/Kconfig | 10 +
> drivers/serial/Makefile | 1 +
> drivers/serial/ucc_uart.c | 1507 ++++++++++++++++++++++++++++++++++++
> +++++++++
> 3 files changed, 1518 insertions(+), 0 deletions(-)
> create mode 100644 drivers/serial/ucc_uart.c
>
>
> diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
> new file mode 100644
> index 0000000..6fe4cfc
> --- /dev/null
> +++ b/drivers/serial/ucc_uart.c
> @@ -0,0 +1,1507 @@
> +/*
> + * Freescale QUICC Engine UART device driver
> + *
> + * Author: Timur Tabi <timur@freescale.com>
> + *
> + * Copyright 2007 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.
> + *
> + * This driver adds support for UART devices via Freescale's QUICC
> Engine
> + * found on some Freescale SOCs.
> + *
> + * If Soft-UART support is needed but not already present, then
> this driver
> + * will request and upload the "Soft-UART" microcode upon probe. The
> + * filename of the microcode should be fsl_qe_ucode_uart_X_YZ.bin,
> where "X"
> + * is the name of the SOC (e.g. 8323), and YZ is the revision of
> the SOC,
> + * (e.g. "11" for 1.1).
> + */
> +
what is the define for? you commented all the others :)
>
> +#define UCC_WAIT_CLOSING 100
> +
> +struct ucc_uart_pram {
> + struct ucc_slow_pram common;
> + u8 res1[8]; /* reserved */
> + __be16 maxidl; /* Maximum idle chars */
> + __be16 idlc; /* temp idle counter */
> + __be16 brkcr; /* Break count register */
> + __be16 parec; /* receive parity error counter */
> + __be16 frmec; /* receive framing error counter */
> + __be16 nosec; /* receive noise counter */
> + __be16 brkec; /* receive break condition counter */
> + __be16 brkln; /* last received break length */
> + __be16 uaddr[2]; /* UART address character 1 & 2 */
> + __be16 rtemp; /* Temp storage */
> + __be16 toseq; /* Transmit out of sequence char */
> + __be16 cchars[8]; /* control characters 1-8 */
> + __be16 rccm; /* receive control character mask */
> + __be16 rccr; /* receive control character register */
> + __be16 rlbc; /* receive last break character */
> + __be16 res2; /* reserved */
> + __be32 res3; /* reserved, should be cleared */
> + u8 res4; /* reserved, should be cleared */
> + u8 res5[3]; /* reserved, should be cleared */
> + __be32 res6; /* reserved, should be cleared */
> + __be32 res7; /* reserved, should be cleared */
> + __be32 res8; /* reserved, should be cleared */
> + __be32 res9; /* reserved, should be cleared */
> + __be32 res10; /* reserved, should be cleared */
> + __be32 res11; /* reserved, should be cleared */
> + __be32 res12; /* reserved, should be cleared */
> + __be32 res13; /* reserved, should be cleared */
> +/* The rest is for Soft-UART only */
> + __be16 supsmr; /* 0x90, Shadow UPSMR */
> + __be16 res92; /* 0x92, reserved, initialize to 0 */
> + __be32 rx_state; /* 0x94, RX state, initialize to 0 */
> + __be32 rx_cnt; /* 0x98, RX count, initialize to 0 */
> + u8 rx_length; /* 0x9C, Char length, set to 1+CL+PEN+1+SL */
> + u8 rx_bitmark; /* 0x9D, reserved, initialize to 0 */
> + u8 rx_temp_dlst_qe; /* 0x9E, reserved, initialize to 0 */
> + u8 res14[0xBC - 0x9F]; /* reserved */
> + __be32 dump_ptr; /* 0xBC, Dump pointer */
> + __be32 rx_frame_rem; /* 0xC0, reserved, initialize to 0 */
> + u8 rx_frame_rem_size; /* 0xC4, reserved, initialize to 0 */
> + u8 tx_mode; /* 0xC5, mode, 0=AHDLC, 1=UART */
> + u16 tx_state; /* 0xC6, TX state */
__be16?
>
> + u8 res15[0xD0 - 0xC8]; /* reserved */
> + __be32 resD0; /* 0xD0, reserved, initialize to 0 */
> + u8 resD4; /* 0xD4, reserved, initialize to 0 */
> + __be16 resD5; /* 0xD5, reserved, initialize to 0 */
> +} __attribute__ ((packed));
> +
>
>
> +/*
> + * Set the modem control lines
> + *
> + * We currently don't support setting modem control lines, but this
> function
> + * needs to exist, otherwise the kernel will panic.
> + */
> +void qe_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +}
What's the issue w/support of this? (maybe a comment related to why
its not supported -- if not here in the git commit message)
> +/*
> + * Enable status change interrupts
> + *
> + * We don't support status change interrupts, but we need to define
> this
> + * function otherwise the kernel will panic.
> + */
> +static void qe_uart_enable_ms(struct uart_port *port)
> +{
same question as above.
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox