[PATCH 0/5] DT Overlay based cape manager for TI's Beaglebone

[PATCH 0/5] DT Overlay based cape manager for TI's Beaglebone

[Pantelis Antoniou]

Introducing a Device Tree overlay cape manager.

Using it it is possible to support the growing cape ecosystem for
the beaglebone, without having to hack a board file for each and
every cape plug combination.

It is possible to force load capes, and also possible to remove
them if need be (although precious few drivers support removal).

This patch is against the mainline kernel as of Jan 7 2013, top
of the tree: "5f243b9 Merge tag 'arm64-fixes' of \
	git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch640"

You will need to have the DTC compiler patch which was posted seperately
to the DTC mailing list "dtc: Dynamic symbols & fixup support", as well
as the I2C accessor patch "i2c-EEPROM: In kernel memory accessor interface" I
posted earlier.

Note that not many interesting capes are supported in the mainline kernel,
since the drivers some time to land in mainline, but you can see an
example of a (almost) feature complete linux kernel at:

git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v9


Pantelis Antoniou (5):
  capemgr: Beaglebone DT overlay based cape manager
  capemgr: Add beaglebone's cape driver bindings
  capemgr: am335x-bone capemgr bindings
  capemgr: firmware makefiles for DT objects
  capemgr: Weather cape cape definition

 .../devicetree/bindings/misc/capes-beaglebone.txt  |  110 ++
 arch/arm/boot/dts/am335x-bone.dts                  |   75 +-
 arch/arm/mach-omap2/Kconfig                        |    2 +
 drivers/misc/Kconfig                               |    2 +
 drivers/misc/Makefile                              |    1 +
 drivers/misc/cape/Kconfig                          |    5 +
 drivers/misc/cape/Makefile                         |    5 +
 drivers/misc/cape/beaglebone/Kconfig               |   11 +
 drivers/misc/cape/beaglebone/Makefile              |    5 +
 drivers/misc/cape/beaglebone/capemgr.c             | 1835 ++++++++++++++++++++
 firmware/Makefile                                  |   12 +
 firmware/capes/cape-bone-weather-00A0.dts          |   66 +
 12 files changed, 2128 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt
 create mode 100644 drivers/misc/cape/Kconfig
 create mode 100644 drivers/misc/cape/Makefile
 create mode 100644 drivers/misc/cape/beaglebone/Kconfig
 create mode 100644 drivers/misc/cape/beaglebone/Makefile
 create mode 100644 drivers/misc/cape/beaglebone/capemgr.c
 create mode 100644 firmware/capes/cape-bone-weather-00A0.dts

-- 
1.7.12

[PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

A cape loader based on DT overlays and DT objects.

Beaglebone cape manager implementation.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
 arch/arm/mach-omap2/Kconfig            |    2 +
 drivers/misc/Kconfig                   |    2 +
 drivers/misc/Makefile                  |    1 +
 drivers/misc/cape/Kconfig              |    5 +
 drivers/misc/cape/Makefile             |    5 +
 drivers/misc/cape/beaglebone/Kconfig   |   11 +
 drivers/misc/cape/beaglebone/Makefile  |    5 +
 drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
 8 files changed, 1866 insertions(+)
 create mode 100644 drivers/misc/cape/Kconfig
 create mode 100644 drivers/misc/cape/Makefile
 create mode 100644 drivers/misc/cape/beaglebone/Kconfig
 create mode 100644 drivers/misc/cape/beaglebone/Makefile
 create mode 100644 drivers/misc/cape/beaglebone/capemgr.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..f0c2eab 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
 	select VFP
+	select OF_OVERLAY
+	select OF_RESOLVE
 	help
 	  Compile a kernel suitable for booting most boards
 
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b151b7c..45558a3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -507,4 +507,6 @@ source "drivers/misc/lis3lv02d/Kconfig"
 source "drivers/misc/carma/Kconfig"
 source "drivers/misc/altera-stapl/Kconfig"
 source "drivers/misc/mei/Kconfig"
+source "drivers/misc/cape/Kconfig"
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2129377..c06d457 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,3 +49,4 @@ obj-y				+= carma/
 obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
 obj-$(CONFIG_ALTERA_STAPL)	+=altera-stapl/
 obj-$(CONFIG_INTEL_MEI)		+= mei/
+obj-y				+= cape/
diff --git a/drivers/misc/cape/Kconfig b/drivers/misc/cape/Kconfig
new file mode 100644
index 0000000..a2ef85e
--- /dev/null
+++ b/drivers/misc/cape/Kconfig
@@ -0,0 +1,5 @@
+#
+# Capes
+#
+
+source "drivers/misc/cape/beaglebone/Kconfig"
diff --git a/drivers/misc/cape/Makefile b/drivers/misc/cape/Makefile
new file mode 100644
index 0000000..7c4eb96
--- /dev/null
+++ b/drivers/misc/cape/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for cape like devices
+#
+
+obj-y				+= beaglebone/
diff --git a/drivers/misc/cape/beaglebone/Kconfig b/drivers/misc/cape/beaglebone/Kconfig
new file mode 100644
index 0000000..99a31ec
--- /dev/null
+++ b/drivers/misc/cape/beaglebone/Kconfig
@@ -0,0 +1,11 @@
+#
+# Beaglebone capes
+#
+
+config CAPE_BEAGLEBONE
+	tristate "Beaglebone cape support"
+	depends on ARCH_OMAP2PLUS && OF && I2C
+	default n
+	select OF_PLUGIN
+	help
+	  Say Y here to include support for beaglebone capes
diff --git a/drivers/misc/cape/beaglebone/Makefile b/drivers/misc/cape/beaglebone/Makefile
new file mode 100644
index 0000000..5b4549f
--- /dev/null
+++ b/drivers/misc/cape/beaglebone/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for beaglebone capes
+#
+
+obj-$(CONFIG_CAPE_BEAGLEBONE)		+= capemgr.o
diff --git a/drivers/misc/cape/beaglebone/capemgr.c b/drivers/misc/cape/beaglebone/capemgr.c
new file mode 100644
index 0000000..651f48d
--- /dev/null
+++ b/drivers/misc/cape/beaglebone/capemgr.c
@@ -0,0 +1,1835 @@
+/*
+ * TI Beaglebone cape controller
+ *
+ * Copyright (C) 2012 Pantelis Antoniou <panto@antoniou-consulting.com>
+ * Copyright (C) 2012 Texas Instruments 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/completion.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
+#include <linux/of_fdt.h>
+#include <linux/slab.h>
+#include <linux/pm_runtime.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/firmware.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/string.h>
+#include <linux/memory.h>
+#include <linux/i2c.h>
+#include <linux/i2c/eeprom.h>
+#include <linux/kthread.h>
+
+/* extra command line overrides */
+static char *extra_override = NULL;
+module_param(extra_override, charp, 0444);
+
+struct bone_capemgr_info;
+
+struct slot_ee_attribute {
+	struct device_attribute devattr;
+	unsigned int field;
+	struct bone_cape_slot *slot;	/* this is filled when instantiated */
+};
+#define to_slot_ee_attribute(x) \
+	container_of((x), struct slot_ee_attribute, devattr)
+
+struct bbrd_ee_attribute {
+	struct device_attribute devattr;
+	unsigned int field;
+};
+#define to_bbrd_ee_attribute(x) \
+	container_of((x), struct bbrd_ee_attribute, devattr)
+
+struct bone_cape_slot {
+	struct list_head	node;
+	struct bone_capemgr_info *info;
+	int			slotno;
+	u32			eeprom_handle;
+	int			eeprom_addr;
+	struct i2c_client	*client;
+	struct memory_accessor	*macc;
+	unsigned int		probed : 1;
+	unsigned int		probe_failed : 1;
+	unsigned int		override : 1;
+	char			text_id[256];
+	char			signature[256];
+	/* quick access */
+	char			board_name[32+1];
+	char 			version[4+1];
+	char 			manufacturer[16+1];
+	char 			part_number[16+1];
+
+	/* attribute group */
+	char			*ee_attr_name;
+	int			ee_attrs_count;
+	struct slot_ee_attribute *ee_attrs;
+	struct attribute	**ee_attrs_tab;
+	struct attribute_group	attrgroup;
+
+	unsigned int		loading : 1;
+	unsigned int		loaded : 1;
+	char			*dtbo;
+	const struct firmware	*fw;
+	struct device_node	*overlay;
+	int			ovinfo_cnt;
+	struct of_overlay_info	*ovinfo;
+
+	/* loader thread */
+	struct task_struct	*loader_thread;
+};
+
+struct bone_capemap {
+	struct list_head node;
+	char *part_number;
+	struct device_node *map_node;
+};
+
+struct bone_baseboard {
+
+	/* from the matched boardmap node */
+	char			*compatible_name;
+
+	/* filled in by reading the eeprom */
+	char			signature[256];
+	char			text_id[64+1];
+
+	/* quick access */
+	char			board_name[8+1];
+	char 			revision[4+1];
+	char 			serial_number[12+1];
+
+	/* access to the eeprom */
+	u32			eeprom_handle;
+	int			eeprom_addr;
+	struct i2c_client	*client;
+	struct memory_accessor	*macc;
+	unsigned int		probed : 1;
+	unsigned int		probe_failed : 1;
+	unsigned int		override : 1;
+};
+
+struct bone_capemgr_info {
+	struct platform_device	*pdev;
+
+	atomic_t next_slot_nr;
+	struct list_head	slot_list;
+	struct mutex		slots_list_mutex;
+
+	int capemaps_nr;
+	struct list_head	capemap_list;
+	struct mutex		capemap_mutex;
+
+	/* baseboard EEPROM data */
+	struct bone_baseboard	baseboard;
+};
+
+static int bone_slot_fill_override(struct bone_cape_slot *slot,
+		struct device_node *node,
+		const char *part_number, const char *version);
+static struct bone_cape_slot *bone_capemgr_add_slot(
+		struct bone_capemgr_info *info, struct device_node *node,
+		const char *part_number, const char *version);
+static int bone_capemgr_load(struct bone_cape_slot *slot);
+static int bone_capemgr_unload(struct bone_cape_slot *slot);
+
+/* baseboard EEPROM field definition */
+#define BBRD_EE_FIELD_HEADER		0
+#define BBRD_EE_FIELD_BOARD_NAME	1
+#define BBRD_EE_FIELD_REVISION		2
+#define BBRD_EE_FIELD_SERIAL_NUMBER	3
+#define BBRD_EE_FIELD_CONFIG_OPTION	4
+#define BBRD_EE_FILED_RSVD1		5
+#define BBRD_EE_FILED_RSVD2		6
+#define BBRD_EE_FILED_RSVD3		7
+
+/* cape EEPROM field definitions */
+#define CAPE_EE_FIELD_HEADER		0
+#define CAPE_EE_FIELD_EEPROM_REV	1
+#define CAPE_EE_FIELD_BOARD_NAME	2
+#define CAPE_EE_FIELD_VERSION		3
+#define CAPE_EE_FIELD_MANUFACTURER	4
+#define CAPE_EE_FIELD_PART_NUMBER	5
+#define CAPE_EE_FIELD_NUMBER_OF_PINS	6
+#define CAPE_EE_FIELD_SERIAL_NUMBER	7
+#define CAPE_EE_FIELD_PIN_USAGE		8
+#define CAPE_EE_FIELD_VDD_3V3EXP	9
+#define CAPE_EE_FIELD_VDD_5V		10
+#define CAPE_EE_FIELD_SYS_5V		11
+#define CAPE_EE_FIELD_DC_SUPPLIED	12
+#define CAPE_EE_FIELD_FIELDS_NR		13
+
+#define EE_FIELD_MAKE_HEADER(p)	\
+	({ \
+		const u8 *_p = (p); \
+		(((u32)_p[0] << 24) | ((u32)_p[1] << 16) | \
+		( (u32)_p[2] <<  8) |  (u32)_p[3]      ); \
+	})
+
+#define EE_FIELD_HEADER_VALID	0xaa5533ee
+
+struct ee_field {
+	const char 	*name;
+	int 		start;
+	int		size;
+	unsigned int	ascii : 1;
+	unsigned int	strip_trailing_dots : 1;
+	const char	*override;
+};
+
+/* baseboard EEPROM definitions */
+static const struct ee_field bbrd_sig_fields[] = {
+	[BBRD_EE_FIELD_HEADER] = {
+		.name		= "header",
+		.start		= 0,
+		.size		= 4,
+		.ascii		= 0,
+		.override	= "\xaa\x55\x33\xee",	/* AA 55 33 EE */
+	},
+	[BBRD_EE_FIELD_BOARD_NAME] = {
+		.name		= "board-name",
+		.start		= 4,
+		.size		= 8,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Board Name",
+	},
+	[BBRD_EE_FIELD_REVISION] = {
+		.name		= "revision",
+		.start		= 12,
+		.size		= 4,
+		.ascii		= 1,
+		.override	= "00A0",
+	},
+	[BBRD_EE_FIELD_SERIAL_NUMBER] = {
+		.name		= "serial-number",
+		.start		= 16,
+		.size		= 12,
+		.ascii		= 1,
+		.override	= "0000000000",
+	},
+	[BBRD_EE_FIELD_CONFIG_OPTION] = {
+		.name		= "config-option",
+		.start		= 28,
+		.size		= 32,
+	},
+};
+
+/* cape EEPROM definitions */
+static const struct ee_field cape_sig_fields[] = {
+	[CAPE_EE_FIELD_HEADER] = {
+		.name		= "header",
+		.start		= 0,
+		.size		= 4,
+		.ascii		= 0,
+		.override	= "\xaa\x55\x33\xee",	/* AA 55 33 EE */
+	},
+	[CAPE_EE_FIELD_EEPROM_REV] = {
+		.name		= "eeprom-format-revision",
+		.start		= 4,
+		.size		= 2,
+		.ascii		= 1,
+		.override	= "A0",
+	},
+	[CAPE_EE_FIELD_BOARD_NAME] = {
+		.name		= "board-name",
+		.start		= 6,
+		.size		= 32,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Override Board Name",
+	},
+	[CAPE_EE_FIELD_VERSION] = {
+		.name		= "version",
+		.start		= 38,
+		.size		= 4,
+		.ascii		= 1,
+		.override	= "00A0",
+	},
+	[CAPE_EE_FIELD_MANUFACTURER] = {
+		.name		= "manufacturer",
+		.start		= 42,
+		.size		= 16,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Override Manuf",
+	},
+	[CAPE_EE_FIELD_PART_NUMBER] = {
+		.name		= "part-number",
+		.start		= 58,
+		.size		= 16,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Override Part#",
+	},
+	[CAPE_EE_FIELD_NUMBER_OF_PINS] = {
+		.name		= "number-of-pins",
+		.start		= 74,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_SERIAL_NUMBER] = {
+		.name		= "serial-number",
+		.start		= 76,
+		.size		= 12,
+		.ascii		= 1,
+		.override	= "0000000000",
+	},
+	[CAPE_EE_FIELD_PIN_USAGE] = {
+		.name		= "pin-usage",
+		.start		= 88,
+		.size		= 140,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_VDD_3V3EXP] = {
+		.name		= "vdd-3v3exp",
+		.start		= 228,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_VDD_5V] = {
+		.name		= "vdd-5v",
+		.start		= 230,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_SYS_5V] = {
+		.name		= "sys-5v",
+		.start		= 232,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_DC_SUPPLIED] = {
+		.name		= "dc-supplied",
+		.start		= 234,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+};
+
+static char *ee_field_get(const struct ee_field *sig_field,
+		const void *data, int field, char *buf, int bufsz)
+{
+	int len;
+
+	/* enough space? */
+	if (bufsz < sig_field->size + sig_field->ascii)
+		return NULL;
+
+	memcpy(buf, (char *)data + sig_field->start, sig_field->size);
+
+	/* terminate ascii field */
+	if (sig_field->ascii)
+		buf[sig_field->size] = '\0';;
+
+	if (sig_field->strip_trailing_dots) {
+		len = strlen(buf);
+		while (len > 1 && buf[len - 1] == '.')
+			buf[--len] = '\0';
+	}
+
+	return buf;
+}
+
+char *bbrd_ee_field_get(const void *data,
+		int field, char *buf, int bufsz)
+{
+	if ((unsigned int)field >= ARRAY_SIZE(bbrd_sig_fields))
+		return NULL;
+
+	return ee_field_get(&bbrd_sig_fields[field], data, field, buf, bufsz);
+}
+
+char *cape_ee_field_get(const void *data,
+		int field, char *buf, int bufsz)
+{
+	if ((unsigned int)field >= ARRAY_SIZE(cape_sig_fields))
+		return NULL;
+
+	return ee_field_get(&cape_sig_fields[field], data, field, buf, bufsz);
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id bone_capemgr_of_match[] = {
+	{
+		.compatible = "ti,bone-capemgr",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, bone_capemgr_of_match);
+
+#endif
+
+static int bone_baseboard_scan(struct bone_baseboard *bbrd)
+{
+	struct bone_capemgr_info *info = container_of(bbrd,
+			struct bone_capemgr_info, baseboard);
+	struct memory_accessor *macc = bbrd->macc;
+	const u8 *p;
+	int i, r;
+
+	/* need to read EEPROM? */
+	if (bbrd->probed)
+		goto bbrd_fail_check;
+
+	bbrd->probed = 1;
+
+	if (!bbrd->override) {
+
+		if (macc == NULL || macc->read == NULL) {
+			dev_err(&info->pdev->dev,
+				"bone: No memory accessor for baseboard\n");
+			return -ENODEV;
+		}
+
+		for (i = 0; i < 10; i++) {
+
+			/* perform read */
+			r = macc->read(macc, bbrd->signature,
+					0, sizeof(bbrd->signature));
+
+			if (r == sizeof(bbrd->signature))
+				break;
+
+			dev_info(&info->pdev->dev,
+				"bone: scan failed (%d time)\n", i + 1);
+
+			msleep(500);
+		}
+
+		if (i >= 10) {
+			bbrd->probe_failed = 1;
+			return r >= 0 ? -EINVAL : r;
+		}
+
+	} else
+		dev_info(&info->pdev->dev,
+			"bone: Using override eeprom data for baseboard\n");
+
+	p = bbrd->signature;
+	if (EE_FIELD_MAKE_HEADER(p) != EE_FIELD_HEADER_VALID) {
+		dev_err(&info->pdev->dev, "bone: Invalid signature "
+			"'%08x' at baseboard\n",
+			EE_FIELD_MAKE_HEADER(p));
+		bbrd->probe_failed = 1;
+		return -ENODEV;
+	}
+
+	bbrd_ee_field_get(bbrd->signature,
+			BBRD_EE_FIELD_BOARD_NAME,
+			bbrd->board_name, sizeof(bbrd->board_name));
+	bbrd_ee_field_get(bbrd->signature,
+			BBRD_EE_FIELD_REVISION,
+			bbrd->revision, sizeof(bbrd->revision));
+	bbrd_ee_field_get(bbrd->signature,
+			BBRD_EE_FIELD_SERIAL_NUMBER,
+			bbrd->serial_number, sizeof(bbrd->serial_number));
+
+	/* board_name,version,manufacturer,part_number */
+	snprintf(bbrd->text_id, sizeof(bbrd->text_id) - 1,
+			"%s,%s,%s", bbrd->board_name, bbrd->revision,
+			bbrd->serial_number);
+
+	/* terminate always */
+	bbrd->text_id[sizeof(bbrd->text_id) - 1] = '\0';
+
+bbrd_fail_check:
+	/* bbrd has failed and we don't support hotpluging */
+	if (bbrd->probe_failed)
+		return -ENODEV;
+
+	return 0;
+}
+
+static int bone_slot_scan(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct memory_accessor *macc = slot->macc;
+	const u8 *p;
+	int r;
+
+	/* need to read EEPROM? */
+	if (slot->probed)
+		goto slot_fail_check;
+
+	slot->probed = 1;
+
+	if (!slot->override) {
+
+		if (macc == NULL || macc->read == NULL) {
+			dev_err(&info->pdev->dev,
+				"bone: No memory accessor for slot %d\n",
+				slot->slotno);
+			return -ENODEV;
+		}
+
+		/* perform read */
+		r = macc->read(macc, slot->signature,
+				0, sizeof(slot->signature));
+
+		if (r != sizeof(slot->signature)) {
+			slot->probe_failed = 1;
+			return r >= 0 ? -EINVAL : r;
+		}
+	} else
+		dev_info(&info->pdev->dev,
+			"bone: Using override eeprom data at slot %d\n",
+			slot->slotno);
+
+	p = slot->signature;
+	if (EE_FIELD_MAKE_HEADER(p) != EE_FIELD_HEADER_VALID) {
+		dev_err(&info->pdev->dev, "bone: Invalid signature "
+			"'%08x' at slot %d\n",
+			EE_FIELD_MAKE_HEADER(p),
+			slot->slotno);
+		slot->probe_failed = 1;
+		return -ENODEV;
+	}
+
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_BOARD_NAME,
+			slot->board_name, sizeof(slot->board_name));
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_VERSION,
+			slot->version, sizeof(slot->version));
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_MANUFACTURER,
+			slot->manufacturer, sizeof(slot->manufacturer));
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_PART_NUMBER,
+			slot->part_number, sizeof(slot->part_number));
+
+	/* board_name,version,manufacturer,part_number */
+	snprintf(slot->text_id, sizeof(slot->text_id) - 1,
+			"%s,%s,%s,%s", slot->board_name, slot->version,
+			slot->manufacturer, slot->part_number);
+
+	/* terminate always */
+	slot->text_id[sizeof(slot->text_id) - 1] = '\0';
+
+slot_fail_check:
+	/* slot has failed and we don't support hotpluging */
+	if (slot->probe_failed)
+		return -ENODEV;
+
+	return 0;
+}
+
+/* check an override slot node if it's compatible */
+static int bone_is_compatible_override(struct device_node *node,
+		const char *compatible_name)
+{
+	struct property *prop;
+	char *buf, *s, *e, *sn;
+	const char *part_number;
+	const char *version;
+	char *tmp_part_number, *tmp_version;
+	int found;
+
+	/* check if the slot is compatible with the board */
+	prop = of_find_property(node, "compatible", NULL);
+
+	/* no prop, it's something that's compatible with everything */
+	if (prop == NULL)
+		return 1;
+
+	/* check if it's directly compatible with the baseboard */
+	if (of_multi_prop_cmp(prop, compatible_name) == 0)
+		return 1;
+
+	/* final try, check if it's specified in the kernel command line */
+	if (extra_override == NULL)
+		return 0;
+
+	/* the compatible name should have kernel-command-line in it */
+	if (of_multi_prop_cmp(prop, "kernel-command-line") != 0)
+		return 0;
+
+	/* we must have at least the part-name */
+	if (of_property_read_string(node, "part-number",
+				&part_number) != 0)
+		return 0;
+
+	/* read the version (if it exists) */
+	if (of_property_read_string(node, "version", &version) != 0)
+		version = NULL;
+
+	/* copy the argument to work on it */
+	buf = kstrdup(extra_override, GFP_KERNEL);
+
+	/* no memory, too bad... */
+	if (buf == NULL)
+		return 0;
+
+	found = 0;
+	s = buf;
+	e = s + strlen(s);
+	while (s < e) {
+		/* find comma separator */
+		sn = strchr(s, ',');
+		if (sn != NULL)
+			*sn++ = '\0';
+		else
+			sn = e;
+		tmp_part_number = s;
+		tmp_version = strchr(tmp_part_number, ':');
+		if (tmp_version != NULL)
+			*tmp_version++ = '\0';
+		s = sn;
+
+		/* the part names must match */
+		if (strcmp(tmp_part_number, part_number) != 0)
+			continue;
+
+		pr_info("override: part-number='%s' version='%s' "
+				"tmp_version='%s'\n",
+				part_number,
+				version ? version : "N/A",
+				tmp_version ? tmp_version : "N/A");
+
+		/* if there's no version, match any */
+		if (version == NULL || tmp_version == NULL ||
+			strcmp(version, tmp_version) == 0) {
+			found = 1;
+			break;
+		}
+	}
+
+	kfree(buf);
+
+	return found;
+}
+
+static int bone_is_compatible_runtime_override(struct device_node *node,
+		const char *req_part_number, const char *req_version)
+{
+	struct property *prop;
+	const char *part_number;
+	const char *version;
+
+	/* only check overrides */
+	if (!of_property_read_bool(node, "ti,cape-override"))
+		return 0;
+
+	/* check if the slot is compatible with the board */
+	prop = of_find_property(node, "compatible", NULL);
+
+	/* no prop, it's something that's compatible with everything */
+	if (prop == NULL)
+		return 1;
+
+	/* the compatible name should have runtime in it */
+	if (of_multi_prop_cmp(prop, "runtime") != 0)
+		return 0;
+
+	/* we must have at least the part-name */
+	if (of_property_read_string(node, "part-number",
+				&part_number) != 0)
+		return 0;
+
+	/* read the version (if it exists) */
+	if (of_property_read_string(node, "version", &version) != 0)
+		version = NULL;
+
+	/* the part names must match */
+	if (strcmp(req_part_number, part_number) != 0)
+		return 0;
+
+	/* if any version is null, any version matches */
+	if (version == NULL || req_version == NULL)
+		return 1;
+
+	/* finally versions must match */
+	return strcmp(req_version, version) == 0;
+}
+
+
+static ssize_t slot_ee_attr_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct slot_ee_attribute *ee_attr = to_slot_ee_attribute(attr);
+	struct bone_cape_slot *slot = ee_attr->slot;
+	const struct ee_field *sig_field;
+	int i, len;
+	char *p, *s;
+	u16 val;
+
+	/* add newline for ascii fields */
+	sig_field = &cape_sig_fields[ee_attr->field];
+
+	len = sig_field->size + sig_field->ascii;
+	p = kmalloc(len, GFP_KERNEL);
+	if (p == NULL)
+		return -ENOMEM;
+
+	s = cape_ee_field_get(slot->signature, ee_attr->field, p, len);
+	if (s == NULL)
+		return -EINVAL;
+
+	/* add newline for ascii fields and return */
+	if (sig_field->ascii) {
+		len = sprintf(buf, "%s\n", s);
+		goto out;
+	}
+
+	/* case by case handling */
+	switch (ee_attr->field) {
+		case CAPE_EE_FIELD_HEADER:
+			len = sprintf(buf, "%02x %02x %02x %02x\n",
+					s[0], s[1], s[2], s[3]);
+			break;
+
+			/* 2 bytes */
+		case CAPE_EE_FIELD_NUMBER_OF_PINS:
+		case CAPE_EE_FIELD_VDD_3V3EXP:
+		case CAPE_EE_FIELD_VDD_5V:
+		case CAPE_EE_FIELD_SYS_5V:
+		case CAPE_EE_FIELD_DC_SUPPLIED:
+			/* the bone is LE */
+			val = s[0] & (s[1] << 8);
+			len = sprintf(buf, "%u\n", (unsigned int)val & 0xffff);
+			break;
+
+		case CAPE_EE_FIELD_PIN_USAGE:
+
+			len = 0;
+			for (i = 0; i < sig_field->size / 2; i++) {
+				/* the bone is LE */
+				val = s[0] & (s[1] << 8);
+				sprintf(buf, "%04x\n", val);
+				buf += 5;
+				len += 5;
+				s += 2;
+			}
+
+			break;
+
+		default:
+			*buf = '\0';
+			len = 0;
+			break;
+	}
+
+out:
+	kfree(p);
+
+	return len;
+}
+
+#define SLOT_EE_ATTR(_name, _field) \
+	{ \
+		.devattr = __ATTR(_name, 0440, slot_ee_attr_show, NULL), \
+		.field = CAPE_EE_FIELD_##_field , \
+		.slot = NULL, \
+	}
+
+static const struct slot_ee_attribute slot_ee_attrs[] = {
+	SLOT_EE_ATTR(header, HEADER),
+	SLOT_EE_ATTR(eeprom-format-revision, EEPROM_REV),
+	SLOT_EE_ATTR(board-name, BOARD_NAME),
+	SLOT_EE_ATTR(version, VERSION),
+	SLOT_EE_ATTR(manufacturer, MANUFACTURER),
+	SLOT_EE_ATTR(part-number, PART_NUMBER),
+	SLOT_EE_ATTR(number-of-pins, NUMBER_OF_PINS),
+	SLOT_EE_ATTR(serial-number, SERIAL_NUMBER),
+	SLOT_EE_ATTR(pin-usage, PIN_USAGE),
+	SLOT_EE_ATTR(vdd-3v3exp, VDD_3V3EXP),
+	SLOT_EE_ATTR(vdd-5v, VDD_5V),
+	SLOT_EE_ATTR(sys-5v, SYS_5V),
+	SLOT_EE_ATTR(dc-supplied, DC_SUPPLIED),
+};
+
+static int bone_cape_slot_sysfs_register(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct device *dev = &info->pdev->dev;
+	struct slot_ee_attribute *ee_attr;
+	struct attribute_group *attrgroup;
+	int i, err, sz;
+
+	slot->ee_attr_name = kasprintf(GFP_KERNEL, "slot-%d", slot->slotno);
+	if (slot->ee_attr_name == NULL) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attr_name\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attr_name;
+	}
+
+	slot->ee_attrs_count = ARRAY_SIZE(slot_ee_attrs);
+
+	sz = slot->ee_attrs_count * sizeof(*slot->ee_attrs);
+	slot->ee_attrs = kmalloc(sz, GFP_KERNEL);
+	if (slot->ee_attrs == NULL) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attrs\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attrs;
+	}
+
+	attrgroup = &slot->attrgroup;
+	memset(attrgroup, 0, sizeof(*attrgroup));
+	attrgroup->name = slot->ee_attr_name;
+
+	sz = sizeof(*slot->ee_attrs_tab) * (slot->ee_attrs_count + 1);
+	attrgroup->attrs = kmalloc(sz, GFP_KERNEL);
+	if (attrgroup->attrs == NULL) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attrs_tab\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attrs_tab;
+	}
+	/* copy everything over */
+	memcpy(slot->ee_attrs, slot_ee_attrs, sizeof(slot_ee_attrs));
+
+	/* bind this attr to the slot */
+	for (i = 0; i < slot->ee_attrs_count; i++) {
+		ee_attr = &slot->ee_attrs[i];
+		ee_attr->slot = slot;
+		attrgroup->attrs[i] = &ee_attr->devattr.attr;
+	}
+	attrgroup->attrs[i] = NULL;
+
+	err = sysfs_create_group(&dev->kobj, attrgroup);
+	if (err != 0) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attrs_tab\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attrs_group;
+	}
+
+	return 0;
+
+err_fail_no_ee_attrs_group:
+	kfree(slot->ee_attrs_tab);
+err_fail_no_ee_attrs_tab:
+	kfree(slot->ee_attrs);
+err_fail_no_ee_attrs:
+	kfree(slot->ee_attr_name);
+err_fail_no_ee_attr_name:
+	return err;
+}
+
+static void bone_cape_slot_sysfs_unregister(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct device *dev = &info->pdev->dev;
+
+	sysfs_remove_group(&dev->kobj, &slot->attrgroup);
+	kfree(slot->ee_attrs_tab);
+	kfree(slot->ee_attrs);
+	kfree(slot->ee_attr_name);
+}
+
+static ssize_t bbrd_ee_attr_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct bbrd_ee_attribute *ee_attr = to_bbrd_ee_attribute(attr);
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_baseboard *bbrd = &info->baseboard;
+	const struct ee_field *sig_field;
+	u16 val;
+	int i, len;
+	char *p, *s;
+
+	/* add newline for ascii fields */
+	sig_field = &bbrd_sig_fields[ee_attr->field];
+
+	len = sig_field->size + sig_field->ascii;
+	p = kmalloc(len, GFP_KERNEL);
+	if (p == NULL)
+		return -ENOMEM;
+
+	s = bbrd_ee_field_get(bbrd->signature, ee_attr->field, p, len);
+	if (s == NULL)
+		return -EINVAL;
+
+	/* add newline for ascii fields and return */
+	if (sig_field->ascii) {
+		len = sprintf(buf, "%s\n", s);
+		goto out;
+	}
+
+	/* case by case handling */
+	switch (ee_attr->field) {
+		case BBRD_EE_FIELD_HEADER:
+			len = sprintf(buf, "%02x %02x %02x %02x\n",
+					s[0], s[1], s[2], s[3]);
+			break;
+
+		case BBRD_EE_FIELD_CONFIG_OPTION:
+			len = 0;
+			for (i = 0; i < sig_field->size / 2; i++) {
+				/* the bone is LE */
+				val = s[0] & (s[1] << 8);
+				sprintf(buf, "%04x\n", val);
+				buf += 5;
+				len += 5;
+				s += 2;
+			}
+			break;
+
+		default:
+			*buf = '\0';
+			len = 0;
+			break;
+	}
+
+out:
+	kfree(p);
+
+	return len;
+}
+
+#define BBRD_EE_ATTR(_name, _field) \
+	{ \
+		.devattr = __ATTR(_name, 0440, bbrd_ee_attr_show, NULL), \
+		.field = BBRD_EE_FIELD_##_field , \
+	}
+
+static struct bbrd_ee_attribute bbrd_ee_attrs[] = {
+	BBRD_EE_ATTR(header, HEADER),
+	BBRD_EE_ATTR(board-name, BOARD_NAME),
+	BBRD_EE_ATTR(revision, REVISION),
+	BBRD_EE_ATTR(serial-number, SERIAL_NUMBER),
+	BBRD_EE_ATTR(config-option, CONFIG_OPTION),
+};
+
+static struct attribute *bbrd_attrs_flat[] = {
+	&bbrd_ee_attrs[BBRD_EE_FIELD_HEADER	 	].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_BOARD_NAME	 	].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_REVISION		].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_SERIAL_NUMBER	].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_CONFIG_OPTION	].devattr.attr,
+	NULL,
+};
+
+static const struct attribute_group bbrd_attr_group = {
+	.name	= "baseboard",
+	.attrs	= bbrd_attrs_flat,
+};
+
+static ssize_t slots_show(struct device *dev, struct device_attribute *attr,
+		char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_cape_slot *slot;
+	ssize_t len, sz;
+
+	mutex_lock(&info->slots_list_mutex);
+	sz = 0;
+	list_for_each_entry(slot, &info->slot_list, node) {
+
+		len = sprintf(buf, "%2d: %02x:%c%c%c%c%c %s\n",
+				slot->slotno,
+				(int)slot->client ?
+					slot->client->addr & 0x7f : 0xff,
+				slot->probed       ? 'P' : '-',
+				slot->probe_failed ? 'F' : '-',
+				slot->override     ? 'O' : '-',
+				slot->loading	   ? 'l' : '-',
+				slot->loaded	   ? 'L' : '-',
+				slot->text_id);
+
+		buf += len;
+		sz += len;
+	}
+	mutex_unlock(&info->slots_list_mutex);
+
+	return sz;
+}
+
+static ssize_t slots_store(struct device *dev, struct device_attribute *attr,
+		 const char *buf, size_t count)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_cape_slot *slot;
+	struct device_node *pnode, *node, *slots_node;
+	char *s, *part_number, *version;
+	int ret;
+	int slotno;
+
+	/* check for remove slot */
+	if (strlen(buf) > 0 && buf[0] == '-') {
+		slotno = simple_strtoul(buf + 1, NULL, 10);
+
+		/* now load each (take lock to be sure */
+		mutex_lock(&info->slots_list_mutex);
+		list_for_each_entry(slot, &info->slot_list, node) {
+			if (slotno == slot->slotno)
+				break;
+		}
+		mutex_unlock(&info->slots_list_mutex);
+
+		if (slot == NULL)
+			return -ENODEV;
+
+		bone_capemgr_unload(slot);
+
+		return strlen(buf);
+	}
+
+	part_number = kstrdup(buf, GFP_KERNEL);
+	if (part_number == NULL)
+		return -ENOMEM;
+
+	/* remove trailing spaces dots and newlines */
+	s = part_number + strlen(part_number);
+	while (s > part_number &&
+			(isspace(s[-1]) || s[-1] == '\n' || s[-1] == '.'))
+		*--s = '\0';
+
+	version = strchr(part_number, ':');
+	if (version != NULL)
+		*version++ = '\0';
+
+	dev_info(&pdev->dev, "part_number '%s', version '%s'\n",
+			part_number, version ? version : "N/A");
+
+	pnode = pdev->dev.of_node;
+	node = NULL;
+	slot = NULL;
+	ret = 0;
+
+	/* iterate over any slots */
+	slots_node = of_get_child_by_name(pnode, "slots");
+	if (slots_node != NULL) {
+		for_each_child_of_node(slots_node, node) {
+
+			/* check if the override is compatible */
+			if (!bone_is_compatible_runtime_override(node,
+						part_number, version))
+				continue;
+
+			slot = bone_capemgr_add_slot(info, node,
+					part_number, version);
+			if (IS_ERR(slot)) {
+				dev_err(&pdev->dev, "Failed to add slot #%d\n",
+					atomic_read(&info->next_slot_nr) - 1);
+				ret = PTR_ERR(slot);
+				slot = NULL;
+				goto err_fail;
+			}
+			break;
+		}
+		of_node_put(node);
+		of_node_put(slots_node);
+	}
+	slots_node = NULL;
+
+	/* no specific slot found, try immediate */
+	if (!slot)
+		slot = bone_capemgr_add_slot(info, NULL,
+				part_number, version);
+
+	if (IS_ERR_OR_NULL(slot)) {
+		dev_err(&pdev->dev, "Failed to add slot #%d\n",
+			atomic_read(&info->next_slot_nr) - 1);
+		ret = slot ? PTR_ERR(slot) : -ENODEV;
+		slot = NULL;
+		goto err_fail;
+	}
+
+	kfree(part_number);
+
+	ret = bone_capemgr_load(slot);
+
+	return ret == 0 ? strlen(buf) : ret;
+err_fail:
+	of_node_put(node);
+	of_node_put(slots_node);
+	kfree(part_number);
+	return ret;
+}
+
+static DEVICE_ATTR(slots, 0644, slots_show, slots_store);
+
+static int bone_capemgr_info_sysfs_register(struct bone_capemgr_info *info)
+{
+	struct device *dev = &info->pdev->dev;
+	int ret;
+
+	ret = device_create_file(dev, &dev_attr_slots);
+	if (ret != 0)
+		goto err_fail_no_slots;
+
+	ret = sysfs_create_group(&dev->kobj, &bbrd_attr_group);
+	if (ret != 0)
+		goto err_fail_no_bbrd_grp;
+
+	return 0;
+err_fail_no_bbrd_grp:
+	device_remove_file(dev, &dev_attr_slots);
+err_fail_no_slots:
+	return ret;
+}
+
+static void bone_capemgr_info_sysfs_unregister(struct bone_capemgr_info *info)
+{
+	struct device *dev = &info->pdev->dev;
+
+	sysfs_remove_group(&dev->kobj, &bbrd_attr_group);
+	device_remove_file(dev, &dev_attr_slots);
+}
+
+static int bone_capemgr_load(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct device *dev = &info->pdev->dev;
+	struct device_node *node;
+	struct property *prop;
+	const char *dtbo;
+	int found, err;
+	struct bone_capemap *capemap;
+
+	if (slot->probe_failed)
+		return -ENODEV;
+
+	if (slot->loaded)
+		return -EAGAIN;
+
+	mutex_lock(&info->capemap_mutex);
+	found = 0;
+	list_for_each_entry(capemap, &info->capemap_list, node) {
+		if (strcmp(capemap->part_number, slot->part_number) == 0) {
+			found = 1;
+			break;
+		}
+	}
+
+	/* found? */
+	if (found) {
+		if (capemap->map_node == NULL) {
+			mutex_unlock(&info->capemap_mutex);
+			/* need to match programatically; not supported yet */
+			dev_err(dev, "slot #%d: Failed to find capemap "
+					"for '%s'\n",
+					slot->slotno, slot->part_number);
+			return -ENODEV;
+		}
+
+		/* locate first match */
+		dtbo = NULL;
+		for_each_child_of_node(capemap->map_node, node) {
+
+			/* dtbo must exist */
+			if (of_property_read_string(node, "dtbo", &dtbo) != 0)
+				continue;
+
+			/* get version property (if any) */
+			prop = of_find_property(node, "version", NULL);
+
+			/* if no version node exists, we match */
+			if (prop == NULL)
+				break;
+
+			if (of_multi_prop_cmp(prop, slot->version) == 0)
+				break;
+		}
+
+		if (node == NULL) {
+			/* can't find dtbo version node? try the default */
+			if (of_property_read_string(capemap->map_node,
+						"dtbo", &dtbo) != 0) {
+				mutex_unlock(&info->capemap_mutex);
+				dev_err(dev, "slot #%d: Failed to find dtbo "
+						"for '%s'\n",
+						slot->slotno,
+						slot->part_number);
+				return -ENODEV;
+			}
+		}
+
+		slot->dtbo = kstrdup(dtbo, GFP_KERNEL);
+		of_node_put(node);	/* handles NULL */
+	} else {
+		dev_info(dev, "slot #%d: Requesting part number/version based "
+				"'%s-%s.dtbo\n",
+				slot->slotno,
+				slot->part_number, slot->version);
+
+		/* no specific capemap node; request the part number + .dtbo*/
+		slot->dtbo = kasprintf(GFP_KERNEL, "%s-%s.dtbo",
+				slot->part_number, slot->version);
+	}
+
+	if (slot->dtbo == NULL) {
+		mutex_unlock(&info->capemap_mutex);
+		dev_err(dev, "slot #%d: Failed to get dtbo '%s'\n",
+				slot->slotno, dtbo);
+		return -ENOMEM;
+	}
+
+	dev_info(dev, "slot #%d: Requesting firmware '%s' for board-name '%s'"
+			", version '%s'\n",
+			slot->slotno,
+			slot->dtbo, slot->board_name, slot->version);
+
+	err = request_firmware(&slot->fw, slot->dtbo, dev);
+	if (err != 0) {
+		dev_err(dev, "failed to load firmware '%s'\n", slot->dtbo);
+		mutex_unlock(&info->capemap_mutex);
+		goto err_fail_no_fw;
+	}
+
+	dev_info(dev, "slot #%d: dtbo '%s' loaded; converting to live tree\n",
+			slot->slotno, slot->dtbo);
+
+	mutex_unlock(&info->capemap_mutex);
+
+	of_fdt_unflatten_tree((void *)slot->fw->data, &slot->overlay);
+	if (slot->overlay == NULL) {
+		dev_err(dev, "slot #%d: Failed to unflatten\n",
+				slot->slotno);
+		err = -EINVAL;
+		goto err_fail;
+	}
+
+	/* mark it as detached */
+	of_node_set_flag(slot->overlay, OF_DETACHED);
+
+	/* perform resolution */
+	err = of_resolve(slot->overlay);
+	if (err != 0) {
+		dev_err(dev, "slot #%d: Failed to resolve tree\n",
+				slot->slotno);
+		goto err_fail;
+	}
+
+	/* now build an overlay info array */
+	err = of_build_overlay_info(slot->overlay,
+			&slot->ovinfo_cnt, &slot->ovinfo);
+	if (err != 0) {
+		dev_err(dev, "slot #%d: Failed to build overlay info\n",
+				slot->slotno);
+		goto err_fail;
+	}
+
+	dev_info(dev, "slot #%d: #%d overlays\n",
+			slot->slotno, slot->ovinfo_cnt);
+
+	err = of_overlay(slot->ovinfo_cnt, slot->ovinfo);
+	if (err != 0) {
+		if (err != 0) {
+			dev_err(dev, "slot #%d: Failed to overlay\n",
+					slot->slotno);
+			goto err_fail_overlay;
+		}
+	}
+
+	dev_info(dev, "slot #%d: Applied #%d overlays.\n",
+			slot->slotno, slot->ovinfo_cnt);
+
+	slot->loading = 0;
+	slot->loaded = 1;
+
+	return 0;
+
+err_fail_overlay:
+
+	of_free_overlay_info(slot->ovinfo_cnt, slot->ovinfo);
+	slot->ovinfo_cnt = 0;
+	slot->ovinfo = NULL;
+
+err_fail:
+
+	/* we can't free the overlay, because the unflatten method is a mess */
+	/* __of_free_tree(slot->overlay); */
+	slot->overlay = NULL;
+
+	release_firmware(slot->fw);
+	slot->fw = NULL;
+
+err_fail_no_fw:
+	return err;
+}
+
+static int bone_capemgr_unload(struct bone_cape_slot *slot)
+{
+	if (!slot->loaded || slot->ovinfo == NULL)
+		return -EINVAL;
+
+	of_overlay_revert(slot->ovinfo_cnt, slot->ovinfo);
+
+	slot->ovinfo_cnt = 0;
+	kfree(slot->ovinfo);
+
+	slot->loaded = 0;
+
+	return 0;
+
+}
+
+static int bone_slot_fill_override(struct bone_cape_slot *slot,
+		struct device_node *node,
+		const char *part_number, const char *version)
+{
+	const struct ee_field *sig_field;
+	struct property *prop;
+	int i, len, has_part_number;
+	char *p;
+
+	slot->probe_failed = 0;
+	slot->probed = 0;
+
+	/* zero out signature */
+	memset(slot->signature, 0,
+			sizeof(slot->signature));
+
+	/* first, fill in all with override defaults */
+	for (i = 0; i < ARRAY_SIZE(cape_sig_fields); i++) {
+
+		sig_field = &cape_sig_fields[i];
+
+		/* point to the entry */
+		p = slot->signature + sig_field->start;
+
+		if (sig_field->override)
+			memcpy(p, sig_field->override,
+					sig_field->size);
+		else
+			memset(p, 0, sig_field->size);
+	}
+
+	/* and now, fill any override data from the node */
+	has_part_number = 0;
+	if (node != NULL) {
+		for (i = 0; i < ARRAY_SIZE(cape_sig_fields); i++) {
+
+			sig_field = &cape_sig_fields[i];
+
+			/* find property with the same name (if any) */
+			prop = of_find_property(node, sig_field->name, NULL);
+			if (prop == NULL)
+				continue;
+
+			/* point to the entry */
+			p = slot->signature + sig_field->start;
+
+			/* copy and zero out any remainder */
+			len = prop->length;
+			if (prop->length > sig_field->size)
+				len = sig_field->size;
+			memcpy(p, prop->value, len);
+			if (len < sig_field->size)
+				memset(p + len, 0, sig_field->size - len);
+
+			/* remember if we got a part number which is required */
+			if (i == CAPE_EE_FIELD_PART_NUMBER && len > 0)
+				has_part_number = 1;
+		}
+	}
+
+	/* if a part_number is supplied use it */
+	if (part_number && (len = strlen(part_number)) > 0) {
+		sig_field = &cape_sig_fields[CAPE_EE_FIELD_PART_NUMBER];
+
+		/* point to the entry */
+		p = slot->signature + sig_field->start;
+
+		/* copy and zero out any remainder */
+		if (len > sig_field->size)
+			len = sig_field->size;
+		memcpy(p, part_number, len);
+		if (len < sig_field->size)
+			memset(p + len, 0, sig_field->size - len);
+
+		has_part_number = 1;
+	}
+
+	/* if a version is supplied use it */
+	if (version && (len = strlen(version)) > 0) {
+		sig_field = &cape_sig_fields[CAPE_EE_FIELD_VERSION];
+
+		/* point to the entry */
+		p = slot->signature + sig_field->start;
+
+		/* copy and zero out any remainder */
+		if (len > sig_field->size)
+			len = sig_field->size;
+		memcpy(p, version, len);
+		if (len < sig_field->size)
+			memset(p + len, 0, sig_field->size - len);
+	}
+
+	/* we must have a part number */
+	if (!has_part_number)
+		return -EINVAL;
+
+	slot->override = 1;
+
+	return 0;
+}
+
+static struct bone_cape_slot *
+bone_capemgr_add_slot(struct bone_capemgr_info *info, struct device_node *node,
+		const char *part_number, const char *version)
+{
+	struct device_node *eeprom_node;
+	struct bone_cape_slot *slot;
+	struct device *dev = &info->pdev->dev;
+	int slotno;
+	int ret;
+
+	eeprom_node = NULL;
+
+	slotno = atomic_inc_return(&info->next_slot_nr) - 1;
+
+	slot = devm_kzalloc(dev, sizeof(*slot), GFP_KERNEL);
+	if (slot == NULL) {
+		ret = -ENOMEM;
+		goto err_no_mem;
+	}
+	slot->info = info;
+	slot->slotno = slotno;
+
+	if (node && !of_property_read_bool(node, "ti,cape-override")) {
+		ret = of_property_read_u32(node, "eeprom",
+				&slot->eeprom_handle);
+		if (ret != 0) {
+			dev_err(dev, "slot #%d: failed to locate eeprom\n",
+					slotno);
+			goto err_no_eeprom;
+		}
+		eeprom_node = of_find_node_by_phandle(slot->eeprom_handle);
+		if (eeprom_node == NULL) {
+			dev_err(dev, "slot #%d: failed to find eeprom node\n",
+					slotno);
+			ret = -ENODEV;
+			goto err_no_eeprom_node;
+		}
+		slot->client = of_find_i2c_device_by_node(eeprom_node);
+		if (slot->client == NULL) {
+			dev_err(dev, "slot #%d: failed to find i2c client\n",
+					slotno);
+			ret = -ENODEV;
+			goto err_no_eeprom_client;
+		}
+		/* release ref to the node & get ref of the i2c client */
+		of_node_put(eeprom_node);
+		eeprom_node = NULL;
+		i2c_use_client(slot->client);
+
+		/* grab the memory accessor of the eeprom */
+		slot->macc = i2c_eeprom_get_memory_accessor(slot->client);
+		if (IS_ERR_OR_NULL(slot->macc)) {
+			dev_err(dev, "slot #%d: failed to get "
+					"memory accessor\n", slotno);
+			ret = slot->macc == NULL ? -ENODEV :
+				PTR_ERR(slot->macc);
+			slot->macc = NULL;
+			goto err_no_eeprom_macc;
+		}
+
+	} else {
+		if (node)
+			dev_info(dev, "slot #%d: specific override\n", slotno);
+		else
+			dev_info(dev, "slot #%d: generic override\n", slotno);
+
+		/* fill in everything with defaults first */
+		ret = bone_slot_fill_override(slot, node, part_number, version);
+		if (ret != 0) {
+			dev_err(dev, "slot #%d: override failed\n",
+					slotno);
+			goto err_no_eeprom;
+		}
+	}
+
+	ret = bone_slot_scan(slot);
+	if (ret != 0) {
+
+		if (!slot->probe_failed) {
+			dev_err(dev, "slot #%d: scan failed\n",
+					slotno);
+			goto err_bad_scan;
+		}
+
+		dev_err(dev, "slot #%d: No cape found\n",
+				slotno);
+		/* but all is fine */
+	} else {
+		dev_info(dev, "slot #%d: '%s'\n",
+				slotno, slot->text_id);
+
+		ret = bone_cape_slot_sysfs_register(slot);
+		if (ret != 0) {
+			dev_err(dev, "slot #%d: sysfs register failed\n",
+					slotno);
+			goto err_no_sysfs;
+		}
+
+	}
+
+	/* add to the slot list */
+	mutex_lock(&info->slots_list_mutex);
+	list_add_tail(&slot->node, &info->slot_list);
+	mutex_unlock(&info->slots_list_mutex);
+
+	return slot;
+
+err_no_sysfs:
+err_bad_scan:
+err_no_eeprom_macc:
+	i2c_release_client(slot->client);
+err_no_eeprom_client:
+	of_node_put(eeprom_node);	/* handles NULL */
+err_no_eeprom_node:
+	/* nothing */
+err_no_eeprom:
+	devm_kfree(dev, slot);
+
+err_no_mem:
+	return ERR_PTR(ret);
+}
+
+static int bone_capemgr_loader(void *data)
+{
+	struct bone_cape_slot *slot = data;
+
+	return bone_capemgr_load(slot);
+}
+
+static int __devinit
+bone_capemgr_probe(struct platform_device *pdev)
+{
+	struct bone_capemgr_info *info;
+	struct bone_baseboard *bbrd;
+	struct bone_cape_slot *slot;
+	struct device_node *pnode = pdev->dev.of_node;
+	struct device_node *baseboardmaps_node;
+	struct device_node *slots_node, *capemaps_node, *node;
+	struct device_node *eeprom_node;
+	const char *part_number;
+	const char *board_name;
+	const char *compatible_name;
+	struct bone_capemap *capemap;
+	int ret, len;
+
+	/* we don't use platform_data at all; we require OF */
+	if (pnode == NULL)
+		return -ENOTSUPP;
+
+	info = devm_kzalloc(&pdev->dev,
+			sizeof(struct bone_capemgr_info), GFP_KERNEL);
+	if (!info) {
+		dev_err(&pdev->dev, "Failed to allocate device structure\n");
+		return -ENOMEM;
+	}
+
+	info->pdev = pdev;
+	platform_set_drvdata(pdev, info);
+
+	atomic_set(&info->next_slot_nr, 0);
+	INIT_LIST_HEAD(&info->slot_list);
+	mutex_init(&info->slots_list_mutex);
+
+	INIT_LIST_HEAD(&info->capemap_list);
+	mutex_init(&info->capemap_mutex);
+
+	baseboardmaps_node = NULL;
+	capemaps_node = NULL;
+
+	/* find the baseboard */
+	bbrd = &info->baseboard;
+
+	baseboardmaps_node = of_get_child_by_name(pnode, "baseboardmaps");
+	if (baseboardmaps_node == NULL) {
+		dev_err(&pdev->dev, "Failed to get baseboardmaps node");
+		ret = -ENODEV;
+		goto err_exit;
+	}
+
+	/* get eeprom of the baseboard */
+	ret = of_property_read_u32(pnode, "eeprom",
+			&bbrd->eeprom_handle);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to locate baseboard eeprom\n");
+		goto err_exit;
+	}
+	eeprom_node = of_find_node_by_phandle(bbrd->eeprom_handle);
+	if (eeprom_node == NULL) {
+		dev_err(&pdev->dev, "Failed to find baseboard eeprom node\n");
+		ret = -ENODEV;
+		goto err_exit;
+	}
+	bbrd->client = of_find_i2c_device_by_node(eeprom_node);
+	of_node_put(eeprom_node);
+	eeprom_node = NULL;
+	if (bbrd->client == NULL) {
+		dev_err(&pdev->dev, "Failed to find baseboard i2c client\n");
+		ret = -ENODEV;
+		goto err_exit;
+	}
+
+	/* release ref to the node & get ref of the i2c client */
+	i2c_use_client(bbrd->client);
+
+	/* grab the memory accessor of the eeprom */
+	bbrd->macc = i2c_eeprom_get_memory_accessor(bbrd->client);
+	if (IS_ERR_OR_NULL(bbrd->macc)) {
+		dev_err(&pdev->dev, "Failed to get "
+				"baseboard memory accessor\n");
+		ret = bbrd->macc == NULL ? -ENODEV :
+			PTR_ERR(bbrd->macc);
+		bbrd->macc = NULL;
+		goto err_exit;
+	}
+
+	ret = bone_baseboard_scan(bbrd);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to scan baseboard eeprom\n");
+		goto err_exit;
+	}
+
+	dev_info(&pdev->dev, "Baseboard: '%s'\n", bbrd->text_id);
+
+	board_name = NULL;
+	compatible_name = NULL;
+	for_each_child_of_node(baseboardmaps_node, node) {
+		/* there must be board-name */
+		if (of_property_read_string(node, "board-name",
+					&board_name) != 0 ||
+		    of_property_read_string(node, "compatible-name",
+					&compatible_name) != 0)
+			continue;
+
+		if (strcmp(bbrd->board_name, board_name) == 0)
+			break;
+	}
+	of_node_put(baseboardmaps_node);
+	baseboardmaps_node = NULL;
+
+	if (node == NULL) {
+		dev_err(&pdev->dev, "Failed to find compatible map for %s\n",
+				bbrd->board_name);
+		ret = -ENODEV;
+		goto err_exit;
+	}
+	bbrd->compatible_name = kstrdup(compatible_name, GFP_KERNEL);
+	if (bbrd->compatible_name == NULL) {
+		dev_err(&pdev->dev, "Failed to allocate compatible name\n");
+		ret = -ENOMEM;
+		goto err_exit;
+	}
+	of_node_put(node);
+
+	dev_info(&pdev->dev, "compatible-baseboard=%s\n",
+			bbrd->compatible_name);
+
+	/* iterate over any capemaps */
+	capemaps_node = of_get_child_by_name(pnode, "capemaps");
+	if (capemaps_node != NULL) {
+
+		for_each_child_of_node(capemaps_node, node) {
+
+			/* there must be part-number */
+			if (of_property_read_string(node, "part-number",
+						&part_number) != 0)
+				continue;
+
+			len = sizeof(*capemap) + strlen(part_number) + 1;
+			capemap = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
+			if (capemap == NULL) {
+				dev_err(&pdev->dev, "Failed to allocate "
+						"capemap\n");
+				ret = -ENOMEM;
+				goto err_exit;
+			}
+			capemap->part_number = (char *)(capemap + 1);
+			capemap->map_node = of_node_get(node);
+			strcpy(capemap->part_number, part_number);
+
+			/* add to the slot list */
+			mutex_lock(&info->capemap_mutex);
+			list_add_tail(&capemap->node, &info->capemap_list);
+			info->capemaps_nr++;
+			mutex_unlock(&info->capemap_mutex);
+		}
+		of_node_put(capemaps_node);
+		capemaps_node = NULL;
+	}
+
+	/* iterate over any slots */
+	slots_node = of_get_child_by_name(pnode, "slots");
+	if (slots_node != NULL) {
+		for_each_child_of_node(slots_node, node) {
+
+			/* check if the override is compatible */
+			if (!bone_is_compatible_override(node,
+						bbrd->compatible_name))
+				continue;
+
+			slot = bone_capemgr_add_slot(info, node,
+					NULL, NULL);
+			if (IS_ERR(slot)) {
+				dev_err(&pdev->dev, "Failed to add slot #%d\n",
+					atomic_read(&info->next_slot_nr));
+				ret = PTR_ERR(slot);
+				goto err_exit;
+			}
+		}
+		of_node_put(slots_node);
+	}
+	slots_node = NULL;
+
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (IS_ERR_VALUE(ret)) {
+		dev_err(&pdev->dev, "Failed to pm_runtime_get_sync()\n");
+		goto err_exit;
+	}
+
+	pm_runtime_put(&pdev->dev);
+
+	bone_capemgr_info_sysfs_register(info);
+
+	/* now load each (take lock to be sure */
+	mutex_lock(&info->slots_list_mutex);
+	list_for_each_entry(slot, &info->slot_list, node) {
+		if (!slot->probe_failed && !slot->loaded) {
+			slot->loading = 1;
+			slot->loader_thread = kthread_run(bone_capemgr_loader,
+					slot, "capemgr-loader-%d",
+					slot->slotno);
+			if (IS_ERR(slot->loader_thread)) {
+				dev_warn(&pdev->dev, "slot #%d: Failed to "
+						"start loader\n", slot->slotno);
+				slot->loader_thread = NULL;
+			}
+		}
+	}
+
+	mutex_unlock(&info->slots_list_mutex);
+
+
+	dev_info(&pdev->dev, "initialized OK.\n");
+
+	return 0;
+
+err_exit:
+	of_node_put(baseboardmaps_node);
+	of_node_put(capemaps_node);
+	platform_set_drvdata(pdev, NULL);
+	devm_kfree(&pdev->dev, info);
+
+	return ret;
+}
+
+static int __devexit bone_capemgr_remove(struct platform_device *pdev)
+{
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_cape_slot *slot, *slotn;
+	int ret;
+
+	mutex_lock(&info->slots_list_mutex);
+	list_for_each_entry_safe(slot, slotn, &info->slot_list, node) {
+
+		/* unload just in case */
+		bone_capemgr_unload(slot);
+
+		/* if probed OK, remove the sysfs nodes */
+		if (slot->probed && !slot->probe_failed)
+			bone_cape_slot_sysfs_unregister(slot);
+
+		/* remove it from the list */
+		list_del(&slot->node);
+
+	}
+	mutex_unlock(&info->slots_list_mutex);
+
+	bone_capemgr_info_sysfs_unregister(info);
+
+	platform_set_drvdata(pdev, NULL);
+
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (IS_ERR_VALUE(ret))
+		return ret;
+
+	pm_runtime_put(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+
+	devm_kfree(&pdev->dev, info);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+#ifdef CONFIG_PM_RUNTIME
+static int bone_capemgr_runtime_suspend(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *_dev = platform_get_drvdata(pdev);
+
+	(void)_dev;
+	return 0;
+}
+
+static int bone_capemgr_runtime_resume(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *_dev = platform_get_drvdata(pdev);
+
+	(void)_dev;
+	return 0;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
+static struct dev_pm_ops bone_capemgr_pm_ops = {
+	SET_RUNTIME_PM_OPS(bone_capemgr_runtime_suspend,
+			   bone_capemgr_runtime_resume, NULL)
+};
+#define BONE_CAPEMGR_PM_OPS (&bone_capemgr_pm_ops)
+#else
+#define BONE_CAPEMGR_PM_OPS NULL
+#endif /* CONFIG_PM */
+
+static struct platform_driver bone_capemgr_driver = {
+	.probe		= bone_capemgr_probe,
+	.remove		= __devexit_p(bone_capemgr_remove),
+	.driver		= {
+		.name	= "bone-capemgr",
+		.owner	= THIS_MODULE,
+		.pm	= BONE_CAPEMGR_PM_OPS,
+		.of_match_table = of_match_ptr(bone_capemgr_of_match),
+	},
+};
+
+module_platform_driver(bone_capemgr_driver);
+
+MODULE_AUTHOR("Pantelis Antoniou");
+MODULE_DESCRIPTION("Beaglebone cape manager");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:bone_capemgr");
-- 
1.7.12

[PATCH 2/5] capemgr: Add beaglebone's cape driver bindings

[Pantelis Antoniou]

Document the beaglebone's cape driver bindings.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
 .../devicetree/bindings/misc/capes-beaglebone.txt  | 110 +++++++++++++++++++++
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt

diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
new file mode 100644
index 0000000..f73cab5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
@@ -0,0 +1,110 @@
+* TI Beaglebone DT Overlay Cape Driver
+
+Required properties:
+
+- compatible: "ti,bone-capemgr"
+
+- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom.
+
+- baseboardmaps - node containing a list of supported
+	beaglebone revisions; each node in should have the
+	following properties:
+	- board-name: The board name stored in the baseboard
+		eeprom.
+	- compatible-name: The name which will be used for
+		matching compatible capes.
+
+- slots: node containing a list of slot nodes (which in the beaglebone
+	case correspond to I2C addresses for dynamically probed capes,
+	or an override slot definition for hardcoded capes.
+	- eeprom: Contains the phandle beaglebone's cape i2c eeprom.
+
+	It is possible to define override slots that will be activated
+	when the baseboard matches, and/or if supplied on the kernel command
+	line and/or when dynamically requested on runtime.
+	In that case the slot is marked with
+	- ti,cape-override: Marks a slot override.
+	- compatible: any of the "runtime", "kernel", or any compatible-name
+	  on a matching baseboardmap node.
+	- Any of the eeprom-format-revision, board-name, version, manufacturer,
+	  part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp,
+	  vdd-5v, sys-5v, dc-supplied properties which fill in the simulated
+	  cape's EEPROM fields. The part-number field is required, the rest
+	  are optional taking into default values.
+
+- capemaps: node contains list of cape mappings, which allow converting
+	from a part-number & version tuple to the filename of the dtbo file.
+	- part-number: part number contained in the EEPROM
+	- version node containing a
+		- version: specific version to map to
+		- dtbo: name of the dtbo file 
+
+Example:
+bone_capemgr {
+	compatible = "ti,bone-capemgr";
+	status = "okay";
+
+	eeprom = <&baseboard_eeprom>;
+
+	baseboardmaps {
+		baseboard_beaglebone: board@0 {
+			board-name = "A335BONE";
+			compatible-name = "ti,beaglebone";
+		};
+	};
+
+	slots {
+		slot@0 {
+			eeprom = <&cape_eeprom0>;
+		};
+
+		slot@1 {
+			eeprom = <&cape_eeprom1>;
+		};
+
+		slot@2 {
+			eeprom = <&cape_eeprom2>;
+		};
+
+		slot@3 {
+			eeprom = <&cape_eeprom3>;
+		};
+	};
+
+	/* mapping between board names and dtb objects */
+	capemaps {
+		/* Weather cape */
+		cape@0 {
+			part-number = "BB-BONE-WTHR-01";
+			version@00A0 {
+				version = "00A0";
+				dtbo = "cape-bone-weather-00A0.dtbo";
+			};
+		};
+	};
+};
+
+Example of the override syntax when used on a bone compatible foo board.
+
+{
+	...
+
+	baseboardmaps {
+		...
+		baseboard_beaglebone: board@0 {
+			board-name = "A335FOO";
+			compatible-name = "ti,foo";
+		};
+
+		slot@6 {
+			ti,cape-override;
+			compatible = "ti,foo";
+			board-name = "FOO-hardcoded";
+			version = "00A0";
+			manufacturer = "Texas Instruments";
+			part-number = "BB-BONE-FOO-01";
+		};
+	};
+
+};
+	
-- 
1.7.12

[PATCH 3/5] capemgr: am335x-bone capemgr bindings

[Pantelis Antoniou]

Bindings which enable the DT overlay based cape manager for
the Texas Instruments Beaglebone platform.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
 arch/arm/boot/dts/am335x-bone.dts | 68 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..5faeece 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -38,7 +38,7 @@
 		};
 	};
 
-	ocp {
+	ocp: ocp {
 		uart1: serial@44e09000 {
 			status = "okay";
 		};
@@ -51,6 +51,35 @@
 				reg = <0x24>;
 			};
 
+			baseboard_eeprom: baseboard_eeprom@50 {
+				compatible = "at,24c256";
+				reg = <0x50>;
+			};
+		};
+
+		i2c3: i2c@4819c000 {
+			status = "okay";
+			clock-frequency = <100000>;
+
+			cape_eeprom0: cape_eeprom0@54 {
+				compatible = "at,24c256";
+				reg = <0x54>;
+			};
+
+			cape_eeprom1: cape_eeprom1@55 {
+				compatible = "at,24c256";
+				reg = <0x55>;
+			};
+
+			cape_eeprom2: cape_eeprom2@56 {
+				compatible = "at,24c256";
+				reg = <0x56>;
+			};
+
+			cape_eeprom3: cape_eeprom3@57 {
+				compatible = "at,24c256";
+				reg = <0x57>;
+			};
 		};
 	};
 
@@ -83,6 +112,43 @@
 			default-state = "off";
 		};
 	};
