OMAP3+: Add DT support for early devices and i2c / twl6030

+++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt

Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt new file +5 -0

@@ -0,0 +1,5 @@
+* HW spinlock on OMAP4 platform:
+
+Required properties:
+- compatible : Must be "ti,omap4-spinlock";
+- ti,hwmods : "spinlock"

arch/arm/boot/dts/omap4.dtsi +0 -0

index 4c61c82..7a7f31e 100644

Adapt the GPIO driver to retrieve information from a DT file. Note that since the driver is currently under cleanup, some hacks will have to be removed after.

Add documentation for GPIO properties specific to OMAP.

Remove an un-needed whitespace.

Signed-off-by Benoit Cousson<[email protected]>

Cc Grant Likely<[email protected]>

Cc Charulatha V<[email protected]>

Cc Tarun Kanti DebBarma<[email protected]>

---
  .../devicetree/bindings/gpio/gpio-omap.txt         |   33 ++++++
  drivers/gpio/gpio-omap.c                           |  108 ++++++++++++++++++--
  2 files changed, 132 insertions(+), 9 deletions(-)

create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +0 -0

new file mode 100644
index 0000000..bdd63de

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +15 -0

+
+
+Example:
+
+gpio4: gpio4 {
+    compatible = "ti,omap4-gpio", "ti,omap-gpio";
+    ti,hwmods = "gpio4";
+    id =<4>;
+    bank-width =<32>;
+    debounce;
+    no_idle_on_suspend;
+    #gpio-cells =<2>;
+    gpio-controller;
+};
+

drivers/gpio/gpio-omap.c +2 -0

index 0599854..f878fa4 100644
@@ -21,6 +21,8 @@
  #include<linux/io.h>
  #include<linux/slab.h>
  #include<linux/pm_runtime.h>
+#include<linux/of.h>
+#include<linux/of_device.h>
 
  #include<mach/hardware.h>
  #include<asm/irq.h>

drivers/gpio/gpio-omap.c +2 -0

  			"Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
  		return -EINVAL;
  	}

@@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
  	irq_set_handler_data(bank->irq, bank);
  }
 
+static const struct of_device_id omap_gpio_match[];
+
  static int __devinit omap_gpio_probe(struct platform_device *pdev)
  {
  	static int gpio_init_done;

@@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
  	struct resource *res;
  	int id;

drivers/gpio/gpio-omap.c +15 -5

+			return -EINVAL;
+		/*
+		 * In an ideal world, the id should not be needed, but since
+		 * the OMAP TRM consider the multiple GPIO controllers as
+		 * multiple banks, the GPIO number is based on the whole set
+		 * of banks. Hence the need to provide an id in order to
+		 * respect the order and the correct GPIO number.
+		 */
+		id -= 1;
+	} else {
+		if (!pdev->dev.platform_data)
+			return -EINVAL;
 
-	if (!pdev->dev.platform_data)
-		return -EINVAL;
-
-	pdata = pdev->dev.platform_data;
+		pdata = pdev->dev.platform_data;
+		id = pdev->id;
+	}
 
  	if (!gpio_init_done) {
  		int ret;

@@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
  			return ret;
  	}
 
-	id = pdev->id;
  	bank =&gpio_bank[id];
 
  	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
  	}

drivers/gpio/gpio-omap.c +67 -0

+			bank->dbck_flag = true;
+		bank->virtual_irq_start = IH_GPIO_BASE + 32 * id;
+	} else {
+		bank->width = pdata->bank_width;
+		bank->dbck_flag = pdata->dbck_flag;
+		bank->virtual_irq_start = pdata->virtual_irq_start;
+	}
 
  	bank->regs = pdata->regs;
 

@@ -1559,10 +1589,70 @@ void omap_gpio_restore_context(void)
  }
  #endif
 
