* Re: [PATCH 3/7] Use archdata.dma_data in dma_direct_ops and add the offset
From: Benjamin Herrenschmidt @ 2008-01-21 6:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <651e15968afb5bbd9eeafb0b66cd5b59eabcf8d9.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Now that all platforms using dma_direct_offset setup the archdata.dma_data
> correctly, we can change the dma_direct_ops to retrieve the offset from
> the dma_data, rather than directly from the global.
>
> While we're here, change the way the offset is used - instead of or'ing it
> into the value, add it. This should have no effect on current implementations
> where the offset is far larger than memory, however in future we may want
> to use smaller offsets.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/dma_64.c | 11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
> index 14206e3..a2d076d 100644
> --- a/arch/powerpc/kernel/dma_64.c
> +++ b/arch/powerpc/kernel/dma_64.c
> @@ -117,6 +117,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
> */
> unsigned long dma_direct_offset;
>
> +static unsigned long get_dma_direct_offset(struct device *dev)
> +{
> + return (unsigned long)dev->archdata.dma_data;
> +}
> +
> static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> @@ -130,7 +135,7 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> return NULL;
> ret = page_address(page);
> memset(ret, 0, size);
> - *dma_handle = virt_to_abs(ret) | dma_direct_offset;
> + *dma_handle = virt_to_abs(ret) + get_dma_direct_offset(dev);
>
> return ret;
> }
> @@ -145,7 +150,7 @@ static dma_addr_t dma_direct_map_single(struct device *dev, void *ptr,
> size_t size,
> enum dma_data_direction direction)
> {
> - return virt_to_abs(ptr) | dma_direct_offset;
> + return virt_to_abs(ptr) + get_dma_direct_offset(dev);
> }
>
> static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
> @@ -161,7 +166,7 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> int i;
>
> for_each_sg(sgl, sg, nents, i) {
> - sg->dma_address = sg_phys(sg) | dma_direct_offset;
> + sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
> sg->dma_length = sg->length;
> }
>
^ permalink raw reply
* Re: [PATCH 2/7] Add celleb_dma_dev_setup()
From: Benjamin Herrenschmidt @ 2008-01-21 6:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <4bdf881cfc1386c5167495a5e64bdb9dc3ca90d5.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
> should set dma_data to dma_direct_offset.
>
> Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
> index 41e1e6f..843a66f 100644
> --- a/arch/powerpc/platforms/celleb/iommu.c
> +++ b/arch/powerpc/platforms/celleb/iommu.c
> @@ -72,6 +72,17 @@ static void __init celleb_init_direct_mapping(void)
> dma_direct_offset = dma_base;
> }
>
> +static void celleb_dma_dev_setup(struct device *dev)
> +{
> + dev->archdata.dma_ops = get_pci_dma_ops();
> + dev->archdata.dma_data = (void *)dma_direct_offset;
> +}
> +
> +static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
> +{
> + celleb_dma_dev_setup(&pdev->dev);
> +}
> +
> static int celleb_of_bus_notify(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> @@ -81,7 +92,7 @@ static int celleb_of_bus_notify(struct notifier_block *nb,
> if (action != BUS_NOTIFY_ADD_DEVICE)
> return 0;
>
> - dev->archdata.dma_ops = get_pci_dma_ops();
> + celleb_dma_dev_setup(dev);
>
> return 0;
> }
> @@ -94,6 +105,7 @@ static int __init celleb_init_iommu(void)
> {
> celleb_init_direct_mapping();
> set_pci_dma_ops(&dma_direct_ops);
> + ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
> bus_register_notifier(&of_platform_bus_type, &celleb_of_bus_notifier);
>
> return 0;
^ permalink raw reply
* Re: [PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: Benjamin Herrenschmidt @ 2008-01-21 6:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote:
> Store the direct_dma_offset in each device's dma_data in the case
> where we're using the direct DMA ops.
>
> We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback
> if we're using a non-zero offset.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/cell/iommu.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index bceb5e1..9682b63 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct device *dev)
> struct cbe_iommu *iommu;
> struct dev_archdata *archdata = &dev->archdata;
>
> - /* If we run without iommu, no need to do anything */
> - if (get_pci_dma_ops() == &dma_direct_ops)
> + if (get_pci_dma_ops() == &dma_direct_ops) {
> + archdata->dma_data = (void *)dma_direct_offset;
> return;
> + }
>
> /* Current implementation uses the first window available in that
> * node's iommu. We -might- do something smarter later though it may
> @@ -690,6 +691,9 @@ static int __init cell_iommu_init_disabled(void)
>
> dma_direct_offset += base;
>
> + if (dma_direct_offset != 0)
> + ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
> +
> printk("iommu: disabled, direct DMA offset is 0x%lx\n",
> dma_direct_offset);
>
^ permalink raw reply
* [PATCH 7/7] Remove bogus comment in dma_direct_alloc_coherent()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use
node local allocations) went in this comment makes no sense.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/dma_64.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 72fdc06..8423907 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -130,7 +130,6 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
void *ret;
int node = dev->archdata.numa_node;
- /* TODO: Maybe use the numa node here too ? */
page = alloc_pages_node(node, flag, get_order(size));
if (page == NULL)
return NULL;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 6/7] Remove the global dma_direct_offset
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
We no longer need the global dma_direct_offset, update the comment to
reflect the new reality.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/dma_64.c | 7 ++++---
include/asm-powerpc/dma-mapping.h | 2 --
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index a2d076d..72fdc06 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -112,10 +112,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
/*
* Generic direct DMA implementation
*
- * This implementation supports a global offset that can be applied if
- * the address at which memory is visible to devices is not 0.
+ * This implementation supports a per-device offset that can be applied if
+ * the address at which memory is visible to devices is not 0. Platform code
+ * can set archdata.dma_data to an unsigned long holding the offset. By
+ * default the offset is zero.
*/
-unsigned long dma_direct_offset;
static unsigned long get_dma_direct_offset(struct device *dev)
{
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index e974876..5eea6db 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -189,8 +189,6 @@ static inline void dma_unmap_sg(struct device *dev, struct scatterlist *sg,
extern struct dma_mapping_ops dma_iommu_ops;
extern struct dma_mapping_ops dma_direct_ops;
-extern unsigned long dma_direct_offset;
-
#else /* CONFIG_PPC64 */
#define dma_supported(dev, mask) (1)
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 5/7] Have celleb use its own dma_direct_offset variable
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Rather than using the global variable, have celleb use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/celleb/iommu.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
index 843a66f..93b0efd 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *io_space_id, u64 *ioid,
return 0;
}
+static unsigned long celleb_dma_direct_offset;
+
static void __init celleb_init_direct_mapping(void)
{
u64 lpar_addr, io_addr;
@@ -69,13 +71,13 @@ static void __init celleb_init_direct_mapping(void)
ioid, DMA_FLAGS);
}
- dma_direct_offset = dma_base;
+ celleb_dma_direct_offset = dma_base;
}
static void celleb_dma_dev_setup(struct device *dev)
{
dev->archdata.dma_ops = get_pci_dma_ops();
- dev->archdata.dma_data = (void *)dma_direct_offset;
+ dev->archdata.dma_data = (void *)celleb_dma_direct_offset;
}
static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 4/7] Have cell use its own dma_direct_offset variable
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Rather than using the global variable, have cell use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 9682b63..7f45d59 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
return NULL;
}
+static unsigned long cell_dma_direct_offset;
+
static void cell_dma_dev_setup(struct device *dev)
{
struct iommu_window *window;
@@ -497,7 +499,7 @@ static void cell_dma_dev_setup(struct device *dev)
struct dev_archdata *archdata = &dev->archdata;
if (get_pci_dma_ops() == &dma_direct_ops) {
- archdata->dma_data = (void *)dma_direct_offset;
+ archdata->dma_data = (void *)cell_dma_direct_offset;
return;
}
@@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabled(void)
/* If we have no Axon, we set up the spider DMA magic offset */
if (of_find_node_by_name(NULL, "axon") == NULL)
- dma_direct_offset = SPIDER_DMA_OFFSET;
+ cell_dma_direct_offset = SPIDER_DMA_OFFSET;
/* Now we need to check to see where the memory is mapped
* in PCI space. We assume that all busses use the same dma
@@ -689,13 +691,13 @@ static int __init cell_iommu_init_disabled(void)
return -ENODEV;
}
- dma_direct_offset += base;
+ cell_dma_direct_offset += base;
- if (dma_direct_offset != 0)
+ if (cell_dma_direct_offset != 0)
ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
- dma_direct_offset);
+ cell_dma_direct_offset);
return 0;
}
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 3/7] Use archdata.dma_data in dma_direct_ops and add the offset
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Now that all platforms using dma_direct_offset setup the archdata.dma_data
correctly, we can change the dma_direct_ops to retrieve the offset from
the dma_data, rather than directly from the global.
While we're here, change the way the offset is used - instead of or'ing it
into the value, add it. This should have no effect on current implementations
where the offset is far larger than memory, however in future we may want
to use smaller offsets.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/dma_64.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 14206e3..a2d076d 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -117,6 +117,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
*/
unsigned long dma_direct_offset;
+static unsigned long get_dma_direct_offset(struct device *dev)
+{
+ return (unsigned long)dev->archdata.dma_data;
+}
+
static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
@@ -130,7 +135,7 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
return NULL;
ret = page_address(page);
memset(ret, 0, size);
- *dma_handle = virt_to_abs(ret) | dma_direct_offset;
+ *dma_handle = virt_to_abs(ret) + get_dma_direct_offset(dev);
return ret;
}
@@ -145,7 +150,7 @@ static dma_addr_t dma_direct_map_single(struct device *dev, void *ptr,
size_t size,
enum dma_data_direction direction)
{
- return virt_to_abs(ptr) | dma_direct_offset;
+ return virt_to_abs(ptr) + get_dma_direct_offset(dev);
}
static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
@@ -161,7 +166,7 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
int i;
for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = sg_phys(sg) | dma_direct_offset;
+ sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
sg->dma_length = sg->length;
}
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/7] Add celleb_dma_dev_setup()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
should set dma_data to dma_direct_offset.
Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
index 41e1e6f..843a66f 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -72,6 +72,17 @@ static void __init celleb_init_direct_mapping(void)
dma_direct_offset = dma_base;
}
+static void celleb_dma_dev_setup(struct device *dev)
+{
+ dev->archdata.dma_ops = get_pci_dma_ops();
+ dev->archdata.dma_data = (void *)dma_direct_offset;
+}
+
+static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
+{
+ celleb_dma_dev_setup(&pdev->dev);
+}
+
static int celleb_of_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -81,7 +92,7 @@ static int celleb_of_bus_notify(struct notifier_block *nb,
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;
- dev->archdata.dma_ops = get_pci_dma_ops();
+ celleb_dma_dev_setup(dev);
return 0;
}
@@ -94,6 +105,7 @@ static int __init celleb_init_iommu(void)
{
celleb_init_direct_mapping();
set_pci_dma_ops(&dma_direct_ops);
+ ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
bus_register_notifier(&of_platform_bus_type, &celleb_of_bus_notifier);
return 0;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
Store the direct_dma_offset in each device's dma_data in the case
where we're using the direct DMA ops.
We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback
if we're using a non-zero offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index bceb5e1..9682b63 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct device *dev)
struct cbe_iommu *iommu;
struct dev_archdata *archdata = &dev->archdata;
- /* If we run without iommu, no need to do anything */
- if (get_pci_dma_ops() == &dma_direct_ops)
+ if (get_pci_dma_ops() == &dma_direct_ops) {
+ archdata->dma_data = (void *)dma_direct_offset;
return;
+ }
/* Current implementation uses the first window available in that
* node's iommu. We -might- do something smarter later though it may
@@ -690,6 +691,9 @@ static int __init cell_iommu_init_disabled(void)
dma_direct_offset += base;
+ if (dma_direct_offset != 0)
+ ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
+
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
dma_direct_offset);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Always hookup PHB IO resource even when empty
From: Michael Ellerman @ 2008-01-21 0:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080121003256.E1EBDDDDF0@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Mon, 2008-01-21 at 11:32 +1100, Benjamin Herrenschmidt wrote:
> We must always hookup the pci_bus resource 0 to the PHB io_resource even
> if the later is empty (the bus has no IO support). Otherwise, some other
> code will end up hooking it up to something bogus and the resource tree
> will end up being broken.
>
> This fixes boot on QS20 Cell blades where the IDE driver failed to allocate
> the IO resources due to breakage of the resource tree.
Tested-by: Michael Ellerman <michael@ellerman.id.au>
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Always hookup PHB IO resource even when empty
From: Benjamin Herrenschmidt @ 2008-01-21 0:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We must always hookup the pci_bus resource 0 to the PHB io_resource even
if the later is empty (the bus has no IO support). Otherwise, some other
code will end up hooking it up to something bogus and the resource tree
will end up being broken.
This fixes boot on QS20 Cell blades where the IDE driver failed to allocate
the IO resources due to breakage of the resource tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This is for 2.6.25, fixes a bug in my PCI rework.
arch/powerpc/kernel/pci_64.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
--- linux-merge.orig/arch/powerpc/kernel/pci_64.c 2008-01-21 11:27:41.000000000 +1100
+++ linux-merge/arch/powerpc/kernel/pci_64.c 2008-01-21 11:28:07.000000000 +1100
@@ -357,7 +357,6 @@ void __devinit scan_phb(struct pci_contr
struct pci_bus *bus;
struct device_node *node = hose->dn;
int i, mode;
- struct resource *res;
DBG("PCI: Scanning PHB %s\n", node ? node->full_name : "<NO NAME>");
@@ -375,12 +374,10 @@ void __devinit scan_phb(struct pci_contr
pcibios_map_io_space(bus);
/* Wire up PHB bus resources */
- if (hose->io_resource.flags) {
- DBG("PCI: PHB IO resource = %016lx-%016lx [%lx]\n",
- hose->io_resource.start, hose->io_resource.end,
- hose->io_resource.flags);
- bus->resource[0] = res = &hose->io_resource;
- }
+ DBG("PCI: PHB IO resource = %016lx-%016lx [%lx]\n",
+ hose->io_resource.start, hose->io_resource.end,
+ hose->io_resource.flags);
+ bus->resource[0] = &hose->io_resource;
for (i = 0; i < 3; ++i) {
DBG("PCI: PHB MEM resource %d = %016lx-%016lx [%lx]\n", i,
hose->mem_resources[i].start,
^ permalink raw reply
* Fwd: MPIC ISU
From: vb @ 2008-01-20 20:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f608b67d0801201216o60be67a1w3ead9714c3bba5aa@mail.gmail.com>
[add linuxppc-embedded@ozlabs.org,]
On Jan 19, 2008 8:19 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> >
> > what platform is linkstation and what kernel version can I find it in?
>
> arch/powerpc/platforms/embedded6xx/linkstation.c
>
> you should be able to find it 2.6.23 or newer.
>
Kumar, thank you for this clarification, I see this file in the latest kernel.
One more question, just out of curiosity - why is it in
platforms/embedded6xx and not in platforms/82xx - is there any
explicit reason for this distinction?
TIA,
/vb
> - k
>
>
^ permalink raw reply
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jon Smirl @ 2008-01-20 15:39 UTC (permalink / raw)
To: Jean Delvare, Benjamin Herrenschmidt; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801200718q7304bc29q38e67580613189e4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
Here' s a version with the compares to zero switched to NO_IRQ. If I
understand how NO_IRQ works it is the correct change. My understanding
is that under ppc IRQ zero was legal and NO_IRQ was -1. But then the
whole kernel switched to NO_IRQ = zero. Powerpc updated to NO_IRQ=0
and used virtual IRQs to move a physical IRQ 0 to another IRQ number.
ppc was not changed. This driver does not appear to have been updated
to track this global change since it didn't initially use the NO_IRQ
define everywhere.
--
Jon Smirl
jonsmirl@gmail.com
[-- Attachment #2: jds-fix-err-returns --]
[-- Type: application/octet-stream, Size: 3562 bytes --]
Clean up error returns
Return errors that were being ignored in the mpc-i2c driver
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/i2c/busses/i2c-mpc.c | 38 +++++++++++++++++++++-----------------
1 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..a774cdf 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
u32 x;
int result = 0;
- if (i2c->irq == 0)
+ if (i2c->irq == NO_IRQ)
{
while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
schedule();
@@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
for (i = 0; i < length; i++) {
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
}
return 0;
@@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c->adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- if (i2c_wait(i2c, timeout, 0) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 0);
+ if (result < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -321,12 +325,12 @@ static int fsl_i2c_probe(struct platform_device *pdev)
pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
- if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
+ i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
return -ENOMEM;
- }
i2c->irq = platform_get_irq(pdev, 0);
- if (i2c->irq < 0) {
+ if (i2c->irq < NO_IRQ) {
result = -ENXIO;
goto fail_get_irq;
}
@@ -341,7 +345,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
if ((result = request_irq(i2c->irq, mpc_i2c_isr,
IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
printk(KERN_ERR
@@ -364,7 +368,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
fail_irq:
iounmap(i2c->base);
@@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(&i2c->adap);
platform_set_drvdata(pdev, NULL);
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
iounmap(i2c->base);
^ permalink raw reply related
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jon Smirl @ 2008-01-20 15:18 UTC (permalink / raw)
To: Jean Delvare, Benjamin Herrenschmidt; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080120120730.06dd8a7f@hyperion.delvare>
On 1/20/08, Jean Delvare <khali@linux-fr.org> wrote:
> > @@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> > i2c_del_adapter(&i2c->adap);
> > platform_set_drvdata(pdev, NULL);
> >
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > free_irq(i2c->irq, i2c);
> >
> > iounmap(i2c->base);
> >
> >
>
> Is this last chunk a cleanup or a bugfix? It seems that NO_IRQ can have
> value 0 or -1 depending on the architecture, so your change is real on
> some architectures.
I was confused by this too. Search the ppc list archives and there is
a thread about it where BenH tries to explain the correct way of
fixing it to me.
This is part of the ppc to powerpc conversion that has not been
completely cleaned up in this driver. NO_IRQ = -1 is ppc and NO_IRQ =
0 is powerpc. Since this driver didn't originally use the NO_IRQ
define it didn't get automatically converted. We need to identify the
right places where NO_IRQ should have been used.
>
> I have to admit that I'm a bit confused by the way IRQs are handled by
> this driver. On the one hand, there is code to handle polled-mode:
>
> static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> {
> (...)
> if (i2c->irq == 0)
I missed this one, it should have been NO_IRQ.
> {
> (...)
> } else {
> /* Interrupt mode */
>
> But on the other hand the initialization code bails out if the platform
> device doesn't provide an IRQ:
>
> static int fsl_i2c_probe(struct platform_device *pdev)
> {
> (...)
> i2c->irq = platform_get_irq(pdev, 0);
> if (i2c->irq < 0) {
> result = -ENXIO;
> goto fail_get_irq;
It is only bailing out on an error, not the NO_IRQ case. But maybe the
comparison needs to be with NO_IRQ instead of zero.
> }
>
> So it seems to me like the polling mode code is never actually used?
> Unless some platforms include an "empty" IRQ in their device
> definition. Which indeed seems to be the case... but then they set the
> IRQ to 0, NOT to NO_IRQ, so I'm wondering if the change you propose is
> really correct.
All of this is very confusing to me, There are physical IRQs and
virtual IRQs. Apparently zero is a legal physical IRQ but it is not a
legal virtual IRQ. We only get virtual IRQs in this code. We need to
get BenH to give us the right answer on these two cases.
>
> Either way, there are more places in the driver where the IRQ is
> compared to 0, so if your change is correct, it should be applied
> consistently. Thus I will revert this part for the time being, if any
> change is really needed with regards to interrupts in this driver,
> please send a separate patch. But please double-check first, as I said
> above it's trickier than it looks.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jean Delvare @ 2008-01-20 11:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080112024743.7023.23630.stgit@terra.home>
Hi Jon,
On Fri, 11 Jan 2008 21:47:43 -0500, Jon Smirl wrote:
> Return errors that were being ignored in the mpc-i2c driver
This wording is a bit excessive. The errors were not being ignored,
only the error code was replaced with a less informative -1. Still,
that's a good fix, although totally unrelated with the patch set it was
hiding into. The only question I have is:
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 30 +++++++++++++++++-------------
> 1 files changed, 17 insertions(+), 13 deletions(-)
>
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index d8de4ac..7c35a8f 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
> static int mpc_write(struct mpc_i2c *i2c, int target,
> const u8 * data, int length, int restart)
> {
> - int i;
> + int i, result;
> unsigned timeout = i2c->adap.timeout;
> u32 flags = restart ? CCR_RSTA : 0;
>
> @@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
> /* Write target byte */
> writeb((target << 1), i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 1);
> + if (result < 0)
> + return result;
>
> for (i = 0; i < length; i++) {
> /* Write data byte */
> writeb(data[i], i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 1);
> + if (result < 0)
> + return result;
> }
>
> return 0;
> @@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
> u8 * data, int length, int restart)
> {
> unsigned timeout = i2c->adap.timeout;
> - int i;
> + int i, result;
> u32 flags = restart ? CCR_RSTA : 0;
>
> /* Start with MEN */
> @@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
> /* Write target address byte - this time with the read flag set */
> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 1);
> + if (result < 0)
> + return result;
>
> if (length) {
> if (length == 1)
> @@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
> }
>
> for (i = 0; i < length; i++) {
> - if (i2c_wait(i2c, timeout, 0) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 0);
> + if (result < 0)
> + return result;
>
> /* Generate txack on next to last byte */
> if (i == length - 2)
> @@ -321,9 +325,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
>
> pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
>
> - if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
> + i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
> + if (!i2c)
> return -ENOMEM;
> - }
>
> i2c->irq = platform_get_irq(pdev, 0);
> if (i2c->irq < 0) {
> @@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> i2c_del_adapter(&i2c->adap);
> platform_set_drvdata(pdev, NULL);
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
>
> iounmap(i2c->base);
>
>
Is this last chunk a cleanup or a bugfix? It seems that NO_IRQ can have
value 0 or -1 depending on the architecture, so your change is real on
some architectures.
I have to admit that I'm a bit confused by the way IRQs are handled by
this driver. On the one hand, there is code to handle polled-mode:
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
{
(...)
if (i2c->irq == 0)
{
(...)
} else {
/* Interrupt mode */
But on the other hand the initialization code bails out if the platform
device doesn't provide an IRQ:
static int fsl_i2c_probe(struct platform_device *pdev)
{
(...)
i2c->irq = platform_get_irq(pdev, 0);
if (i2c->irq < 0) {
result = -ENXIO;
goto fail_get_irq;
}
So it seems to me like the polling mode code is never actually used?
Unless some platforms include an "empty" IRQ in their device
definition. Which indeed seems to be the case... but then they set the
IRQ to 0, NOT to NO_IRQ, so I'm wondering if the change you propose is
really correct.
Either way, there are more places in the driver where the IRQ is
compared to 0, so if your change is correct, it should be applied
consistently. Thus I will revert this part for the time being, if any
change is really needed with regards to interrupts in this driver,
please send a separate patch. But please double-check first, as I said
above it's trickier than it looks.
--
Jean Delvare
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: John Rigby @ 2008-01-20 3:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801182259k22663ca9s74b109f0f15d11fd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Do you get a "Can't open initial console" message or just no output?
On Jan 18, 2008 11:59 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/18/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> > > PSCs change from 5200 to 5121
> > > this patch localizes the differences in
> > > preparation for adding 5121 support
> > >
> > > Signed-off-by: John Rigby <jrigby@freescale.com>
> >
> > This patch breaks the serial console on my Efika.
>
> Er, more specifically, I get console output, but I get no output from
> the init process (like when I add "init=/bin/sh" to the kernel
> parameters).
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 1583 bytes --]
^ permalink raw reply
* Re: MPIC ISU
From: Kumar Gala @ 2008-01-19 16:19 UTC (permalink / raw)
To: vb; +Cc: linuxppc-embedded
In-Reply-To: <f608b67d0801181044j352ee94dl50ea291164f4cb17@mail.gmail.com>
On Jan 18, 2008, at 12:44 PM, vb wrote:
> Kumar,
>
> thank you for your reply!
>
> On Jan 18, 2008 7:54 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>>>
>>> What is it, at the very least - what does ISU stand for?
>>>
>>> I would really appreciate any hints,
>>
>> Interrupt service unit. I believe its an IBM concept.
>>
>> For 8245 can you look at what the linkstation port is doing and mimic
>> that. I believe its an 8245 or 8241 so it should be close to what
>> you
>> need.
>>
>
> what platform is linkstation and what kernel version can I find it in?
arch/powerpc/platforms/embedded6xx/linkstation.c
you should be able to find it 2.6.23 or newer.
- k
^ permalink raw reply
* Re: [RFC/PATCH 1/2] [POWERPC] mpc5200: normalize compatible property bindings
From: Stephen Rothwell @ 2008-01-19 12:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, jrigby
In-Reply-To: <20080118170443.10592.97538.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi Grant,
On Fri, 18 Jan 2008 10:04:49 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -44,9 +44,14 @@ lite5200_fix_clock_config(void)
> {
> struct device_node *np;
> struct mpc52xx_cdm __iomem *cdm;
> + struct of_device_id cdm_ids[] = {
Surely this should be static and __initdata?
> @@ -79,9 +84,14 @@ lite5200_fix_port_config(void)
> {
> struct device_node *np;
> struct mpc52xx_gpio __iomem *gpio;
> + struct of_device_id gpio_ids[] = {
And this?
> +++ b/arch/powerpc/platforms/52xx/lite5200_pm.c
> @@ -43,6 +43,12 @@ static int lite5200_pm_set_target(suspend_state_t state)
> static int lite5200_pm_prepare(void)
> {
> struct device_node *np;
> + struct of_device_id immr_ids[] = {
This should be static and const.
Similarly for the rest ...
--
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 6/7] [POWERPC] Get rid of conditional includes of board specific setup
From: Arnd Bergmann @ 2008-01-19 12:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <4790B891.3050106@scram.de>
On Friday 18 January 2008, Jochen Friedrich wrote:
> Directly include mpc885ads.h from mpc885ads_setup.c. Now we can get rid
> of the arch dependent includes in mpc8xx.h.
Ah, very nice. How close are we to enabling an 8xx multiplatform
build after this?
> =A0#ifdef CONFIG_8xx
> =A0
> =A0extern void mpc8xx_restart(char *cmd);
> @@ -18,22 +20,9 @@ extern void mpc8xx_get_rtc_time(struct rtc_time *tm);
> =A0extern void mpc8xx_pics_init(void);
> =A0extern unsigned int mpc8xx_get_irq(void);
>=20
> #ifdef CONFIG_PCMCIA_M8XX
> extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
> #endif
=20
> =A0#endif /* CONFIG_8xx */
> =A0#endif /* __CONFIG_8xx_DEFS */
You can also kill the #ifdef CONFIG_8xx and the #ifdef CONFIG_PCMCIA_M8XX,
there is no point hiding extern declarations behind an #ifdef, but it
has the disadvantage of causing unnecessary rebuilds if the configuration
symbols change.
Arnd <><
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: Grant Likely @ 2008-01-19 6:59 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801182258r5a3b6465kf0e7918e0e56e0c4@mail.gmail.com>
On 1/18/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> > PSCs change from 5200 to 5121
> > this patch localizes the differences in
> > preparation for adding 5121 support
> >
> > Signed-off-by: John Rigby <jrigby@freescale.com>
>
> This patch breaks the serial console on my Efika.
Er, more specifically, I get console output, but I get no output from
the init process (like when I add "init=/bin/sh" to the kernel
parameters).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: Grant Likely @ 2008-01-19 6:58 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1200614738-25654-8-git-send-email-jrigby@freescale.com>
On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> PSCs change from 5200 to 5121
> this patch localizes the differences in
> preparation for adding 5121 support
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
This patch breaks the serial console on my Efika.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-19 4:56 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080117202024.GA25090@aepfle.de>
On Thu, 17 Jan 2008, Olaf Hering wrote:
> On Thu, Jan 17, Olaf Hering wrote:
>
> > Since -mm boots further, what patch should I try?
>
> rc8-mm1 crashes as well, l3 passed to reap_alien() is NULL.
Sigh. It looks like we need alien cache structures in some cases for nodes
that have no memory. We must allocate structures for all nodes regardless
if they have allocatable memory or not.
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-19 4:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080118065621.GA27495@aepfle.de>
On Fri, 18 Jan 2008, Olaf Hering wrote:
> calls cache_grow with nodeid 0
> > [c00000000075bbd0] [c0000000000f82d0] .cache_alloc_refill+0x234/0x2c0
> calls cache_grow with nodeid 0
> > [c00000000075bbe0] [c0000000000f7f38] .____cache_alloc_node+0x17c/0x1e8
>
> calls cache_grow with nodeid 1
> > [c00000000075bbe0] [c0000000000f7d68] .fallback_alloc+0x1a0/0x1f4
Okay that makes sense. You have no node 0 with normal memory but the node
assigned to the executing processor is zero (correct?). Thus it needs to
fallback to node 1 and that is not possible during bootstrap. You need to
run kmem_cache_init() on a cpu on a processor with memory.
Or we need to revert the patch which would allocate control
structures again for all online nodes regardless if they have memory or
not.
Does reverting 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 change the
situation? (However, we tried this on the other thread without success).
^ permalink raw reply
* [PATCH/RFC] [POWERPC] Allow multiple images to be built when CONFIG_DEFAULT_UIMAGE set
From: Grant Likely @ 2008-01-19 3:55 UTC (permalink / raw)
To: linuxppc-dev, paulus, scottwood, david
From: Grant Likely <grant.likely@secretlab.ca>
Most of the embedded board ports select CONFIG_DEFAULT_UIMAGE so that
uImage files get built by default. However, the current code casues
the arch/powerpc/boot/Makefile to be called with the 'uImage' target
and adds 'uImage' to the 'image-y' make variable. If CONFIG_DEFAULT_UIMAGE
is not set, then the boot makefile is called with target 'zImage'.
However, the zImage target already automatically causes all targets
listed in 'image-y' to be built, which includes uImage.
This patch makes the default build target alwasy call the boot makefile
using the 'zImage' target, regardless of if CONFIG_DEFAULT_UIMAGE is set.
Making this change allows multiple boot images to be built from a single
kernel compile. An example of where this is useful is with the Efika
and lite5200 boards. Both boards can use the same kernel image (vmlinux),
but they use different boot image files (zImage.chrp vs. uImage). By
making this change, the boot makefile now builds both by default so a
single defconfig can be used for testing both platforms.
This patch also eliminates the BOOTIMAGE variable because it doesn't
appear to be used anywhere. (Someone please correct me if I'm wrong)
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/Makefile | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6451c2f 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,10 +151,7 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
^ permalink raw reply related
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