ARM: davinci: add support for the am1808 based enbw_cmc board

Add a function to initialize the davinci interrupt controller (INTC) using a device tree node.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++++++++
 arch/arm/mach-davinci/cp_intc.c                    |   51 ++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
 3 files changed, 78 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt

Documentation/devicetree/bindings/arm/davinci/intc.txt new file +26 -0

new file mode 100644
index 0000000..dac2f69
@@ -0,0 +1,26 @@
+* TI Davinci Interrupt Controller
+
+davinci are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+	"ti,davinci-intc"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The type shall be a <u32> and the value shall be 1.
+
+  The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+	intc: interrupt-controller at 1 {
+		compatible = "ti,davinci-intc";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		ti,intc-size = <101>;
+		reg = <0xfffee000 0x2000>;
+	};

arch/arm/mach-davinci/cp_intc.c +22 -0

index f83152d..2c6e2e4 100644
@@ -11,7 +11,11 @@
 
 #include <linux/init.h>
 #include <linux/irq.h>
+#include <linux/irqdomain.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 
 #include <mach/common.h>
 #include <mach/cp_intc.h>

@@ -175,3 +179,50 @@ void __init cp_intc_init(void)
 	/* Enable global interrupt */
 	cp_intc_write(1, CP_INTC_GLOBAL_ENABLE);
 }