+#if defined(CONFIG_OF)
+static struct omap_gpio_reg_offs omap2_gpio_regs = {
+	.revision =		OMAP24XX_GPIO_REVISION,
+	.direction =		OMAP24XX_GPIO_OE,
+	.datain =		OMAP24XX_GPIO_DATAIN,
+	.dataout =		OMAP24XX_GPIO_DATAOUT,
+	.set_dataout =		OMAP24XX_GPIO_SETDATAOUT,
+	.clr_dataout =		OMAP24XX_GPIO_CLEARDATAOUT,
+	.irqstatus =		OMAP24XX_GPIO_IRQSTATUS1,
+	.irqstatus2 =		OMAP24XX_GPIO_IRQSTATUS2,
+	.irqenable =		OMAP24XX_GPIO_IRQENABLE1,
+	.set_irqenable =	OMAP24XX_GPIO_SETIRQENABLE1,
+	.clr_irqenable =	OMAP24XX_GPIO_CLEARIRQENABLE1,
+	.debounce =		OMAP24XX_GPIO_DEBOUNCE_VAL,
+	.debounce_en =		OMAP24XX_GPIO_DEBOUNCE_EN,
+};
+
+static struct omap_gpio_platform_data omap2_pdata = {
+	.bank_type = METHOD_GPIO_24XX,
+	.regs =&omap2_gpio_regs,
+};
+
+static struct omap_gpio_reg_offs omap4_gpio_regs = {
+	.revision =		OMAP4_GPIO_REVISION,
+	.direction =		OMAP4_GPIO_OE,
+	.datain =		OMAP4_GPIO_DATAIN,
+	.dataout =		OMAP4_GPIO_DATAOUT,
+	.set_dataout =		OMAP4_GPIO_SETDATAOUT,
+	.clr_dataout =		OMAP4_GPIO_CLEARDATAOUT,
+	.irqstatus =		OMAP4_GPIO_IRQSTATUS1,
+	.irqstatus2 =		OMAP4_GPIO_IRQSTATUS2,
+	.irqenable =		OMAP4_GPIO_IRQENABLE1,
+	.set_irqenable =	OMAP4_GPIO_SETIRQENABLE1,
+	.clr_irqenable =	OMAP4_GPIO_CLEARIRQENABLE1,
+	.debounce =		OMAP4_GPIO_DEBOUNCINGTIME,
+	.debounce_en =		OMAP4_GPIO_DEBOUNCENABLE,
+};
+
+static struct omap_gpio_platform_data omap4_pdata = {
+	.bank_type = METHOD_GPIO_44XX,
+	.regs =&omap4_gpio_regs,
+};
+
+static const struct of_device_id omap_gpio_match[] = {
+	{
+		.compatible = "ti,omap4-gpio",
+		.data =&omap4_pdata,
+	},
+	{
+		.compatible = "ti,omap2-gpio",
+		.data =&omap2_pdata,
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap_gpio_match);
+#else
+#define omap_gpio_match NULL
+#endif
+
  static struct platform_driver omap_gpio_driver = {
  	.probe		= omap_gpio_probe,
  	.driver		= {
  		.name	= "omap_gpio",
+		.of_match_table = omap_gpio_match,
  	},
  };
 

Quoted 24 lines · Benoit Cousson

Adapt the GPIO driver to retrieve information from a DT file. Note that since the driver is currently under cleanup, some hacks will have to be removed after.

Add documentation for GPIO properties specific to OMAP.

Remove an un-needed whitespace.

Signed-off-by Benoit Cousson<[email protected]>

Cc Grant Likely<[email protected]>

Cc Charulatha V<[email protected]>

Cc Tarun Kanti DebBarma<[email protected]>

---
   .../devicetree/bindings/gpio/gpio-omap.txt         |   33 ++++++
   drivers/gpio/gpio-omap.c                           |  108 ++++++++++++++++++--
   2 files changed, 132 insertions(+), 9 deletions(-)

create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +0 -0

new file mode 100644
index 0000000..bdd63de

Documentation/devicetree/bindings/gpio/gpio-omap.txt line 5

Quoted 5 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +5 -0

@@ -0,0 +1,33 @@
+OMAP GPIO controller
+
+Required properties:
+- compatible:
+  - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers

Would it be more readable to have
"ti,omap2-gpio" for OMAP2 controllers and
"ti,omap3-gpio" for OMAP3 controllers?

Quoted 10 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +10 -0

+  - "ti,omap4-gpio" for OMAP4 controller
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)
+- bank-width: number of pin supported by the controller (16 or 32)

