[RFC] [PATCH] Device Tree on ARM platform

[RFC] [PATCH] Device Tree on ARM platform

[Janboe Ye]

Hi, All

Currently, ARM linux uses mach-type to figure out platform. But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals.

The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code.

Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware , for the detail of device tree.

www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf

Signed-off-by: janboe <yuan-bo.ye@motorola.com>

 arch/arm/Kconfig                   |   13 ++
 arch/arm/include/asm/of_device.h   |   32 +++
 arch/arm/include/asm/of_platform.h |   39 ++++
 arch/arm/include/asm/prom.h        |  367 ++++++++++++++++++++++++++++++++
 arch/arm/include/asm/setup.h       |    8 +
 arch/arm/kernel/Makefile           |    1 +
 arch/arm/kernel/prom.c             |  414 ++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c            |    2 +
 drivers/of/Kconfig                 |    2 +-
 9 files changed, 877 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f430e15..b0ee851 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -158,6 +158,17 @@ config ARCH_MTD_XIP
 config GENERIC_HARDIRQS_NO__DO_IRQ
 	def_bool y
 
+config OF
+        def_bool y
+
+config PROC_DEVICETREE
+        bool "Support for device tree in /proc"
+        depends on PROC_FS
+        help
+          This option adds a device-tree directory under /proc which contains
+          an image of the device tree that the kernel copies from Open
+          Firmware or other boot firmware. If unsure, say Y here.
+
 if OPROFILE
 
 config OPROFILE_ARMV6
@@ -1231,6 +1242,8 @@ menu "Device Drivers"
 
 source "drivers/base/Kconfig"
 
+source "drivers/of/Kconfig"
+
 source "drivers/connector/Kconfig"
 
 if ALIGNMENT_TRAP || !CPU_CP15_MMU
diff --git a/arch/arm/include/asm/of_device.h b/arch/arm/include/asm/of_device.h
new file mode 100644
index 0000000..6317713
--- /dev/null
+++ b/arch/arm/include/asm/of_device.h
@@ -0,0 +1,32 @@
+#ifndef _ASM_POWERPC_OF_DEVICE_H
+#define _ASM_POWERPC_OF_DEVICE_H
+#ifdef __KERNEL__
+
+#include <linux/device.h>
+#include <linux/of.h>
+
+/*
+ * The of_device is a kind of "base class" that is a superset of
+ * struct device for use by devices attached to an OF node and
+ * probed using OF properties.
+ */
+struct of_device {
+	struct device_node	*node;		/* to be obsoleted */
+	u64			dma_mask;	/* DMA mask */
+	struct device		dev;		/* Generic device interface */
+};
+
+extern struct of_device *of_device_alloc(struct device_node *np,
+					 const char *bus_id,
+					 struct device *parent);
+
+extern int of_device_uevent(struct device *dev,
+			    struct kobj_uevent_env *env);
+
+static inline int of_node_to_nid(struct device_node *device)
+{
+	return 0;
+}
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_OF_DEVICE_H */
diff --git a/arch/arm/include/asm/of_platform.h b/arch/arm/include/asm/of_platform.h
new file mode 100644
index 0000000..53b4650
--- /dev/null
+++ b/arch/arm/include/asm/of_platform.h
@@ -0,0 +1,39 @@
+#ifndef _ASM_POWERPC_OF_PLATFORM_H
+#define _ASM_POWERPC_OF_PLATFORM_H
+/*
+ *    Copyright (C) 2006 Benjamin Herrenschmidt, IBM Corp.
+ *			 <benh@kernel.crashing.org>
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ *
+ */
+
+/* Platform drivers register/unregister */
+static inline int of_register_platform_driver(struct of_platform_driver *drv)
+{
+	return of_register_driver(drv, &of_platform_bus_type);
+}
+static inline void of_unregister_platform_driver(struct of_platform_driver *drv)
+{
+	of_unregister_driver(drv);
+}
+
+/* Platform devices and busses creation */
+extern struct of_device *of_platform_device_create(struct device_node *np,
+						   const char *bus_id,
+						   struct device *parent);
+/* pseudo "matches" value to not do deep probe */
+#define OF_NO_DEEP_PROBE ((struct of_device_id *)-1)
+
+extern int of_platform_bus_probe(struct device_node *root,
+				 const struct of_device_id *matches,
+				 struct device *parent);
+
+extern struct of_device *of_find_device_by_phandle(phandle ph);
+
+extern void of_instantiate_rtc(void);
+
+#endif	/* _ASM_POWERPC_OF_PLATFORM_H */
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
new file mode 100644
index 0000000..8105074
--- /dev/null
+++ b/arch/arm/include/asm/prom.h
@@ -0,0 +1,367 @@
+#ifndef _POWERPC_PROM_H
+#define _POWERPC_PROM_H
+#ifdef __KERNEL__
+
+/*
+ * Definitions for talking to the Open Firmware PROM on
+ * Power Macintosh computers.
+ *
+ * Copyright (C) 1996-2005 Paul Mackerras.
+ *
+ * Updates for PPC64 by Peter Bergner & David Engebretsen, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <linux/platform_device.h>
+#include <asm/irq.h>
+#include <asm/atomic.h>
+
+#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT	1
+#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT	1
+
+#define of_compat_cmp(s1, s2, l)	strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2)		strcmp((s1), (s2))
+#define of_node_cmp(s1, s2)		strcasecmp((s1), (s2))
+
+/* Definitions used by the flattened device tree */
+#define OF_DT_HEADER		0xd00dfeed	/* marker */
+#define OF_DT_BEGIN_NODE	0x1		/* Start of node, full name */
+#define OF_DT_END_NODE		0x2		/* End node */
+#define OF_DT_PROP		0x3		/* Property: name off, size,
+						 * content */
+#define OF_DT_NOP		0x4		/* nop */
+#define OF_DT_END		0x9
+
+#define OF_DT_VERSION		0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+	u32	magic;			/* magic word OF_DT_HEADER */
+	u32	totalsize;		/* total size of DT block */
+	u32	off_dt_struct;		/* offset to structure */
+	u32	off_dt_strings;		/* offset to strings */
+	u32	off_mem_rsvmap;		/* offset to memory reserve map */
+	u32	version;		/* format version */
+	u32	last_comp_version;	/* last compatible version */
+	/* version 2 fields below */
+	u32	boot_cpuid_phys;	/* Physical CPU id we're booting on */
+	/* version 3 fields below */
+	u32	dt_strings_size;	/* size of the DT strings block */
+	/* version 17 fields below */
+	u32	dt_struct_size;		/* size of the DT structure block */
+};
+
+
+
+typedef u32 phandle;
+typedef u32 ihandle;
+
+struct property {
+	char	*name;
+	int	length;
+	void	*value;
+	struct property *next;
+};
+
+struct device_node {
+	const char *name;
+	const char *type;
+	phandle	node;
+	phandle linux_phandle;
+	char	*full_name;
+
+	struct	property *properties;
+	struct  property *deadprops; /* removed properties */
+	struct	device_node *parent;
+	struct	device_node *child;
+	struct	device_node *sibling;
+	struct	device_node *next;	/* next device of same type */
+	struct	device_node *allnext;	/* next in list of all nodes */
+	struct  proc_dir_entry *pde;	/* this node's proc directory */
+	struct  kref kref;
+	unsigned long _flags;
+	void	*data;
+};
+
+extern struct device_node *of_chosen;
+
+static inline int of_node_check_flag(struct device_node *n, unsigned long flag)
+{
+	return test_bit(flag, &n->_flags);
+}
+
+static inline void of_node_set_flag(struct device_node *n, unsigned long flag)
+{
+	set_bit(flag, &n->_flags);
+}
+
+
+#define HAVE_ARCH_DEVTREE_FIXUPS
+
+static inline void set_node_proc_entry(struct device_node *dn,
+					struct proc_dir_entry *de)
+{
+	dn->pde = de;
+}
+
+
+extern struct device_node *of_find_all_nodes(struct device_node *prev);
+extern struct device_node *of_node_get(struct device_node *node);
+extern void of_node_put(struct device_node *node);
+
+/* For scanning the flat device-tree at boot time */
+extern int __init of_scan_flat_dt(int (*it)(unsigned long node,
+					    const char *uname, int depth,
+					    void *data),
+				  void *data);
+extern void * __init of_get_flat_dt_prop(unsigned long node, const char *name,
+					unsigned long *size);
+extern int __init of_flat_dt_is_compatible(unsigned long node,
+					const char *name);
+extern unsigned long __init of_get_flat_dt_root(void);
+
+/* For updating the device tree at runtime */
+extern void of_attach_node(struct device_node *);
+extern void of_detach_node(struct device_node *);
+
+/* Other Prototypes */
+extern void finish_device_tree(void);
+extern void unflatten_device_tree(void);
+extern void early_init_devtree(void *);
+extern int machine_is_compatible(const char *compat);
+extern void print_properties(struct device_node *node);
+extern int prom_n_intr_cells(struct device_node *np);
+extern void prom_get_irq_senses(unsigned char *senses, int off, int max);
+extern int prom_add_property(struct device_node *np, struct property *prop);
+extern int prom_remove_property(struct device_node *np, struct property *prop);
+extern int prom_update_property(struct device_node *np,
+				struct property *newprop,
+				struct property *oldprop);
+
+#ifdef CONFIG_PPC32
+/*
+ * PCI <-> OF matching functions
+ * (XXX should these be here?)
+ */
+struct pci_bus;
+struct pci_dev;
+extern int pci_device_from_OF_node(struct device_node *node,
+				   u8 *bus, u8 *devfn);
+extern struct device_node *pci_busdev_to_OF_node(struct pci_bus *, int);
+extern struct device_node *pci_device_to_OF_node(struct pci_dev *);
+extern void pci_create_OF_bus_map(void);
+#endif
+
+extern struct resource *request_OF_resource(struct device_node* node,
+				int index, const char *name_postfix);
+extern int release_OF_resource(struct device_node *node, int index);
+
+
+/*
+ * OF address retreival & translation
+ */
+
+
+/* Helper to read a big number; size is in cells (not bytes) */
+static inline u64 of_read_number(const u32 *cell, int size)
+{
+	u64 r = 0;
+	while (size--)
+		r = (r << 32) | *(cell++);
+	return r;
+}
+
+/* Like of_read_number, but we want an unsigned long result */
+#ifdef CONFIG_PPC32
+static inline unsigned long of_read_ulong(const u32 *cell, int size)
+{
+	return cell[size-1];
+}
+#else
+#define of_read_ulong(cell, size)	of_read_number(cell, size)
+#endif
+
+/* Translate an OF address block into a CPU physical address
+ */
+extern u64 of_translate_address(struct device_node *np, const u32 *addr);
+
+/* Translate a DMA address from device space to CPU space */
+extern u64 of_translate_dma_address(struct device_node *dev,
+				    const u32 *in_addr);
+
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern const u32 *of_get_address(struct device_node *dev, int index,
+			   u64 *size, unsigned int *flags);
+#ifdef CONFIG_PCI
+extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+			       u64 *size, unsigned int *flags);
+#else
+static inline const u32 *of_get_pci_address(struct device_node *dev,
+		int bar_no, u64 *size, unsigned int *flags)
+{
+	return NULL;
+}
+#endif /* CONFIG_PCI */
+
+/* Get an address as a resource. Note that if your address is
+ * a PIO address, the conversion will fail if the physical address
+ * can't be internally converted to an IO token with
+ * pci_address_to_pio(), that is because it's either called to early
+ * or it can't be matched to any host bridge IO space
+ */
+extern int of_address_to_resource(struct device_node *dev, int index,
+				  struct resource *r);
+#ifdef CONFIG_PCI
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+				      struct resource *r);
+#else
+static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
+		struct resource *r)
+{
+	return -ENOSYS;
+}
+#endif /* CONFIG_PCI */
+
+/* Parse the ibm,dma-window property of an OF node into the busno, phys and
+ * size parameters.
+ */
+void of_parse_dma_window(struct device_node *dn, const void *dma_window_prop,
+		unsigned long *busno, unsigned long *phys, unsigned long *size);
+
+extern void kdump_move_device_tree(void);
+
+/* CPU OF node matching */
+struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
+
+/* cache lookup */
+struct device_node *of_find_next_cache_node(struct device_node *np);
+
+/* Get the MAC address */
+extern const void *of_get_mac_address(struct device_node *np);
+
+/*
+ * OF interrupt mapping
+ */
+
+/* This structure is returned when an interrupt is mapped. The controller
+ * field needs to be put() after use
+ */
+
+#define OF_MAX_IRQ_SPEC		 4 /* We handle specifiers of at most 4 cells */
+
+struct of_irq {
+	struct device_node *controller;	/* Interrupt controller node */
+	u32 size;			/* Specifier size */
+	u32 specifier[OF_MAX_IRQ_SPEC];	/* Specifier copy */
+};
+
+/**
+ * of_irq_map_init - Initialize the irq remapper
+ * @flags:	flags defining workarounds to enable
+ *
+ * Some machines have bugs in the device-tree which require certain workarounds
+ * to be applied. Call this before any interrupt mapping attempts to enable
+ * those workarounds.
+ */
+#define OF_IMAP_OLDWORLD_MAC	0x00000001
+#define OF_IMAP_NO_PHANDLE	0x00000002
+
+extern void of_irq_map_init(unsigned int flags);
+
+/**
+ * of_irq_map_raw - Low level interrupt tree parsing
+ * @parent:	the device interrupt parent
+ * @intspec:	interrupt specifier ("interrupts" property of the device)
+ * @ointsize:   size of the passed in interrupt specifier
+ * @addr:	address specifier (start of "reg" property of the device)
+ * @out_irq:	structure of_irq filled by this function
+ *
+ * Returns 0 on success and a negative number on error
+ *
+ * This function is a low-level interrupt tree walking function. It
+ * can be used to do a partial walk with synthetized reg and interrupts
+ * properties, for example when resolving PCI interrupts when no device
+ * node exist for the parent.
+ *
+ */
+
+extern int of_irq_map_raw(struct device_node *parent, const u32 *intspec,
+			  u32 ointsize, const u32 *addr,
+			  struct of_irq *out_irq);
+
+
+/**
+ * of_irq_map_one - Resolve an interrupt for a device
+ * @device:	the device whose interrupt is to be resolved
+ * @index:     	index of the interrupt to resolve
+ * @out_irq:	structure of_irq filled by this function
+ *
+ * This function resolves an interrupt, walking the tree, for a given
+ * device-tree node. It's the high level pendant to of_irq_map_raw().
+ * It also implements the workarounds for OldWolrd Macs.
+ */
+extern int of_irq_map_one(struct device_node *device, int index,
+			  struct of_irq *out_irq);
+
+/**
+ * of_irq_map_pci - Resolve the interrupt for a PCI device
+ * @pdev:	the device whose interrupt is to be resolved
+ * @out_irq:	structure of_irq filled by this function
+ *
+ * This function resolves the PCI interrupt for a given PCI device. If a
+ * device-node exists for a given pci_dev, it will use normal OF tree
+ * walking. If not, it will implement standard swizzling and walk up the
+ * PCI tree until an device-node is found, at which point it will finish
+ * resolving using the OF tree walking.
+ */
+struct pci_dev;
+extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
+
+extern int of_irq_to_resource(struct device_node *dev, int index,
+			struct resource *r);
+
+/**
+ * of_iomap - Maps the memory mapped IO for a given device_node
+ * @device:	the device whose io range will be mapped
+ * @index:	index of the io range
+ *
+ * Returns a pointer to the mapped memory
+ */
+extern void __iomem *of_iomap(struct device_node *device, int index);
+extern int have_of;
+/*
+ * NB:  This is here while we transition from using asm/prom.h
+ * to linux/of.h
+ */
+#include <linux/of.h>
+
+/* align addr on a size boundary - adjust address up/down if needed */
+#define _ALIGN_UP(addr, size)	(((addr) + ((size) - 1)) & (~((size) - 1)))
+#define _ALIGN_DOWN(addr, size)	((addr) & (~((size) - 1)))
+
+/* align addr on a size boundary - adjust address up if needed */
+#define _ALIGN(addr, size)     _ALIGN_UP(addr, size)
+
+#endif /* __KERNEL__ */
+#endif /* _POWERPC_PROM_H */
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 7ffbb29..2fbf11a 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -150,6 +150,13 @@ struct tag_memclk {
 	__u32 fmemclk;
 };
 
+/* Flat dev tree address */
+#define ATAG_FLAT_DEV_TREE_ADDRESS 0xf100040A
+struct tag_flat_dev_tree_address {
+	u32 flat_dev_tree_address;
+	u32 flat_dev_tree_size;
+};
+
 struct tag {
 	struct tag_header hdr;
 	union {
@@ -177,6 +184,7 @@ struct tag {
 		 * DC21285 specific
 		 */
 		struct tag_memclk	memclk;
+		struct tag_flat_dev_tree_address flat_dev_tree_address;
 	} u;
 };
 
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 4305345..adbdd3b 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ATAGS_PROC)	+= atags.o
 obj-$(CONFIG_OABI_COMPAT)	+= sys_oabi-compat.o
 obj-$(CONFIG_ARM_THUMBEE)	+= thumbee.o
 obj-$(CONFIG_KGDB)		+= kgdb.o
+obj-$(CONFIG_OF)		+= prom.o
 
 obj-$(CONFIG_CRUNCH)		+= crunch.o crunch-bits.o
 AFLAGS_crunch-bits.o		:= -Wa,-mcpu=ep9312
diff --git a/arch/arm/kernel/prom.c b/arch/arm/kernel/prom.c
new file mode 100644
index 0000000..9d1c835
--- /dev/null
+++ b/arch/arm/kernel/prom.c
@@ -0,0 +1,414 @@
+/*
+ * Procedures for creating, accessing and interpreting the device tree.
+ *
+ * Paul Mackerras       August 1996.
+ * Copyright (C) 1996-2005 Paul Mackerras.
+ *
+ *  Adapted for 64bit PowerPC by Dave Engebretsen and Peter Bergner.
+ *    {engebret|bergner}@us.ibm.com
+ *
+ *  Adapted for ARM by Motorola Inc.
+ *
+ *      This program is free software; you can redistribute it and/or
+ *      modify it under the terms of the GNU General Public License
+ *      as published by the Free Software Foundation; either version
+ *      2 of the License, or (at your option) any later version.
+ */
+
+#include <stdarg.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/init.h>
+#include <linux/threads.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+#include <linux/pci.h>
+#include <linux/stringify.h>
+#include <linux/delay.h>
+#include <linux/initrd.h>
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/bootmem.h>
+#include <linux/kexec.h>
+#include <linux/debugfs.h>
+#include <linux/irq.h>
+#include <asm/prom.h>
+#include <asm/setup.h>
+#include <asm/memory.h>
+#ifdef DEBUG
+#define DBG(fmt...) printk(KERN_ERR fmt)
+#else
+#define DBG(fmt...)
+#endif
+
+struct boot_param_header *initial_boot_params;
+
+extern struct device_node *allnodes;	/* temporary while merging */
+
+extern rwlock_t devtree_lock;	/* temporary while merging */
+
+/* export that to outside world */
+struct device_node *of_chosen;
+
+static inline char *find_flat_dt_string(u32 offset)
+{
+	return ((char *)initial_boot_params) +
+		initial_boot_params->off_dt_strings + offset;
+}
+
+static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
+				       unsigned long align)
+{
+	void *res;
+
+	*mem = _ALIGN(*mem, align);
+	res = (void *)*mem;
+	*mem += size;
+
+	return res;
+}
+
+static unsigned long __init unflatten_dt_node(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;
+	char *pathp;
+	u32 tag;
+	unsigned int l, allocl;
+	int has_name = 0;
+	int new_format = 0;
+
+	tag = *((u32 *)(*p));
+	if (tag != OF_DT_BEGIN_NODE) {
+		printk("Weird tag at start of node: %x\n", tag);
+		return mem;
+	}
+	*p += 4;
+	pathp = (char *)*p;
+	l = allocl = strlen(pathp) + 1;
+	*p = _ALIGN(*p + l, 4);
+
+	/* version 0x10 has a more compact unit name here instead of the full
+	 * path. we accumulate the full path size using "fpsize", we'll rebuild
+	 * it later. We detect this because the first character of the name is
+	 * not '/'.
+	 */
+	if ((*pathp) != '/') {
+		new_format = 1;
+		if (fpsize == 0) {
+			/* root node: special case. fpsize accounts for path
+			 * plus terminating zero. root node only has '/', so
+			 * fpsize should be 2, but we want to avoid the first
+			 * level nodes to have two '/' so we use fpsize 1 here
+			 */
+			fpsize = 1;
+			allocl = 2;
+		} else {
+			/* account for '/' and path size minus terminal 0
+			 * already in 'l'
+			 */
+			fpsize += l;
+			allocl = fpsize;
+		}
+	}
+
+
+	np = unflatten_dt_alloc(&mem, sizeof(struct device_node) + allocl,
+				__alignof__(struct device_node));
+	if (allnextpp) {
+		memset(np, 0, sizeof(*np));
+		np->full_name = ((char *)np) + sizeof(struct device_node);
+		if (new_format) {
+			char *p = np->full_name;
+			/* rebuild full path for new format */
+			if (dad && dad->parent) {
+				strcpy(p, dad->full_name);
+#ifdef DEBUG
+				if ((strlen(p) + l + 1) != allocl) {
+					DBG("%s: p: %d, l: %d, a: %d\n",
+					    pathp, (int)strlen(p), l, allocl);
+				}
+#endif
+				p += strlen(p);
+			}
+			*(p++) = '/';
+			memcpy(p, pathp, l);
+		} else
+			memcpy(np->full_name, pathp, l);
+		prev_pp = &np->properties;
+		**allnextpp = np;
+		*allnextpp = &np->allnext;
+		if (dad != NULL) {
+			np->parent = dad;
+			/* we temporarily use the next field as `last_child'*/
+			if (dad->next == 0)
+				dad->child = np;
+			else
+				dad->next->sibling = np;
+			dad->next = np;
+		}
+		kref_init(&np->kref);
+	}
+	while (1) {
+		u32 sz, noff;
+		char *pname;
+
+		tag = *((u32 *)(*p));
+		if (tag == OF_DT_NOP) {
+			*p += 4;
+			continue;
+		}
+		if (tag != OF_DT_PROP)
+			break;
+		*p += 4;
+		sz = *((u32 *)(*p));
+		noff = *((u32 *)((*p) + 4));
+		*p += 8;
+		if (initial_boot_params->version < 0x10)
+			*p = _ALIGN(*p, sz >= 8 ? 8 : 4);
+
+		pname = find_flat_dt_string(noff);
+		if (pname == NULL) {
+			printk(KERN_INFO "Can't find property name in list!\n");
+			break;
+		}
+		if (strcmp(pname, "name") == 0)
+			has_name = 1;
+		l = strlen(pname) + 1;
+		pp = unflatten_dt_alloc(&mem, sizeof(struct property),
+					__alignof__(struct property));
+		if (allnextpp) {
+			if (strcmp(pname, "linux,phandle") == 0) {
+				np->node = *((u32 *)*p);
+				if (np->linux_phandle == 0)
+					np->linux_phandle = np->node;
+			}
+			if (strcmp(pname, "ibm,phandle") == 0)
+				np->linux_phandle = *((u32 *)*p);
+			pp->name = pname;
+			pp->length = sz;
+			pp->value = (void *)*p;
+			*prev_pp = pp;
+			prev_pp = &pp->next;
+		}
+		*p = _ALIGN((*p) + sz, 4);
+	}
+	/* with version 0x10 we may not have the name property, recreate
+	 * it here from the unit name if absent
+	 */
+	if (!has_name) {
+		char *p = pathp, *ps = pathp, *pa = NULL;
+		int sz;
+
+		while (*p) {
+			if ((*p) == '@')
+				pa = p;
+			if ((*p) == '/')
+				ps = p + 1;
+			p++;
+		}
+		if (pa < ps)
+			pa = p;
+		sz = (pa - ps) + 1;
+		pp = unflatten_dt_alloc(&mem, sizeof(struct property) + sz,
+					__alignof__(struct property));
+		if (allnextpp) {
+			pp->name = "name";
+			pp->length = sz;
+			pp->value = pp + 1;
+			*prev_pp = pp;
+			prev_pp = &pp->next;
+			memcpy(pp->value, ps, sz - 1);
+			((char *)pp->value)[sz - 1] = 0;
+			DBG("fixed up name for %s -> %s\n", pathp,
+				(char *)pp->value);
+		}
+	}
+	if (allnextpp) {
+		*prev_pp = NULL;
+		np->name = of_get_property(np, "name", NULL);
+		np->type = of_get_property(np, "device_type", NULL);
+
+		if (!np->name)
+			np->name = "<NULL>";
+		if (!np->type)
+			np->type = "<NULL>";
+	}
+	while (tag == OF_DT_BEGIN_NODE) {
+		mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
+		tag = *((u32 *)(*p));
+	}
+	if (tag != OF_DT_END_NODE) {
+		printk(KERN_INFO "Weird tag at end of node: %x\n", tag);
+		return mem;
+	}
+	*p += 4;
+	return mem;
+}
+
+/**
+ * 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 (this used to be done by finish_device_tree)
+ */
+void __init unflatten_device_tree(void)
+{
+	unsigned long start, mem, size;
+	struct device_node **allnextp = &allnodes;
+
+	DBG(" -> unflatten_device_tree()\n");
+	if (!initial_boot_params)
+		return;
+	/* First pass, scan for size */
+	start = ((unsigned long)initial_boot_params) +
+		initial_boot_params->off_dt_struct;
+	size = unflatten_dt_node(0, &start, NULL, NULL, 0);
+	size = (size | 3) + 1;
+
+	DBG("  size is %lx, allocating...\n", size);
+
+	/* Allocate memory for the expanded device tree */
+	mem = (unsigned long) __alloc_bootmem(size + 4,
+			__alignof__(struct device_node), 0);
+
+	((u32 *)mem)[size / 4] = 0xdeadbeef;
+
+	DBG("  unflattening %lx...\n", mem);
+
+	/* Second pass, do actual unflattening */
+	start = ((unsigned long)initial_boot_params) +
+		initial_boot_params->off_dt_struct;
+	unflatten_dt_node(mem, &start, NULL, &allnextp, 0);
+	if (*((u32 *)start) != OF_DT_END)
+		printk(KERN_WARNING "Weird tag at end of tree: %08x\n",
+			*((u32 *)start));
+	if (((u32 *)mem)[size / 4] != 0xdeadbeef)
+		printk(KERN_WARNING "End of tree marker overwritten: %08x\n",
+		       ((u32 *)mem)[size / 4]);
+	*allnextp = NULL;
+
+	/* 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");
+
+	DBG(" <- unflatten_device_tree()\n");
+}
+
+/**
+ *	of_find_node_by_phandle - Find a node given a phandle
+ *	@handle:	phandle of the node to find
+ *
+ *	Returns a node pointer with refcount incremented, use
+ *	of_node_put() on it when done.
+ */
+struct device_node *of_find_node_by_phandle(phandle handle)
+{
+	struct device_node *np;
+
+	read_lock(&devtree_lock);
+	for (np = allnodes; np != 0; np = np->allnext)
+		if (np->linux_phandle == handle)
+			break;
+	of_node_get(np);
+	read_unlock(&devtree_lock);
+	return np;
+}
+EXPORT_SYMBOL(of_find_node_by_phandle);
+
+struct device_node *of_node_get(struct device_node *node)
+{
+	if (node)
+		kref_get(&node->kref);
+	return node;
+}
+EXPORT_SYMBOL(of_node_get);
+static inline struct device_node *kref_to_device_node(struct kref *kref)
+{
+	return container_of(kref, struct device_node, kref);
+}
+
+/**
+ *	of_node_release - release a dynamically allocated node
+ *	@kref:  kref element of the node to be released
+ *
+ *	In of_node_put() this function is passed to kref_put()
+ *	as the destructor.
+ */
+static void of_node_release(struct kref *kref)
+{
+	struct device_node *node = kref_to_device_node(kref);
+	struct property *prop = node->properties;
+
+	/* We should never be releasing nodes that haven't been detached. */
+	if (!of_node_check_flag(node, OF_DETACHED)) {
+		printk(KERN_WARNING "WARNING: Bad of_node_put() on %s\n",
+			node->full_name);
+		dump_stack();
+		kref_init(&node->kref);
+		return;
+	}
+
+	if (!of_node_check_flag(node, OF_DYNAMIC))
+		return;
+
+	while (prop) {
+		struct property *next = prop->next;
+		kfree(prop->name);
+		kfree(prop->value);
+		kfree(prop);
+		prop = next;
+
+		if (!prop) {
+			prop = node->deadprops;
+			node->deadprops = NULL;
+		}
+	}
+	kfree(node->full_name);
+	kfree(node->data);
+	kfree(node);
+}
+
+/**
+ *	of_node_put - Decrement refcount of a node
+ *	@node:	Node to dec refcount, NULL is supported to
+ *		simplify writing of callers
+ *
+ */
+void of_node_put(struct device_node *node)
+{
+	if (node)
+		kref_put(&node->kref, of_node_release);
+}
+EXPORT_SYMBOL(of_node_put);
+
+int have_of;
+u32 phys_flat_dev_tree_address __initdata;
+u32 phys_flat_dev_tree_size __initdata;
+
+/* process flat device tree for hardware configuration */
+static int __init parse_tag_flat_dev_tree_address(const struct tag *tag)
+{
+    phys_flat_dev_tree_address =
+			tag->u.flat_dev_tree_address.flat_dev_tree_address;
+    phys_flat_dev_tree_size = tag->u.flat_dev_tree_address.flat_dev_tree_size;
+
+    have_of = 1;
+    if (phys_flat_dev_tree_size)
+	initial_boot_params = phys_to_virt(phys_flat_dev_tree_address);
+
+    printk(KERN_INFO
+	"%s: flat_dev_tree_address=0x%08x, flat_dev_tree_size == 0x%08X\n",
+	__func__,
+	phys_flat_dev_tree_address,
+	phys_flat_dev_tree_size);
+
+    return 0;
+}
+
+__tagtable(ATAG_FLAT_DEV_TREE_ADDRESS, parse_tag_flat_dev_tree_address);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 68d6494..8b219ec 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -35,6 +35,7 @@
 #include <asm/cacheflush.h>
 #include <asm/cachetype.h>
 #include <asm/tlbflush.h>
+#include <asm/prom.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/irq.h>
@@ -726,6 +727,7 @@ void __init setup_arch(char **cmdline_p)
 	parse_cmdline(cmdline_p, from);
 	paging_init(mdesc);
 	request_standard_resources(&meminfo, mdesc);
+	unflatten_device_tree();
 
 #ifdef CONFIG_SMP
 	smp_init_cpus();
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index f821dbc..c23a6ea 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -1,6 +1,6 @@
 config OF_DEVICE
 	def_bool y
-	depends on OF && (SPARC || PPC_OF)
+	depends on OF && (SPARC || PPC_OF || ARM)
 
 config OF_GPIO
 	def_bool y

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 1:08 AM, Janboe Ye <yuan-bo.ye@motorola.com> wrote:
> Hi, All
>
> Currently, ARM linux uses mach-type to figure out platform. But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals.
>
> The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code.
>
> Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware , for the detail of device tree.
>
> www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
>
> Signed-off-by: janboe <yuan-bo.ye@motorola.com>

Heeheehe, This is Fantastic.  I'm actually working on this too.  Would
you like to join our efforts?

>  arch/arm/include/asm/of_device.h   |   32 +++
>  arch/arm/include/asm/of_platform.h |   39 ++++
>  arch/arm/include/asm/prom.h        |  367 ++++++++++++++++++++++++++++++++
>  arch/arm/include/asm/setup.h       |    8 +
>  arch/arm/kernel/Makefile           |    1 +
>  arch/arm/kernel/prom.c             |  414 ++++++++++++++++++++++++++++++++++++
>  arch/arm/kernel/setup.c            |    2 +

Right now we've got 3 platforms in mainline using the OF
infrastructure (sparc, powerpc & microblaze), and 2 using the
Flattened Device Tree (powerpc & microblaze).  Unfortunately, all of
the FDT stuff is duplicated between the 2 ports, along with some OF
support functions which could be common.  I don't want to see it
duplicated yet again.  First thing to do is to factor out the common
code and then make that buildable on ARM.

Another thing that needs to be done is to make the OF code endian
safe.  The FDT format is all in network-byte-order, but since the
current users are all big endian, not enough care has been taken to
use the appropriate nto*() functions when reading data out of the
tree.

> +/* process flat device tree for hardware configuration */
> +static int __init parse_tag_flat_dev_tree_address(const struct tag *tag)
> +{
> +    phys_flat_dev_tree_address =
> +                       tag->u.flat_dev_tree_address.flat_dev_tree_address;
> +    phys_flat_dev_tree_size = tag->u.flat_dev_tree_address.flat_dev_tree_size;
> +
> +    have_of = 1;
> +    if (phys_flat_dev_tree_size)
> +       initial_boot_params = phys_to_virt(phys_flat_dev_tree_address);
> +
> +    printk(KERN_INFO
> +       "%s: flat_dev_tree_address=0x%08x, flat_dev_tree_size == 0x%08X\n",
> +       __func__,
> +       phys_flat_dev_tree_address,
> +       phys_flat_dev_tree_size);
> +
> +    return 0;
> +}
> +
> +__tagtable(ATAG_FLAT_DEV_TREE_ADDRESS, parse_tag_flat_dev_tree_address);

I like this approach.  By using an ATAG, it doesn't force the ARM
kernel to use the FDT.  Of a platform provides one, then great, the
board port can use it.  If not, then it doesn't break existing board
ports.

An unanswered question is how platforms will make use of the FDT data.
 One idea is to define a new machine number for "FDT described
platform", and then probe what board-specific setup code to use from
data in the tree.  Another is if an FDT blob is provided on an
existing board which already has a machine number, then the board code
can be modified to extract device descriptions out of the tree.

I've found that even when firmware does not provide FDT support, it is
still useful to use the FDT data structure and to link it into the
kernel image itself.  There isn't the advantage of building a
multiplatform image in this case, but I find that it tends to result
in more common code between board ports using the same SoC or even
same core.  ie.  Most of the PowerPC eval boards using one of the 440
core variants can be supported by the file
arch/powerpc/platforms/440/ppc44x_simple.c, which is less than 100
lines long.

One thing I'd like to stress is that in powerpc land we make a lot of
mistakes on device tree usage conventions and bindings.  There is a
broad history of experience in the old OpenFirmware documents.  I
often found problems I was trying to solve with FDT already had been
solved by the OpenFirmware folks years ago.  General agreement now is
that all new bindings *must* be documented and reviewed before a
driver using them are merged (the documentation and driver can be
reviewed at the same time).  Right now the documentation is held in
Documentation/powerpc/fdt-bindings/, but that can be moved to a more
common location.  The mailing list for device tree review is
devicetree-discuss@ozlabs.org.  It's also a good place to go for
questions.

I've been toying with the idea for a while now of splitting the device
tree bindings documentation out of the kernel entirely so that it is
useful for other projects too.  For example, I believe that the
FreeBSD ARM community has expressed some interest in the FDT approach.

g.

> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 68d6494..8b219ec 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -35,6 +35,7 @@
>  #include <asm/cacheflush.h>
>  #include <asm/cachetype.h>
>  #include <asm/tlbflush.h>
> +#include <asm/prom.h>
>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/irq.h>
> @@ -726,6 +727,7 @@ void __init setup_arch(char **cmdline_p)
>        parse_cmdline(cmdline_p, from);
>        paging_init(mdesc);
>        request_standard_resources(&meminfo, mdesc);
> +       unflatten_device_tree();
>
>  #ifdef CONFIG_SMP
>        smp_init_cpus();
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index f821dbc..c23a6ea 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -1,6 +1,6 @@
>  config OF_DEVICE
>        def_bool y
> -       depends on OF && (SPARC || PPC_OF)
> +       depends on OF && (SPARC || PPC_OF || ARM)
>
>  config OF_GPIO
>        def_bool y
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Timur Tabi]

On Wed, May 27, 2009 at 9:27 AM, Grant Likely <grant.likely@secretlab.ca> wrote:

>> Signed-off-by: janboe <yuan-bo.ye@motorola.com>
>
> Heeheehe, This is Fantastic.