+
+	bone_capemgr {
+		compatible = "ti,bone-capemgr";
+		status = "okay";
+
+		eeprom = <&baseboard_eeprom>;
+
+		baseboardmaps {
+			baseboard_beaglebone: board@0 {
+				board-name = "A335BONE";
+				compatible-name = "ti,beaglebone";
+			};
+		};
+
+		slots {
+			slot@0 {
+				eeprom = <&cape_eeprom0>;
+			};
+
+			slot@1 {
+				eeprom = <&cape_eeprom1>;
+			};
+
+			slot@2 {
+				eeprom = <&cape_eeprom2>;
+			};
+
+			slot@3 {
+				eeprom = <&cape_eeprom3>;
+			};
+		};
+
+		/* mapping between board names and dtb objects */
+		capemaps {
+
+		};
+	};
 };
 
 /include/ "tps65217.dtsi"
-- 
1.7.12

[PATCH 3/5] capemgr: am335x-bone capemgr bindings

[Pantelis Antoniou]

Bindings which enable the DT overlay based cape manager for
the Texas Instruments Beaglebone platform.

Signed-off-by: Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
---
 arch/arm/boot/dts/am335x-bone.dts | 68 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..5faeece 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -38,7 +38,7 @@
 		};
 	};
 
-	ocp {
+	ocp: ocp {
 		uart1: serial@44e09000 {
 			status = "okay";
 		};
@@ -51,6 +51,35 @@
 				reg = <0x24>;
 			};
 
+			baseboard_eeprom: baseboard_eeprom@50 {
+				compatible = "at,24c256";
+				reg = <0x50>;
+			};
+		};
+
+		i2c3: i2c@4819c000 {
+			status = "okay";
+			clock-frequency = <100000>;
+
+			cape_eeprom0: cape_eeprom0@54 {
+				compatible = "at,24c256";
+				reg = <0x54>;
+			};
+
+			cape_eeprom1: cape_eeprom1@55 {
+				compatible = "at,24c256";
+				reg = <0x55>;
+			};
+
+			cape_eeprom2: cape_eeprom2@56 {
+				compatible = "at,24c256";
+				reg = <0x56>;
+			};
+
+			cape_eeprom3: cape_eeprom3@57 {
+				compatible = "at,24c256";
+				reg = <0x57>;
+			};
 		};
 	};
 