Documentation/devicetree/bindings/gpio/gpio-omap.txt line 18

Quoted 3 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +3 -0

+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a temporary
+  hack until the bank_count is removed from the driver.

Is there a general rule to be followed as to when to use "ti,<prop-name>" and when to use just"<prop-name>". Since all these are OMAP specific properties, shouldn't all of them be "ti,<prop-name>"?

Quoted 29 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +13 -0

+Example:
+
+gpio4: gpio4 {
+    compatible = "ti,omap4-gpio", "ti,omap-gpio";
+    ti,hwmods = "gpio4";
+    id =<4>;
+    bank-width =<32>;
+    debounce;
+    no_idle_on_suspend;
+    #gpio-cells =<2>;
+    gpio-controller;
+};
+

drivers/gpio/gpio-omap.c +2 -0

index 0599854..f878fa4 100644
@@ -21,6 +21,8 @@
   #include<linux/io.h>
   #include<linux/slab.h>
   #include<linux/pm_runtime.h>
+#include<linux/of.h>
+#include<linux/of_device.h>
 
   #include<mach/hardware.h>
   #include<asm/irq.h>

@@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
   	unsigned long flags;
 

drivers/gpio/gpio-omap.c static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable) · line 526

Quoted 3 lines

drivers/gpio/gpio-omap.c +1 -1

   	if (bank->non_wakeup_gpios&   gpio_bit) {
-		dev_err(bank->dev,
+		dev_err(bank->dev,

Stray change?

Quoted 20 lines

drivers/gpio/gpio-omap.c +5 -0

   			"Unable to modify wakeup on non-wakeup GPIO%d\n", gpio);
   		return -EINVAL;
   	}

@@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
   	irq_set_handler_data(bank->irq, bank);
   }
 
+static const struct of_device_id omap_gpio_match[];
+
   static int __devinit omap_gpio_probe(struct platform_device *pdev)
   {
   	static int gpio_init_done;

@@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
   	struct resource *res;
   	int id;
   	struct gpio_bank *bank;
+	struct device_node *node = pdev->dev.of_node;
+	const struct of_device_id *match;
+

drivers/gpio/gpio-omap.c static int __devinit omap_gpio_probe(struct platform_device *pdev)

Quoted 6 lines

drivers/gpio/gpio-omap.c +6 -0

+	match = of_match_device(omap_gpio_match,&pdev->dev);
+	if (match) {
+		pdata = match->data;
+		/* XXX: big hack until the bank_count is removed */
+		of_property_read_u32(node, "bank-count",&gpio_bank_count);
+		if (of_property_read_u32(node, "id",&id))

id should be u32.

Quoted 34 lines

drivers/gpio/gpio-omap.c +15 -5

+			return -EINVAL;
+		/*
+		 * In an ideal world, the id should not be needed, but since
+		 * the OMAP TRM consider the multiple GPIO controllers as
+		 * multiple banks, the GPIO number is based on the whole set
+		 * of banks. Hence the need to provide an id in order to
+		 * respect the order and the correct GPIO number.
+		 */
+		id -= 1;
+	} else {
+		if (!pdev->dev.platform_data)
+			return -EINVAL;
 
-	if (!pdev->dev.platform_data)
-		return -EINVAL;
-
-	pdata = pdev->dev.platform_data;
+		pdata = pdev->dev.platform_data;
+		id = pdev->id;
+	}
 
   	if (!gpio_init_done) {
   		int ret;

@@ -1171,7 +1195,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
   			return ret;
   	}
 
-	id = pdev->id;
   	bank =&gpio_bank[id];
 
   	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

@@ -1181,12 +1204,19 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
   	}

drivers/gpio/gpio-omap.c static int __devinit omap_gpio_probe(struct platform_device *pdev) · line 1211

Quoted 10 lines

drivers/gpio/gpio-omap.c +2 -3

 
   	bank->irq = res->start;