Yes, I agree.  Thanks for working on this.  I was hoping to work on it
myself later this year.  Freescale develops both ARM-based and
PowerPC-based SOCs, and some devices are shared between them (e.g. the
SSI).  Lack of device-tree support on ARM has been a real hindrance to
getting the ARM-based Linux support on par with PowerPC.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Wed, May 27, 2009 at 09:39:30AM -0500, Timur Tabi wrote:
> > > Signed-off-by: janboe <yuan-bo.ye@motorola.com>
> >
> > Heeheehe, This is Fantastic.
>
> Yes, I agree. Thanks for working on this. I was hoping to work on it
> myself later this year. Freescale develops both ARM-based and
> PowerPC-based SOCs, and some devices are shared between them (e.g. the
> SSI). Lack of device-tree support on ARM has been a real hindrance to
> getting the ARM-based Linux support on par with PowerPC.

Another reason might be this:

rsc@thebe:linux-2.6$ git log --pretty=short arch/arm/mach-mx? \
	arch/arm/plat-mxc/ | grep -e "^Author." | grep freescale | wc -l
1

rsc@thebe:linux-2.6$ git log --pretty=short arch/arm/mach-mx? \
	arch/arm/plat-mxc/ | grep -e "^Author." | grep pengutronix | wc -l
97

rsc@thebe:linux-2.6$ git log --pretty=short arch/arm/mach-mx? \
	arch/arm/plat-mxc/ | grep -e "^Author." | wc -l
195

I'm highly convinced that the existence of oftree-hell in ARM-land would
have been *the* key motivation for FSL to have worked on mainline
instead of inhouse-BSPs back in 2004 when we mainlined i.MX1 and in 2007
when we started the mainline work on MX27 and MX31.

Seriously: oftree in general is a good idea. Just that it doesn't work
in practise. The concept has some serious flaws:

- The whole concept is based on the assumption that bindings are defined
  *once*, then never to be changed again. As this is not true (check
  MPC5200 to find out what I mean), oftree wreckage is *the* main cause
  of new kernels not working on old bootloaders any more. Is there a
  solution of this problem? I have not seen a good idea how to avoid the
  constant change in definitions.

- The oftree layering is fundamentally broken. We already have a sane
  abstraction for arbitrary hardware in the kernel: platform devices.
  Why not instanciate platform devices from a generic oftree core?

- Platform data makes it possible to store function pointers. There
  is no equivalent to this concept in oftree-land.

oftree could be a great tool if these things would be resolved.
Currently they are not, and in result, ARM just works and is easy,
whereas on PowerPC systems people often spend more time working on
binding stuff than on the actual functionality.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> Seriously: oftree in general is a good idea. Just that it doesn't work
> in practise. The concept has some serious flaws:
>
> - The whole concept is based on the assumption that bindings are defined
>  *once*, then never to be changed again. As this is not true (check
>  MPC5200 to find out what I mean), oftree wreckage is *the* main cause
>  of new kernels not working on old bootloaders any more. Is there a
>  solution of this problem? I have not seen a good idea how to avoid the
>  constant change in definitions.

This is a MPC5200 is the posterchild for device tree wreckage; mostly
because of my own inexperience at the time.  A lot of mistakes were
made and I freely admit that.

However, my counter example is Xilinx Virtex support.  The Virtex is
an FPGA with all the devices instantiated in the FPGA fabric.  It
would be a nightmare to try and describe each different FPGA bitstream
using hand coded platform devices, and the xparameters.h file exported
by the Xilinx toolchain wasn't much better.  Encoding the machine
layout in a data structure (the device tree) has decoupled FPGA
changes from the kernel image.  Now FPGA engineers can make major
changes to FPGA layouts without having to lockstep with changes in the
kernel.  I regularly boot a single kernel image on multiple bitstream
images.

That being said, the problems we have had are the reason why it is
*not* recommended to hard link the device tree image into firmware.
We do commit to not breaking old trees, but the ability to update is
important; particularly for enabling new features/drivers.

> - The oftree layering is fundamentally broken. We already have a sane
>  abstraction for arbitrary hardware in the kernel: platform devices.
>  Why not instanciate platform devices from a generic oftree core?

No; the oftree is a data structure.  That is it, nothing more.  The
device tree layout is well defined and independent of Linux kernel
internal implementation details.  In powerpc land we've chosen to use
the of_platform bus to decode the data into Linux usable form, and I
think it is the best approach.  If a designer wanted to, then platform
devices could be instantiated instead.  In fact, that used to be done
for most powerpc devices, but we've moved away from that model because
the data still needs to be decoded somewhere, and that 'somewhere'
should be as close to the driver as possible.

> - Platform data makes it possible to store function pointers. There
>  is no equivalent to this concept in oftree-land.

But there is concept of platform specific code.  In the majority of
cases platform specific function pointers aren't needed at all.  In
the cases where they are; platform devices can still be used.

> oftree could be a great tool if these things would be resolved.
> Currently they are not, and in result, ARM just works and is easy,
> whereas on PowerPC systems people often spend more time working on
> binding stuff than on the actual functionality.

That's a rather polarizing statement and I don't think its fair.  The
FDT is not a magic bullet.  It makes aspects of platform independence,
code sharing, and board porting simpler, but it is also requires
forethought and has overhead associated with it.  I don't think anyone
is proposing to require all ARM platforms to use the FDT approach.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Peter Korsgaard]

>>>>> "Robert" == Robert Schwebel <r.schwebel@pengutronix.de> writes:

Hi,

 Robert> - The whole concept is based on the assumption that bindings
 Robert> are defined *once*, then never to be changed again. As this
 Robert> is not true (check MPC5200 to find out what I mean), oftree
 Robert> wreckage is *the* main cause of new kernels not working on
 Robert> old bootloaders any more. Is there a solution of this
 Robert> problem? I have not seen a good idea how to avoid the
 Robert> constant change in definitions.

Just bundle the .dtb with the kernel and they'll always be in sync. I
know this isn't really in the spirit of OF, but currently imho the
only realistic solution.

I did a (nacked) patch to do this with the multi-image support in
U-Boot some time ago:

http://patchwork.ozlabs.org/patch/589/

 Robert> - The oftree layering is fundamentally broken. We already
 Robert> have a sane abstraction for arbitrary hardware in the kernel:
 Robert> platform devices.  Why not instanciate platform devices from
 Robert> a generic oftree core?

 Robert> - Platform data makes it possible to store function
 Robert> pointers. There is no equivalent to this concept in
 Robert> oftree-land.

Yeah.

-- 
Bye, Peter Korsgaard

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

Hi Grant,

On Wed, May 27, 2009 at 09:39:21AM -0600, Grant Likely wrote:
> This is a MPC5200 is the posterchild for device tree wreckage; mostly
> because of my own inexperience at the time.  A lot of mistakes were
> made and I freely admit that.
>
> However, my counter example is Xilinx Virtex support. The Virtex is an
> FPGA with all the devices instantiated in the FPGA fabric. It would
> be a nightmare to try and describe each different FPGA bitstream using
> hand coded platform devices, and the xparameters.h file exported by
> the Xilinx toolchain wasn't much better. Encoding the machine layout
> in a data structure (the device tree) has decoupled FPGA changes from
> the kernel image. Now FPGA engineers can make major changes to FPGA
> layouts without having to lockstep with changes in the kernel. I
> regularly boot a single kernel image on multiple bitstream images.
>
> That being said, the problems we have had are the reason why it is
> *not* recommended to hard link the device tree image into firmware.
> We do commit to not breaking old trees, but the ability to update is
> important; particularly for enabling new features/drivers.

Point taken.

We often have the situation that we have

- a SoC cpu from vendor A
- a module with the cpu+ram+peripherals from vendor B
- a baseboard from vendor C
- sometimes an extension board from vendor D

All that with non-introspectable busses, like chip select busses, SPI,
i2c, FPGA-internal busses etc. We recently tried to put oftree sniplets
into the devices (one into the module, one in the baseboard etc), let
u-boot collect these sniplets and build an oftree out of it. It doesn't
work. If you try this, you'll quickly find out that you would have to
put the schematics into the oftree. A peripheral pin can be routed to a
ball, goes from a connector of the module to a baseboard, to the
extension board, come back and go to another unit on the SoC. This
cannot be described in the oftree. At one place, you need to *know*
about the whole hardware that you have and have a single "we have X" to
"X's oftree" mapping.

In the end, having a single "X needs these platform data" kernel source
file is much, much cleaner and less error prone than what we currently
have with the oftree.

> > - The oftree layering is fundamentally broken. We already have a sane
> >  abstraction for arbitrary hardware in the kernel: platform devices.
> >  Why not instanciate platform devices from a generic oftree core?
>
> No; the oftree is a data structure. That is it, nothing more.

Unfortunately, it is an incomplete data structure regarding to what the
kernel needs.

> > - Platform data makes it possible to store function pointers. There
> >  is no equivalent to this concept in oftree-land.
>
> But there is concept of platform specific code. In the majority of
> cases platform specific function pointers aren't needed at all. In
> the cases where they are; platform devices can still be used.

In this case, they need an equivalent to a "machine number" information.

> > oftree could be a great tool if these things would be resolved.
> > Currently they are not, and in result, ARM just works and is easy,
> > whereas on PowerPC systems people often spend more time working on
> > binding stuff than on the actual functionality.
>
> That's a rather polarizing statement and I don't think its fair. The
> FDT is not a magic bullet. It makes aspects of platform independence,
> code sharing, and board porting simpler, but it is also requires
> forethought and has overhead associated with it. I don't think anyone
> is proposing to require all ARM platforms to use the FDT approach.

Sorry, it was not meant to be offending, it just reflects a certain
level of frustration.

Don't take me wrong: I consider the *idea* behind oftree a good one. It
just has unsolved problems. If we manage to turn this discussion into
something that accelerates things into a good direction, I'm all with
you.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Scott Wood]

Peter Korsgaard wrote:
>>>>>> "Robert" == Robert Schwebel <r.schwebel@pengutronix.de> writes:
> 
> Hi,
> 
>  Robert> - The whole concept is based on the assumption that bindings
>  Robert> are defined *once*, then never to be changed again. As this
>  Robert> is not true (check MPC5200 to find out what I mean), oftree
>  Robert> wreckage is *the* main cause of new kernels not working on
>  Robert> old bootloaders any more. Is there a solution of this
>  Robert> problem? I have not seen a good idea how to avoid the
>  Robert> constant change in definitions.
> 
> Just bundle the .dtb with the kernel and they'll always be in sync. I
> know this isn't really in the spirit of OF, but currently imho the
> only realistic solution.

That removes the ability to use the device tree to pass information from 
the bootloader, such as MAC addresses and clock frequencies.  On the 
u-boot list, you'll find people trying such hacks (which were rightly 
NACKed) as passing the information in the device's volatile registers 
(which the Linux driver must then not reset) to deal with ARM Linux's 
lack of this ability.

>  Robert> - The oftree layering is fundamentally broken. We already
>  Robert> have a sane abstraction for arbitrary hardware in the kernel:
>  Robert> platform devices.  Why not instanciate platform devices from
>  Robert> a generic oftree core?

You can, if you want.  But you'll need extra glue code that understands 
the individual bindings.  IMHO that logic is usually better off in the 
driver itself, but if you really need platform code to involve itself in 
some way (such as providing callbacks), then exceptions can be made.

-Scott

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Wed, May 27, 2009 at 05:05:27PM +0200, Robert Schwebel wrote:

> I'm highly convinced that the existence of oftree-hell in ARM-land would
> have been *the* key motivation for FSL to have worked on mainline
> instead of inhouse-BSPs back in 2004 when we mainlined i.MX1 and in 2007
> when we started the mainline work on MX27 and MX31.

I remain to be convinced about that but anyway..

> Seriously: oftree in general is a good idea. Just that it doesn't work
> in practise. The concept has some serious flaws:

> - Platform data makes it possible to store function pointers. There
>   is no equivalent to this concept in oftree-land.

The handling of platform data is my main concern as someone working
primarily on platform independant drivers - function pointers are a
particular problem but the possibility of having to write code to
handle both OF and non-OF systems to cater for systems using both
approaches is also a concern for me.

> oftree could be a great tool if these things would be resolved.
> Currently they are not, and in result, ARM just works and is easy,
> whereas on PowerPC systems people often spend more time working on
> binding stuff than on the actual functionality.

This worries me too, my experiences with OF device tree handling for
ASoC have been pretty negative - but then audio is one of the worst
cases for handling within the device tree.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King]

(For whatever reason, I don't have the initial email on this.)

On Wed, May 27, 2009 at 08:27:10AM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 1:08 AM, Janboe Ye <yuan-bo.ye@motorola.com> wrote:
> > Hi, All
> >
> > Currently, ARM linux uses mach-type to figure out platform. But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals.
> >
> > The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code.
> >
> > Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware , for the detail of device tree.
> >
> > www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
> >
> > Signed-off-by: janboe <yuan-bo.ye@motorola.com>
> 
> Heeheehe, This is Fantastic.  I'm actually working on this too.  Would
> you like to join our efforts?

My position is that I don't like this approach.  We have _enough_ of a
problem getting boot loaders to do stuff they should be doing on ARM
platforms, that handing them the ability to define a whole device tree
is just insanely stupid.

For example, it's taken _years_ to get boot loader folk to pass one
correct value to the kernel.  It's taken years for boot loaders to
start passing ATAGs to the kernel to describe memory layouts.  And even
then there's various buggy platforms which don't do this correctly.

I don't see device trees as being any different - in fact, I see it as
yet another possibility for a crappy interface that lots of people will
get wrong, and then we'll have to carry stupid idiotic fixups in the
kernel for lots of platforms.

The end story is that as far as machine developers are concerned, a
boot loader, once programmed into the device, is immutable.  They never
_ever_ want to change it, period.

So no, I see this as a recipe for ugly hacks appearing in the kernel
working around boot loader crappyness, and therefore I'm against it.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 11:44 AM, Russell King
<rmk+lkml@arm.linux.org.uk> wrote:
> (For whatever reason, I don't have the initial email on this.)
>
> On Wed, May 27, 2009 at 08:27:10AM -0600, Grant Likely wrote:
>> On Wed, May 27, 2009 at 1:08 AM, Janboe Ye <yuan-bo.ye@motorola.com> wrote:
>> > Hi, All
>> >
>> > Currently, ARM linux uses mach-type to figure out platform. But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals.
>> >
>> > The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code.
>> >
>> > Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware , for the detail of device tree.
>> >
>> > www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
>> >
>> > Signed-off-by: janboe <yuan-bo.ye@motorola.com>
>>
>> Heeheehe, This is Fantastic.  I'm actually working on this too.  Would
>> you like to join our efforts?
>
> My position is that I don't like this approach.  We have _enough_ of a
> problem getting boot loaders to do stuff they should be doing on ARM
> platforms, that handing them the ability to define a whole device tree
> is just insanely stupid.

The point of this approach is that the device tree is *not* create by
firmware.  Firmware can pass it in if it is convenient to do so, (ie;
the device tree blob stored in flash as a separate image) but it
doesn't have to be and it is not 'owned' by firmware.

It is also true that there is the option for firmware to manipulate
the .dts, but once again it is not required and it does not replace
the existing ATAGs.

If a board port does get the device tree wrong; no big deal, we just
fix it and ship it with the next kernel.

> The end story is that as far as machine developers are concerned, a
> boot loader, once programmed into the device, is immutable.  They never
> _ever_ want to change it, period.

I agree 100%.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King]

On Wed, May 27, 2009 at 11:23:29AM -0500, Scott Wood wrote:
> That removes the ability to use the device tree to pass information from  
> the bootloader, such as MAC addresses and clock frequencies.  On the  
> u-boot list, you'll find people trying such hacks (which were rightly  
> NACKed) as passing the information in the device's volatile registers  
> (which the Linux driver must then not reset) to deal with ARM Linux's  
> lack of this ability.

No one has brought that up on the ARM mailing lists - so does this issue
really exist?  All of the stuff I see on the ARM lists seems to be well
behaved and following our existing model - even vendor stuff (supplied
to me under NDA) seems to generally get this kind of stuff right.

Basically, what I'm saying is that I have seen no evidence to support
the argument you're making, but I'm not saying you're wrong or that it
doesn't happen.

>>  Robert> - The oftree layering is fundamentally broken. We already
>>  Robert> have a sane abstraction for arbitrary hardware in the kernel:
>>  Robert> platform devices.  Why not instanciate platform devices from
>>  Robert> a generic oftree core?
>
> You can, if you want.  But you'll need extra glue code that understands  
> the individual bindings.  IMHO that logic is usually better off in the  
> driver itself, but if you really need platform code to involve itself in  
> some way (such as providing callbacks), then exceptions can be made.

No it is not.  Device drivers are best written to support devices, and
the platform specific code should not be anywhere near them.  Platform
specific code to handle oddities of platforms should be totally separate
from the device driver itself.

For example, see the mess that is cs89x0, which isn't a platform driver
(or any kind of driver model driver).  It's full of individual platform
specific hacks to make it work on platforms X, Y and Z.  The same was
true of the smc91x driver (which is a platform driver but wasn't done
in a generic way.)  smc91x was very quickly becoming a big problem to
maintain and use because of all the platform specific junk being shoe-
horned into the driver.  smc91x eventually got fixed.  cs89x0 hasn't.

smc91x is a prime example of the kind of information drivers need - base
address and irq are very much insufficient to describe how this device is
connected.  There's much more information required to specify this device
fully, and throwing it into the driver doesn't work.  We've been there
and proven that point.

So, repeat this mantra: device drivers should contain no platform specifics.
Platform specifics should be separated from the driver and implemented by
platform support code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [RFC] [PATCH] Device Tree on ARM platform

[Peter Korsgaard]

>>>>> "Scott" == Scott Wood <scottwood@freescale.com> writes:

Hi,

 >> Just bundle the .dtb with the kernel and they'll always be in sync. I
 >> know this isn't really in the spirit of OF, but currently imho the
 >> only realistic solution.

 Scott> That removes the ability to use the device tree to pass information
 Scott> from the bootloader, such as MAC addresses and clock frequencies.  On
 Scott> the u-boot list, you'll find people trying such hacks (which were
 Scott> rightly NACKed) as passing the information in the device's volatile
 Scott> registers (which the Linux driver must then not reset) to deal with
 Scott> ARM Linux's lack of this ability.

No, with the multi-image support U-Boot has full access to the device
tree. E.G. I adjust the flash partition list defined in the .dtb in my
board's ft_board_setup() routine.

-- 
Bye, Peter Korsgaard

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Wed, May 27, 2009 at 12:32 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 05:05:27PM +0200, Robert Schwebel wrote:

>> oftree could be a great tool if these things would be resolved.
>> Currently they are not, and in result, ARM just works and is easy,
>> whereas on PowerPC systems people often spend more time working on
>> binding stuff than on the actual functionality.
>
> This worries me too, my experiences with OF device tree handling for
> ASoC have been pretty negative - but then audio is one of the worst
> cases for handling within the device tree.

ASoC is where I2C was a year ago. I2C had it's own module loading
conventions. OF assumes the subsystem is going to follow the standard
kernel module loading conventions. I2C has now been fixed to use the
standard conventions and it happily works with OF now.

The fight with ASoC is that two different entities are trying to link
the modules together - ASoC (machine drivers) and the device tree
code. There should only be one system linking everything together.
But you want these ASoC machine drivers on ARM because ARM doesn't
have device trees.

I2C had the same problem. I2C wanted everything loaded form machine
drivers. The machine drivers are now optional. ASoC can be fixed in
the same way.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] [PATCH] Device Tree on ARM platform

[Alexander Clouter]

In gmane.linux.kernel Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
> <r.schwebel@pengutronix.de> wrote:
>> Seriously: oftree in general is a good idea. Just that it doesn't work
>> in practise. The concept has some serious flaws:
>>
>> - The whole concept is based on the assumption that bindings are defined
>>  *once*, then never to be changed again. As this is not true (check
>>  MPC5200 to find out what I mean), oftree wreckage is *the* main cause
>>  of new kernels not working on old bootloaders any more. Is there a
>>  solution of this problem? I have not seen a good idea how to avoid the
>>  constant change in definitions.
> 
> This is a MPC5200 is the posterchild for device tree wreckage; mostly
> because of my own inexperience at the time.  A lot of mistakes were
> made and I freely admit that.
> 
> However, my counter example is Xilinx Virtex support.  The Virtex is
> an FPGA with all the devices instantiated in the FPGA fabric.  It
> would be a nightmare to try and describe each different FPGA bitstream
> using hand coded platform devices, and the xparameters.h file exported
> by the Xilinx toolchain wasn't much better.  Encoding the machine
> layout in a data structure (the device tree) has decoupled FPGA
> changes from the kernel image.  Now FPGA engineers can make major
> changes to FPGA layouts without having to lockstep with changes in the
> kernel.  I regularly boot a single kernel image on multiple bitstream
> images.
> 
> That being said, the problems we have had are the reason why it is
> *not* recommended to hard link the device tree image into firmware.
> We do commit to not breaking old trees, but the ability to update is
> important; particularly for enabling new features/drivers.
> 
Although I have no input of value here, I'm hoping I do not become the 
next posterchild for "pain++".

I'm working through redo'ing the FPGA support in the TS-7800[1] into a 
new bus rather than just continuing the messy direction I have been 
going to date[2].

My current approach is that the bus handles the 'hotplug'ing of the FPGA 
bitstream by unregistering all the devices and then when it's informed 
the new bitstream is ready it prods all the registered drivers if any 
devices need bringing up (obviously drivers can be modprobe'd as and 
when).

The 'magic' is that the FPGA code has some special value[3] that what it 
is and the drivers (outside the platform code) have a list of FPGA magic 
values (with a mask) that they are willing to service.  The *bus* 
(platform code) is what installs the devices effectively and only does 
so if the loaded driver says it can drive a particular loaded bitstream 
(in the bus driver struct is a array of ID's it checks).

Does this sound sane?  Is it an approach that could be ACKed one day?  
Currently the bit that might be considered sinful is there is for some 
of the drivers (rtc-m48t86, timeriomem-rng and plat_nand) the FPGA bus 
'driver' is a light wrapper around the platform device driver.  This is 
so that the hooks still exist so the bus know what to load and unload as 
and when.

I cannot think of another way to do this as implementing the FPGA as a 
'parent' *device* rather than a bus would shift all the bitstream 
specific code back into the platform code :-/  There might be a magic 
method I have not seen yet though.

I would dish out patches, but currently it's not a patch set, just one 
phat one; obviously it will be broken up later :)

Cheers

[1] http://ts78xx.digriz.org.uk/
	http://armlinux.simtec.co.uk/kautobuild/2.6.29/index.html#machine_1653
[2] http://git.marvell.com/?p=orion.git;a=blob;f=arch/arm/mach-orion5x/ts78xx-setup.c;hb=HEAD
[3] ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7800-linux/docs/ts-7800-syscon-regmap.txt

-- 
Alexander Clouter
.sigmonster says: Good leaders being scarce, following yourself is allowed.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Scott Wood]

Russell King wrote:
> On Wed, May 27, 2009 at 11:23:29AM -0500, Scott Wood wrote:
>> That removes the ability to use the device tree to pass information from  
>> the bootloader, such as MAC addresses and clock frequencies.  On the  
>> u-boot list, you'll find people trying such hacks (which were rightly  
>> NACKed) as passing the information in the device's volatile registers  
>> (which the Linux driver must then not reset) to deal with ARM Linux's  
>> lack of this ability.
> 
> No one has brought that up on the ARM mailing lists - so does this issue
> really exist?  All of the stuff I see on the ARM lists seems to be well
> behaved and following our existing model - even vendor stuff (supplied
> to me under NDA) seems to generally get this kind of stuff right.

I'm just going by what I've seen on the u-boot list lately.  What is the 
existing ARM Linux model for passing MAC addresses, so that we can point 
people to that when they try to get u-boot to do silly things?

>>>  Robert> - The oftree layering is fundamentally broken. We already
>>>  Robert> have a sane abstraction for arbitrary hardware in the kernel:
>>>  Robert> platform devices.  Why not instanciate platform devices from
>>>  Robert> a generic oftree core?
>> You can, if you want.  But you'll need extra glue code that understands  
>> the individual bindings.  IMHO that logic is usually better off in the  
>> driver itself, but if you really need platform code to involve itself in  
>> some way (such as providing callbacks), then exceptions can be made.
> 
> No it is not.  Device drivers are best written to support devices, and
> the platform specific code should not be anywhere near them.  Platform
> specific code to handle oddities of platforms should be totally separate
> from the device driver itself.

I'm not talking about platform specific code, I'm talking about code to 
retrieve information about a device from the device tree.  There would 
not be separate instances of this for "platforms X, Y and Z", just one 
of_platform binding in each driver.  It's no different than having a 
platform bus binding, except in the data structures used.

But to restate, having external glue to create platform devices from the 
device tree is fine if that's what you want to do.  We used to do that, 
but it was a pain compared to keeping everything in one place.  Your 
experience may differ.

> smc91x is a prime example of the kind of information drivers need - base
> address and irq are very much insufficient to describe how this device is
> connected.  There's much more information required to specify this device
> fully, and throwing it into the driver doesn't work.  We've been there
> and proven that point.

The device tree is quite capable of expressing information beyond 
addresses and interrupts.

-Scott

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
> I'm not talking about platform specific code, I'm talking about code to
> retrieve information about a device from the device tree.  There would not
> be separate instances of this for "platforms X, Y and Z", just one
> of_platform binding in each driver.  It's no different than having a
> platform bus binding, except in the data structures used.
>
> But to restate, having external glue to create platform devices from the
> device tree is fine if that's what you want to do.  We used to do that, but
> it was a pain compared to keeping everything in one place.  Your experience
> may differ.

Could 'struct platform_device' and 'struct of_platform_device" be
unified into a single structure? It's personal preference whether the
internal representation of the hardware is done via a device tree or
snippets of platform code, but do we need to have to different device
types?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
> On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
> > I'm not talking about platform specific code, I'm talking about code to
> > retrieve information about a device from the device tree.  There would not
> > be separate instances of this for "platforms X, Y and Z", just one
> > of_platform binding in each driver.  It's no different than having a
> > platform bus binding, except in the data structures used.
> >
> > But to restate, having external glue to create platform devices from the
> > device tree is fine if that's what you want to do.  We used to do that, but
> > it was a pain compared to keeping everything in one place.  Your experience
> > may differ.
> 
> Could 'struct platform_device' and 'struct of_platform_device" be
> unified into a single structure? It's personal preference whether the
> internal representation of the hardware is done via a device tree or
> snippets of platform code, but do we need to have to different device
> types?

That's a damned good question - platform devices have been around since
the dawn of the device model, so the real question which needs to be
asked is: what was the reason that of_platform_device created rather
than unifying it with the already provided platform_device ?

BTW, I can find no such struct "of_platform_device" in include/linux.
Is it specific to each and every OF implementation?

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King]

On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
> Russell King wrote:
>> No one has brought that up on the ARM mailing lists - so does this issue
>> really exist?  All of the stuff I see on the ARM lists seems to be well
>> behaved and following our existing model - even vendor stuff (supplied
>> to me under NDA) seems to generally get this kind of stuff right.
>
> I'm just going by what I've seen on the u-boot list lately.  What is the  
> existing ARM Linux model for passing MAC addresses, so that we can point  
> people to that when they try to get u-boot to do silly things?

To program them into the hardware registers, which is not what we in
the ARM community say, but it's what the _network_ guys tell people
they should be doing.

I've suggested in the past having a standard kernel parameter such
that you can specify a mac address on a per-device basis in a totally
platform independent way, but the network folk don't like that idea.

>>> You can, if you want.  But you'll need extra glue code that 
>>> understands  the individual bindings.  IMHO that logic is usually 
>>> better off in the  driver itself, but if you really need platform 
>>> code to involve itself in  some way (such as providing callbacks), 
>>> then exceptions can be made.
>>
>> No it is not.  Device drivers are best written to support devices, and
>> the platform specific code should not be anywhere near them.  Platform
>> specific code to handle oddities of platforms should be totally separate
>> from the device driver itself.
>
> I'm not talking about platform specific code, I'm talking about code to  
> retrieve information about a device from the device tree.  There would  
> not be separate instances of this for "platforms X, Y and Z", just one  
> of_platform binding in each driver.  It's no different than having a  
> platform bus binding, except in the data structures used.

I really don't see what OF buys us then, apart from additional dependencies
that have to be correct for the kernel to work.  I can only see disadvantages
if all OF is, is a way to pass some file to the kernel to (effectively) tell
it which drivers to use.

>> smc91x is a prime example of the kind of information drivers need - base
>> address and irq are very much insufficient to describe how this device is
>> connected.  There's much more information required to specify this device
>> fully, and throwing it into the driver doesn't work.  We've been there
>> and proven that point.
>
> The device tree is quite capable of expressing information beyond  
> addresses and interrupts.

Bus width?  Register offset spacing?  SMC LED configuration?  Whether
to use the hardware wait signal from the SMC?

If you're going to say yes to all that, I'm going to start asking how
you cope with verifying that the data for ethernet driver A doesn't
get accidentally used for ethernet driver B.

I assume you have some kind of compiler, which needs a set of specification
files to tell it what's required for each driver which is OF compatible.
If not, I can see no way for OF trees to ever be safe and correct.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:21 Wed 27 May     , Russell King - ARM Linux wrote:
> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
> > On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
> > > I'm not talking about platform specific code, I'm talking about code to
> > > retrieve information about a device from the device tree.  There would not
> > > be separate instances of this for "platforms X, Y and Z", just one
> > > of_platform binding in each driver.  It's no different than having a
> > > platform bus binding, except in the data structures used.
> > >
> > > But to restate, having external glue to create platform devices from the
> > > device tree is fine if that's what you want to do.  We used to do that, but
> > > it was a pain compared to keeping everything in one place.  Your experience
> > > may differ.
> > 
> > Could 'struct platform_device' and 'struct of_platform_device" be
> > unified into a single structure? It's personal preference whether the
> > internal representation of the hardware is done via a device tree or
> > snippets of platform code, but do we need to have to different device
> > types?
> 
> That's a damned good question - platform devices have been around since
> the dawn of the device model, so the real question which needs to be
> asked is: what was the reason that of_platform_device created rather
> than unifying it with the already provided platform_device ?
I agree at 100%

when you have to support the same driver for non OF and OF platform it's
really a pain in the ass

Best Regards,
J.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Sergei Shtylyov]

Hello.

Russell King wrote:

>>>smc91x is a prime example of the kind of information drivers need - base
>>>address and irq are very much insufficient to describe how this device is
>>>connected.  There's much more information required to specify this device
>>>fully, and throwing it into the driver doesn't work.  We've been there
>>>and proven that point.

>>The device tree is quite capable of expressing information beyond  
>>addresses and interrupts.

> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?

    Yes, it's perefectly capable of all that. In fact, the first two items 
have already been defined for MTD and serial devices (though I wasn't happy 
about how the 2nd item was done IIRC).

> If you're going to say yes to all that, I'm going to start asking how
> you cope with verifying that the data for ethernet driver A doesn't
> get accidentally used for ethernet driver B.

    It's incorporated into the device node corresponding to Ethernet device 
A, which driver B doesn't drive.

> I assume you have some kind of compiler, which needs a set of specification
> files to tell it what's required for each driver which is OF compatible.

    The compiler is called (surprise :-) 'dtc'.

> If not, I can see no way for OF trees to ever be safe and correct.

WBR, Sergei

Re: [RFC] [PATCH] Device Tree on ARM platform

[Scott Wood]

Russell King wrote:
> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
>> Russell King wrote:
>>> No one has brought that up on the ARM mailing lists - so does this issue
>>> really exist?  All of the stuff I see on the ARM lists seems to be well
>>> behaved and following our existing model - even vendor stuff (supplied
>>> to me under NDA) seems to generally get this kind of stuff right.
>> I'm just going by what I've seen on the u-boot list lately.  What is the  
>> existing ARM Linux model for passing MAC addresses, so that we can point  
>> people to that when they try to get u-boot to do silly things?
> 
> To program them into the hardware registers, 

Isn't that adding a requirement to the boot firmware?  I thought you 
didn't like that? :-)

The patches that were proposed (and NACKed) in u-boot did exactly this 
-- except supposedly they would only set the MAC address if the 
interface were actually used prior to booting the kernel.

> which is not what we in the ARM community say, but it's what the
> _network_ guys tell people they should be doing.

They don't seem to be NACKing drivers that get it from the device tree 
instead.

> I've suggested in the past having a standard kernel parameter such
> that you can specify a mac address on a per-device basis in a totally
> platform independent way, but the network folk don't like that idea.

How do you reliably associate MAC addresses with specific devices that 
way?  The device tree can do this.

Think of the device tree as a really expressive kernel command line 
argument. :-)

>> I'm not talking about platform specific code, I'm talking about code to  
>> retrieve information about a device from the device tree.  There would  
>> not be separate instances of this for "platforms X, Y and Z", just one  
>> of_platform binding in each driver.  It's no different than having a  
>> platform bus binding, except in the data structures used.
> 
> I really don't see what OF buys us then,

The data is in a key/value format rather than a C struct, which makes it 
easier to pass from entities outside the kernel *if you want to*.

It is this distinction that led to the platfom/of_platform split -- we 
can't turn key/value into C structs without glue code that knows the 
specific device binding, and it's easier for the driver to access that 
data directly.

>> The device tree is quite capable of expressing information beyond  
>> addresses and interrupts.
> 
> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?
> 
> If you're going to say yes to all that,

Sure, you can add properties for that stuff.

> I'm going to start asking how
> you cope with verifying that the data for ethernet driver A doesn't
> get accidentally used for ethernet driver B.

Device nodes have "compatible" properties indicating what the hardware 
is compatible with.  A given driver only binds to nodes for hardware 
that is compatible with what it knows how to drive.

> I assume you have some kind of compiler, which needs a set of specification
> files to tell it what's required for each driver which is OF compatible.

Yes, there's a device tree compiler.  It doesn't know the details of 
individual device bindings, which is a little less safe than C structs, 
but not much.  There's nothing in theory preventing the compiler from 
being given this knowledge, and doing checks beyond what the C compiler 
can do.

> If not, I can see no way for OF trees to ever be safe and correct.

Code reviews and testing, same as how you get C code to be correct.

-Scott

Re: [RFC] [PATCH] Device Tree on ARM platform

[Timur Tabi]

Scott Wood wrote:
> The patches that were proposed (and NACKed) in u-boot did exactly this 
> -- except supposedly they would only set the MAC address if the 
> interface were actually used prior to booting the kernel.

How does a Linux driver normally get a MAC address if it's not passed via the device tree and it isn't already programmed in the hardware?  Is there some file in /etc that stores these things?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:53 Wed 27 May     , Scott Wood wrote:
> Russell King wrote:
>> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
>>> Russell King wrote:
>>>> No one has brought that up on the ARM mailing lists - so does this issue
>>>> really exist?  All of the stuff I see on the ARM lists seems to be well
>>>> behaved and following our existing model - even vendor stuff (supplied
>>>> to me under NDA) seems to generally get this kind of stuff right.
>>> I'm just going by what I've seen on the u-boot list lately.  What is 
>>> the  existing ARM Linux model for passing MAC addresses, so that we 
>>> can point  people to that when they try to get u-boot to do silly 
>>> things?
>>
>> To program them into the hardware registers, 
>
> Isn't that adding a requirement to the boot firmware?  I thought you  
> didn't like that? :-)
>
> The patches that were proposed (and NACKed) in u-boot did exactly this  
> -- except supposedly they would only set the MAC address if the  
> interface were actually used prior to booting the kernel.
The patch proposed was only set the mac address in the register independtly
if you use the interface or not. But it will require that you enable the
interface driver.

Best Regards,
J.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jean-Christophe PLAGNIOL-VILLARD]

> There are two issues that keep the of_platform and platform busses
> separate.  They aren't show stoppers, but they reflect the current
> state.
> 
> 1) Source of data: a platform_device carries a pdata structure with it
> to describe the hardware.  An of_device carries a device_node pointer.
>  Before dropping of_platform bus, a mechanism needs to be in place to
> add hooks for translating the device tree data into a pdata structure
> for each platform device.
> 
> 2) Driver binding mechanism:  device tree nodes usually have a
> "compatible" property which is a list of strings.  The first string
> describes exactly what the device is (ie. "atmel,24c08") and an
> optional list of other devices which it is register interface
> backwards compatible with.  The intent is that newer devices can claim
> compatibility with older ones so that existing device drivers will
> work without needing to be told the new device name.  However, it
> leaves the option when a device errata or something similar raises
> it's ugly head, a driver can still get information about the exact
> device name and apply the appropriate workarounds.  Driver probing
> should walk the list and give preference to higher priority compatible
> values.  of_platform bus does this, but I cannot think of a clean way
> to do the same thing with the platform bus.
> 
> One option that has been suggested (more than once) is to make the
> adapter code an of_platform_driver which translates the device tree
> data and then registers the appropriate platform_devices.  This neatly
> solves the problem, but I don't like the overhead involved in
> registering 2 struct devices with the kernel for every device node in
> the device tree.
but simplify the dev and maintaining is also an important goal.

