* 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: [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
* [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
* [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] 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] 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
* 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] 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
* 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
* 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
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