-	bank->virtual_irq_start = pdata->virtual_irq_start;
   	bank->method = pdata->bank_type;
   	bank->dev =&pdev->dev;
-	bank->dbck_flag = pdata->dbck_flag;
   	bank->stride = pdata->bank_stride;
-	bank->width = pdata->bank_width;
+	if (match) {
+		of_property_read_u32(node, "bank-width",&bank->width);

Bank width should be u32.

drivers/gpio/gpio-omap.c static int __devinit omap_gpio_probe(struct platform_device *pdev) · line 1212

Quoted 1 line

drivers/gpio/gpio-omap.c +1 -0

+		if (of_get_property(node, "debounce", NULL))

of_find_property() should suffice.

Quoted 8 lines · Rajendra

Documentation/devicetree/bindings/gpio/gpio-omap.txt line 5

Quoted 3 lines · Benoit Cousson

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +3 -0

+Required properties:
+- compatible:
+  - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers

Would it be more readable to have
"ti,omap2-gpio" for OMAP2 controllers and
"ti,omap3-gpio" for OMAP3 controllers?

Quoted 9 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt line 14

Quoted 9 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +9 -0

+  - "ti,omap4-gpio" for OMAP4 controller
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)

Quoted 10 lines

Quoted 5 lines

+- bank-width: number of pin supported by the controller (16 or 32)
+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a

temporary
+ hack until the bank_count is removed from the driver.

Is there a general rule to be followed as to when to use "ti,<prop-name>" and when to use just"<prop-name>". Since all these are OMAP specific properties, shouldn't all of them be "ti,<prop-name>"?

To be honest, I was wondering as well about this rule.
I think that a property that is not purely OMAP specific and that represents some standard HW information does not have to be prefixed by "ti,XXX".
So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me quite generic.

Quoted 6 lines · Benoit

Quoted 5 lines · Rajendra

Quoted 3 lines · Benoit Cousson

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +3 -0

+Required properties:
+- compatible:
+  - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers

Quoted 3 lines

Quoted 3 lines

Would it be more readable to have
"ti,omap2-gpio" for OMAP2 controllers and
"ti,omap3-gpio" for OMAP3 controllers?

Or have OMAP3 say this if it's fully backwards compatible:

	compatible = "ti,omap3-gpio", "ti,omap2-gpio";

Quoted 9 lines

Quoted 9 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt line 14

Quoted 9 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +9 -0

+  - "ti,omap4-gpio" for OMAP4 controller
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)

What does "the id" mean, in relation to the actual hardware?

Some existing bindings have such a thing (often called "cell-index"), but it should be well-defined what it refers to. Often aliases would be a better approach, if it just refers to what the manual calls the device.

Quoted 11 lines

Quoted 10 lines

Quoted 5 lines

+- bank-width: number of pin supported by the controller (16 or 32)
+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a

temporary
+ hack until the bank_count is removed from the driver.

Is there a general rule to be followed as to when to use "ti,<prop-name>" and when to use just"<prop-name>". Since all these are OMAP specific properties, shouldn't all of them be "ti,<prop-name>"?

Quoted 6 lines

To be honest, I was wondering as well about this rule.
I think that a property that is not purely OMAP specific and that represents some standard HW information does not have to be prefixed by "ti,XXX".
So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me quite generic.

It's about where the property is documented. Suppose you use an un-prefixed bank-width but define it in the TI-specific binding to mean width in bits. Later, someone wants something similar for another driver, doesn't look at the TI binding, but says, "This is generic, I'll define something in the main gpio binding," but defines it as width in bytes (ignore the (de)merits of defining it that way in this case). If you had a namespace prefix, it would be clear which binding a node is referring to.

As for bank-count, the description "this is a temporary hack until the bank_count is removed from the driver" suggests it shouldn't be there at all, much less be part of the generic binding.

Quoted 1 line · Scott Wood

What does "the id" mean, in relation to the actual hardware?

It's true that the description is not super meaningful... This is the HW instance number. We have 6 gpios, named gpio1 to gpio6, but the pin numbering is global, meaning from 1 to 192, sine only the global number is referenced in the pinmuxing control, we have to maintain the order to ensure the right number.