+
+#ifdef CONFIG_OF
+int __init dv_intc_of_init(struct device_node *node, struct device_node *parent)
+{
+	struct resource res;
+	u32 nr_irqs;
+
+	if (WARN_ON(!node))
+		return -ENODEV;
+
+	if (of_address_to_resource(node, 0, &res)) {
+		WARN(1, "unable to get intc registers\n");
+		return -EINVAL;
+	}
+
+	davinci_soc_info.intc_base = res.start;
+	if (WARN_ON(!davinci_soc_info.intc_base))
+		return -EINVAL;

Quoted 16 lines · Heiko Schocher

Add a function to initialize the davinci interrupt controller (INTC) using a device tree node.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++++++++
 arch/arm/mach-davinci/cp_intc.c                    |   51 ++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
 3 files changed, 78 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt

Quoted 4 lines

arch/arm/mach-davinci/cp_intc.c +0 -0

index f83152d..2c6e2e4 100644

arch/arm/mach-davinci/cp_intc.c void __init cp_intc_init(void) · line 209

Quoted 2 lines

arch/arm/mach-davinci/cp_intc.c +2 -0

+	cp_intc_init();
+	irq_domain_add_simple(node, 0);

Take a look at the irq_domain patches that will be (probably) merged in v3.4. Instead of calling irq_domain_add_simple(), you should migrate the whole interrupt controller to natively use an irq_domain for hwirq <--> irq mapping.

Hello Grant,

Quoted 17 lines · Grant Likely

Quoted 16 lines · Heiko Schocher

Add a function to initialize the davinci interrupt controller (INTC) using a device tree node.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++++++++
 arch/arm/mach-davinci/cp_intc.c                    |   51 ++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
 3 files changed, 78 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt

[...]

Quoted 4 lines

Quoted 4 lines

arch/arm/mach-davinci/cp_intc.c +0 -0

index f83152d..2c6e2e4 100644

[...]

Quoted 6 lines

arch/arm/mach-davinci/cp_intc.c void __init cp_intc_init(void) · line 209

Quoted 2 lines

arch/arm/mach-davinci/cp_intc.c +2 -0

+	cp_intc_init();
+	irq_domain_add_simple(node, 0);

Take a look at the irq_domain patches that will be (probably) merged in v3.4. Instead of calling irq_domain_add_simple(), you should migrate the whole interrupt controller to natively use an irq_domain for hwirq <--> irq mapping.

I rebased my hole patchset to:

git://git.secretlab.ca/git/linux-2.6.git irqdomain/next and reworked the arch/arm/mach-davinci/cp_intc.c irq driver to use irq_domain, works good on the enbw_cmc board :-)

Waiting for your comment to my question to the
[RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board patch, see:
http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg07132.html

and resend the hole reworked patchserie. Is it OK, if I use the above branch as base for sending this patchserie, or should I use another tree/branch for it?

Hello Heiko,

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt line 4

Quoted 4 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +4 -0

+* Texas Instruments Davinci EMAC
+
+This file provides information, what the davice node
+for the davinci_emac interface contain.

Please, fix the typo. (davice -> device)

add of support for the davinci_emac driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc netdev at vger.kernel.org

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../bindings/arm/davinci/davinci_emac.txt          |   46 ++++++++
 drivers/net/ethernet/ti/davinci_emac.c             |  111 +++++++++++++++++++-
 2 files changed, 156 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +1 -0

new file mode 100644
index 0000000..4e5dc8d
@@ -0,0 +1,46 @@
+* Texas Instruments Davinci EMAC

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +31 -0

+- phy-handle: Contains a phandle to an Ethernet PHY.
+              if not, davinci_emac driver defaults to 100/FULL
+- interrupts: interrupt mapping for the davinci emac interrupts sources:
+              4 sources: <Receive Threshold Interrupt
+			  Receive Interrupt
+			  Transmit Interrupt
+			  Miscellaneous Interrupt>
+- pinmux-handle: Contains a handle to configure the pinmux settings.
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example (enbw_cmc board):
+	eth0: emac at 1e20000 {
+		compatible = "ti,davinci-emac";
+		reg = <0x220000 0x4000>;
+		ctrl_reg_offset = <0x3000>;
+		ctrl_mod_reg_offset = <0x2000>;
+		ctrl_ram_offset = <0>;
+		hw_ram_addr = <0>;
+		ctrl_ram_size = <0x2000>;
+		version = <1>;
+		local-mac-address = [ 00 00 00 00 00 00 ];
+		interrupts = <33
+				34
+				35
+				36
+				>;
+		interrupt-parent = <&intc>;
+		pinmux-handle = <&emac_pins>;
+	};

drivers/net/ethernet/ti/davinci_emac.c +22 -0

index 794ac30..cad7a96 100644
@@ -58,6 +58,12 @@
 #include <linux/io.h>
 #include <linux/uaccess.h>
 #include <linux/davinci_emac.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_net.h>
+
+#include <mach/mux.h>
 
 #include <asm/irq.h>
 #include <asm/page.h>

@@ -339,6 +345,9 @@ struct emac_priv {
 	u32 rx_addr_type;
 	atomic_t cur_tx;
 	const char *phy_id;
+#ifdef CONFIG_OF
+	struct device_node *phy_node;
+#endif
 	struct phy_device *phydev;
 	spinlock_t lock;
 	/*platform specific members*/

@@ -1582,6 +1591,7 @@ static int emac_dev_open(struct net_device *ndev)
 	cpdma_ctlr_start(priv->dma);
 
 	priv->phydev = NULL;
+
 	/* use the first phy on the bus if pdata did not give us a phy id */
 	if (!priv->phy_id) {
 		struct device *phy;

@@ -1759,6 +1769,104 @@ static const struct net_device_ops emac_netdev_ops = {
 #endif
 };
 
+#ifdef CONFIG_OF
+static struct emac_platform_data
+	*davinci_emac_of_get_pdata(struct platform_device *pdev,
+	struct emac_priv *priv)
+{
+	struct device_node *np;
+	struct device_node *pinmux_np;
+	struct emac_platform_data *pdata = NULL;
+	const u8 *mac_addr;
+	u32 data;
+	int ret;
+	struct resource temp_res;

drivers/net/ethernet/ti/davinci_emac.c +29 -0

+		if (!pdata)
+			goto nodata;
+	}
+
+	mac_addr = of_get_mac_address(np);
+	if (mac_addr)
+		memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+
+	ret = of_property_read_u32(np, "ctrl_reg_offset", &data);
+	if (!ret)
+		pdata->ctrl_reg_offset = data;
+
+	ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data);
+	if (!ret)
+		pdata->ctrl_mod_reg_offset = data;
+
+	ret = of_property_read_u32(np, "ctrl_ram_offset", &data);
+	if (!ret)
+		pdata->ctrl_ram_offset = data;
+
+	ret = of_property_read_u32(np, "hw_ram_addr", &data);
+	if (!ret)
+		pdata->hw_ram_addr = data;
+
+	ret = of_property_read_u32(np, "ctrl_ram_size", &data);
+	if (!ret)
+		pdata->ctrl_ram_size = data;
+
+	ret = of_property_read_u32(np, "rmii_en", &data);

drivers/net/ethernet/ti/davinci_emac.c +21 -1

+		}
+		index++;
+	}
+
+	pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
+	if (pinmux_np)
+		davinci_cfg_reg_of(pinmux_np);
+
+	pdev->dev.platform_data = pdata;
+nodata:
+	return  pdata;
+}
+#else
+static struct emac_platform_data
+	*davinci_emac_of_get_pdata(struct platform_device *pdev,
+	struct emac_priv *priv)
+{
+	return  pdev->dev.platform_data;
+}
+#endif
 /**
  * davinci_emac_probe: EMAC device probe
  * @pdev: The DaVinci EMAC device that we are removing

@@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 
 	spin_lock_init(&priv->lock);
 
-	pdata = pdev->dev.platform_data;
+	pdata = davinci_emac_of_get_pdata(pdev, priv);
 	if (!pdata) {
 		dev_err(&pdev->dev, "no platform data\n");
 		rc = -ENODEV;

Quoted 29 lines · Heiko Schocher

add of support for the davinci_emac driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc netdev at vger.kernel.org

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../bindings/arm/davinci/davinci_emac.txt          |   46 ++++++++
 drivers/net/ethernet/ti/davinci_emac.c             |  111 +++++++++++++++++++-
 2 files changed, 156 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +7 -0

new file mode 100644
index 0000000..4e5dc8d
@@ -0,0 +1,46 @@
+* Texas Instruments Davinci EMAC
+
+This file provides information, what the davice node
+for the davinci_emac interface contain.
+
+Required properties:
+- compatible: "ti,davinci-emac";

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt line 11

Quoted 4 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +4 -0

+- reg: Offset and length of the register set for the device
+- ctrl_reg_offset: offset to control register
+- ctrl_mod_reg_offset: offset to control module register
+- ctrl_ram_offset: offset to control module ram

Should these be explicit properties, or can they be discerned from the compatible string (which should include the hardware version; see below).

Also, any custom properties that are specific to a binding really should include a vendor prefix ('ti,') to avoid namespace collisions with common bindings.

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt line 12

Quoted 1 line

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +1 -0

+- hw_ram_addr: hardware ram addr

Can this be added as a second tuple in the reg property?

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt line 15

Quoted 3 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +3 -0

+- ctrl_ram_size: size of control module ram
+- version: 1 (EMAC_VERSION_1 for DM644x)
+           2 (EMAC_VERSION_2 for DM646x)

Don't use a version property. Encode it into the compatible property. ie:

compatible = "ti,davinci-dm6440-emac"; or
compatible = "ti,davinci-dm6460-emac";

You'll also note that I did not use a 'x' as a wildcard. It is always safer to be explicit about the part number. And have newer parts claim compatibility with older ones like so:

compatible = "ti,davinci-dm6443-emac", "ti,davinci-dm6440-emac"; (I am obviously making up numbers here. Fill in appropriate numbers for your device.

Quoted 5 lines

drivers/net/ethernet/ti/davinci_emac.c +0 -0

index 794ac30..cad7a96 100644
@@ -58,6 +58,12 @@

drivers/net/ethernet/ti/davinci_emac.c static const struct net_device_ops emac_netdev_ops = { · line 1793

Quoted 3 lines

drivers/net/ethernet/ti/davinci_emac.c +3 -0

+	pdata = pdev->dev.platform_data;
+	if (!pdata) {
+		pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL);

devm_kzalloc()

Quoted 33 lines

drivers/net/ethernet/ti/davinci_emac.c +33 -0

+		if (!pdata)
+			goto nodata;
+	}
+
+	mac_addr = of_get_mac_address(np);
+	if (mac_addr)
+		memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+
+	ret = of_property_read_u32(np, "ctrl_reg_offset", &data);
+	if (!ret)
+		pdata->ctrl_reg_offset = data;
+
+	ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data);
+	if (!ret)
+		pdata->ctrl_mod_reg_offset = data;
+
+	ret = of_property_read_u32(np, "ctrl_ram_offset", &data);
+	if (!ret)
+		pdata->ctrl_ram_offset = data;
+
+	ret = of_property_read_u32(np, "hw_ram_addr", &data);
+	if (!ret)
+		pdata->hw_ram_addr = data;
+
+	ret = of_property_read_u32(np, "ctrl_ram_size", &data);
+	if (!ret)
+		pdata->ctrl_ram_size = data;
+
+	ret = of_property_read_u32(np, "rmii_en", &data);
+	if (!ret)
+		pdata->rmii_en = data;
+
+	ret = of_property_read_u32(np, "version", &data);

drivers/net/ethernet/ti/davinci_emac.c static const struct net_device_ops emac_netdev_ops = { · line 1832

Quoted 6 lines

drivers/net/ethernet/ti/davinci_emac.c +6 -0

+	if (!ret)
+		pdata->version = data;
+
+	ret = of_property_read_u32(np, "no_bd_ram", &data);
+	if (!ret)
+		pdata->ctrl_mod_reg_offset = data;

Not all these properties are mentioned in the documentation.

Quoted 4 lines

drivers/net/ethernet/ti/davinci_emac.c +4 -0

+
+	priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
+	if (!priv->phy_node)
+		pdata->phy_id = "";

drivers/net/ethernet/ti/davinci_emac.c static const struct net_device_ops emac_netdev_ops = { · line 1839

Quoted 3 lines

drivers/net/ethernet/ti/davinci_emac.c +3 -0

+
+	if (!of_address_to_resource(np, 0, &temp_res))
+		memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource));

Don't use of_address_to_resource. The platform device resource table will already be populated by the core code so you don't need to call it here. Besides, it is illegal for drivers to overwrite the pdev->resource[] table.

Quoted 5 lines

drivers/net/ethernet/ti/davinci_emac.c +5 -0

+
+	index = 0;
+	while (index < 4) {
+		irq = irq_of_parse_and_map(np, index);
+		if (irq > 0) {

drivers/net/ethernet/ti/davinci_emac.c static const struct net_device_ops emac_netdev_ops = { · line 1849

Quoted 5 lines

drivers/net/ethernet/ti/davinci_emac.c +5 -0

+			temp_res.start = irq;
+			temp_res.end = irq;
+			temp_res.flags = IORESOURCE_IRQ;
+			memcpy(&pdev->resource[index + 1], &temp_res,
+				sizeof(struct resource));

Same here, the core code will have already populated the irqs into the resource table for you.

Quoted 34 lines

drivers/net/ethernet/ti/davinci_emac.c +21 -1

+		}
+		index++;
+	}
+
+	pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
+	if (pinmux_np)
+		davinci_cfg_reg_of(pinmux_np);
+
+	pdev->dev.platform_data = pdata;
+nodata:
+	return  pdata;
+}
+#else
+static struct emac_platform_data
+	*davinci_emac_of_get_pdata(struct platform_device *pdev,
+	struct emac_priv *priv)
+{
+	return  pdev->dev.platform_data;
+}
+#endif
 /**
  * davinci_emac_probe: EMAC device probe
  * @pdev: The DaVinci EMAC device that we are removing

@@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 
 	spin_lock_init(&priv->lock);
 
-	pdata = pdev->dev.platform_data;
+	pdata = davinci_emac_of_get_pdata(pdev, priv);
 	if (!pdata) {
 		dev_err(&pdev->dev, "no platform data\n");
 		rc = -ENODEV;

@@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 

drivers/net/ethernet/ti/davinci_emac.c static int __devinit davinci_emac_probe(struct platform_device *pdev) · line 1922

Quoted 3 lines

drivers/net/ethernet/ti/davinci_emac.c +1 -0

 	/* MAC addr and PHY mask , RMII enable info from platform_data */
 	memcpy(priv->mac_addr, pdata->mac_addr, 6);