Have to duplicated ressource handling via ifdef in every drivers is also an
overhead which need to be avoided

Best Regards,
J.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 1:39 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 20:21 Wed 27 May     , Russell King - ARM Linux wrote:
>> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
>> > On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
>> > > I'm not talking about platform specific code, I'm talking about code to
>> > > retrieve information about a device from the device tree.  There would not
>> > > be separate instances of this for "platforms X, Y and Z", just one
>> > > of_platform binding in each driver.  It's no different than having a
>> > > platform bus binding, except in the data structures used.
>> > >
>> > > But to restate, having external glue to create platform devices from the
>> > > device tree is fine if that's what you want to do.  We used to do that, but
>> > > it was a pain compared to keeping everything in one place.  Your experience
>> > > may differ.
>> >
>> > Could 'struct platform_device' and 'struct of_platform_device" be
>> > unified into a single structure? It's personal preference whether the
>> > internal representation of the hardware is done via a device tree or
>> > snippets of platform code, but do we need to have to different device
>> > types?
>>
>> That's a damned good question - platform devices have been around since
>> the dawn of the device model, so the real question which needs to be
>> asked is: what was the reason that of_platform_device created rather
>> than unifying it with the already provided platform_device ?
> I agree at 100%
>
> when you have to support the same driver for non OF and OF platform it's
> really a pain in the ass

There are two issues that keep the of_platform and platform busses
separate.  They aren't show stoppers, but they reflect the current
state.

1) Source of data: a platform_device carries a pdata structure with it
to describe the hardware.  An of_device carries a device_node pointer.
 Before dropping of_platform bus, a mechanism needs to be in place to
add hooks for translating the device tree data into a pdata structure
for each platform device.

2) Driver binding mechanism:  device tree nodes usually have a
"compatible" property which is a list of strings.  The first string
describes exactly what the device is (ie. "atmel,24c08") and an
optional list of other devices which it is register interface
backwards compatible with.  The intent is that newer devices can claim
compatibility with older ones so that existing device drivers will
work without needing to be told the new device name.  However, it
leaves the option when a device errata or something similar raises
it's ugly head, a driver can still get information about the exact
device name and apply the appropriate workarounds.  Driver probing
should walk the list and give preference to higher priority compatible
values.  of_platform bus does this, but I cannot think of a clean way
to do the same thing with the platform bus.

One option that has been suggested (more than once) is to make the
adapter code an of_platform_driver which translates the device tree
data and then registers the appropriate platform_devices.  This neatly
solves the problem, but I don't like the overhead involved in
registering 2 struct devices with the kernel for every device node in
the device tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Wed, 27 May 2009 20:29:10 +0100

> To program them into the hardware registers, which is not what we in
> the ARM community say, but it's what the _network_ guys tell people
> they should be doing.
> 
> I've suggested in the past having a standard kernel parameter such
> that you can specify a mac address on a per-device basis in a totally
> platform independent way, but the network folk don't like that idea.

As a "network guy" I can tell you that when the system firmware
provides a system-wide or device specific MAC address in it's device
tree, that is what you should use.

And that's what I've been doing on sparc FOR 15 YEARS.

Device trees are the only systematic generic mechanism for
describing device layouts on the myriad of embedded boards
out there which you will ever find.

Two platforms, and now a third, have been using this scheme
over a very proven period of time.  It's not a hack, there is
infrastructure to get the boot loaders to do the right thing,
and only ARM seems to resist it. :-)

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Timur Tabi <timur@freescale.com>
Date: Wed, 27 May 2009 14:54:14 -0500

> How does a Linux driver normally get a MAC address if it's not
> passed via the device tree and it isn't already programmed in the
> hardware?  Is there some file in /etc that stores these things?

It depends.  Some devices have EEPROM's that store the permanently
assigned MAC address, some have NVRAM for this, and yet other's put it
into the PCI ROM.

Some platforms that have real OF device trees often do not put the
permanent MAC address into the EEPROM or NVRAM even if it is
customary to do so on a particular device.  The MAC has to be
obtained from the OF device tree.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:23 Wed 27 May     , David Miller wrote:
> From: Russell King <rmk+lkml@arm.linux.org.uk>
> Date: Wed, 27 May 2009 20:29:10 +0100
> 
> > To program them into the hardware registers, which is not what we in
> > the ARM community say, but it's what the _network_ guys tell people
> > they should be doing.
> > 
> > I've suggested in the past having a standard kernel parameter such
> > that you can specify a mac address on a per-device basis in a totally
> > platform independent way, but the network folk don't like that idea.
> 
> As a "network guy" I can tell you that when the system firmware
> provides a system-wide or device specific MAC address in it's device
> tree, that is what you should use.
> 
> And that's what I've been doing on sparc FOR 15 YEARS.
> 
> Device trees are the only systematic generic mechanism for
> describing device layouts on the myriad of embedded boards
> out there which you will ever find.
> 
> Two platforms, and now a third, have been using this scheme
> over a very proven period of time.  It's not a hack, there is
> infrastructure to get the boot loaders to do the right thing,
> and only ARM seems to resist it. :-)
The SH, avr32, mips, x86 does not support it too IIRC

Best Regards,
J.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Timur Tabi]

David Miller wrote:

> It depends.  Some devices have EEPROM's that store the permanently
> assigned MAC address, some have NVRAM for this, and yet other's put it
> into the PCI ROM.

Well, I specifically said "isn't already programmed in the hardware".  I wasn't talking about just the NIC.  

> Some platforms that have real OF device trees often do not put the
> permanent MAC address into the EEPROM or NVRAM even if it is
> customary to do so on a particular device.  The MAC has to be
> obtained from the OF device tree.

Sorry, you're not answering my question.  I asked what do drivers do when the MAC address is not in the OF tree, and it is not programmed in hardware (any hardware).

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Wed, 27 May 2009 21:39:27 +0200

> when you have to support the same driver for non OF and OF platform it's
> really a pain in the ass

We could embed the platform_device object into the of_platform_device
structure, it's just an implementation issue.

But more to the point, I can tell you that anything platform_device
does can be implemented in terms of of_platform_device but the
opposite is not true.

Actually, I kind of appreciate the existence of both kinds of objects.
When you're instantiating LEDs or similar small devices on a MDIO
bus, and the LED driver has to work on OF and non-OF platforms,
I see nothing wrong with using platform devices for instantiation.
And I've done this myself for system LED devices on sparc64 boxes.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:28 Wed 27 May     , David Miller wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Date: Wed, 27 May 2009 21:39:27 +0200
> 
> > when you have to support the same driver for non OF and OF platform it's
> > really a pain in the ass
> 
> We could embed the platform_device object into the of_platform_device
> structure, it's just an implementation issue.
> 
> But more to the point, I can tell you that anything platform_device
> does can be implemented in terms of of_platform_device but the
> opposite is not true.
This is one of the problem I face not so long ago when I want to the boot
count limit functionnality which is only availlble for of platform

That's why I think having a simplest way to have driver availlable on the
twice platform is important. It will be a win-win at the end

Best Regards,
J.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 10:20 AM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
>> That being said, the problems we have had are the reason why it is
>> *not* recommended to hard link the device tree image into firmware.
>> We do commit to not breaking old trees, but the ability to update is
>> important; particularly for enabling new features/drivers.
>
> Point taken.
>
> We often have the situation that we have
>
> - a SoC cpu from vendor A
> - a module with the cpu+ram+peripherals from vendor B
> - a baseboard from vendor C
> - sometimes an extension board from vendor D
>
> All that with non-introspectable busses, like chip select busses, SPI,
> i2c, FPGA-internal busses etc. We recently tried to put oftree sniplets
> into the devices (one into the module, one in the baseboard etc), let
> u-boot collect these sniplets and build an oftree out of it. It doesn't
> work. If you try this, you'll quickly find out that you would have to
> put the schematics into the oftree. A peripheral pin can be routed to a
> ball, goes from a connector of the module to a baseboard, to the
> extension board, come back and go to another unit on the SoC. This
> cannot be described in the oftree. At one place, you need to *know*
> about the whole hardware that you have and have a single "we have X" to
> "X's oftree" mapping.

Indeed, and it relies on encoding too much knowledge into the
firmware... code which may change.

> In the end, having a single "X needs these platform data" kernel source
> file is much, much cleaner and less error prone than what we currently
> have with the oftree.

What about a single device tree blob for each particular
configuration?  The .dtb isn't intended to solve the probing problem.
It's intended to solve the problem of describing your board design (or
board stack in your case).

>> > - The oftree layering is fundamentally broken. We already have a sane
>> >  abstraction for arbitrary hardware in the kernel: platform devices.
>> >  Why not instanciate platform devices from a generic oftree core?
>>
>> No; the oftree is a data structure. That is it, nothing more.
>
> Unfortunately, it is an incomplete data structure regarding to what the
> kernel needs.

I don't follow your argument.  It's a data structure that uniquely
describes your hardware in a way which encourages the most code reuse
possible; but is still independent of kernel internal implementation.
ie. a FDT blob should be usable not just by Linux, but also by BSD or
any of the other OS options.  It is not an attempt to eliminate
platform specific code; just to reduce it as much as possible.  Weird,
harry, non-standard stuff probably still needs board specific code to
handle.

>> > - Platform data makes it possible to store function pointers. There
>> >  is no equivalent to this concept in oftree-land.
>>
>> But there is concept of platform specific code. In the majority of
>> cases platform specific function pointers aren't needed at all. In
>> the cases where they are; platform devices can still be used.
>
> In this case, they need an equivalent to a "machine number" information.

Yes.  In the device tree we've been using the root node's compatible
or model property.

>> > oftree could be a great tool if these things would be resolved.
>> > Currently they are not, and in result, ARM just works and is easy,
>> > whereas on PowerPC systems people often spend more time working on
>> > binding stuff than on the actual functionality.
>>
>> That's a rather polarizing statement and I don't think its fair. The
>> FDT is not a magic bullet. It makes aspects of platform independence,
>> code sharing, and board porting simpler, but it is also requires
>> forethought and has overhead associated with it. I don't think anyone
>> is proposing to require all ARM platforms to use the FDT approach.
>
> Sorry, it was not meant to be offending, it just reflects a certain
> level of frustration.
>
> Don't take me wrong: I consider the *idea* behind oftree a good one. It
> just has unsolved problems. If we manage to turn this discussion into
> something that accelerates things into a good direction, I'm all with
> you.

:-)

Understood.  So far I think things are going well, at least nobody has
yet suggested doing something biologically improbable.  :-P

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[M. Warner Losh]

In message: <20090527.132553.40558501.davem@davemloft.net>
            David Miller <davem@davemloft.net> writes:
: From: Timur Tabi <timur@freescale.com>
: Date: Wed, 27 May 2009 14:54:14 -0500
: 
: > How does a Linux driver normally get a MAC address if it's not
: > passed via the device tree and it isn't already programmed in the
: > hardware?  Is there some file in /etc that stores these things?
: 
: It depends.  Some devices have EEPROM's that store the permanently
: assigned MAC address, some have NVRAM for this, and yet other's put it
: into the PCI ROM.

Some also put it into their CIS for things like PC Card, CardBus and
SDIO too.  It is the definition of device specific :).

: Some platforms that have real OF device trees often do not put the
: permanent MAC address into the EEPROM or NVRAM even if it is
: customary to do so on a particular device.  The MAC has to be
: obtained from the OF device tree.

This is but one of many ways to get it...

Warner

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 10:32 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 05:05:27PM +0200, Robert Schwebel wrote:
>
>> I'm highly convinced that the existence of oftree-hell in ARM-land would
>> have been *the* key motivation for FSL to have worked on mainline
>> instead of inhouse-BSPs back in 2004 when we mainlined i.MX1 and in 2007
>> when we started the mainline work on MX27 and MX31.
>
> I remain to be convinced about that but anyway..
>
>> Seriously: oftree in general is a good idea. Just that it doesn't work
>> in practise. The concept has some serious flaws:
>
>> - Platform data makes it possible to store function pointers. There
>>   is no equivalent to this concept in oftree-land.
>
> The handling of platform data is my main concern as someone working
> primarily on platform independant drivers - function pointers are a
> particular problem but the possibility of having to write code to
> handle both OF and non-OF systems to cater for systems using both
> approaches is also a concern for me.

Having a hook function which generates a pdata structure from a device
node on a per driver basis is a common approach.  Essentially, the
hook becomes an addon to the driver which doesn't impact the driver as
a whole.  i2c and SPI device tend to take this approach.

The other common pattern, usually used on platform drivers, is to
factor out the common code and use 2 separate bus binding blocks; one
for platform and one for of_platform.  It has some (low) impact on
driver structure, but not everyone likes this approach.

>> oftree could be a great tool if these things would be resolved.
>> Currently they are not, and in result, ARM just works and is easy,
>> whereas on PowerPC systems people often spend more time working on
>> binding stuff than on the actual functionality.
>
> This worries me too, my experiences with OF device tree handling for
> ASoC have been pretty negative - but then audio is one of the worst
> cases for handling within the device tree.