I still do not know how to use that with the way gpio binding is working. Because in theory each gpio controller should be referenced with the local number, not the global one. And converting that global number from HW spec to a gpio instance + local number seems to me very error prone.

On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:

Documentation/devicetree/bindings/gpio/gpio-omap.txt line 5

Quoted 3 lines

Documentation/devicetree/bindings/gpio/gpio-omap.txt new file +3 -0

+Required properties:
+- compatible:
+  - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers

Would it be more readable to have
"ti,omap2-gpio" for OMAP2 controllers and
"ti,omap3-gpio" for OMAP3 controllers?

On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:

Review

Quoted 2 lines

(quoted diff) +2 -0

+	if (match) {
+		of_property_read_u32(node, "bank-width",&bank->width);

Bank width should be u32.

Add initial device-tree support for twl familly chips.

The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly.

Add documentation for the Texas Instruments TWL Integrated Chip.

Signed-off-by Benoit Cousson<[email protected]>

Cc Balaji T K<[email protected]>

Cc Graeme Gregory<[email protected]>

Cc Samuel Ortiz<[email protected]>

---
  .../devicetree/bindings/mfd/twl-familly.txt        |   47 +++++++++++++++++
  drivers/mfd/twl-core.c                             |   53 ++++++++++++++++++--
  2 files changed, 96 insertions(+), 4 deletions(-)

create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt

Documentation/devicetree/bindings/mfd/twl-familly.txt new file +24 -0

new file mode 100644
index 0000000..ff4cacd
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,twl4030";
+  For Integrated power-management/audio CODEC device used in OMAP3
+  based boards
+- compatible : Must be "ti,twl6030";
+  For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+  it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells =<1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+  that support a different number of features.
+  The children nodes will thus depend of the capabilty of the variant.

Documentation/devicetree/bindings/mfd/twl-familly.txt new file +2 -0

+    };
+};

drivers/mfd/twl-core.c +5 -0

index 01ecfee..3ef0b43 100644
@@ -33,6 +33,10 @@
  #include<linux/platform_device.h>
  #include<linux/clk.h>
  #include<linux/err.h>
+#include<linux/slab.h>
+#include<linux/of_irq.h>
+#include<linux/of_platform.h>
+#include<linux/irqdomain.h>
 
  #include<linux/regulator/machine.h>
 

@@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
  	int				status;
  	unsigned			i;
  	struct twl4030_platform_data	*pdata = client->dev.platform_data;
+	struct device_node		*node = client->dev.of_node;

drivers/mfd/twl-core.c +26 -3

+		if (!pdata) {
+			status = -ENOMEM;
+			goto exit;
+		}
+
+		/*
+		 * XXX: For the moment the IRQs for TWL seems to be encoded in
+		 * the global OMAP space. That should be cleaned to allow
+		 * dynamically adding a new IRQ controller.
+		 */
+		if ((id->driver_data)&  TWL6030_CLASS) {
+			pdata->irq_base = TWL6030_IRQ_BASE;
+			pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
+		} else {
+			pdata->irq_base = TWL4030_IRQ_BASE;
+			pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
+		}
+		irq_domain_add_simple(node, pdata->irq_base);
+	}
+
  	if (!pdata) {
  		dev_dbg(&client->dev, "no platform data?\n");
-		return -EINVAL;
+		status = -EINVAL;
+		goto fail_free;
  	}
 
  	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
  		dev_dbg(&client->dev, "can't talk I2C?\n");
-		return -EIO;
+		status = -EIO;
+		goto fail_free;
  	}
 
  	if (inuse) {
  		dev_dbg(&client->dev, "driver is already in use\n");
-		return -EBUSY;
+		status = -EBUSY;
+		goto fail_free;
  	}
 
  	for (i = 0; i<  TWL_NUM_SLAVES; i++) {

drivers/mfd/twl-core.c +10 -0

+	if (node)
+		status = of_platform_populate(node, NULL, NULL,&client->dev);
+	else
+#endif
+		status = add_children(pdata, id->driver_data);
+
  fail:
  	if (status<  0)
  		twl_remove(client);
+fail_free:
+	if (node)
+		kfree(pdata);
+exit:
  	return status;
  }
 