+

Nit: There are a few instances of unrelated whitespace changes in this patch.

Hello Grant,

Quoted 30 lines · Grant Likely

Quoted 29 lines · Heiko Schocher

add of support for the davinci_emac driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc netdev at vger.kernel.org

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../bindings/arm/davinci/davinci_emac.txt          |   46 ++++++++
 drivers/net/ethernet/ti/davinci_emac.c             |  111 +++++++++++++++++++-
 2 files changed, 156 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +7 -0

new file mode 100644
index 0000000..4e5dc8d
@@ -0,0 +1,46 @@
+* Texas Instruments Davinci EMAC
+
+This file provides information, what the davice node
+for the davinci_emac interface contain.
+
+Required properties:
+- compatible: "ti,davinci-emac";

Quoted 8 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt line 11

Quoted 4 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +4 -0

+- reg: Offset and length of the register set for the device
+- ctrl_reg_offset: offset to control register
+- ctrl_mod_reg_offset: offset to control module register
+- ctrl_ram_offset: offset to control module ram

Should these be explicit properties, or can they be discerned from the compatible string (which should include the hardware version; see below).

Hmm.. I do not know all davinci SoCs ... maybe someone from TI could answer this? But I think, we could discern this from the compatible string. I prepare this for v2. Maybe it is Ok, if I do this only for my hardwareversion and others add this, if needed? (maybe the better approach, as I can code it, but have no hw for testing it ... so it maybe is buggy)

Quoted 3 lines

Also, any custom properties that are specific to a binding really should include a vendor prefix ('ti,') to avoid namespace collisions with common bindings.

Yep, is "ti,davinci-" ok? Also I should use dashes instead underscores, right?

Quoted 4 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt line 12

Quoted 2 lines

Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt new file +1 -0

+- hw_ram_addr: hardware ram addr

Can this be added as a second tuple in the reg property?