@@ -83,6 +112,43 @@
 			default-state = "off";
 		};
 	};
+
+	bone_capemgr {
+		compatible = "ti,bone-capemgr";
+		status = "okay";
+
+		eeprom = <&baseboard_eeprom>;
+
+		baseboardmaps {
+			baseboard_beaglebone: board@0 {
+				board-name = "A335BONE";
+				compatible-name = "ti,beaglebone";
+			};
+		};
+
+		slots {
+			slot@0 {
+				eeprom = <&cape_eeprom0>;
+			};
+
+			slot@1 {
+				eeprom = <&cape_eeprom1>;
+			};
+
+			slot@2 {
+				eeprom = <&cape_eeprom2>;
+			};
+
+			slot@3 {
+				eeprom = <&cape_eeprom3>;
+			};
+		};
+
+		/* mapping between board names and dtb objects */
+		capemaps {
+
+		};
+	};
 };
 
 /include/ "tps65217.dtsi"
-- 
1.7.12

[PATCH 4/5] capemgr: firmware makefiles for DT objects

[Pantelis Antoniou]

Makefile rules to support compiling DT cape definitions.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
 firmware/Makefile | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/firmware/Makefile b/firmware/Makefile
index cbb09ce..361b2af 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -147,6 +147,9 @@ quiet_cmd_mkdir = MKDIR   $(patsubst $(objtree)/%,%,$@)
 quiet_cmd_ihex  = IHEX    $@
       cmd_ihex  = $(OBJCOPY) -Iihex -Obinary $< $@
 
+quiet_cmd_dtco	= DTCO $@
+      cmd_dtco	= $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -@ $<
+
 quiet_cmd_ihex2fw  = IHEX2FW $@
       cmd_ihex2fw  = $(objtree)/$(obj)/ihex2fw $< $@
 
@@ -233,6 +236,10 @@ $(obj)/%.fw: $(obj)/%.HEX $(ihex2fw_dep) | $(objtree)/$(obj)/$$(dir %)
 $(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep) | $(objtree)/$(obj)/$$(dir %)
 	$(call cmd,h16tofw)
 
+# DTBO is device tree blob object
+$(obj)/%.dtbo: $(obj)/%.dts | $(objtree)/$(obj)/$$(dir %)
+	$(call cmd,dtco)
+
 $(firmware-dirs):
 	$(call cmd,mkdir)
 
-- 
1.7.12

[PATCH 5/5] capemgr: Weather cape cape definition

[Pantelis Antoniou]

Add the weather cape to the supported capes.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
 arch/arm/boot/dts/am335x-bone.dts         |  9 ++++-
 firmware/Makefile                         |  5 +++
 firmware/capes/cape-bone-weather-00A0.dts | 66 +++++++++++++++++++++++++++++++
 3 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 firmware/capes/cape-bone-weather-00A0.dts

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 5faeece..b02f29a 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -146,7 +146,14 @@
 
 		/* mapping between board names and dtb objects */
 		capemaps {
-
+			/* Weather cape */
+			cape@0 {
+				part-number = "BB-BONE-WTHR-01";
+				version@00A0 {
+					version = "00A0";
+					dtbo = "cape-bone-weather-00A0.dtbo";
+				};
+			};
 		};
 	};
 };
diff --git a/firmware/Makefile b/firmware/Makefile
index 361b2af..5ebb757 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -136,6 +136,11 @@ fw-shipped-$(CONFIG_USB_VICAM) += vicam/firmware.fw
 fw-shipped-$(CONFIG_VIDEO_CPIA2) += cpia2/stv0672_vp4.bin
 fw-shipped-$(CONFIG_YAM) += yam/1200.bin yam/9600.bin
 
+# Capes
+
+# the weather cape
+fw-shipped-$(CONFIG_CAPE_BEAGLEBONE) += capes/cape-bone-weather-00A0.dtbo
+
 fw-shipped-all := $(fw-shipped-y) $(fw-shipped-m) $(fw-shipped-)
 
 # Directories which we _might_ need to create, so we have a rule for them.
diff --git a/firmware/capes/cape-bone-weather-00A0.dts b/firmware/capes/cape-bone-weather-00A0.dts
new file mode 100644
index 0000000..ad91577
--- /dev/null
+++ b/firmware/capes/cape-bone-weather-00A0.dts
@@ -0,0 +1,66 @@
+/*
+* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*/
+/dts-v1/;
+/plugin/;
+
+/ {
+       compatible = "ti,beaglebone";
+       part-number = "BB-BONE-WTHR-01";
+       version = "00A0";
+
+       fragment@0 {
+               target = <&am33xx_pinmux>;
+               __overlay__ {
+			pinctrl-single,pins = <
+				0x0c 0x37       /* gpmc_ad3.gpio1_3, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */
+			>;
+               };
+       };
+
+       fragment@1 {
+               target = <&i2c3>;	/* actually I2C2 */
+
+               __overlay__ {
+		       /* needed to avoid gripping by DTC */
+		       #address-cells = <1>;
+		       #size-cells = <0>;
+
+		       /* Ambient light sensor */
+		       tsl2550@39 {
+			       compatible = "tsl,tsl2550";
+			       reg = <0x39>;
+		       };
+
+		       /* Humidity Sensor */
+		       sht21@40 {
+			       compatible = "sensiron,sht21";
+			       reg = <0x40>;
+		       };
+
+		       /* Barometric pressure sensor */
+		       bmp085@77 {
+			       compatible = "bosch,bmp085";
+			       reg = <0x77>;
+		       };
+               };
+       };
+
+       fragment@2 {
+               target = <&ocp>;
+               __overlay__ {
+		       onewire@0 {
+			       compatible      = "w1-gpio";
+			       pinctrl-names   = "default";
+			       pinctrl-0       = <&weather_cape_w1_pins>;
+			       status          = "okay";
+
+			       gpios = <&gpio2 3 0>;
+		       };
+               };
+       };
+};
-- 
1.7.12

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Tony Lindgren]

* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
> A cape loader based on DT overlays and DT objects.
> 
> Beaglebone cape manager implementation.
> 
> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> ---
>  arch/arm/mach-omap2/Kconfig            |    2 +
>  drivers/misc/Kconfig                   |    2 +
>  drivers/misc/Makefile                  |    1 +
>  drivers/misc/cape/Kconfig              |    5 +
>  drivers/misc/cape/Makefile             |    5 +
>  drivers/misc/cape/beaglebone/Kconfig   |   11 +
>  drivers/misc/cape/beaglebone/Makefile  |    5 +
>  drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++

The driver should probably be in drivers/bus?

>  8 files changed, 1866 insertions(+)
>  create mode 100644 drivers/misc/cape/Kconfig
>  create mode 100644 drivers/misc/cape/Makefile
>  create mode 100644 drivers/misc/cape/beaglebone/Kconfig
>  create mode 100644 drivers/misc/cape/beaglebone/Makefile
>  create mode 100644 drivers/misc/cape/beaglebone/capemgr.c
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 41b581f..f0c2eab 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL
>  	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>  	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
>  	select VFP
> +	select OF_OVERLAY
> +	select OF_RESOLVE
>  	help
>  	  Compile a kernel suitable for booting most boards

You should just make the driver depend on OF_OVERLAY and
OF_RESOLVE as most SoCs won't need this. Then we can select
it in the omap2plus_defconfig.

Regards,

Tony  

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Tony,

On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
>> A cape loader based on DT overlays and DT objects.
>> 
>> Beaglebone cape manager implementation.
>> 
>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
>> ---
>> arch/arm/mach-omap2/Kconfig            |    2 +
>> drivers/misc/Kconfig                   |    2 +
>> drivers/misc/Makefile                  |    1 +
>> drivers/misc/cape/Kconfig              |    5 +
>> drivers/misc/cape/Makefile             |    5 +
>> drivers/misc/cape/beaglebone/Kconfig   |   11 +
>> drivers/misc/cape/beaglebone/Makefile  |    5 +
>> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
> 
> The driver should probably be in drivers/bus?
> 

It was a bus on the previous iteration and there was a flame storm of epic proportions.

It is not a bus at all now, it's just a device loader; there are no
bus constructs at all. I am at a loss to classify it really, so drivers/misc
where every misfit ends up sounded OK.

I'm open to suggestions though.

>> 8 files changed, 1866 insertions(+)
>> create mode 100644 drivers/misc/cape/Kconfig
>> create mode 100644 drivers/misc/cape/Makefile
>> create mode 100644 drivers/misc/cape/beaglebone/Kconfig
>> create mode 100644 drivers/misc/cape/beaglebone/Makefile
>> create mode 100644 drivers/misc/cape/beaglebone/capemgr.c
>> 
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index 41b581f..f0c2eab 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL
>> 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>> 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
>> 	select VFP
>> +	select OF_OVERLAY
>> +	select OF_RESOLVE
>> 	help
>> 	  Compile a kernel suitable for booting most boards
> 
> You should just make the driver depend on OF_OVERLAY and
> OF_RESOLVE as most SoCs won't need this. Then we can select
> it in the omap2plus_defconfig.
> 

OK

> Regards,
> 
> Tony  

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Tony Lindgren]

* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:16]:
> Hi Tony,
> 
> On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:
> 
> > * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
> >> A cape loader based on DT overlays and DT objects.
> >> 
> >> Beaglebone cape manager implementation.
> >> 
> >> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> >> ---
> >> arch/arm/mach-omap2/Kconfig            |    2 +
> >> drivers/misc/Kconfig                   |    2 +
> >> drivers/misc/Makefile                  |    1 +
> >> drivers/misc/cape/Kconfig              |    5 +
> >> drivers/misc/cape/Makefile             |    5 +
> >> drivers/misc/cape/beaglebone/Kconfig   |   11 +
> >> drivers/misc/cape/beaglebone/Makefile  |    5 +
> >> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
> > 
> > The driver should probably be in drivers/bus?
> > 
> 
> It was a bus on the previous iteration and there was a flame storm of epic proportions.

Heh :)
 
> It is not a bus at all now, it's just a device loader; there are no
> bus constructs at all. I am at a loss to classify it really, so drivers/misc
> where every misfit ends up sounded OK.

Right..

> I'm open to suggestions though.

Well how about split it to an eeprom driver, and Linux generic
device loader parts?

Regards,

Tony

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Tony,