Quoted 1 line · Benoit Cousson

Add initial device-tree support for twl familly chips.

s/familly/family

Quoted 11 lines

The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly.

Add documentation for the Texas Instruments TWL Integrated Chip.

Signed-off-by Benoit Cousson<[email protected]>

Cc Balaji T K<[email protected]>

Cc Graeme Gregory<[email protected]>

Cc Samuel Ortiz<[email protected]>

Quoted 5 lines

---
   .../devicetree/bindings/mfd/twl-familly.txt        |   47 +++++++++++++++++
   drivers/mfd/twl-core.c                             |   53 ++++++++++++++++++--
   2 files changed, 96 insertions(+), 4 deletions(-)

create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt

s/familly.txt/family.txt

Quoted 34 lines

Documentation/devicetree/bindings/mfd/twl-familly.txt new file +28 -0

new file mode 100644
index 0000000..ff4cacd
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,twl4030";
+  For Integrated power-management/audio CODEC device used in OMAP3
+  based boards
+- compatible : Must be "ti,twl6030";
+  For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+  it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells =<1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+  that support a different number of features.
+  The children nodes will thus depend of the capabilty of the variant.
+
+
+Example:
+/*

Documentation/devicetree/bindings/mfd/twl-familly.txt

Quoted 6 lines

Documentation/devicetree/bindings/mfd/twl-familly.txt new file +6 -0

+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl at 48 {
+    compatible = "ti,twl6030";
+    reg =<0x48>;

What does the 'reg' property signify here for twl?

Documentation/devicetree/bindings/mfd/twl-familly.txt line 45

Quoted 11 lines

Documentation/devicetree/bindings/mfd/twl-familly.txt new file +11 -0

+    interrupts =<39>; /* IRQ_SYS_1N cascaded to gic */
+    interrupt-controller;
+    #interrupt-cells =<1>;
+    interrupt-parent =<&gic>;
+    #address-cells =<1>;
+    #size-cells =<0>;
+
+    twl_rtc {
+        compatible = "ti,twl_rtc";
+        interrupts =<11>;
+        reg =<0>;

Does the 'reg' property need to be faked for
every twl child node, even if it does not have
any?

Quoted 25 lines

Documentation/devicetree/bindings/mfd/twl-familly.txt new file +2 -0

+    };
+};

drivers/mfd/twl-core.c +5 -0

index 01ecfee..3ef0b43 100644
@@ -33,6 +33,10 @@
   #include<linux/platform_device.h>
   #include<linux/clk.h>
   #include<linux/err.h>
+#include<linux/slab.h>
+#include<linux/of_irq.h>
+#include<linux/of_platform.h>
+#include<linux/irqdomain.h>
 
   #include<linux/regulator/machine.h>
 

@@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
   	int				status;
   	unsigned			i;
   	struct twl4030_platform_data	*pdata = client->dev.platform_data;
+	struct device_node		*node = client->dev.of_node;
   	u8 temp;
   	int ret = 0;
 

drivers/mfd/twl-core.c twl_probe(struct i2c_client *client, const struct i2c_device_id *id) · line 1199

Quoted 7 lines

drivers/mfd/twl-core.c +7 -0

+	if (node&&   !pdata) {
+		/*
+		 * XXX: Temporary fake pdata until the information
+		 * is correctly retrieved by every TWL modules from DT.
+		 */
+		pdata = kzalloc(sizeof(struct twl4030_platform_data),
+				GFP_KERNEL);

devm_kzalloc instead?

Quoted 46 lines

drivers/mfd/twl-core.c +26 -3

+		if (!pdata) {
+			status = -ENOMEM;
+			goto exit;
+		}
+
+		/*
+		 * XXX: For the moment the IRQs for TWL seems to be encoded in
+		 * the global OMAP space. That should be cleaned to allow
+		 * dynamically adding a new IRQ controller.
+		 */
+		if ((id->driver_data)&   TWL6030_CLASS) {
+			pdata->irq_base = TWL6030_IRQ_BASE;
+			pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
+		} else {
+			pdata->irq_base = TWL4030_IRQ_BASE;
+			pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
+		}
+		irq_domain_add_simple(node, pdata->irq_base);
+	}
+
   	if (!pdata) {
   		dev_dbg(&client->dev, "no platform data?\n");
-		return -EINVAL;
+		status = -EINVAL;
+		goto fail_free;
   	}
 
   	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
   		dev_dbg(&client->dev, "can't talk I2C?\n");
