* [POWERPC 07/18] Have cell use its own dma_direct_offset variable
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
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>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/iommu.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
@@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_
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 de
struct dev_archdata *archdata = &dev->archdata;
if (get_pci_dma_ops() == &dma_direct_ops) {
- archdata->dma_data = &dma_direct_offset;
+ archdata->dma_data = &cell_dma_direct_offset;
return;
}
@@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabl
/* 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,10 +691,10 @@ static int __init cell_iommu_init_disabl
return -ENODEV;
}
- dma_direct_offset += base;
+ cell_dma_direct_offset += base;
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
- dma_direct_offset);
+ cell_dma_direct_offset);
return 0;
}
--
^ permalink raw reply
* [POWERPC 05/18] Add celleb_dma_dev_setup()
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
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>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/celleb/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
@@ -72,6 +72,17 @@ static void __init celleb_init_direct_ma
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 = &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 n
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;
- dev->archdata.dma_ops = get_pci_dma_ops();
+ celleb_dma_dev_setup(dev);
return 0;
}
@@ -97,6 +108,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
* [POWERPC 09/18] Remove the global dma_direct_offset
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
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>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/kernel/dma_64.c | 7 ++++---
include/asm-powerpc/dma-mapping.h | 2 --
2 files changed, 4 insertions(+), 5 deletions(-)
Index: linux-2.6-new/arch/powerpc/kernel/dma_64.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/kernel/dma_64.c
+++ linux-2.6-new/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 point archdata.dma_data at an unsigned long holding the offset. By
+ * default no offset is used.
*/
-unsigned long dma_direct_offset;
static unsigned long get_dma_direct_offset(struct device *dev)
{
Index: linux-2.6-new/include/asm-powerpc/dma-mapping.h
===================================================================
--- linux-2.6-new.orig/include/asm-powerpc/dma-mapping.h
+++ linux-2.6-new/include/asm-powerpc/dma-mapping.h
@@ -186,8 +186,6 @@ static inline void dma_unmap_sg(struct d
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)
--
^ permalink raw reply
* [POWERPC 04/18] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
Store a pointer to the direct_dma_offset in each device's dma_data
in the case where we're using the direct DMA ops.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/iommu.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
@@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct de
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 = &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
--
^ permalink raw reply
* [POWERPC 08/18] Have celleb use its own dma_direct_offset variable
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
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>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/celleb/iommu.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/celleb/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
@@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *i
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_ma
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 = &dma_direct_offset;
+ dev->archdata.dma_data = &celleb_dma_direct_offset;
}
static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
--
^ permalink raw reply
* [POWERPC 11/18] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <20071218174852.112644000@arndb.de>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/cbe_cpufreq.c | 3 ++-
arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c | 3 ++-
arch/powerpc/platforms/cell/cbe_regs.c | 4 ++--
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/cell/setup.c | 2 +-
arch/powerpc/platforms/celleb/iommu.c | 3 +--
arch/powerpc/platforms/celleb/setup.c | 2 +-
7 files changed, 10 insertions(+), 9 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -21,8 +21,9 @@
*/
#include <linux/cpufreq.h>
+#include <linux/of_platform.h>
+
#include <asm/machdep.h>
-#include <asm/of_platform.h>
#include <asm/prom.h>
#include <asm/cell-regs.h>
#include "cbe_cpufreq.h"
Index: linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
@@ -23,7 +23,8 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/timer.h>
-#include <asm/of_platform.h>
+#include <linux/of_platform.h>
+
#include <asm/processor.h>
#include <asm/prom.h>
#include <asm/pmi.h>
Index: linux-2.6-new/arch/powerpc/platforms/cell/cbe_regs.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/cbe_regs.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/cbe_regs.c
@@ -9,13 +9,13 @@
#include <linux/percpu.h>
#include <linux/types.h>
#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/prom.h>
#include <asm/ptrace.h>
-#include <asm/of_device.h>
-#include <asm/of_platform.h>
#include <asm/cell-regs.h>
/*
Index: linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
@@ -26,13 +26,13 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/notifier.h>
+#include <linux/of_platform.h>
#include <asm/prom.h>
#include <asm/iommu.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
#include <asm/udbg.h>
-#include <asm/of_platform.h>
#include <asm/lmb.h>
#include <asm/firmware.h>
#include <asm/cell-regs.h>
Index: linux-2.6-new/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/setup.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/setup.c
@@ -30,6 +30,7 @@
#include <linux/console.h>
#include <linux/mutex.h>
#include <linux/memory_hotplug.h>
+#include <linux/of_platform.h>
#include <asm/mmu.h>
#include <asm/processor.h>
@@ -51,7 +52,6 @@
#include <asm/spu_priv1.h>
#include <asm/udbg.h>
#include <asm/mpic.h>
-#include <asm/of_platform.h>
#include <asm/cell-regs.h>
#include "interrupt.h"
Index: linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/celleb/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
@@ -22,8 +22,8 @@
#include <linux/init.h>
#include <linux/dma-mapping.h>
#include <linux/pci.h>
+#include <linux/of_platform.h>
-#include <asm/of_platform.h>
#include <asm/firmware.h>
#include "beat_wrapper.h"
Index: linux-2.6-new/arch/powerpc/platforms/celleb/setup.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/celleb/setup.c
+++ linux-2.6-new/arch/powerpc/platforms/celleb/setup.c
@@ -40,6 +40,7 @@
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/console.h>
+#include <linux/of_platform.h>
#include <asm/mmu.h>
#include <asm/processor.h>
@@ -52,7 +53,6 @@
#include <asm/time.h>
#include <asm/spu_priv1.h>
#include <asm/firmware.h>
-#include <asm/of_platform.h>
#include <asm/rtas.h>
#include <asm/cell-regs.h>
--
^ permalink raw reply
* [POWERPC 03/18] cell: add missing \n
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
Two printk() calls were missing the terminating '\n'.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_manage.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_manage.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_manage.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_manage.c
@@ -345,7 +345,7 @@ static int __init of_create_spu(struct s
}
ret = spu_map_interrupts_old(spu, spe);
if (ret) {
- printk(KERN_ERR "%s: could not map interrupts",
+ printk(KERN_ERR "%s: could not map interrupts\n",
spu->name);
goto out_unmap;
}
@@ -525,7 +525,7 @@ static int __init init_affinity(void)
if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
init_affinity_qs20_harcoded();
else
- printk("No affinity configuration found");
+ printk("No affinity configuration found\n");
}
return 0;
--
^ permalink raw reply
* Getting this error when mounting the jffs2 partition created using mkImage..
From: ravi.rao @ 2007-12-18 19:02 UTC (permalink / raw)
To: linuxlink-help, linuxppc-embedded; +Cc: Miki.Groftisza
[-- Attachment #1: Type: text/plain, Size: 14453 bytes --]
Hi All,
I have u-boot based bootloader on our custom board based on
ppc405EP.
Various partitions are..
Amd/Fujitsu Extended Query Table at 0x0040
RoadRunner: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 5 MTD partitions on "RoadRunner":
0x03fc0000-0x04000000 : "U-Boot based RR Boot loader"
0x03fa0000-0x03fc0000 : "U-Boot Env Storage"
0x03f80000-0x03fa0000 : "U-Boot Redundant Env Storage"
0x027c0000-0x03f80000 : "Kernel Image"
0x00000000-0x027c0000 : "JFFS2 Linux FS"
I have used the following command to create the jffs2 file system image.
$BLDTOOLS/mkfs.jffs2 -b -e 0x10000 -d $JFFS2 -p 0x27c0000 -o rr-app_64.img
${MKIMAGE} -T filesystem -n 'RR App Image for AMD' -d rr-app_64.img
uRR-app_64
I did tftp the uRR-app_64 at the uboot prompt and copy the image to flash
at address 0xfc000000 using the command..
=> tftp 1000000 rr1/uRR-app_64
Trying ppc_4xx_eth0
PHY AN speed read failed, assuming 10BASE-T
PHY AN duplex read failed, assuming half duplex
ENET Speed is 10 Mbps - HALF duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server 10.2.1.1; our IP address is 10.2.254.125
Filename 'rr1/uRR-app_64'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#########################
done
Bytes transferred = 9109568 (8b0040 hex)
=> cp.b 1000000 fc000000 8b0040
addr=>FC000000 ...flash_id=>000000AA ... start=>FC000000 ...end=>FDFFFFFF
...Copy to Flash...
addr=>FC000000 ...flash_id=>000000AA ... start=>FC000000 ...end=>FDFFFFFF
...
addr=>FC8B003F ...flash_id=>000000AA ... start=>FC000000 ...end=>FDFFFFFF
...
addr=>FC000000 ... end=>FC8B003F ...info_first=>03FFDF00 ...
info_last=>03FFDF00 ...
Writing from src 0x1000000 to addr 0xfc000000 of length 9109568 and count
= 9109568
done
Board boot's up fine but I get the following error at the end of boot..
IP-Config: Complete:
device=eth0, addr=10.2.254.125, mask=255.255.0.0, gw=10.2.0.1,
host=unknown, domain=, nis-domain=(none),
bootserver=10.2.1.1, rootserver=10.2.1.1, rootpath=
Freeing unused kernel memory: 112k init
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
0x2705 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004:
0xdf63 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008:
0x4768 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c:
0x008b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018:
0xe581 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c:
0x0507 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020:
0x5252 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024:
0x7070 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000028:
0x6d61 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000002c:
0x2066 instead
Further such events for this erase block will not be printed
CLEANMARKER node found at 0x00000040, not first node in block (0x00000000)
Node at 0x0000fbe0 with length 0x0000045a would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010000:
0x0103 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010004:
0xffa0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010008:
0xa361 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001000c:
0x15a0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010010:
0xfd66 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010014:
0xcfd1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010018:
0x1040 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001001c:
0x52ab instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010020:
0x002c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00010024:
0xe510 instead
Further such events for this erase block will not be printed
Empty flash at 0x0001003c ends at 0x00010040
CLEANMARKER node found at 0x00010040, not first node in block (0x00010000)
Node at 0x0001fc38 with length 0x00000403 would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000:
0x0c22 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004:
0x1924 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020008:
0x32c8 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002000c:
0xc8a0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020010:
0x91c1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020014:
0x46ba instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020018:
0xbf76 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002001c:
0x1313 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020020:
0x3c50 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020024:
0x1040 instead
Further such events for this erase block will not be printed
Empty flash at 0x0002003c ends at 0x00020040
CLEANMARKER node found at 0x00020040, not first node in block (0x00020000)
Node at 0x0002f8e0 with length 0x0000075b would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030000:
0x4cff instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030004:
0x0e27 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030008:
0x1b50 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0003000c:
0xc760 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030010:
0x4f80 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030014:
0xdaaf instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030018:
0x9b43 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0003001c:
0x6103 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030020:
0xb076 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030024:
0x00a1 instead
Further such events for this erase block will not be printed
Empty flash at 0x0003003c ends at 0x00030040
CLEANMARKER node found at 0x00030040, not first node in block (0x00030000)
Node at 0x0003f954 with length 0x000006e8 would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040000:
0x2b40 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040004:
0x6d4f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040008:
0x6db6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004000c:
0xb0be instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040010:
0xe8c8 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040014:
0x712e instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040018:
0xd01d instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004001c:
0xf2bb instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040020:
0x0350 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040024:
0x0a83 instead
Further such events for this erase block will not be printed
Empty flash at 0x0004003c ends at 0x00040040
CLEANMARKER node found at 0x00040040, not first node in block (0x00040000)
Node at 0x0004f7f0 with length 0x0000084a would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050000:
0xfda7 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050004:
0xd769 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050008:
0xf4db instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005000c:
0x06fa instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050010:
0xe86f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050014:
0x0132 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050018:
0xd8be instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0005001c:
0x0710 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050020:
0x7980 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00050024:
0x63a8 instead
Further such events for this erase block will not be printed
Empty flash at 0x0005003c ends at 0x00050040
CLEANMARKER node found at 0x00050040, not first node in block (0x00050000)
Node at 0x0005f8ac with length 0x0000078f would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060000:
0x501a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060004:
0x00b6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060008:
0x4e02 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006000c:
0x9ccc instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060010:
0x4d0c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060014:
0x0c3f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060018:
0xd81b instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006001c:
0xea19 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060020:
0x3258 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060024:
0xfb51 instead
Further such events for this erase block will not be printed
Empty flash at 0x0006003c ends at 0x00060040
CLEANMARKER node found at 0x00060040, not first node in block (0x00060000)
Node at 0x0006f8c0 with length 0x0000077c would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070000:
0x7dc1 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070004:
0x9b76 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070008:
0x0750 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0007000c:
0x5a5f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070010:
0x90cd instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070014:
0x7803 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070018:
0xacfe instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0007001c:
0x2fc0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070020:
0x6a6f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00070024:
0xba07 instead
Further such events for this erase block will not be printed
Empty flash at 0x0007003c ends at 0x00070040
CLEANMARKER node found at 0x00070040, not first node in block (0x00070000)
Node at 0x0007ff34 with length 0x00000107 would run over the end of the
erase block
Perhaps the file system was created with the wrong erase size?
Any help to resolve this issue is greatly appreciated..
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
[-- Attachment #2: Type: text/html, Size: 22723 bytes --]
^ permalink raw reply
* Re: [POWERPC 04/18] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: Benjamin Herrenschmidt @ 2007-12-18 19:48 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175104.219782000@arndb.de>
On Tue, 2007-12-18 at 18:48 +0100, arnd@arndb.de wrote:
> plain text document attachment
> (0014-Set-archdata.dma_data-for-direct-DMA-in-cell_dma_dev.patch)
> Store a pointer to the direct_dma_offset in each device's dma_data
> in the case where we're using the direct DMA ops.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ack.
> ---
> arch/powerpc/platforms/cell/iommu.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/platforms/cell/iommu.c
> +++ linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
> @@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct de
> 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 = &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
>
^ permalink raw reply
* Re: [POWERPC 05/18] Add celleb_dma_dev_setup()
From: Benjamin Herrenschmidt @ 2007-12-18 19:48 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175104.432538000@arndb.de>
On Tue, 2007-12-18 at 18:48 +0100, arnd@arndb.de wrote:
> plain text document attachment (0015-Add-celleb_dma_dev_setup.patch)
> 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>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Ack.
> arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/platforms/celleb/iommu.c
> +++ linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
> @@ -72,6 +72,17 @@ static void __init celleb_init_direct_ma
> 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 = &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 n
> if (action != BUS_NOTIFY_ADD_DEVICE)
> return 0;
>
> - dev->archdata.dma_ops = get_pci_dma_ops();
> + celleb_dma_dev_setup(dev);
>
> return 0;
> }
> @@ -97,6 +108,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: [POWERPC 06/18] Use archdata.dma_data in dma_direct_ops
From: Benjamin Herrenschmidt @ 2007-12-18 19:49 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175104.638243000@arndb.de>
On Tue, 2007-12-18 at 18:48 +0100, arnd@arndb.de wrote:
> plain text document attachment
> (0016-Use-archdata.dma_data-in-dma_direct_ops.patch)
> 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.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ack.
> arch/powerpc/kernel/dma_64.c | 18 +++++++++++++++---
> 1 files changed, 15 insertions(+), 3 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/kernel/dma_64.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/kernel/dma_64.c
> +++ linux-2.6-new/arch/powerpc/kernel/dma_64.c
> @@ -117,6 +117,18 @@ EXPORT_SYMBOL(dma_iommu_ops);
> */
> unsigned long dma_direct_offset;
>
> +static unsigned long get_dma_direct_offset(struct device *dev)
> +{
> + unsigned long *offset;
> +
> + offset = dev->archdata.dma_data;
> +
> + if (offset)
> + return *offset;
> +
> + return 0;
> +}
> +
> static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> @@ -130,7 +142,7 @@ static void *dma_direct_alloc_coherent(s
> 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 +157,7 @@ static dma_addr_t dma_direct_map_single(
> 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 +173,7 @@ static int dma_direct_map_sg(struct devi
> 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: [POWERPC 07/18] Have cell use its own dma_direct_offset variable
From: Benjamin Herrenschmidt @ 2007-12-18 19:50 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175104.846274000@arndb.de>
On Tue, 2007-12-18 at 18:48 +0100, arnd@arndb.de wrote:
> plain text document attachment
> (0017-Have-cell-use-its-own-dma_direct_offset-variable.patch)
> 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>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Ack.
> arch/powerpc/platforms/cell/iommu.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/platforms/cell/iommu.c
> +++ linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
> @@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_
> 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 de
> struct dev_archdata *archdata = &dev->archdata;
>
> if (get_pci_dma_ops() == &dma_direct_ops) {
> - archdata->dma_data = &dma_direct_offset;
> + archdata->dma_data = &cell_dma_direct_offset;
> return;
> }
>
> @@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabl
>
> /* 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,10 +691,10 @@ static int __init cell_iommu_init_disabl
> return -ENODEV;
> }
>
> - dma_direct_offset += base;
> + cell_dma_direct_offset += base;
>
> printk("iommu: disabled, direct DMA offset is 0x%lx\n",
> - dma_direct_offset);
> + cell_dma_direct_offset);
>
> return 0;
> }
>
^ permalink raw reply
* Re: [POWERPC 08/18] Have celleb use its own dma_direct_offset variable
From: Benjamin Herrenschmidt @ 2007-12-18 19:50 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175105.049114000@arndb.de>
On Tue, 2007-12-18 at 18:49 +0100, arnd@arndb.de wrote:
> plain text document attachment
> (0018-Have-celleb-use-its-own-dma_direct_offset-variable.patch)
> 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>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Ack.
> arch/powerpc/platforms/celleb/iommu.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/platforms/celleb/iommu.c
> +++ linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
> @@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *i
> 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_ma
> 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 = &dma_direct_offset;
> + dev->archdata.dma_data = &celleb_dma_direct_offset;
> }
>
> static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
>
^ permalink raw reply
* Re: [POWERPC 09/18] Remove the global dma_direct_offset
From: Benjamin Herrenschmidt @ 2007-12-18 19:52 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175105.263700000@arndb.de>
On Tue, 2007-12-18 at 18:49 +0100, arnd@arndb.de wrote:
> plain text document attachment
> (0019-Remove-the-global-dma_direct_offset.patch)
> 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>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Ack.
> arch/powerpc/kernel/dma_64.c | 7 ++++---
> include/asm-powerpc/dma-mapping.h | 2 --
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/kernel/dma_64.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/kernel/dma_64.c
> +++ linux-2.6-new/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 point archdata.dma_data at an unsigned long holding the offset. By
> + * default no offset is used.
> */
> -unsigned long dma_direct_offset;
>
> static unsigned long get_dma_direct_offset(struct device *dev)
> {
> Index: linux-2.6-new/include/asm-powerpc/dma-mapping.h
> ===================================================================
> --- linux-2.6-new.orig/include/asm-powerpc/dma-mapping.h
> +++ linux-2.6-new/include/asm-powerpc/dma-mapping.h
> @@ -186,8 +186,6 @@ static inline void dma_unmap_sg(struct d
> 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)
>
^ permalink raw reply
* Re: [POWERPC 10/18] Remove bogus comment in dma_direct_alloc_coherent()
From: Benjamin Herrenschmidt @ 2007-12-18 19:52 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071218175105.491157000@arndb.de>
On Tue, 2007-12-18 at 18:49 +0100, arnd@arndb.de wrote:
> plain text document attachment
> (0020-Remove-bogus-comment-in-dma_direct_alloc_coherent.patch)
> 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>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Ack.
> arch/powerpc/kernel/dma_64.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> Index: linux-2.6-new/arch/powerpc/kernel/dma_64.c
> ===================================================================
> --- linux-2.6-new.orig/arch/powerpc/kernel/dma_64.c
> +++ linux-2.6-new/arch/powerpc/kernel/dma_64.c
> @@ -137,7 +137,6 @@ static void *dma_direct_alloc_coherent(s
> 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;
>
^ permalink raw reply
* Re: [POWERPC 00/18] cell patches for 2.6.25
From: Arnd Bergmann @ 2007-12-18 20:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20071218174852.112644000@arndb.de>
On Tuesday 18 December 2007, arnd@arndb.de wrote:
> Paul, if there are no objections to these patches, please pull them from
>=20
> =A0 git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2=
=2E6.25
I just noticed that quilt ate the 'From' lines from the patches when sending
them out, so make sure you don't apply them from mail. The git tree is
fine, so I can send them out as patches again if necessary.
Arnd <><
^ permalink raw reply
* ppc405 in EDK9.2
From: Stephen Neuendorffer @ 2007-12-18 20:29 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, simekm2
=09
The PPC405 in EDK9.2 and beyond has a slightly different set of bus
interfaces than before. I've updated the BSP generator to handle it,
and added some test cases. The updates are at
git://git.xilinx.com/gen-mhs-devtree.git
Steve
^ permalink raw reply
* Re: [PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
From: Mark A. Greer @ 2007-12-18 21:35 UTC (permalink / raw)
To: Mark A. Greer, linuxppc-dev
In-Reply-To: <20071214220335.GA21311@localhost.localdomain>
On Sat, Dec 15, 2007 at 09:03:35AM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 05:37:38PM -0700, Mark A. Greer wrote:
> > From: Mark A. Greer <mgreer@mvista.com>
> >
> > Convert the prpmc2800.dts file to dts-v1. Basically, this means
> > converting the numeric constants to be 'C'-like (e.g., hexadecimal
> > numbers start with '0x').
>
> [snip]
> > interrupt-parent = <&/mv64x60/pic>;
>
> If you're converting to dts-v1, you should also convert any path
> references like this to &{/mv64x60/pic} or else use a label. Yes,
> some early dts-v1 supporting dtc versions supported these as is, but
> the idea is to try to forget that they existed and always require the
> {} quoting in dts-v1.
I did convert to use labels in a later patch but it uses <&label> as
well. I can change them to &{label} that it appears you are suggesting
(I haven't tested to see that they work yet though).
Mark
^ permalink raw reply
* Re: [PATCH] Fix sleep on powerbook 3400
From: Paul Mackerras @ 2007-12-18 22:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1197977322.4885.109.camel@johannes.berg>
Johannes Berg writes:
> Do you want me to rebase my patches on top of this?
Don't bother, I'll just tweak your patches, or do a git merge between
your changes and mine.
Paul.
^ permalink raw reply
* Re: Raising list size limit
From: David Gibson @ 2007-12-18 22:33 UTC (permalink / raw)
To: Olof Johansson; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <20071218161208.GA7495@lixom.net>
On Tue, Dec 18, 2007 at 10:12:08AM -0600, Olof Johansson wrote:
> On Tue, Dec 18, 2007 at 09:54:15AM -0600, Kumar Gala wrote:
> >
> > On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote:
> >
> > > On Tue, 18 Dec 2007 14:36:27 +1100
> > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > >> Hi,
> > >>
> > >> I am considering raising the limit on the size of postings to
> > >> 400k. Does
> > >> anyone have a real problem with this? Limiting message size was
> > >> done to
> > >> limit the damage of larges spams (and we don;t get very many of
> > >> those on
> > >> the list) and to ease the pain for people downloading emails over a
> > >> slow
> > >> (like dialup) link (and are there many of those left?).
> > >
> > > Fine by me!
> >
> > Do you really have patches that are 400k?
>
> I'm guessing stuff such as "dtc merge" could reach those sizes?
dtc merge was 224k, if it had stayed together with the libfdt merge it
would have been a about 300k.
--
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 1/8] powerpc: prpmc2800 - Convert dts file to v1
From: David Gibson @ 2007-12-18 22:38 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071218213506.GB30388@mag.az.mvista.com>
On Tue, Dec 18, 2007 at 02:35:06PM -0700, Mark A. Greer wrote:
> On Sat, Dec 15, 2007 at 09:03:35AM +1100, David Gibson wrote:
> > On Mon, Dec 10, 2007 at 05:37:38PM -0700, Mark A. Greer wrote:
> > > From: Mark A. Greer <mgreer@mvista.com>
> > >
> > > Convert the prpmc2800.dts file to dts-v1. Basically, this means
> > > converting the numeric constants to be 'C'-like (e.g., hexadecimal
> > > numbers start with '0x').
> >
> > [snip]
> > > interrupt-parent = <&/mv64x60/pic>;
> >
> > If you're converting to dts-v1, you should also convert any path
> > references like this to &{/mv64x60/pic} or else use a label. Yes,
> > some early dts-v1 supporting dtc versions supported these as is, but
> > the idea is to try to forget that they existed and always require the
> > {} quoting in dts-v1.
>
> I did convert to use labels in a later patch but it uses <&label> as
> well. I can change them to &{label} that it appears you are suggesting
> (I haven't tested to see that they work yet though).
&label is fine, it's just &/full/path that needs changing.
I realised you removed all the &/full/path things in a later patch, so
the series as a whole will work. But this patch alleges to convert to
dts-v1 of itself, but because it fails to requote the path references,
it doesn't.
--
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] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: David Gibson @ 2007-12-18 22:39 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <4767F271.4090703@freescale.com>
On Tue, Dec 18, 2007 at 10:16:49AM -0600, Scott Wood wrote:
> David Gibson wrote:
> > In this case the driver and binding have been developed together and
> > for the time being it does require PHY nodes, obviously. I'm saying
> > that maybe that requirement ought to be changed.
>
> I don't see why.
>
> > Well, phandle is only used to find the phy node itself, so it doesn't
> > count. The only piece of information there is the reg - the PHY id.
> > Following a phandle to another node is a fairly complex way of finding
> > a single integer.
> >
> > Eh, I guess it's ok, but just directly giving the PHY id or a probe
> > mask in the MAC node would also be fine (we do this for 4xx EMAC).
>
> It's not just a simple integer -- it also tells you which mdio bus
> it's on.
Ah, good point. Ok, I withdraw my complaints.
--
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: Raising list size limit
From: Stephen Rothwell @ 2007-12-18 23:20 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20071218143627.94f76142.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On Tue, 18 Dec 2007 14:36:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I am considering raising the limit on the size of postings to 400k. Does
> anyone have a real problem with this? Limiting message size was done to
> limit the damage of larges spams (and we don;t get very many of those on
> the list) and to ease the pain for people downloading emails over a slow
> (like dialup) link (and are there many of those left?).
OK, this is done now. Do your worst :-)
--
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
* DTS files, 83xx, clock frequencies
From: Russell McGuire @ 2007-12-18 23:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.543.1198006353.17691.linuxppc-embedded@ozlabs.org>
All,
I note that in most of the 83xx dts config files that the different
frequency fields are being populated with non-zero numbers. i.e. bus-freq,
clock-freq, core-freq, etc...
Isn't default behavior that these fields are kept from the <BIOS> U-boot
during boot, if a zero is present? Is there any advantage to resetting them
within the dts file during linux boot up? Or is it necessary to populate
these values for correct operations, specifically with in the QUICC Engines?
Over all my curiosity is that between versions of the board, i.e. different
CPU's that may be clocked faster or slower, I see no reason to change the
dts/blobs if I already have to change the BIOS to correctly boot up.
-Russ
^ permalink raw reply
* Re: DTS files, 83xx, clock frequencies
From: Scott Wood @ 2007-12-18 23:59 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000001c841ce$d11fcdd0$6405a8c0@absolut>
Russell McGuire wrote:
> I note that in most of the 83xx dts config files that the different
> frequency fields are being populated with non-zero numbers. i.e. bus-freq,
> clock-freq, core-freq, etc...
>
> Isn't default behavior that these fields are kept from the <BIOS> U-boot
> during boot, if a zero is present?
U-boot overwrites those values regardless of whether they were zero in
the dts.
> Is there any advantage to resetting them
> within the dts file during linux boot up?
No, and it doesn't. If you're looking arch/powerpc/boot, then that's
for compatibility with non-device-tree-aware u-boots.
-Scott
^ 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