First steps are hard.  I2C and SPI work had similar groans and pains,
and ASoC is considerably more complex.  In the end the stuff in
drivers/of/* was added to handle the creation of i2c, spi and phy
devices from data in the device tree.  It is a mechanism which seems
to be working well.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 11:56 AM, Russell King
<rmk+lkml@arm.linux.org.uk> wrote:
> So, repeat this mantra: device drivers should contain no platform specifics.
> Platform specifics should be separated from the driver and implemented by
> platform support code.

/me suspects we are having a violent agreement on this point.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 12:56 PM, Alexander Clouter <alex@digriz.org.uk> wrote:
> In gmane.linux.kernel Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
>> <r.schwebel@pengutronix.de> wrote:
>>> Seriously: oftree in general is a good idea. Just that it doesn't work
>>> in practise. The concept has some serious flaws:
>>>
>>> - The whole concept is based on the assumption that bindings are defined
>>>  *once*, then never to be changed again. As this is not true (check
>>>  MPC5200 to find out what I mean), oftree wreckage is *the* main cause
>>>  of new kernels not working on old bootloaders any more. Is there a
>>>  solution of this problem? I have not seen a good idea how to avoid the
>>>  constant change in definitions.
>>
>> This is a MPC5200 is the posterchild for device tree wreckage; mostly
>> because of my own inexperience at the time.  A lot of mistakes were
>> made and I freely admit that.
>>
>> However, my counter example is Xilinx Virtex support.  The Virtex is
>> an FPGA with all the devices instantiated in the FPGA fabric.  It
>> would be a nightmare to try and describe each different FPGA bitstream
>> using hand coded platform devices, and the xparameters.h file exported
>> by the Xilinx toolchain wasn't much better.  Encoding the machine
>> layout in a data structure (the device tree) has decoupled FPGA
>> changes from the kernel image.  Now FPGA engineers can make major
>> changes to FPGA layouts without having to lockstep with changes in the
>> kernel.  I regularly boot a single kernel image on multiple bitstream
>> images.
>>
>> That being said, the problems we have had are the reason why it is
>> *not* recommended to hard link the device tree image into firmware.
>> We do commit to not breaking old trees, but the ability to update is
>> important; particularly for enabling new features/drivers.
>>
> Although I have no input of value here, I'm hoping I do not become the
> next posterchild for "pain++".
>
> I'm working through redo'ing the FPGA support in the TS-7800[1] into a
> new bus rather than just continuing the messy direction I have been
> going to date[2].
>
> My current approach is that the bus handles the 'hotplug'ing of the FPGA
> bitstream by unregistering all the devices and then when it's informed
> the new bitstream is ready it prods all the registered drivers if any
> devices need bringing up (obviously drivers can be modprobe'd as and
> when).
>
> The 'magic' is that the FPGA code has some special value[3] that what it
> is and the drivers (outside the platform code) have a list of FPGA magic
> values (with a mask) that they are willing to service.  The *bus*
> (platform code) is what installs the devices effectively and only does
> so if the loaded driver says it can drive a particular loaded bitstream
> (in the bus driver struct is a array of ID's it checks).
>
> Does this sound sane?  Is it an approach that could be ACKed one day?
> Currently the bit that might be considered sinful is there is for some
> of the drivers (rtc-m48t86, timeriomem-rng and plat_nand) the FPGA bus
> 'driver' is a light wrapper around the platform device driver.  This is
> so that the hooks still exist so the bus know what to load and unload as
> and when.

Personally, I'd not write a separate bus.  I'd write a platform driver
which turns around and registers more platform devices with the
original device as the parent in the _probe routine, and unregisters
them in _remove.  Should have the same affect with less complex code.
However, someone with more device-model-foo may have better advice.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Josh Boyer]

On Wed, May 27, 2009 at 10:27:01PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>On 13:23 Wed 27 May     , David Miller wrote:
>> From: Russell King <rmk+lkml@arm.linux.org.uk>
>> Date: Wed, 27 May 2009 20:29:10 +0100
>> 
>> > To program them into the hardware registers, which is not what we in
>> > the ARM community say, but it's what the _network_ guys tell people
>> > they should be doing.
>> > 
>> > I've suggested in the past having a standard kernel parameter such
>> > that you can specify a mac address on a per-device basis in a totally
>> > platform independent way, but the network folk don't like that idea.
>> 
>> As a "network guy" I can tell you that when the system firmware
>> provides a system-wide or device specific MAC address in it's device
>> tree, that is what you should use.
>> 
>> And that's what I've been doing on sparc FOR 15 YEARS.
>> 
>> Device trees are the only systematic generic mechanism for
>> describing device layouts on the myriad of embedded boards
>> out there which you will ever find.
>> 
>> Two platforms, and now a third, have been using this scheme
>> over a very proven period of time.  It's not a hack, there is
>> infrastructure to get the boot loaders to do the right thing,
>> and only ARM seems to resist it. :-)
>The SH, avr32, mips, x86 does not support it too IIRC

x86 has a variant.  The OLPC uses OF.

josh

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:

> > I'm not talking about platform specific code, I'm talking about code to  
> > retrieve information about a device from the device tree.  There would  
> > not be separate instances of this for "platforms X, Y and Z", just one  
> > of_platform binding in each driver.  It's no different than having a  
> > platform bus binding, except in the data structures used.

> I really don't see what OF buys us then, apart from additional dependencies
> that have to be correct for the kernel to work.  I can only see disadvantages
> if all OF is, is a way to pass some file to the kernel to (effectively) tell
> it which drivers to use.

The main selling points of the device tree AFAICT are that some
platforms have to use it it anyway due to the native OS and firmware for
the platform use it, the possibility of using the same device tree with
more than one OS (modulo unrepresentable holes) and the fact that some
people find it more convenient to use than straight data tables
(personally I find the two approaches to be much of a muchness there).
Perhaps I'm missing something, though?

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 2:19 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
>> One option that has been suggested (more than once) is to make the
>> adapter code an of_platform_driver which translates the device tree
>> data and then registers the appropriate platform_devices.  This neatly
>> solves the problem, but I don't like the overhead involved in
>> registering 2 struct devices with the kernel for every device node in
>> the device tree.
> but simplify the dev and maintaining is also an important goal.
>
> Have to duplicated ressource handling via ifdef in every drivers is also an
> overhead which need to be avoided

agreed.  I don't have a best of both worlds answer here.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Timur Tabi <timur@freescale.com>
Date: Wed, 27 May 2009 15:27:57 -0500

> I asked what do drivers do when the MAC address is not in the OF
> tree, and it is not programmed in hardware (any hardware).

They either fail to probe the device or use a random MAC address,
the later of which is severely frowned upon.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Wed, 27 May 2009 22:27:01 +0200

> The SH, avr32, mips, x86 does not support it too IIRC

Actually x86 does support OF, via real OF firmware in fact :-)

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 2:52 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
>> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
>
>> > I'm not talking about platform specific code, I'm talking about code to
>> > retrieve information about a device from the device tree.  There would
>> > not be separate instances of this for "platforms X, Y and Z", just one
>> > of_platform binding in each driver.  It's no different than having a
>> > platform bus binding, except in the data structures used.
>
>> I really don't see what OF buys us then, apart from additional dependencies
>> that have to be correct for the kernel to work.  I can only see disadvantages
>> if all OF is, is a way to pass some file to the kernel to (effectively) tell
>> it which drivers to use.
>
> The main selling points of the device tree AFAICT are that some
> platforms have to use it it anyway due to the native OS and firmware for
> the platform use it, the possibility of using the same device tree with
> more than one OS (modulo unrepresentable holes) and the fact that some
> people find it more convenient to use than straight data tables
> (personally I find the two approaches to be much of a muchness there).
> Perhaps I'm missing something, though?

Here are some that I've find useful:

There is the advantage that it decouples the machine description from
the kernel code, which in turn seems to encourage code reuse.  There
has been a significant decrease in the amount of platform specific
code in powerpc since the switch to FDT booting.

There is the advantage of easy multiplatform support.  I regularly
build a single kernel image which boots on all my MPC5200 boards, and
on my MPC83xx boards.  Because the machine description is a separate
image blob, and not hard compiled into the kernel, the kernel doesn't
have to be explicitly told what boards it may possibly be booted on
(other than turning on the appropriate drivers; handled with modules,
just like on x86).  It may not be much of an advantage for current
deployed systems, but it is a huge win during development and
testing....

That being said, I've been told that Motorola has shipped phones with
FDT support in the kernel for exactly the reason of booting a single
kernel image on multiple versions of the device.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Alexander Clouter]

In gmane.linux.kernel Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, May 27, 2009 at 12:56 PM, Alexander Clouter <alex@digriz.org.uk> wrote:
>> In gmane.linux.kernel Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
>>>
>>> [snipped]
>>>
>> Although I have no input of value here, I'm hoping I do not become the
>> next posterchild for "pain++".
>>
>> I'm working through redo'ing the FPGA support in the TS-7800[1] into a
>> new bus rather than just continuing the messy direction I have been
>> going to date[2].
>>
>> My current approach is that the bus handles the 'hotplug'ing of the FPGA
>> bitstream by unregistering all the devices and then when it's informed
>> the new bitstream is ready it prods all the registered drivers if any
>> devices need bringing up (obviously drivers can be modprobe'd as and
>> when).
>>
>> The 'magic' is that the FPGA code has some special value[3] that what it
>> is and the drivers (outside the platform code) have a list of FPGA magic
>> values (with a mask) that they are willing to service.  The *bus*
>> (platform code) is what installs the devices effectively and only does
>> so if the loaded driver says it can drive a particular loaded bitstream
>> (in the bus driver struct is a array of ID's it checks).
>>
>> Does this sound sane?  Is it an approach that could be ACKed one day?
>> Currently the bit that might be considered sinful is there is for some
>> of the drivers (rtc-m48t86, timeriomem-rng and plat_nand) the FPGA bus
>> 'driver' is a light wrapper around the platform device driver.  This is
>> so that the hooks still exist so the bus know what to load and unload as
>> and when.
> 
> Personally, I'd not write a separate bus.  I'd write a platform driver
> which turns around and registers more platform devices with the
> original device as the parent in the _probe routine, and unregisters
> them in _remove.  Should have the same affect with less complex code.
> However, someone with more device-model-foo may have better advice.
> 
That's a thought, but this 'bus' does not just drive platform devices, 
there are other drivers that will live outside the scope.

I have a half completed GPIO expander for the 'factory' FPGA bitstream 
that could not be done as a platform device.  The GPIO pin's also 
multiplex as an ISA (PC/104) bus and chip select's a SPI bus too.

Another driver is a DMA engine provisioned by the factory bitstream too 
as well as AVR+ADC+watchdog system too.

What would make sense for this approach would be if it was to drive 
bit's from the opencores.org website.

Because there is a mix of platform devices and 'awkward' bit's, this is 
why I was thinking about a seperate bus.

Cheers for the suggestion, it's got me thinkingthat there still has to 
be a better way :)

Cheers

-- 
Alexander Clouter
.sigmonster says: Who goeth a-borrowing goeth a-sorrowing.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Wed, May 27, 2009 at 02:42:13PM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 10:32 AM, Mark Brown

> > The handling of platform data is my main concern as someone working
> > primarily on platform independant drivers - function pointers are a
> > particular problem but the possibility of having to write code to
> > handle both OF and non-OF systems to cater for systems using both
> > approaches is also a concern for me.

> Having a hook function which generates a pdata structure from a device
> node on a per driver basis is a common approach.  Essentially, the
> hook becomes an addon to the driver which doesn't impact the driver as
> a whole.  i2c and SPI device tend to take this approach.

Yes, this is what I mean about doing it twice - you have to have the
regular platform data structure plus another function to map the
OpenFirmware data into it.  The fact that quite a few of the devices I
deal with want function pointers as platform data doesn't help here.

> > This worries me too, my experiences with OF device tree handling for
> > ASoC have been pretty negative - but then audio is one of the worst
> > cases for handling within the device tree.

> First steps are hard.  I2C and SPI work had similar groans and pains,
> and ASoC is considerably more complex.  In the end the stuff in
> drivers/of/* was added to handle the creation of i2c, spi and phy
> devices from data in the device tree.  It is a mechanism which seems
> to be working well.

Instantiating the devices is a solved problem - with the current code
you can load the drivers for all the various parts of the audio
subsystem via the standard device model with everything appearing on
whatever bus it normally should.  The only exception to that is AC97
(because it's a bit special and needs some general TLC).  Some more work
is needed on the core to fully take advantage of what this bought us but
as far as loading and initialising device drivers goes you should be
there already.

What's a really crippling problem for what people seem to want to do
with the device tree right now is expressing the clocking trees and
requirements for a non-trivial audio subsystem.  The current clock API
is quite a way off being able to cope with this at runtime and without
that the benefits of trying to put the data into device trees are
questionable - a plaform independant representation of this data most
likely needs us to be able to automatically configure the clock tree
based on a description of the interconnects and their constraints.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mitch Bradley]

If anybody is interested, the core ARM support has been added to the 
Open Firmware tree at svn://openfirmware.info/openfirmware - the same 
version of OFW that's used on OLPC - under an MIT-style license. This is 
a full-featured Open Firmware whose lineage traces back to the original 
Open Boot implementation that I wrote for Sun starting in 1987.

It's not yet fully elaborated for specific platforms and devices, but it 
does contain all the core IEE1275 device tree stuff and the standard 
support packages.  It gets you to an ok prompt on Beagle Board and 
Gumstix Overo systems.  The source-level and assembly-language debuggers 
are fully functional. As currently configured on those systems, you can 
load it into memory either via u-boot or instead of u-boot.

This base ARM port, while newly released as FOSS, is quite solid, having 
been developed some years ago for the Digital (RIP) DNARD system.

I'd be happy to work with people to add deeper support for specific 
device and platforms.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Wed, May 27, 2009 at 02:50:27PM -0400, Jon Smirl wrote:
> On Wed, May 27, 2009 at 12:32 PM, Mark Brown

> > This worries me too, my experiences with OF device tree handling for
> > ASoC have been pretty negative - but then audio is one of the worst
> > cases for handling within the device tree.

> ASoC is where I2C was a year ago. I2C had it's own module loading
> conventions. OF assumes the subsystem is going to follow the standard
> kernel module loading conventions. I2C has now been fixed to use the
> standard conventions and it happily works with OF now.

As I just said to Grant this is not the case any more, unless you are
using AC97.  You can instantiate all the component drivers for an ASoC
card via the normal device model methods, the overwhelming majority of
my ASoC work is done on systems that do exactly this.

> The fight with ASoC is that two different entities are trying to link
> the modules together - ASoC (machine drivers) and the device tree
> code. There should only be one system linking everything together.

That's not the fundamental problem that machine drivers solve, though
they do the basic tab A into slot B stuff too.  The biggest problem that
machine drivers solve is that they allow us to set up the clocks used in
the audio subsystem in a way that is appropriate for the system based on
how it's wired up and what it's supposed to do.  As I just said to Grant
any OS neutral expression of this configuration suitable for use in a
device tree would need to be able to provide some constraints and a wiring
diagram.  These would then be used together with constraints from the
current runtime configuration to calculate an actual clock configuration
for the system.

If we had a cross-platform clock framework which was capable of handling
this then producing a generic machine driver would be more tractable but
there's no visible prospect of that happening any time soon.

Please read back over the original soc-of-simple thread, it goes into
the problems in a bit more detail.

> But you want these ASoC machine drivers on ARM because ARM doesn't
> have device trees.

This is nothing to do with the device trees, as I believe I've mentioned
before the existing ARM equivalents of the device tree are exactly
equivalent to it for device loading as far as things outside arch/arm
are concerned.

> I2C had the same problem. I2C wanted everything loaded form machine
> drivers. The machine drivers are now optional. ASoC can be fixed in
> the same way.

It's very easy to say things like this but there's quite a way to go
before they can be delivered upon; if it were straightforward to handle
I'd expect that soc-of-simple would be able to cope with it.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Wed, May 27, 2009 at 01:55:00PM -0700, David Miller wrote:
> > I asked what do drivers do when the MAC address is not in the OF
> > tree, and it is not programmed in hardware (any hardware).
>
> They either fail to probe the device or use a random MAC address,
> the later of which is severely frowned upon.

For embedded, having no dedicated eeprom for the MAC address but
defining them from the bootloader's configuration space is the standard
use case.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Wed, May 27, 2009 at 02:35:11PM -0600, Grant Likely wrote:
> > Unfortunately, it is an incomplete data structure regarding to what
> > the kernel needs.
>
> I don't follow your argument. It's a data structure that uniquely
> describes your hardware in a way which encourages the most code reuse
> possible; but is still independent of kernel internal implementation.
> ie. a FDT blob should be usable not just by Linux, but also by BSD or
> any of the other OS options. It is not an attempt to eliminate
> platform specific code; just to reduce it as much as possible. Weird,
> harry, non-standard stuff probably still needs board specific code to
> handle.

The oftree by design wants to be a complete hardware description. As you
mention above, there are cases where you *nevertheless* need ad-hoc
information about things *not* encoded into the device tree.

This renders the whole concept ad absurdum. You need a machine number
again - and if you need that: why not stay with the ARM model, define
everything with platform data and avoid the whole thing?

Regarding the multi OS argument: I consider it impossible that people
agree on all micro details of a hardware decision. Will it really be
possible to get a common agreement about let's say Russell's SMSC
example between all these people? Remember: if we forget (or don't agree
on) one single aspect which a driver developer *needs*, he will have to
work around it -> machine number land.

My impression is that oftree only works in a perfect world. But we don't
have one, so the fundamental design decision is broken.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Robert Schwebel <r.schwebel@pengutronix.de>
Date: Thu, 28 May 2009 01:48:01 +0200

> My impression is that oftree only works in a perfect world. But we
> don't have one, so the fundamental design decision is broken.

It is imperfect, that's why it all determined by software we
control and thus we can fix.  _THAT_ is the whole point.

Bringing up SMSC over and over again is just a scarecrow.  So
one driver went insanely bad and if an ifdef platform specific
hacks nightmare, big deal.

That has no bearing on whether OF device trees constructed by
bootloader software or onboard firmware is a good idea or not.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Wed, May 27, 2009 at 02:22:50PM -0600, Grant Likely wrote:
> 2) Driver binding mechanism:  device tree nodes usually have a
> "compatible" property which is a list of strings. The first string
> describes exactly what the device is (ie. "atmel,24c08") and an
> optional list of other devices which it is register interface
> backwards compatible with.

This is a good example. The "exact" description above doesn't say
anything about some of the details the driver needs to know. Here is the
at24 driver:

http://lxr.linux.no/linux+v2.6.29/include/linux/i2c/at24.h#L18

Where do we get the page size & flags from?

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Scott Wood]

Robert Schwebel wrote:
> The oftree by design wants to be a complete hardware description. As you
> mention above, there are cases where you *nevertheless* need ad-hoc
> information about things *not* encoded into the device tree.
> 
> This renders the whole concept ad absurdum. You need a machine number
> again - and if you need that: why not stay with the ARM model, define
> everything with platform data and avoid the whole thing?

Because it's better to have a little platform specific code than a lot 
of it?

-Scott

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Robert Schwebel <r.schwebel@pengutronix.de>
Date: Thu, 28 May 2009 01:57:05 +0200

> On Wed, May 27, 2009 at 02:22:50PM -0600, Grant Likely wrote:
>> 2) Driver binding mechanism:  device tree nodes usually have a
>> "compatible" property which is a list of strings. The first string
>> describes exactly what the device is (ie. "atmel,24c08") and an
>> optional list of other devices which it is register interface
>> backwards compatible with.
> 
> This is a good example. The "exact" description above doesn't say
> anything about some of the details the driver needs to know. Here is the
> at24 driver:
> 
> http://lxr.linux.no/linux+v2.6.29/include/linux/i2c/at24.h#L18
> 
> Where do we get the page size & flags from?

You can use device node properties.

Every device node has mode than just a "name" and "compatible"
property.  You can add arbitrary properties, which are simply name -->
value pairs.  The type of the value is opaque, it can be any arbitrary
binary data, a string, a 32-bit integer, a MAC address, etc.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Scott Wood <scottwood@freescale.com>
Date: Wed, 27 May 2009 18:58:24 -0500

> Because it's better to have a little platform specific code than a lot
> of it?

Judging by some of the questions I see popping up over and over again,
I suspect that many people resisting OF device trees lack much of an
understanding of what they provide and can do.

Questions like "How do we determine attribute X of a given device" has
an obvious answer if you understand device node properties and that
you can encode arbitrary things into them to provide arbitrary bits of
information on a per-device-instance basis.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Wed, May 27, 2009 at 6:24 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 02:50:27PM -0400, Jon Smirl wrote:
>> On Wed, May 27, 2009 at 12:32 PM, Mark Brown
>
>> > This worries me too, my experiences with OF device tree handling for
>> > ASoC have been pretty negative - but then audio is one of the worst
>> > cases for handling within the device tree.
>
>> ASoC is where I2C was a year ago. I2C had it's own module loading
>> conventions. OF assumes the subsystem is going to follow the standard
>> kernel module loading conventions. I2C has now been fixed to use the
>> standard conventions and it happily works with OF now.
>
> As I just said to Grant this is not the case any more, unless you are
> using AC97.  You can instantiate all the component drivers for an ASoC
> card via the normal device model methods, the overwhelming majority of
> my ASoC work is done on systems that do exactly this.
>
>> The fight with ASoC is that two different entities are trying to link
>> the modules together - ASoC (machine drivers) and the device tree
>> code. There should only be one system linking everything together.
>
> That's not the fundamental problem that machine drivers solve, though
> they do the basic tab A into slot B stuff too.  The biggest problem that
> machine drivers solve is that they allow us to set up the clocks used in
> the audio subsystem in a way that is appropriate for the system based on
> how it's wired up and what it's supposed to do.  As I just said to Grant
> any OS neutral expression of this configuration suitable for use in a
> device tree would need to be able to provide some constraints and a wiring
> diagram.  These would then be used together with constraints from the
> current runtime configuration to calculate an actual clock configuration
> for the system.
>
> If we had a cross-platform clock framework which was capable of handling
> this then producing a generic machine driver would be more tractable but
> there's no visible prospect of that happening any time soon.
>
> Please read back over the original soc-of-simple thread, it goes into
> the problems in a bit more detail.
>
>> But you want these ASoC machine drivers on ARM because ARM doesn't
>> have device trees.
>
> This is nothing to do with the device trees, as I believe I've mentioned
> before the existing ARM equivalents of the device tree are exactly
> equivalent to it for device loading as far as things outside arch/arm
> are concerned.
>
>> I2C had the same problem. I2C wanted everything loaded form machine
>> drivers. The machine drivers are now optional. ASoC can be fixed in
>> the same way.
>
> It's very easy to say things like this but there's quite a way to go
> before they can be delivered upon; if it were straightforward to handle
> I'd expect that soc-of-simple would be able to cope with it.
>

It's an evolutionary process, let's get ASoC loading all of the right
modules first. Then we can move on to clocking, etc. I2C went through
the same process.  For example, the new efika-audio-fabric and
pcm030-audio-fabric files should not be needed once the binding
process is fully working. Next up we can try and simlify
mpc8610_hpcd.c.

When I disabled soc-of-simple that stop the autoloading of codecs on
i2s. That needs to be fixed. Next kernel cycle I will be working on
mpc5200 i2s.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Wed, May 27, 2009 at 06:58:24PM -0500, Scott Wood wrote:
> Robert Schwebel wrote:
>> The oftree by design wants to be a complete hardware description. As
>> you mention above, there are cases where you *nevertheless* need
>> ad-hoc information about things *not* encoded into the device tree.
>>
>> This renders the whole concept ad absurdum. You need a machine number
>> again - and if you need that: why not stay with the ARM model, define
>> everything with platform data and avoid the whole thing?
>
> Because it's better to have a little platform specific code than a lot
> of it?

Until now, oftree has created more problems than it has solved for us.
The idea works fine for well-known things like memory maps and
interrupts. It works badly for corner cases, and embedded land is full
of it. The effort to get the oftree stuff right is often more than a
magnitude of order higher than the effort for the actual functionality.
That should be an alarm sign that something is wrong.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Wed, May 27, 2009 at 5:05 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, May 27, 2009 at 2:52 PM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>> On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
>>> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
>>
>>> > I'm not talking about platform specific code, I'm talking about code to
>>> > retrieve information about a device from the device tree.  There would
>>> > not be separate instances of this for "platforms X, Y and Z", just one
>>> > of_platform binding in each driver.  It's no different than having a
>>> > platform bus binding, except in the data structures used.
>>
>>> I really don't see what OF buys us then, apart from additional dependencies
>>> that have to be correct for the kernel to work.  I can only see disadvantages
>>> if all OF is, is a way to pass some file to the kernel to (effectively) tell
>>> it which drivers to use.
>>
>> The main selling points of the device tree AFAICT are that some
>> platforms have to use it it anyway due to the native OS and firmware for
>> the platform use it, the possibility of using the same device tree with
>> more than one OS (modulo unrepresentable holes) and the fact that some
>> people find it more convenient to use than straight data tables
>> (personally I find the two approaches to be much of a muchness there).
>> Perhaps I'm missing something, though?
>
> Here are some that I've find useful:
>
> There is the advantage that it decouples the machine description from
> the kernel code, which in turn seems to encourage code reuse.  There
> has been a significant decrease in the amount of platform specific
> code in powerpc since the switch to FDT booting.

I agree with this. I have observed the same thing.

>
> There is the advantage of easy multiplatform support.  I regularly
> build a single kernel image which boots on all my MPC5200 boards, and
> on my MPC83xx boards.  Because the machine description is a separate
> image blob, and not hard compiled into the kernel, the kernel doesn't
> have to be explicitly told what boards it may possibly be booted on
> (other than turning on the appropriate drivers; handled with modules,
> just like on x86).  It may not be much of an advantage for current
> deployed systems, but it is a huge win during development and
> testing....

I am routinely booting four different mpc5200 systems off from the
same NFS tree and the same kernel image. These four mpc5200 system
have quite different capabilities. There are different audio codecs,
PCI/no-PCI, ATA/no-ATA, SD cards, RAM, flash (some 8b others 16b),
they don't even have the console on the same serial port. I build a
single kernel and test it on all four of these systems. The device
tree customizes each kernel at boot time to support the right
hardware.

We want to use this capability in the field. A single update can
services multiple versions of the hardware.

> That being said, I've been told that Motorola has shipped phones with
> FDT support in the kernel for exactly the reason of booting a single
> kernel image on multiple versions of the device.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Robert Schwebel <r.schwebel@pengutronix.de>
Date: Thu, 28 May 2009 02:07:07 +0200

> Until now, oftree has created more problems than it has solved for us.
> The idea works fine for well-known things like memory maps and
> interrupts.

Here you give a specific example about the positives.

> It works badly for corner cases, and embedded land is full
> of it. The effort to get the oftree stuff right is often more than a
> magnitude of order higher than the effort for the actual functionality.
> That should be an alarm sign that something is wrong.

And here you speak about the negatives purely in generalities that
cannot be discussed concretely.

And, sadly, I think this is on purpose.

RE: [RFC] [PATCH] Device Tree on ARM platform

[Stephen Neuendorffer]

> -----Original Message-----
> From:
devicetree-discuss-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org
[mailto:devicetree-
> discuss-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org] On Behalf
Of Robert Schwebel
> Sent: Wednesday, May 27, 2009 9:20 AM
> To: grant.likely@secretlab.ca
> Cc: devicetree-discuss; linux-kernel@vger.kernel.org;
linux-arm-kernel@lists.arm.linux.org.uk; Janboe
> Ye; Timur Tabi; rmk@arm.linux.org.uk
> Subject: Re: [RFC] [PATCH] Device Tree on ARM platform
> 
> Hi Grant,
> 
> On Wed, May 27, 2009 at 09:39:21AM -0600, Grant Likely wrote:
> > This is a MPC5200 is the posterchild for device tree wreckage;
mostly
> > because of my own inexperience at the time.  A lot of mistakes were
> > made and I freely admit that.
> >
> > However, my counter example is Xilinx Virtex support. The Virtex is
an
> > FPGA with all the devices instantiated in the FPGA fabric. It would
> > be a nightmare to try and describe each different FPGA bitstream
using
> > hand coded platform devices, and the xparameters.h file exported by
> > the Xilinx toolchain wasn't much better. Encoding the machine layout
> > in a data structure (the device tree) has decoupled FPGA changes
from
> > the kernel image. Now FPGA engineers can make major changes to FPGA
> > layouts without having to lockstep with changes in the kernel. I
> > regularly boot a single kernel image on multiple bitstream images.
> >
> > That being said, the problems we have had are the reason why it is
> > *not* recommended to hard link the device tree image into firmware.
> > We do commit to not breaking old trees, but the ability to update is
> > important; particularly for enabling new features/drivers.
> 
> Point taken.
> 
> We often have the situation that we have
> 
> - a SoC cpu from vendor A
> - a module with the cpu+ram+peripherals from vendor B
> - a baseboard from vendor C
> - sometimes an extension board from vendor D

I completely agree...  Generally speaking, this is a huge problem for
Microblaze/Virtex PPC support, since very little about the board
connectivity is implied or required based on the chip itself.
Hence, describing the board-level connectivity becomes imperative.  More
importantly, describing the
board-level connectivity separately from the FPGA internal connectivity
is also important from
an information management perspective.
 
> All that with non-introspectable busses, like chip select busses, SPI,
> i2c, FPGA-internal busses etc. We recently tried to put oftree
sniplets
> into the devices (one into the module, one in the baseboard etc), let
> u-boot collect these sniplets and build an oftree out of it. It
doesn't
> work. If you try this, you'll quickly find out that you would have to
> put the schematics into the oftree.

If this is what is required to describe the connectivity of the system,
so be it.
Unfortunately, the fact that OF/DTS has tree structure doesn't provide
syntactic help for making these associations, but neither does it
provide a hinderance either.  At this level, OF/DTS
mainly provides a way of expressing hierarchy, and all the connections
must be specified orthogonally
from the tree hierarchy.

> A peripheral pin can be routed to a
> ball, goes from a connector of the module to a baseboard, to the
> extension board, come back and go to another unit on the SoC. This
> cannot be described in the oftree.

This I disagree with.  There is nothing preventing you from representing
this in a
device tree, other than figuring out how.

> At one place, you need to *know*
> about the whole hardware that you have and have a single "we have X"
to
> "X's oftree" mapping.

In my opinion, the 'platform support code' often devolves into hardcoded
references that
come from digesting all of this connectivity.  This works until knowing
the connectivity
becomes important.  Audio SOCs and clocks are two cases that have been
brought up in
this discussion.  I would
prefer to bite the bullet, and give the kernel all of the information
and let the driver
figure out what is important.
 
> In the end, having a single "X needs these platform data" kernel
source
> file is much, much cleaner and less error prone than what we currently
> have with the oftree.

I disagree.  It may be the easy way to get most things to work in the
short term, but
based on my experience, it results in information holes, hacks, and
other things that would
be neatly solved by taking the time to describe the system more
completely in the first place.

Steve


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.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 08:21:16PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
> > On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
> > > I'm not talking about platform specific code, I'm talking about code to
> > > retrieve information about a device from the device tree.  There would not
> > > be separate instances of this for "platforms X, Y and Z", just one
> > > of_platform binding in each driver.  It's no different than having a
> > > platform bus binding, except in the data structures used.
> > >
> > > But to restate, having external glue to create platform devices from the
> > > device tree is fine if that's what you want to do.  We used to do that, but
> > > it was a pain compared to keeping everything in one place.  Your experience
> > > may differ.
> > 
> > Could 'struct platform_device' and 'struct of_platform_device" be
> > unified into a single structure? It's personal preference whether the
> > internal representation of the hardware is done via a device tree or
> > snippets of platform code, but do we need to have to different device
> > types?
> 
> That's a damned good question - platform devices have been around since
> the dawn of the device model, so the real question which needs to be
> asked is: what was the reason that of_platform_device created rather
> than unifying it with the already provided platform_device ?
> 
> BTW, I can find no such struct "of_platform_device" in include/linux.
> Is it specific to each and every OF implementation?

They should be unified.  I believe the problem was at the time
of_platform devices came into existence there was no arch-specific
field in the device structure that could be used to hold a reference
to the devtree node.

Since then, the fiddliness of doing the conversion has always just
outweighed the impetus to do so.  The of_platform bus model is
conceptually completely broken, but in practice only slightly broken
for all common cases.

I've been meaning at several times to replace the of_platform bus
infrastructure with a system to traverse the OF tree and construct
platform devices (or other un-probeable bus devices, e.g. i2c) based
on a table of constructor functions.  It's just always been edged out
by other work.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Thu, May 28, 2009 at 02:07:07AM +0200, Robert Schwebel wrote:
> On Wed, May 27, 2009 at 06:58:24PM -0500, Scott Wood wrote:
> > Robert Schwebel wrote:
> >> The oftree by design wants to be a complete hardware description. As
> >> you mention above, there are cases where you *nevertheless* need
> >> ad-hoc information about things *not* encoded into the device tree.
> >>
> >> This renders the whole concept ad absurdum. You need a machine number
> >> again - and if you need that: why not stay with the ARM model, define
> >> everything with platform data and avoid the whole thing?
> >
> > Because it's better to have a little platform specific code than a lot
> > of it?
> 
> Until now, oftree has created more problems than it has solved for us.
> The idea works fine for well-known things like memory maps and
> interrupts. It works badly for corner cases, and embedded land is full
> of it. The effort to get the oftree stuff right is often more than a
> magnitude of order higher than the effort for the actual functionality.
> That should be an alarm sign that something is wrong.

It's true that going to a device tree model does take quite a bit of
time and effort to get up to speed.  As Grant said, we've made quite a
few errors along the way on powerpc, as people experimented with the
unfamiliar idea.  Along the way a lot of people complained about how
we were much better off without the device tree.

However, I think nowadays, with most of the community at least roughly
up to speed on device tree conventions, and the worst mistakes over, a
lot of people who doubted the value of the device tree approach are
coming around.

Grant mentions the Xilinx devices as an example - they're interesting
because of the fancy stuff they're doing, autogenerating the devtree
from the FPGA configuration.  But to me the real indicator of the
device tree's value is the handful of platforms for which support has
been added with *only* a new dts - a single, fairly simple text file.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 05:05:27PM +0200, Robert Schwebel wrote:
> On Wed, May 27, 2009 at 09:39:30AM -0500, Timur Tabi wrote:
[snip]
> - The whole concept is based on the assumption that bindings are defined
>   *once*, then never to be changed again. As this is not true (check
>   MPC5200 to find out what I mean), oftree wreckage is *the* main cause
>   of new kernels not working on old bootloaders any more. Is there a
>   solution of this problem? I have not seen a good idea how to avoid the
>   constant change in definitions.

That's true in the ideal, but doesn't break down completely in
reality.  Sure, you want to *aim* for a binding which never needs
updating, but in practice of course, you do need to change it.  When
you do, you end up with backwards compatibility code in the kernel or
the firmware or both to handle both "old" and "new" variants of the
device tree.  It's not perfect, but it still results in substantially
*less* accumulated cruft than we had before.

> - The oftree layering is fundamentally broken. We already have a sane
>   abstraction for arbitrary hardware in the kernel: platform devices.
>   Why not instanciate platform devices from a generic oftree core?

You're conflating the concept of the device tree structure with the
way we instantiate of_platform devices.  As Grant says, the actual
passed in device tree is just a data structure.

You're correct that the layering for the handling of the of_platform
bus and of_platform devices is fundmentally broken, although in
practice it works a lot less badly than it does in theory.  I've been
meaning to get around to replacing this with a saner structure (using
a table of constructor functions to instantiate platform devices or
others from the device tree information), but haven't had time yet.

> - Platform data makes it possible to store function pointers. There
>   is no equivalent to this concept in oftree-land.
> 
> oftree could be a great tool if these things would be resolved.
> Currently they are not, and in result, ARM just works and is easy,
> whereas on PowerPC systems people often spend more time working on
> binding stuff than on the actual functionality.

I think that was true in the early days when everyone was getting the
hang of the device tree.  It's becoming less and less true.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 02:54:10PM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 2:19 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> >> One option that has been suggested (more than once) is to make the
> >> adapter code an of_platform_driver which translates the device tree
> >> data and then registers the appropriate platform_devices.  This neatly
> >> solves the problem, but I don't like the overhead involved in
> >> registering 2 struct devices with the kernel for every device node in
> >> the device tree.
> > but simplify the dev and maintaining is also an important goal.
> >
> > Have to duplicated ressource handling via ifdef in every drivers is also an
> > overhead which need to be avoided
> 
> agreed.  I don't have a best of both worlds answer here.

I do.  As intimated other places in this thread, I think the right
approach is to register constructor functions that will be used during
boot to traverse the OF devtree and instantiate platform devices (or
other device types in some cases, e.g. i2c).  The driver will then
bind to the platform device this created.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 5:48 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> On Wed, May 27, 2009 at 02:35:11PM -0600, Grant Likely wrote:
>> > Unfortunately, it is an incomplete data structure regarding to what
>> > the kernel needs.
>>
>> I don't follow your argument. It's a data structure that uniquely
>> describes your hardware in a way which encourages the most code reuse
>> possible; but is still independent of kernel internal implementation.
>> ie. a FDT blob should be usable not just by Linux, but also by BSD or
>> any of the other OS options. It is not an attempt to eliminate
>> platform specific code; just to reduce it as much as possible. Weird,
>> harry, non-standard stuff probably still needs board specific code to
>> handle.
>
> The oftree by design wants to be a complete hardware description. As you
> mention above, there are cases where you *nevertheless* need ad-hoc
> information about things *not* encoded into the device tree.

That is an oversimplified characterization.  Of course the device tree
is striving to be a complete hardware description; but it cannot and
should not describe everything.  The goal is to make common stuff
common, and still have a mechanism to identify the corner cases.  For
example, most serial ports are described with a single node with
'compatible = "ns16550"' and 'reg', 'interrupts', 'current-speed' and
'clock-frequency' properties to describe the configuration.  This is a
common idiom which doesn't require any additional platform specific
code.  However, for a one-off board specific device which doesn't have
any kind of common description would probably be described simply as:

        data-capture@[address] {
                compatible = "<manufacturer>,<custom-daq-device-name>;
                reg = < [address] [size] >;
                interrupts = < [irq-number] [irq-sense] >;
        }

It it would be assumed that the device driver knows the details about
how the device is wired up.

So, no it does not eliminate platform specific code in all cases
(although I would argue most cases), but it does significantly reduce
it.

> This renders the whole concept ad absurdum. You need a machine number
> again - and if you need that: why not stay with the ARM model, define
> everything with platform data and avoid the whole thing?

That is not the problem being addressed.  It doesn't address
multiplatform kernels, it does not address the duplicate code issue,
and it doesn't address the reduced effort required of board ports.

> Regarding the multi OS argument: I consider it impossible that people
> agree on all micro details of a hardware decision. Will it really be
> possible to get a common agreement about let's say Russell's SMSC
> example between all these people? Remember: if we forget (or don't agree
> on) one single aspect which a driver developer *needs*, he will have to
> work around it -> machine number land.

Even assuming that you are correct; there is greater pressure when
using the device tree to make things work together because it means
less code to maintain.

> My impression is that oftree only works in a perfect world. But we don't
> have one, so the fundamental design decision is broken.

I disagree.  For the things that do work (and there are a lot of them)
it is a net win, and for the corner cases which do not, the mechanism
allows for the ability to handle exceptions at the
platform-support-code level (not at the device driver level).  That's
why I like the device tree model.  It acknowledges that the data
structure will never be perfect and provides the ability to deal with
it gracefully.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 5:57 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> On Wed, May 27, 2009 at 02:22:50PM -0600, Grant Likely wrote:
>> 2) Driver binding mechanism:  device tree nodes usually have a
>> "compatible" property which is a list of strings. The first string
>> describes exactly what the device is (ie. "atmel,24c08") and an
>> optional list of other devices which it is register interface
>> backwards compatible with.
>
> This is a good example. The "exact" description above doesn't say
> anything about some of the details the driver needs to know. Here is the
> at24 driver:
>
> http://lxr.linux.no/linux+v2.6.29/include/linux/i2c/at24.h#L18
>
> Where do we get the page size & flags from?

It is inherent in the value "atmel,24c08".  Because the exact device
model is specified, the kernel can know what the page size and flags
are for that device.  OTOH, if it is appropriate for the device, then
the binding can be defined to include things like page size and flags
encoded explicitly in additional properties.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 5:58 PM, Scott Wood <scottwood@freescale.com> wrote:
> Robert Schwebel wrote:
>>
>> The oftree by design wants to be a complete hardware description. As you
>> mention above, there are cases where you *nevertheless* need ad-hoc
>> information about things *not* encoded into the device tree.
>>
>> This renders the whole concept ad absurdum. You need a machine number
>> again - and if you need that: why not stay with the ARM model, define
>> everything with platform data and avoid the whole thing?
>
> Because it's better to have a little platform specific code than a lot of
> it?

Yes, exactly.

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 09:52:23PM +0100, Mark Brown wrote:
> On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
> > On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
> 
> > > I'm not talking about platform specific code, I'm talking about code to  
> > > retrieve information about a device from the device tree.  There would  
> > > not be separate instances of this for "platforms X, Y and Z", just one  
> > > of_platform binding in each driver.  It's no different than having a  
> > > platform bus binding, except in the data structures used.
> 
> > I really don't see what OF buys us then, apart from additional dependencies
> > that have to be correct for the kernel to work.  I can only see disadvantages
> > if all OF is, is a way to pass some file to the kernel to (effectively) tell
> > it which drivers to use.
> 
> The main selling points of the device tree AFAICT are that some
> platforms have to use it it anyway due to the native OS and firmware for
> the platform use it, the possibility of using the same device tree with
> more than one OS (modulo unrepresentable holes) and the fact that some
> people find it more convenient to use than straight data tables
> (personally I find the two approaches to be much of a muchness there).
> Perhaps I'm missing something, though?

The tree structure as opposed to plain data tables is not a trivial
difference.  It makes it much, much more convenient to describe
complex device layouts unambiguously than flat tables.  It's not
perfect but it's about three shit loads better than flat data tables
(powerpc embedded went through that stage too, on the way to device
trees and it sucked mightily).

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 6:07 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> On Wed, May 27, 2009 at 06:58:24PM -0500, Scott Wood wrote:
>> Robert Schwebel wrote:
>>> The oftree by design wants to be a complete hardware description. As
>>> you mention above, there are cases where you *nevertheless* need
>>> ad-hoc information about things *not* encoded into the device tree.
>>>
>>> This renders the whole concept ad absurdum. You need a machine number
>>> again - and if you need that: why not stay with the ARM model, define
>>> everything with platform data and avoid the whole thing?
>>
>> Because it's better to have a little platform specific code than a lot
>> of it?
>
> Until now, oftree has created more problems than it has solved for us.
> The idea works fine for well-known things like memory maps and
> interrupts. It works badly for corner cases, and embedded land is full
> of it. The effort to get the oftree stuff right is often more than a
> magnitude of order higher than the effort for the actual functionality.
> That should be an alarm sign that something is wrong.

Personally, I attribute a lot of that in powerpc land to the fact that
we had no clue what we were doing when we started the process of
porting all powerpc platforms to use the device tree.  It was hard.
It was painful.  We didn't have much established convention to learn
from.  However, now that it is complete I would say that it has been a
net-win and it is now simpler to bring up new boards and SoCs than it
ever was before.

Now we do know what we are doing and it should never cause that level
of pain again.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Wed, May 27, 2009 at 8:57 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> Grant mentions the Xilinx devices as an example - they're interesting
> because of the fancy stuff they're doing, autogenerating the devtree
> from the FPGA configuration.  But to me the real indicator of the
> device tree's value is the handful of platforms for which support has
> been added with *only* a new dts - a single, fairly simple text file.

Yes, exactly!  Even with the .dtb blob linked into the kernel image
this has been a huge win in simplicity.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 11:52:50AM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 11:44 AM, Russell King
> <rmk+lkml@arm.linux.org.uk> wrote:
> > (For whatever reason, I don't have the initial email on this.)
> >
> > On Wed, May 27, 2009 at 08:27:10AM -0600, Grant Likely wrote:
> >> On Wed, May 27, 2009 at 1:08 AM, Janboe Ye <yuan-bo.ye@motorola.com> wrote:
> >> > Hi, All
> >> >
> >> > Currently, ARM linux uses mach-type to figure out platform. But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals.
> >> >
> >> > The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code.
> >> >
> >> > Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware , for the detail of device tree.
> >> >
> >> > www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
> >> >
> >> > Signed-off-by: janboe <yuan-bo.ye@motorola.com>
> >>
> >> Heeheehe, This is Fantastic.  I'm actually working on this too.  Would
> >> you like to join our efforts?
> >
> > My position is that I don't like this approach.  We have _enough_ of a
> > problem getting boot loaders to do stuff they should be doing on ARM
> > platforms, that handing them the ability to define a whole device tree
> > is just insanely stupid.
> 
> The point of this approach is that the device tree is *not* create by
> firmware.  Firmware can pass it in if it is convenient to do so, (ie;
> the device tree blob stored in flash as a separate image) but it
> doesn't have to be and it is not 'owned' by firmware.
> 
> It is also true that there is the option for firmware to manipulate
> the .dts, but once again it is not required and it does not replace
> the existing ATAGs.
> 
> If a board port does get the device tree wrong; no big deal, we just
> fix it and ship it with the next kernel.

Indeed one of the explicit goals we had in mind in building the
flattened device tree system is that the kernel proper can rely on
having a usable device tree, without requiring that the bootloader /
firmware get all that right.

Firmware can supply a device tre, and if that's sufficiently good to
be usable, that's fine.  But alternatively our bootwrapper can use
whatever scraps of information the bootloader does provide to either
pick the right device tree for the platform, tweak it as necessary for
information the bootloader does supply correctly (memory and/or flash
sizes are common examples), or even build a full device tree from
information the firmware supplies in some other form (rare, but
occasionally usefule, e.g. PReP).

We explicitly had the ARM machine number approach in mind as one of
many cases that the devtree mechanism can degenerate to: the
bootwrapper just picks the right canned device tree based on the
machine number.  If the bootloader gets the machine number wrong, but
supplies a few other hints that let us work out what the right machine
is, we have logic to pick the device tree based on that.  Yes, still a
hack, but at least it's well isolated.

If the firmware does provide a device tree, but it's crap, code to
patch it up to something usable (which could be anything from applying
a couple of tweaks, up to replacing it wholesale with a canned tree
based on one or two properties in the original which let you identify
the machine) is again well isolated.

> > The end story is that as far as machine developers are concerned, a
> > boot loader, once programmed into the device, is immutable.  They never
> > _ever_ want to change it, period.

You're over focusing - as too many people do - on the firmware/kernel
communication aspects of the devtree.  Yes, the devtree does open some
interesting possibilities in that area, but as you say, firmware can
never be trusted so the devtree doesn't really bring anything new
(better or worse) here.

What it does bring is a *far* more useful and expressive way of
representing consolidated device information in the kernel than simple
tables.  And with the device tree compiler, it also becomes much more
convenient to prepare this information than building C tables.  I
encourage you to have a look at the sample device trees in
arch/powerpc/boot/dts and at the device tree compiler code (either in
scripts/dtc where it's just been moved, or from the upstream source at
git://git.jdl.com/software/dtc.git).

I have to agree with DaveM - a lot of people's objections to the
devtree stem from not actually understanding what it does and how it
works.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: David Gibson <david@gibson.dropbear.id.au>
Date: Thu, 28 May 2009 12:52:58 +1000

> The of_platform bus model is conceptually completely broken, but in
> practice only slightly broken for all common cases.

The fact that every single SBUS and EBUS driver for sparc is now an
of_platform driver, and the fact that as a further result joint
SBUS/PCI drivers are now almost completely unified, speaks volumes to
the fact that it is not broken.

Yes, you'll have some non-shared probing code, one to fetch the
resources from PCI/platform_device/whatever and one for of_device.

But, I say big deal.

The rest remains entirely unified, even the DMA calls are all the
same in unified SBUS/EBUS/PCI device drivers.  It just works.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 09:27:30PM -0700, David Miller wrote:
> From: David Gibson <david@gibson.dropbear.id.au>
> Date: Thu, 28 May 2009 12:52:58 +1000
> 
> > The of_platform bus model is conceptually completely broken, but in
> > practice only slightly broken for all common cases.
> 
> The fact that every single SBUS and EBUS driver for sparc is now an
> of_platform driver, and the fact that as a further result joint
> SBUS/PCI drivers are now almost completely unified, speaks volumes to
> the fact that it is not broken.

Only because the set of busses that need to be probed using devtree
information has a very large overlap with the set of busses that are
specific to OF aware platforms.

The conceptual problem becomes apparent when you consider things like
i2c.  The devtree is the obvious source to discover what i2c device
are present, but they need to be instantiated as i2c devices on the
i2c bus, not of platform devices.

The of_platform bus and the platform bus are just different
implementations of a "dumb" bus (roughly: single address space mapped
somewhere into MMIO, no introspection), the "of" variant being more
convenient for devtree based probing.  There's no inherent reason they
can't be merged, only a whole bunch of little fiddly reasons.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: David Gibson <david@gibson.dropbear.id.au>
Date: Thu, 28 May 2009 14:47:32 +1000

> The conceptual problem becomes apparent when you consider things like
> i2c.  The devtree is the obvious source to discover what i2c device
> are present, but they need to be instantiated as i2c devices on the
> i2c bus, not of platform devices.

Sure, but there is no reason there can't be an of_platform driver
for those i2c devices.  And such instantiated devices get propagated
either instantly to the parent, or later when the parent controller
probes.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Wed, May 27, 2009 at 10:31:47PM -0700, David Miller wrote:
> From: David Gibson <david@gibson.dropbear.id.au>
> Date: Thu, 28 May 2009 14:47:32 +1000
> 
> > The conceptual problem becomes apparent when you consider things like
> > i2c.  The devtree is the obvious source to discover what i2c device
> > are present, but they need to be instantiated as i2c devices on the
> > i2c bus, not of platform devices.
> 
> Sure, but there is no reason there can't be an of_platform driver
> for those i2c devices.  And such instantiated devices get propagated
> either instantly to the parent, or later when the parent controller
> probes.

Right, but the point is the bus info is trying to do two things here -
one is to supply stuff that's actually common to the bus interface,
the other is the probing logic.  That's usually connected to the bus
interface, but in the case of non-probeable basses on a system with a
devtree, that's no longer the case.  As soon as the bus has some
common logic that's really related to the bus interface regardless of
platform, then you start losing to use of_platform instead of a
specific bus structure because you have to duplicate that -
essentially having both OF and non-OF variants of however many busses
we need.

I think its saner instead to have the device model stuff only
represent stuff that's actually related to the bus interface, and
separately instantiate things into those busses from an OF tree
traversal.  I think this can be made as convenient as the current
setup for OF systems, though obviously I'll have to get around to
actually implementing it to be sure.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]


> It is inherent in the value "atmel,24c08".  Because the exact device
> model is specified, the kernel can know what the page size and flags
> are for that device.

I am afraid this is not the case. I remember that we once had two revisions of
the same eeprom, and the vendor decided to increase the page size without
changing the naming of the eeprom. (Can't point to any documentation yet, would
have to dig this up.) Those eeproms can be really weird.

Also, there are _a lot_ of eeprom manufacturers out there, so the match table
will be enormous....

> OTOH, if it is appropriate for the device, then the binding can be defined to
> include things like page size and flags encoded explicitly in additional
> properties.

..., so I think a property like "page-size" could really be argumented for.
Actually, I am quite optimistic that there could be agreement on it. Maybe we
could also reuse the "read-only" property which is used for partitions. Still,
this discussion has to be done, and that is additional work for mainlining.

Also, this would be _another_ wrapper to collect data from the device tree and
pass it into platform_data. I think it is difficult to maintain. If somebody
extends at24 and forgets about the of-wrapper, it may easily get broken. Plus,
at least for me, coding always very similar stuff, feels like bloating the
kernel. I did it a few times now, and that made me really wonder if we can't
have a more generic solution to that problem. Sadly, I could neither come up
with anything useful :(

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Wed, 2009-05-27 at 17:05 +0200, Robert Schwebel wrote:

> I'm highly convinced that the existence of oftree-hell in ARM-land would
> have been *the* key motivation for FSL to have worked on mainline
> instead of inhouse-BSPs back in 2004 when we mainlined i.MX1 and in 2007
> when we started the mainline work on MX27 and MX31.
> 
> Seriously: oftree in general is a good idea. Just that it doesn't work
> in practise. The concept has some serious flaws:

Lots of strong words and animosity here ... we may not have got
everything right the first time around, an some things may still be wet
behind the ears but overall, I'm strongly convinced that this whole
thing ended up being a net benefit for various reasons though not
necessarily the most obvious ones.

> - The whole concept is based on the assumption that bindings are defined
>   *once*, then never to be changed again. As this is not true (check
>   MPC5200 to find out what I mean), oftree wreckage is *the* main cause
>   of new kernels not working on old bootloaders any more. Is there a
>   solution of this problem? I have not seen a good idea how to avoid the
>   constant change in definitions.

Bindings are defined as we go and mostly -can- be changed, it's actually
not that a big deal. It depends what your approach is though vs. putting
the device-tree in a firmware or just shipping it wrapped with the
kernel. Right, putting DTs in firmwares mean potential issues like that,
but we dealt on real OF based platforms with serious differences in
approach and bindings between IBM, Apple and Sun without big
difficulties.

IE. It's not a big deal in practice, at least not as much as it seems.

Part of the problem exposed by the bindings discussions is typical to
internet discussions where the less complex the problem is, the more
idiots come in and think they have something to contribute :-)

Mostly, a binding only need some good work once for bus types, and a lot
of the common ones have been ironed out. Funnily enough, it looks like
we may have to do one for amba on powerpc soon too :-)

For actual devices, there's a huge amount of flexibility. It's nice to
be standardize whenever possible, but in the end, the content of a node
is a deal between the device-tree and the driver.

> - The oftree layering is fundamentally broken. We already have a sane
>   abstraction for arbitrary hardware in the kernel: platform devices.
>   Why not instanciate platform devices from a generic oftree core?

I don't understand what you mean here. Platform devices are everything
-but- a sane abstraction, but again, there is absolutely no issue there,
it's completely orthogonal.

Nowadays, any struct device can be linked to an OF device node thanks to
the archdata extension that we added to the generic struct device. One
of the idea we have in mind is to create a simple mechanism that
"intanciate" devices based on probing them in the tree, regardless of
the actual bus and linux device "type" (platform, PCI, i2c, ...).
 
> - Platform data makes it possible to store function pointers. There
>   is no equivalent to this concept in oftree-land.

I don't see why there would be ... those are totally different issues
here.

> oftree could be a great tool if these things would be resolved.
> Currently they are not, and in result, ARM just works and is easy,
> whereas on PowerPC systems people often spend more time working on
> binding stuff than on the actual functionality.

A lot of conservatism here and little attempt to even think about the
possible benefits :-)

There are areas where the device-tree have proved invaluable. One is
interrupt routing. The ability of the DT to represent any possible
interrupt layout of cascaded PICs and other fucked up schemes is great,
which mixed with powerpc simple virtual interrupt mapping scheme greatly
simplified handling of many setups.

You really only need to describe in each device what PIC it's connected
to, what IRQ on that PIC and the sense info. You can convert interrupt
domain using maps (useful for PCI). The kernel provide simple helper to
retrieve this, and with our IRQ remapping core (which I would recommend
porting as well), can trivially assign PIC/irq pairs to a linux irq
number. No more hard wired ranges that blow up every time you try to
add a new GPIO controller in the system etc...

It's also proved very useful to effectively have all the data related
to how the HW is wired together in one single place rather than spread
among 25 drivers and platform files.

And that's just some ...

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Wed, 2009-05-27 at 18:56 +0100, Russell King wrote:
> 
> smc91x is a prime example of the kind of information drivers need - base
> address and irq are very much insufficient to describe how this device is
> connected.  There's much more information required to specify this device
> fully, and throwing it into the driver doesn't work.  We've been there
> and proven that point.

The device-tree is a very nice and convenient way to convey all the
informations the driver need straight to the driver without any platform
code in the middle :-)

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Wed, 2009-05-27 at 14:08 -0500, Scott Wood wrote:
> But to restate, having external glue to create platform devices from the 
> device tree is fine if that's what you want to do.  We used to do that, 
> but it was a pain compared to keeping everything in one place.  Your 
> experience may differ.

This is a non-solved debate as to what is best. If an existing driver
already has fairly complete platform_device support, it might be best to
just create a glue that fills up the data structure from the DT... 

In any case, all the approaches are possible, the DT stuff doesn't
corner you into a specific one.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

> That's a damned good question - platform devices have been around since
> the dawn of the device model, so the real question which needs to be
> asked is: what was the reason that of_platform_device created rather
> than unifying it with the already provided platform_device ?
> 
> BTW, I can find no such struct "of_platform_device" in include/linux.
> Is it specific to each and every OF implementation?

It's just of_device... of_platform_driver and of_device.

The reason it's there is historical in fact (I created it :-) Mostly
because it predates having the archdata field in struct device which
allows to convey the pointer to the OF tree node to the driver.

Nowadays, I wouldn't necessarily need it.

An interesting example that I may have to implement for powerpc here
is amba as it looks like there may be some folks bridging AXI to
some ppc stuff.

Here, what I would do is define a simple binding that describes how to
represent amba based devices in the tree (mostly having a description
of the bridge itself) and then a file in drivers/amba that contains
code that will instanciate the -existing- amba_device objects as they
are found in the tree.

I can provide the addresses and IRQ routing straight off the tree.

>From there, I have two options to get the ID off them. I can leave the
code as-is in drivers/amba/bus.c to do MMIOs to read it... 

Or I can decide to be fancy and define a property in the DT to carry
that ID and add the ability to the amba core to, when the amba device
has a DT node and that property is present, to avoid that MMIO operation
and create the right ID directly (which can be faster though that
doesn't necessary represent much, it's just an example).

Among other things, we have the ability on ppc64 and sparc64 (and this
code will soon be moved to some generic place for the benefit of others)
to create the entire PCI tree from the DT, by creating the pci_dev's and
populating them from the info in the DT rather than probing config
space. We keep a hook to allow the platform to indicate on a per-bus
basis whether to use the DT or do a hard probe.

This has been very useful in a few circumstances. It was initially done
to avoid doing config space accesses to some weirdo bridges when running
under a hypervisor on IBM machines or other strange things that
hypervisor can invent such as PCI devices with no function 0 :-)

It also proved that it speeds up the PCI discovery significantly.

But it also helps a lot with one important thing: It avoids BAR sizing
on all the devices that are fully described in the tree. That means that
the devices (or entire busses) are no longer taken offline for a little
while during boot... which happens with IRQs enabled, and can be a
killer if your PIC itself is behind one of these devices and you get the
interrupt at the wrong time.

That's just examples of what you -can- do with the DT. We made its usage
mandatory for all platforms on powerpc but you obviously wouldn't want
to do that on ARM. However, it's probably worth providing the optional
infrastructure to use it, and see how it goes with people doing so, it
might end up being a really good thing.

To finish, it's like any tool... its benefits (or lack of) all depends
how it's used.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 01:57 +0200, Robert Schwebel wrote:
> On Wed, May 27, 2009 at 02:22:50PM -0600, Grant Likely wrote:
> > 2) Driver binding mechanism:  device tree nodes usually have a
> > "compatible" property which is a list of strings. The first string
> > describes exactly what the device is (ie. "atmel,24c08") and an
> > optional list of other devices which it is register interface
> > backwards compatible with.
> 
> This is a good example. The "exact" description above doesn't say
> anything about some of the details the driver needs to know. Here is the
> at24 driver:
> 
> http://lxr.linux.no/linux+v2.6.29/include/linux/i2c/at24.h#L18
> 
> Where do we get the page size & flags from?

Easy, add properties for them in the node for that device ! The
device-tree actually makes that really easy, a lot easier than anything
else I've seen so far.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 08:34 +0200, Wolfram Sang wrote:
> 
> > OTOH, if it is appropriate for the device, then the binding can be defined to
> > include things like page size and flags encoded explicitly in additional
> > properties.
> 
> ..., so I think a property like "page-size" could really be argumented for.

Most definitely. And it's in fact reasonably easy to define such
bindings. And if somebody later decide do invent a fancier property
called "page-data" that contains more structured informations, the
driver can still fall back to using "page-size" when the later is not
found. It's rarely needed but the technique works reasonably well.

> Actually, I am quite optimistic that there could be agreement on it. Maybe we
> could also reuse the "read-only" property which is used for partitions. Still,
> this discussion has to be done, and that is additional work for mainlining.

Well, it depends. You don't need to have defined all the bindings for
all possible devices on the planet before adding to your architecture
the core bits to have the ability to use device-trees :-)

However, it does make sense for a platform using it, to at least try
to make sure that bindings for the devices it uses are in reasonable
shape.

Again, no solution is ever perfect and whatever the technique is,
somebody can make a mess of it. But my experience is that most of
the time, those things come pretty easily out of common sense when
talking about bindings for a -device-. Bindings for -busses- take
a bit more thoughts, I agree.

> Also, this would be _another_ wrapper to collect data from the device tree and
> pass it into platform_data.
>  I think it is difficult to maintain.

It's easier to have -one- piece of code taking data for device type X
to create the platform data and than all platforms around having C code
spread around that manufactures that platform data in 36 different ways.

So here, I disagree.

>  If somebody
> extends at24 and forgets about the of-wrapper, it may easily get broken.

No. If somebody adds new fields and not knowing about them doesn't break
existing users, then only the first person to try to use the new
functionality will discover the need for a new property and update the
wrapper.

If somebody however changes the platform data in incompatible ways, that
person is supposed to fix all users right ? So grep all platforms etc...
and the wrapper will show up in that grep.

Also, it might be a lot easier to change just the wrapper don't you
think ? :-)
  
>  Plus,at least for me, coding always very similar stuff, feels like bloating the
> kernel. I did it a few times now, and that made me really wonder if we can't
> have a more generic solution to that problem. Sadly, I could neither come up
> with anything useful :(

Well, the device-tree does avoid a -lot- of code duplication... you can
see that easily when you look at our 4xx based platforms today vs. what
they were in arch/ppc

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Wed, 2009-05-27 at 14:54 -0600, Grant Likely wrote:
> > Have to duplicated ressource handling via ifdef in every drivers is
> also an
> > overhead which need to be avoided
> 
> agreed.  I don't have a best of both worlds answer here.

Right and I don't advocate changing existing perfectly working platform
drivers, I think having wrappers to create them is fine.

In fact, I've been thinking for a long time about doing something like
that: Have those wrappers be registered via a standard OF set of match
strings for bus types and device types.

Then we can have a single loop that walks the tree, invoke those
"constructors" that return a struct device * (whatever the device
type that was actually created, could have been platform_device,
pci_dev, amba_device, etc...). It also passes them the parent device *

That way, all devices are instanciated from the DT -and- the topology
in sysfs preserves the topology in the device-tree (ie, parent/child
relationships are preserved).

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Wed, 2009-05-27 at 20:29 +0100, Russell King wrote:
> 
> 
> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?

Yes. Anything. Basically just a bunch of named properties with
arbitrary content in the nodes for the various devices.
  
> If you're going to say yes to all that, I'm going to start asking how
> you cope with verifying that the data for ethernet driver A doesn't
> get accidentally used for ethernet driver B.

I'm not sure about the question. If it's about identifying which
instance of a device is using the data, it's basically easy since
you used that device-node to create the device in the kernel in
the first place, so you just stick that node pointer into the
achdata as we do on powerpc and can use it to retrieve all the
properties.

If you are talking about different drivers for the same device,
well we try to define bindings such that they describe the hardware
itself in a way that is reasonably agnostic to whatever driver will be
used... 

> I assume you have some kind of compiler, which needs a set of
> specification files to tell it what's required for each driver which
> is OF compatible. If not, I can see no way for OF trees to ever be
> safe and correct.

No, the format at boot time is a flattened tree of nodes with arbitrary
named nodes containing other nodes and named properties (names are
ASCII) and properties have arbitrary binary content.

_Bindings_ define what to put in these things for various bus and device
types, and we do have a compiler, dtc, that goes from a C-like textual
representation and generates the blob.

It makes it easy to create properties that contains strings, numbers,
phandles (references to other nodes), etc...

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 06:01 +0800, Mitch Bradley wrote:
> If anybody is interested, the core ARM support has been added to the 
> Open Firmware tree at svn://openfirmware.info/openfirmware - the same 
> version of OFW that's used on OLPC - under an MIT-style license. This is 
> a full-featured Open Firmware whose lineage traces back to the original 
> Open Boot implementation that I wrote for Sun starting in 1987.
> 
> It's not yet fully elaborated for specific platforms and devices, but it 
> does contain all the core IEE1275 device tree stuff and the standard 
> support packages.  It gets you to an ok prompt on Beagle Board and 
> Gumstix Overo systems.  The source-level and assembly-language debuggers 
> are fully functional. As currently configured on those systems, you can 
> load it into memory either via u-boot or instead of u-boot.
> 
> This base ARM port, while newly released as FOSS, is quite solid, having 
> been developed some years ago for the Digital (RIP) DNARD system.
> 
> I'd be happy to work with people to add deeper support for specific 
> device and platforms.

That's actually great news !

While most of the discussion here revolves around whether to use a
device-tree or not, mostly with the flattened device-tree format in
mind, having a real OF implementation is always a much better option
as far as I'm concerned.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Thu, May 28, 2009 at 05:37:16PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-05-27 at 18:56 +0100, Russell King wrote:
> > 
> > smc91x is a prime example of the kind of information drivers need - base
> > address and irq are very much insufficient to describe how this device is
> > connected.  There's much more information required to specify this device
> > fully, and throwing it into the driver doesn't work.  We've been there
> > and proven that point.
> 
> The device-tree is a very nice and convenient way to convey all the
> informations the driver need straight to the driver without any platform
> code in the middle :-)

I'm still uncertain whether that's actually a true statement.  For some
cases, of course it's true, but I have a nasty suspicion that we have
corner cases where OF won't cope well with.

As I see it, if we were to convert to OF, we're boxing ourselves in to
a corner that would be extremely difficult to get out of.  We would
never be able to step back from OF.  Lets take an example.  If we were
to convert PXA to OF including all the PXA SoC drivers, and a board
configuration came along which required hacks to a driver.  Later on
we find that most platform authors are applying similar hacks because
their hardware is subtly different but those differences can't be
expressed via OF.  At this point, what do we do?  We can't say "well,
OF doesn't work well on this platform, we want to get rid of it" that
would be extremely difficult to impossible to do.


For example, how would an IrDA transceiver be expressed in OF?

Obviously it would have to start off with some sort of UART definition
for SIR, with a separate (and sometimes unrelated in terms of register
space and SoC pin configuration) FIR unit.  Whether FIR is used or not
is platform specific.  So far so good, I don't see a problem yet.

We then have one or two GPIOs doing some function - eg, one GPIO might
be a simple power on/off while the other controls FIR or SIR mode in
the transceiver itself.  Or the two lines might be a bit combination
which selects 'off', 'on + sir', 'on + fir' modes depending on the
transceiver used.  In the case of one GPIO it might be the mode select
or it might be the power control.

I suspect this can be expressed by having some sort of OF table specifying
several gpios & their value for each combination of power & mode...
except some platforms have special control registers in FPGAs which do
not appear as GPIOs... so how are those expressed?  We have function
pointers back into platform code to cope with this at present.


Another example - LCD displays.  Some platforms need a certain sequence
of GPIO activations with delays between when powering up and down the
LCD display.  Currently we express this in the platform support file and
pass a function pointer into the LCD Driver.  Can this be expressed with
OF?


Another example - backlights.  Some platforms need to twiddle a GPIO
at a certain point in the brightness scale and reset the PWM, and they
currently do this via an (optional) function pointer in the generic PWM
backlight driver.  Can this be expressed with OF?


That's just a few examples of areas where we haven't been able to describe
platforms using pure data-based descriptions, and they're all things that
we don't want to stuff into the individual drivers (doing so involves lots
of ifdefs and namespace pollution - we saw that in 2.4 kernels.)

In order for me to be convinced that OF is not going to cause us grief,
I'd like to see a range of platforms converted to OF to check that we're
not going to find any unexpected problems - eg, a load of PXA platforms,
particularly those with the above kinds of problems.

And no, Dave Miller saying "I've been using this for 15 years on Sparc"
"Three architectures are using it" isn't going to convince me.  The proof
is in the code, not the waffle.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Wolfgang Denk]

Dear Robert Schwebel,

In message <20090528000707.GR6805@pengutronix.de> you wrote:
>
> Until now, oftree has created more problems than it has solved for us.
> The idea works fine for well-known things like memory maps and
> interrupts. It works badly for corner cases, and embedded land is full
> of it. The effort to get the oftree stuff right is often more than a
> magnitude of order higher than the effort for the actual functionality.

Well, but isn't this also because the device tree dramatically
reduced the amount of effort to get a new board supported? We have
seen a number of cases where _only_ the device tree needed
significant efforts to get a basic BSP running on a new board.
Talking about ration of device tree efforts versus code writing
efforts is somewhat irrelevant when you ignore that the total effort
goes down. Sometimes significantly.

> That should be an alarm sign that something is wrong.

Maybe the interpretation of data?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

Re: [RFC] [PATCH] Device Tree on ARM platform

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa40905272029n32aa5f1ds86d07f0de4894815@mail.gmail.com> you wrote:
>
> Personally, I attribute a lot of that in powerpc land to the fact that
> we had no clue what we were doing when we started the process of
> porting all powerpc platforms to use the device tree.  It was hard.
> It was painful.  We didn't have much established convention to learn
> from.  However, now that it is complete I would say that it has been a
> net-win and it is now simpler to bring up new boards and SoCs than it
> ever was before.

True. From a commercial point of view this is a huge  problem  casued
by the device tree - custumers who used to oder a BSP from commercial
service providers (like Robert or me :-) now often find that all they
need  to  do is to tweak the device tree to get their system running.
Lost business. D*mn...  [Maybe this explains Robert's reluctance?]

But as stated before:  from the engineering point of view it's a real
big win now.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
                                                        -- S. Beckett

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date: Thu, 28 May 2009 10:15:13 +0100

> For example, how would an IrDA transceiver be expressed in OF?

As a child device node of the IRDA device, with associated
properties.

You can express _ANYTHING_ using the OF device tree.  It is
not even something to discuss, it's flexible enough.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Wolfgang Denk <wd@denx.de>
Date: Thu, 28 May 2009 11:51:26 +0200

> Lost business. D*mn...  [Maybe this explains Robert's reluctance?]

ROFL

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

> I'm still uncertain whether that's actually a true statement.  For some
> cases, of course it's true, but I have a nasty suspicion that we have
> corner cases where OF won't cope well with.
> 
> As I see it, if we were to convert to OF, we're boxing ourselves in to
> a corner that would be extremely difficult to get out of.  We would
> never be able to step back from OF.  Lets take an example.  If we were
> to convert PXA to OF including all the PXA SoC drivers, and a board
> configuration came along which required hacks to a driver.  Later on
> we find that most platform authors are applying similar hacks because
> their hardware is subtly different but those differences can't be
> expressed via OF.  At this point, what do we do?  We can't say "well,
> OF doesn't work well on this platform, we want to get rid of it" that
> would be extremely difficult to impossible to do.

I understand your concern. However, I yet have to encounter a case where
the device-tree mechanism doesn't allow to convey the necessary
informations. From my experience, it's always been superior in that area
to any other mechanism we came up with.

However, it's hard to give a final judgment without actual examples. But
I see you are providing one below, let's see...

> For example, how would an IrDA transceiver be expressed in OF?
> 
> Obviously it would have to start off with some sort of UART definition
> for SIR, with a separate (and sometimes unrelated in terms of register
> space and SoC pin configuration) FIR unit.  Whether FIR is used or not
> is platform specific.  So far so good, I don't see a problem yet.

Right. Well, there are various ways to approach this. One is to have the
transceiver be a child of the UART but that doesn't necessarily work
well in term of addressing and conveying the necessary register
informations.

However, it would be reasonably simple and not unheard of to instead for
example stick a property in the UART node, for example "fir-transceiver"
that contains a phandle (a phandle is a pointer to another node) that
points to the node that represents the transceiver and has the necessary
register mapping informations.

We have that kind of cross-node relationships expressed in various ways
for things like network interfaces where the PHY controller sits on a
different part of the SoC for example. It works reasonably well.

> We then have one or two GPIOs doing some function - eg, one GPIO might
> be a simple power on/off while the other controls FIR or SIR mode in
> the transceiver itself.  Or the two lines might be a bit combination
> which selects 'off', 'on + sir', 'on + fir' modes depending on the
> transceiver used.  In the case of one GPIO it might be the mode select
> or it might be the power control.

One approach is to have the FIR node contain a property called
"power-gpio" pointing to the GPIO node for the power GPIO etc...

It's only one way.

If the stuff gets too tricky due to multi-usage or multiplexing of the
said GPIO, you could have instead a node for a "pseudo device" that
would be fir-power-control or whatever else that contains some
information and that the platform uses to provide a callback to the FIR
drivers.

The device-tree doesn't corner yet there. A given device binding might
define the basics for devices of that type, but I yet have to see a case
where you cannot express dependencies reasonably well in the
device-tree.

One thing to keep in mind is that the "tree" doesn't mean that there is
one strict hierarchy of devices. The "main" hierarchy of the device-tree
is generally chosen based on addressing capabilities to convey register
address translations.

But you can cross that via node pointers easily and provide alternate
hierarchies within the tree. It's commonly use for interrupt routing for
example where devices can have an "interrupt-parent" property that
points to the PIC they are attached to (or to a node that convert
interrupt domains when that makes more sense, called an interrupt map,
this is commonly used for PCI). By default, if you don't provide such an
explicit parent, the tree parent is considered as the interrupt parent
(and may itself contain an interrupt-parent property that points to the
PIC for all its children).

The possibilities are almost endless. When you hit a real corner case,
you can always create some kind of pseudo device that is backed by
actual C code to resolve the situation in the kernel, or some kind of
'power-method' property that you can use to lookup a table of platform
provided methods. That's just ideas... 

One thing I agree with is that it takes some time to get familiar with
the various ways the device tree can be used and thus use it
efficiently. As I said earlier, it's a tool, it's very powerful but can
be misused like any tool. I believe a good approach for ARM isn't to
convert altogether to a device-tree based approach that requires all
platforms to use it, but to start providing the infrastructure for
platforms to "opt-in" and see how it goes from there.

And you always still have the choice of hard wiring something in the
platform code if you really want to :-)

> I suspect this can be expressed by having some sort of OF table specifying
> several gpios & their value for each combination of power & mode...
> except some platforms have special control registers in FPGAs which do
> not appear as GPIOs... so how are those expressed?  We have function
> pointers back into platform code to cope with this at present.

You can still do something like that. I don't think the tree limits
your ability to do that sort of thing.

> Another example - LCD displays.  Some platforms need a certain sequence
> of GPIO activations with delays between when powering up and down the
> LCD display.  Currently we express this in the platform support file and
> pass a function pointer into the LCD Driver.  Can this be expressed with
> OF?

The tree itself wouldn't contain a function pointer no. There are
several approaches here. If what you are trying to express can
reasonably well be done via some kind of table of values & delays, you
can define a property format that contains that to stick into the LCD
node.

A more flexible approach may be to have a "power-method" property as I
proposed above. You can then create some kind of mechanism to export
various such methods based on their name that the platforms can provide
or that can be in separate files and have the driver lookup the right
one using the property in the LCD node.

Apple tried to do some ACPI-ish kind of "scripts" in the device-tree
where they actually stick tokenized kinds of sequences of things which
themselves are method calls to other drivers and pseudo-instructions all
in one property.

This is a possibility, and we do have an interpreter for that stuff in
the kernel, but I find it gross and over-engineered myself at least the
way it was done. But if we feel it's worth doing something like that
cleanly, then why not ?

> Another example - backlights.  Some platforms need to twiddle a GPIO
> at a certain point in the brightness scale and reset the PWM, and they
> currently do this via an (optional) function pointer in the generic PWM
> backlight driver.  Can this be expressed with OF?

Similar to the above, there are ways to express things, but to a certain
extent, when things gets too tricky, C code might be the best approach,
however nothing prevents you from having a mechanism to name those
methods and register the callbacks and use that. Or keep your old way.

I think at this stage, it's really a matter of trying it out on a few
platforms and see how it goes.

I don't pretend it's going to magically solve everything or make
everything nicer. But it has the potential of solving many things and
making many things nicer.

> That's just a few examples of areas where we haven't been able to describe
> platforms using pure data-based descriptions, and they're all things that
> we don't want to stuff into the individual drivers (doing so involves lots
> of ifdefs and namespace pollution - we saw that in 2.4 kernels.)

Yup, I understand this problem well, it's what Apple tried to solve in
the example above, and what ACPI tries to solve with AML, and while we
-could- try to define some kind of scripted mechanism, I'm not sure its
worth the challenge and we may as well go back to actual C code for
those special cases. But I don't think having a device-tree makes that
problem any worse than it is, ie, existing solutions would still work.
It has even the potential of making it a bit cleaner to separate the
magic handlers and access them by names.

Now, if we want to go crazy, we can look into the full OF rather than
just the device-tree, ie, bring in the tokenized F-code interpreter in,
and express things as F-code methods :-) but that might be overkill, at
least I believe it is for most our embedded cases on powerpc.

> In order for me to be convinced that OF is not going to cause us grief,
> I'd like to see a range of platforms converted to OF to check that we're
> not going to find any unexpected problems - eg, a load of PXA platforms,
> particularly those with the above kinds of problems.

I think we need to distinguish using the OF-style device-tree, which is
I think what this thread initially is about, from using a full blown OF
as a firmware, and potentially trying to either keep it alive along with
the kernel to be able to call into it (which is possible but hard) or
bring in an f-code interpreter into the kernel.

The former is mostly what I advocate for now for embedded. The later is
something interesting to explore I suppose but not on my personal agenda
right now.

> And no, Dave Miller saying "I've been using this for 15 years on Sparc"
> "Three architectures are using it" isn't going to convince me.  The proof
> is in the code, not the waffle.

Well, sparc has the advantage of having a full OF implementation from
day one with people who have been smart enough to provide reasonably
good representations of things in their device-trees. Also, sparc
doesn't have to deal with some of the intricacies of the embedded world
(same deal with ppc64) so I tend to agree here that the situation isn't
that clear cut.

However, it's probably worth giving it a go.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 02:57 -0700, David Miller wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Date: Thu, 28 May 2009 10:15:13 +0100
> 
> > For example, how would an IrDA transceiver be expressed in OF?
> 
> As a child device node of the IRDA device, with associated
> properties.
> 
> You can express _ANYTHING_ using the OF device tree.  It is
> not even something to discuss, it's flexible enough.

Well, that example is interesting because you may not want the
transceiver to be a child of the UART :-) The tree hierachy is mostly
about addressing, and addressing below a UART doesn't mean much.

So if the transceiver has a bunch of MMIO registers, it might be better
off located elsewhere, and have the UART have a "fir-transceiver"
property with a phandle to the actual device...

But yes, I definitely agree, it's flexible enough for a lot of that
stuff. Where things get tricky is to express "methods" rather than just
relationships. This is where x86 loses big time with ACPI, Apple lost
with their platform functions in OF properties, and appart from having a
real OF implementation under the hood that is kept alive along with the
kernel to call in, the tree doesn't provide a simple solution.

However, it doesn't either invalidate existing solutions based on
function pointers into the platform code... it might even make it nicer
by naming those functions into some kind of directory where they can be
registered by the platform code and "named" by a property in the node,
though I tend to prefer the approach of having a property with a phandle
to a node that is a pseudo-device ("power-control") or so, which has its
own driver providing the methods.

The possibilities are endless. _BUT_ it does require some careful
thinking to get things right. To that extent, I do agree with Russell
that rather than a "violent" conversion, ARM should first try things out
as an opt-in for a few platforms and see how it goes.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Thu, May 28, 2009 at 11:51:26AM +0200, Wolfgang Denk wrote:
> True. From a commercial point of view this is a huge  problem  casued
> by the device tree - custumers who used to oder a BSP from commercial
> service providers (like Robert or me :-) now often find that all they
> need  to  do is to tweak the device tree to get their system running.
> Lost business. D*mn...  [Maybe this explains Robert's reluctance?]

Wolfgang, you know me long enough to realize that this argument is
*crap*.

Talking about business cases, it has turned out to be extremely
difficult to explain customers that the effort for the actual
functionality is only a little percentage of the work necessary to do
the oftree stuff right. The functionality has often worked after a few
hours, and until all oftrees have been solved, it often takes weeks.

In result, this has already led to customers concluding that

- mainline is not worth the effort
- linux is overkill and one should better use cortex-bare-metal

However, that is only our personal observation.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Thu, May 28, 2009 at 02:57:39AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Date: Thu, 28 May 2009 10:15:13 +0100
> 
> > For example, how would an IrDA transceiver be expressed in OF?
> 
> As a child device node of the IRDA device, with associated
> properties.
> 
> You can express _ANYTHING_ using the OF device tree.  It is
> not even something to discuss, it's flexible enough.

That's not a useful reply.  I'm trying to discuss specifics and find out
_precisely_ how they would be handled in an OF-based situation.  You're
attitude in this discussion is really not helping, and is actually
insulting.

If you have anything _usefully_ technical to contribute then please do.
Otherwise, shut up.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Thu, May 28, 2009 at 08:11:33PM +1000, Benjamin Herrenschmidt wrote:
> The possibilities are endless. _BUT_ it does require some careful
> thinking to get things right. To that extent, I do agree with Russell
> that rather than a "violent" conversion, ARM should first try things out
> as an opt-in for a few platforms and see how it goes.

I think that the overall discussion goes into a very good direction.

The level of agreement is not as low as it might look like, I agree with
most of what David Gibson, benh and rmk have said so far; the problems
we've seen have been well identified. In the end it's probably a matter
of finding enough time to actually implement for example a prototype for
PXA.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Thu, May 28, 2009 at 08:11:33PM +1000, Benjamin Herrenschmidt wrote:
> Well, that example is interesting because you may not want the
> transceiver to be a child of the UART :-) The tree hierachy is mostly
> about addressing, and addressing below a UART doesn't mean much.
> 
> So if the transceiver has a bunch of MMIO registers, it might be better
> off located elsewhere, and have the UART have a "fir-transceiver"
> property with a phandle to the actual device...

IrDA transceivers do not have MMIO registers.  Transceivers are an IR
LED, an IR phototransitor and receiver circuitry.  They're typically
9 pin devices with power, ground, transmit, receive and a bunch of
control signals.

These control signals end up connected to some random GPIO pins or
FPGA or some other device which has some free IO lines in the platform.

These control signals need to be controlled with reference to the IrDA
driver, sometimes with tight timing constraints (particularly when
switching between SIR and FIR modes.)

> But yes, I definitely agree, it's flexible enough for a lot of that
> stuff. Where things get tricky is to express "methods" rather than just
> relationships. This is where x86 loses big time with ACPI, Apple lost
> with their platform functions in OF properties, and appart from having a
> real OF implementation under the hood that is kept alive along with the
> kernel to call in, the tree doesn't provide a simple solution.
> 
> However, it doesn't either invalidate existing solutions based on
> function pointers into the platform code... it might even make it nicer
> by naming those functions into some kind of directory where they can be
> registered by the platform code and "named" by a property in the node,
> though I tend to prefer the approach of having a property with a phandle
> to a node that is a pseudo-device ("power-control") or so, which has its
> own driver providing the methods.

The kind of reply I was hoping to get to my email was something more
along these lines - an informed view giving an idea how some of these
issues would be addressed with an OF device tree.

I can see how the named functions/directory would work - that seems to
be relatively simple and straight forward.

However, the pseudo-device approach I'm less clear about.  With a separate
driver for the "power control" pseudo-device, how would you communicate
the state information down to that driver?

I am equating OF devices and drivers too much with the struct device and
struct driver model, which sounds like it's not the best thing to do with
OF.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Wed, May 27, 2009 at 05:15:25PM -0700, David Miller wrote:
> From: Robert Schwebel <r.schwebel@pengutronix.de>

> > It works badly for corner cases, and embedded land is full
> > of it. The effort to get the oftree stuff right is often more than a
> > magnitude of order higher than the effort for the actual functionality.
> > That should be an alarm sign that something is wrong.

> And here you speak about the negatives purely in generalities that
> cannot be discussed concretely.

> And, sadly, I think this is on purpose.

A concrete example that was mentioned elsewhere in the thread is audio
subsystems.  The audio subsystem for an embedded system will contain
multiple chips - a mobile phone could have the CPU, an audio CODEC,
bluetooth and GSM for example.  These will be interconnected by a
combination of analogue and digital links.  The digital links consist of
six wires (data, sync clock and bit clock for each of transmit and
recieve), some of which may be tied together in hardware.  Some of these
links may be shared either with switches or using TDM.  The devices will
also have master clocks from various sources and will often have PLLs or
FLLs able to generate clocks if the inputs aren't directly usable.  Each
clock domain within the audio subsystem will need some level of
synchronisation of the clocks and there may be multiple clock domains
within the system.

In principle we could describe the links between the devices, provide
some additional use case based constraints then take this information
and figure out a suitable runtime configuration automatically; this is
probably the only viable OS neutral way of doing things.  In practice
we're nowhere near having a clock framework which is able to support
implementing this.

The current approach is to write custom code that knows a suitable way
to set things up in a given system (which is a much more tractable
problem).  The PowerPC people have mostly accepted using this approach
but they're really not happy with it and it's been difficult to get the
general community understanding that it's hard to cope with this in the
device tree.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:15 Thu 28 May     , Russell King - ARM Linux wrote:
> On Thu, May 28, 2009 at 05:37:16PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-05-27 at 18:56 +0100, Russell King wrote:
> > > 
> > > smc91x is a prime example of the kind of information drivers need - base
> > > address and irq are very much insufficient to describe how this device is
> > > connected.  There's much more information required to specify this device
> > > fully, and throwing it into the driver doesn't work.  We've been there
> > > and proven that point.
> > 
> > The device-tree is a very nice and convenient way to convey all the
> > informations the driver need straight to the driver without any platform
> > code in the middle :-)
> 
> I'm still uncertain whether that's actually a true statement.  For some
> cases, of course it's true, but I have a nasty suspicion that we have
> corner cases where OF won't cope well with.
> 
> As I see it, if we were to convert to OF, we're boxing ourselves in to
> a corner that would be extremely difficult to get out of.  We would
> never be able to step back from OF.  Lets take an example.  If we were
> to convert PXA to OF including all the PXA SoC drivers, and a board
> configuration came along which required hacks to a driver.  Later on
> we find that most platform authors are applying similar hacks because
> their hardware is subtly different but those differences can't be
> expressed via OF.  At this point, what do we do?  We can't say "well,
> OF doesn't work well on this platform, we want to get rid of it" that
> would be extremely difficult to impossible to do.
One of the really nice ability is to allow to simplify AMP support
by defining one device tree for each core where each kernel will use nealy the same
kernel. As done by Kumar for the mpc8572ds.

You can found here the boot procedure and kernel option
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=blob;f=doc/README.mpc8572ds;h=06dab596bea52ab8d8c2ba89d86f793cc4881ccb;hb=HEAD

Best Regards,
J.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Dmitry Eremin-Solenikov]

David Miller wrote:

> From: Russell King - ARM Linux
> <linux@arm.linux.org.uk> Date: Thu, 28 May 2009
> 10:15:13 +0100
> 
>> For example, how would an IrDA transceiver be expressed in OF?
> 
> As a child device node of the IRDA device, with associated properties.
> 
> You can express _ANYTHING_ using the OF device tree.  It is not even
> something to discuss, it's flexible enough.

Hmmm. How to express the following situation:
On one of my platforms (sharp tosa) the backlight controller
is separated into two parts: one sitting on SPI, one on the I2C.
The tricky part is that the I2C part is only available when some
of registers of SPI part are programmed in a specific way.

-- 
With best wishes
Dmitry

Re: [RFC] [PATCH] Device Tree on ARM platform

[Sascha Hauer]

On Wed, May 27, 2009 at 03:05:58PM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 2:52 PM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
> >> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
> >
> >> > I'm not talking about platform specific code, I'm talking about code to
> >> > retrieve information about a device from the device tree.  There would
> >> > not be separate instances of this for "platforms X, Y and Z", just one
> >> > of_platform binding in each driver.  It's no different than having a
> >> > platform bus binding, except in the data structures used.
> >
> >> I really don't see what OF buys us then, apart from additional dependencies
> >> that have to be correct for the kernel to work.  I can only see disadvantages
> >> if all OF is, is a way to pass some file to the kernel to (effectively) tell
> >> it which drivers to use.
> >
> > The main selling points of the device tree AFAICT are that some
> > platforms have to use it it anyway due to the native OS and firmware for
> > the platform use it, the possibility of using the same device tree with
> > more than one OS (modulo unrepresentable holes) and the fact that some
> > people find it more convenient to use than straight data tables
> > (personally I find the two approaches to be much of a muchness there).
> > Perhaps I'm missing something, though?
> 
> Here are some that I've find useful:
> 
> There is the advantage that it decouples the machine description from
> the kernel code, which in turn seems to encourage code reuse.  There
> has been a significant decrease in the amount of platform specific
> code in powerpc since the switch to FDT booting.
> 
> There is the advantage of easy multiplatform support.  I regularly
> build a single kernel image which boots on all my MPC5200 boards, and
> on my MPC83xx boards.

That is not necessarily an advantage of a device tree. On ARM you can
also build a kernel which runs on 20+ PXA platforms at the same time.
(And I'm sure it can be done to even support say i.MX and PXA at the
same time, but this is another story)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Holger Schurig]

> Lack of device-tree support on ARM has been a real hindrance to
> getting the ARM-based Linux support on par with PowerPC.

And I always thought that this is because Freescale does some BSP 
in the background, then release a BSP with some kernel and 
doesn't even try getting something included in "main" Linus, 
a.k.a. into Linus' tree.

Hey, but that's better then Marvell, where you need to sign an 
NDA to even access the documentation. With Freescale's doc (and 
help of the community!) I was able to get some Freescale i.MX21 
related drivers into Linus' tree.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Thu, May 28, 2009 at 5:15 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 28, 2009 at 05:37:16PM +1000, Benjamin Herrenschmidt wrote:
>> On Wed, 2009-05-27 at 18:56 +0100, Russell King wrote:
>> >
>> > smc91x is a prime example of the kind of information drivers need - base
>> > address and irq are very much insufficient to describe how this device is
>> > connected.  There's much more information required to specify this device
>> > fully, and throwing it into the driver doesn't work.  We've been there
>> > and proven that point.
>>
>> The device-tree is a very nice and convenient way to convey all the
>> informations the driver need straight to the driver without any platform
>> code in the middle :-)
>
> I'm still uncertain whether that's actually a true statement.  For some
> cases, of course it's true, but I have a nasty suspicion that we have
> corner cases where OF won't cope well with.
>
> As I see it, if we were to convert to OF, we're boxing ourselves in to
> a corner that would be extremely difficult to get out of.  We would
> never be able to step back from OF.  Lets take an example.  If we were
> to convert PXA to OF including all the PXA SoC drivers, and a board
> configuration came along which required hacks to a driver.  Later on
> we find that most platform authors are applying similar hacks because
> their hardware is subtly different but those differences can't be
> expressed via OF.  At this point, what do we do?  We can't say "well,
> OF doesn't work well on this platform, we want to get rid of it" that
> would be extremely difficult to impossible to do.
>
>
> For example, how would an IrDA transceiver be expressed in OF?
>
> Obviously it would have to start off with some sort of UART definition
> for SIR, with a separate (and sometimes unrelated in terms of register
> space and SoC pin configuration) FIR unit.  Whether FIR is used or not
> is platform specific.  So far so good, I don't see a problem yet.
>
> We then have one or two GPIOs doing some function - eg, one GPIO might
> be a simple power on/off while the other controls FIR or SIR mode in
> the transceiver itself.  Or the two lines might be a bit combination
> which selects 'off', 'on + sir', 'on + fir' modes depending on the
> transceiver used.  In the case of one GPIO it might be the mode select
> or it might be the power control.
>
> I suspect this can be expressed by having some sort of OF table specifying
> several gpios & their value for each combination of power & mode...
> except some platforms have special control registers in FPGAs which do
> not appear as GPIOs... so how are those expressed?  We have function
> pointers back into platform code to cope with this at present.
>
>
> Another example - LCD displays.  Some platforms need a certain sequence
> of GPIO activations with delays between when powering up and down the
> LCD display.  Currently we express this in the platform support file and
> pass a function pointer into the LCD Driver.  Can this be expressed with
> OF?
>
>
> Another example - backlights.  Some platforms need to twiddle a GPIO
> at a certain point in the brightness scale and reset the PWM, and they
> currently do this via an (optional) function pointer in the generic PWM
> backlight driver.  Can this be expressed with OF?
>
>
> That's just a few examples of areas where we haven't been able to describe
> platforms using pure data-based descriptions, and they're all things that
> we don't want to stuff into the individual drivers (doing so involves lots
> of ifdefs and namespace pollution - we saw that in 2.4 kernels.)
>
> In order for me to be convinced that OF is not going to cause us grief,
> I'd like to see a range of platforms converted to OF to check that we're
> not going to find any unexpected problems - eg, a load of PXA platforms,
> particularly those with the above kinds of problems.

I've also run into the problem of tying very machine specific code to
a device tree. This is coupled to the desire to have function pointer
callbacks.  I agree that this is a problem and the OF aware platforms
have the same problem. However, I don't think the problem has anything
to do with device trees, instead I believe the problem is internal to
Linux.

In general we're missing a design for a single file that holds all of
the machine specific code. There isn't any simple way right now to put
all of this code into a single file. In the current model this code
gets scattered all over the place.

If you look at arch/powerpc/platforms/... you'll find a few machine
specific files in there. That concept could be extended. After the
device tree loads, the machine specific file runs if there is one. At
that point, the machine specific code could insert function pointers
into the device tree. Later when the device drivers load they could
find these pointers and use them to implement machine specific
overrides. All of this machine specific override code would live in a
single file.

For ARM the model could be to use the machine number to load a device
tree built into the kernel (these trees would slowly migrate into the
firmware). After the device tree is selected the machine specific code
would add the override function pointers. Unified OF aware device
drivers would load using the device tree. These drivers would find the
function pointers and use them to implement machine specific features.

The function pointers also provides a way to migrate away from machine
specific code.  If we discover some machines specific code really
should be common code, the function pointer can be eliminated since
all of the support is in the kernel and not in the firmware.


>
> And no, Dave Miller saying "I've been using this for 15 years on Sparc"
> "Three architectures are using it" isn't going to convince me.  The proof
> is in the code, not the waffle.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Thu, May 28, 2009 at 12:17:32PM +0000, Dmitry Eremin-Solenikov wrote:
> David Miller wrote:
> 
> > From: Russell King - ARM Linux
> > <linux@arm.linux.org.uk> Date: Thu, 28 May 2009
> > 10:15:13 +0100
> > 
> >> For example, how would an IrDA transceiver be expressed in OF?
> > 
> > As a child device node of the IRDA device, with associated properties.
> > 
> > You can express _ANYTHING_ using the OF device tree.  It is not even
> > something to discuss, it's flexible enough.
> 
> Hmmm. How to express the following situation:
> On one of my platforms (sharp tosa) the backlight controller
> is separated into two parts: one sitting on SPI, one on the I2C.
> The tricky part is that the I2C part is only available when some
> of registers of SPI part are programmed in a specific way.

Put nodes under both the SPI and I2C busses, they have properties with
phandles to refer to each other (could be one way or both depending on
needs).  Sprinkle with any additional information properties as
necessary.  Your driver (in the broad sense, rather than the "struct
device_driver" sense) binds both devices and does what it needs to do.

The I2C part should possibly have a status property with value
"disabled" to indicate that it's not usable, until something activates
it (in this case the other part of the driver frobbing the SPI side).

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Thu, May 28, 2009 at 10:48:17PM +1000, David Gibson wrote:
> On Thu, May 28, 2009 at 12:17:32PM +0000, Dmitry Eremin-Solenikov wrote:
> > David Miller wrote:
> > 
> > > From: Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> Date: Thu, 28 May 2009
> > > 10:15:13 +0100
> > > 
> > >> For example, how would an IrDA transceiver be expressed in OF?
> > > 
> > > As a child device node of the IRDA device, with associated properties.
> > > 
> > > You can express _ANYTHING_ using the OF device tree.  It is not even
> > > something to discuss, it's flexible enough.
> > 
> > Hmmm. How to express the following situation:
> > On one of my platforms (sharp tosa) the backlight controller
> > is separated into two parts: one sitting on SPI, one on the I2C.
> > The tricky part is that the I2C part is only available when some
> > of registers of SPI part are programmed in a specific way.
> 
> Put nodes under both the SPI and I2C busses, they have properties with
> phandles to refer to each other (could be one way or both depending on
> needs).  Sprinkle with any additional information properties as
> necessary.  Your driver (in the broad sense, rather than the "struct
> device_driver" sense) binds both devices and does what it needs to do.
> 
> The I2C part should possibly have a status property with value
> "disabled" to indicate that it's not usable, until something activates
> it (in this case the other part of the driver frobbing the SPI side).

I should add, that's only one way, though it is the most obvious to me
from the information you've given.  Depending on the details of the
device other possibilities might be appropriate.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Wed, May 27, 2009 at 08:04:58PM -0400, Jon Smirl wrote:
> On Wed, May 27, 2009 at 6:24 PM, Mark Brown

> > Please read back over the original soc-of-simple thread, it goes into
> > the problems in a bit more detail.

...

> It's an evolutionary process, let's get ASoC loading all of the right
> modules first. Then we can move on to clocking, etc. I2C went through

As I have said a number of times with the exception of the AC97 the core
is basically there.  Certainly as far as loading modules goes the work
that needs doing is all at the driver level.  It'd be helpful if you'd
take this on board more - as things stand ASoC isn't doing any device
loading itself and relies on notifications from the individual drivers
that they're ready to use.

There's more stuff that needs doing in the core but I'm not going to
stop and wait for the drivers to catch up except in so much as it stops
other work - I only have the ability to test some devices and plenty of
stuff to be getting on with.  The feature is there if people want to use
it and I'm insisting on it for new CODEC drivers.

> the same process.  For example, the new efika-audio-fabric and
> pcm030-audio-fabric files should not be needed once the binding

As I have repeatedly explained to you there are particular issues with
AC97 which affect these drivers.

> When I disabled soc-of-simple that stop the autoloading of codecs on
> i2s. That needs to be fixed. Next kernel cycle I will be working on
> mpc5200 i2s.

This is going down to the individual drivers for your systems using old
device instantiation methods.  Someone needs to update the drivers.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Thu, May 28, 2009 at 02:43:21PM +0200, Holger Schurig wrote:

> Hey, but that's better then Marvell, where you need to sign an 
> NDA to even access the documentation. With Freescale's doc (and 
> help of the community!) I was able to get some Freescale i.MX21 
> related drivers into Linus' tree.

Marvell have improved greatly here compared to the situation in the past
- they are working actively on pushing things into mainline and they've
published several of their chip manuals (all the PXA2xx and PXA3xx stuff
is there, for example).

Re: [RFC] [PATCH] Device Tree on ARM platform

[Thomas Gleixner]

On Thu, 28 May 2009, Sascha Hauer wrote:
> > There is the advantage of easy multiplatform support.  I regularly
> > build a single kernel image which boots on all my MPC5200 boards, and
> > on my MPC83xx boards.
> 
> That is not necessarily an advantage of a device tree. On ARM you can
> also build a kernel which runs on 20+ PXA platforms at the same time.
> (And I'm sure it can be done to even support say i.MX and PXA at the
> same time, but this is another story)

Well, you can run it on 20+ PXA platforms which have all their own
machine number, but you have all the little details of each platform
hardcoded into the kernel.

That does not help at all when your board has 5 variants just
different in subtle details which can not be probed or enumerated by
inspection. That's a common scenario in the embedded world.

So you either have 5 board numbers and all the details harcoded again
or you add some extra magic to deduce on which variant you are running
on.

We have seen almost everything in the weirdness range from poking in
some hardcoded FLASH cells over weird command line parsers up to a XML
parser which were added to work around the limitations of the machine
number model.

With a device tree you can avoid that crap and provide a standardized
interface for such cases.

I'm not saying that the device tree will make all those problems go
away magically, but it's orders of magnitudes better than what people
do now.

There is no need to force switch all of ARM to the device tree, but
adding support for it would be a good move. Nobody wants to enforce it
and both models can live happily side by side and we'll see which
variant turns out to be the long term favourite solution.

Thanks,

	tglx

Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Thu, May 28, 2009 at 6:13 AM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> On Thu, May 28, 2009 at 11:51:26AM +0200, Wolfgang Denk wrote:
>> True. From a commercial point of view this is a huge  problem  casued
>> by the device tree - custumers who used to oder a BSP from commercial
>> service providers (like Robert or me :-) now often find that all they
>> need  to  do is to tweak the device tree to get their system running.
>> Lost business. D*mn...  [Maybe this explains Robert's reluctance?]
>
> Wolfgang, you know me long enough to realize that this argument is
> *crap*.
>
> Talking about business cases, it has turned out to be extremely
> difficult to explain customers that the effort for the actual
> functionality is only a little percentage of the work necessary to do
> the oftree stuff right. The functionality has often worked after a few
> hours, and until all oftrees have been solved, it often takes weeks.
>
> In result, this has already led to customers concluding that
>
> - mainline is not worth the effort

And as an indirect customer of yours (via Phytec) I am spending a
bunch of time submitting code you wrote to mainline. By not submitting
code to mainline you prevent me from getting to security patches that
have been made to later kernels. "port and forget" is evil should be
banned.

> - linux is overkill and one should better use cortex-bare-metal
>
> However, that is only our personal observation.
>
> rsc
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 12:34 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
>> It is inherent in the value "atmel,24c08".  Because the exact device
>> model is specified, the kernel can know what the page size and flags
>> are for that device.
>
> I am afraid this is not the case. I remember that we once had two revisions of
> the same eeprom, and the vendor decided to increase the page size without
> changing the naming of the eeprom. (Can't point to any documentation yet, would
> have to dig this up.) Those eeproms can be really weird.
>
> Also, there are _a lot_ of eeprom manufacturers out there, so the match table
> will be enormous....

... which is the whole point of "compatible".  Every possible variant
doesn't get listed in the device driver; device nodes in the tree
claim compatibility with older, already known parts.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 1:32 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Nowadays, any struct device can be linked to an OF device node thanks to
> the archdata extension that we added to the generic struct device. One
> of the idea we have in mind is to create a simple mechanism that
> "intanciate" devices based on probing them in the tree, regardless of
> the actual bus and linux device "type" (platform, PCI, i2c, ...).

Which is actually exactly what happens now for i2c, spi and (in .31)
mdio.  of_platform is the exception.  a really big elephant of an
exception, but an excpection never the less.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Thu, May 28, 2009 at 09:33:28AM -0400, Jon Smirl wrote:
> > Wolfgang, you know me long enough to realize that this argument is
> > *crap*.
> >
> > Talking about business cases, it has turned out to be extremely
> > difficult to explain customers that the effort for the actual
> > functionality is only a little percentage of the work necessary to do
> > the oftree stuff right. The functionality has often worked after a few
> > hours, and until all oftrees have been solved, it often takes weeks.
> >
> > In result, this has already led to customers concluding that
> >
> > - mainline is not worth the effort
>
> And as an indirect customer of yours (via Phytec) I am spending a
> bunch of time submitting code you wrote to mainline. By not submitting
> code to mainline you prevent me from getting to security patches that
> have been made to later kernels. "port and forget" is evil should be
> banned.

This is absurd. Check

http://remword.com/kps_result/2_6_30_whole.html
http://remword.com/kps_result/2_6_29_whole.html

and I suppose our commitment to mainlining should be out of question,
also taking into account that all of this is done by a kernel team of
six people.

Nevertheless, nobody has infinite time, sorry.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 6:17 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> David Miller wrote:
>
>> From: Russell King - ARM Linux
>> <linux@arm.linux.org.uk> Date: Thu, 28 May 2009
>> 10:15:13 +0100
>>
>>> For example, how would an IrDA transceiver be expressed in OF?
>>
>> As a child device node of the IRDA device, with associated properties.
>>
>> You can express _ANYTHING_ using the OF device tree.  It is not even
>> something to discuss, it's flexible enough.
>
> Hmmm. How to express the following situation:
> On one of my platforms (sharp tosa) the backlight controller
> is separated into two parts: one sitting on SPI, one on the I2C.
> The tricky part is that the I2C part is only available when some
> of registers of SPI part are programmed in a specific way.

Perhaps something like this (in dts format):

spi@[someaddress] {
        #size-cells = <0>;
        #address-cells = <1>;
        compatible = "name-of-spi-bus-device";
        reg = <[someaddress] [size]>;
        backlight-spi: backlight@5 {
                compatible = "sharp,backlight-spi";
                reg = <5>;  /* CS line # 5 */
        }
}