No, if I know this right, this is used for DMA, and also could be RAM.

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher<[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Grant Likely<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
  2 files changed, 82 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +0 -0

new file mode 100644
index 0000000..94ec670

Hello,

Quoted 30 lines · Heiko Schocher

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher<[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Grant Likely<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
  2 files changed, 82 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +6 -0

new file mode 100644
index 0000000..94ec670
@@ -0,0 +1,39 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:

Documentation/devicetree/bindings/arm/davinci/i2c.txt line 9

Quoted 3 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +3 -0

+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+- id: id of the controller

I was wondering whether we're supposed to use "cell-index" property name for such a device instance index? or doesn't it really matter and "id" is fine? Such an IP instance index seems quite common so I thought it could be easier to follow to use standard name.

Quoted 31 lines · Heiko Schocher

Quoted 30 lines

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher<[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Grant Likely<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
  2 files changed, 82 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +6 -0

new file mode 100644
index 0000000..94ec670
@@ -0,0 +1,39 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:

Quoted 8 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt line 9

Quoted 3 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +3 -0

+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+- id: id of the controller

I was wondering whether we're supposed to use "cell-index" property name for such a device instance index? or doesn't it really matter and "id" is fine? Such an IP instance index seems quite common so I thought it could be easier to follow to use standard name.

I just copied the "name" from "struct davinci_nand_pdata" ... it is used in the davinci_nand driver as chipselect ... maybe it is better I rename this to "chipselect" ?

From what I can see the 'id' property is used to determine I2C adapter

Hello Heiko,

Quoted 40 lines · Heiko Schocher

Quoted 31 lines · Heiko Schocher

Quoted 30 lines

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher<[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Grant Likely<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
  2 files changed, 82 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +6 -0

new file mode 100644
index 0000000..94ec670
@@ -0,0 +1,39 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:

Quoted 8 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt line 9

Quoted 3 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +3 -0

+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+- id: id of the controller

I was wondering whether we're supposed to use "cell-index" property name for such a device instance index? or doesn't it really matter and "id" is fine? Such an IP instance index seems quite common so I thought it could be easier to follow to use standard name.

Quoted 3 lines

I just copied the "name" from "struct davinci_nand_pdata" ... it is used in the davinci_nand driver as chipselect ... maybe it is better I rename this to "chipselect" ?

From what I can see the 'id' property is used to determine I2C adapter number. In that case 'id' seems more correct than "chipselect". Are you sure there is a chip select functionality in I2C controller ?

It seems that your id is just an index of I2C controller in hardware. I would personally just use cell-index for that, but I'm not a dt expert, someone nay correct me.

Moreover you seem to overwrite platform device name and id,

		if (!of_property_read_u32(pdev->dev.of_node, "id",

drivers/i2c/busses/i2c-davinci.c +5 -0

+			&prop)) {
+			pdev->id = prop;
+			pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
+			sprintf((char *)pdev->dev.init_name,
+				"i2c_davinci.%d", pdev->id);

I'm not sure if it is a good practice.

If you want to pre-define platform
device name (likely for the clock API to work), it might be more appropriate to use OF_DEV_AUXDATA in the machine code, until there are clock bindings available.

Quoted 21 lines · Sylwester Nawrocki

Hello Heiko,

Quoted 18 lines · Heiko Schocher

Quoted 18 lines · Heiko Schocher

Quoted 17 lines

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher<[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Grant Likely<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
  2 files changed, 82 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Quoted 10 lines

Moreover you seem to overwrite platform device name and id,

		if (!of_property_read_u32(pdev->dev.of_node, "id",

drivers/i2c/busses/i2c-davinci.c +5 -0

+			&prop)) {
+			pdev->id = prop;
+			pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
+			sprintf((char *)pdev->dev.init_name,
+				"i2c_davinci.%d", pdev->id);

I'm not sure if it is a good practice.

No, it is not good practice. At this point the device is already registered. Changing the value of pdev->id will cause problems in the core code because the /sysfs files will have already been created.

Quoted 4 lines

If you want to pre-define platform
device name (likely for the clock API to work), it might be more appropriate to use OF_DEV_AUXDATA in the machine code, until there are clock bindings available.

Yes, use OF_DEV_AUXDATA, but *only* if you need it for hooking up clocks, regulators, or similar. Don't use it just because you want the device to have a different name for cosmetic reasons. The need for AUXDATA should go away once the DT clock binding code is merged.

The whole 'cell-index' or 'id' thing is a BadIdea(tm). Don't use it, and tell others not to do it when you see it. There are some legacy uses in powerpc, but those were written before I and others knew better.

The *only* situation where cell-index is acceptable is when the driver absolutely must know which hardware instance it is driving because it needs to calculate offsets in a shared register or something, and even then it should not be used to set the pdev->id field. That situation does not look to be the case here.

If you're using the DT, then let the core code dynamically assign the i2c adapter number.

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks <[email protected]>

Cc Wolfram Sang <[email protected]>

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
 drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +0 -0

new file mode 100644
index 0000000..94ec670

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +23 -0

+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Optional properties:
+- bus-delay: bus delay in usec
+- pinmux-handle: Contains a handle to configure the pinmux settings.
+
+Example (enbw_cmc board):
+	i2c at 1c22000 {
+		compatible = "ti,davinci-i2c";
+		reg = <0x22000 0x1000>;
+		clock-frequency = <100000>;
+		interrupts = <15 2>;
+		interrupt-parent = <&intc>;
+		id = <1>;
+		pinmux-handle = <&i2c1_pins>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dtt at 48 {
+				compatible = "national,lm75";
+				reg = <0x48>;
+			};
+	};

drivers/i2c/busses/i2c-davinci.c +3 -0

index a76d85f..6f59fae 100644
@@ -38,9 +38,12 @@
 #include <linux/slab.h>
 #include <linux/cpufreq.h>
 #include <linux/gpio.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
 
 #include <mach/hardware.h>
 #include <mach/i2c.h>
+#include <mach/mux.h>
 
 /* ----- global defines ----------------------------------------------- */
 

@@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
 	.functionality	= i2c_davinci_func,
 };

drivers/i2c/busses/i2c-davinci.c +1 -0

+
 static int davinci_i2c_probe(struct platform_device *pdev)
 {
 	struct davinci_i2c_dev *dev;

drivers/i2c/busses/i2c-davinci.c +3 -0

 		r = -ENODEV;
 		goto err_free_mem;

@@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	adap->algo = &i2c_davinci_algo;
 	adap->dev.parent = &pdev->dev;
 	adap->timeout = DAVINCI_I2C_TIMEOUT;
+	adap->dev.of_node = pdev->dev.of_node;
 
 	adap->nr = pdev->id;
 	r = i2c_add_numbered_adapter(adap);

@@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "failure adding adapter\n");
 		goto err_free_irq;
 	}
+	of_i2c_register_devices(adap);
 
 	return 0;
 

@@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = {
 		.name	= "i2c_davinci",
 		.owner	= THIS_MODULE,
 		.pm	= davinci_i2c_pm_ops,
+		.of_match_table = davinci_i2c_of_match,
 	},
 };
 

Signature · 1 line

1.7.7.5

Quoted 12 lines · Heiko Schocher

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks <[email protected]>

Cc Wolfram Sang <[email protected]>

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

Hi Heiko,

comments below.

Quoted 16 lines

---
 .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
 drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +4 -0

new file mode 100644
index 0000000..94ec670
@@ -0,0 +1,39 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.

Documentation/devicetree/bindings/arm/davinci/i2c.txt line 9

Quoted 5 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +5 -0

+
+Required properties:
+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+- id: id of the controller

Don't use an 'id' property. i2c bus numbers should be dynamically assigned when using the device tree.

Documentation/devicetree/bindings/arm/davinci/i2c.txt line 14

Quoted 5 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +5 -0

+
+Recommended properties :
+- interrupts : <a b> where a is the interrupt number and b is a
+  field that represents an encoding of the sense and level
+  information for the interrupt.

This is inaccurate. It is entirely defined by the interrupt controller. All you need to say here is that this is a standard interrupts property.

Documentation/devicetree/bindings/arm/davinci/i2c.txt line 16

Quoted 2 lines

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +2 -0

+- interrupt-parent : the phandle for the interrupt controller that
+  services interrupts for this device.

Don't even mention this one. It can often be inherited from a parent node.

Quoted 21 lines

drivers/i2c/busses/i2c-davinci.c +3 -0

index a76d85f..6f59fae 100644
@@ -38,9 +38,12 @@
 #include <linux/slab.h>
 #include <linux/cpufreq.h>
 #include <linux/gpio.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
 
 #include <mach/hardware.h>
 #include <mach/i2c.h>
+#include <mach/mux.h>
 
 /* ----- global defines ----------------------------------------------- */
 

@@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
 	.functionality	= i2c_davinci_func,
 };
 

drivers/i2c/busses/i2c-davinci.c static struct i2c_algorithm i2c_davinci_algo = { · line 649

Quoted 9 lines

drivers/i2c/busses/i2c-davinci.c +9 -0

+#if defined(CONFIG_OF)
+static const struct of_device_id davinci_i2c_of_match[] = {
+	{.compatible = "ti,davinci-i2c", },
+	{},
+}
+MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
+#else
+#define davinci_i2c_of_match NULL
+#endif

The #else clause can be dropped if you use the of_match_ptr() macro when referencing it.

Quoted 8 lines

drivers/i2c/busses/i2c-davinci.c +1 -0

+
 static int davinci_i2c_probe(struct platform_device *pdev)
 {
 	struct davinci_i2c_dev *dev;

@@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	dev->irq = irq->start;
 	platform_set_drvdata(pdev, dev);
 

drivers/i2c/busses/i2c-davinci.c static int davinci_i2c_probe(struct platform_device *pdev) · line 698

Quoted 7 lines

drivers/i2c/busses/i2c-davinci.c +7 -0

+	if ((dev->dev->platform_data == NULL) &&
+		(pdev->dev.of_node)) {
+		struct device_node *pinmux_np;
+		struct davinci_i2c_platform_data *pdata;
+		u32 prop;
+
+		dev->dev->platform_data = &davinci_i2c_platform_data_default;

Don't do this. What if a davinci part shows up with two i2c busses? Use devm_kzalloc() instead.

Quoted 7 lines

drivers/i2c/busses/i2c-davinci.c +7 -0

+		pdata = &davinci_i2c_platform_data_default;
+		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+			&prop))
+			pdata->bus_freq = prop / 1000;
+		if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
+			&prop))
+			pdata->bus_delay = prop;

drivers/i2c/busses/i2c-davinci.c static int davinci_i2c_probe(struct platform_device *pdev) · line 711

Quoted 6 lines

drivers/i2c/busses/i2c-davinci.c +6 -0

+		if (!of_property_read_u32(pdev->dev.of_node, "id",
+			&prop)) {
+			pdev->id = prop;
+			pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
+			sprintf((char *)pdev->dev.init_name,
+				"i2c_davinci.%d", pdev->id);

Blech! Drop this. Leave the core code to set the device name.

drivers/i2c/busses/i2c-davinci.c static int davinci_i2c_probe(struct platform_device *pdev) · line 720

Quoted 3 lines

drivers/i2c/busses/i2c-davinci.c +1 -0

 	dev->clk = clk_get(&pdev->dev, NULL);
+
 	if (IS_ERR(dev->clk)) {

Nit: unrelated whitespace change

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks <[email protected]>

Cc Wolfram Sang <[email protected]>

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
 drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +10 -0

new file mode 100644
index 0000000..94ec670
@@ -0,0 +1,39 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:
+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+- id: id of the controller
+

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +18 -0

+
+Example (enbw_cmc board):
+	i2c at 1c22000 {
+		compatible = "ti,davinci-i2c";
+		reg = <0x22000 0x1000>;
+		clock-frequency = <100000>;
+		interrupts = <15 2>;
+		interrupt-parent = <&intc>;
+		id = <1>;
+		pinmux-handle = <&i2c1_pins>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dtt at 48 {
+				compatible = "national,lm75";
+				reg = <0x48>;
+			};
+	};

drivers/i2c/busses/i2c-davinci.c +3 -0

index a76d85f..6f59fae 100644
@@ -38,9 +38,12 @@
 #include <linux/slab.h>
 #include <linux/cpufreq.h>
 #include <linux/gpio.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
 
 #include <mach/hardware.h>
 #include <mach/i2c.h>
+#include <mach/mux.h>
 
 /* ----- global defines ----------------------------------------------- */
 

@@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
 	.functionality	= i2c_davinci_func,
 };

drivers/i2c/busses/i2c-davinci.c +9 -0

+		struct device_node *pinmux_np;
+		struct davinci_i2c_platform_data *pdata;
+		u32 prop;
+
+		dev->dev->platform_data = &davinci_i2c_platform_data_default;
+		pdata = &davinci_i2c_platform_data_default;
+		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+			&prop))
+			pdata->bus_freq = prop / 1000;

drivers/i2c/busses/i2c-davinci.c +9 -0

+		pinmux_np = of_parse_phandle(pdev->dev.of_node,
+				"pinmux-handle", 0);
+		if (pinmux_np)
+			davinci_cfg_reg_of(pinmux_np);
+	}
 	dev->clk = clk_get(&pdev->dev, NULL);
