* 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: [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: [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: 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: 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: [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: [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 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] 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
* 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: Using USB on ML403
From: Grant Likely @ 2008-01-15 3:22 UTC (permalink / raw)
To: Yedu Jathavedan; +Cc: linuxppc-embedded
In-Reply-To: <20080114183942.un31p1u02s4s8www@webmail.cecs.pdx.edu>
On 1/14/08, Yedu Jathavedan <yeduj@ece.pdx.edu> wrote:
> Hi,
>
> I am a beginner to FPGA programming. I want to use the USB Host on
> ML403 in a PowerPC processor reference system to store some data on a
> Thumb Drive.
>
> Currently, I've configured the BSP(OS support) as standalone. There is
> the OPB USB2 IP core with drivers which I want to use. But, not sure
The opb_usb2_device ip core is a USB device, not a host. It will not
work for reading a thumb drive.
You want to configure your BSP as linux_v2_6 so you can get a
xparameter_ml40x.h file which will work with linux.
> which port connections to use & if that will configure the Cypress
> CY7C67300 USB controller. The Application Note Xapp925 for ML403 uses
> OPB EPC core to configure the Cypress controller. If that is the case,
> is there any driver for the cypress controller?
opb_epc is the right thing to use to get the cypress c67300 working.
I've got a driver for the c67x00 in my git tree:
http://git.secretlab.ca/git/linux-2.6-virtex.git in the virtex-c67x00 branch.
Go here for my notes on Linux on the Virtex:
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
>
> If I use Linux kernel 2.6, how would it help me? Are there any drivers
> for the USB that I can use for kernel 2.6? If anyone has worked on
> this problem before, I would greatly appreciate their help.
All my work is targeted for 2.6. It will be difficult to get support
if you use 2.4
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] [POWERPC] Fixup use of phys_addr_t in mpic code
From: Kumar Gala @ 2008-01-15 2:58 UTC (permalink / raw)
To: linuxppc-dev
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>
---
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)
{
--
1.5.3.7
^ permalink raw reply related
* Using USB on ML403
From: Yedu Jathavedan @ 2008-01-15 2:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am a beginner to FPGA programming. I want to use the USB Host on
ML403 in a PowerPC processor reference system to store some data on a
Thumb Drive.
Currently, I've configured the BSP(OS support) as standalone. There is
the OPB USB2 IP core with drivers which I want to use. But, not sure
which port connections to use & if that will configure the Cypress
CY7C67300 USB controller. The Application Note Xapp925 for ML403 uses
OPB EPC core to configure the Cypress controller. If that is the case,
is there any driver for the cypress controller?
If I use Linux kernel 2.6, how would it help me? Are there any drivers
for the USB that I can use for kernel 2.6? If anyone has worked on
this problem before, I would greatly appreciate their help.
Thanks & Regards,
Yedu Jathavedan
^ permalink raw reply
* [PATCH] [POWERPC] Remove update_bridge_resource
From: Kumar Gala @ 2008-01-15 2:46 UTC (permalink / raw)
To: linuxppc-dev
The 85xx/86xx pci code no longer uses update_bridge_resource and it was the
only caller.
---
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 */
/*
--
1.5.3.7
^ permalink raw reply related
* [PATCH] [POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx
From: Kumar Gala @ 2008-01-15 2:46 UTC (permalink / raw)
To: linuxppc-dev
The current PCI code for Freescale 85xx/86xx was treating the virtual
P2P PCIe bridge as a transparent bridge. Rather than doing that fixup
the virtual P2P bridge by copying the resources from the PHB.
Also, fixup a bit of the code for dealing with resource_size_t being
64-bits and how we set ATMU registers for >4G.
---
in my git tree.
arch/powerpc/sysdev/fsl_pci.c | 141 +++++++++++++++++------------------------
1 files changed, 57 insertions(+), 84 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4b1d512..39177eb 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -33,8 +33,8 @@ void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
struct ccsr_pci __iomem *pci;
int i;
- pr_debug("PCI memory map start 0x%x, size 0x%x\n", rsrc->start,
- rsrc->end - rsrc->start + 1);
+ pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
+ (u64)rsrc->start, (u64)rsrc->end - (u64)rsrc->start + 1);
pci = ioremap(rsrc->start, rsrc->end - rsrc->start + 1);
/* Disable all windows (except powar0 since its ignored) */
@@ -46,17 +46,17 @@ void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
/* Setup outbound MEM window */
for(i = 0; i < 3; i++)
if (hose->mem_resources[i].flags & IORESOURCE_MEM){
- pr_debug("PCI MEM resource start 0x%08x, size 0x%08x.\n",
- hose->mem_resources[i].start,
- hose->mem_resources[i].end
- - hose->mem_resources[i].start + 1);
- out_be32(&pci->pow[i+1].potar,
- (hose->mem_resources[i].start >> 12)
- & 0x000fffff);
+ resource_size_t pci_addr_start =
+ hose->mem_resources[i].start -
+ hose->pci_mem_offset;
+ pr_debug("PCI MEM resource start 0x%016llx, size 0x%016llx.\n",
+ (u64)hose->mem_resources[i].start,
+ (u64)hose->mem_resources[i].end
+ - (u64)hose->mem_resources[i].start + 1);
+ out_be32(&pci->pow[i+1].potar, (pci_addr_start >> 12));
out_be32(&pci->pow[i+1].potear, 0);
out_be32(&pci->pow[i+1].powbar,
- (hose->mem_resources[i].start >> 12)
- & 0x000fffff);
+ (hose->mem_resources[i].start >> 12));
/* Enable, Mem R/W */
out_be32(&pci->pow[i+1].powar, 0x80044000
| (__ilog2(hose->mem_resources[i].end
@@ -65,15 +65,14 @@ void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
/* Setup outbound IO window */
if (hose->io_resource.flags & IORESOURCE_IO){
- pr_debug("PCI IO resource start 0x%08x, size 0x%08x, phy base 0x%08x.\n",
- hose->io_resource.start,
- hose->io_resource.end - hose->io_resource.start + 1,
- hose->io_base_phys);
- out_be32(&pci->pow[i+1].potar, (hose->io_resource.start >> 12)
- & 0x000fffff);
+ pr_debug("PCI IO resource start 0x%016llx, size 0x%016llx, "
+ "phy base 0x%016llx.\n",
+ (u64)hose->io_resource.start,
+ (u64)hose->io_resource.end - (u64)hose->io_resource.start + 1,
+ (u64)hose->io_base_phys);
+ out_be32(&pci->pow[i+1].potar, (hose->io_resource.start >> 12));
out_be32(&pci->pow[i+1].potear, 0);
- out_be32(&pci->pow[i+1].powbar, (hose->io_base_phys >> 12)
- & 0x000fffff);
+ out_be32(&pci->pow[i+1].powbar, (hose->io_base_phys >> 12));
/* Enable, IO R/W */
out_be32(&pci->pow[i+1].powar, 0x80088000
| (__ilog2(hose->io_resource.end
@@ -107,55 +106,17 @@ void __init setup_pci_cmd(struct pci_controller *hose)
}
}
-static void __init quirk_fsl_pcie_transparent(struct pci_dev *dev)
-{
- struct resource *res;
- int i, res_idx = PCI_BRIDGE_RESOURCES;
- struct pci_controller *hose;
+static int fsl_pcie_bus_fixup;
+static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
+{
/* if we aren't a PCIe don't bother */
if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
return ;
-
- /*
- * Make the bridge be transparent.
- */
- dev->transparent = 1;
-
- hose = pci_bus_to_host(dev->bus);
- if (!hose) {
- printk(KERN_ERR "Can't find hose for bus %d\n",
- dev->bus->number);
- return;
- }
-
- /* Clear out any of the virtual P2P bridge registers */
- pci_write_config_word(dev, PCI_IO_BASE_UPPER16, 0);
- pci_write_config_word(dev, PCI_IO_LIMIT_UPPER16, 0);
- pci_write_config_byte(dev, PCI_IO_BASE, 0x10);
- pci_write_config_byte(dev, PCI_IO_LIMIT, 0);
- pci_write_config_word(dev, PCI_MEMORY_BASE, 0x10);
- pci_write_config_word(dev, PCI_MEMORY_LIMIT, 0);
- pci_write_config_word(dev, PCI_PREF_BASE_UPPER32, 0x0);
- pci_write_config_word(dev, PCI_PREF_LIMIT_UPPER32, 0x0);
- pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0x10);
- pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, 0);
-
- if (hose->io_resource.flags) {
- res = &dev->resource[res_idx++];
- res->start = hose->io_resource.start;
- res->end = hose->io_resource.end;
- res->flags = hose->io_resource.flags;
- update_bridge_resource(dev, res);
- }
-
- for (i = 0; i < 3; i++) {
- res = &dev->resource[res_idx + i];
- res->start = hose->mem_resources[i].start;
- res->end = hose->mem_resources[i].end;
- res->flags = hose->mem_resources[i].flags;
- update_bridge_resource(dev, res);
- }
+
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+ fsl_pcie_bus_fixup = 1;
+ return ;
}
int __init fsl_pcie_check_link(struct pci_controller *hose)
@@ -179,6 +140,18 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
bus->resource[i] = bus->parent->resource[i];
}
}
+
+ if (fsl_pcie_bus_fixup &&
+ (bus->parent == hose->bus) &&
+ early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
+ for (i = 0; i < 4; ++i) {
+ if (bus->resource[i] && bus->parent->resource[i]) {
+ bus->resource[i]->start = bus->parent->resource[i]->start;
+ bus->resource[i]->end = bus->parent->resource[i]->end;
+ bus->resource[i]->flags = bus->parent->resource[i]->flags;
+ }
+ }
+ }
}
int __init fsl_add_bridge(struct device_node *dev, int is_primary)
@@ -240,23 +213,23 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
return 0;
}
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8548E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8548, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8543E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8543, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8547E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8545E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8545, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8568E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8568, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8567E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8567, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8548E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8548, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8543E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8543, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8547E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8545E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8545, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8568E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8568, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8567E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8567, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
--
1.5.3.7
^ permalink raw reply related
* [PATCH] [POWERPC] Fixup transparent P2P resources
From: Kumar Gala @ 2008-01-15 2:45 UTC (permalink / raw)
To: linuxppc-dev
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.
---
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
--
1.5.3.7
^ permalink raw reply related
* [PATCH] [POWERPC] Ensure we only handle PowerMac PCI bus fixup for memory resources
From: Kumar Gala @ 2008-01-15 2:44 UTC (permalink / raw)
To: linuxppc-dev
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.
---
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"
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Kumar Gala @ 2008-01-15 2:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080114162935.GA27862@ld0162-tx32.am.freescale.net>
On Jan 14, 2008, at 10:29 AM, Scott Wood wrote:
> The reg property in fsl soc nodes should be removed.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
> fsl_soc.c
> index 3ace747..7502e03 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -54,10 +54,18 @@ phys_addr_t get_immrbase(void)
> soc = of_find_node_by_type(NULL, "soc");
> if (soc) {
> int size;
> - const void *prop = of_get_property(soc, "reg", &size);
> + u32 naddr;
> + const u32 *prop = of_get_property(soc, "#address-cells", &size);
> +
> + if (prop && size == 4)
> + naddr = *prop;
> + else
> + naddr = 2;
Why default to two?
>
> +
> + prop = of_get_property(soc, "ranges", &size);
> + if (prop && size == 12)
> + immrbase = of_translate_address(soc, prop + naddr);
>
> - if (prop)
> - immrbase = of_translate_address(soc, prop);
why not make your code an else case if we don't have reg?
>
> of_node_put(soc);
> }
or something like, than we don't have to worry about adjust anything,
and if you don't have any children its kinda a pointless device tree :)
if (soc) {
struct device_node *child = of_get_next_child(soc, NULL);
if (child) {
const void *prop = of_get_property(soc, "ranges", NULL);
if (prop)
immrbase = of_translate_address(child, prop);
of_node_put(child);
}
of_node_put(soc);
}
- k
^ permalink raw reply
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: David Gibson @ 2008-01-15 0:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080114163004.GA27880@ld0162-tx32.am.freescale.net>
On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
> ft_get_next_node() enumerates children of a given node.
> ft_get_next_prop() enumerates propreties of a given node.
>
> ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
> than a node offset and property name; it is primarily intended for use
> with ft_get_next_prop().
Urg... this kind of serves me right for not getting my act together on
iterator functions yet. I really don't like this approach much. I'll
see if I can come up with something I prefer this afternoon.
The biggest thing I dislike is that I've deliberately avoided having
any offsets-to-properties exposed to the library user. That's because
the whole offsets change when you write the tree problem is worse for
properties than nodes (in that likely idiomatic uses will be bitten by
changes in property offsets).
Some more specific comments on the patch below.
[snip]
> +const void *fdt_getprop_offset(const void *fdt, int propoffset,
> + const char **name, int *lenp)
> +{
> + uint32_t tag;
> + const struct fdt_property *prop;
> + int namestroff;
> + int err, len;
> +
> + err = fdt_check_header(fdt);
> + if (err)
> + goto fail;
> +
> + tag = fdt_next_tag(fdt,propoffset, NULL);
> + if (tag != FDT_PROP) {
> + err = -FDT_ERR_BADOFFSET;
> + goto fail;
> + }
> +
> + err = -FDT_ERR_BADSTRUCTURE;
> + prop = fdt_offset_ptr(fdt, propoffset, sizeof(*prop));
> + if (!prop)
> + goto fail;
> +
> + if (name) {
> + namestroff = fdt32_to_cpu(prop->nameoff);
> + *name = fdt_string(fdt, namestroff);
> + }
> +
> + len = fdt32_to_cpu(prop->len);
> + if (lenp)
> + *lenp = len;
> +
> + prop = fdt_offset_ptr(fdt, propoffset, sizeof(*prop) + len);
> + if (!prop)
> + goto fail;
This juggling to call fdt_offset_ptr() over the whole length of the
property representation should be rolled up into an internal function
and used within fdt_get_property() as well.
[snip]
> +int fdt_get_next_node(const void *fdt, int startoffset,
> + int *depth, int recursive)
> +{
> + uint32_t tag;
> + int offset, nextoffset;
> +
> + CHECK_HEADER(fdt);
> +
> + if (startoffset >= 0) {
> + tag = fdt_next_tag(fdt, startoffset, &nextoffset);
> + if (tag != FDT_BEGIN_NODE)
> + return -FDT_ERR_BADOFFSET;
> + } else {
> + nextoffset = 0;
> + }
> +
> + do {
> + offset = nextoffset;
> + tag = fdt_next_tag(fdt, offset, &nextoffset);
> +
> + switch (tag) {
> + case FDT_BEGIN_NODE:
> + if ((*depth)++ == 0 || recursive) {
> + return offset;
> + }
> +
> + break;
> +
> + case FDT_END_NODE:
> + if (--*depth < 0)
> + return -FDT_ERR_NOTFOUND;
> +
> + break;
> +
> + case FDT_PROP:
> + case FDT_END:
> + case FDT_NOP:
> + break;
> +
> + default:
> + return -FDT_ERR_BADSTRUCTURE;
> + }
> + } while (tag != FDT_END);
> +
> + if (depth != 0)
> + return -FDT_ERR_BADSTRUCTURE;
I think this should be FDT_ERR_TRUNCATED.
> + return -FDT_ERR_NOTFOUND;
In fact, so should this. This function should never actually reach
the FDT_END tag.
> +}
> +
> +int fdt_get_next_prop(const void *fdt, int startoffset)
> +{
> + uint32_t tag;
> + int offset, nextoffset;
> +
> + CHECK_HEADER(fdt);
> +
> + if (startoffset >= 0) {
> + tag = fdt_next_tag(fdt, startoffset, &nextoffset);
> + if (tag != FDT_BEGIN_NODE && tag != FDT_PROP)
> + return -FDT_ERR_BADOFFSET;
> + } else {
> + nextoffset = 0;
This alternate case shouldn't be here. For properties, the given
offset should always be either the node offset to find within, or
another property offset. This other case simply makes negative and 0
startoffset equivalent. Instead, negative startoffset should cause
FDT_ERR_BADOFFSET.
> + }
> +
> + do {
> + offset = nextoffset;
> + tag = fdt_next_tag(fdt, offset, &nextoffset);
> +
> + switch (tag) {
> + case FDT_BEGIN_NODE:
> + case FDT_END_NODE:
> + return -FDT_ERR_NOTFOUND;
> +
> + case FDT_PROP:
> + return offset;
> +
> + case FDT_END:
> + case FDT_NOP:
> + break;
> +
> + default:
> + return -FDT_ERR_BADSTRUCTURE;
> + }
> + } while (tag != FDT_END);
> +
> + return -FDT_ERR_BADSTRUCTURE;
Should be FDT_ERR_TRUNCATED again.
> +}
> diff --git a/libfdt/fdt_strerror.c b/libfdt/fdt_strerror.c
> index f9d32ef..4e87550 100644
> --- a/libfdt/fdt_strerror.c
> +++ b/libfdt/fdt_strerror.c
> @@ -70,6 +70,7 @@ static struct errtabent errtable[] = {
> ERRTABENT(FDT_ERR_BADOFFSET),
> ERRTABENT(FDT_ERR_BADPATH),
> ERRTABENT(FDT_ERR_BADSTATE),
> + ERRTABENT(FDT_ERR_BADDEPTH),
>
> ERRTABENT(FDT_ERR_TRUNCATED),
> ERRTABENT(FDT_ERR_BADMAGIC),
> diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
> index d053689..6c5d4a9 100644
> --- a/libfdt/libfdt.h
> +++ b/libfdt/libfdt.h
> @@ -85,25 +85,28 @@
> /* FDT_ERR_BADSTATE: Function was passed an incomplete device
> * tree created by the sequential-write functions, which is
> * not sufficiently complete for the requested operation. */
> +#define FDT_ERR_BADDEPTH 8
> + /* FDT_ERR_BADDEPTH: Function was passed a negative
> + * (or otherwise invalid) depth. */
You've added this error code, but you don't actually return it
anywhere...
[snip]
> /**
> + * fdt_getprop_offset - retrieve the value of a given property by offset
> + * @fdt: pointer to the device tree blob
> + * @propoffset: offset of the property to read
> + * @name: pointer to a character pointer (will be overwritten) or NULL
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_getprop() retrieves a pointer to the value of the property
> + * named 'name' of the node at offset nodeoffset (this will be a
> + * pointer to within the device blob itself, not a copy of the value).
> + * If lenp is non-NULL, the length of the property value also
> + * returned, in the integer pointed to by lenp.
This description is incorrect - you've copied the fdt_getprop()
description and forgotten to update it.
[snip]
And finally, new libfdt functions should have testcases.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Problem booting Linux 2.6 on Virtex-4
From: David Baird @ 2008-01-15 0:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080114210954.AC436CF8050@mail36-dub.bigfish.com>
Hi Steve,
On Jan 14, 2008 2:09 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> What kernel version are you targeting? Are you using arch/powerpc or arch/ppc? V4 has a data cache errata, which isn't currently in mainline arch/powerpc.
I am using arch/ppc/, but to be honest, I don't yet know what the
difference is between those two trees.
Also, I am still learning how to use git, but it appears that I am
using this version:
Tags: v2.6.24-rc7
I am actually using OpenEmbedded which executes the following commands
to get the Linux tree:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git clone git://git.secretlab.ca/git/linux-2.6-virtex.git master
> if((mfpvr() & 0xfffff000) == 0x20011000) {
> /* PPC errata 213: only for Virtex-4 FX */
> __asm__("mfccr0 0\n\t"
> "oris 0,0,0x50000000@h\n\t"
> "mtccr0 0"
> : : : "0");
> }
I tried out this code snippit, but it did not help :-( I also looked
in head.S and found that this was already in there:
#if defined(CONFIG_XILINX_VIRTEX_4_FX)
/* PPC errata 213: only for Virtex-4 FX */
mfccr0 0
oris 0,0,0x50000000@h
mtccr0 0
#endif
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.
-David
(P.S. - Sorry I forgot to send to this to the list on the first try)
^ permalink raw reply
* Re: Problem booting Linux 2.6 on Virtex-4
From: David Baird @ 2008-01-14 23:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <440abda90801141211m52bd0a3bk67014c6df2bf406c@mail.gmail.com>
On Jan 14, 2008 1:11 PM, David Baird <dhbaird@gmail.com> wrote:
> I am now trying to experiment with the hardware and see if I can find
> a hardware reference design. I will let you know what I figure out.
Okay, I got something to work. I had been using EDK 9.1i. Today, I
got hold of a copy of EDK 9.2i and I tried out a reference design that
comes with EDK. Voila! The aliasing problem seems to have vanished.
So, basically, I still don't know why there was an aliasing problem in
the first place. But, now something works. I will still try to
figure out what the original problem was...
-David
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
From: David Gibson @ 2008-01-14 23:34 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20080114225926.GB22862@mag.az.mvista.com>
On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> From: Mark A. Greer <mgreer@mvista.com>
>
> Add DTS file for the Emerson Katana 750i & 752i platforms.
[snip]
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Katana-75xi"; /* Default */
> + compatible = "emerson,katana-750i";
> + coherency-off;
Where is this flag used from?
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,750 {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <733333333>; /* Default */
> + bus-frequency = <133333333>; /* Default */
> + timebase-frequency = <33333333>; /* Default */
> + i-cache-line-size = <0x20>;
> + d-cache-line-size = <0x20>;
> + i-cache-size = <0x8000>;
> + d-cache-size = <0x8000>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x04000000>; /* Default (64MB) */
> + };
> +
> + mv64x60@f8100000 { /* Marvell Discovery */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "mv64360"; /* Default */
> + compatible = "marvell,mv64360";
> + clock-frequency = <133333333>;
> + hs_reg_valid;
> + reg = <0xf8100000 0x00010000>;
> + virtual-reg = <0xf8100000>;
You seem to have virtual-reg properties on a *lot* of nodes, are they
really necessary? virtual-reg should be used *only* for things which
you need to access very early in the bootwrapper. Usually that's only
the serial port for the console. Come to that, the CPU is a 750 which
has a real mode, so it seems dubious that you would need any
virtual-reg values at all.
[snip]
> + flash@e8000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "cfi-flash";
> + bank-width = <4>;
> + device-width = <2>;
> + reg = <0xe8000000 0x04000000>;
> + monitor@0 {
> + label = "Monitor";
If you're using the "label" property, it would be normal to name the
nodes simply "partition@address".
> + reg = <0x00000000 0x00100000>;
> + };
> + pkernel@100000 {
> + label = "Primary Kernel";
> + reg = <0x00100000 0x00180000>;
> + };
> + pfs@280000 {
> + label = "Primary Filesystem";
> + reg = <0x00280000 0x01e00000>;
> + };
> + skernel@2080000 {
> + label = "Secondary Kernel";
> + reg = <0x02080000 0x00180000>;
> + };
> + sfs@2200000 {
> + label = "Secondary Filesystem";
> + reg = <0x02200000 0x01e00000>;
> + };
> + user@100000 { /* overlay all but monitor */
> + label = "User FLASH";
> + reg = <0x00100000 0x03f00000>;
> + };
> + };
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
This device_type value should not be here.
> + compatible = "marvell,mv64360-mdio";
> + PHY0: ethernet-phy@12 {
> + device_type = "ethernet-phy";
> + compatible = "broadcom,bcm5461";
> + reg = <12>;
> + };
> + PHY1: ethernet-phy@11 {
> + device_type = "ethernet-phy";
> + compatible = "broadcom,bcm5461";
> + reg = <11>;
> + };
> + PHY2: ethernet-phy@4 {
> + device_type = "ethernet-phy";
> + compatible = "broadcom,bcm5461";
> + reg = <4>;
> + };
> + };
> +
> + multiethernet@2000 {
This needs some sort of "compatible" value.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2000 0x2000>;
> + ethernet@0 {
[snip]
> + CUNIT: cunit@f200 {
What is this device? It needs some sort of "compatible" value.
> + reg = <0xf200 0x200>;
> + };
> +
> + MPSCROUTING: mpscrouting@b400 {
Ditto.
> + reg = <0xb400 0xc>;
> + };
> +
> + MPSCINTR: mpscintr@b800 {
Ditto.
> + reg = <0xb800 0x100>;
> + virtual-reg = <0xf810b800>;
> + };
[snip]
> + i2c@c000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
This device_type value shouldn't be here either.
> + compatible = "marvell,mv64360-i2c";
> + reg = <0xc000 0x20>;
> + virtual-reg = <0xf810c000>;
> + freq_m = <8>;
> + freq_n = <3>;
> + interrupts = <37>;
> + interrupt-parent = <&PIC>;
> + rtc@68 {
> + compatible = "dallas,ds1307";
> + reg = <0x68>;
> + };
> + };
[snip]
> + mpp@f000 {
> + compatible = "marvell,mv64360-mpp";
> + reg = <0xf000 0x10>;
> + };
> +
> + gpp@f100 {
> + compatible = "marvell,mv64360-gpp";
> + reg = <0xf100 0x20>;
> + };
What are these two devices?
> + pci@80000000 {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "marvell,mv64360-pci";
> + cell-index = <1>;
> + reg = <0x0c78 0x8>;
> + ranges = <0x01000000 0x0 0x0
> + 0xb0000000 0x0 0x04000000
> + 0x02000000 0x0 0x80000000
> + 0x80000000 0x0 0x30000000>;
> + bus-range = <0x0 0xff>;
> + clock-frequency = <66000000>;
> + interrupt-pci-iack = <0x0cb4>;
> + interrupt-parent = <&PIC>;
> + interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> + interrupt-map = <
> + /* IDSEL 0x04 - PMC 1 */
> + 0x2000 0 0 1 &PIC 73
> + 0x2000 0 0 2 &PIC 74
> + 0x2000 0 0 3 &PIC 78
> + 0x2000 0 0 4 &PIC 72
> +
> + /* IDSEL 0x05 - PMC 2 */
> + 0x2800 0 0 1 &PIC 74
> + 0x2800 0 0 2 &PIC 78
> + 0x2800 0 0 3 &PIC 72
> + 0x2800 0 0 4 &PIC 73
> +
> + /* IDSEL 0x06 - T8110 */
> + 0x3000 0 0 1 &PIC 78
> +
> + /* IDSEL 0x08 - i82544 */
> + 0x4000 0 0 1 &PIC 78
> + >;
> + };
> +
> + pci@f8080000 { /* Required to acces Hotswap register */
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "marvell,mv64360-pci";
> + cell-index = <0>;
> + reg = <0x0cf8 0x8>;
> + ranges = <0x01000000 0x0 0x0
> + 0xf8080000 0x0 0x00010000
> + 0x02000000 0x0 0xf8090000
> + 0xf8090000 0x0 0x00010000>;
> + bus-range = <0x0 0xff>;
Two PCI bridges with identical bus-range values seems potentially
problematic...
> + };
[snip]
> + chosen {
> + bootargs = "ip=on";
The dts file should not include a "bootargs" value. The wrapper will
fill that in from the kernel config.
> + linux,stdout-path = "/mv64x60@f8100000/mpsc@8000";
> + };
> +};
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Katana750i - Add platform support
From: Stephen Rothwell @ 2008-01-14 23:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20080114230057.GC22862@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]
Hi Mark,
On Mon, 14 Jan 2008 16:00:57 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> +++ b/arch/powerpc/platforms/embedded6xx/katana750i.c
> @@ -0,0 +1,314 @@
> +/*
> + * Board setup routines for the Emerson Katana-750i/752i
> + *
> + * Author: Mark A. Greer <mgreer@mvista.com>
> + *
> + * Based on code prpmc2800.c by Dale Farnsworth <dale@farnsworth.org>
> + * and original katana port by Tim Montgomery <timm@artesyncp.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
A Copyright notice would be nice.
> +static void __init katana750i_setup_arch(void)
> +{
> + struct device_node *np;
> + phys_addr_t paddr;
> + const unsigned int *reg;
> +
> + /*
> + * ioremap mpp and gpp registers in case they are later
> + * needed by katana750i_reset_board().
> + */
> + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-mpp");
> + reg = of_get_property(np, "reg", NULL);
What happens if np == NULL?
> + paddr = of_translate_address(np, reg);
> + of_node_put(np);
> + mv64x60_mpp_reg_base = ioremap(paddr, reg[1]);
> +
> + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp");
> + reg = of_get_property(np, "reg", NULL);
Ditto.
> + paddr = of_translate_address(np, reg);
> + of_node_put(np);
> + mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
> +
> +#ifdef CONFIG_PCI
> + mv64x60_pci_init();
> +#endif
Maybe there should be a stub of mv64x60_pci_init for the non PCI case -
that would save the ifdefs in C code.
> + np = of_find_compatible_node(NULL, NULL, "katana750i,cpld");
> + reg = of_get_property(np, "reg", NULL);
What if np == NULL?
--
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: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Stephen Rothwell @ 2008-01-14 23:21 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20080114225150.GB21940@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
Hi Mark,
On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> +++ b/arch/powerpc/sysdev/mv64x60.h
> @@ -3,10 +3,32 @@
>
> #include <linux/init.h>
>
> +#include <asm/prom.h>
You probably meant to include linux/of.h here
--
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: I2C and CAN bus on MPC5200B device tree
From: David Gibson @ 2008-01-14 23:21 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <478B18D9.6020201@grandegger.com>
On Mon, Jan 14, 2008 at 09:10:01AM +0100, Wolfgang Grandegger wrote:
> Grant Likely wrote:
> > On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >> Hi guys,
> >>
> >> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> >> for it) and have not found any CAN bus documentation for device trees.
> >>
> >> I want to update the firmware tree to add these but, am basically looking
> >> for those docs, or someone to go over a few points.. is there some kind of
> >> tree standard I should be looking at, or some patch I missed which has
> >> a driver which implements something that looks at a compatible tree?
> >
> > I think some consensus has been achieved for describing i2c busses and
> > their attached devices, but I don't think booting-without-of.txt has
> > been updated with the details yet. I need to look into that more.
> >
> > I don't think anyone has tackled CAN. Best bet is to draft a tree in
> > the way you think it should be described and post it to the list.
> > That will give a starting point for us to discuss it and come to
> > consensus.
>
> For MSCAN on the MPC5200 we currently have:
>
> mscan@900 {
> device_type = "mscan";
These device_type entries should not be here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
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