i2c@[anotheraddress] {
        #size-cells = <0>;
        #address-cells = <1>;
        compatible = "name-of-i2c-bus-device";
        reg = <[anotheraddress] [size]>;
        backlight@30 {
                compatible = "sharp,backlight-i2c";
                reg = <30>;
                spi-interface-phandle = < &backlight-spi >;
        }
}

Two nodes are used to describe the device and a "phandle" is used to
link them.  A device driver probe could be triggered (bind) against
the i2c half of the device and follow the phandle to get the rest of
the description.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Ben Dooks]

On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
> On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
> > I'm not talking about platform specific code, I'm talking about code to
> > retrieve information about a device from the device tree.  There would not
> > be separate instances of this for "platforms X, Y and Z", just one
> > of_platform binding in each driver.  It's no different than having a
> > platform bus binding, except in the data structures used.
> >
> > But to restate, having external glue to create platform devices from the
> > device tree is fine if that's what you want to do.  We used to do that, but
> > it was a pain compared to keeping everything in one place.  Your experience
> > may differ.
> 
> Could 'struct platform_device' and 'struct of_platform_device" be
> unified into a single structure? It's personal preference whether the
> internal representation of the hardware is done via a device tree or
> snippets of platform code, but do we need to have to different device
> types?

I was wondering what the pros/cons of having a system that takes a
device tree and manufactures platform devices / etc from it? I think
one of the cons is that if you change the platform device data, then
you have not only the board definitions to change, but the of->platform
code to modify as well...

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Ben Dooks]