+
 	if (IS_ERR(dev->clk)) {
 		r = -ENODEV;
 		goto err_free_mem;

@@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	adap->algo = &i2c_davinci_algo;
 	adap->dev.parent = &pdev->dev;
 	adap->timeout = DAVINCI_I2C_TIMEOUT;
+	adap->dev.of_node = pdev->dev.of_node;
 
 	adap->nr = pdev->id;
 	r = i2c_add_numbered_adapter(adap);

@@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "failure adding adapter\n");
 		goto err_free_irq;
 	}
+	of_i2c_register_devices(adap);
 
 	return 0;
 

@@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = {
 		.name	= "i2c_davinci",
 		.owner	= THIS_MODULE,
 		.pm	= davinci_i2c_pm_ops,
+		.of_match_table = davinci_i2c_of_match,
 	},
 };
 

Signature · 6 lines

1.7.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 23 lines · Heiko Schocher

add of support for the davinci i2c driver.

Signed-off-by Heiko Schocher <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-i2c at vger.kernel.org

Cc Ben Dooks <[email protected]>

Cc Wolfram Sang <[email protected]>

Cc Grant Likely <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
 .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
 drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
 2 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

Documentation/devicetree/bindings/arm/davinci/i2c.txt new file +0 -0

new file mode 100644
index 0000000..94ec670

Quoted 2 lines

+Optional properties:
+- bus-delay: bus delay in usec

bus_delay sounds rather like frequency in a different name, what is it for?

Quoted 5 lines

drivers/i2c/busses/i2c-davinci.c +0 -0

index a76d85f..6f59fae 100644
@@ -38,9 +38,12 @@

drivers/i2c/busses/i2c-davinci.c static struct i2c_algorithm i2c_davinci_algo = { · line 649

Quoted 4 lines

drivers/i2c/busses/i2c-davinci.c +4 -0

+MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
+#else
+#define davinci_i2c_of_match NULL
+#endif

see of_match_ptr() and you won't need the #else.

drivers/i2c/busses/i2c-davinci.c static int davinci_i2c_probe(struct platform_device *pdev) · line 693

Quoted 9 lines

static int davinci_i2c_probe(struct platform_device *pdev) {

drivers/i2c/busses/i2c-davinci.c +2 -0

 	struct davinci_i2c_dev *dev;

@@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	dev->irq = irq->start;
 	platform_set_drvdata(pdev, dev);
 
+	if ((dev->dev->platform_data == NULL) &&
+		(pdev->dev.of_node)) {

If there's platform_data an of_node, what happens then?

Quoted 13 lines

drivers/i2c/busses/i2c-davinci.c +13 -0

+		struct device_node *pinmux_np;
+		struct davinci_i2c_platform_data *pdata;
+		u32 prop;
+
+		dev->dev->platform_data = &davinci_i2c_platform_data_default;
+		pdata = &davinci_i2c_platform_data_default;
+		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+			&prop))
+			pdata->bus_freq = prop / 1000;
+		if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
+			&prop))
+			pdata->bus_delay = prop;
+		if (!of_property_read_u32(pdev->dev.of_node, "id",

drivers/i2c/busses/i2c-davinci.c static int davinci_i2c_probe(struct platform_device *pdev) · line 712

Quoted 6 lines

drivers/i2c/busses/i2c-davinci.c +6 -0

+			&prop)) {
+			pdev->id = prop;
+			pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
+			sprintf((char *)pdev->dev.init_name,
+				"i2c_davinci.%d", pdev->id);
+		}