On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:16]:
>> Hi Tony,
>> 
>> On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:
>> 
>>> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
>>>> A cape loader based on DT overlays and DT objects.
>>>> 
>>>> Beaglebone cape manager implementation.
>>>> 
>>>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
>>>> ---
>>>> arch/arm/mach-omap2/Kconfig            |    2 +
>>>> drivers/misc/Kconfig                   |    2 +
>>>> drivers/misc/Makefile                  |    1 +
>>>> drivers/misc/cape/Kconfig              |    5 +
>>>> drivers/misc/cape/Makefile             |    5 +
>>>> drivers/misc/cape/beaglebone/Kconfig   |   11 +
>>>> drivers/misc/cape/beaglebone/Makefile  |    5 +
>>>> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
>>> 
>>> The driver should probably be in drivers/bus?
>>> 
>> 
>> It was a bus on the previous iteration and there was a flame storm of epic proportions.
> 
> Heh :)
> 
>> It is not a bus at all now, it's just a device loader; there are no
>> bus constructs at all. I am at a loss to classify it really, so drivers/misc
>> where every misfit ends up sounded OK.
> 
> Right..
> 
>> I'm open to suggestions though.
> 
> Well how about split it to an eeprom driver, and Linux generic
> device loader parts?
> 

All that's left is the eeprom driver (accessor) and calls to the 
generic DT overlay constructs. 

If you caught on the previous patchset about DT overlays it should be
clear.

So it is split along those lines already.


> Regards,
> 
> Tony

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Tony,

On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> [130107 12:16]:
>> Hi Tony,
>> 
>> On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:
>> 
>>> * Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> [130107 10:54]:
>>>> A cape loader based on DT overlays and DT objects.
>>>> 
>>>> Beaglebone cape manager implementation.
>>>> 
>>>> Signed-off-by: Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
>>>> ---
>>>> arch/arm/mach-omap2/Kconfig            |    2 +
>>>> drivers/misc/Kconfig                   |    2 +
>>>> drivers/misc/Makefile                  |    1 +
>>>> drivers/misc/cape/Kconfig              |    5 +
>>>> drivers/misc/cape/Makefile             |    5 +
>>>> drivers/misc/cape/beaglebone/Kconfig   |   11 +
>>>> drivers/misc/cape/beaglebone/Makefile  |    5 +
>>>> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
>>> 
>>> The driver should probably be in drivers/bus?
>>> 
>> 
>> It was a bus on the previous iteration and there was a flame storm of epic proportions.
> 
> Heh :)
> 
>> It is not a bus at all now, it's just a device loader; there are no
>> bus constructs at all. I am at a loss to classify it really, so drivers/misc
>> where every misfit ends up sounded OK.
> 
> Right..
> 
>> I'm open to suggestions though.
> 
> Well how about split it to an eeprom driver, and Linux generic
> device loader parts?
> 

All that's left is the eeprom driver (accessor) and calls to the 
generic DT overlay constructs. 

If you caught on the previous patchset about DT overlays it should be
clear.

So it is split along those lines already.


> Regards,
> 
> Tony

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Tony Lindgren]

* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:29]:
> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:
> > 
> > Well how about split it to an eeprom driver, and Linux generic
> > device loader parts?
> > 
> 
> All that's left is the eeprom driver (accessor) and calls to the 
> generic DT overlay constructs. 
>
> If you caught on the previous patchset about DT overlays it should be
> clear.
> 
> So it is split along those lines already.

Hmm I was thinking something like this:

drivers/base/device-loader.c
drivers/misc/eeprom/beaglebone-cape.c

Then you may be able to just load the configuration for it
from a .dts file and maybe no hardware specific glue is even
needed.

Regards,

Tony

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Tony,

On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:29]:
>> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:
>>> 
>>> Well how about split it to an eeprom driver, and Linux generic
>>> device loader parts?
>>> 
>> 
>> All that's left is the eeprom driver (accessor) and calls to the 
>> generic DT overlay constructs. 
>> 
>> If you caught on the previous patchset about DT overlays it should be
>> clear.
>> 
>> So it is split along those lines already.
> 
> Hmm I was thinking something like this:
> 
> drivers/base/device-loader.c
> drivers/misc/eeprom/beaglebone-cape.c
> 
> Then you may be able to just load the configuration for it
> from a .dts file and maybe no hardware specific glue is even
> needed.
> 

At the end of the line, some kind of hardware glue is going to be needed.

I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
in the beagleboard), it is a bit premature to think about making it overly
general, besides the part that are obviously part of the infrastructure 
(like the DT overlay stuff).

What I'm getting at, is that we need some user experience about this, before
going away and creating structure out of possible misconception about the uses. 

> Regards,
> 
> Tony

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Tony Lindgren]

* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:43]:
> Hi Tony,
> 
> On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote:
> 
> > * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:29]:
> >> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:
> >>> 
> >>> Well how about split it to an eeprom driver, and Linux generic
> >>> device loader parts?
> >>> 
> >> 
> >> All that's left is the eeprom driver (accessor) and calls to the 
> >> generic DT overlay constructs. 
> >> 
> >> If you caught on the previous patchset about DT overlays it should be
> >> clear.
> >> 
> >> So it is split along those lines already.
> > 
> > Hmm I was thinking something like this:
> > 
> > drivers/base/device-loader.c
> > drivers/misc/eeprom/beaglebone-cape.c
> > 
> > Then you may be able to just load the configuration for it
> > from a .dts file and maybe no hardware specific glue is even
> > needed.
> > 
> 
> At the end of the line, some kind of hardware glue is going to be needed.
> 
> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> in the beagleboard), it is a bit premature to think about making it overly
> general, besides the part that are obviously part of the infrastructure 
> (like the DT overlay stuff).
> 
> What I'm getting at, is that we need some user experience about this, before
> going away and creating structure out of possible misconception about the uses. 

IMHO stuff like this will be needed by many SoCs. Some examples of similar
things for omaps that have eventually become generic frameworks have been
the clock framework, USB OTG support, runtime PM, pinmux framework and
so on.

So I suggest a minimal generic API from the start as that will make things
a lot easier in the long run.

Regards,

Tony

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)

On Monday 07 January 2013, Tony Lindgren wrote:
> > 
> > At the end of the line, some kind of hardware glue is going to be needed.
> > 
> > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > in the beagleboard), it is a bit premature to think about making it overly
> > general, besides the part that are obviously part of the infrastructure 
> > (like the DT overlay stuff).
> > 
> > What I'm getting at, is that we need some user experience about this, before
> > going away and creating structure out of possible misconception about the uses. 
> 
> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> things for omaps that have eventually become generic frameworks have been
> the clock framework, USB OTG support, runtime PM, pinmux framework and
> so on.
> 
> So I suggest a minimal generic API from the start as that will make things
> a lot easier in the long run.

I agree. The ux500 platform already has the concept of "user interface boards",
which currently is not well integrated into devicetree. I believe Sascha
mentioned that Pengutronix had been shipping some other systems with add-on
boards and generating device tree binaries from source for each combination.

Ideally, both of the above should be able to use the same DT overlay logic
as BeagleBone, and I'm sure there are more of those.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)

On Monday 07 January 2013, Tony Lindgren wrote:
> > 
> > At the end of the line, some kind of hardware glue is going to be needed.
> > 
> > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > in the beagleboard), it is a bit premature to think about making it overly
> > general, besides the part that are obviously part of the infrastructure 
> > (like the DT overlay stuff).
> > 
> > What I'm getting at, is that we need some user experience about this, before
> > going away and creating structure out of possible misconception about the uses. 
> 
> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> things for omaps that have eventually become generic frameworks have been
> the clock framework, USB OTG support, runtime PM, pinmux framework and
> so on.
> 
> So I suggest a minimal generic API from the start as that will make things
> a lot easier in the long run.

I agree. The ux500 platform already has the concept of "user interface boards",
which currently is not well integrated into devicetree. I believe Sascha
mentioned that Pengutronix had been shipping some other systems with add-on
boards and generating device tree binaries from source for each combination.

Ideally, both of the above should be able to use the same DT overlay logic
as BeagleBone, and I'm sure there are more of those.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Arnd,

On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:

> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
>>> 
>>> At the end of the line, some kind of hardware glue is going to be needed.
>>> 
>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>> in the beagleboard), it is a bit premature to think about making it overly
>>> general, besides the part that are obviously part of the infrastructure 
>>> (like the DT overlay stuff).
>>> 
>>> What I'm getting at, is that we need some user experience about this, before
>>> going away and creating structure out of possible misconception about the uses. 
>> 
>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>> things for omaps that have eventually become generic frameworks have been
>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>> so on.
>> 
>> So I suggest a minimal generic API from the start as that will make things
>> a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
> 
> 	Arnd

Hmm, I see. 

I will need some more information about the interface of the 'user interface boards'.
I.e. how is the board identified, what is typically present on those boards, etc.

Can we get some input by the owner of other similar hardware? I know the FPGA
people have similar requirements for example. There are other people that are hitting
problems getting DT to work with their systems, like the V4L people with the order
of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
cleanly solved by the overlay being contained in the V4L device node and applied just before
the device is probed.

In the meantime it would be better to wait until we have some ack from the maintainers
of the core subsystems about what they think.
 
Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Arnd,

On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:

> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
>>> 
>>> At the end of the line, some kind of hardware glue is going to be needed.
>>> 
>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>> in the beagleboard), it is a bit premature to think about making it overly
>>> general, besides the part that are obviously part of the infrastructure 
>>> (like the DT overlay stuff).
>>> 
>>> What I'm getting at, is that we need some user experience about this, before
>>> going away and creating structure out of possible misconception about the uses. 
>> 
>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>> things for omaps that have eventually become generic frameworks have been
>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>> so on.
>> 
>> So I suggest a minimal generic API from the start as that will make things
>> a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
> 
> 	Arnd

Hmm, I see. 

I will need some more information about the interface of the 'user interface boards'.
I.e. how is the board identified, what is typically present on those boards, etc.

Can we get some input by the owner of other similar hardware? I know the FPGA
people have similar requirements for example. There are other people that are hitting
problems getting DT to work with their systems, like the V4L people with the order
of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
cleanly solved by the overlay being contained in the V4L device node and applied just before
the device is probed.

In the meantime it would be better to wait until we have some ack from the maintainers
of the core subsystems about what they think.
 
Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Guennadi Liakhovetski]

(adding linux-media ML to cc)

Hi Pantelis

On Tue, 8 Jan 2013, Pantelis Antoniou wrote:

> Hi Arnd,
> 
> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
> 
> > (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> > 
> > On Monday 07 January 2013, Tony Lindgren wrote:
> >>> 
> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> > 
> > 	Arnd
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.
> 
> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.

You probably mean these related V4L patches: 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
that base upon of asynchronous V4L2 subdevice probing, referenced above. 
Yes, V4L DT nodes, as documented in 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
contain "port" and "endpoint" nodes, that describe the configuration of 
the hardware port and link to devices, connected to it. Not sure how well 
this would work with DT overlays, because endpoint nodes on both sides of 
the video data bus contain references to the other side and I don't know 
whether and how these can be created and / or updated at run-time. 
Otherwise, yes, the approach that we're currently developing on V4L allows 
us to build video data pipelines independent of (sub)device driver probing 
order.

Thanks
Guennadi

> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Guennadi Liakhovetski]

(adding linux-media ML to cc)

Hi Pantelis

On Tue, 8 Jan 2013, Pantelis Antoniou wrote:

> Hi Arnd,
> 
> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
> 
> > (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> > 
> > On Monday 07 January 2013, Tony Lindgren wrote:
> >>> 
> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> > 
> > 	Arnd
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.
> 
> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.

You probably mean these related V4L patches: 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
that base upon of asynchronous V4L2 subdevice probing, referenced above. 
Yes, V4L DT nodes, as documented in 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
contain "port" and "endpoint" nodes, that describe the configuration of 
the hardware port and link to devices, connected to it. Not sure how well 
this would work with DT overlays, because endpoint nodes on both sides of 
the video data bus contain references to the other side and I don't know 
whether and how these can be created and / or updated at run-time. 
Otherwise, yes, the approach that we're currently developing on V4L allows 
us to build video data pipelines independent of (sub)device driver probing 
order.

Thanks
Guennadi

> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Lee Jones]

> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.

User Interface Boards are mearly removable PCBs which are interchangeable
amongst various hardware platforms. They are connected via numerous
connectors which carry all sorts of different data links; i2c, spi, rs232,
etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
pad, leds, jumpers, switches and a bunch of sensors.

You can find a small example of how we interface to these by viewing
'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
currently include it as a *.dtsi from a platform's dts file.

> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.
> 
> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis
> 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Lee Jones]

> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.

User Interface Boards are mearly removable PCBs which are interchangeable
amongst various hardware platforms. They are connected via numerous
connectors which carry all sorts of different data links; i2c, spi, rs232,
etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
pad, leds, jumpers, switches and a bunch of sensors.

You can find a small example of how we interface to these by viewing
'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
currently include it as a *.dtsi from a platform's dts file.

> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.
> 
> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis
> 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Guennadi,

On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:

> (adding linux-media ML to cc)
> 
> Hi Pantelis
> 
> On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
> 
>> Hi Arnd,
>> 
>> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
>> 
>>> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
>>> 
>>> On Monday 07 January 2013, Tony Lindgren wrote:
>>>>> 
>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>>> 
>>> 	Arnd
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
>> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
> 
> You probably mean these related V4L patches: 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
> that base upon of asynchronous V4L2 subdevice probing, referenced above. 
> Yes, V4L DT nodes, as documented in 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
> contain "port" and "endpoint" nodes, that describe the configuration of 
> the hardware port and link to devices, connected to it. Not sure how well 
> this would work with DT overlays, because endpoint nodes on both sides of 
> the video data bus contain references to the other side and I don't know 
> whether and how these can be created and / or updated at run-time. 
> Otherwise, yes, the approach that we're currently developing on V4L allows 
> us to build video data pipelines independent of (sub)device driver probing 
> order.
> 

I'm not very well versed at the V4L intricacies, and correct me if I got it wrong,
but it seems like you have the  problem on needing to probe a bunch of devices only after 
the parent device has been probed successfully. 
Your async subdevice probing method seems to be doing this.

It might be simpler to do something like this:

v4ldevice {
	compatible = "foo,v4ldev";
	...
	overlay {
		fragment@0 {
			target = <&i2c0>;
			__overlay__ {
				...
				/* i2c devices */
			};
		};
		fragment@0 {
			target = <&ocp>;
			__overlay__ {
				..
				/* platform devices */
			};
		};
		...
	}:
};

And in the probe of the v4ldev apply the overlay. The i2c devices will end up in the
i2c node, the platform devices to the ocp node, etc, and will be registered.

There is nothing preventing the overlay being in a part of the board dts file. 
You will need to do a resolve pass for the phandles, but it's not insurmountable IMO.

Regards

-- Pantelis

> Thanks
> Guennadi
> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Guennadi,

On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:

> (adding linux-media ML to cc)
> 
> Hi Pantelis
> 
> On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
> 
>> Hi Arnd,
>> 
>> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
>> 
>>> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
>>> 
>>> On Monday 07 January 2013, Tony Lindgren wrote:
>>>>> 
>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>>> 
>>> 	Arnd
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
>> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
> 
> You probably mean these related V4L patches: 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
> that base upon of asynchronous V4L2 subdevice probing, referenced above. 
> Yes, V4L DT nodes, as documented in 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
> contain "port" and "endpoint" nodes, that describe the configuration of 
> the hardware port and link to devices, connected to it. Not sure how well 
> this would work with DT overlays, because endpoint nodes on both sides of 
> the video data bus contain references to the other side and I don't know 
> whether and how these can be created and / or updated at run-time. 
> Otherwise, yes, the approach that we're currently developing on V4L allows 
> us to build video data pipelines independent of (sub)device driver probing 
> order.
> 

I'm not very well versed at the V4L intricacies, and correct me if I got it wrong,
but it seems like you have the  problem on needing to probe a bunch of devices only after 
the parent device has been probed successfully. 
Your async subdevice probing method seems to be doing this.

It might be simpler to do something like this:

v4ldevice {
	compatible = "foo,v4ldev";
	...
	overlay {
		fragment@0 {
			target = <&i2c0>;
			__overlay__ {
				...
				/* i2c devices */
			};
		};
		fragment@0 {
			target = <&ocp>;
			__overlay__ {
				..
				/* platform devices */
			};
		};
		...
	}:
};

And in the probe of the v4ldev apply the overlay. The i2c devices will end up in the
i2c node, the platform devices to the ocp node, etc, and will be registered.

There is nothing preventing the overlay being in a part of the board dts file. 
You will need to do a resolve pass for the phandles, but it's not insurmountable IMO.

Regards

-- Pantelis

> Thanks
> Guennadi
> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Lee,

On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:

>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
> 
> User Interface Boards are mearly removable PCBs which are interchangeable
> amongst various hardware platforms. They are connected via numerous
> connectors which carry all sorts of different data links; i2c, spi, rs232,
> etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> pad, leds, jumpers, switches and a bunch of sensors.
> 
> You can find a small example of how we interface to these by viewing
> 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> currently include it as a *.dtsi from a platform's dts file.

I see. What I'm asking about is whether there's a method where you can read
an EEPROM, or some GPIO code combination where I can find out what kind of board
is plugged each time.

If there is not, there is no way to automatically load the overlays; you can always
use the kernel command line, or have the a user space application to request the loading
of a specific board's overlay.

Regards

-- Pantelis

> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
>> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
>> 
> 
> -- 
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Lee,

On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:

>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
> 
> User Interface Boards are mearly removable PCBs which are interchangeable
> amongst various hardware platforms. They are connected via numerous
> connectors which carry all sorts of different data links; i2c, spi, rs232,
> etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> pad, leds, jumpers, switches and a bunch of sensors.
> 
> You can find a small example of how we interface to these by viewing
> 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> currently include it as a *.dtsi from a platform's dts file.

I see. What I'm asking about is whether there's a method where you can read
an EEPROM, or some GPIO code combination where I can find out what kind of board
is plugged each time.

If there is not, there is no way to automatically load the overlays; you can always
use the kernel command line, or have the a user space application to request the loading
of a specific board's overlay.

Regards

-- Pantelis

> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
>> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
>> 
> 
> -- 
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Lee Jones]

On Tue, 08 Jan 2013, Pantelis Antoniou wrote:

> Hi Lee,
> 
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> 
> >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> >>>>> 
> >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>>>> in the beagleboard), it is a bit premature to think about making it overly
> >>>>> general, besides the part that are obviously part of the infrastructure 
> >>>>> (like the DT overlay stuff).
> >>>>> 
> >>>>> What I'm getting at, is that we need some user experience about this, before
> >>>>> going away and creating structure out of possible misconception about the uses. 
> >>>> 
> >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >>>> things for omaps that have eventually become generic frameworks have been
> >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >>>> so on.
> >>>> 
> >>>> So I suggest a minimal generic API from the start as that will make things
> >>>> a lot easier in the long run.
> >>> 
> >>> I agree. The ux500 platform already has the concept of "user interface boards",
> >>> which currently is not well integrated into devicetree. I believe Sascha
> >>> mentioned that Pengutronix had been shipping some other systems with add-on
> >>> boards and generating device tree binaries from source for each combination.
> >>> 
> >>> Ideally, both of the above should be able to use the same DT overlay logic
> >>> as BeagleBone, and I'm sure there are more of those.
> >> 
> >> Hmm, I see. 
> >> 
> >> I will need some more information about the interface of the 'user interface boards'.
> >> I.e. how is the board identified, what is typically present on those boards, etc.
> > 
> > User Interface Boards are mearly removable PCBs which are interchangeable
> > amongst various hardware platforms. They are connected via numerous
> > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > pad, leds, jumpers, switches and a bunch of sensors.
> > 
> > You can find a small example of how we interface to these by viewing
> > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > currently include it as a *.dtsi from a platform's dts file.
> 
> I see. What I'm asking about is whether there's a method where you can read
> an EEPROM, or some GPIO code combination where I can find out what kind of board
> is plugged each time.
> 
> If there is not, there is no way to automatically load the overlays; you can always
> use the kernel command line, or have the a user space application to request the loading
> of a specific board's overlay.

Unfortunately, there is no way to probe the UIBs. :(

> >> Can we get some input by the owner of other similar hardware? I know the FPGA
> >> people have similar requirements for example. There are other people that are hitting
> >> problems getting DT to work with their systems, like the V4L people with the order
> >> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> >> cleanly solved by the overlay being contained in the V4L device node and applied just before
> >> the device is probed.
> >> 
> >> In the meantime it would be better to wait until we have some ack from the maintainers
> >> of the core subsystems about what they think.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Lee Jones]