On Wed, May 27, 2009 at 02:22:50PM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 1:39 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 20:21 Wed 27 May     , Russell King - ARM Linux wrote:
> >> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
> >> > On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
> >> > > I'm not talking about platform specific code, I'm talking about code to
> >> > > retrieve information about a device from the device tree.  There would not
> >> > > be separate instances of this for "platforms X, Y and Z", just one
> >> > > of_platform binding in each driver.  It's no different than having a
> >> > > platform bus binding, except in the data structures used.
> >> > >
> >> > > But to restate, having external glue to create platform devices from the
> >> > > device tree is fine if that's what you want to do.  We used to do that, but
> >> > > it was a pain compared to keeping everything in one place.  Your experience
> >> > > may differ.
> >> >
> >> > Could 'struct platform_device' and 'struct of_platform_device" be
> >> > unified into a single structure? It's personal preference whether the
> >> > internal representation of the hardware is done via a device tree or
> >> > snippets of platform code, but do we need to have to different device
> >> > types?
> >>
> >> That's a damned good question - platform devices have been around since
> >> the dawn of the device model, so the real question which needs to be
> >> asked is: what was the reason that of_platform_device created rather
> >> than unifying it with the already provided platform_device ?
> > I agree at 100%
> >
> > when you have to support the same driver for non OF and OF platform it's
> > really a pain in the ass
> 
> There are two issues that keep the of_platform and platform busses
> separate.  They aren't show stoppers, but they reflect the current
> state.
> 
> 1) Source of data: a platform_device carries a pdata structure with it
> to describe the hardware.  An of_device carries a device_node pointer.
>  Before dropping of_platform bus, a mechanism needs to be in place to
> add hooks for translating the device tree data into a pdata structure
> for each platform device.
> 
> 2) Driver binding mechanism:  device tree nodes usually have a
> "compatible" property which is a list of strings.  The first string
> describes exactly what the device is (ie. "atmel,24c08") and an
> optional list of other devices which it is register interface
> backwards compatible with.  The intent is that newer devices can claim
> compatibility with older ones so that existing device drivers will
> work without needing to be told the new device name.  However, it
> leaves the option when a device errata or something similar raises
> it's ugly head, a driver can still get information about the exact
> device name and apply the appropriate workarounds.  Driver probing
> should walk the list and give preference to higher priority compatible
> values.  of_platform bus does this, but I cannot think of a clean way
> to do the same thing with the platform bus.
> 
> One option that has been suggested (more than once) is to make the
> adapter code an of_platform_driver which translates the device tree
> data and then registers the appropriate platform_devices.  This neatly
> solves the problem, but I don't like the overhead involved in
> registering 2 struct devices with the kernel for every device node in
> the device tree.

Surely the code could simply run at init time, throwing away the data
and code it doesn't need once it is done?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Robert Schwebel]

On Thu, May 28, 2009 at 03:17:43PM +0100, Ben Dooks wrote:
> I was wondering what the pros/cons of having a system that takes a
> device tree and manufactures platform devices / etc from it? I think
> one of the cons is that if you change the platform device data, then
> you have not only the board definitions to change, but the of->platform
> code to modify as well...

I think a unification of both data structures would be much better than
having two of them ontop of each other.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 6:43 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, May 27, 2009 at 03:05:58PM -0600, Grant Likely wrote:
> > There is the advantage of easy multiplatform support.  I regularly
> > build a single kernel image which boots on all my MPC5200 boards, and
> > on my MPC83xx boards.
>
> That is not necessarily an advantage of a device tree. On ARM you can
> also build a kernel which runs on 20+ PXA platforms at the same time.
> (And I'm sure it can be done to even support say i.MX and PXA at the
> same time, but this is another story)

With hard coded device tables the kernel needs to be explicitly taught
about each new board, and each enabled board increases the size of the
kernel image with separate copies of the device table.  With an
external data structure, a previously unknown board can be booted
without recompiling the kernel (assuming of course that the SoC is
supported).

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 6:47 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Thu, May 28, 2009 at 5:15 AM, Russell King - ARM Linux
> For ARM the model could be to use the machine number to load a device
> tree built into the kernel (these trees would slowly migrate into the
> firmware). After the device tree is selected the machine specific code
> would add the override function pointers. Unified OF aware device
> drivers would load using the device tree. These drivers would find the
> function pointers and use them to implement machine specific features.

Nagging point: it is not encouraged to move the device tree into the
firmware.  It is useful to *pass* the device tree via the kernel, but
hard linking it in is the way of pain because it makes updates hard.
This is probably what you meant, but I wanted to clarify.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 8:17 AM, Ben Dooks <ben-linux@fluff.org> wrote:
> On Wed, May 27, 2009 at 03:13:55PM -0400, Jon Smirl wrote:
>> On Wed, May 27, 2009 at 3:08 PM, Scott Wood <scottwood@freescale.com> wrote:
>> > I'm not talking about platform specific code, I'm talking about code to
>> > retrieve information about a device from the device tree.  There would not
>> > be separate instances of this for "platforms X, Y and Z", just one
>> > of_platform binding in each driver.  It's no different than having a
>> > platform bus binding, except in the data structures used.
>> >
>> > But to restate, having external glue to create platform devices from the
>> > device tree is fine if that's what you want to do.  We used to do that, but
>> > it was a pain compared to keeping everything in one place.  Your experience
>> > may differ.
>>
>> Could 'struct platform_device' and 'struct of_platform_device" be
>> unified into a single structure? It's personal preference whether the
>> internal representation of the hardware is done via a device tree or
>> snippets of platform code, but do we need to have to different device
>> types?
>
> I was wondering what the pros/cons of having a system that takes a
> device tree and manufactures platform devices / etc from it? I think
> one of the cons is that if you change the platform device data, then
> you have not only the board definitions to change, but the of->platform
> code to modify as well...

Yes, this is the long term goal.  And not just platform devices
either, i2c, spi, mdio, etc.  The current problem is that there still
needs to be a per-driver mechanism to translate device tree data into
the correct pdata structure.  That code is not hard, but it is
undetermined what is best for where that code should live and how it
should be triggered.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 3:15 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> In order for me to be convinced that OF is not going to cause us grief,
> I'd like to see a range of platforms converted to OF to check that we're
> not going to find any unexpected problems - eg, a load of PXA platforms,
> particularly those with the above kinds of problems.

/me goes back to working on this.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Sascha Hauer]

On Thu, May 28, 2009 at 03:18:02PM +0200, Thomas Gleixner wrote:
> On Thu, 28 May 2009, Sascha Hauer wrote:
> > > There is the advantage of easy multiplatform support.  I regularly
> > > build a single kernel image which boots on all my MPC5200 boards, and
> > > on my MPC83xx boards.
> > 
> > That is not necessarily an advantage of a device tree. On ARM you can
> > also build a kernel which runs on 20+ PXA platforms at the same time.
> > (And I'm sure it can be done to even support say i.MX and PXA at the
> > same time, but this is another story)
> 
> Well, you can run it on 20+ PXA platforms which have all their own
> machine number, but you have all the little details of each platform
> hardcoded into the kernel.
> 
> That does not help at all when your board has 5 variants just
> different in subtle details which can not be probed or enumerated by
> inspection. That's a common scenario in the embedded world.

We normally hide these subtle details behind a baseboard= kernel
parameter. I agree with you that it's far better to have a standardized
way to specify this. For my taste the oftree is too bloated for this
purpose.

> 
> So you either have 5 board numbers and all the details harcoded again
> or you add some extra magic to deduce on which variant you are running
> on.
> 
> We have seen almost everything in the weirdness range from poking in
> some hardcoded FLASH cells over weird command line parsers up to a XML
> parser which were added to work around the limitations of the machine
> number model.
> 
> With a device tree you can avoid that crap and provide a standardized
> interface for such cases.
> 
> I'm not saying that the device tree will make all those problems go
> away magically, but it's orders of magnitudes better than what people
> do now.
> 
> There is no need to force switch all of ARM to the device tree, but
> adding support for it would be a good move. Nobody wants to enforce it
> and both models can live happily side by side and we'll see which
> variant turns out to be the long term favourite solution.

Having it as an optional feature seems a good idea for the same reasons
you mentioned. I just wonder how optional it can be once a board
maintainer and a person sending patches disagree on whether to use oftree
or not.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Thomas Gleixner]

On Thu, 28 May 2009, Sascha Hauer wrote:
> > That does not help at all when your board has 5 variants just
> > different in subtle details which can not be probed or enumerated by
> > inspection. That's a common scenario in the embedded world.
> 
> We normally hide these subtle details behind a baseboard= kernel
> parameter. I agree with you that it's far better to have a standardized
> way to specify this. For my taste the oftree is too bloated for this
> purpose.

Well, with the baseboard= you still have to hack the details into the
kernel, which just adds code which needs to be maintained. I really
can do without 20 different platform structs and switch cases which
init GPIOs if there is an elegant way to describe the pin routing and
such. If you get your configuration out of OF tree then you can handle
this w/o even touching the kernel in most cases.

> > There is no need to force switch all of ARM to the device tree, but
> > adding support for it would be a good move. Nobody wants to enforce it
> > and both models can live happily side by side and we'll see which
> > variant turns out to be the long term favourite solution.
> 
> Having it as an optional feature seems a good idea for the same reasons
> you mentioned. I just wonder how optional it can be once a board
> maintainer and a person sending patches disagree on whether to use oftree
> or not.

As always it will be discussed on technical grounds. :)

Thanks,

	tglx

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

Just a request:

I'm not sure exactly who it is (I think it's Dmitry) but this sub-thread
has had the list of addresses to be sent copies totally managled to the
extent that some posts aren't making it even to my mailing list server
or my address.

Grant - I assume you added linux-arm-kernel back yourself for your
reply?

I think Dmitry uses gmane - maybe gmane only supports posting to one
list at a time?

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 10:53 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Just a request:
>
> I'm not sure exactly who it is (I think it's Dmitry) but this sub-thread
> has had the list of addresses to be sent copies totally managled to the
> extent that some posts aren't making it even to my mailing list server
> or my address.
>
> Grant - I assume you added linux-arm-kernel back yourself for your
> reply?

No, I didn't muck with the cc: list at all.  I've been blindly
clicking "reply-to-all".

It sounds like you've received my reply to dmitry's email, but not
dmitry's email, correct?

All of the emails from Dmitry I see here on my end include both
linux-kernel and linux-arm-kernel in the cc: list.

g.

> I think Dmitry uses gmane - maybe gmane only supports posting to one
> list at a time?
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Alexander Clouter]

In gmane.linux.kernel Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> Just a request:
> 
> I'm not sure exactly who it is (I think it's Dmitry) but this sub-thread
> has had the list of addresses to be sent copies totally managled to the
> extent that some posts aren't making it even to my mailing list server
> or my address.
> 
> Grant - I assume you added linux-arm-kernel back yourself for your
> reply?
> 
> I think Dmitry uses gmane - maybe gmane only supports posting to one
> list at a time?
>
I'll confess I am a GMANE weenie but I have been following up to all 
threads; but I'm pretty sure the email CC's are getting lost.  I was 
always part of the LKML and the ARM list; just to keep my part of the 
thread going I became a member of 'devicetree'.

If you think the problem exists with me and I could be the problem, let 
me know :)

Cheers

-- 
Alexander Clouter
.sigmonster says: History books which contain no lies are extremely dull.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date: Thu, 28 May 2009 11:14:40 +0100

> If you have anything _usefully_ technical to contribute then please do.
> Otherwise, shut up.

I did, I said:

>> As a child device node of the IRDA device, with associated
>> properties.

You can ignore what I say, and that is your choice.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 08:13 -0600, Grant Likely wrote:
> Two nodes are used to describe the device and a "phandle" is used to
> link them.  A device driver probe could be triggered (bind) against
> the i2c half of the device and follow the phandle to get the rest of
> the description.

One thing I wouldn't do though is to put "phandle" in the property
name :-) Just call it spi-interface.

Now, that's an option. And it works to a certain extent. But I do
understand the need in general to provide "methods". It's something
we don't solve (but then we don't make it worse than it was before).

I think the cleanest option might be named methods in the device-tree
for example, a device can have an "enable-method" property and a
"clock-method" property. The names would use the usual convention
of "manuf,name" to avoid clashes and could be registered by the
platform.

Now, it -does- somewhat deviates from the moto that the DT should
only contain OS agnostic HW representations, but appart for having
a full blown OF with actual method calls in each nodes I don't
see a nicer way at this stage.

Now, the methods could then take "informations" from the target DT.

For example, one could have a generic "simple-gpio-enable" method that
can be used as "enable-method" anywhere, as long as the target device
contains also a "enable-gpio" property that points to the actual GPIO
(and maybe an "enable-delay" while at it).

IE. We can provide a collection of "simple" methods that handle
the easy cases in library code.

I'm very much against putting actual function pointers in the tree
though as Jon Smirl proposed.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 4:37 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 05:15:25PM -0700, David Miller wrote:
>> From: Robert Schwebel <r.schwebel@pengutronix.de>
>
>> > It works badly for corner cases, and embedded land is full
>> > of it. The effort to get the oftree stuff right is often more than a
>> > magnitude of order higher than the effort for the actual functionality.
>> > That should be an alarm sign that something is wrong.
>
>> And here you speak about the negatives purely in generalities that
>> cannot be discussed concretely.
>
>> And, sadly, I think this is on purpose.
>
> A concrete example that was mentioned elsewhere in the thread is audio
> subsystems.  The audio subsystem for an embedded system will contain
> multiple chips - a mobile phone could have the CPU, an audio CODEC,
> bluetooth and GSM for example.  These will be interconnected by a
> combination of analogue and digital links.  The digital links consist of
> six wires (data, sync clock and bit clock for each of transmit and
> recieve), some of which may be tied together in hardware.  Some of these
> links may be shared either with switches or using TDM.  The devices will
> also have master clocks from various sources and will often have PLLs or
> FLLs able to generate clocks if the inputs aren't directly usable.  Each
> clock domain within the audio subsystem will need some level of
> synchronisation of the clocks and there may be multiple clock domains
> within the system.
>
> In principle we could describe the links between the devices, provide
> some additional use case based constraints then take this information
> and figure out a suitable runtime configuration automatically; this is
> probably the only viable OS neutral way of doing things.  In practice
> we're nowhere near having a clock framework which is able to support
> implementing this.
>
> The current approach is to write custom code that knows a suitable way
> to set things up in a given system (which is a much more tractable
> problem).  The PowerPC people have mostly accepted using this approach
> but they're really not happy with it and it's been difficult to get the
> general community understanding that it's hard to cope with this in the
> device tree.

I should clarify my position.  I want to make sure the simple things
are described in the device tree and have a generic block of code in
the kernel that can wire them up (the whole simple-of thing is a hacky
and half-assed example of this).  However, when it comes to complex
configurations that cannot be easily described, I'm all for using
platform specific code.

In fact, I may have been premature in pursuing the generic description
and generic fabric driver approach for the MPC5200 audio driver.  It
may have been better to get a few similar MPC5200 boards under our
belt before trying to identifying the common cases.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 11:34 +0100, Russell King - ARM Linux wrote:
> On Thu, May 28, 2009 at 08:11:33PM +1000, Benjamin Herrenschmidt wrote:
> > Well, that example is interesting because you may not want the
> > transceiver to be a child of the UART :-) The tree hierachy is mostly
> > about addressing, and addressing below a UART doesn't mean much.
> > 
> > So if the transceiver has a bunch of MMIO registers, it might be better
> > off located elsewhere, and have the UART have a "fir-transceiver"
> > property with a phandle to the actual device...
> 
> IrDA transceivers do not have MMIO registers.  Transceivers are an IR
> LED, an IR phototransitor andr receiver circuitry.  They're typically
> 9 pin devices with power, ground, transmit, receive and a bunch of
> control signals.

Right, I'm used to those transceivers. For some reason I read from your
previous post that you had such a transceiver with registers. But it
doesn't matter much, it's a valid example of how you can go "accross"
the base hierarchy of the tree if needs be.

In the case of a simple transciever like the ones controlled by GPIOs or
via bit banging on flow control lines, yes, it would probably be a child
of the UART node, eventually with properties describing which GPIOs
(via phandles to GPIO nodes for example) are used to configure it.

I think the -root- of the discussion at this stage is really the problem
of providing those "methods" for power control, clock control, or other
similar housekeeping things. I think the device-tree doesn't make things
better or worse per se, and unless there's an actual live OF
implementation underneath (in which case nodes do have methods you can
call into via OF callbacks), then the device-tree doesn't provide an
automatic way of solving that. But we can invent one :-)

> The kind of reply I was hoping to get to my email was something more
> along these lines - an informed view giving an idea how some of these
> issues would be addressed with an OF device tree.
> 
> I can see how the named functions/directory would work - that seems to
> be relatively simple and straight forward.

Right. It deviates a bit from the idea that the device-tree should be
agnostic to the operating system and only represent the HW layout, but
I'm no religious fanatic and I think it might be a very good compromise.

In many case, sets of "standard" methods could be provided by the kernel
that use properties in the target node as arguments. For example, things
like "simple-enable-gpio" and "simple-reset-gpio" could be generically
provided, using properties such as "enable-gpio" (phandle to a GPIO
node), "enable-delay" (integer duration) etc... in the target node as
"arguments". The platform can then register the more fancy onces it
needs.

> However, the pseudo-device approach I'm less clear about.  With a separate
> driver for the "power control" pseudo-device, how would you communicate
> the state information down to that driver?

It depends. It doesn't have to be "pseudo" actually... in the case of
backlight, one could have a node for backlight control and a real driver
binding to it that just does backlight control. The linkage between that
and the main LCD driver, if necessary, can be done via phandle links in
the tree, and recovering the driver from the node (a bit tricky but
doable).

> I am equating OF devices and drivers too much with the struct device and
> struct driver model, which sounds like it's not the best thing to do with
> OF.

Well, it depends really. Mostly we -do- end up with a struct device for
a node ... but it's not necessarily always true.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 17:04 +0200, Sascha Hauer wrote:
> 
> We normally hide these subtle details behind a baseboard= kernel
> parameter. I agree with you that it's far better to have a
> standardized
> way to specify this. For my taste the oftree is too bloated for this
> purpose.

Define "bloated" ?

We got a lot of push back on powerpc initially with this exact same
argument "too bloated" but that was never backed up with facts and
numbers, and I would mostly say that nobody makes it anymore now
that it's there and people use it.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Gibson]

On Fri, May 29, 2009 at 08:21:58AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-28 at 08:13 -0600, Grant Likely wrote:
> > Two nodes are used to describe the device and a "phandle" is used to
> > link them.  A device driver probe could be triggered (bind) against
> > the i2c half of the device and follow the phandle to get the rest of
> > the description.
> 
> One thing I wouldn't do though is to put "phandle" in the property
> name :-) Just call it spi-interface.
> 
> Now, that's an option. And it works to a certain extent. But I do
> understand the need in general to provide "methods". It's something
> we don't solve (but then we don't make it worse than it was before).
> 
> I think the cleanest option might be named methods in the device-tree
> for example, a device can have an "enable-method" property and a
> "clock-method" property. The names would use the usual convention
> of "manuf,name" to avoid clashes and could be registered by the
> platform.
> 
> Now, it -does- somewhat deviates from the moto that the DT should
> only contain OS agnostic HW representations, but appart for having
> a full blown OF with actual method calls in each nodes I don't
> see a nicer way at this stage.

But then another OS can also understand those names and at least use
them to figure out what procedures it needs.  That's not fundamentally
different from the fact that the device tree doesn't provide drivers -
if a node has a certain compatible value, you just have to know how to
drive it based on that.

Note that ePAPR (a new standard for firmware/OS interface on embedded
powerpc machines) already has a small example of this approach.  We
add an "enable-method" property in the cpu nodes to indicate how
secondary cpus should be started up.  One basic, least common
denominator method is defined in the standard, but it's kind of
crappy, so it's expected that vendor and/or platform specific methods
will be used most of the time - in order to boot such a machine, the
OS just has to know how to implement that method.

Also note that there are certainly circumstances where it's reasonable
to have a device node representing nothing more than a tangle of wires
between a couple of other devices.  In this case the compatible
property as usual selects a "driver" for the device (in practice
usually folded into some other driver) which can handle peculiar
routing or other fiddling things such as you describe.

> Now, the methods could then take "informations" from the target DT.
> 
> For example, one could have a generic "simple-gpio-enable" method that
> can be used as "enable-method" anywhere, as long as the target device
> contains also a "enable-gpio" property that points to the actual GPIO
> (and maybe an "enable-delay" while at it).
> 
> IE. We can provide a collection of "simple" methods that handle
> the easy cases in library code.
> 
> I'm very much against putting actual function pointers in the tree
> though as Jon Smirl proposed.

-- 
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

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mitch Bradley]

I have an embeddable FCode interpreter that could be built into a 
kernel.  Perhaps it's time to resurrect that.  The total size is on the 
order of 50K with debugging tools included; probably more like 35K if 
stripped down to just the essentials.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Fri, 2009-05-29 at 09:59 +0800, Mitch Bradley wrote:
> I have an embeddable FCode interpreter that could be built into a 
> kernel.  Perhaps it's time to resurrect that.  The total size is on the 
> order of 50K with debugging tools included; probably more like 35K if 
> stripped down to just the essentials.

It's interesting... might be an option. I tend to prefer myself having
the methods be properly documented by the HW designer, and implemented
as C code in the kernel, for various reasons.

There are pro and cons to both approaches. We could define special
properties to embed f-code in the device-tree and run it that way, it's
probably a more business-friendly method :-) IE. It makes it possible
to completely avoid board specific code in the kernel, possibly making
it feasible to run existing distributions on new HW to a certain
extend by just updating those scripts.

But it comes with some drawbacks too... too often, this stuff will
replace good documentation, the scripts provided by the FW will be
busted in subtle ways that the kernel will have to work around, and thus
it can be used as a way to avoid documenting or open sourcing things and
obfuscating operations.

So at this stage, my personal preference goes for well defined methods
named by the device tree and implemented by the kernel natively. But
people are free to disagree with me on this one.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 29 May 2009 13:52:16 +1000

> But it comes with some drawbacks too... too often, this stuff will
> replace good documentation, the scripts provided by the FW will be
> busted in subtle ways that the kernel will have to work around, and thus
> it can be used as a way to avoid documenting or open sourcing things and
> obfuscating operations.

We'll have all of the down sides of ACPI if we start doing stuff
like this.

Keep FCODE execution in the firmware itself, thanks.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Mitch Bradley <wmb@firmworks.com>
Date: Fri, 29 May 2009 09:59:37 +0800

> I have an embeddable FCode interpreter that could be built into a
> kernel.  Perhaps it's time to resurrect that.  The total size is on
> the order of 50K with debugging tools included; probably more like 35K
> if stripped down to just the essentials.

If you have a GPL'd OF tokenizer in there I'll give you a big
wet kiss. :-)

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Thu, 2009-05-28 at 21:11 -0700, David Miller wrote:
> From: Mitch Bradley <wmb@firmworks.com>
> Date: Fri, 29 May 2009 09:59:37 +0800
> 
> > I have an embeddable FCode interpreter that could be built into a
> > kernel.  Perhaps it's time to resurrect that.  The total size is on
> > the order of 50K with debugging tools included; probably more like 35K
> > if stripped down to just the essentials.
> 
> If you have a GPL'd OF tokenizer in there I'll give you a big
> wet kiss. :-)

openbios doesn't have one ?

Cheers
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 29 May 2009 14:56:01 +1000

> On Thu, 2009-05-28 at 21:11 -0700, David Miller wrote:
>> From: Mitch Bradley <wmb@firmworks.com>
>> Date: Fri, 29 May 2009 09:59:37 +0800
>> 
>> > I have an embeddable FCode interpreter that could be built into a
>> > kernel.  Perhaps it's time to resurrect that.  The total size is on
>> > the order of 50K with debugging tools included; probably more like 35K
>> > if stripped down to just the essentials.
>> 
>> If you have a GPL'd OF tokenizer in there I'll give you a big
>> wet kiss. :-)
> 
> openbios doesn't have one ?

It's MIT/BSD licensed.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Sascha Hauer]

On Fri, May 29, 2009 at 10:51:14AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-28 at 17:04 +0200, Sascha Hauer wrote:
> > 
> > We normally hide these subtle details behind a baseboard= kernel
> > parameter. I agree with you that it's far better to have a
> > standardized
> > way to specify this. For my taste the oftree is too bloated for this
> > purpose.
> 
> Define "bloated" ?

I don't mean bloated in terms of kbytes but bloated in terms of complex
code used to parse the device tree. I more than once put information in
the device tree and wondered where this information got lost on the way
to the driver where I wanted to use it. Back on ARM I was very happy to
just have a simple board file which is easier for me to understand and
maintain.
Of course this can be solved with /me learning more about the device
tree, that's why I said 'for my taste'.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

On Fri, 2009-05-29 at 09:52 +0200, Sascha Hauer wrote:
> 
> I don't mean bloated in terms of kbytes but bloated in terms of complex
> code used to parse the device tree. I more than once put information in
> the device tree and wondered where this information got lost on the way
> to the driver where I wanted to use it. Back on ARM I was very happy to
> just have a simple board file which is easier for me to understand and
> maintain.
> Of course this can be solved with /me learning more about the device
> tree, that's why I said 'for my taste'.

Well, the code to walk it is trivial since once 'expanded' we reproduce
the tree structure with pointers.

Now, the problem indeed is how do you get to your node from a driver,
and that's where we are making things easy on powerpc by sticking the
node pointer in the struct device itself.

Of course that needs to be populated properly. We have code in PCI to do
it that would need to be ported over for PCI stuff (but I recommend
waiting a bit as this code is currently different on ppc32 and ppc64, a
bit messy, and Kumar is currently working on cleaning that up and
unifying it), and when device are discovered and instanciated from the
DT in the first place, then this is naturally populated.