Is this _really_ necessary, looks a bit of a hack to me.

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +1 -0

new file mode 100644
index 0000000..7e8d6db
@@ -0,0 +1,72 @@
+* Texas Instruments Davinci NAND

Quoted 16 lines · Heiko Schocher

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +10 -0

new file mode 100644
index 0000000..7e8d6db
@@ -0,0 +1,72 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+        - offset and length for the access window
+        - offset and length for accessing the aemif control registers

Documentation/devicetree/bindings/arm/davinci/nand.txt line 11

Quoted 1 line

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +1 -0

+- id: id of the controller

What does "id of the controller" mean, specfically? From this I can't even tell if it's a number or a string, much less how to use it semantically. If it's just a "match what's in the manual" thing, perhaps an alias would be better here. Or, if it's a value with a specific meaning (e.g. that you need to program into a register) use a more specific name.

Documentation/devicetree/bindings/arm/davinci/nand.txt line 21

Quoted 9 lines

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +9 -0

+Recommended properties :
+- mask_ale: mask for ale
+- mask_cle: mask for cle
+- mask_chipsel: mask for chipselect
+- ecc_mode: ECC mode, see NAND_ECC_* defines
+- ecc_bits: used ECC bits
+- options: nand options, defined in
+           include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
+- bbt_options: NAND_BBT_* defines

Binding-specific properties should have a vendor prefix. Dashes are preferred to underscores.

Don't specify Linux internals by reference -- they could change and invalidate existing device trees and non-Linux code that accepts them (e.g. U-Boot). If you want them to line up, copy the definition here, and if Linux changes, write glue code to convert. It would probably be better to define specific properties for anything that must be specified here (neither deteted dynamically nor defined by compatible = "ti,davinci-nand").

Do all of these properties really belong here? I can see providing some

information about ECC or BBT mode, if there are multiple conventions already in use (or that are reasonably justifiable for different situations), as that must agree with how the flash has already been programmed. How much of the rest can vary from one "ti,davinci-nand" to another? Maybe it's obvious to someone more familiar with davinci, but what does "mask for ale/cle/chipselect" mean?

Documentation/devicetree/bindings/arm/davinci/nand.txt line 55

Quoted 1 line

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +1 -0