On Tue, 08 Jan 2013, Pantelis Antoniou wrote:

> Hi Lee,
> 
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> 
> >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> >>>>> 
> >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>>>> in the beagleboard), it is a bit premature to think about making it overly
> >>>>> general, besides the part that are obviously part of the infrastructure 
> >>>>> (like the DT overlay stuff).
> >>>>> 
> >>>>> What I'm getting at, is that we need some user experience about this, before
> >>>>> going away and creating structure out of possible misconception about the uses. 
> >>>> 
> >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >>>> things for omaps that have eventually become generic frameworks have been
> >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >>>> so on.
> >>>> 
> >>>> So I suggest a minimal generic API from the start as that will make things
> >>>> a lot easier in the long run.
> >>> 
> >>> I agree. The ux500 platform already has the concept of "user interface boards",
> >>> which currently is not well integrated into devicetree. I believe Sascha
> >>> mentioned that Pengutronix had been shipping some other systems with add-on
> >>> boards and generating device tree binaries from source for each combination.
> >>> 
> >>> Ideally, both of the above should be able to use the same DT overlay logic
> >>> as BeagleBone, and I'm sure there are more of those.
> >> 
> >> Hmm, I see. 
> >> 
> >> I will need some more information about the interface of the 'user interface boards'.
> >> I.e. how is the board identified, what is typically present on those boards, etc.
> > 
> > User Interface Boards are mearly removable PCBs which are interchangeable
> > amongst various hardware platforms. They are connected via numerous
> > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > pad, leds, jumpers, switches and a bunch of sensors.
> > 
> > You can find a small example of how we interface to these by viewing
> > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > currently include it as a *.dtsi from a platform's dts file.
> 
> I see. What I'm asking about is whether there's a method where you can read
> an EEPROM, or some GPIO code combination where I can find out what kind of board
> is plugged each time.
> 
> If there is not, there is no way to automatically load the overlays; you can always
> use the kernel command line, or have the a user space application to request the loading
> of a specific board's overlay.

Unfortunately, there is no way to probe the UIBs. :(

> >> Can we get some input by the owner of other similar hardware? I know the FPGA
> >> people have similar requirements for example. There are other people that are hitting
> >> problems getting DT to work with their systems, like the V4L people with the order
> >> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> >> cleanly solved by the overlay being contained in the V4L device node and applied just before
> >> the device is probed.
> >> 
> >> In the meantime it would be better to wait until we have some ack from the maintainers
> >> of the core subsystems about what they think.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Sascha Hauer]

On Mon, Jan 07, 2013 at 09:35:04PM +0000, Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.

What we have is usually CPU modules which can have different base
boards. Usually they are not detectable by software. Right now we
normally use a baseboard dts which includes a board dtd which then
includes the SoC dtsi. This works quite well on dtc level.

For us overlay dts become interesting when it comes to all the little
variants of the boards, like for example different displays, different
touchscreens,...

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: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Sascha Hauer]

On Mon, Jan 07, 2013 at 09:35:04PM +0000, Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.

What we have is usually CPU modules which can have different base
boards. Usually they are not detectable by software. Right now we
normally use a baseboard dts which includes a board dtd which then
includes the SoC dtsi. This works quite well on dtc level.

For us overlay dts become interesting when it comes to all the little
variants of the boards, like for example different displays, different
touchscreens,...

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: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Tuesday 08 January 2013, Lee Jones wrote:
> > If there is not, there is no way to automatically load the overlays; you can always
> > use the kernel command line, or have the a user space application to request the loading
> > of a specific board's overlay.
> 
> Unfortunately, there is no way to probe the UIBs. :(

I thought that some of the newer UIBs had it, just not the old ones.
As Pantelis says, we could at least detect the ones that have an EEPROM
on them, and use a command line option or device tree attribute for the others.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Tuesday 08 January 2013, Lee Jones wrote:
> > If there is not, there is no way to automatically load the overlays; you can always
> > use the kernel command line, or have the a user space application to request the loading
> > of a specific board's overlay.
> 
> Unfortunately, there is no way to probe the UIBs. :(

I thought that some of the newer UIBs had it, just not the old ones.
As Pantelis says, we could at least detect the ones that have an EEPROM
on them, and use a command line option or device tree attribute for the others.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Arnd,

On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:

> On Tuesday 08 January 2013, Lee Jones wrote:
>>> If there is not, there is no way to automatically load the overlays; you can always
>>> use the kernel command line, or have the a user space application to request the loading
>>> of a specific board's overlay.
>> 
>> Unfortunately, there is no way to probe the UIBs. :(
> 
> I thought that some of the newer UIBs had it, just not the old ones.
> As Pantelis says, we could at least detect the ones that have an EEPROM
> on them, and use a command line option or device tree attribute for the others.
> 
> 	Arnd

So I gather the new ones have an eeprom?

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Arnd,

On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:

> On Tuesday 08 January 2013, Lee Jones wrote:
>>> If there is not, there is no way to automatically load the overlays; you can always
>>> use the kernel command line, or have the a user space application to request the loading
>>> of a specific board's overlay.
>> 
>> Unfortunately, there is no way to probe the UIBs. :(
> 
> I thought that some of the newer UIBs had it, just not the old ones.
> As Pantelis says, we could at least detect the ones that have an EEPROM
> on them, and use a command line option or device tree attribute for the others.
> 
> 	Arnd

So I gather the new ones have an eeprom?

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Tuesday 08 January 2013, Pantelis Antoniou wrote:
> On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
> 
> > On Tuesday 08 January 2013, Lee Jones wrote:
> >>> If there is not, there is no way to automatically load the overlays; you can always
> >>> use the kernel command line, or have the a user space application to request the loading
> >>> of a specific board's overlay.
> >> 
> >> Unfortunately, there is no way to probe the UIBs. :(
> > 
> > I thought that some of the newer UIBs had it, just not the old ones.
> > As Pantelis says, we could at least detect the ones that have an EEPROM
> > on them, and use a command line option or device tree attribute for the others.
> > 
> >       Arnd
> 
> So I gather the new ones have an eeprom?

I don't remember the details unfortunately. Lee should be the one who can find out.
IIRC there was at least a single integeger number on them.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Tuesday 08 January 2013, Pantelis Antoniou wrote:
> On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
> 
> > On Tuesday 08 January 2013, Lee Jones wrote:
> >>> If there is not, there is no way to automatically load the overlays; you can always
> >>> use the kernel command line, or have the a user space application to request the loading
> >>> of a specific board's overlay.
> >> 
> >> Unfortunately, there is no way to probe the UIBs. :(
> > 
> > I thought that some of the newer UIBs had it, just not the old ones.
> > As Pantelis says, we could at least detect the ones that have an EEPROM
> > on them, and use a command line option or device tree attribute for the others.
> > 
> >       Arnd
> 
> So I gather the new ones have an eeprom?

I don't remember the details unfortunately. Lee should be the one who can find out.
IIRC there was at least a single integeger number on them.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Lee Jones]

On Tue, 08 Jan 2013, Arnd Bergmann wrote:

> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
> > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
> > 
> > > On Tuesday 08 January 2013, Lee Jones wrote:
> > >>> If there is not, there is no way to automatically load the overlays; you can always
> > >>> use the kernel command line, or have the a user space application to request the loading
> > >>> of a specific board's overlay.
> > >> 
> > >> Unfortunately, there is no way to probe the UIBs. :(
> > > 
> > > I thought that some of the newer UIBs had it, just not the old ones.
> > > As Pantelis says, we could at least detect the ones that have an EEPROM
> > > on them, and use a command line option or device tree attribute for the others.
> > > 
> > >       Arnd
> > 
> > So I gather the new ones have an eeprom?
> 
> I don't remember the details unfortunately. Lee should be the one who can find out.
> IIRC there was at least a single integeger number on them.

Not as far as I can remember. There was (is?) a crude method of
identifying UIBs, but attempting to obtain certain I2C lines and
testing which ones were accessible. However, if there is an issue
with I2C, the wrong UIB was 'probed'.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Lee Jones]

On Tue, 08 Jan 2013, Arnd Bergmann wrote:

> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
> > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
> > 
> > > On Tuesday 08 January 2013, Lee Jones wrote:
> > >>> If there is not, there is no way to automatically load the overlays; you can always
> > >>> use the kernel command line, or have the a user space application to request the loading
> > >>> of a specific board's overlay.
> > >> 
> > >> Unfortunately, there is no way to probe the UIBs. :(
> > > 
> > > I thought that some of the newer UIBs had it, just not the old ones.
> > > As Pantelis says, we could at least detect the ones that have an EEPROM
> > > on them, and use a command line option or device tree attribute for the others.
> > > 
> > >       Arnd
> > 
> > So I gather the new ones have an eeprom?
> 
> I don't remember the details unfortunately. Lee should be the one who can find out.
> IIRC there was at least a single integeger number on them.

Not as far as I can remember. There was (is?) a crude method of
identifying UIBs, but attempting to obtain certain I2C lines and
testing which ones were accessible. However, if there is an issue
with I2C, the wrong UIB was 'probed'.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Linus Walleij]

On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 08 Jan 2013, Arnd Bergmann wrote:
>
>> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
>> > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
>> >
>> > > On Tuesday 08 January 2013, Lee Jones wrote:
>> > >>> If there is not, there is no way to automatically load the overlays; you can always
>> > >>> use the kernel command line, or have the a user space application to request the loading
>> > >>> of a specific board's overlay.
>> > >>
>> > >> Unfortunately, there is no way to probe the UIBs. :(
>> > >
>> > > I thought that some of the newer UIBs had it, just not the old ones.
>> > > As Pantelis says, we could at least detect the ones that have an EEPROM
>> > > on them, and use a command line option or device tree attribute for the others.
>> > >
>> > >       Arnd
>> >
>> > So I gather the new ones have an eeprom?
>>
>> I don't remember the details unfortunately. Lee should be the one who can find out.
>> IIRC there was at least a single integeger number on them.
>
> Not as far as I can remember. There was (is?) a crude method of
> identifying UIBs, but attempting to obtain certain I2C lines and
> testing which ones were accessible. However, if there is an issue
> with I2C, the wrong UIB was 'probed'.

Right, so the UIBs had different GPIO expanders on some I2C addresses,
so we attempt to communicate with the expander to see if it's board type A,
and if it doesn't respond it's deemed to be board type B.

This is the code:
arch/arm/mach-ux500/board-mop500-uib.c

/*
 * Detect the UIB attached based on the presence or absence of i2c devices.
 */
int __init mop500_uib_init(void)
{
        struct uib *uib = mop500_uib;
        struct i2c_adapter *i2c0;
        int ret;

        if (!cpu_is_u8500_family())
                return -ENODEV;

        if (uib) {
                __mop500_uib_init(uib, "from uib= boot argument");
                return 0;
        }

        i2c0 = i2c_get_adapter(0);
        if (!i2c0) {
                __mop500_uib_init(&mop500_uibs[STUIB],
                                "fallback, could not get i2c0");
                return -ENODEV;
        }

        /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
        ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
                        I2C_SMBUS_QUICK, NULL);
        i2c_put_adapter(i2c0);

        if (ret == 0)
                uib = &mop500_uibs[U8500UIB];
        else
                uib = &mop500_uibs[STUIB];

        __mop500_uib_init(uib, "detected");

        return 0;
}

Not elegant but better than e.g. passing a kernel command line option.

As you say it has the downside of detecting the wrong UIB if there is
some (other) problem with the I2C block. But in that case the system is
likely borked anyway so I wonder if it matters...

Even with the device tree approach we'd be into trouble if say, the UIB
was unplugged (which is perfectly possible). The device tree cannot
detect that.

The larger question is how to handle, at runtime, hardware that may
or may not be present, in a device tree world.

Compare this other case: the Integrator has pluggable daughterboards,
(called LMs, logic modules) and in that case we have specific registers
to detect them, and register the daughter board on this specific bus
that Russell came up with in arch/arm/mach-integrator/lm.c,
the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:

static void __init ap_init(void)
{
        unsigned long sc_dec;
        int i;

        platform_device_register(&cfi_flash_device);

        sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
        for (i = 0; i < 4; i++) {
                struct lm_device *lmdev;

                if ((sc_dec & (16 << i)) == 0)
                        continue;

                lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
                if (!lmdev)
                        continue;

                lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
                lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
                lmdev->resource.flags = IORESOURCE_MEM;
                lmdev->irq = IRQ_AP_EXPINT0 + i;
                lmdev->id = i;

                lm_device_register(lmdev);
        }

        integrator_init(false);
}

In this case I think the autodetect is so nice that device tree probing
is mostly pointless. If it wasn't for the fact that we get a
cross-depenency to defined interrupts and clocks and whatever that
are coming from the device tree. Which is where DT shows its
all-or-nothing face.

So to get an elegant DT probing in this case I *guess* the right thing
to do is to dynamically add nodes to the device tree from the board
code, or have all alternatives inside the DT marked "disable" and then
mark them as "okay" from the board code by modifying the DT at
runtime.

Ideas welcome.

Yours,
Linus Walleij

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Linus Walleij]

On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 08 Jan 2013, Arnd Bergmann wrote:
>
>> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
>> > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
>> >
>> > > On Tuesday 08 January 2013, Lee Jones wrote:
>> > >>> If there is not, there is no way to automatically load the overlays; you can always
>> > >>> use the kernel command line, or have the a user space application to request the loading
>> > >>> of a specific board's overlay.
>> > >>
>> > >> Unfortunately, there is no way to probe the UIBs. :(
>> > >
>> > > I thought that some of the newer UIBs had it, just not the old ones.
>> > > As Pantelis says, we could at least detect the ones that have an EEPROM
>> > > on them, and use a command line option or device tree attribute for the others.
>> > >
>> > >       Arnd
>> >
>> > So I gather the new ones have an eeprom?
>>
>> I don't remember the details unfortunately. Lee should be the one who can find out.
>> IIRC there was at least a single integeger number on them.
>
> Not as far as I can remember. There was (is?) a crude method of
> identifying UIBs, but attempting to obtain certain I2C lines and
> testing which ones were accessible. However, if there is an issue
> with I2C, the wrong UIB was 'probed'.

Right, so the UIBs had different GPIO expanders on some I2C addresses,
so we attempt to communicate with the expander to see if it's board type A,
and if it doesn't respond it's deemed to be board type B.

This is the code:
arch/arm/mach-ux500/board-mop500-uib.c

/*
 * Detect the UIB attached based on the presence or absence of i2c devices.
 */
int __init mop500_uib_init(void)
{
        struct uib *uib = mop500_uib;
        struct i2c_adapter *i2c0;
        int ret;

        if (!cpu_is_u8500_family())
                return -ENODEV;

        if (uib) {
                __mop500_uib_init(uib, "from uib= boot argument");
                return 0;
        }

        i2c0 = i2c_get_adapter(0);
        if (!i2c0) {
                __mop500_uib_init(&mop500_uibs[STUIB],
                                "fallback, could not get i2c0");
                return -ENODEV;
        }

        /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
        ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
                        I2C_SMBUS_QUICK, NULL);
        i2c_put_adapter(i2c0);

        if (ret == 0)
                uib = &mop500_uibs[U8500UIB];
        else
                uib = &mop500_uibs[STUIB];

        __mop500_uib_init(uib, "detected");

        return 0;
}

Not elegant but better than e.g. passing a kernel command line option.

As you say it has the downside of detecting the wrong UIB if there is
some (other) problem with the I2C block. But in that case the system is
likely borked anyway so I wonder if it matters...

Even with the device tree approach we'd be into trouble if say, the UIB
was unplugged (which is perfectly possible). The device tree cannot
detect that.

The larger question is how to handle, at runtime, hardware that may
or may not be present, in a device tree world.

Compare this other case: the Integrator has pluggable daughterboards,
(called LMs, logic modules) and in that case we have specific registers
to detect them, and register the daughter board on this specific bus
that Russell came up with in arch/arm/mach-integrator/lm.c,
the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:

static void __init ap_init(void)
{
        unsigned long sc_dec;
        int i;

        platform_device_register(&cfi_flash_device);

        sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
        for (i = 0; i < 4; i++) {
                struct lm_device *lmdev;

                if ((sc_dec & (16 << i)) == 0)
                        continue;

                lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
                if (!lmdev)
                        continue;

                lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
                lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
                lmdev->resource.flags = IORESOURCE_MEM;
                lmdev->irq = IRQ_AP_EXPINT0 + i;
                lmdev->id = i;

                lm_device_register(lmdev);
        }

        integrator_init(false);
}

In this case I think the autodetect is so nice that device tree probing
is mostly pointless. If it wasn't for the fact that we get a
cross-depenency to defined interrupts and clocks and whatever that
are coming from the device tree. Which is where DT shows its
all-or-nothing face.

So to get an elegant DT probing in this case I *guess* the right thing
to do is to dynamically add nodes to the device tree from the board
code, or have all alternatives inside the DT marked "disable" and then
mark them as "okay" from the board code by modifying the DT at
runtime.

Ideas welcome.

Yours,
Linus Walleij

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Linus,

On Jan 9, 2013, at 10:29 AM, Linus Walleij wrote:

> On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Tue, 08 Jan 2013, Arnd Bergmann wrote:
>> 
>>> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
>>>> On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
>>>> 
>>>>> On Tuesday 08 January 2013, Lee Jones wrote:
>>>>>>> If there is not, there is no way to automatically load the overlays; you can always
>>>>>>> use the kernel command line, or have the a user space application to request the loading
>>>>>>> of a specific board's overlay.
>>>>>> 
>>>>>> Unfortunately, there is no way to probe the UIBs. :(
>>>>> 
>>>>> I thought that some of the newer UIBs had it, just not the old ones.
>>>>> As Pantelis says, we could at least detect the ones that have an EEPROM
>>>>> on them, and use a command line option or device tree attribute for the others.
>>>>> 
>>>>>      Arnd
>>>> 
>>>> So I gather the new ones have an eeprom?
>>> 
>>> I don't remember the details unfortunately. Lee should be the one who can find out.
>>> IIRC there was at least a single integeger number on them.
>> 
>> Not as far as I can remember. There was (is?) a crude method of
>> identifying UIBs, but attempting to obtain certain I2C lines and
>> testing which ones were accessible. However, if there is an issue
>> with I2C, the wrong UIB was 'probed'.
> 
> Right, so the UIBs had different GPIO expanders on some I2C addresses,
> so we attempt to communicate with the expander to see if it's board type A,
> and if it doesn't respond it's deemed to be board type B.
> 
> This is the code:
> arch/arm/mach-ux500/board-mop500-uib.c
> 
> /*
> * Detect the UIB attached based on the presence or absence of i2c devices.
> */
> int __init mop500_uib_init(void)
> {
>        struct uib *uib = mop500_uib;
>        struct i2c_adapter *i2c0;
>        int ret;
> 
>        if (!cpu_is_u8500_family())
>                return -ENODEV;
> 
>        if (uib) {
>                __mop500_uib_init(uib, "from uib= boot argument");
>                return 0;
>        }
> 
>        i2c0 = i2c_get_adapter(0);
>        if (!i2c0) {
>                __mop500_uib_init(&mop500_uibs[STUIB],
>                                "fallback, could not get i2c0");
>                return -ENODEV;
>        }
> 
>        /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
>        ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
>                        I2C_SMBUS_QUICK, NULL);
>        i2c_put_adapter(i2c0);
> 
>        if (ret == 0)
>                uib = &mop500_uibs[U8500UIB];
>        else
>                uib = &mop500_uibs[STUIB];
> 
>        __mop500_uib_init(uib, "detected");
> 
>        return 0;
> }
> 
> Not elegant but better than e.g. passing a kernel command line option.
> 
> As you say it has the downside of detecting the wrong UIB if there is
> some (other) problem with the I2C block. But in that case the system is
> likely borked anyway so I wonder if it matters...
> 
> Even with the device tree approach we'd be into trouble if say, the UIB
> was unplugged (which is perfectly possible). The device tree cannot
> detect that.
> 
> The larger question is how to handle, at runtime, hardware that may
> or may not be present, in a device tree world.
> 
> Compare this other case: the Integrator has pluggable daughterboards,
> (called LMs, logic modules) and in that case we have specific registers
> to detect them, and register the daughter board on this specific bus
> that Russell came up with in arch/arm/mach-integrator/lm.c,
> the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:
> 
> static void __init ap_init(void)
> {
>        unsigned long sc_dec;
>        int i;
> 
>        platform_device_register(&cfi_flash_device);
> 
>        sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
>        for (i = 0; i < 4; i++) {
>                struct lm_device *lmdev;
> 
>                if ((sc_dec & (16 << i)) == 0)
>                        continue;
> 
>                lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
>                if (!lmdev)
>                        continue;
> 
>                lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
>                lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
>                lmdev->resource.flags = IORESOURCE_MEM;
>                lmdev->irq = IRQ_AP_EXPINT0 + i;
>                lmdev->id = i;
> 
>                lm_device_register(lmdev);
>        }
> 
>        integrator_init(false);
> }
> 
> In this case I think the autodetect is so nice that device tree probing
> is mostly pointless. If it wasn't for the fact that we get a
> cross-depenency to defined interrupts and clocks and whatever that
> are coming from the device tree. Which is where DT shows its
> all-or-nothing face.
> 
> So to get an elegant DT probing in this case I *guess* the right thing
> to do is to dynamically add nodes to the device tree from the board
> code, or have all alternatives inside the DT marked "disable" and then
> mark them as "okay" from the board code by modifying the DT at
> runtime.
> 
> Ideas welcome.
> 

Your problems are not all that different than the ones we have with the 
beaglebone. Your UIBs seem to be exactly like beaglebone capes without
a reliable probing mechanism, which the LMs seem to have a register where a
bit is turn on for each board present.

Let me try to make a list about the kind of boards the DT overlay stuff 
might be applicable, and the different probe methods.

Beaglebone:	I2C EEPROM read (standard format)
Beagleboard:	I2C EEPROM read (standard format - sometimes)
Pandaboard	N/A (not quite sure there)
ux500:		I2C probe of device at known address
integrator:	Memory read of system config register 
pengutronix:	N/A (maybe some kind of known device probe would work)

I've also heard in passing of some boards that just have an area in NAND
where a list of plugged in boards is stored. It can be simplified by
having the bootloader pass a command line argument.

Other than the different probe method (and possible future hot-plug capability)
I don't see anything different.  

What do you think?

Regards

-- Pantelis


> Yours,
> Linus Walleij

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Wednesday 09 January 2013, Pantelis Antoniou wrote:
> I've also heard in passing of some boards that just have an area in NAND
> where a list of plugged in boards is stored. It can be simplified by
> having the bootloader pass a command line argument.
> 
> Other than the different probe method (and possible future hot-plug capability)
> I don't see anything different.  
> 
> What do you think?

Just one comment on the command line option from the boot loader: If the
boot loader is already DT aware, it should not need to modify the command line,
but instead should just enable or disable the right nodes in the tree to
statically configure all the peripherals on the extension board. That of course
won't work for hotpluggable devices.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Arnd,

On Jan 9, 2013, at 12:21 PM, Arnd Bergmann wrote:

> On Wednesday 09 January 2013, Pantelis Antoniou wrote:
>> I've also heard in passing of some boards that just have an area in NAND
>> where a list of plugged in boards is stored. It can be simplified by
>> having the bootloader pass a command line argument.
>> 
>> Other than the different probe method (and possible future hot-plug capability)
>> I don't see anything different.  
>> 
>> What do you think?
> 
> Just one comment on the command line option from the boot loader: If the
> boot loader is already DT aware, it should not need to modify the command line,
> but instead should just enable or disable the right nodes in the tree to
> statically configure all the peripherals on the extension board. That of course
> won't work for hotpluggable devices.
> 

Both methods work for the beaglebone capemgr. Not every bootloader (or version of
the bootloader) can modify DT blobs, but the kernel command line is easily modified.

> 	Arnd

Regards

-- Pantelis

P.S. Any word from the core maintainers yet?

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Wednesday 09 January 2013, Linus Walleij wrote:
> On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Tue, 08 Jan 2013, Arnd Bergmann wrote:
> >> I don't remember the details unfortunately. Lee should be the one who can find out.
> >> IIRC there was at least a single integeger number on them.
> >
> > Not as far as I can remember. There was (is?) a crude method of
> > identifying UIBs, but attempting to obtain certain I2C lines and
> > testing which ones were accessible. However, if there is an issue
> > with I2C, the wrong UIB was 'probed'.
> 
> Right, so the UIBs had different GPIO expanders on some I2C addresses,
> so we attempt to communicate with the expander to see if it's board type A,
> and if it doesn't respond it's deemed to be board type B.
> 
> This is the code:
> arch/arm/mach-ux500/board-mop500-uib.c

Ok, no idea what I was confusing it with then.

> Compare this other case: the Integrator has pluggable daughterboards,
> (called LMs, logic modules) and in that case we have specific registers
> to detect them, and register the daughter board on this specific bus
> that Russell came up with in arch/arm/mach-integrator/lm.c,
> the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:
> 
> static void __init ap_init(void)
> {
>         unsigned long sc_dec;
>         int i;
> 
>         platform_device_register(&cfi_flash_device);
> 
>         sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
>         for (i = 0; i < 4; i++) {
>                 struct lm_device *lmdev;
> 
>                 if ((sc_dec & (16 << i)) == 0)
>                         continue;
> 
>                 lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
>                 if (!lmdev)
>                         continue;
> 
>                 lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
>                 lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
>                 lmdev->resource.flags = IORESOURCE_MEM;
>                 lmdev->irq = IRQ_AP_EXPINT0 + i;
>                 lmdev->id = i;
> 
>                 lm_device_register(lmdev);
>         }
> 
>         integrator_init(false);
> }
> 
> In this case I think the autodetect is so nice that device tree probing
> is mostly pointless. If it wasn't for the fact that we get a
> cross-depenency to defined interrupts and clocks and whatever that
> are coming from the device tree. Which is where DT shows its
> all-or-nothing face.

Well, the extension bus above can easily be represented as a single device
with four interrupts and four memory ranges. The child devices don't
have to show up in DT at all, since they can be detected, but the detection
mechanism should be there. This is the same as PCI devices, where we have
to describe the host controller, but not the add-on cards.

> So to get an elegant DT probing in this case I *guess* the right thing
> to do is to dynamically add nodes to the device tree from the board
> code, or have all alternatives inside the DT marked "disable" and then
> mark them as "okay" from the board code by modifying the DT at
> runtime.

That would also work, but I think the other way is simpler.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Linus Walleij]

On Wed, Jan 9, 2013 at 12:48 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday 09 January 2013, Linus Walleij wrote:

>> static void __init ap_init(void)
>> {
>>         unsigned long sc_dec;
>>         int i;
>>
>>         platform_device_register(&cfi_flash_device);
>>
>>         sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
>>         for (i = 0; i < 4; i++) {
>>                 struct lm_device *lmdev;
>>
>>                 if ((sc_dec & (16 << i)) == 0)
>>                         continue;
>>
>>                 lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
>>                 if (!lmdev)
>>                         continue;
>>
>>                 lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
>>                 lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
>>                 lmdev->resource.flags = IORESOURCE_MEM;
>>                 lmdev->irq = IRQ_AP_EXPINT0 + i;
>>                 lmdev->id = i;
>>
>>                 lm_device_register(lmdev);
>>         }
>>
>>         integrator_init(false);
>> }
>>
>> In this case I think the autodetect is so nice that device tree probing
>> is mostly pointless. If it wasn't for the fact that we get a
>> cross-depenency to defined interrupts and clocks and whatever that
>> are coming from the device tree. Which is where DT shows its
>> all-or-nothing face.
>
> Well, the extension bus above can easily be represented as a single device
> with four interrupts and four memory ranges. The child devices don't
> have to show up in DT at all, since they can be detected, but the detection
> mechanism should be there. This is the same as PCI devices, where we have
> to describe the host controller, but not the add-on cards.

Right, so the picture is more complex.

Each logic module / plug-in card spawn a set of struct amba_device
primecells.

Each of them need clocks and interrupts. These are then cascaded
from the clocks/irqs on the main board.

>> So to get an elegant DT probing in this case I *guess* the right thing
>> to do is to dynamically add nodes to the device tree from the board
>> code, or have all alternatives inside the DT marked "disable" and then
>> mark them as "okay" from the board code by modifying the DT at
>> runtime.
>
> That would also work, but I think the other way is simpler.

So when taking into account that the daugther boards are not just
spawning themselves but a number of devices in turn, I thin
it's the only way...

I will get to tackle this when I've converted the Integrator PCI to DT
and removed the Integrator boardfiles.

Yours,
Linus Walleij

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Arnd Bergmann]

On Thursday 17 January 2013, Linus Walleij wrote:
> Each logic module / plug-in card spawn a set of struct amba_device
> primecells.
> 
> Each of them need clocks and interrupts. These are then cascaded
> from the clocks/irqs on the main board.

But can they be cascaded from any clocks and irqs on the mainboard,
or just a few selected ones that are connected to the plug-in
module?

If you can describe which IRQs and clocks are routed to the
connector, then everything below it can be locally described
again. For the interrupts, you can use an
interrupt-map/interrupt-map-mask pair, and I'd assume for
the clocks, you just need to provide the right labels.

	Arnd

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Linus Walleij]

On Thu, Jan 17, 2013 at 11:35 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 17 January 2013, Linus Walleij wrote:
>> Each logic module / plug-in card spawn a set of struct amba_device
>> primecells.
>>
>> Each of them need clocks and interrupts. These are then cascaded
>> from the clocks/irqs on the main board.
>
> But can they be cascaded from any clocks and irqs on the mainboard,
> or just a few selected ones that are connected to the plug-in
> module?

Just those.

> If you can describe which IRQs and clocks are routed to the
> connector, then everything below it can be locally described
> again.

Hm yes...

> For the interrupts, you can use an
> interrupt-map/interrupt-map-mask pair,

Actually it is a single IRQ and then there is a cascaded VIC inside
the module.

> and I'd assume for
> the clocks, you just need to provide the right labels.

Yes sounds reasonable.

I'll deal with it when I get there...

Yours,
Linus Walleij

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Grant Likely]