So I don't think this is a big issue, and the amount of code involved is
relatively small and self contained.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Thu, May 28, 2009 at 04:32:40PM -0600, Grant Likely wrote:

> and half-assed example of this).  However, when it comes to complex
> configurations that cannot be easily described, I'm all for using
> platform specific code.

Indeed, and I do appreciate this.  The problem in the audio area is more
when new people come along since everyone working with the device tree
expects to be able to use the device tree to cover everything which
means going round things again and explaining how non-trivial that would
be.

> In fact, I may have been premature in pursuing the generic description
> and generic fabric driver approach for the MPC5200 audio driver.  It
> may have been better to get a few similar MPC5200 boards under our
> belt before trying to identifying the common cases.

Sure.  My only big concern with it is that it compeltely sidesteps
clocking decisions so there's a lot of codecs it's not going to be
immediately useful with and I don't have a clear idea how it could be
extended to be so.  Most other things look like they can be added on
fairly easily when required.

It'd also be nice if there were a way for systems to say that they're
able to use it but that's getting back to the whole OS-specifics in the
device tree thing.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Benjamin Herrenschmidt]

> Sure.  My only big concern with it is that it compeltely sidesteps
> clocking decisions so there's a lot of codecs it's not going to be
> immediately useful with and I don't have a clear idea how it could be
> extended to be so.  Most other things look like they can be added on
> fairly easily when required.

Regarding clocks ...

Paulus and I had a discussion the other day and he mentioned a very good
idea to represent the clock net in the device-tree.

Basically, do it just like the interrupts.

IE. A device would have a "clocks" property that contain a certain
amount of cells representing a clock source in a clock provider, itself
identified by a "clock-parent" property (default to the actual node
parent). Clock providers would have a #clock-cells to provide the number
of cells a in the "clocks" property for each clock source.

Actually, we could be a little bit smarter since clocks are more messy
than interrupts, and define "clocks" to be a serie of clock-parent
phandle and clock id within that parent. The clock id size is still
represented by the #clock-cells of the clock parent, but we avoid the
pitfall of the interrupt routing that makes it hard to connect to
multiple different PICs.

That would provide the routing, without actual values or capabilities of
each clock, that's orthogonal. But that would allow driver to easily
find their clock "provider" and we could thus provide some simple
infrastructure to register drivers or handlers to perform actions on
those clocks, such as refcounting users, etc...

It may also be useful to define properties in the clock controllers
themselves mapping clock IDs to actual frequencies or things like that
but I'm only half convinced here. IE. Let's start by defining the
-wiring- and leave the -values- (on,off, slewing, freq adjustement,
spreading) to an API between drivers and clock providers for now.

Maybe later with experience with can find good ways to extend the
device-tree representiation to provide actual clock settings and/or
tables.

Cheers,
Ben.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Sat, May 30, 2009 at 07:52:46PM +1000, Benjamin Herrenschmidt wrote:
> 
> > Sure.  My only big concern with it is that it compeltely sidesteps
> > clocking decisions so there's a lot of codecs it's not going to be
> > immediately useful with and I don't have a clear idea how it could be
> > extended to be so.  Most other things look like they can be added on
> > fairly easily when required.
> 
> Regarding clocks ...
> 
> Paulus and I had a discussion the other day and he mentioned a very good
> idea to represent the clock net in the device-tree.

I think the first thing to do is to get an accurate description of the
problem before thinking about how to come up with solutions.  I saw
that this kept coming up in Mark's emails, so I asked him about it
in private.

There are several issues surrounding clock stuff which he's seeing:

1. implementers of the clock API which have not been subject to my
   rigorous review abuse it to the point of making the API essentially
   useless, and that causes Mark problems.

   This basically comes down to people trying to uniquely name every
   single clock, and use just the name to do the lookup, ignoring the
   struct device.  This approach, really, does not work and makes the
   API pointless.

2. inter-relationships between several clocks.  To take his example,
   for clocking a DAC and ADC, you may have three clocks (dac_clk,
   adc_clk and bclk).  You may want dac_clk to be xkHz, adc_clk ykHz
   and bclk (which could well be related to both) to be zkHz.  For
   each of these, you might be able to accept an error of so-many-
   percent.

I believe (2) is an entirely separate problem to the device tree, and
really shouldn't concern the device tree beyond, maybe, providing the
contraints for individual clock _sources_.

(1) on the other hand is related, but is not really a device tree problem.
It's a problem with the way people use the API (even though that wrong
usage is explicitly documented as being wrong, this doesn't stop people
being lazy.)

I hadn't been doing the rigorous review of implementations on ARM as they
come in, in the interests of getting platform support into the kernel.
However, earlier this year I came up with a solution to this (clkdev) and
implemented it initially for the platforms I had, and later extended it to
the most complex ARM platform we have - OMAP.

clkdev doesn't stop the abuse per-se, but it _does_ make it damned easy
to change the lookup relationships, even build new relationships at run
time - which I can see will be an advantage to device tree stuff.

To put it another way, the conversion from broken-clk-get implementation
to clkdev is very simple and localised - you can use clkdev to continue
matching by clock connection name.  Once you've made that step, you can
then go through the drivers, one by one, fixing them and updating the
table.

Unlike previous attempts at putting a set of generic code behind the clk
API, clkdev does not place any requirements on the contents of struct clk.
To do so is fundamentally wrong - firstly, a struct clk is merely what the
clk_get API returns to represent the desired clock as a cookie, and
secondly, it has always been intended for there to be a many-to-one
relationship between the arguments to clk_get() and the returned cookie.

At the moment, clkdev lives in the ARM architecture, which seemed like a
sane place while it proves itself.  Moving it out into generic code is
the next step in its evolution - but I'm certainly not going to play
bun-fights with people over non-ARM clk API implementations, so it's
something other people will need to convert over to.

> It may also be useful to define properties in the clock controllers
> themselves mapping clock IDs to actual frequencies or things like that
> but I'm only half convinced here. IE. Let's start by defining the
> -wiring- and leave the -values- (on,off, slewing, freq adjustement,
> spreading) to an API between drivers and clock providers for now.

We have an API for that already (see above).

Re: [RFC] [PATCH] Device Tree on ARM platform

[Pavel Machek]

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f430e15..b0ee851 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -158,6 +158,17 @@ config ARCH_MTD_XIP
>  config GENERIC_HARDIRQS_NO__DO_IRQ
>  	def_bool y
>  
> +config OF
> +        def_bool y
> +
> +config PROC_DEVICETREE
> +        bool "Support for device tree in /proc"

It certainly should not be in /proc.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Sat, May 30, 2009 at 11:21:53AM +0100, Russell King - ARM Linux wrote:

> I think the first thing to do is to get an accurate description of the
> problem before thinking about how to come up with solutions.  I saw
> that this kept coming up in Mark's emails, so I asked him about it
> in private.

I have had these discussions in one form or another several times so
I've not really been going into any of the issues in enormous detail in
this thread.

> 2. inter-relationships between several clocks.  To take his example,
>    for clocking a DAC and ADC, you may have three clocks (dac_clk,
>    adc_clk and bclk).  You may want dac_clk to be xkHz, adc_clk ykHz
>    and bclk (which could well be related to both) to be zkHz.  For
>    each of these, you might be able to accept an error of so-many-
>    percent.

More generally this is a desire for a framework which can take the set
of clocks and constraints on them and automatically implement a viable
configuration for the system.  Since there are tradeoffs involved it's
not as straightfoward as it might be.  The things that give me headaches
when I consider this include:

 - PLLs/FLLs with varying degrees of configurability are available on
   some devices but burn power when used (this is one of the issues with
   the accuracy consideration you mention).
 - Many of the clocks can be either an input or an output.
 - Pretty much any aspect of the desired configuration can change at run
   time based on any part of the system - some of it is policy.

Within any one system there are normally simplifying assumptions which
make life a lot easier but these aren't available to generic code.

I think this is a solvable problem but it's not trivial and depends on
the clock API implementation improvements you have mentioned - since the
audio clocking is generally tied into the rest of the system clocking a
free standing solution is not going to cover everything.

> I believe (2) is an entirely separate problem to the device tree, and
> really shouldn't concern the device tree beyond, maybe, providing the
> contraints for individual clock _sources_.

That's not the impression that a lot of the device tree users give - the
expectation people seem to have is that they can put all the system
configuration that needs to be done into the device tree.  This means
that we end up needing to be able to either have software that can
decide the configuration for itself or be able to express the various
options in the device tree so that the configuration can be handed to
the kernel that way.  Given the whole OS neutrality thing I'm not sure
how far we can go beyond simply describing the hardware which tends to
suggest that automatic configuration is going to be needed to make
people happy.

> (1) on the other hand is related, but is not really a device tree problem.
> It's a problem with the way people use the API (even though that wrong
> usage is explicitly documented as being wrong, this doesn't stop people
> being lazy.)

I agree entirely with this; while there's work to do in this area I
don't see any fundamental problem with describing clock trees in either
the kernel or a device tree style format.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Kyle Moffett]

On Sat, May 30, 2009 at 7:22 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index f430e15..b0ee851 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -158,6 +158,17 @@ config ARCH_MTD_XIP
>>  config GENERIC_HARDIRQS_NO__DO_IRQ
>>       def_bool y
>>
>> +config OF
>> +        def_bool y
>> +
>> +config PROC_DEVICETREE
>> +        bool "Support for device tree in /proc"
>
> It certainly should not be in /proc.

There is unfortunately a relatively large legacy base of existing
tools which depend on the device-tree (specifically, the
representation of the OF device tree that the kernel generates at
boot-time) present in proc, especially on platforms (PowerPC/Sparc)
which have a real OpenFirmware implementation.

On the other hand, since this is a new port, we can just assume that
(for this port) we're going to fix the tools to use a different path.

Cheers,
Kyle Moffett

Re: [RFC] [PATCH] Device Tree on ARM platform

[David Miller]

From: Kyle Moffett <kyle@moffetthome.net>
Date: Sat, 30 May 2009 21:29:56 -0400

> On the other hand, since this is a new port, we can just assume that
> (for this port) we're going to fix the tools to use a different path.

I don't see any benefit from putting it somewhere else if existing
platforms already, especially wrt. reuse of existing tools and
bootup mount scripts.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

For what its worth, here's a review of this patch.

On Wed, May 27, 2009 at 03:08:03PM +0800, Janboe Ye wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f430e15..b0ee851 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -158,6 +158,17 @@ config ARCH_MTD_XIP
>  config GENERIC_HARDIRQS_NO__DO_IRQ
>  	def_bool y
>  
> +config OF
> +        def_bool y

We really don't want OF enabled for all ARM platforms, the vast majority
don't use it.  It would be far better to only enable it for those classes
of machines which (eventually) support it, otherwise it's just needless
bloat.

> +
> +config PROC_DEVICETREE
> +        bool "Support for device tree in /proc"
> +        depends on PROC_FS
> +        help
> +          This option adds a device-tree directory under /proc which contains
> +          an image of the device tree that the kernel copies from Open
> +          Firmware or other boot firmware. If unsure, say Y here.
> +
>  if OPROFILE
>  
>  config OPROFILE_ARMV6
> @@ -1231,6 +1242,8 @@ menu "Device Drivers"
>  
>  source "drivers/base/Kconfig"
>  
> +source "drivers/of/Kconfig"
> +
>  source "drivers/connector/Kconfig"
>  
>  if ALIGNMENT_TRAP || !CPU_CP15_MMU
> diff --git a/arch/arm/include/asm/of_device.h b/arch/arm/include/asm/of_device.h
> new file mode 100644
> index 0000000..6317713
> --- /dev/null
> +++ b/arch/arm/include/asm/of_device.h
> @@ -0,0 +1,32 @@
> +#ifndef _ASM_POWERPC_OF_DEVICE_H
> +#define _ASM_POWERPC_OF_DEVICE_H

This isn't PowerPC.

> +#ifdef __KERNEL__
> +
> +#include <linux/device.h>
> +#include <linux/of.h>
> +
> +/*
> + * The of_device is a kind of "base class" that is a superset of
> + * struct device for use by devices attached to an OF node and
> + * probed using OF properties.
> + */
> +struct of_device {
> +	struct device_node	*node;		/* to be obsoleted */
> +	u64			dma_mask;	/* DMA mask */
> +	struct device		dev;		/* Generic device interface */
> +};
> +
> +extern struct of_device *of_device_alloc(struct device_node *np,
> +					 const char *bus_id,
> +					 struct device *parent);
> +
> +extern int of_device_uevent(struct device *dev,
> +			    struct kobj_uevent_env *env);

Both of these don't appear to be defined or used in this patch, are
these prototypes necessary?

> +
> +static inline int of_node_to_nid(struct device_node *device)
> +{
> +	return 0;
> +}
> +
> +#endif /* __KERNEL__ */
> +#endif /* _ASM_POWERPC_OF_DEVICE_H */
> diff --git a/arch/arm/include/asm/of_platform.h b/arch/arm/include/asm/of_platform.h
> new file mode 100644
> index 0000000..53b4650
> --- /dev/null
> +++ b/arch/arm/include/asm/of_platform.h
> @@ -0,0 +1,39 @@
> +#ifndef _ASM_POWERPC_OF_PLATFORM_H
> +#define _ASM_POWERPC_OF_PLATFORM_H

Also not PowerPC.

> +/*
> + *    Copyright (C) 2006 Benjamin Herrenschmidt, IBM Corp.
> + *			 <benh@kernel.crashing.org>
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU General Public License
> + *  as published by the Free Software Foundation; either version
> + *  2 of the License, or (at your option) any later version.
> + *
> + */
> +
> +/* Platform drivers register/unregister */
> +static inline int of_register_platform_driver(struct of_platform_driver *drv)
> +{
> +	return of_register_driver(drv, &of_platform_bus_type);
> +}
> +static inline void of_unregister_platform_driver(struct of_platform_driver *drv)
> +{
> +	of_unregister_driver(drv);
> +}

Not sure why this isn't generic code.

> +
> +/* Platform devices and busses creation */
> +extern struct of_device *of_platform_device_create(struct device_node *np,
> +						   const char *bus_id,
> +						   struct device *parent);

Doesn't appear to be defined or used in this patch, is this prototype
necessary?

> +/* pseudo "matches" value to not do deep probe */
> +#define OF_NO_DEEP_PROBE ((struct of_device_id *)-1)
> +
> +extern int of_platform_bus_probe(struct device_node *root,
> +				 const struct of_device_id *matches,
> +				 struct device *parent);
> +
> +extern struct of_device *of_find_device_by_phandle(phandle ph);
> +
> +extern void of_instantiate_rtc(void);

These three don't appear to be defined or used in this patch, are
they necessary?

> +
> +#endif	/* _ASM_POWERPC_OF_PLATFORM_H */
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> new file mode 100644
> index 0000000..8105074
> --- /dev/null
> +++ b/arch/arm/include/asm/prom.h
> @@ -0,0 +1,367 @@
> +#ifndef _POWERPC_PROM_H
> +#define _POWERPC_PROM_H

ARM, not PowerPC.

> +#ifdef __KERNEL__
> +
> +/*
> + * Definitions for talking to the Open Firmware PROM on
> + * Power Macintosh computers.

As far as I know, we don't have an OF PROM to talk to in any ARM machine.
Is this file relevent for ARM?  Maybe it's misnamed?

> + *
> + * Copyright (C) 1996-2005 Paul Mackerras.
> + *
> + * Updates for PPC64 by Peter Bergner & David Engebretsen, IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +#include <linux/types.h>
> +#include <linux/proc_fs.h>
> +#include <linux/platform_device.h>
> +#include <asm/irq.h>
> +#include <asm/atomic.h>

I don't see anything using atomic stuff in here, but I do see bitops,
which seems to be missing from the include list above.

> +
> +#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT	1
> +#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT	1
> +
> +#define of_compat_cmp(s1, s2, l)	strcasecmp((s1), (s2))
> +#define of_prop_cmp(s1, s2)		strcmp((s1), (s2))
> +#define of_node_cmp(s1, s2)		strcasecmp((s1), (s2))
> +
> +/* Definitions used by the flattened device tree */
> +#define OF_DT_HEADER		0xd00dfeed	/* marker */
> +#define OF_DT_BEGIN_NODE	0x1		/* Start of node, full name */
> +#define OF_DT_END_NODE		0x2		/* End node */
> +#define OF_DT_PROP		0x3		/* Property: name off, size,
> +						 * content */
> +#define OF_DT_NOP		0x4		/* nop */
> +#define OF_DT_END		0x9
> +
> +#define OF_DT_VERSION		0x10
> +
> +/*
> + * This is what gets passed to the kernel by prom_init or kexec
> + *
> + * The dt struct contains the device tree structure, full pathes and
> + * property contents. The dt strings contain a separate block with just
> + * the strings for the property names, and is fully page aligned and
> + * self contained in a page, so that it can be kept around by the kernel,
> + * each property name appears only once in this page (cheap compression)
> + *
> + * the mem_rsvmap contains a map of reserved ranges of physical memory,
> + * passing it here instead of in the device-tree itself greatly simplifies
> + * the job of everybody. It's just a list of u64 pairs (base/size) that
> + * ends when size is 0
> + */
> +struct boot_param_header {
> +	u32	magic;			/* magic word OF_DT_HEADER */
> +	u32	totalsize;		/* total size of DT block */
> +	u32	off_dt_struct;		/* offset to structure */
> +	u32	off_dt_strings;		/* offset to strings */
> +	u32	off_mem_rsvmap;		/* offset to memory reserve map */
> +	u32	version;		/* format version */
> +	u32	last_comp_version;	/* last compatible version */
> +	/* version 2 fields below */
> +	u32	boot_cpuid_phys;	/* Physical CPU id we're booting on */
> +	/* version 3 fields below */
> +	u32	dt_strings_size;	/* size of the DT strings block */
> +	/* version 17 fields below */
> +	u32	dt_struct_size;		/* size of the DT structure block */
> +};
> +
> +
> +
> +typedef u32 phandle;
> +typedef u32 ihandle;
> +
> +struct property {
> +	char	*name;
> +	int	length;
> +	void	*value;
> +	struct property *next;
> +};
> +
> +struct device_node {
> +	const char *name;
> +	const char *type;
> +	phandle	node;
> +	phandle linux_phandle;
> +	char	*full_name;
> +
> +	struct	property *properties;
> +	struct  property *deadprops; /* removed properties */
> +	struct	device_node *parent;
> +	struct	device_node *child;
> +	struct	device_node *sibling;
> +	struct	device_node *next;	/* next device of same type */
> +	struct	device_node *allnext;	/* next in list of all nodes */
> +	struct  proc_dir_entry *pde;	/* this node's proc directory */
> +	struct  kref kref;
> +	unsigned long _flags;
> +	void	*data;
> +};
> +
> +extern struct device_node *of_chosen;
> +
> +static inline int of_node_check_flag(struct device_node *n, unsigned long flag)
> +{
> +	return test_bit(flag, &n->_flags);
> +}
> +
> +static inline void of_node_set_flag(struct device_node *n, unsigned long flag)
> +{
> +	set_bit(flag, &n->_flags);
> +}
> +
> +
> +#define HAVE_ARCH_DEVTREE_FIXUPS
> +
> +static inline void set_node_proc_entry(struct device_node *dn,
> +					struct proc_dir_entry *de)
> +{
> +	dn->pde = de;
> +}
> +
> +
> +extern struct device_node *of_find_all_nodes(struct device_node *prev);

Doesn't appear to be defined or used in this patch, is this prototype
necessary?

> +extern struct device_node *of_node_get(struct device_node *node);
> +extern void of_node_put(struct device_node *node);

These two are, great.

> +
> +/* For scanning the flat device-tree at boot time */
> +extern int __init of_scan_flat_dt(int (*it)(unsigned long node,
> +					    const char *uname, int depth,
> +					    void *data),
> +				  void *data);
> +extern void * __init of_get_flat_dt_prop(unsigned long node, const char *name,
> +					unsigned long *size);
> +extern int __init of_flat_dt_is_compatible(unsigned long node,
> +					const char *name);
> +extern unsigned long __init of_get_flat_dt_root(void);
> +
> +/* For updating the device tree at runtime */
> +extern void of_attach_node(struct device_node *);
> +extern void of_detach_node(struct device_node *);
> +
> +/* Other Prototypes */
> +extern void finish_device_tree(void);

These seven again don't appear to be defined...

> +extern void unflatten_device_tree(void);

This one is, yay!

> +extern void early_init_devtree(void *);
> +extern int machine_is_compatible(const char *compat);
> +extern void print_properties(struct device_node *node);
> +extern int prom_n_intr_cells(struct device_node *np);
> +extern void prom_get_irq_senses(unsigned char *senses, int off, int max);
> +extern int prom_add_property(struct device_node *np, struct property *prop);
> +extern int prom_remove_property(struct device_node *np, struct property *prop);
> +extern int prom_update_property(struct device_node *np,
> +				struct property *newprop,
> +				struct property *oldprop);

These eight don't appear to be defined...

> +
> +#ifdef CONFIG_PPC32

This define will never be set, so the definitions within this conditional
should not be here.

> +/*
> + * PCI <-> OF matching functions
> + * (XXX should these be here?)
> + */
> +struct pci_bus;
> +struct pci_dev;
> +extern int pci_device_from_OF_node(struct device_node *node,
> +				   u8 *bus, u8 *devfn);
> +extern struct device_node *pci_busdev_to_OF_node(struct pci_bus *, int);
> +extern struct device_node *pci_device_to_OF_node(struct pci_dev *);
> +extern void pci_create_OF_bus_map(void);
> +#endif
> +
> +extern struct resource *request_OF_resource(struct device_node* node,
> +				int index, const char *name_postfix);
> +extern int release_OF_resource(struct device_node *node, int index);

These two don't appear to be defined.

> +
> +
> +/*
> + * OF address retreival & translation
> + */
> +
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 of_read_number(const u32 *cell, int size)
> +{
> +	u64 r = 0;
> +	while (size--)
> +		r = (r << 32) | *(cell++);
> +	return r;
> +}
> +
> +/* Like of_read_number, but we want an unsigned long result */
> +#ifdef CONFIG_PPC32

Ditto.

> +static inline unsigned long of_read_ulong(const u32 *cell, int size)
> +{
> +	return cell[size-1];
> +}
> +#else
> +#define of_read_ulong(cell, size)	of_read_number(cell, size)
> +#endif
> +
> +/* Translate an OF address block into a CPU physical address
> + */
> +extern u64 of_translate_address(struct device_node *np, const u32 *addr);
> +
> +/* Translate a DMA address from device space to CPU space */
> +extern u64 of_translate_dma_address(struct device_node *dev,
> +				    const u32 *in_addr);
> +
> +/* Extract an address from a device, returns the region size and
> + * the address space flags too. The PCI version uses a BAR number
> + * instead of an absolute index
> + */
> +extern const u32 *of_get_address(struct device_node *dev, int index,
> +			   u64 *size, unsigned int *flags);
> +#ifdef CONFIG_PCI
> +extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
> +			       u64 *size, unsigned int *flags);
> +#else
> +static inline const u32 *of_get_pci_address(struct device_node *dev,
> +		int bar_no, u64 *size, unsigned int *flags)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_PCI */

These address translation macros aren't defined, should they be?

> +
> +/* Get an address as a resource. Note that if your address is
> + * a PIO address, the conversion will fail if the physical address
> + * can't be internally converted to an IO token with
> + * pci_address_to_pio(), that is because it's either called to early
> + * or it can't be matched to any host bridge IO space
> + */
> +extern int of_address_to_resource(struct device_node *dev, int index,
> +				  struct resource *r);

Not defined.  I've stopped checking here, so prototypes below will need
removing if they're not required.

> +#ifdef CONFIG_PCI
> +extern int of_pci_address_to_resource(struct device_node *dev, int bar,
> +				      struct resource *r);
> +#else
> +static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
> +		struct resource *r)
> +{
> +	return -ENOSYS;
> +}
> +#endif /* CONFIG_PCI */
> +
> +/* Parse the ibm,dma-window property of an OF node into the busno, phys and
> + * size parameters.
> + */
> +void of_parse_dma_window(struct device_node *dn, const void *dma_window_prop,
> +		unsigned long *busno, unsigned long *phys, unsigned long *size);
> +
> +extern void kdump_move_device_tree(void);
> +
> +/* CPU OF node matching */
> +struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
> +
> +/* cache lookup */
> +struct device_node *of_find_next_cache_node(struct device_node *np);
> +
> +/* Get the MAC address */
> +extern const void *of_get_mac_address(struct device_node *np);
> +
> +/*
> + * OF interrupt mapping
> + */
> +
> +/* This structure is returned when an interrupt is mapped. The controller
> + * field needs to be put() after use
> + */
> +
> +#define OF_MAX_IRQ_SPEC		 4 /* We handle specifiers of at most 4 cells */
> +
> +struct of_irq {
> +	struct device_node *controller;	/* Interrupt controller node */
> +	u32 size;			/* Specifier size */
> +	u32 specifier[OF_MAX_IRQ_SPEC];	/* Specifier copy */
> +};
> +
> +/**
> + * of_irq_map_init - Initialize the irq remapper
> + * @flags:	flags defining workarounds to enable
> + *
> + * Some machines have bugs in the device-tree which require certain workarounds
> + * to be applied. Call this before any interrupt mapping attempts to enable
> + * those workarounds.
> + */
> +#define OF_IMAP_OLDWORLD_MAC	0x00000001
> +#define OF_IMAP_NO_PHANDLE	0x00000002
> +
> +extern void of_irq_map_init(unsigned int flags);
> +
> +/**
> + * of_irq_map_raw - Low level interrupt tree parsing
> + * @parent:	the device interrupt parent
> + * @intspec:	interrupt specifier ("interrupts" property of the device)
> + * @ointsize:   size of the passed in interrupt specifier
> + * @addr:	address specifier (start of "reg" property of the device)
> + * @out_irq:	structure of_irq filled by this function
> + *
> + * Returns 0 on success and a negative number on error
> + *
> + * This function is a low-level interrupt tree walking function. It
> + * can be used to do a partial walk with synthetized reg and interrupts
> + * properties, for example when resolving PCI interrupts when no device
> + * node exist for the parent.
> + *
> + */
> +
> +extern int of_irq_map_raw(struct device_node *parent, const u32 *intspec,
> +			  u32 ointsize, const u32 *addr,
> +			  struct of_irq *out_irq);
> +
> +
> +/**
> + * of_irq_map_one - Resolve an interrupt for a device
> + * @device:	the device whose interrupt is to be resolved
> + * @index:     	index of the interrupt to resolve
> + * @out_irq:	structure of_irq filled by this function
> + *
> + * This function resolves an interrupt, walking the tree, for a given
> + * device-tree node. It's the high level pendant to of_irq_map_raw().
> + * It also implements the workarounds for OldWolrd Macs.
> + */
> +extern int of_irq_map_one(struct device_node *device, int index,
> +			  struct of_irq *out_irq);
> +
> +/**
> + * of_irq_map_pci - Resolve the interrupt for a PCI device
> + * @pdev:	the device whose interrupt is to be resolved
> + * @out_irq:	structure of_irq filled by this function
> + *
> + * This function resolves the PCI interrupt for a given PCI device. If a
> + * device-node exists for a given pci_dev, it will use normal OF tree
> + * walking. If not, it will implement standard swizzling and walk up the
> + * PCI tree until an device-node is found, at which point it will finish
> + * resolving using the OF tree walking.
> + */
> +struct pci_dev;
> +extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> +
> +extern int of_irq_to_resource(struct device_node *dev, int index,
> +			struct resource *r);
> +
> +/**
> + * of_iomap - Maps the memory mapped IO for a given device_node
> + * @device:	the device whose io range will be mapped
> + * @index:	index of the io range
> + *
> + * Returns a pointer to the mapped memory
> + */
> +extern void __iomem *of_iomap(struct device_node *device, int index);
> +extern int have_of;
> +/*
> + * NB:  This is here while we transition from using asm/prom.h
> + * to linux/of.h
> + */
> +#include <linux/of.h>

Hmm, if asm/prom.h is a transitionary thing, should new implementations be
providing it?

> +
> +/* align addr on a size boundary - adjust address up/down if needed */
> +#define _ALIGN_UP(addr, size)	(((addr) + ((size) - 1)) & (~((size) - 1)))
> +#define _ALIGN_DOWN(addr, size)	((addr) & (~((size) - 1)))
> +
> +/* align addr on a size boundary - adjust address up if needed */
> +#define _ALIGN(addr, size)     _ALIGN_UP(addr, size)
> +
> +#endif /* __KERNEL__ */
> +#endif /* _POWERPC_PROM_H */
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index 7ffbb29..2fbf11a 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -150,6 +150,13 @@ struct tag_memclk {
>  	__u32 fmemclk;
>  };
>  
> +/* Flat dev tree address */
> +#define ATAG_FLAT_DEV_TREE_ADDRESS 0xf100040A

I'd prefer this to be 0x544100xx where 'xx' is the next available number
(which looks like being '0A').  The 0x544n00nn numbers are used for non-
platform specific tags.

> +struct tag_flat_dev_tree_address {

Hmm, the name of this structure doesn't really reflect it's purpose.  It
isn't an address, it's an address and size.  'tag_flat_dev_tree' would
be sufficient.

> +	u32 flat_dev_tree_address;
> +	u32 flat_dev_tree_size;

and just calling these 'address' and 'size' would also be sufficient.

> +};
> +
>  struct tag {
>  	struct tag_header hdr;
>  	union {
> @@ -177,6 +184,7 @@ struct tag {
>  		 * DC21285 specific
>  		 */
>  		struct tag_memclk	memclk;
> +		struct tag_flat_dev_tree_address flat_dev_tree_address;

'flat_dev_tree' will do fine here as well.

>  	} u;
>  };
>  
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index 4305345..adbdd3b 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_ATAGS_PROC)	+= atags.o
>  obj-$(CONFIG_OABI_COMPAT)	+= sys_oabi-compat.o
>  obj-$(CONFIG_ARM_THUMBEE)	+= thumbee.o
>  obj-$(CONFIG_KGDB)		+= kgdb.o
> +obj-$(CONFIG_OF)		+= prom.o
>  
>  obj-$(CONFIG_CRUNCH)		+= crunch.o crunch-bits.o
>  AFLAGS_crunch-bits.o		:= -Wa,-mcpu=ep9312
> diff --git a/arch/arm/kernel/prom.c b/arch/arm/kernel/prom.c
> new file mode 100644
> index 0000000..9d1c835
> --- /dev/null
> +++ b/arch/arm/kernel/prom.c
> @@ -0,0 +1,414 @@
> +/*
> + * Procedures for creating, accessing and interpreting the device tree.

Again, we don't have a PROM, but maybe this file is just misnamed.  Is
there a better name for it?

> + *
> + * Paul Mackerras       August 1996.
> + * Copyright (C) 1996-2005 Paul Mackerras.
> + *
> + *  Adapted for 64bit PowerPC by Dave Engebretsen and Peter Bergner.
> + *    {engebret|bergner}@us.ibm.com
> + *
> + *  Adapted for ARM by Motorola Inc.
> + *
> + *      This program is free software; you can redistribute it and/or
> + *      modify it under the terms of the GNU General Public License
> + *      as published by the Free Software Foundation; either version
> + *      2 of the License, or (at your option) any later version.
> + */
> +
> +#include <stdarg.h>
> +#include <linux/kernel.h>
> +#include <linux/string.h>
> +#include <linux/init.h>
> +#include <linux/threads.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +#include <linux/pci.h>
> +#include <linux/stringify.h>
> +#include <linux/delay.h>
> +#include <linux/initrd.h>
> +#include <linux/bitops.h>
> +#include <linux/module.h>
> +#include <linux/bootmem.h>
> +#include <linux/kexec.h>
> +#include <linux/debugfs.h>
> +#include <linux/irq.h>
> +#include <asm/prom.h>
> +#include <asm/setup.h>
> +#include <asm/memory.h>
> +#ifdef DEBUG
> +#define DBG(fmt...) printk(KERN_ERR fmt)
> +#else
> +#define DBG(fmt...)
> +#endif
> +
> +struct boot_param_header *initial_boot_params;

Should this be static?

> +
> +extern struct device_node *allnodes;	/* temporary while merging */
> +
> +extern rwlock_t devtree_lock;	/* temporary while merging */
> +
> +/* export that to outside world */
> +struct device_node *of_chosen;
> +
> +static inline char *find_flat_dt_string(u32 offset)
> +{
> +	return ((char *)initial_boot_params) +
> +		initial_boot_params->off_dt_strings + offset;
> +}
> +
> +static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
> +				       unsigned long align)
> +{
> +	void *res;
> +
> +	*mem = _ALIGN(*mem, align);
> +	res = (void *)*mem;
> +	*mem += size;
> +
> +	return res;
> +}
> +
> +static unsigned long __init unflatten_dt_node(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;
> +	char *pathp;
> +	u32 tag;
> +	unsigned int l, allocl;
> +	int has_name = 0;
> +	int new_format = 0;
> +
> +	tag = *((u32 *)(*p));

There's lots of this casting going on - maybe an accessor function or macro
to read a u32 quantity from the stream (and increment the pointer) would be
better?

> +	if (tag != OF_DT_BEGIN_NODE) {
> +		printk("Weird tag at start of node: %x\n", tag);
> +		return mem;
> +	}
> +	*p += 4;
> +	pathp = (char *)*p;
> +	l = allocl = strlen(pathp) + 1;
> +	*p = _ALIGN(*p + l, 4);
> +
> +	/* version 0x10 has a more compact unit name here instead of the full
> +	 * path. we accumulate the full path size using "fpsize", we'll rebuild
> +	 * it later. We detect this because the first character of the name is
> +	 * not '/'.
> +	 */
> +	if ((*pathp) != '/') {
> +		new_format = 1;
> +		if (fpsize == 0) {
> +			/* root node: special case. fpsize accounts for path
> +			 * plus terminating zero. root node only has '/', so
> +			 * fpsize should be 2, but we want to avoid the first
> +			 * level nodes to have two '/' so we use fpsize 1 here
> +			 */
> +			fpsize = 1;
> +			allocl = 2;
> +		} else {
> +			/* account for '/' and path size minus terminal 0
> +			 * already in 'l'
> +			 */
> +			fpsize += l;
> +			allocl = fpsize;
> +		}
> +	}
> +
> +
> +	np = unflatten_dt_alloc(&mem, sizeof(struct device_node) + allocl,
> +				__alignof__(struct device_node));
> +	if (allnextpp) {
> +		memset(np, 0, sizeof(*np));
> +		np->full_name = ((char *)np) + sizeof(struct device_node);

This is just a more complex way of saying:

		np->full_name = (char *)(np + 1);

> +		if (new_format) {
> +			char *p = np->full_name;
> +			/* rebuild full path for new format */
> +			if (dad && dad->parent) {
> +				strcpy(p, dad->full_name);
> +#ifdef DEBUG
> +				if ((strlen(p) + l + 1) != allocl) {
> +					DBG("%s: p: %d, l: %d, a: %d\n",
> +					    pathp, (int)strlen(p), l, allocl);
> +				}
> +#endif
> +				p += strlen(p);
> +			}
> +			*(p++) = '/';
> +			memcpy(p, pathp, l);

Hmm.  Wouldn't:

			int n = scnprintf(np->full_name, allocl, "%s/%s",
				dad && dad->parent ? dad->full_name : "",
				pathp);
#ifdef DEBUG
			if (n != allocl) {
				DBG("%s: p: %d, l: %d, a: %d\n",
				    pathp, (int)strlen(p), l, allocl);
			}
#endif

be simpler and more readable?

> +		} else
> +			memcpy(np->full_name, pathp, l);

Interestingly, you check above that the new format string fits exactly in
the buffer, but no check here.  Maybe the check above can be eliminated
with the simplified version.

> +		prev_pp = &np->properties;
> +		**allnextpp = np;
> +		*allnextpp = &np->allnext;
> +		if (dad != NULL) {
> +			np->parent = dad;
> +			/* we temporarily use the next field as `last_child'*/
> +			if (dad->next == 0)
> +				dad->child = np;
> +			else
> +				dad->next->sibling = np;
> +			dad->next = np;
> +		}
> +		kref_init(&np->kref);
> +	}
> +	while (1) {
> +		u32 sz, noff;
> +		char *pname;
> +
> +		tag = *((u32 *)(*p));
> +		if (tag == OF_DT_NOP) {
> +			*p += 4;
> +			continue;
> +		}
> +		if (tag != OF_DT_PROP)
> +			break;
> +		*p += 4;
> +		sz = *((u32 *)(*p));
> +		noff = *((u32 *)((*p) + 4));
> +		*p += 8;
> +		if (initial_boot_params->version < 0x10)
> +			*p = _ALIGN(*p, sz >= 8 ? 8 : 4);
> +
> +		pname = find_flat_dt_string(noff);
> +		if (pname == NULL) {
> +			printk(KERN_INFO "Can't find property name in list!\n");
> +			break;
> +		}
> +		if (strcmp(pname, "name") == 0)
> +			has_name = 1;
> +		l = strlen(pname) + 1;
> +		pp = unflatten_dt_alloc(&mem, sizeof(struct property),
> +					__alignof__(struct property));
> +		if (allnextpp) {
> +			if (strcmp(pname, "linux,phandle") == 0) {
> +				np->node = *((u32 *)*p);
> +				if (np->linux_phandle == 0)
> +					np->linux_phandle = np->node;
> +			}
> +			if (strcmp(pname, "ibm,phandle") == 0)
> +				np->linux_phandle = *((u32 *)*p);
> +			pp->name = pname;
> +			pp->length = sz;
> +			pp->value = (void *)*p;
> +			*prev_pp = pp;
> +			prev_pp = &pp->next;
> +		}
> +		*p = _ALIGN((*p) + sz, 4);
> +	}
> +	/* with version 0x10 we may not have the name property, recreate
> +	 * it here from the unit name if absent
> +	 */
> +	if (!has_name) {
> +		char *p = pathp, *ps = pathp, *pa = NULL;
> +		int sz;
> +
> +		while (*p) {
> +			if ((*p) == '@')
> +				pa = p;
> +			if ((*p) == '/')
> +				ps = p + 1;
> +			p++;
> +		}
> +		if (pa < ps)
> +			pa = p;
> +		sz = (pa - ps) + 1;
> +		pp = unflatten_dt_alloc(&mem, sizeof(struct property) + sz,
> +					__alignof__(struct property));
> +		if (allnextpp) {
> +			pp->name = "name";
> +			pp->length = sz;
> +			pp->value = pp + 1;
> +			*prev_pp = pp;
> +			prev_pp = &pp->next;
> +			memcpy(pp->value, ps, sz - 1);
> +			((char *)pp->value)[sz - 1] = 0;

strlcpy?

> +			DBG("fixed up name for %s -> %s\n", pathp,
> +				(char *)pp->value);
> +		}
> +	}
> +	if (allnextpp) {
> +		*prev_pp = NULL;
> +		np->name = of_get_property(np, "name", NULL);
> +		np->type = of_get_property(np, "device_type", NULL);
> +
> +		if (!np->name)
> +			np->name = "<NULL>";
> +		if (!np->type)
> +			np->type = "<NULL>";
> +	}
> +	while (tag == OF_DT_BEGIN_NODE) {
> +		mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
> +		tag = *((u32 *)(*p));
> +	}
> +	if (tag != OF_DT_END_NODE) {
> +		printk(KERN_INFO "Weird tag at end of node: %x\n", tag);
> +		return mem;
> +	}
> +	*p += 4;
> +	return mem;
> +}
> +
> +/**
> + * 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 (this used to be done by finish_device_tree)
> + */
> +void __init unflatten_device_tree(void)
> +{
> +	unsigned long start, mem, size;
> +	struct device_node **allnextp = &allnodes;
> +
> +	DBG(" -> unflatten_device_tree()\n");
> +	if (!initial_boot_params)
> +		return;
> +	/* First pass, scan for size */
> +	start = ((unsigned long)initial_boot_params) +
> +		initial_boot_params->off_dt_struct;
> +	size = unflatten_dt_node(0, &start, NULL, NULL, 0);
> +	size = (size | 3) + 1;

This might be worth doing proper alignment on - as it is, if 'size' was
already aligned, this will still align it to the _next_ word boundary.

	size = (size + 3) & ~3;

Even better would be:

	size = ALIGN(size, __alignof__(u32));

or whatever type you're requiring it to be aligned to.

> +
> +	DBG("  size is %lx, allocating...\n", size);
> +
> +	/* Allocate memory for the expanded device tree */
> +	mem = (unsigned long) __alloc_bootmem(size + 4,

sizeof(u32) ?

> +			__alignof__(struct device_node), 0);
> +
> +	((u32 *)mem)[size / 4] = 0xdeadbeef;

sizeof(u32) ?  As I side-note, I really hate these casts - it's screaming
that the type of 'mem' is wrong.  Making it a void pointer might be an
improvement (though it does require casts in unflatten_dt_alloc instead.)

	void *mem;
	u32 *mem_endmarker;

	mem = __alloc_bootmem(size + sizeof(u32),
			__alignof__(struct device_node), 0);

	mem_endmarker = mem + size;
	*mem_endmarker = 0xdeadbeef;

	...

	if (*mem_endmarker != 0xdeadbeef)
		printk(...);

looks much nicer and again easier to read, no?

> +
> +	DBG("  unflattening %lx...\n", mem);
> +
> +	/* Second pass, do actual unflattening */
> +	start = ((unsigned long)initial_boot_params) +
> +		initial_boot_params->off_dt_struct;
> +	unflatten_dt_node(mem, &start, NULL, &allnextp, 0);
> +	if (*((u32 *)start) != OF_DT_END)
> +		printk(KERN_WARNING "Weird tag at end of tree: %08x\n",
> +			*((u32 *)start));
> +	if (((u32 *)mem)[size / 4] != 0xdeadbeef)
> +		printk(KERN_WARNING "End of tree marker overwritten: %08x\n",
> +		       ((u32 *)mem)[size / 4]);
> +	*allnextp = NULL;
> +
> +	/* 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");
> +
> +	DBG(" <- unflatten_device_tree()\n");
> +}
> +
> +/**
> + *	of_find_node_by_phandle - Find a node given a phandle
> + *	@handle:	phandle of the node to find
> + *
> + *	Returns a node pointer with refcount incremented, use
> + *	of_node_put() on it when done.
> + */
> +struct device_node *of_find_node_by_phandle(phandle handle)
> +{
> +	struct device_node *np;
> +
> +	read_lock(&devtree_lock);
> +	for (np = allnodes; np != 0; np = np->allnext)
> +		if (np->linux_phandle == handle)
> +			break;
> +	of_node_get(np);
> +	read_unlock(&devtree_lock);
> +	return np;
> +}
> +EXPORT_SYMBOL(of_find_node_by_phandle);
> +
> +struct device_node *of_node_get(struct device_node *node)
> +{
> +	if (node)
> +		kref_get(&node->kref);
> +	return node;
> +}
> +EXPORT_SYMBOL(of_node_get);

Blank line here would be nice.

> +static inline struct device_node *kref_to_device_node(struct kref *kref)
> +{
> +	return container_of(kref, struct device_node, kref);
> +}
> +
> +/**
> + *	of_node_release - release a dynamically allocated node
> + *	@kref:  kref element of the node to be released
> + *
> + *	In of_node_put() this function is passed to kref_put()
> + *	as the destructor.
> + */
> +static void of_node_release(struct kref *kref)
> +{
> +	struct device_node *node = kref_to_device_node(kref);
> +	struct property *prop = node->properties;
> +
> +	/* We should never be releasing nodes that haven't been detached. */
> +	if (!of_node_check_flag(node, OF_DETACHED)) {
> +		printk(KERN_WARNING "WARNING: Bad of_node_put() on %s\n",
> +			node->full_name);
> +		dump_stack();
> +		kref_init(&node->kref);
> +		return;
> +	}
> +
> +	if (!of_node_check_flag(node, OF_DYNAMIC))
> +		return;
> +
> +	while (prop) {
> +		struct property *next = prop->next;
> +		kfree(prop->name);
> +		kfree(prop->value);
> +		kfree(prop);
> +		prop = next;
> +
> +		if (!prop) {
> +			prop = node->deadprops;
> +			node->deadprops = NULL;
> +		}
> +	}
> +	kfree(node->full_name);
> +	kfree(node->data);
> +	kfree(node);
> +}
> +
> +/**
> + *	of_node_put - Decrement refcount of a node
> + *	@node:	Node to dec refcount, NULL is supported to
> + *		simplify writing of callers
> + *
> + */
> +void of_node_put(struct device_node *node)
> +{
> +	if (node)
> +		kref_put(&node->kref, of_node_release);
> +}
> +EXPORT_SYMBOL(of_node_put);
> +
> +int have_of;
> +u32 phys_flat_dev_tree_address __initdata;
> +u32 phys_flat_dev_tree_size __initdata;
> +
> +/* process flat device tree for hardware configuration */
> +static int __init parse_tag_flat_dev_tree_address(const struct tag *tag)
> +{
> +    phys_flat_dev_tree_address =
> +			tag->u.flat_dev_tree_address.flat_dev_tree_address;
> +    phys_flat_dev_tree_size = tag->u.flat_dev_tree_address.flat_dev_tree_size;
> +
> +    have_of = 1;
> +    if (phys_flat_dev_tree_size)
> +	initial_boot_params = phys_to_virt(phys_flat_dev_tree_address);

With shorter names, and elimination of unnecessary variables, this can become:

	if (tag->u.flat_dev_tree.size)
		initial_boot_params = phys_to_virt(tag->u.flat_dev_tree.address);
	have_of = 1;

which is immensely more readable than the above.

> +
> +    printk(KERN_INFO
> +	"%s: flat_dev_tree_address=0x%08x, flat_dev_tree_size == 0x%08X\n",
> +	__func__,
> +	phys_flat_dev_tree_address,
> +	phys_flat_dev_tree_size);

I really hate normal printk's which include things like source file name,
function name, line numbers, etc.  That may be useful for debug messages,
but for normal output it's virtually irrelevent.  It's certainly
irrelevent here - are users or developers going to care that the message
has come from a function called 'parse_tag_flat_dev_tree_address' ?

Of course, the two variable names need to become the versions in the
tag itself.

> +
> +    return 0;
> +}
> +
> +__tagtable(ATAG_FLAT_DEV_TREE_ADDRESS, parse_tag_flat_dev_tree_address);
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 68d6494..8b219ec 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -35,6 +35,7 @@
>  #include <asm/cacheflush.h>
>  #include <asm/cachetype.h>
>  #include <asm/tlbflush.h>
> +#include <asm/prom.h>
>  
>  #include <asm/mach/arch.h>
>  #include <asm/mach/irq.h>
> @@ -726,6 +727,7 @@ void __init setup_arch(char **cmdline_p)
>  	parse_cmdline(cmdline_p, from);
>  	paging_init(mdesc);
>  	request_standard_resources(&meminfo, mdesc);
> +	unflatten_device_tree();

Might this want to come immediately after 'paging_init' but before
'request_standard_resources' ?  If we want resources to be controlled
by device tree stuff then it would have to be.

The other point which occurs to me is that on ARM, platforms do some
kind of platform specific setup in paging_init() - that may be an
issue which will need to be revisited.

>  
>  #ifdef CONFIG_SMP
>  	smp_init_cpus();
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index f821dbc..c23a6ea 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -1,6 +1,6 @@
>  config OF_DEVICE
>  	def_bool y
> -	depends on OF && (SPARC || PPC_OF)
> +	depends on OF && (SPARC || PPC_OF || ARM)
>  
>  config OF_GPIO
>  	def_bool y
> 
> 
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: [RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Fri, May 29, 2009 at 10:51:14AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-28 at 17:04 +0200, Sascha Hauer wrote:
> > 
> > We normally hide these subtle details behind a baseboard= kernel
> > parameter. I agree with you that it's far better to have a
> > standardized
> > way to specify this. For my taste the oftree is too bloated for this
> > purpose.
> 
> Define "bloated" ?
> 
> We got a lot of push back on powerpc initially with this exact same
> argument "too bloated" but that was never backed up with facts and
> numbers, and I would mostly say that nobody makes it anymore now
> that it's there and people use it.

It really depends how you look at it.

If you look at the amount of supporting code required for one platform
on ARM, it's typically fairly small - mostly just declaration of data
structures (platform devices, platform device data), and possibly a few
small functions to handle the quirkyness of the platform.  That's of the
order of a few K of data and code combined - that's on average about 4K.
Add in the SoC platform device declaration code, and maybe add another
10K.

So, about 14K of code and data.

The OF support code in drivers/of is about 3K.  The code posted at the
start of this thread I suspect will be about 4K or so, which gives us a
running total of maybe 7K.

What's now missing is conversion of drivers and the like to be DT
compatible, or creation of the platform devices to translate DT into
platform devices and their associated platform device data.  Plus
some way to handle the platforms quirks, which as discussed would be
hard to represent in DT.

So I suspect it's actually marginal whether DT turns out to be larger
than our current approach.  So I agree with BenH - I don't think there's
an argument to be made about 'bloat' here.

What /does/ concern me is what I percieve as the need to separate the
platform quirks from the description of the platform - so rather than
having a single file describing the entire platform (eg,
arch/arm/mach-pxa/lubbock.c) we would need:

- a file to create the DT information
- a separate .c file in the kernel containing code to handle the
  platforms quirks, or a bunch of new DT drivers to do the same
- ensure both DT and quirks are properly in-sync.

But... we need to see how Grant gets on with his PXA trial before we
can properly assess this.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Dmitry Eremin-Solenikov]

Kyle Moffett wrote:

> On Sat, May 30, 2009 at 7:22 AM, Pavel Machek <pavel@ucw.cz> wrote:
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>> f430e15..b0ee851 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -158,6 +158,17 @@ config ARCH_MTD_XIP
>>>  config GENERIC_HARDIRQS_NO__DO_IRQ
>>>       def_bool y
>>>
>>> +config OF
>>> +        def_bool y
>>> +
>>> +config PROC_DEVICETREE
>>> +        bool "Support for device tree in /proc"
>>
>> It certainly should not be in /proc.
> 
> There is unfortunately a relatively large legacy base of existing tools

And the keyword is *legacy* IMO. We have had legacy things like /proc/acpi,
/proc/ide etc. for years. However one by one they are being dropped and
replaced with more vivid interfaces. IMO one shouldn't hang around legacy
things for years. Just define and implement the replacement and delcare
that legacy interface will fade out and will be removed in a year or two.



With best wishes
Dmitry

Re: [RFC] [PATCH] Device Tree on ARM platform

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Sun, 31 May 2009 11:08:43 +0100 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > diff --git a/arch/arm/include/asm/of_platform.h b/arch/arm/include/asm/of_platform.h
> > new file mode 100644
> > index 0000000..53b4650
> > --- /dev/null
> > +++ b/arch/arm/include/asm/of_platform.h
> > +/* Platform drivers register/unregister */
> > +static inline int of_register_platform_driver(struct of_platform_driver *drv)
> > +{
> > +	return of_register_driver(drv, &of_platform_bus_type);
> > +}
> > +static inline void of_unregister_platform_driver(struct of_platform_driver *drv)
> > +{
> > +	of_unregister_driver(drv);
> > +}
> 
> Not sure why this isn't generic code.

They are both in include/linux/of_platform.h since commit
0763ed2355198cdef2f6a2098e9d52eb1fe4365d ("of: make
of_(un)register_platform_driver common code") - added to Linus' tree
on May 5.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [RFC] [PATCH] Device Tree on ARM platform

[Janboe Ye]

hi, Russell

Thank you for comments.

I update my patch according to your comments except one comments.


> diff --git a/arch/arm/kernel/prom.c b/arch/arm/kernel/prom.c
> > new file mode 100644
> > index 0000000..9d1c835
> > --- /dev/null
> > +++ b/arch/arm/kernel/prom.c
> > @@ -0,0 +1,414 @@
> > +/*
> > + * Procedures for creating, accessing and interpreting the device tree.
> 
> Again, we don't have a PROM, but maybe this file is just misnamed.  Is
> there a better name for it?
> 
the file named as prom.[ch] is because the main codes are from PPC's prom code, and fs/proc/proc_devicetree.c also include prom.h directly.

Changelogs:
1 remove of_platform and of_device support function declaration. Maybe of_platform and of_device could be added later.
2 clean up functions declaration which is used boottime in prom.h which is not needed now. It could be added if some information need to be setup before paging_init. 
3 put OF configuration in kernel feature menu

Signed-off-by: janboe <yuan-bo.ye@motorola.com>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f430e15..b6a0dfd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -915,6 +915,17 @@ config NODES_SHIFT
 	default "2"
 	depends on NEED_MULTIPLE_NODES
 
+config OF
+        bool "Support for device tree"
+
+config PROC_DEVICETREE
+        bool "Support for device tree in /proc"
+        depends on PROC_FS && OF
+        help
+          This option adds a device-tree directory under /proc which contains
+          an image of the device tree that the kernel copies from Open
+          Firmware or other boot firmware. If unsure, say Y here.
+
 source "mm/Kconfig"
 
 config LEDS
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
new file mode 100644
index 0000000..5949d7d
--- /dev/null
+++ b/arch/arm/include/asm/prom.h
@@ -0,0 +1,142 @@
+#ifndef _ARM_PROM_H
+#define _ARM_PROM_H
+#ifdef __KERNEL__
+
+/*
+ * Copyright (C) 1996-2005 Paul Mackerras.
+ *
+ * Updates for PPC64 by Peter Bergner & David Engebretsen, IBM Corp.
+ *
+ * Updates for ARM by Motorola Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <linux/platform_device.h>
+
+#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT	1
+#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT	1
+
+#define of_compat_cmp(s1, s2, l)	strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2)		strcmp((s1), (s2))
+#define of_node_cmp(s1, s2)		strcasecmp((s1), (s2))
+
+/* Definitions used by the flattened device tree */
+#define OF_DT_HEADER		0xd00dfeed	/* marker */
+#define OF_DT_BEGIN_NODE	0x1		/* Start of node, full name */
+#define OF_DT_END_NODE		0x2		/* End node */
+#define OF_DT_PROP		0x3		/* Property: name off, size,
+						 * content */
+#define OF_DT_NOP		0x4		/* nop */
+#define OF_DT_END		0x9
+
+#define OF_DT_VERSION		0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+	u32	magic;			/* magic word OF_DT_HEADER */
+	u32	totalsize;		/* total size of DT block */
+	u32	off_dt_struct;		/* offset to structure */
+	u32	off_dt_strings;		/* offset to strings */
+	u32	off_mem_rsvmap;		/* offset to memory reserve map */
+	u32	version;		/* format version */
+	u32	last_comp_version;	/* last compatible version */
+	/* version 2 fields below */
+	u32	boot_cpuid_phys;	/* Physical CPU id we're booting on */
+	/* version 3 fields below */
+	u32	dt_strings_size;	/* size of the DT strings block */
+	/* version 17 fields below */
+	u32	dt_struct_size;		/* size of the DT structure block */
+};
+
+
+
+typedef u32 phandle;
+typedef u32 ihandle;
+
+struct property {
+	char	*name;
+	int	length;
+	void	*value;
+	struct property *next;
+};
+
+struct device_node {
+	const char *name;
+	const char *type;
+	phandle	node;
+	phandle linux_phandle;
+	char	*full_name;
+
+	struct	property *properties;
+	struct  property *deadprops; /* removed properties */
+	struct	device_node *parent;
+	struct	device_node *child;
+	struct	device_node *sibling;
+	struct	device_node *next;	/* next device of same type */
+	struct	device_node *allnext;	/* next in list of all nodes */
+	struct  proc_dir_entry *pde;	/* this node's proc directory */
+	struct  kref kref;
+	unsigned long _flags;
+	void	*data;
+};
+
+extern struct device_node *of_chosen;
+
+static inline int of_node_check_flag(struct device_node *n, unsigned long flag)
+{
+	return test_bit(flag, &n->_flags);
+}
+
+static inline void of_node_set_flag(struct device_node *n, unsigned long flag)
+{
+	set_bit(flag, &n->_flags);
+}
+
+
+#define HAVE_ARCH_DEVTREE_FIXUPS
+
+static inline void set_node_proc_entry(struct device_node *dn,
+					struct proc_dir_entry *de)
+{
+	dn->pde = de;
+}
+
+extern struct device_node *of_node_get(struct device_node *node);
+extern void of_node_put(struct device_node *node);
+
+/* Other Prototypes */
+extern void unflatten_device_tree(void);
+
+/*
+ * NB:  This is here while we transition from using asm/prom.h
+ * to linux/of.h
+ */
+#include <linux/of.h>
+
+/* align addr on a size boundary - adjust address up/down if needed */
+#define _ALIGN_UP(addr, size)	(((addr) + ((size) - 1)) & (~((size) - 1)))
+#define _ALIGN_DOWN(addr, size)	((addr) & (~((size) - 1)))
+
+/* align addr on a size boundary - adjust address up if needed */
+#define _ALIGN(addr, size)     _ALIGN_UP(addr, size)
+
+#endif /* __KERNEL__ */
+#endif /* _ARM_PROM_H */
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 7ffbb29..8d9f4bd 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -150,6 +150,13 @@ struct tag_memclk {
 	__u32 fmemclk;
 };
 
+/* Flat dev tree address */
+#define ATAG_FLAT_DEV_TREE_ADDRESS 0x5441000A
+struct tag_flat_dev_tree_address {
+	u32 address;
+	u32 size;
+};
+
 struct tag {
 	struct tag_header hdr;
 	union {
@@ -177,6 +184,7 @@ struct tag {
 		 * DC21285 specific
 		 */
 		struct tag_memclk	memclk;
+		struct tag_flat_dev_tree_address flat_dev_tree;
 	} u;
 };
 
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 4305345..adbdd3b 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ATAGS_PROC)	+= atags.o
 obj-$(CONFIG_OABI_COMPAT)	+= sys_oabi-compat.o
 obj-$(CONFIG_ARM_THUMBEE)	+= thumbee.o
 obj-$(CONFIG_KGDB)		+= kgdb.o
+obj-$(CONFIG_OF)		+= prom.o
 
 obj-$(CONFIG_CRUNCH)		+= crunch.o crunch-bits.o
 AFLAGS_crunch-bits.o		:= -Wa,-mcpu=ep9312
diff --git a/arch/arm/kernel/prom.c b/arch/arm/kernel/prom.c
new file mode 100644
index 0000000..03d5e4c
--- /dev/null
+++ b/arch/arm/kernel/prom.c
@@ -0,0 +1,402 @@
+/*
+ * Procedures for creating, accessing and interpreting the device tree.
+ *
+ * Paul Mackerras       August 1996.
+ * Copyright (C) 1996-2005 Paul Mackerras.
+ *
+ *  Adapted for 64bit PowerPC by Dave Engebretsen and Peter Bergner.
+ *    {engebret|bergner}@us.ibm.com
+ *
+ *  Adapted for ARM by Motorola Inc.
+ *
+ *      This program is free software; you can redistribute it and/or
+ *      modify it under the terms of the GNU General Public License
+ *      as published by the Free Software Foundation; either version
+ *      2 of the License, or (at your option) any later version.
+ */
+
+#include <stdarg.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/init.h>
+#include <linux/threads.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+#include <linux/pci.h>
+#include <linux/stringify.h>
+#include <linux/delay.h>
+#include <linux/initrd.h>
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/bootmem.h>
+#include <linux/kexec.h>
+#include <linux/debugfs.h>
+#include <linux/irq.h>
+#include <asm/prom.h>
+#include <asm/setup.h>
+#include <asm/memory.h>
+#ifdef DEBUG
+#define DBG(fmt...) printk(KERN_ERR fmt)
+#else
+#define DBG(fmt...)
+#endif
+
+static struct boot_param_header *initial_boot_params;
+
+extern struct device_node *allnodes;	/* temporary while merging */
+
+extern rwlock_t devtree_lock;	/* temporary while merging */
+
+/* export that to outside world */
+struct device_node *of_chosen;
+
+static inline char *find_flat_dt_string(u32 offset)
+{
+	return ((char *)initial_boot_params) +
+		initial_boot_params->off_dt_strings + offset;
+}
+
+static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
+				       unsigned long align)
+{
+	void *res;
+
+	*mem = _ALIGN(*mem, align);
+	res = (void *)*mem;
+	*mem += size;
+
+	return res;
+}
+
+static unsigned long __init unflatten_dt_node(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;
+	char *pathp;
+	u32 tag;
+	unsigned int l, allocl;
+	int has_name = 0;
+	int new_format = 0;
+
+	tag = *((u32 *)(*p));
+	if (tag != OF_DT_BEGIN_NODE) {
+		printk("Weird tag at start of node: %x\n", tag);
+		return mem;
+	}
+	*p += 4;
+	pathp = (char *)*p;
+	l = allocl = strlen(pathp) + 1;
+	*p = _ALIGN(*p + l, 4);
+
+	/* version 0x10 has a more compact unit name here instead of the full
+	 * path. we accumulate the full path size using "fpsize", we'll rebuild
+	 * it later. We detect this because the first character of the name is
+	 * not '/'.
+	 */
+	if ((*pathp) != '/') {
+		new_format = 1;
+		if (fpsize == 0) {
+			/* root node: special case. fpsize accounts for path
+			 * plus terminating zero. root node only has '/', so
+			 * fpsize should be 2, but we want to avoid the first
+			 * level nodes to have two '/' so we use fpsize 1 here
+			 */
+			fpsize = 1;
+			allocl = 2;
+		} else {
+			/* account for '/' and path size minus terminal 0
+			 * already in 'l'
+			 */
+			fpsize += l;
+			allocl = fpsize;
+		}
+	}
+
+
+	np = unflatten_dt_alloc(&mem, sizeof(struct device_node) + allocl,
+				__alignof__(struct device_node));
+	if (allnextpp) {
+		memset(np, 0, sizeof(*np));
+		np->full_name = ((char *)np) + sizeof(struct device_node);
+		if (new_format) {
+			int n = scnprintf(np->full_name, allocl, "%s/%s",
+                                dad && dad->parent ? dad->full_name : "",
+                                pathp);
+#ifdef DEBUG
+			if (n != allocl) {
+				DBG("%s: p: %d, l: %d, a: %d\n",
+				    pathp, (int)strlen(p), l, allocl);
+			}
+#endif
+		} else
+			memcpy(np->full_name, pathp, l);
+		prev_pp = &np->properties;
+		**allnextpp = np;
+		*allnextpp = &np->allnext;
+		if (dad != NULL) {
+			np->parent = dad;
+			/* we temporarily use the next field as `last_child'*/
+			if (dad->next == 0)
+				dad->child = np;
+			else
+				dad->next->sibling = np;
+			dad->next = np;
+		}
+		kref_init(&np->kref);
+	}
+	while (1) {
+		u32 sz, noff;
+		char *pname;
+
+		tag = *((u32 *)(*p));
+		if (tag == OF_DT_NOP) {
+			*p += 4;
+			continue;
+		}
+		if (tag != OF_DT_PROP)
+			break;
+		*p += 4;
+		sz = *((u32 *)(*p));
+		noff = *((u32 *)((*p) + 4));
+		*p += 8;
+		if (initial_boot_params->version < 0x10)
+			*p = _ALIGN(*p, sz >= 8 ? 8 : 4);
+
+		pname = find_flat_dt_string(noff);
+		if (pname == NULL) {
+			printk(KERN_INFO "Can't find property name in list!\n");
+			break;
+		}
+		if (strcmp(pname, "name") == 0)
+			has_name = 1;
+		l = strlen(pname) + 1;
+		pp = unflatten_dt_alloc(&mem, sizeof(struct property),
+					__alignof__(struct property));
+		if (allnextpp) {
+			if (strcmp(pname, "linux,phandle") == 0) {
+				np->node = *((u32 *)*p);
+				if (np->linux_phandle == 0)
+					np->linux_phandle = np->node;
+			}
+			pp->name = pname;
+			pp->length = sz;
+			pp->value = (void *)*p;
+			*prev_pp = pp;
+			prev_pp = &pp->next;
+		}
+		*p = _ALIGN((*p) + sz, 4);
+	}
+	/* with version 0x10 we may not have the name property, recreate
+	 * it here from the unit name if absent
+	 */
+	if (!has_name) {
+		char *p = pathp, *ps = pathp, *pa = NULL;
+		int sz;
+
+		while (*p) {
+			if ((*p) == '@')
+				pa = p;
+			if ((*p) == '/')
+				ps = p + 1;
+			p++;
+		}
+		if (pa < ps)
+			pa = p;
+		sz = (pa - ps) + 1;
+		pp = unflatten_dt_alloc(&mem, sizeof(struct property) + sz,
+					__alignof__(struct property));
+		if (allnextpp) {
+			pp->name = "name";
+			pp->length = sz;
+			pp->value = pp + 1;
+			*prev_pp = pp;
+			prev_pp = &pp->next;
+			strlcpy(pp->value, ps, sz);
+			DBG("fixed up name for %s -> %s\n", pathp,
+				(char *)pp->value);
+		}
+	}
+	if (allnextpp) {
+		*prev_pp = NULL;
+		np->name = of_get_property(np, "name", NULL);
+		np->type = of_get_property(np, "device_type", NULL);
+
+		if (!np->name)
+			np->name = "<NULL>";
+		if (!np->type)
+			np->type = "<NULL>";
+	}
+	while (tag == OF_DT_BEGIN_NODE) {
+		mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
+		tag = *((u32 *)(*p));
+	}
+	if (tag != OF_DT_END_NODE) {
+		printk(KERN_INFO "Weird tag at end of node: %x\n", tag);
+		return mem;
+	}
+	*p += 4;
+	return mem;
+}
+
+/**
+ * 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 (this used to be done by finish_device_tree)
+ */
+void __init unflatten_device_tree(void)
+{
+	unsigned long start, size;
+	void *mem;
+	u32 *mem_endmarker;
+	struct device_node **allnextp = &allnodes;
+
+	DBG(" -> unflatten_device_tree()\n");
+	if (!initial_boot_params)
+		return;
+	/* First pass, scan for size */
+	start = ((unsigned long)initial_boot_params) +
+		initial_boot_params->off_dt_struct;
+	size = unflatten_dt_node(0, &start, NULL, NULL, 0);
+	size = ALIGN(size, __alignof__(u32));
+
+	DBG("  size is %lx, allocating...\n", size);
+
+	/* Allocate memory for the expanded device tree */
+	mem = __alloc_bootmem(size + sizeof(u32),
+			__alignof__(struct device_node), 0);
+	mem_endmarker = mem + size;
+	*mem_endmarker = 0xdeadbeef;
+
+	DBG("  unflattening %lx...\n", mem);
+
+	/* Second pass, do actual unflattening */
+	start = ((unsigned long)initial_boot_params) +
+		initial_boot_params->off_dt_struct;
+	unflatten_dt_node((unsigned long)mem, &start, NULL, &allnextp, 0);
+	if (*((u32 *)start) != OF_DT_END)
+		printk(KERN_WARNING "Weird tag at end of tree: %08x\n",
+			*((u32 *)start));
+	if (*mem_endmarker != 0xdeadbeef)
+		printk(KERN_WARNING "End of tree marker overwritten: %08x\n",
+		       *mem_endmarker);
+	*allnextp = NULL;
+
+	/* 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");
+
+	DBG(" <- unflatten_device_tree()\n");
+}
+
+/**
+ *	of_find_node_by_phandle - Find a node given a phandle
+ *	@handle:	phandle of the node to find
+ *
+ *	Returns a node pointer with refcount incremented, use
+ *	of_node_put() on it when done.
+ */
+struct device_node *of_find_node_by_phandle(phandle handle)
+{
+	struct device_node *np;
+
+	read_lock(&devtree_lock);
+	for (np = allnodes; np != 0; np = np->allnext)
+		if (np->linux_phandle == handle)
+			break;
+	of_node_get(np);
+	read_unlock(&devtree_lock);
+	return np;
+}
+EXPORT_SYMBOL(of_find_node_by_phandle);
+
+struct device_node *of_node_get(struct device_node *node)
+{
+	if (node)
+		kref_get(&node->kref);
+	return node;
+}
+EXPORT_SYMBOL(of_node_get);
+
+static inline struct device_node *kref_to_device_node(struct kref *kref)
+{
+	return container_of(kref, struct device_node, kref);
+}
+
+/**
+ *	of_node_release - release a dynamically allocated node
+ *	@kref:  kref element of the node to be released
+ *
+ *	In of_node_put() this function is passed to kref_put()
+ *	as the destructor.
+ */
+static void of_node_release(struct kref *kref)
+{
+	struct device_node *node = kref_to_device_node(kref);
+	struct property *prop = node->properties;
+
+	/* We should never be releasing nodes that haven't been detached. */
+	if (!of_node_check_flag(node, OF_DETACHED)) {
+		printk(KERN_WARNING "WARNING: Bad of_node_put() on %s\n",
+			node->full_name);
+		dump_stack();
+		kref_init(&node->kref);
+		return;
+	}
+
+	if (!of_node_check_flag(node, OF_DYNAMIC))
+		return;
+
+	while (prop) {
+		struct property *next = prop->next;
+		kfree(prop->name);
+		kfree(prop->value);
+		kfree(prop);
+		prop = next;
+
+		if (!prop) {
+			prop = node->deadprops;
+			node->deadprops = NULL;
+		}
+	}
+	kfree(node->full_name);
+	kfree(node->data);
+	kfree(node);
+}
+
+/**
+ *	of_node_put - Decrement refcount of a node
+ *	@node:	Node to dec refcount, NULL is supported to
+ *		simplify writing of callers
+ *
+ */
+void of_node_put(struct device_node *node)
+{
+	if (node)
+		kref_put(&node->kref, of_node_release);
+}
+EXPORT_SYMBOL(of_node_put);
+
+int have_of;
+
+/* process flat device tree for hardware configuration */
+static int __init parse_tag_flat_dev_tree_address(const struct tag *tag)
+{
+    if (tag->u.flat_dev_tree.size)
+	initial_boot_params = phys_to_virt(tag->u.flat_dev_tree.address);
+
+    have_of = 1;
+    printk(KERN_INFO
+	"flat_dev_tree_address=0x%08x, flat_dev_tree_size == 0x%08X\n",
+	tag->u.flat_dev_tree.address,
+	tag->u.flat_dev_tree.size);
+
+    return 0;
+}
+
+__tagtable(ATAG_FLAT_DEV_TREE_ADDRESS, parse_tag_flat_dev_tree_address);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 68d6494..5f163b5 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -35,6 +35,7 @@
 #include <asm/cacheflush.h>
 #include <asm/cachetype.h>
 #include <asm/tlbflush.h>
+#include <asm/prom.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/irq.h>
@@ -725,6 +726,9 @@ void __init setup_arch(char **cmdline_p)
 	boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
 	parse_cmdline(cmdline_p, from);
 	paging_init(mdesc);
+#ifdef CONFIG_OF
+	unflatten_device_tree();
+#endif
 	request_standard_resources(&meminfo, mdesc);
 
 #ifdef CONFIG_SMP

Re: [RFC] [PATCH] Device Tree on ARM platform

[Holger Schurig]

> 1. implementers of the clock API which have not been subject
> to my rigorous review abuse it to the point of making the API
> essentially useless, and that causes Mark problems.

If that's a problem, when something needs changes. An API that 
can only be managed by implementers due to rigorous review lacks 
something, maybe easy-of-use, maybe documentation. Can it be the 
case that the current state makes you a single-point of failure?

If yes, I'd at least suggest better docs in linux/Documentation, 
e.g. describe the big-picture, the implementation and common 
cave-ats, e.g. why an approach "uniquely name every single 
clock ... makes the API pointless" doesn't work.

Re: [RFC] [PATCH] Device Tree on ARM platform

[Mark Brown]

On Tue, Jun 02, 2009 at 09:57:20AM +0200, Holger Schurig wrote:

> > 1. implementers of the clock API which have not been subject
> > to my rigorous review abuse it to the point of making the API
> > essentially useless, and that causes Mark problems.

> If that's a problem, when something needs changes. An API that 
> can only be managed by implementers due to rigorous review lacks 
> something, maybe easy-of-use, maybe documentation. Can it be the 
> case that the current state makes you a single-point of failure?

The problem is more that a lot of platform maintainers have treated the
clock API as being a bit of platform support code not intended to be
used by drivers, causing them to take lots of shortcuts when
implementing it that only work in their specific use cases - at times to
the point where it's not even possible to register new clocks.  Since
this means that the API is essentially unusable in generic driver code
you end up with nobody using it there and no back pressure other than
code review on maintainers to provide a good implementation.

> If yes, I'd at least suggest better docs in linux/Documentation, 
> e.g. describe the big-picture, the implementation and common 
> cave-ats, e.g. why an approach "uniquely name every single 
> clock ... makes the API pointless" doesn't work.

None of which means that better documentation wouldn't help, of course.