-		return -EIO;
+		status = -EIO;
+		goto fail_free;
   	}
 
   	if (inuse) {
   		dev_dbg(&client->dev, "driver is already in use\n");
-		return -EBUSY;
+		status = -EBUSY;
+		goto fail_free;
   	}
 
   	for (i = 0; i<   TWL_NUM_SLAVES; i++) {

@@ -1269,10 +1304,20 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
   		twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
   	}
 

drivers/mfd/twl-core.c twl_probe(struct i2c_client *client, const struct i2c_device_id *id) · line 1307

Quoted 2 lines

drivers/mfd/twl-core.c +1 -1

-	status = add_children(pdata, id->driver_data);
+#ifdef CONFIG_OF_DEVICE

is the #ifdef really needed?

Add i2c controllers nodes into the main ocp bus.

Signed-off-by Benoit Cousson<[email protected]>

Cc G, Manjunath Kondaiah<[email protected]>

---
  arch/arm/boot/dts/omap4.dtsi |   32 ++++++++++++++++++++++++++++++++
  1 files changed, 32 insertions(+), 0 deletions(-)

arch/arm/boot/dts/omap4.dtsi +4 -0

index bb19bca..447f482 100644
@@ -21,6 +21,10 @@
  	interrupt-parent =<&gic>;
 
  	aliases {
+		i2c1 =&i2c1;
+		i2c2 =&i2c2;
+		i2c3 =&i2c3;
+		i2c4 =&i2c4;
  	};
 
  	cpus {

arch/arm/boot/dts/omap4.dtsi +25 -0

+			#address-cells =<1>;
+			#size-cells =<0>;
+			ti,hwmods = "i2c1";
+		};
+
+		i2c2: i2c at 2 {
+			compatible = "ti,omap3-i2c";
+			#address-cells =<1>;
+			#size-cells =<0>;
+			ti,hwmods = "i2c2";
+		};
+
+		i2c3: i2c at 3 {
+			compatible = "ti,omap3-i2c";
+			#address-cells =<1>;
+			#size-cells =<0>;
+			ti,hwmods = "i2c3";
+		};
+
+		i2c4: i2c at 4 {
+			compatible = "ti,omap3-i2c";
+			#address-cells =<1>;
+			#size-cells =<0>;
+			ti,hwmods = "i2c4";
+		};
  	};
  };

Add required clock frequencies for the i2c client devices existing on beagle board.

Add the twl4030 basic description with only the twl_rtc module.

Add the EEPROM node.

Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html

Signed-off-by Benoit Cousson <[email protected]>

Cc G, Manjunath Kondaiah <[email protected]>

---
 arch/arm/boot/dts/omap3-beagle.dts |   38 ++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)

arch/arm/boot/dts/omap3-beagle.dts +6 -0

index 9486be6..a65f39d 100644
@@ -27,3 +27,41 @@
 		reg = <0x80000000 0x20000000>; /* 512 MB */
 	};
 };
+
+&i2c1 {
+	clock-frequency = <2600000>;
+
+	/*
+	 * Integrated Power Management Chip

arch/arm/boot/dts/omap3-beagle.dts +22 -0

+			compatible = "ti,twl4030-rtc";
+			interrupts = <11>;
+		};
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+
+	/*
+	 * Display monitor features are burnt in the EEPROM
+	 * as EDID data.
+	 */
+	eeprom at 50 {
+		compatible = "ti,eeprom";
+		reg = <0x50>;
+	};
+};

Signature · 1 line

1.7.0.4