+	nandflash at 3,0 {

PowerPC's ePAPR document -- not directly relevant to ARM, but contains a more recently updated list of generic names than the IEEE1275 recommended pratice -- specifies "flash@". If you don't want to do that, "nand@" is used in many existing trees. Why introduce a new name?

Hello Scott,

Quoted 17 lines · Scott Wood

Quoted 16 lines · Heiko Schocher

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +10 -0

new file mode 100644
index 0000000..7e8d6db
@@ -0,0 +1,72 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+        - offset and length for the access window
+        - offset and length for accessing the aemif control registers

Quoted 8 lines

Documentation/devicetree/bindings/arm/davinci/nand.txt line 11

Quoted 1 line

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +1 -0

+- id: id of the controller

What does "id of the controller" mean, specfically? From this I can't even tell if it's a number or a string, much less how to use it semantically. If it's just a "match what's in the manual" thing, perhaps an alias would be better here. Or, if it's a value with a specific meaning (e.g. that you need to program into a register) use a more specific name.

Ok, fix this. Id means here, which chipselect the controller uses. Maybe it is better to rename it to "chipselect" ?

Quoted 10 lines

Quoted 9 lines

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +9 -0

+Recommended properties :
+- mask_ale: mask for ale
+- mask_cle: mask for cle
+- mask_chipsel: mask for chipselect
+- ecc_mode: ECC mode, see NAND_ECC_* defines
+- ecc_bits: used ECC bits
+- options: nand options, defined in
+           include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
+- bbt_options: NAND_BBT_* defines

Quoted 2 lines

Binding-specific properties should have a vendor prefix. Dashes are preferred to underscores.

You think something like that:

davinci-mask-ale
davinci-mask-cle
...

Quoted 7 lines

Don't specify Linux internals by reference -- they could change and invalidate existing device trees and non-Linux code that accepts them (e.g. U-Boot). If you want them to line up, copy the definition here, and if Linux changes, write glue code to convert. It would probably be better to define specific properties for anything that must be specified here (neither deteted dynamically nor defined by compatible = "ti,davinci-nand").

Ok, I add the defines here, and add also a comment in the dts.

Quoted 1 line

Do all of these properties really belong here? I can see providing some

I think so, because this values come from existing platform code (grep for struct davinci_nand_pdata)

Comment in arch/arm/mach-davinci/include/mach/nand.h says for mask_ale and mask_cle:

/* NOTE: boards don't need to use these address bits
* for ALE/CLE unless they support booting from NAND.
* They're used unless platform data overrides them. */

It is used for addressing the ALE/CLE Signals through the address, used on the arch/arm/mach-davinci/board-dm646x-evm.c and arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think, this should be also be setupable through OF ...

Quoted 27 lines · Heiko Schocher

Hello Scott,

Quoted 24 lines · Scott Wood

Quoted 7 lines · Heiko Schocher

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +1 -0

new file mode 100644
index 0000000..7e8d6db
@@ -0,0 +1,72 @@
+* Texas Instruments Davinci NAND

Documentation/devicetree/bindings/arm/davinci/nand.txt line 11

Quoted 10 lines

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +10 -0

+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+        - offset and length for the access window
+        - offset and length for accessing the aemif control registers
+- id: id of the controller

What does "id of the controller" mean, specfically? From this I can't even tell if it's a number or a string, much less how to use it semantically. If it's just a "match what's in the manual" thing, perhaps an alias would be better here. Or, if it's a value with a specific meaning (e.g. that you need to program into a register) use a more specific name.

Quoted 2 lines

Ok, fix this. Id means here, which chipselect the controller uses. Maybe it is better to rename it to "chipselect" ?

Yes, or better "ti,chipselect" or "ti,davinci-chipselect".

Quoted 11 lines

Quoted 11 lines

Documentation/devicetree/bindings/arm/davinci/nand.txt line 21

Quoted 9 lines

Documentation/devicetree/bindings/arm/davinci/nand.txt new file +9 -0

+Recommended properties :
+- mask_ale: mask for ale
+- mask_cle: mask for cle
+- mask_chipsel: mask for chipselect
+- ecc_mode: ECC mode, see NAND_ECC_* defines
+- ecc_bits: used ECC bits
+- options: nand options, defined in
+           include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
+- bbt_options: NAND_BBT_* defines

Binding-specific properties should have a vendor prefix. Dashes are preferred to underscores.

Quoted 5 lines

You think something like that:

davinci-mask-ale
davinci-mask-cle
...

"ti,davinci-mask-ale", etc.

Quoted 8 lines

Quoted 7 lines

Don't specify Linux internals by reference -- they could change and invalidate existing device trees and non-Linux code that accepts them (e.g. U-Boot). If you want them to line up, copy the definition here, and if Linux changes, write glue code to convert. It would probably be better to define specific properties for anything that must be specified here (neither deteted dynamically nor defined by compatible = "ti,davinci-nand").

Ok, I add the defines here, and add also a comment in the dts.

Which options actually need to come from the device tree?

Quoted 3 lines

Quoted 1 line

Do all of these properties really belong here? I can see providing some

I think so, because this values come from existing platform code (grep for struct davinci_nand_pdata)

The standards are a bit stricter for the device tree, since it's a more stable interface across components -- at least that's how we've used it on a lot of powerpc targets. I'm not sure if that's the intent here, but I have seen U-Boot patches for ARM hardware using them as well.

Quoted 8 lines

Comment in arch/arm/mach-davinci/include/mach/nand.h says for mask_ale and mask_cle:

/* NOTE: boards don't need to use these address bits
* for ALE/CLE unless they support booting from NAND.
* They're used unless platform data overrides them. */

Quoted 4 lines

It is used for addressing the ALE/CLE Signals through the address, used on the arch/arm/mach-davinci/board-dm646x-evm.c and arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think, this should be also be setupable through OF ...

OK, if it's board logic that does the decoding, and the compatible is not board-specific, they belong here.

Scott Wood wrote:
I found the following used options:

ecc_mode:
NAND_ECC_NONE
NAND_ECC_SOFT
NAND_ECC_HW
NAND_ECC_HW_SYNDROME

bbt_options:
NAND_BBT_USE_FLASH

ecc_bits:
1
4

options:
NAND_BUSWIDTH_16

Quoted 4 lines

Quoted 3 lines

Quoted 1 line

Do all of these properties really belong here? I can see providing some

I think so, because this values come from existing platform code (grep for struct davinci_nand_pdata)

Quoted 4 lines

The standards are a bit stricter for the device tree, since it's a more stable interface across components -- at least that's how we've used it on a lot of powerpc targets. I'm not sure if that's the intent here, but I have seen U-Boot patches for ARM hardware using them as well.

Ok, so, should I introduce instead properties for the above needed parameters?

(As this are not davinci specific parameters, are there somewhere such definitions for them?)

Quoted 22 lines · Heiko Schocher

Scott Wood wrote:
I found the following used options:

ecc_mode:
NAND_ECC_NONE
NAND_ECC_SOFT
NAND_ECC_HW
NAND_ECC_HW_SYNDROME

bbt_options:
NAND_BBT_USE_FLASH

ecc_bits:
1
4

options:
NAND_BUSWIDTH_16

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Do all of these properties really belong here? I can see providing some

I think so, because this values come from existing platform code (grep for struct davinci_nand_pdata)

Quoted 6 lines

Quoted 4 lines

The standards are a bit stricter for the device tree, since it's a more stable interface across components -- at least that's how we've used it on a lot of powerpc targets. I'm not sure if that's the intent here, but I have seen U-Boot patches for ARM hardware using them as well.

Ok, so, should I introduce instead properties for the above needed parameters?

Yes.

Quoted 1 line

(As this are not davinci specific parameters, are there somewhere such definitions for them?)

It's controller-specific which options are changeable, and whether there's a better source of information. Most controllers don't seem to need this. I'd keep the definitions davinci specific for now. If there's enough of a common need, a common definition could be considered.

Quoted 5 lines

ecc_mode:
NAND_ECC_NONE
NAND_ECC_SOFT
NAND_ECC_HW
NAND_ECC_HW_SYNDROME

Quoted 2 lines

bbt_options:
NAND_BBT_USE_FLASH

Quoted 3 lines

ecc_bits:
1
4

Quoted 2 lines

options:
NAND_BUSWIDTH_16

Hello Scott,

Quoted 6 lines · Scott Wood

Quoted 5 lines · Heiko Schocher

ecc_mode:
NAND_ECC_NONE
NAND_ECC_SOFT
NAND_ECC_HW
NAND_ECC_HW_SYNDROME

"ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome"

Quoted 2 lines

Quoted 2 lines

bbt_options:
NAND_BBT_USE_FLASH

"ti,davinci-nand-bbt-options" = "use_flash"

Quoted 3 lines

Quoted 3 lines

ecc_bits:
1
4

"ti,davinci-nand-ecc-bits" = "1" or "4"

Quoted 2 lines

Quoted 2 lines

options:
NAND_BUSWIDTH_16

"ti,davinci-nand-options" = "buswidth-16"

- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support

Signed-off-by Heiko Schocher <[email protected]>

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-mtd at lists.infradead.org

Cc linux-i2c at vger.kernel.org

Cc netdev at vger.kernel.org

Cc David Woodhouse <[email protected]>

Cc Ben Dooks <[email protected]>

Cc Wolfram Sang <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Wolfgang Denk <[email protected]>

---
- post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC boards board specific callbacks, how to solve this with OF support?

 arch/arm/boot/dts/enbw_cmc.dts                  |  286 +++++++++++++++++
 arch/arm/configs/enbw_cmc_defconfig             |  125 ++++++++
 arch/arm/mach-davinci/Kconfig                   |    8 +
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-enbw-cmc.c          |  384 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 6 files changed, 805 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
 create mode 100644 arch/arm/configs/enbw_cmc_defconfig
 create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c

arch/arm/boot/dts/enbw_cmc.dts new file +26 -0

new file mode 100644
index 0000000..e5995ce
@@ -0,0 +1,286 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher <[email protected]>
+ *
+ * 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.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "EnBW CMC";
+	compatible = "enbw,cmc";
+
+	aliases {
+		ethernet0 = &eth0;
+	};
+
+	arm {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0xfffee000 0x00020000>;

arch/arm/mach-davinci/board-enbw-cmc.c new file +104 -0

new file mode 100644
index 0000000..4473c4a
@@ -0,0 +1,384 @@
+/*
+ * EnBW Communication Module Compact board
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Author: Heiko Schocher <[email protected]>
+ *
+ * based on:
+ * TI DA850/OMAP-L138 EVM board
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/console.h>
+#include <linux/gpio.h>
+#include <linux/gpio_keys.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/aemif.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/mux.h>
+#include <mach/nand.h>
+#include <mach/spi.h>
+
+#define ENBW_CMC_MMCSD_CD_PIN          GPIO_TO_PIN(3, 13)
+
+/*
+ * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8].
+ */
+#define DA850_USB_VBUS_PIN	GPIO_TO_PIN(7, 12)
+#define ON_BD_USB_OVC		GPIO_TO_PIN(7, 8)
+
+#if defined(CONFIG_USB_OHCI_HCD)
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id);
+static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler;
+
+static int enbw_cmc_usb_set_power(unsigned port, int on)
+{
+	gpio_set_value(DA850_USB_VBUS_PIN, on);
+	return 0;
+}
+
+static int enbw_cmc_usb_get_power(unsigned port)
+{
+	return gpio_get_value(DA850_USB_VBUS_PIN);
+}
+
+static int enbw_cmc_usb_get_oci(unsigned port)
+{
+	return !gpio_get_value(ON_BD_USB_OVC);
+}
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *);
+
+static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler)
+{
+	int irq         = gpio_to_irq(ON_BD_USB_OVC);
+	int error       = 0;
+
+	if (handler != NULL) {
+		enbw_cmc_usb_ocic_handler = handler;
+
+		error = request_irq(irq, enbw_cmc_usb_ocic_irq,
+					IRQF_DISABLED | IRQF_TRIGGER_RISING |
+					IRQF_TRIGGER_FALLING,
+					"OHCI over-current indicator", NULL);
+		if (error)
+			pr_err("%s: could not request IRQ to watch "
+				"over-current indicator changes\n", __func__);
+	} else {
+		free_irq(irq, NULL);
+	}
+	return error;
+}
+
+static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = {
+	.set_power      = enbw_cmc_usb_set_power,
+	.get_power      = enbw_cmc_usb_get_power,
+	.get_oci        = enbw_cmc_usb_get_oci,
+	.ocic_notify    = enbw_cmc_usb_ocic_notify,
+	.potpgt         = (10 + 1) / 2,  /* 10 ms max */
+};