On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> Hi Lee,
> 
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> 
> >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> >>>>> 
> >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>>>> in the beagleboard), it is a bit premature to think about making it overly
> >>>>> general, besides the part that are obviously part of the infrastructure 
> >>>>> (like the DT overlay stuff).
> >>>>> 
> >>>>> What I'm getting at, is that we need some user experience about this, before
> >>>>> going away and creating structure out of possible misconception about the uses. 
> >>>> 
> >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >>>> things for omaps that have eventually become generic frameworks have been
> >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >>>> so on.
> >>>> 
> >>>> So I suggest a minimal generic API from the start as that will make things
> >>>> a lot easier in the long run.
> >>> 
> >>> I agree. The ux500 platform already has the concept of "user interface boards",
> >>> which currently is not well integrated into devicetree. I believe Sascha
> >>> mentioned that Pengutronix had been shipping some other systems with add-on
> >>> boards and generating device tree binaries from source for each combination.
> >>> 
> >>> Ideally, both of the above should be able to use the same DT overlay logic
> >>> as BeagleBone, and I'm sure there are more of those.
> >> 
> >> Hmm, I see. 
> >> 
> >> I will need some more information about the interface of the 'user interface boards'.
> >> I.e. how is the board identified, what is typically present on those boards, etc.
> > 
> > User Interface Boards are mearly removable PCBs which are interchangeable
> > amongst various hardware platforms. They are connected via numerous
> > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > pad, leds, jumpers, switches and a bunch of sensors.
> > 
> > You can find a small example of how we interface to these by viewing
> > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > currently include it as a *.dtsi from a platform's dts file.
> 
> I see. What I'm asking about is whether there's a method where you can read
> an EEPROM, or some GPIO code combination where I can find out what kind of board
> is plugged each time.
> 
> If there is not, there is no way to automatically load the overlays; you can always
> use the kernel command line, or have the a user space application to request the loading
> of a specific board's overlay.
> 

In this case the best thing to do is announce the availability of the
expansion via a request_firmware() call and let udev handle supplying
the correct overlay file.

g.

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Grant Likely]

On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> Hi Lee,
> 
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> 
> >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> >>>>> 
> >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>>>> in the beagleboard), it is a bit premature to think about making it overly
> >>>>> general, besides the part that are obviously part of the infrastructure 
> >>>>> (like the DT overlay stuff).
> >>>>> 
> >>>>> What I'm getting at, is that we need some user experience about this, before
> >>>>> going away and creating structure out of possible misconception about the uses. 
> >>>> 
> >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >>>> things for omaps that have eventually become generic frameworks have been
> >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >>>> so on.
> >>>> 
> >>>> So I suggest a minimal generic API from the start as that will make things
> >>>> a lot easier in the long run.
> >>> 
> >>> I agree. The ux500 platform already has the concept of "user interface boards",
> >>> which currently is not well integrated into devicetree. I believe Sascha
> >>> mentioned that Pengutronix had been shipping some other systems with add-on
> >>> boards and generating device tree binaries from source for each combination.
> >>> 
> >>> Ideally, both of the above should be able to use the same DT overlay logic
> >>> as BeagleBone, and I'm sure there are more of those.
> >> 
> >> Hmm, I see. 
> >> 
> >> I will need some more information about the interface of the 'user interface boards'.
> >> I.e. how is the board identified, what is typically present on those boards, etc.
> > 
> > User Interface Boards are mearly removable PCBs which are interchangeable
> > amongst various hardware platforms. They are connected via numerous
> > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > pad, leds, jumpers, switches and a bunch of sensors.
> > 
> > You can find a small example of how we interface to these by viewing
> > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > currently include it as a *.dtsi from a platform's dts file.
> 
> I see. What I'm asking about is whether there's a method where you can read
> an EEPROM, or some GPIO code combination where I can find out what kind of board
> is plugged each time.
> 
> If there is not, there is no way to automatically load the overlays; you can always
> use the kernel command line, or have the a user space application to request the loading
> of a specific board's overlay.
> 

In this case the best thing to do is announce the availability of the
expansion via a request_firmware() call and let udev handle supplying
the correct overlay file.

g.

Re: [PATCH 2/5] capemgr: Add beaglebone's cape driver bindings

[Grant Likely]

On Mon,  7 Jan 2013 20:51:03 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> Document the beaglebone's cape driver bindings.
> 
> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Hi Pantelis,

I'll go back and review the driver in a minute, but I'll start here
since this is the data model that we'll be using for a long time.
Overall this looks pretty sane. It's pretty well contained too which I
like. Long term I do want to try and create some common patterns for
overlay connections, but it's really hard to do that when this is the
first serious attempt at implementing one.  :-) This is nicely contained
to only the beaglebone use case which makes it easy to try out without
forcing this exact data model on all users. If it works in other places,
then fantastic! we've got our generic model. If not, then we can refine
the interface for new boards without breaking beaglebone.

Comments below...

> ---
>  .../devicetree/bindings/misc/capes-beaglebone.txt  | 110 +++++++++++++++++++++
>  1 file changed, 110 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> new file mode 100644
> index 0000000..f73cab5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> @@ -0,0 +1,110 @@
> +* TI Beaglebone DT Overlay Cape Driver
> +
> +Required properties:
> +
> +- compatible: "ti,bone-capemgr"

"capemgr" sounds like a software construct. Can you rename this to
something that sounds more like describing concrete hardware? From that
perspective, "ti,bone-capebus" would be appropriate here, regardless of
where the driver actually lives in the kernel tree.

It would be better to be more specific here with the compatible
property also. Put the actual board name into the compatible string.
Following the lead of the board level compatible property, call it
'ti,am335x-bone-capebus". Newer boards can claim compatibilty with the
older where appropriate.

> +
> +- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom.
> +
> +- baseboardmaps - node containing a list of supported
> +	beaglebone revisions; each node in should have the
> +	following properties:
> +	- board-name: The board name stored in the baseboard
> +		eeprom.

If it is stored in the baseboard eeprom, then why does it need to appear
in the .dtb?

> +	- compatible-name: The name which will be used for
> +		matching compatible capes.

What is the matching logic for this compatible capes? How does it get
used?

> +
> +- slots: node containing a list of slot nodes (which in the beaglebone
> +	case correspond to I2C addresses for dynamically probed capes,
> +	or an override slot definition for hardcoded capes.
> +	- eeprom: Contains the phandle beaglebone's cape i2c eeprom.
> +
> +	It is possible to define override slots that will be activated
> +	when the baseboard matches, and/or if supplied on the kernel command
> +	line and/or when dynamically requested on runtime.
> +	In that case the slot is marked with
> +	- ti,cape-override: Marks a slot override.
> +	- compatible: any of the "runtime", "kernel", or any compatible-name
> +	  on a matching baseboardmap node.
> +	- Any of the eeprom-format-revision, board-name, version, manufacturer,
> +	  part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp,
> +	  vdd-5v, sys-5v, dc-supplied properties which fill in the simulated
> +	  cape's EEPROM fields. The part-number field is required, the rest
> +	  are optional taking into default values.

I could use some help understanding the use-case for the override slots.
It isn't clear to me how the override is intended to work. Can you
describe exactly what happens when an override slot is defined? Do
override slots replace detected slots, or are they separate?

> +
> +- capemaps: node contains list of cape mappings, which allow converting
> +	from a part-number & version tuple to the filename of the dtbo file.
> +	- part-number: part number contained in the EEPROM
> +	- version node containing a
> +		- version: specific version to map to
> +		- dtbo: name of the dtbo file 

I think you'd be better off here defining a direct 1:1 mapping from
board name + revision to dtb filename. Maintaining a list of mappings in
the dtb file means it needs to be updated when new capes are created. It
would be nicer to drop the new overlay in the root filesystem (or initrd
if that is more convenient) and have the kernel know when to pick it up.

> +
> +Example:
> +bone_capemgr {
> +	compatible = "ti,bone-capemgr";
> +	status = "okay";
> +
> +	eeprom = <&baseboard_eeprom>;
> +
> +	baseboardmaps {
> +		baseboard_beaglebone: board@0 {
> +			board-name = "A335BONE";
> +			compatible-name = "ti,beaglebone";
> +		};
> +	};
> +
> +	slots {
> +		slot@0 {
> +			eeprom = <&cape_eeprom0>;
> +		};
> +
> +		slot@1 {
> +			eeprom = <&cape_eeprom1>;
> +		};
> +
> +		slot@2 {
> +			eeprom = <&cape_eeprom2>;
> +		};
> +
> +		slot@3 {
> +			eeprom = <&cape_eeprom3>;
> +		};
> +	};
> +
> +	/* mapping between board names and dtb objects */
> +	capemaps {
> +		/* Weather cape */
> +		cape@0 {
> +			part-number = "BB-BONE-WTHR-01";
> +			version@00A0 {
> +				version = "00A0";
> +				dtbo = "cape-bone-weather-00A0.dtbo";
> +			};
> +		};
> +	};
> +};
> +
> +Example of the override syntax when used on a bone compatible foo board.
> +
> +{
> +	...
> +
> +	baseboardmaps {
> +		...
> +		baseboard_beaglebone: board@0 {
> +			board-name = "A335FOO";
> +			compatible-name = "ti,foo";
> +		};
> +
> +		slot@6 {
> +			ti,cape-override;
> +			compatible = "ti,foo";
> +			board-name = "FOO-hardcoded";
> +			version = "00A0";
> +			manufacturer = "Texas Instruments";
> +			part-number = "BB-BONE-FOO-01";
> +		};
> +	};
> +
> +};
> +	
> -- 
> 1.7.12
> 

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

Re: [PATCH 2/5] capemgr: Add beaglebone's cape driver bindings

[Grant Likely]

On Mon,  7 Jan 2013 20:51:03 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> Document the beaglebone's cape driver bindings.
> 
> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Hi Pantelis,

I'll go back and review the driver in a minute, but I'll start here
since this is the data model that we'll be using for a long time.
Overall this looks pretty sane. It's pretty well contained too which I
like. Long term I do want to try and create some common patterns for
overlay connections, but it's really hard to do that when this is the
first serious attempt at implementing one.  :-) This is nicely contained
to only the beaglebone use case which makes it easy to try out without
forcing this exact data model on all users. If it works in other places,
then fantastic! we've got our generic model. If not, then we can refine
the interface for new boards without breaking beaglebone.

