* [PATCH 7/7] fdt.c: Refactor unflatten_device_tree and add fdt_unflatten_tree
From: Stephen Neuendorffer @ 2010-11-18 23:55 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-7-git-send-email-stephen.neuendorffer@xilinx.com>
unflatten_device_tree has two dependencies on things that happen
during boot time. Firstly, it references the initial device tree
directly. Secondly, it allocates memory using the early boot
allocator. This patch factors out these dependencies and uses
the new __unflatten_device_tree function to implement a driver-visible
fdt_unflatten_tree function, which can be used to unflatten a
blob after boot time.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
--
V2: remove extra __va() call
make dt_alloc functions return void *. This doesn't fix the general
strangeness in this code that constantly casts back and forth between
unsigned long and __be32 *
---
drivers/of/fdt.c | 149 +++++++++++++++++++++++++++++++----------------
include/linux/of_fdt.h | 2 +
2 files changed, 100 insertions(+), 51 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 236a8c9..e29dbe2 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -11,10 +11,12 @@
#include <linux/kernel.h>
#include <linux/initrd.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/string.h>
#include <linux/errno.h>
+#include <linux/slab.h>
#ifdef CONFIG_PPC
#include <asm/machdep.h>
@@ -312,6 +314,94 @@ unsigned long unflatten_dt_node(struct boot_param_header *blob,
return mem;
}
+/**
+ * __unflatten_device_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens a device-tree, creating the
+ * tree of struct device_node. It also fills the "name" and "type"
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ * @blob: The blob to expand
+ * @mynodes: The device_node tree created by the call
+ * @dt_alloc: An allocator that provides a virtual address to memory
+ * for the resulting tree
+ */
+void __unflatten_device_tree(struct boot_param_header *blob,
+ struct device_node **mynodes,
+ void * (*dt_alloc)(u64 size, u64 align))
+{
+ unsigned long start, mem, size;
+ struct device_node **allnextp = mynodes;
+
+ pr_debug(" -> unflatten_device_tree()\n");
+
+ if (!blob) {
+ pr_debug("No device tree pointer\n");
+ return;
+ }
+
+ pr_debug("Unflattening device tree:\n");
+ pr_debug("magic: %08x\n", be32_to_cpu(blob->magic));
+ pr_debug("size: %08x\n", be32_to_cpu(blob->totalsize));
+ pr_debug("version: %08x\n", be32_to_cpu(blob->version));
+
+ if (be32_to_cpu(blob->magic) != OF_DT_HEADER) {
+ pr_err("Invalid device tree blob header\n");
+ return;
+ }
+
+ /* First pass, scan for size */
+ start = ((unsigned long)blob) +
+ be32_to_cpu(blob->off_dt_struct);
+ size = unflatten_dt_node(blob, 0, &start, NULL, NULL, 0);
+ size = (size | 3) + 1;
+
+ pr_debug(" size is %lx, allocating...\n", size);
+
+ /* Allocate memory for the expanded device tree */
+ mem = (unsigned long)
+ dt_alloc(size + 4, __alignof__(struct device_node));
+
+ ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
+
+ pr_debug(" unflattening %lx...\n", mem);
+
+ /* Second pass, do actual unflattening */
+ start = ((unsigned long)blob) +
+ be32_to_cpu(blob->off_dt_struct);
+ unflatten_dt_node(blob, mem, &start, NULL, &allnextp, 0);
+ if (be32_to_cpup((__be32 *)start) != OF_DT_END)
+ pr_warning("Weird tag at end of tree: %08x\n", *((u32 *)start));
+ if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
+ pr_warning("End of tree marker overwritten: %08x\n",
+ be32_to_cpu(((__be32 *)mem)[size / 4]));
+ *allnextp = NULL;
+
+ pr_debug(" <- unflatten_device_tree()\n");
+}
+
+static void *kernel_tree_alloc(u64 size, u64 align)
+{
+ return kzalloc(size, GFP_KERNEL);
+}
+
+/**
+ * of_fdt_unflatten_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens the device-tree passed by the firmware, creating the
+ * tree of struct device_node. It also fills the "name" and "type"
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ */
+void of_fdt_unflatten_tree(unsigned long *blob,
+ struct device_node **mynodes)
+{
+ struct boot_param_header *device_tree =
+ (struct boot_param_header *)blob;
+ __unflatten_device_tree(device_tree, mynodes, &kernel_tree_alloc);
+}
+EXPORT_SYMBOL_GPL(of_fdt_unflatten_tree);
+
/* Everything below here references initial_boot_params directly. */
int __initdata dt_root_addr_cells;
int __initdata dt_root_size_cells;
@@ -569,6 +659,12 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
return 1;
}
+static void *__init early_device_tree_alloc(u64 size, u64 align)
+{
+ unsigned long mem = early_init_dt_alloc_memory_arch(size, align);
+ return __va(mem);
+}
+
/**
* unflatten_device_tree - create tree of device_nodes from flat blob
*
@@ -579,62 +675,13 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
*/
void __init unflatten_device_tree(void)
{
- unsigned long start, mem, size;
- struct device_node **allnextp = &allnodes;
-
- pr_debug(" -> unflatten_device_tree()\n");
-
- if (!initial_boot_params) {
- pr_debug("No device tree pointer\n");
- return;
- }
-
- pr_debug("Unflattening device tree:\n");
- pr_debug("magic: %08x\n", be32_to_cpu(initial_boot_params->magic));
- pr_debug("size: %08x\n", be32_to_cpu(initial_boot_params->totalsize));
- pr_debug("version: %08x\n", be32_to_cpu(initial_boot_params->version));
-
- if (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER) {
- pr_err("Invalid device tree blob header\n");
- return;
- }
-
- /* First pass, scan for size */
- start = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_struct);
- size = unflatten_dt_node(initial_boot_params, 0, &start,
- NULL, NULL, 0);
- size = (size | 3) + 1;
-
- pr_debug(" size is %lx, allocating...\n", size);
-
- /* Allocate memory for the expanded device tree */
- mem = early_init_dt_alloc_memory_arch(size + 4,
- __alignof__(struct device_node));
- mem = (unsigned long) __va(mem);
-
- ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
-
- pr_debug(" unflattening %lx...\n", mem);
-
- /* Second pass, do actual unflattening */
- start = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_struct);
- unflatten_dt_node(initial_boot_params, mem, &start,
- NULL, &allnextp, 0);
- if (be32_to_cpup((__be32 *)start) != OF_DT_END)
- pr_warning("Weird tag at end of tree: %08x\n", *((u32 *)start));
- if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
- pr_warning("End of tree marker overwritten: %08x\n",
- be32_to_cpu(((__be32 *)mem)[size / 4]));
- *allnextp = NULL;
+ __unflatten_device_tree(initial_boot_params, &allnodes,
+ early_device_tree_alloc);
/* Get pointer to OF "/chosen" node for use everywhere */
of_chosen = of_find_node_by_path("/chosen");
if (of_chosen == NULL)
of_chosen = of_find_node_by_path("/chosen@0");
-
- pr_debug(" <- unflatten_device_tree()\n");
}
#endif /* CONFIG_EARLY_FLATTREE */
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 70c5b73..9ce5dfd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -68,6 +68,8 @@ extern void *of_fdt_get_property(struct boot_param_header *blob,
extern int of_fdt_is_compatible(struct boot_param_header *blob,
unsigned long node,
const char *compat);
+extern void of_fdt_unflatten_tree(unsigned long *blob,
+ struct device_node **mynodes);
/* TBD: Temporary export of fdt globals - remove when code fully merged */
extern int __initdata dt_root_addr_cells;
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 4/7] fdt.c: Add non-boottime device tree functions
From: Stephen Neuendorffer @ 2010-11-18 23:54 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-4-git-send-email-stephen.neuendorffer@xilinx.com>
In preparation for providing run-time handling of device trees, factor
out some of the basic functions so that they take an arbitrary blob,
rather than relying on the single boot-time tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
--
V2: functions have of_fdt_* names
removed find_flat_dt_string
blob argument is first
---
drivers/of/fdt.c | 133 ++++++++++++++++++++++++++++-------------------
include/linux/of_fdt.h | 11 ++++
2 files changed, 90 insertions(+), 54 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4d71b29..190e26c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -22,6 +22,82 @@
#include <asm/page.h>
+char *of_fdt_get_string(struct boot_param_header *blob, u32 offset)
+{
+ return ((char *)blob) +
+ be32_to_cpu(blob->off_dt_strings) + offset;
+}
+
+/**
+ * of_fdt_get_property - Given a node in the given flat blob, return
+ * the property ptr
+ */
+void *of_fdt_get_property(struct boot_param_header *blob,
+ unsigned long node, const char *name,
+ unsigned long *size)
+{
+ unsigned long p = node;
+
+ do {
+ u32 tag = be32_to_cpup((__be32 *)p);
+ u32 sz, noff;
+ const char *nstr;
+
+ p += 4;
+ if (tag == OF_DT_NOP)
+ continue;
+ if (tag != OF_DT_PROP)
+ return NULL;
+
+ sz = be32_to_cpup((__be32 *)p);
+ noff = be32_to_cpup((__be32 *)(p + 4));
+ p += 8;
+ if (be32_to_cpu(blob->version) < 0x10)
+ p = ALIGN(p, sz >= 8 ? 8 : 4);
+
+ nstr = of_fdt_get_string(blob, noff);
+ if (nstr == NULL) {
+ pr_warning("Can't find property index name !\n");
+ return NULL;
+ }
+ if (strcmp(name, nstr) == 0) {
+ if (size)
+ *size = sz;
+ return (void *)p;
+ }
+ p += sz;
+ p = ALIGN(p, 4);
+ } while (1);
+}
+
+/**
+ * of_fdt_is_compatible - Return true if given node from the given blob has
+ * compat in its compatible list
+ * @blob: A device tree blob
+ * @node: node to test
+ * @compat: compatible string to compare with compatible list.
+ */
+int of_fdt_is_compatible(struct boot_param_header *blob,
+ unsigned long node, const char *compat)
+{
+ const char *cp;
+ unsigned long cplen, l;
+
+ cp = of_fdt_get_property(blob, node, "compatible", &cplen);
+ if (cp == NULL)
+ return 0;
+ while (cplen > 0) {
+ if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
+ return 1;
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ return 0;
+}
+
+/* Everything below here references initial_boot_params directly. */
int __initdata dt_root_addr_cells;
int __initdata dt_root_size_cells;
@@ -29,12 +105,6 @@ struct boot_param_header *initial_boot_params;
#ifdef CONFIG_EARLY_FLATTREE
-char *find_flat_dt_string(u32 offset)
-{
- return ((char *)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_strings) + offset;
-}
-
/**
* of_scan_flat_dt - scan flattened tree blob and call callback on each.
* @it: callback function
@@ -123,38 +193,7 @@ unsigned long __init of_get_flat_dt_root(void)
void *__init of_get_flat_dt_prop(unsigned long node, const char *name,
unsigned long *size)
{
- unsigned long p = node;
-
- do {
- u32 tag = be32_to_cpup((__be32 *)p);
- u32 sz, noff;
- const char *nstr;
-
- p += 4;
- if (tag == OF_DT_NOP)
- continue;
- if (tag != OF_DT_PROP)
- return NULL;
-
- sz = be32_to_cpup((__be32 *)p);
- noff = be32_to_cpup((__be32 *)(p + 4));
- p += 8;
- if (be32_to_cpu(initial_boot_params->version) < 0x10)
- p = ALIGN(p, sz >= 8 ? 8 : 4);
-
- nstr = find_flat_dt_string(noff);
- if (nstr == NULL) {
- pr_warning("Can't find property index name !\n");
- return NULL;
- }
- if (strcmp(name, nstr) == 0) {
- if (size)
- *size = sz;
- return (void *)p;
- }
- p += sz;
- p = ALIGN(p, 4);
- } while (1);
+ return of_fdt_get_property(initial_boot_params, node, name, size);
}
/**
@@ -164,21 +203,7 @@ void *__init of_get_flat_dt_prop(unsigned long node, const char *name,
*/
int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
{
- const char *cp;
- unsigned long cplen, l;
-
- cp = of_get_flat_dt_prop(node, "compatible", &cplen);
- if (cp == NULL)
- return 0;
- while (cplen > 0) {
- if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
- return 1;
- l = strlen(cp) + 1;
- cp += l;
- cplen -= l;
- }
-
- return 0;
+ return of_fdt_is_compatible(initial_boot_params, node, compat);
}
static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
@@ -303,7 +328,7 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
if (be32_to_cpu(initial_boot_params->version) < 0x10)
*p = ALIGN(*p, sz >= 8 ? 8 : 4);
- pname = find_flat_dt_string(noff);
+ pname = of_fdt_get_string(initial_boot_params, noff);
if (pname == NULL) {
pr_info("Can't find property name in list !\n");
break;
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 7bbf5b3..70c5b73 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -58,6 +58,17 @@ struct boot_param_header {
};
#if defined(CONFIG_OF_FLATTREE)
+
+/* For scanning an arbitrary device-tree at any time */
+extern char *of_fdt_get_string(struct boot_param_header *blob, u32 offset);
+extern void *of_fdt_get_property(struct boot_param_header *blob,
+ unsigned long node,
+ const char *name,
+ unsigned long *size);
+extern int of_fdt_is_compatible(struct boot_param_header *blob,
+ unsigned long node,
+ const char *compat);
+
/* TBD: Temporary export of fdt globals - remove when code fully merged */
extern int __initdata dt_root_addr_cells;
extern int __initdata dt_root_size_cells;
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 5/7] fdt.c: Refactor unflatten_dt_node
From: Stephen Neuendorffer @ 2010-11-18 23:55 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-5-git-send-email-stephen.neuendorffer@xilinx.com>
unflatten_dt_node is a helper function that does most of the work to
convert a device tree blob into tree of device nodes. This code
now uses a passed-in blob instead of using the single boot-time blob,
allowing it to be called in more contexts.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
V2: don't reorder
blob argument first.
---
drivers/of/fdt.c | 27 ++++++++++++++++-----------
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 190e26c..a07fd1a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -206,7 +206,7 @@ int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
return of_fdt_is_compatible(initial_boot_params, node, compat);
}
-static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
+static void *unflatten_dt_alloc(unsigned long *mem, unsigned long size,
unsigned long align)
{
void *res;
@@ -220,16 +220,18 @@ static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
/**
* unflatten_dt_node - Alloc and populate a device_node from the flat tree
+ * @blob: The parent device tree blob
* @p: pointer to node in flat tree
* @dad: Parent struct device_node
* @allnextpp: pointer to ->allnext from last allocated device_node
* @fpsize: Size of the node path up at the current depth.
*/
-unsigned long __init unflatten_dt_node(unsigned long mem,
- unsigned long *p,
- struct device_node *dad,
- struct device_node ***allnextpp,
- unsigned long fpsize)
+unsigned long unflatten_dt_node(struct boot_param_header *blob,
+ unsigned long mem,
+ unsigned long *p,
+ struct device_node *dad,
+ struct device_node ***allnextpp,
+ unsigned long fpsize)
{
struct device_node *np;
struct property *pp, **prev_pp = NULL;
@@ -325,10 +327,10 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
sz = be32_to_cpup((__be32 *)(*p));
noff = be32_to_cpup((__be32 *)((*p) + 4));
*p += 8;
- if (be32_to_cpu(initial_boot_params->version) < 0x10)
+ if (be32_to_cpu(blob->version) < 0x10)
*p = ALIGN(*p, sz >= 8 ? 8 : 4);
- pname = of_fdt_get_string(initial_boot_params, noff);
+ pname = of_fdt_get_string(blob, noff);
if (pname == NULL) {
pr_info("Can't find property name in list !\n");
break;
@@ -407,7 +409,8 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
if (tag == OF_DT_NOP)
*p += 4;
else
- mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
+ mem = unflatten_dt_node(blob, mem, p, np, allnextpp,
+ fpsize);
tag = be32_to_cpup((__be32 *)(*p));
}
if (tag != OF_DT_END_NODE) {
@@ -599,7 +602,8 @@ void __init unflatten_device_tree(void)
/* First pass, scan for size */
start = ((unsigned long)initial_boot_params) +
be32_to_cpu(initial_boot_params->off_dt_struct);
- size = unflatten_dt_node(0, &start, NULL, NULL, 0);
+ size = unflatten_dt_node(initial_boot_params, 0, &start,
+ NULL, NULL, 0);
size = (size | 3) + 1;
pr_debug(" size is %lx, allocating...\n", size);
@@ -616,7 +620,8 @@ void __init unflatten_device_tree(void)
/* Second pass, do actual unflattening */
start = ((unsigned long)initial_boot_params) +
be32_to_cpu(initial_boot_params->off_dt_struct);
- unflatten_dt_node(mem, &start, NULL, &allnextp, 0);
+ unflatten_dt_node(initial_boot_params, mem, &start,
+ NULL, &allnextp, 0);
if (be32_to_cpup((__be32 *)start) != OF_DT_END)
pr_warning("Weird tag at end of tree: %08x\n", *((u32 *)start));
if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 3/7] arch/x86: select OF and OF_FLATTREE
From: Stephen Neuendorffer @ 2010-11-18 23:54 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-3-git-send-email-stephen.neuendorffer@xilinx.com>
Testing patch to verify that the device tree code can be compiled on X86.
---
arch/x86/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cea0cd9..0f2ed5b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -59,6 +59,8 @@ config X86
select ANON_INODES
select HAVE_ARCH_KMEMCHECK
select HAVE_USER_RETURN_NOTIFIER
+ select OF
+ select OF_FLATTREE
config INSTRUCTION_DECODER
def_bool (KPROBES || PERF_EVENTS)
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 6/7] fdt.c: Reorder unflatten_dt_node
From: Stephen Neuendorffer @ 2010-11-18 23:55 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-6-git-send-email-stephen.neuendorffer@xilinx.com>
Move unflatten_dt_node to be grouped with non-__init functions.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
drivers/of/fdt.c | 218 +++++++++++++++++++++++++++---------------------------
1 files changed, 109 insertions(+), 109 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a07fd1a..236a8c9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -97,115 +97,6 @@ int of_fdt_is_compatible(struct boot_param_header *blob,
return 0;
}
-/* Everything below here references initial_boot_params directly. */
-int __initdata dt_root_addr_cells;
-int __initdata dt_root_size_cells;
-
-struct boot_param_header *initial_boot_params;
-
-#ifdef CONFIG_EARLY_FLATTREE
-
-/**
- * of_scan_flat_dt - scan flattened tree blob and call callback on each.
- * @it: callback function
- * @data: context data pointer
- *
- * This function is used to scan the flattened device-tree, it is
- * used to extract the memory information at boot before we can
- * unflatten the tree
- */
-int __init of_scan_flat_dt(int (*it)(unsigned long node,
- const char *uname, int depth,
- void *data),
- void *data)
-{
- unsigned long p = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_struct);
- int rc = 0;
- int depth = -1;
-
- do {
- u32 tag = be32_to_cpup((__be32 *)p);
- char *pathp;
-
- p += 4;
- if (tag == OF_DT_END_NODE) {
- depth--;
- continue;
- }
- if (tag == OF_DT_NOP)
- continue;
- if (tag == OF_DT_END)
- break;
- if (tag == OF_DT_PROP) {
- u32 sz = be32_to_cpup((__be32 *)p);
- p += 8;
- if (be32_to_cpu(initial_boot_params->version) < 0x10)
- p = ALIGN(p, sz >= 8 ? 8 : 4);
- p += sz;
- p = ALIGN(p, 4);
- continue;
- }
- if (tag != OF_DT_BEGIN_NODE) {
- pr_err("Invalid tag %x in flat device tree!\n", tag);
- return -EINVAL;
- }
- depth++;
- pathp = (char *)p;
- p = ALIGN(p + strlen(pathp) + 1, 4);
- if ((*pathp) == '/') {
- char *lp, *np;
- for (lp = NULL, np = pathp; *np; np++)
- if ((*np) == '/')
- lp = np+1;
- if (lp != NULL)
- pathp = lp;
- }
- rc = it(p, pathp, depth, data);
- if (rc != 0)
- break;
- } while (1);
-
- return rc;
-}
-
-/**
- * of_get_flat_dt_root - find the root node in the flat blob
- */
-unsigned long __init of_get_flat_dt_root(void)
-{
- unsigned long p = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_struct);
-
- while (be32_to_cpup((__be32 *)p) == OF_DT_NOP)
- p += 4;
- BUG_ON(be32_to_cpup((__be32 *)p) != OF_DT_BEGIN_NODE);
- p += 4;
- return ALIGN(p + strlen((char *)p) + 1, 4);
-}
-
-/**
- * of_get_flat_dt_prop - Given a node in the flat blob, return the property ptr
- *
- * This function can be used within scan_flattened_dt callback to get
- * access to properties
- */
-void *__init of_get_flat_dt_prop(unsigned long node, const char *name,
- unsigned long *size)
-{
- return of_fdt_get_property(initial_boot_params, node, name, size);
-}
-
-/**
- * of_flat_dt_is_compatible - Return true if given node has compat in compatible list
- * @node: node to test
- * @compat: compatible string to compare with compatible list.
- */
-int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
-{
- return of_fdt_is_compatible(initial_boot_params, node, compat);
-}
-
static void *unflatten_dt_alloc(unsigned long *mem, unsigned long size,
unsigned long align)
{
@@ -421,6 +312,115 @@ unsigned long unflatten_dt_node(struct boot_param_header *blob,
return mem;
}
+/* Everything below here references initial_boot_params directly. */
+int __initdata dt_root_addr_cells;
+int __initdata dt_root_size_cells;
+
+struct boot_param_header *initial_boot_params;
+
+#ifdef CONFIG_EARLY_FLATTREE
+
+/**
+ * of_scan_flat_dt - scan flattened tree blob and call callback on each.
+ * @it: callback function
+ * @data: context data pointer
+ *
+ * This function is used to scan the flattened device-tree, it is
+ * used to extract the memory information at boot before we can
+ * unflatten the tree
+ */
+int __init of_scan_flat_dt(int (*it)(unsigned long node,
+ const char *uname, int depth,
+ void *data),
+ void *data)
+{
+ unsigned long p = ((unsigned long)initial_boot_params) +
+ be32_to_cpu(initial_boot_params->off_dt_struct);
+ int rc = 0;
+ int depth = -1;
+
+ do {
+ u32 tag = be32_to_cpup((__be32 *)p);
+ char *pathp;
+
+ p += 4;
+ if (tag == OF_DT_END_NODE) {
+ depth--;
+ continue;
+ }
+ if (tag == OF_DT_NOP)
+ continue;
+ if (tag == OF_DT_END)
+ break;
+ if (tag == OF_DT_PROP) {
+ u32 sz = be32_to_cpup((__be32 *)p);
+ p += 8;
+ if (be32_to_cpu(initial_boot_params->version) < 0x10)
+ p = ALIGN(p, sz >= 8 ? 8 : 4);
+ p += sz;
+ p = ALIGN(p, 4);
+ continue;
+ }
+ if (tag != OF_DT_BEGIN_NODE) {
+ pr_err("Invalid tag %x in flat device tree!\n", tag);
+ return -EINVAL;
+ }
+ depth++;
+ pathp = (char *)p;
+ p = ALIGN(p + strlen(pathp) + 1, 4);
+ if ((*pathp) == '/') {
+ char *lp, *np;
+ for (lp = NULL, np = pathp; *np; np++)
+ if ((*np) == '/')
+ lp = np+1;
+ if (lp != NULL)
+ pathp = lp;
+ }
+ rc = it(p, pathp, depth, data);
+ if (rc != 0)
+ break;
+ } while (1);
+
+ return rc;
+}
+
+/**
+ * of_get_flat_dt_root - find the root node in the flat blob
+ */
+unsigned long __init of_get_flat_dt_root(void)
+{
+ unsigned long p = ((unsigned long)initial_boot_params) +
+ be32_to_cpu(initial_boot_params->off_dt_struct);
+
+ while (be32_to_cpup((__be32 *)p) == OF_DT_NOP)
+ p += 4;
+ BUG_ON(be32_to_cpup((__be32 *)p) != OF_DT_BEGIN_NODE);
+ p += 4;
+ return ALIGN(p + strlen((char *)p) + 1, 4);
+}
+
+/**
+ * of_get_flat_dt_prop - Given a node in the flat blob, return the property ptr
+ *
+ * This function can be used within scan_flattened_dt callback to get
+ * access to properties
+ */
+void *__init of_get_flat_dt_prop(unsigned long node, const char *name,
+ unsigned long *size)
+{
+ return of_fdt_get_property(initial_boot_params, node, name, size);
+}
+
+/**
+ * of_flat_dt_is_compatible - Return true if given node has compat in compatible list
+ * @node: node to test
+ * @compat: compatible string to compare with compatible list.
+ */
+int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
+{
+ return of_fdt_is_compatible(initial_boot_params, node, compat);
+}
+
#ifdef CONFIG_BLK_DEV_INITRD
/**
* early_init_dt_check_for_initrd - Decode initrd location from flat tree
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH] powerpc: remove second definition of STACK_FRAME_OVERHEAD
From: Stephen Rothwell @ 2010-11-19 1:06 UTC (permalink / raw)
To: ppc-dev, Benjamin Herrenschmidt
Cc: H. Peter Anvin, Jan Beulich, Arnaud Lacombe
Since STACK_FRAME_OVERHEAD is defined in asm/ptrace.h and that
is ASSEMBER safe, we can just include that instead of going via
asm-offsets.h.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/asm-offsets.c | 1 -
arch/powerpc/kernel/entry_32.S | 1 +
arch/powerpc/kernel/exceptions-64s.S | 1 +
arch/powerpc/kernel/fpu.S | 1 +
arch/powerpc/kernel/head_40x.S | 1 +
arch/powerpc/kernel/head_44x.S | 1 +
arch/powerpc/kernel/head_64.S | 1 +
arch/powerpc/kernel/head_8xx.S | 1 +
arch/powerpc/kernel/head_fsl_booke.S | 1 +
arch/powerpc/kernel/misc_32.S | 1 +
arch/powerpc/kernel/misc_64.S | 1 +
arch/powerpc/kernel/ppc_save_regs.S | 1 +
arch/powerpc/kernel/vector.S | 1 +
arch/powerpc/platforms/pseries/hvCall.S | 1 +
14 files changed, 13 insertions(+), 1 deletions(-)
This was prompted by another change that caused the multiple definitions
to produce a warning. That warning has already been fixe, but this seems
the correct thing to do anyway.
I have build tested this for all the (top level) powerpc defconfigs.
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index bd0df2e..23e6a93 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -209,7 +209,6 @@ int main(void)
DEFINE(RTASENTRY, offsetof(struct rtas_t, entry));
/* Interrupt register frame */
- DEFINE(STACK_FRAME_OVERHEAD, STACK_FRAME_OVERHEAD);
DEFINE(INT_FRAME_SIZE, STACK_INT_FRAME_SIZE);
DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs));
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ed4aeb9..c22dc1e 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -31,6 +31,7 @@
#include <asm/asm-offsets.h>
#include <asm/unistd.h>
#include <asm/ftrace.h>
+#include <asm/ptrace.h>
#undef SHOW_SYSCALLS
#undef SHOW_SYSCALLS_TASK
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 9f8b01d..8a81799 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -13,6 +13,7 @@
*/
#include <asm/exception-64s.h>
+#include <asm/ptrace.h>
/*
* We layout physical memory as follows:
diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index e86c040..de36955 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -23,6 +23,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
#ifdef CONFIG_VSX
#define REST_32FPVSRS(n,c,base) \
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 8278e8b..9dd21a8 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -40,6 +40,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
/* As with the other PowerPC ports, it is expected that when code
* execution begins here, the following registers contain valid, yet
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 562305b..cbb3436 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -37,6 +37,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
#include <asm/synch.h>
#include "head_booke.h"
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index f0dd577..ce41b97 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -38,6 +38,7 @@
#include <asm/page_64.h>
#include <asm/irqflags.h>
#include <asm/kvm_book3s_asm.h>
+#include <asm/ptrace.h>
/* The physical memory is layed out such that the secondary processor
* spin code sits at 0x0000...0x00ff. On server, the vectors follow
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 1f1a04b..1cbf64e 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -29,6 +29,7 @@
#include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
/* Macro to make the code more readable. */
#ifdef CONFIG_8xx_CPU6
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 529b817..3e02710 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -41,6 +41,7 @@
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/cache.h>
+#include <asm/ptrace.h>
#include "head_booke.h"
/* As with the other PowerPC ports, it is expected that when code
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index a7a570d..094bd98 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -30,6 +30,7 @@
#include <asm/processor.h>
#include <asm/kexec.h>
#include <asm/bug.h>
+#include <asm/ptrace.h>
.text
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index e514490..206a321 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -25,6 +25,7 @@
#include <asm/cputable.h>
#include <asm/thread_info.h>
#include <asm/kexec.h>
+#include <asm/ptrace.h>
.text
diff --git a/arch/powerpc/kernel/ppc_save_regs.S b/arch/powerpc/kernel/ppc_save_regs.S
index 5113bd2..e83ba3f 100644
--- a/arch/powerpc/kernel/ppc_save_regs.S
+++ b/arch/powerpc/kernel/ppc_save_regs.S
@@ -11,6 +11,7 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
/*
* Grab the register values as they are now.
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index fe46048..9de6f39 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -5,6 +5,7 @@
#include <asm/cputable.h>
#include <asm/thread_info.h>
#include <asm/page.h>
+#include <asm/ptrace.h>
/*
* load_up_altivec(unused, unused, tsk)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
index 48d2057..fd05fde 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -11,6 +11,7 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
+#include <asm/ptrace.h>
#define STK_PARM(i) (48 + ((i)-3)*8)
--
1.7.2.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: manual merge of the bkl-config tree with Linus' tree
From: Stephen Rothwell @ 2010-11-19 2:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, linux-next, Paul Mackerras, linuxppc-dev,
Alessio Igor Bogani
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
Hi Arnd,
Today's linux-next merge of the bkl-config tree got a conflict in
arch/powerpc/kernel/setup_64.c between commit
0f6b77ca12bea571e0a97b0588f62aa5f6012d61 ("powerpc: Update a BKL related
comment") from Linus' tree and commit
bb2d384ab8184eb7f7146897e47fa5b38583112c ("BKL: remove references to
lock_kernel from comments") from the bkl-config tree.
I just used the former version.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Ellerman @ 2010-11-19 5:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev list
In-Reply-To: <20101119163104.624d264d.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > I vote for:
> >
> > -> Exception: 401 (Instruction Access) at 00000000f7937794
>
> Or:
>
> ☛ Exception: 401 (Instruction Access) at 00000000f7937794
Let's get serious, it's _really_ like a phone call:
☎ Exception: 401 (Instruction Access) at 00000000f7937794
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Neuling @ 2010-11-19 6:02 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, linuxppc-dev list
In-Reply-To: <1290145458.2867.3.camel@concordia>
> On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.id.=
> au> wrote:
> > >
> > > I vote for:
> > >=20
> > > -> Exception: 401 (Instruction Access) at 00000000f7937794
> >=20
> > Or:
> >=20
> > =E2=98=9B Exception: 401 (Instruction Access) at 00000000f7937794
>
> Let's get serious, it's _really_ like a phone call:
>
> =E2=98=8E Exception: 401 (Instruction Access) at 00000000f7937794
We need a dedicated NACK char!
Mikey
^ permalink raw reply
* Change in PCI behaviour
From: Gary Thomas @ 2010-11-19 15:42 UTC (permalink / raw)
To: Linux PPC Development
I'm upgrading from 2.6.28 to 2.6.32 (yes, I know it's not the latest,
but it's the best I can do at the moment). There seems to have been
a change in how the PCI bus is scanned/assigned which is causing me
some hardware problems. My hardware is FSL MPC8347 and the problem
is likely specific to the FSL PCI code.
My system has 256MB RAM, fully mapped into the PCI export window.
There are an additional 2 devices on the PCI bus. On 2.6.28, I
get this layout:
PCI: Probing PCI hardware
pci 0000:00:00.0: reg 10 32bit mmio: [0x000000-0x0fffff]
pci 0000:00:00.0: reg 18 64bit mmio: [0x000000-0xfffffff]
pci 0000:00:0b.0: reg 10 io port: [0x1000-0x1007]
pci 0000:00:0b.0: reg 14 io port: [0x1008-0x100b]
pci 0000:00:0b.0: reg 18 io port: [0x1010-0x1017]
pci 0000:00:0b.0: reg 1c io port: [0x1018-0x101b]
pci 0000:00:0b.0: reg 20 io port: [0x1020-0x102f]
pci 0000:00:0b.0: reg 24 32bit mmio: [0x100000-0x1001ff]
pci 0000:00:0b.0: reg 30 32bit mmio: [0x000000-0x07ffff]
pci 0000:00:0b.0: supports D1 D2
pci 0000:00:0c.0: reg 10 32bit mmio: [0x4000000-0x7ffffff]
PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
bus: 00 index 0 io port: [0x00-0xfffff]
bus: 00 index 1 mmio: [0xc0000000-0xdfffffff]
There are no notices, but the key item is that device 0000:00:0c.0 gets
mapped at PCI address 0xD0000000.
On 2.6.32, I get this:
PCI: Probing PCI hardware
pci 0000:00:0b.0: reg 10: [io 0x1000-0x1007]
pci 0000:00:0b.0: reg 14: [io 0x1008-0x100b]
pci 0000:00:0b.0: reg 18: [io 0x1010-0x1017]
pci 0000:00:0b.0: reg 1c: [io 0x1018-0x101b]
pci 0000:00:0b.0: reg 20: [io 0x1020-0x102f]
pci 0000:00:0b.0: reg 24: [mem 0x00100000-0x001001ff]
pci 0000:00:0b.0: reg 30: [mem 0x00000000-0x0007ffff pref]
pci 0000:00:0b.0: supports D1 D2
pci 0000:00:0c.0: reg 10: [mem 0x04000000-0x07ffffff]
PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
pci 0000:00:0c.0: BAR 0: assigned [mem 0xc0000000-0xc3ffffff]
pci 0000:00:0c.0: BAR 0: set to [mem 0xc0000000-0xc3ffffff] (PCI address [0xc0000000-0xc3ffffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xc4000000-0xc407ffff pref]
pci 0000:00:0b.0: BAR 5: assigned [mem 0xc4080000-0xc40801ff]
pci 0000:00:0b.0: BAR 5: set to [mem 0xc4080000-0xc40801ff] (PCI address [0xc4080000-0xc40801ff]
pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
pci_bus 0000:00: resource 1 [mem 0xc0000000-0xdfffffff]
In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
This causes problems because it's a truly stupid device that does
not work properly at PCI [relative] address 0x00000000. It simply
does not respond at that address. Pick anywhere else and it will
work fine!
On 2.6.28, I get this layout:
# ls -l /sys/bus/pci/devices
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:00.0 -> ../../../devices/pci0000:00/0000:00:00.0
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0b.0 -> ../../../devices/pci0000:00/0000:00:0b.0
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0c.0 -> ../../../devices/pci0000:00/0000:00:0c.0
# cat /sys/bus/pci/devices/0000\:00\:0c.0/resource
0x00000000d0000000 0x00000000d3ffffff 0x0000000000020200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
On 2.6.32, the final layout looks like this:
# ls -l /sys/bus/pci/devices/
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0b.0 -> ../../../devices/pci0000:00/0000:00:0b.0
lrwxrwxrwx 1 root root 0 Jan 1 1970 0000:00:0c.0 -> ../../../devices/pci0000:00/0000:00:0c.0
# cat /sys/bus/pci/devices/0000\:00\:0c.0/resource
0x00000000c0000000 0x00000000c3ffffff 0x0000000000020200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
Bottom line: how can I get this behaviour back (so as to get my
stupid graphics controller working again)??
Thanks for any ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Change in PCI behaviour
From: Benjamin Herrenschmidt @ 2010-11-19 21:46 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CE69AF6.6090408@mlbassoc.com>
On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
> This causes problems because it's a truly stupid device that does
> not work properly at PCI [relative] address 0x00000000. It simply
> does not respond at that address. Pick anywhere else and it will
> work fine!
Hrm, we used to have a trick avoid giving out the first meg of a bus to
avoid that sort of thing, I suppose it got lost. The rest is related to
the way you map your PCI I suppose in your dts. You can switch back to a
1:1 instead of 1:0 mapping I suppose.
One way to achieve the above result would be to, in your platform code,
reserve the mem region that corresponds to PCI 0...1M (c0000000...+1M)
before the device resources are assigned/allocated.
I though we had code to do that with the "legacy" regions somewhere...
oh well, no code at hand to check right now.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Stijn Devriendt @ 2010-11-20 10:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1289995250-17927-2-git-send-email-w.sang@pengutronix.de>
Hi Wolfram,
I'm surprised that this would work. I've patched the at24 driver as well
to use OF data, but took a different approach.
As far as I could tell, using compatible = <24c64>; didn't load the right
module
(module name is at24) and using at24 caused a device id mismatch because
at24 is not a known device ID. I could be wrong here and if so, I'd very
much
like a source code hint as to why...
My patch worked by changing drivers/of/of_i2c.c to allow a generic
kind = " " statement that was filled in as i2c_board_info.type, to allow
the module name and the device id to be different.
This makes the at24 driver no longer rely on probing (which it claims
is buggy anyway) and also benefits other drivers that support multiple
devices, but where probing is difficult (e.g. lm90 driver).
I'm in the process of getting employer approval to get these patches
upstream.
Regards,
Stijn
-----Oorspronkelijk bericht-----
From: Wolfram Sang
Sent: Wednesday, November 17, 2010 1:00 PM
To: devicetree-discuss@ozlabs.org
Cc: linuxppc-dev@ozlabs.org
Subject: [PATCH 1/3] misc: at24: parse OF-data, too
Information about the pagesize and read-only-status may also come from
the devicetree. Parse this data, too, and act accordingly. While we are
here, change the initialization printout a bit. write_max is useful to
know to detect performance bottlenecks, the rest is superfluous.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
Changes since last version:
- use __be32 instead of u32
Documentation/powerpc/dts-bindings/eeprom.txt | 28 +++++++++++++++++++++
drivers/misc/eeprom/at24.c | 33
++++++++++++++++++++----
2 files changed, 55 insertions(+), 6 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/eeprom.txt
diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt
b/Documentation/powerpc/dts-bindings/eeprom.txt
new file mode 100644
index 0000000..4342c10
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/eeprom.txt
@@ -0,0 +1,28 @@
+EEPROMs (I2C)
+
+Required properties:
+
+ - compatible : should be "<manufacturer>,<type>"
+ If there is no specific driver for <manufacturer>, a generic
+ driver based on <type> is selected. Possible types are:
+ 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
+ 24c128, 24c256, 24c512, 24c1024, spd
+
+ - reg : the I2C address of the EEPROM
+
+Optional properties:
+
+ - pagesize : the length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong
value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
+
+ - read-only: this parameterless property disables writes to the eeprom
+
+Example:
+
+eeprom@52 {
+ compatible = "atmel,24c32";
+ reg = <0x52>;
+ pagesize = <32>;
+};
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 559b0b3..3a53efc 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -20,6 +20,7 @@
#include <linux/log2.h>
#include <linux/bitops.h>
#include <linux/jiffies.h>
+#include <linux/of.h>
#include <linux/i2c.h>
#include <linux/i2c/at24.h>
@@ -457,6 +458,27 @@ static ssize_t at24_macc_write(struct memory_accessor
*macc, const char *buf,
/*-------------------------------------------------------------------------*/
+#ifdef CONFIG_OF
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{
+ const __be32 *val;
+ struct device_node *node = client->dev.of_node;
+
+ if (node) {
+ if (of_get_property(node, "read-only", NULL))
+ chip->flags |= AT24_FLAG_READONLY;
+ val = of_get_property(node, "pagesize", NULL);
+ if (val)
+ chip->page_size = be32_to_cpup(val);
+ }
+}
+#else
+static void at24_get_ofdata(struct i2c_client *client,
+ struct at24_platform_data *chip)
+{ }
+#endif /* CONFIG_OF */
+
static int at24_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct at24_platform_data chip;
@@ -485,6 +507,9 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
*/
chip.page_size = 1;
+ /* update chipdata if OF is present */
+ at24_get_ofdata(client, &chip);
+
chip.setup = NULL;
chip.context = NULL;
}
@@ -597,19 +622,15 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
i2c_set_clientdata(client, at24);
- dev_info(&client->dev, "%zu byte %s EEPROM %s\n",
+ dev_info(&client->dev, "%zu byte %s EEPROM, %s, %u bytes/write\n",
at24->bin.size, client->name,
- writable ? "(writable)" : "(read-only)");
+ writable ? "writable" : "read-only", at24->write_max);
if (use_smbus == I2C_SMBUS_WORD_DATA ||
use_smbus == I2C_SMBUS_BYTE_DATA) {
dev_notice(&client->dev, "Falling back to %s reads, "
"performance will suffer\n", use_smbus ==
I2C_SMBUS_WORD_DATA ? "word" : "byte");
}
- dev_dbg(&client->dev,
- "page_size %d, num_addresses %d, write_max %d, use_smbus %d\n",
- chip.page_size, num_addresses,
- at24->write_max, use_smbus);
/* export data to kernel code */
if (chip.setup)
--
1.7.2.3
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Wolfram Sang @ 2010-11-20 12:42 UTC (permalink / raw)
To: Stijn Devriendt; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <5F1D4949966C4C509360407B0F948EFE@HIGHGuY>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
Hi,
> As far as I could tell, using compatible = <24c64>; didn't load the right
> module (module name is at24) and using at24 caused a device id mismatch
> because at24 is not a known device ID. I could be wrong here and if so, I'd
> very much like a source code hint as to why...
Have you tried "<vendor>, 24c64"? All I can say is that it works for me. Plain
at24 worked for years with pcm030.dts and pcm032.dts, so I don't know which
issue you are facing. This patch is just about extending the support.
> My patch worked by changing drivers/of/of_i2c.c to allow a generic
> kind = " " statement that was filled in as i2c_board_info.type, to allow
> the module name and the device id to be different.
> This makes the at24 driver no longer rely on probing (which it claims
> is buggy anyway) and also benefits other drivers that support multiple
> devices, but where probing is difficult (e.g. lm90 driver).
>
> I'm in the process of getting employer approval to get these patches
> upstream.
I hope you will get it approved, it is a lot easier to talk about code :)
Best regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Stijn Devriendt @ 2010-11-20 14:07 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20101120124226.GB11936@pengutronix.de>
On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hi,
>
>> As far as I could tell, using compatible =3D <24c64>; didn't load the ri=
ght
>> module (module name is at24) and using at24 caused a device id mismatch
>> because at24 is not a known device ID. I could be wrong here and if so, =
I'd
>> very =A0much like a source code hint as to why...
>
> Have you tried "<vendor>, 24c64"? All I can say is that it works for me. =
Plain
> at24 worked for years with pcm030.dts and pcm032.dts, so I don't know whi=
ch
> issue you are facing. This patch is just about extending the support.
According to of_modalias_node, the prefix is stripped anyway, so that
wouldn't help.
The code probably worked using the buggy probing...
>
>> My patch worked by changing drivers/of/of_i2c.c to allow a generic
>> kind =3D " " statement that was filled in as i2c_board_info.type, to all=
ow
>> the module name and the device id to be different.
>> This makes the at24 driver no longer rely on probing (which it claims
>> is buggy anyway) and also benefits other drivers that support multiple
>> devices, but where probing is difficult (e.g. lm90 driver).
>>
>> I'm in the process of getting employer approval to get these patches
>> upstream.
>
It'll get approved ;) It's the first time I'm taking these steps, but
the procedures
are there, so at most it'll take some extra time.
> I hope you will get it approved, it is a lot easier to talk about code :)
>
> Best regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL
> N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1
> =3DtyTb
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gary Thomas @ 2010-11-21 17:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <1290203218.32570.48.camel@pasglop>
On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
>> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
>> This causes problems because it's a truly stupid device that does
>> not work properly at PCI [relative] address 0x00000000. It simply
>> does not respond at that address. Pick anywhere else and it will
>> work fine!
>
> Hrm, we used to have a trick avoid giving out the first meg of a bus to
> avoid that sort of thing, I suppose it got lost. The rest is related to
> the way you map your PCI I suppose in your dts. You can switch back to a
> 1:1 instead of 1:0 mapping I suppose.
>
> One way to achieve the above result would be to, in your platform code,
> reserve the mem region that corresponds to PCI 0...1M (c0000000...+1M)
> before the device resources are assigned/allocated.
>
> I though we had code to do that with the "legacy" regions somewhere...
> oh well, no code at hand to check right now.
Thanks, I found a combo of regions in my DTS that fixed this.
That went well and the system is now running, but it's not stable :-(
It will crash randomly, generally leaving no trace of what went wrong.
I've attached a BDI to it, but mostly all it can tell me is "it's dead"
The one thing that seems to pop up is it looks like it's jumping into
space (aka the wrong place) when doing rfi (this is a guess). I've
seen things like the MSR ends up loaded with an address, or similar
strangeness.
Were there any system level changes during this period (I know it's
some time ago) that might have introduced such an instability? It's
tough to scan through the diffs and get a feeling for any little details
like this.
Any ideas or hints greatly appreciated, thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Ellerman @ 2010-11-21 23:05 UTC (permalink / raw)
To: Michael Neuling; +Cc: Stephen Rothwell, linuxppc-dev list
In-Reply-To: <30421.1290146540@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote:
> > On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.id.=
> > au> wrote:
> > > >
> > > > I vote for:
> > > >=20
> > > > -> Exception: 401 (Instruction Access) at 00000000f7937794
> > >=20
> > > Or:
> > >=20
> > > =E2=98=9B Exception: 401 (Instruction Access) at 00000000f7937794
> >
> > Let's get serious, it's _really_ like a phone call:
> >
> > =E2=98=8E Exception: 401 (Instruction Access) at 00000000f7937794
>
> We need a dedicated NACK char!
␕!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gary Thomas @ 2010-11-22 10:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <4CE95E11.1050606@mlbassoc.com>
On 11/21/2010 10:59 AM, Gary Thomas wrote:
> On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote:
>>> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
>>> This causes problems because it's a truly stupid device that does
>>> not work properly at PCI [relative] address 0x00000000. It simply
>>> does not respond at that address. Pick anywhere else and it will
>>> work fine!
>>
>> Hrm, we used to have a trick avoid giving out the first meg of a bus to
>> avoid that sort of thing, I suppose it got lost. The rest is related to
>> the way you map your PCI I suppose in your dts. You can switch back to a
>> 1:1 instead of 1:0 mapping I suppose.
>>
>> One way to achieve the above result would be to, in your platform code,
>> reserve the mem region that corresponds to PCI 0...1M (c0000000...+1M)
>> before the device resources are assigned/allocated.
>>
>> I though we had code to do that with the "legacy" regions somewhere...
>> oh well, no code at hand to check right now.
>
> Thanks, I found a combo of regions in my DTS that fixed this.
>
> That went well and the system is now running, but it's not stable :-(
> It will crash randomly, generally leaving no trace of what went wrong.
> I've attached a BDI to it, but mostly all it can tell me is "it's dead"
> The one thing that seems to pop up is it looks like it's jumping into
> space (aka the wrong place) when doing rfi (this is a guess). I've
> seen things like the MSR ends up loaded with an address, or similar
> strangeness.
>
> Were there any system level changes during this period (I know it's
> some time ago) that might have introduced such an instability? It's
> tough to scan through the diffs and get a feeling for any little details
> like this.
>
> Any ideas or hints greatly appreciated, thanks
>
I have a bit more information on this. I'm pretty sure that the failures
are only happening in my SCSI (SATA actually) code. My board (8347ea) has
a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28.
In 2.6.32, it will run for a while (possibly quite a while), then timeout
trying to do a large block write - typically 256 blocks. Once this timeout
happens, the SIL controller is stuck and accesses to it will eventually
cause the whole system to hang (as above).
Was there any major change in how PCI or DMA was handled between 2.6.28
and 2.6.32? Given the ephemeral nature of these failures (multiple runs
all eventually fail, but never the same twice), my only hope of fixing it
will be to have some ideas what might have changed.
Thanks for any ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Change in PCI behaviour
From: Gabriel Paubert @ 2010-11-22 10:37 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CE69AF6.6090408@mlbassoc.com>
On Fri, Nov 19, 2010 at 08:42:46AM -0700, Gary Thomas wrote:
> In this case, note that PCI device 0000:00:0c.0 is at 0xc0000000.
> This causes problems because it's a truly stupid device that does
> not work properly at PCI [relative] address 0x00000000. It simply
> does not respond at that address. Pick anywhere else and it will
> work fine!
Yes, but it was one upon a time in the PCI spec that setting the
a base register to 0 should disable the corresponding decoder.
I don't know whether this has changed (I actually never had the
final PCI spec, only drafts). However I once had a device who
actually did not disable base addresses set to zero and this was
described as a bug in its (numerous) errata. This also caused
a lot of mayhem since in some versions/configurations it used
up to 64kB of PCI I/O space (especially fun on x86...).
Gabriel
^ permalink raw reply
* [PATCHv4] Xilinx Virtex 4 FX Soft FPU support
From: Sergey Temerkhanov @ 2010-11-22 10:50 UTC (permalink / raw)
To: linuxppc-dev
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.> This patch
enables support for Xilinx Virtex 4 FX singe-float FPU.
Changelog v3-v4
-Added help for CONFIG_XILINX_SOFTFPU option
-Made kernel math emulation dependent on !PPC_FPU.
Changelog v2-v3:
-Fixed whitespaces for SAVE_FPR/REST_FPR.
-Changed description of MSR_AP bit.
-Removed the stub for APU unavailable exception.
Changelog v1->v2:
-Added MSR_AP bit definition
-Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
'Platform support' and made it Virtex4-FX-only.
-Changed SAVE_FPR/REST_FPR definition style.
Caveats:
- Hard-float binaries which rely on in-kernel math emulation will
give wrong results since they expect 64-bit double-precision instead
of 32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.
Signed-off-by: Sergey Temerkhanov<temerkhanov@cifronik.ru>
diff -r df25ff2b70a4 arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/Kconfig Fri Sep 10 13:08:13 2010 +0400
@@ -293,7 +293,7 @@
config MATH_EMULATION
bool "Math emulation"
- depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
+ depends on (4xx || 8xx || E200 || PPC_MPC832x || E500) && !PPC_FPU
---help---
Some PowerPC chips designed for embedded applications do not have
a floating-point unit and therefore do not implement the
diff -r df25ff2b70a4 arch/powerpc/include/asm/ppc_asm.h
--- a/arch/powerpc/include/asm/ppc_asm.h Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/include/asm/ppc_asm.h Fri Sep 10 13:08:13 2010 +0400
@@ -85,13 +85,21 @@
#define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base)
#define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base)
-#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
+#ifdef CONFIG_XILINX_SOFTFPU
+#define SAVE_FPR(n, base) stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#else
+#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#endif
+
#define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base)
#define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
#define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
#define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
#define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
-#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
#define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base)
#define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base)
#define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base)
diff -r df25ff2b70a4 arch/powerpc/include/asm/reg.h
--- a/arch/powerpc/include/asm/reg.h Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/include/asm/reg.h Fri Sep 10 13:08:13 2010 +0400
@@ -30,6 +30,7 @@
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
#define MSR_VEC_LG 25 /* Enable AltiVec */
+#define MSR_AP_LG 25 /* Enable APU */
#define MSR_VSX_LG 23 /* Enable VSX */
#define MSR_POW_LG 18 /* Enable Power Management */
#define MSR_WE_LG 18 /* Wait State Enable */
@@ -71,6 +72,7 @@
#define MSR_HV 0
#endif
+#define MSR_AP __MASK(MSR_AP_LG) /* Enable APU */
#define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */
#define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */
#define MSR_POW __MASK(MSR_POW_LG) /* Enable Power Management */
diff -r df25ff2b70a4 arch/powerpc/kernel/fpu.S
--- a/arch/powerpc/kernel/fpu.S Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/kernel/fpu.S Fri Sep 10 13:08:13 2010 +0400
@@ -57,6 +57,9 @@
_GLOBAL(load_up_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -85,6 +88,9 @@
toreal(r5)
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r10,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r10,r10,MSR_AP@h
+#endif
andc r4,r4,r10 /* disable FP for previous task */
PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
@@ -94,6 +100,9 @@
mfspr r5,SPRN_SPRG_THREAD /* current task's THREAD (phys) */
lwz r4,THREAD_FPEXC_MODE(r5)
ori r9,r9,MSR_FP /* enable FP for current */
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r9,r9,MSR_AP@h
+#endif
or r9,r9,r4
#else
ld r4,PACACURRENT(r13)
@@ -124,6 +133,9 @@
_GLOBAL(giveup_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -145,6 +157,9 @@
beq 1f
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r3,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r3,r3,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r3,r3,MSR_VSX@h
diff -r df25ff2b70a4 arch/powerpc/kernel/head_40x.S
--- a/arch/powerpc/kernel/head_40x.S Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/kernel/head_40x.S Fri Sep 10 13:08:13 2010 +0400
@@ -420,7 +420,19 @@
addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_STD(0x700, program_check_exception)
+/* 0x0800 - FPU unavailable Exception */
+#ifdef CONFIG_PPC_FPU
+ START_EXCEPTION(0x0800, FloatingPointUnavailable)
+ NORMAL_EXCEPTION_PROLOG
+ beq 1f; \
+ bl load_up_fpu; /* if from user, just load it up */ \
+ b fast_exception_return; \
+1: addi r3,r1,STACK_FRAME_OVERHEAD; \
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
+#else
EXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE)
+#endif
+
EXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE)
@@ -432,7 +444,7 @@
EXCEPTION(0x0D00, Trap_0D, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0E00, Trap_0E, unknown_exception, EXC_XFER_EE)
- EXCEPTION(0x0F00, Trap_0F, unknown_exception, EXC_XFER_EE)
+ EXCEPTION(0x0F20, Trap_0F, unknown_exception, EXC_XFER_EE)
/* 0x1000 - Programmable Interval Timer (PIT) Exception */
START_EXCEPTION(0x1000, Decrementer)
@@ -821,8 +833,10 @@
* The PowerPC 4xx family of processors do not have an FPU, so this just
* returns.
*/
+#ifndef CONFIG_PPC_FPU
_ENTRY(giveup_fpu)
blr
+#endif
/* This is where the main kernel code starts.
*/
diff -r df25ff2b70a4 arch/powerpc/platforms/Kconfig
--- a/arch/powerpc/platforms/Kconfig Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/platforms/Kconfig Fri Sep 10 13:08:13 2010 +0400
@@ -338,4 +338,15 @@
bool "Xilinx PCI host bridge support"
depends on PCI && XILINX_VIRTEX
+config XILINX_SOFTFPU
+ bool "Xilinx Soft FPU support"
+ select PPC_FPU
+ depends on XILINX_VIRTEX_4_FX && !PPC40x_SIMPLE && !405GP && !405GPR
+ help
+ Say Y to enable support for Xilinx Virtex 4 FX singe-float FPU.
+ Caveats:
+ - Hard-float binaries which rely on in-kernel math emulation will give
wrong
+ results since they expect 64-bit double-precision instead of 32-bit
+ single-precision numbers which Virtex-4 soft FPU produces.
+
endmenu
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Josh Boyer @ 2010-11-22 11:25 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, Michael Neuling, linuxppc-dev list
In-Reply-To: <1290380744.4961.7.camel@concordia>
On Sun, Nov 21, 2010 at 6:05 PM, Michael Ellerman
<michael@ellerman.id.au> wrote:
> On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote:
>> > On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
>> > > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerma=
n.id.=3D
>> > au> wrote:
>> > > >
>> > > > I vote for:
>> > > >=3D20
>> > > > =C2=A0-> Exception: 401 (Instruction Access) at 00000000f7937794
>> > >=3D20
>> > > Or:
>> > >=3D20
>> > > =3DE2=3D98=3D9B Exception: 401 (Instruction Access) at 00000000f7937=
794
>> >
>> > Let's get serious, it's _really_ like a phone call:
>> >
>> > =3DE2=3D98=3D8E Exception: 401 (Instruction Access) at 00000000f793779=
4
>>
>> We need a dedicated NACK char!
>
> =E2=90=95!
Surely it would be: =E2=98=A3
josh
^ permalink raw reply
* Re: [PATCH 1/3] misc: at24: parse OF-data, too
From: Stijn Devriendt @ 2010-11-22 16:48 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20101120124226.GB11936@pengutronix.de>
Hi Wolfram,
I seem to be mistaken. I retried "compatible=3D<linux,24c64>" and it did
all the right
things. I was mistaken that request_module() only takes the driver
name, at24 in this
case, and not all device names in the table_ids.
This pretty much makes my patch redundant. Thanks for helping me clear
things out.
Regards,
Stijn
On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hi,
>
>> As far as I could tell, using compatible =3D <24c64>; didn't load the ri=
ght
>> module (module name is at24) and using at24 caused a device id mismatch
>> because at24 is not a known device ID. I could be wrong here and if so, =
I'd
>> very =A0much like a source code hint as to why...
>
> Have you tried "<vendor>, 24c64"? All I can say is that it works for me. =
Plain
> at24 worked for years with pcm030.dts and pcm032.dts, so I don't know whi=
ch
> issue you are facing. This patch is just about extending the support.
>
>> My patch worked by changing drivers/of/of_i2c.c to allow a generic
>> kind =3D " " statement that was filled in as i2c_board_info.type, to all=
ow
>> the module name and the device id to be different.
>> This makes the at24 driver no longer rely on probing (which it claims
>> is buggy anyway) and also benefits other drivers that support multiple
>> devices, but where probing is difficult (e.g. lm90 driver).
>>
>> I'm in the process of getting employer approval to get these patches
>> upstream.
>
> I hope you will get it approved, it is a lot easier to talk about code :)
>
> Best regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL
> N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1
> =3DtyTb
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Scott Wood @ 2010-11-22 18:45 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, linuxppc-dev list
In-Reply-To: <1290145458.2867.3.camel@concordia>
On Fri, 19 Nov 2010 16:44:18 +1100
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman <michael@ellerman.i=
d.au> wrote:
> > >
> > > I vote for:
> > >=20
> > > -> Exception: 401 (Instruction Access) at 00000000f7937794
> >=20
> > Or:
> >=20
> > =E2=98=9B Exception: 401 (Instruction Access) at 00000000f7937794
>=20
> Let's get serious, it's _really_ like a phone call:
>=20
> =E2=98=8E Exception: 401 (Instruction Access) at 00000000f7937794
Sparc got it right:
void die_if_kernel(char *str, struct pt_regs *regs)
{
static int die_counter;
int count =3D 0;
=09
/* Amuse the user. */
printk(
" \\|/ ____ \\|/\n"
" \"@'/ .. \\`@\"\n"
" /_| \\__/ |_\\\n"
" \\__U_/\n");
-Scott
^ permalink raw reply
* Re: Change in PCI behaviour
From: Benjamin Herrenschmidt @ 2010-11-22 20:26 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4CEA3F87.9080102@mlbassoc.com>
On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
> I have a bit more information on this. I'm pretty sure that the failures
> are only happening in my SCSI (SATA actually) code. My board (8347ea) has
> a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28.
> In 2.6.32, it will run for a while (possibly quite a while), then timeout
> trying to do a large block write - typically 256 blocks. Once this timeout
> happens, the SIL controller is stuck and accesses to it will eventually
> cause the whole system to hang (as above).
>
> Was there any major change in how PCI or DMA was handled between 2.6.28
> and 2.6.32? Given the ephemeral nature of these failures (multiple runs
> all eventually fail, but never the same twice), my only hope of fixing it
> will be to have some ideas what might have changed.
Maybe the changes you did to the PCI outbound windows are now breaking
DMA ? Make sure the outbound and inbound don't overlap for example and
that all RAM is reachable for inbound.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] MPC5200: Eliminate duplicate include of of_device.h
From: Jesper Juhl @ 2010-11-22 21:54 UTC (permalink / raw)
To: alsa-devel
Cc: Takashi Iwai, Mark Brown, linux-kernel, linuxppc-dev,
Liam Girdwood
Eliminate duplicate #include <linux/of_device.h> from
sound/soc/fsl/mpc5200_dma.c
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
mpc5200_dma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index dce6b55..f92dca0 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -9,7 +9,6 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/slab.h>
-#include <linux/of_device.h>
#include <linux/of_platform.h>
#include <sound/soc.h>
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] powerpc, time: printk time stamp init not correct
From: Heiko Schocher @ 2010-11-23 7:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Heiko Schocher, Wolfgang Denk
problem:
I see sometimes on my mpc5200 based board such printk timing
information:
[ 0.000000] NR_IRQS:512 nr_irqs:512 16
[ 0.000000] MPC52xx PIC is up and running!
[ 0.000000] clocksource: timebase mult[79364d9] shift[22] registered
[ 0.000000] console [ttyPSC0] enabled
[ 130.300633] pid_max: default: 32768 minimum: 301
[ 130.305647] Mount-cache hash table entries: 512
[ 130.315818] NET: Registered protocol family 16
reason:
if the tbu not starts from 0 when linux boots, boot_tb
maybe could not store the real 64 bit tbu value, because
boot_tp is only a 32 bit unsigned long.
solution:
change boot_tb to unsigned long long
Signed-off-by: Heiko Schocher <hs@denx.de>
cc: Wolfgang Denk <wd@denx.de>
---
arch/powerpc/kernel/time.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index fa91732..a66df7d 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -155,7 +155,7 @@ EXPORT_SYMBOL_GPL(rtc_lock);
static u64 tb_to_ns_scale __read_mostly;
static unsigned tb_to_ns_shift __read_mostly;
-static unsigned long boot_tb __read_mostly;
+static unsigned long long boot_tb __read_mostly;
extern struct timezone sys_tz;
static long timezone_offset;
--
1.7.2.3
^ 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