Quoted 25 lines · Heiko Schocher

- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support

Signed-off-by Heiko Schocher <[email protected]>

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-mtd at lists.infradead.org

Cc linux-i2c at vger.kernel.org

Cc netdev at vger.kernel.org

Cc David Woodhouse <[email protected]>

Cc Ben Dooks <[email protected]>

Cc Wolfram Sang <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Wolfgang Denk <[email protected]>

Quoted 8 lines

---
- post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC boards board specific callbacks, how to solve this with OF support?

Quoted 50 lines

 arch/arm/boot/dts/enbw_cmc.dts                  |  286 +++++++++++++++++
 arch/arm/configs/enbw_cmc_defconfig             |  125 ++++++++
 arch/arm/mach-davinci/Kconfig                   |    8 +
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-enbw-cmc.c          |  384 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 6 files changed, 805 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
 create mode 100644 arch/arm/configs/enbw_cmc_defconfig
 create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c

arch/arm/boot/dts/enbw_cmc.dts new file +33 -0

new file mode 100644
index 0000000..e5995ce
@@ -0,0 +1,286 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher <[email protected]>
+ *
+ * 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.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "EnBW CMC";
+	compatible = "enbw,cmc";
+
+	aliases {
+		ethernet0 = &eth0;
+	};
+
+	arm {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0xfffee000 0x00020000>;
+		intc: interrupt-controller at 1 {
+			compatible = "ti,davinci-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			ti,intc-size = <101>;
+			reg = <0x0 0x2000>;
+		};

arch/arm/boot/dts/enbw_cmc.dts line 36

Quoted 3 lines

arch/arm/boot/dts/enbw_cmc.dts new file +3 -0

+	};
+	soc at 1c00000 {
+		compatible = "ti,da8xx";

As previously mentioned, using wildcard ('x') characters in compatible properties is bad practice. Always be specific and use the compatible list to make sure the correct driver gets bound (assuming the device is 100% register level compatible with the older one).

arch/arm/boot/dts/enbw_cmc.dts line 42

Quoted 6 lines

arch/arm/boot/dts/enbw_cmc.dts new file +6 -0

+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x01c00000 0x400000>;
+
+		serial0: serial at 1c42000 {
+			cell-index = <2>;

As previously mentioned, don't use cell index. If you *really* need to assign a number to a device, then use a property in the /aliases node and make sure pdev->id does *not* get modified.

arch/arm/boot/dts/enbw_cmc.dts line 43

Quoted 1 line

arch/arm/boot/dts/enbw_cmc.dts new file +1 -0

+			compatible = "ns16550a";

Should include a string for the specific device. Something like:

	compatible = "ti,da800", "ns16550a";

Quoted 6 lines

arch/arm/mach-davinci/board-enbw-cmc.c new file +0 -0

new file mode 100644
index 0000000..4473c4a
@@ -0,0 +1,384 @@

arch/arm/mach-davinci/board-enbw-cmc.c line 114

Quoted 2 lines

arch/arm/mach-davinci/board-enbw-cmc.c new file +2 -0

+#if defined(CONFIG_OF)
+static __init void enbw_cmc_usb_init(void)

All the focus is on DT now. How about making CONFIG_OF required for this board? Also, this is just another board file. The focus should

be on creating a generic board support file for DT platforms.

Quoted 34 lines · Heiko Schocher

Quoted 33 lines

- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support

Signed-off-by Heiko Schocher<[email protected]>

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-mtd at lists.infradead.org

Cc linux-i2c at vger.kernel.org

Cc netdev at vger.kernel.org

Cc David Woodhouse<[email protected]>

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Kevin Hilman<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
- post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC boards board specific callbacks, how to solve this with OF support?

Quoted 5 lines

Quoted 5 lines

arch/arm/boot/dts/enbw_cmc.dts new file +0 -0

new file mode 100644
index 0000000..e5995ce

Quoted 5 lines

arch/arm/boot/dts/enbw_cmc.dts

Quoted 1 line

arch/arm/boot/dts/enbw_cmc.dts new file +1 -0

+			compatible = "ns16550a";

Should include a string for the specific device. Something like:

	compatible = "ti,da800", "ns16550a";

added.

Hello.

Quoted 34 lines · Heiko Schocher

Quoted 34 lines · Heiko Schocher

Quoted 33 lines

- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support

Signed-off-by Heiko Schocher<[email protected]>

Cc linux-arm-kernel at lists.infradead.org

Cc devicetree-discuss at lists.ozlabs.org

Cc davinci-linux-open-source at linux.davincidsp.com

Cc linux-mtd at lists.infradead.org

Cc linux-i2c at vger.kernel.org

Cc netdev at vger.kernel.org

Cc David Woodhouse<[email protected]>

Cc Ben Dooks<[email protected]>

Cc Wolfram Sang<[email protected]>

Cc Sekhar Nori<[email protected]>

Cc Kevin Hilman<[email protected]>

Cc Wolfgang Denk<[email protected]>

---
- post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC boards board specific callbacks, how to solve this with OF support?

[...]

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

arch/arm/boot/dts/enbw_cmc.dts new file +0 -0

new file mode 100644
index 0000000..e5995ce

[...]

Quoted 3 lines

Quoted 3 lines

arch/arm/boot/dts/enbw_cmc.dts

Quoted 1 line

arch/arm/boot/dts/enbw_cmc.dts new file +1 -0

+			compatible = "ns16550a";

Should include a string for the specific device. Something like:

Quoted 3 lines

Quoted 1 line

	compatible = "ti,da800", "ns16550a";

added.

Note that there's no DA800 chip, only DA828, DA830, and DA850 AFAIK.