Comments below...

> ---
>  .../devicetree/bindings/misc/capes-beaglebone.txt  | 110 +++++++++++++++++++++
>  1 file changed, 110 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> new file mode 100644
> index 0000000..f73cab5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> @@ -0,0 +1,110 @@
> +* TI Beaglebone DT Overlay Cape Driver
> +
> +Required properties:
> +
> +- compatible: "ti,bone-capemgr"

"capemgr" sounds like a software construct. Can you rename this to
something that sounds more like describing concrete hardware? From that
perspective, "ti,bone-capebus" would be appropriate here, regardless of
where the driver actually lives in the kernel tree.

It would be better to be more specific here with the compatible
property also. Put the actual board name into the compatible string.
Following the lead of the board level compatible property, call it
'ti,am335x-bone-capebus". Newer boards can claim compatibilty with the
older where appropriate.

> +
> +- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom.
> +
> +- baseboardmaps - node containing a list of supported
> +	beaglebone revisions; each node in should have the
> +	following properties:
> +	- board-name: The board name stored in the baseboard
> +		eeprom.

If it is stored in the baseboard eeprom, then why does it need to appear
in the .dtb?

> +	- compatible-name: The name which will be used for
> +		matching compatible capes.

What is the matching logic for this compatible capes? How does it get
used?

> +
> +- slots: node containing a list of slot nodes (which in the beaglebone
> +	case correspond to I2C addresses for dynamically probed capes,
> +	or an override slot definition for hardcoded capes.
> +	- eeprom: Contains the phandle beaglebone's cape i2c eeprom.
> +
> +	It is possible to define override slots that will be activated
> +	when the baseboard matches, and/or if supplied on the kernel command
> +	line and/or when dynamically requested on runtime.
> +	In that case the slot is marked with
> +	- ti,cape-override: Marks a slot override.
> +	- compatible: any of the "runtime", "kernel", or any compatible-name
> +	  on a matching baseboardmap node.
> +	- Any of the eeprom-format-revision, board-name, version, manufacturer,
> +	  part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp,
> +	  vdd-5v, sys-5v, dc-supplied properties which fill in the simulated
> +	  cape's EEPROM fields. The part-number field is required, the rest
> +	  are optional taking into default values.

I could use some help understanding the use-case for the override slots.
It isn't clear to me how the override is intended to work. Can you
describe exactly what happens when an override slot is defined? Do
override slots replace detected slots, or are they separate?

> +
> +- capemaps: node contains list of cape mappings, which allow converting
> +	from a part-number & version tuple to the filename of the dtbo file.
> +	- part-number: part number contained in the EEPROM
> +	- version node containing a
> +		- version: specific version to map to
> +		- dtbo: name of the dtbo file 

I think you'd be better off here defining a direct 1:1 mapping from
board name + revision to dtb filename. Maintaining a list of mappings in
the dtb file means it needs to be updated when new capes are created. It
would be nicer to drop the new overlay in the root filesystem (or initrd
if that is more convenient) and have the kernel know when to pick it up.

> +
> +Example:
> +bone_capemgr {
> +	compatible = "ti,bone-capemgr";
> +	status = "okay";
> +
> +	eeprom = <&baseboard_eeprom>;
> +
> +	baseboardmaps {
> +		baseboard_beaglebone: board@0 {
> +			board-name = "A335BONE";
> +			compatible-name = "ti,beaglebone";
> +		};
> +	};
> +
> +	slots {
> +		slot@0 {
> +			eeprom = <&cape_eeprom0>;
> +		};
> +
> +		slot@1 {
> +			eeprom = <&cape_eeprom1>;
> +		};
> +
> +		slot@2 {
> +			eeprom = <&cape_eeprom2>;
> +		};
> +
> +		slot@3 {
> +			eeprom = <&cape_eeprom3>;
> +		};
> +	};
> +
> +	/* mapping between board names and dtb objects */
> +	capemaps {
> +		/* Weather cape */
> +		cape@0 {
> +			part-number = "BB-BONE-WTHR-01";
> +			version@00A0 {
> +				version = "00A0";
> +				dtbo = "cape-bone-weather-00A0.dtbo";
> +			};
> +		};
> +	};
> +};
> +
> +Example of the override syntax when used on a bone compatible foo board.
> +
> +{
> +	...
> +
> +	baseboardmaps {
> +		...
> +		baseboard_beaglebone: board@0 {
> +			board-name = "A335FOO";
> +			compatible-name = "ti,foo";
> +		};
> +
> +		slot@6 {
> +			ti,cape-override;
> +			compatible = "ti,foo";
> +			board-name = "FOO-hardcoded";
> +			version = "00A0";
> +			manufacturer = "Texas Instruments";
> +			part-number = "BB-BONE-FOO-01";
> +		};
> +	};
> +
> +};
> +	
> -- 
> 1.7.12
> 

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

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Greg Kroah-Hartman]

On Tue, Mar 26, 2013 at 04:16:10PM +0000, Grant Likely wrote:
> On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> > Hi Lee,
> > 
> > On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> > 
> > >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> > >>>>> 
> > >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > >>>>> in the beagleboard), it is a bit premature to think about making it overly
> > >>>>> general, besides the part that are obviously part of the infrastructure 
> > >>>>> (like the DT overlay stuff).
> > >>>>> 
> > >>>>> What I'm getting at, is that we need some user experience about this, before
> > >>>>> going away and creating structure out of possible misconception about the uses. 
> > >>>> 
> > >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > >>>> things for omaps that have eventually become generic frameworks have been
> > >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> > >>>> so on.
> > >>>> 
> > >>>> So I suggest a minimal generic API from the start as that will make things
> > >>>> a lot easier in the long run.
> > >>> 
> > >>> I agree. The ux500 platform already has the concept of "user interface boards",
> > >>> which currently is not well integrated into devicetree. I believe Sascha
> > >>> mentioned that Pengutronix had been shipping some other systems with add-on
> > >>> boards and generating device tree binaries from source for each combination.
> > >>> 
> > >>> Ideally, both of the above should be able to use the same DT overlay logic
> > >>> as BeagleBone, and I'm sure there are more of those.
> > >> 
> > >> Hmm, I see. 
> > >> 
> > >> I will need some more information about the interface of the 'user interface boards'.
> > >> I.e. how is the board identified, what is typically present on those boards, etc.
> > > 
> > > User Interface Boards are mearly removable PCBs which are interchangeable
> > > amongst various hardware platforms. They are connected via numerous
> > > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > > pad, leds, jumpers, switches and a bunch of sensors.
> > > 
> > > You can find a small example of how we interface to these by viewing
> > > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > > currently include it as a *.dtsi from a platform's dts file.
> > 
> > I see. What I'm asking about is whether there's a method where you can read
> > an EEPROM, or some GPIO code combination where I can find out what kind of board
> > is plugged each time.
> > 
> > If there is not, there is no way to automatically load the overlays; you can always
> > use the kernel command line, or have the a user space application to request the loading
> > of a specific board's overlay.
> > 
> 
> In this case the best thing to do is announce the availability of the
> expansion via a request_firmware() call and let udev handle supplying
> the correct overlay file.

The code to load firmware files was recently removed from udev, now that
the kernel handles this automatically itself :)

But yes, the same call still applies, request_firmware() should work
fine here.

thanks,

greg k-h

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Greg Kroah-Hartman]

On Tue, Mar 26, 2013 at 04:16:10PM +0000, Grant Likely wrote:
> On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote:
> > Hi Lee,
> > 
> > On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> > 
> > >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> > >>>>> 
> > >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > >>>>> in the beagleboard), it is a bit premature to think about making it overly
> > >>>>> general, besides the part that are obviously part of the infrastructure 
> > >>>>> (like the DT overlay stuff).
> > >>>>> 
> > >>>>> What I'm getting at, is that we need some user experience about this, before
> > >>>>> going away and creating structure out of possible misconception about the uses. 
> > >>>> 
> > >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > >>>> things for omaps that have eventually become generic frameworks have been
> > >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> > >>>> so on.
> > >>>> 
> > >>>> So I suggest a minimal generic API from the start as that will make things
> > >>>> a lot easier in the long run.
> > >>> 
> > >>> I agree. The ux500 platform already has the concept of "user interface boards",
> > >>> which currently is not well integrated into devicetree. I believe Sascha
> > >>> mentioned that Pengutronix had been shipping some other systems with add-on
> > >>> boards and generating device tree binaries from source for each combination.
> > >>> 
> > >>> Ideally, both of the above should be able to use the same DT overlay logic
> > >>> as BeagleBone, and I'm sure there are more of those.
> > >> 
> > >> Hmm, I see. 
> > >> 
> > >> I will need some more information about the interface of the 'user interface boards'.
> > >> I.e. how is the board identified, what is typically present on those boards, etc.
> > > 
> > > User Interface Boards are mearly removable PCBs which are interchangeable
> > > amongst various hardware platforms. They are connected via numerous
> > > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > > pad, leds, jumpers, switches and a bunch of sensors.
> > > 
> > > You can find a small example of how we interface to these by viewing
> > > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > > currently include it as a *.dtsi from a platform's dts file.
> > 
> > I see. What I'm asking about is whether there's a method where you can read
> > an EEPROM, or some GPIO code combination where I can find out what kind of board
> > is plugged each time.
> > 
> > If there is not, there is no way to automatically load the overlays; you can always
> > use the kernel command line, or have the a user space application to request the loading
> > of a specific board's overlay.
> > 
> 
> In this case the best thing to do is announce the availability of the
> expansion via a request_firmware() call and let udev handle supplying
> the correct overlay file.

The code to load firmware files was recently removed from udev, now that
the kernel handles this automatically itself :)

But yes, the same call still applies, request_firmware() should work
fine here.

thanks,

greg k-h

Re: [PATCH 2/5] capemgr: Add beaglebone's cape driver bindings

[Pantelis Antoniou]

Hi Grant

On Mar 26, 2013, at 7:36 PM, Grant Likely wrote:

> On Mon,  7 Jan 2013 20:51:03 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
>> Document the beaglebone's cape driver bindings.
>> 
>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> 
> Hi Pantelis,
> 
> I'll go back and review the driver in a minute, but I'll start here
> since this is the data model that we'll be using for a long time.
> Overall this looks pretty sane. It's pretty well contained too which I
> like. Long term I do want to try and create some common patterns for
> overlay connections, but it's really hard to do that when this is the
> first serious attempt at implementing one.  :-) This is nicely contained
> to only the beaglebone use case which makes it easy to try out without
> forcing this exact data model on all users. If it works in other places,
> then fantastic! we've got our generic model. If not, then we can refine
> the interface for new boards without breaking beaglebone.
> 

Glad you liked it. I really tried hard to keep things nicely separated since
we're definitely on to uncharted waters.

We will definitely adopt this for the beagleboard too (maybe some other boards too)
so some rearrangement will take place for the v2 of the patches.

We're under the gun for the new beaglebone that's coming out shortly, so the new patches
will be out in a couple of weeks.

> Comments below...
> 
>> ---
>> .../devicetree/bindings/misc/capes-beaglebone.txt  | 110 +++++++++++++++++++++
>> 1 file changed, 110 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/capes-beaglebone.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
>> new file mode 100644
>> index 0000000..f73cab5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
>> @@ -0,0 +1,110 @@
>> +* TI Beaglebone DT Overlay Cape Driver
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,bone-capemgr"
> 
> "capemgr" sounds like a software construct. Can you rename this to
> something that sounds more like describing concrete hardware? From that
> perspective, "ti,bone-capebus" would be appropriate here, regardless of
> where the driver actually lives in the kernel tree.
> 

Hum, well I guess so, that would work. Perhaps same as with 
ti,beagle-capebus.

But I thought using the work bus was out :)

> It would be better to be more specific here with the compatible
> property also. Put the actual board name into the compatible string.
> Following the lead of the board level compatible property, call it
> 'ti,am335x-bone-capebus". Newer boards can claim compatibilty with the
> older where appropriate.
> 

Let's not put am335x there, there's nothing SoC specific. The bone is
a am335x, but the beagleboard is not, etc.

There's also some crazy talk about compatibility between different board
families; we can keep it aside for now, but let's not assign anything
SoC specific. 

>> +
>> +- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom.
>> +
>> +- baseboardmaps - node containing a list of supported
>> +	beaglebone revisions; each node in should have the
>> +	following properties:
>> +	- board-name: The board name stored in the baseboard
>> +		eeprom.
> 
> If it is stored in the baseboard eeprom, then why does it need to appear
> in the .dtb?

It needs to because there are slightly different revisions of the bone.
Defining the revisions it allows us to auto-load the dtbos containing the
differences for the baseboard revision.

In this way we keep the same kernel/software images working on all the
bone revisions, significantly reducing the support burden.

> 
>> +	- compatible-name: The name which will be used for
>> +		matching compatible capes.
> 
> What is the matching logic for this compatible capes? How does it get
> used?
> 

See below.

>> +
>> +- slots: node containing a list of slot nodes (which in the beaglebone
>> +	case correspond to I2C addresses for dynamically probed capes,
>> +	or an override slot definition for hardcoded capes.
>> +	- eeprom: Contains the phandle beaglebone's cape i2c eeprom.
>> +
>> +	It is possible to define override slots that will be activated
>> +	when the baseboard matches, and/or if supplied on the kernel command
>> +	line and/or when dynamically requested on runtime.
>> +	In that case the slot is marked with
>> +	- ti,cape-override: Marks a slot override.
>> +	- compatible: any of the "runtime", "kernel", or any compatible-name
>> +	  on a matching baseboardmap node.
>> +	- Any of the eeprom-format-revision, board-name, version, manufacturer,
>> +	  part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp,
>> +	  vdd-5v, sys-5v, dc-supplied properties which fill in the simulated
>> +	  cape's EEPROM fields. The part-number field is required, the rest
>> +	  are optional taking into default values.
> 
> I could use some help understanding the use-case for the override slots.
> It isn't clear to me how the override is intended to work. Can you
> describe exactly what happens when an override slot is defined? Do
> override slots replace detected slots, or are they separate?
> 

Override slots are slots that are not probed via the eeprom,
but instead are loaded as a result of

1) User configuration
2) Base board match

In essence, overrides are when the normal probing method isn't applicable.

To understand why there's needed let's take two examples, one is the
development version of the Geiger cape.

That version did not have an EEPROM (mainly because it's a wired up board
with no SMD components).

It's override definition is:

>  /* geiger cape version A0 without an EEPROM */
>  slot@5 {
>  	ti,cape-override;
>  	compatible = "kernel-command-line", "runtime";
>  	board-name = "Bone-Geiger";
>  	version = "00A0";
>  	manufacturer = "Geiger Inc.";
>  	part-number = "BB-BONE-GEIGER";
>  };


The compatible property declares this to be an override which is enabled
either from the command line or at runtime.

To load this cape, you can either use the sysfs/slots property or add a kernel
parameter of the form capemgr.extra_override=BB-BONE-GEIGER:00A0

There's also a new 'force' compatible option in the updated patchset which always
applies the override (but that's mostly for development purposes).

Let's take a look at new beaglebone that's coming out shortly.

One of the differences it has from the original is that of onboard HDMI.

It's override definition is:

> 
>  /* Beaglebone black has it soldered on */
>  slot@6 {
>   	ti,cape-override;
>   	compatible = "ti,beaglebone-black";
>  	board-name = "Bone-Black-HDMI";
>  	version = "00A0";
>  	manufacturer = "Texas Instruments";
>  	part-number = "BB-BONELT-HDMI";
>  };
> 



It's compatible property is "ti,beaglebone-black"

This means that this is an override that should be applied for the new beaglebone.

Taking a look at the baseboardmaps node we see that there's board node that maps
the internal board-name (A335BNLT) to the well formed DT name ti,beaglebone-black.

And that's the reason of the baeboardsmaps nodes, mapping from some internal
representation of board revision to a single well formed DT compatible property.

>> +
>> +- capemaps: node contains list of cape mappings, which allow converting
>> +	from a part-number & version tuple to the filename of the dtbo file.
>> +	- part-number: part number contained in the EEPROM
>> +	- version node containing a
>> +		- version: specific version to map to
>> +		- dtbo: name of the dtbo file 
> 
> I think you'd be better off here defining a direct 1:1 mapping from
> board name + revision to dtb filename. Maintaining a list of mappings in
> the dtb file means it needs to be updated when new capes are created. It
> would be nicer to drop the new overlay in the root filesystem (or initrd
> if that is more convenient) and have the kernel know when to pick it up.
> 

I'm ambivalent about this. There is a direct 1:1 mapping, using directly the
part number works just as well, but knowing the hardware people, I'm not sure
I can trust them not to use part number that are not filename friendly.
I.e. they might sneak a '/' in there and we'll be SOL.

You can think of the capemaps node as an optional filename sanitizer, it's
not required, but guarantees that we're not dependent on sane part-number fields.

>> +
>> +Example:
>> +bone_capemgr {
>> +	compatible = "ti,bone-capemgr";
>> +	status = "okay";
>> +
>> +	eeprom = <&baseboard_eeprom>;
>> +
>> +	baseboardmaps {
>> +		baseboard_beaglebone: board@0 {
>> +			board-name = "A335BONE";
>> +			compatible-name = "ti,beaglebone";
>> +		};
>> +	};
>> +
>> +	slots {
>> +		slot@0 {
>> +			eeprom = <&cape_eeprom0>;
>> +		};
>> +
>> +		slot@1 {
>> +			eeprom = <&cape_eeprom1>;
>> +		};
>> +
>> +		slot@2 {
>> +			eeprom = <&cape_eeprom2>;
>> +		};
>> +
>> +		slot@3 {
>> +			eeprom = <&cape_eeprom3>;
>> +		};
>> +	};
>> +
>> +	/* mapping between board names and dtb objects */
>> +	capemaps {
>> +		/* Weather cape */
>> +		cape@0 {
>> +			part-number = "BB-BONE-WTHR-01";
>> +			version@00A0 {
>> +				version = "00A0";
>> +				dtbo = "cape-bone-weather-00A0.dtbo";
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +Example of the override syntax when used on a bone compatible foo board.
>> +
>> +{
>> +	...
>> +
>> +	baseboardmaps {
>> +		...
>> +		baseboard_beaglebone: board@0 {
>> +			board-name = "A335FOO";
>> +			compatible-name = "ti,foo";
>> +		};
>> +
>> +		slot@6 {
>> +			ti,cape-override;
>> +			compatible = "ti,foo";
>> +			board-name = "FOO-hardcoded";
>> +			version = "00A0";
>> +			manufacturer = "Texas Instruments";
>> +			part-number = "BB-BONE-FOO-01";
>> +		};
>> +	};
>> +
>> +};
>> +	
>> -- 
>> 1.7.12
>> 
> 
> -- 
> Grant Likely, B.Sc, P.Eng.
> Secret Lab Technologies, Ltd.

Regards

-- Pantelis

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:35 Mon 07 Jan     , Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
I'm looking for this also as on at91 sama9x5ek and sam9cn12ek and the
sama5d3xek, we have 1 wire eeproms to detect the boards (motherboards and
daugther boards)
where we have 1 1-wire per board and cpu boards so we can detect everything
and have it's revision and more information

we already have barebox that detect the 1-wire but we need the same handling
in the kernel

Best Regards,
J.
> 
> 	Arnd
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:35 Mon 07 Jan     , Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
I'm looking for this also as on at91 sama9x5ek and sam9cn12ek and the
sama5d3xek, we have 1 wire eeproms to detect the boards (motherboards and
daugther boards)
where we have 1 1-wire per board and cpu boards so we can detect everything
and have it's revision and more information

we already have barebox that detect the 1-wire but we need the same handling
in the kernel

Best Regards,
J.
> 
> 	Arnd
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss