[PATCH 0/8] Various omap device tree usability fixes for v3.13 merge window

[PATCH 0/8] Various omap device tree usability fixes for v3.13 merge window

[Tony Lindgren]

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi all,

Here are some patches to fix various issue for device tree based
booting for omaps that I've ran into recently while working on
removing legacy platform data for mach-omap2.

Regards,

Tony


Tony Lindgren (8):
  net: smc91x: Fix device tree based configuration so it's usable
  mmc: omap: Fix DMA configuration to not rely on device id
  mmc: omap: Fix I2C dependency and make driver usable with device tree
  i2c: omap: Fix missing device tree flags for omap2
  gpio: twl4030: Fix regression for twl gpio output
  gpio: twl4030: Fix passing of pdata in the device tree case
  ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and
    smc91x
  ARM: dts: Fix omap2 specific dtsi files by adding the missing entries

 .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 +
 arch/arm/boot/dts/omap-zoom-common.dtsi            |  2 +-
 arch/arm/boot/dts/omap2.dtsi                       | 96 ++++++++++++++++++++++
 arch/arm/boot/dts/omap2420.dtsi                    | 23 ++++++
 arch/arm/boot/dts/omap2430.dtsi                    | 49 +++++++++++
 arch/arm/mach-omap2/gpmc.c                         | 58 +++++--------
 drivers/gpio/gpio-twl4030.c                        | 13 ++-
 drivers/i2c/busses/i2c-omap.c                      | 22 +++++
 drivers/mmc/host/omap.c                            | 42 +++++-----
 drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++---
 10 files changed, 285 insertions(+), 76 deletions(-)

-- 
1.8.1.1

[PATCH 0/8] Various omap device tree usability fixes for v3.13 merge window

[Tony Lindgren]

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi all,

Here are some patches to fix various issue for device tree based
booting for omaps that I've ran into recently while working on
removing legacy platform data for mach-omap2.

Regards,

Tony


Tony Lindgren (8):
  net: smc91x: Fix device tree based configuration so it's usable
  mmc: omap: Fix DMA configuration to not rely on device id
  mmc: omap: Fix I2C dependency and make driver usable with device tree
  i2c: omap: Fix missing device tree flags for omap2
  gpio: twl4030: Fix regression for twl gpio output
  gpio: twl4030: Fix passing of pdata in the device tree case
  ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and
    smc91x
  ARM: dts: Fix omap2 specific dtsi files by adding the missing entries

 .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 +
 arch/arm/boot/dts/omap-zoom-common.dtsi            |  2 +-
 arch/arm/boot/dts/omap2.dtsi                       | 96 ++++++++++++++++++++++
 arch/arm/boot/dts/omap2420.dtsi                    | 23 ++++++
 arch/arm/boot/dts/omap2430.dtsi                    | 49 +++++++++++
 arch/arm/mach-omap2/gpmc.c                         | 58 +++++--------
 drivers/gpio/gpio-twl4030.c                        | 13 ++-
 drivers/i2c/busses/i2c-omap.c                      | 22 +++++
 drivers/mmc/host/omap.c                            | 42 +++++-----
 drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++---
 10 files changed, 285 insertions(+), 76 deletions(-)

-- 
1.8.1.1

[PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.

Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.

Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 ++
 drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++++++++++-----
 2 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
index 953049b..53d69e3 100644
--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
 Optional properties:
 - phy-device : phandle to Ethernet phy
 - local-mac-address : Ethernet mac address to use
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+  should be performed on the device.  Valid value for SMSC LAN is
+  1, 2 or 4.  If it's omitted or invalid, the size would be 2.
+- smsc,nowait : Setup for fast register access with no waits
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 73be7f3..93d4b7d 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
 #include <linux/mii.h>
 #include <linux/workqueue.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
@@ -2189,6 +2190,15 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 	}
 }
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+	{ .compatible = "smsc,lan91c94", },
+	{ .compatible = "smsc,lan91c111", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
 /*
  * smc_init(void)
  *   Input parameters:
@@ -2203,6 +2213,8 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 static int smc_drv_probe(struct platform_device *pdev)
 {
 	struct smc91x_platdata *pd = dev_get_platdata(&pdev->dev);
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match = NULL;
 	struct smc_local *lp;
 	struct net_device *ndev;
 	struct resource *res, *ires;
@@ -2222,11 +2234,40 @@ static int smc_drv_probe(struct platform_device *pdev)
 	 */
 
 	lp = netdev_priv(ndev);
+	lp->cfg.flags = 0;
 
 	if (pd) {
 		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
 		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
-	} else {
+	}
+
+#if IS_BUILTIN(CONFIG_OF)
+	match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
+	if (match) {
+		u32 val;
+
+		of_property_read_u32(np, "reg-io-width", &val);
+		switch (val) {
+		case 1:
+			lp->cfg.flags |= SMC91X_USE_8BIT;
+			break;
+		case 2:
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+			break;
+		case 4:
+			lp->cfg.flags |= SMC91X_USE_32BIT;
+			break;
+		default:
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+			break;
+		}
+
+		if (of_get_property(np, "smsc,nowait", NULL))
+			lp->cfg.flags |= SMC91X_NOWAIT;
+	}
+#endif
+
+	if (!pd && !match) {
 		lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2375,15 +2416,6 @@ static int smc_drv_resume(struct device *dev)
 	return 0;
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
-	{ .compatible = "smsc,lan91c94", },
-	{ .compatible = "smsc,lan91c111", },
-	{},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
 static struct dev_pm_ops smc_drv_pm_ops = {
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,
-- 
1.8.1.1

[PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.

Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.

Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev at vger.kernel.org
Cc: devicetree at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 ++
 drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++++++++++-----
 2 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
index 953049b..53d69e3 100644
--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
 Optional properties:
 - phy-device : phandle to Ethernet phy
 - local-mac-address : Ethernet mac address to use
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+  should be performed on the device.  Valid value for SMSC LAN is
+  1, 2 or 4.  If it's omitted or invalid, the size would be 2.
+- smsc,nowait : Setup for fast register access with no waits
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 73be7f3..93d4b7d 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
 #include <linux/mii.h>
 #include <linux/workqueue.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
@@ -2189,6 +2190,15 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 	}
 }
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+	{ .compatible = "smsc,lan91c94", },
+	{ .compatible = "smsc,lan91c111", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
 /*
  * smc_init(void)
  *   Input parameters:
@@ -2203,6 +2213,8 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 static int smc_drv_probe(struct platform_device *pdev)
 {
 	struct smc91x_platdata *pd = dev_get_platdata(&pdev->dev);
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match = NULL;
 	struct smc_local *lp;
 	struct net_device *ndev;
 	struct resource *res, *ires;
@@ -2222,11 +2234,40 @@ static int smc_drv_probe(struct platform_device *pdev)
 	 */
 
 	lp = netdev_priv(ndev);
+	lp->cfg.flags = 0;
 
 	if (pd) {
 		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
 		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
-	} else {
+	}
+
+#if IS_BUILTIN(CONFIG_OF)
+	match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
+	if (match) {
+		u32 val;
+
+		of_property_read_u32(np, "reg-io-width", &val);
+		switch (val) {
+		case 1:
+			lp->cfg.flags |= SMC91X_USE_8BIT;
+			break;
+		case 2:
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+			break;
+		case 4:
+			lp->cfg.flags |= SMC91X_USE_32BIT;
+			break;
+		default:
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+			break;
+		}
+
+		if (of_get_property(np, "smsc,nowait", NULL))
+			lp->cfg.flags |= SMC91X_NOWAIT;
+	}
+#endif
+
+	if (!pd && !match) {
 		lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2375,15 +2416,6 @@ static int smc_drv_resume(struct device *dev)
 	return 0;
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
-	{ .compatible = "smsc,lan91c94", },
-	{ .compatible = "smsc,lan91c111", },
-	{},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
 static struct dev_pm_ops smc_drv_pm_ops = {
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,
-- 
1.8.1.1

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

We are wrongly relying on device id for the DMA configuration
which can lead to wrong DMA channel being selected.

Fix the issue by using the standard resources like we should.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---

 drivers/mmc/host/omap.c | 32 +++++++++++---------------------
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index b94f38e..ed56868 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -90,17 +90,6 @@
 #define OMAP_MMC_CMDTYPE_AC	2
 #define OMAP_MMC_CMDTYPE_ADTC	3
 
-#define OMAP_DMA_MMC_TX		21
-#define OMAP_DMA_MMC_RX		22
-#define OMAP_DMA_MMC2_TX	54
-#define OMAP_DMA_MMC2_RX	55
-
-#define OMAP24XX_DMA_MMC2_TX	47
-#define OMAP24XX_DMA_MMC2_RX	48
-#define OMAP24XX_DMA_MMC1_TX	61
-#define OMAP24XX_DMA_MMC1_RX	62
-
-
 #define DRIVER_NAME "mmci-omap"
 
 /* Specifies how often in millisecs to poll for card status changes
@@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	host->dma_tx_burst = -1;
 	host->dma_rx_burst = -1;
 
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
-	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+	if (res)
+		sig = res->start;
+	host->dma_tx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "tx");
 	if (!host->dma_tx)
 		dev_warn(host->dev, "unable to obtain TX DMA engine channel %u\n",
 			sig);
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_RX : OMAP24XX_DMA_MMC2_RX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_RX : OMAP_DMA_MMC2_RX;
-	host->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+	if (res)
+		sig = res->start;
+	host->dma_rx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "rx");
 	if (!host->dma_rx)
 		dev_warn(host->dev, "unable to obtain RX DMA engine channel %u\n",
 			sig);
-- 
1.8.1.1

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

We are wrongly relying on device id for the DMA configuration
which can lead to wrong DMA channel being selected.

Fix the issue by using the standard resources like we should.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---

 drivers/mmc/host/omap.c | 32 +++++++++++---------------------
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index b94f38e..ed56868 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -90,17 +90,6 @@
 #define OMAP_MMC_CMDTYPE_AC	2
 #define OMAP_MMC_CMDTYPE_ADTC	3
 
-#define OMAP_DMA_MMC_TX		21
-#define OMAP_DMA_MMC_RX		22
-#define OMAP_DMA_MMC2_TX	54
-#define OMAP_DMA_MMC2_RX	55
-
-#define OMAP24XX_DMA_MMC2_TX	47
-#define OMAP24XX_DMA_MMC2_RX	48
-#define OMAP24XX_DMA_MMC1_TX	61
-#define OMAP24XX_DMA_MMC1_RX	62
-
-
 #define DRIVER_NAME "mmci-omap"
 
 /* Specifies how often in millisecs to poll for card status changes
@@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	host->dma_tx_burst = -1;
 	host->dma_rx_burst = -1;
 
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
-	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+	if (res)
+		sig = res->start;
+	host->dma_tx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "tx");
 	if (!host->dma_tx)
 		dev_warn(host->dev, "unable to obtain TX DMA engine channel %u\n",
 			sig);
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_RX : OMAP24XX_DMA_MMC2_RX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_RX : OMAP_DMA_MMC2_RX;
-	host->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+	if (res)
+		sig = res->start;
+	host->dma_rx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "rx");
 	if (!host->dma_rx)
 		dev_warn(host->dev, "unable to obtain RX DMA engine channel %u\n",
 			sig);
-- 
1.8.1.1

[PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Tony Lindgren]

Some features can be configured by the companion I2C chips,
which may not be available at the probe time. Fix the issue
by returning -EPROBE_DEFER when the MMC controller slots
are not configured.

While at it, let's also add minimal device tree support so
omap24xx platforms can use this driver without legacy mode
since we claim to support device tree for mach-omap2 based
systems.

Although adding the minimal device tree support is not strictly
a fix, it does remove one of the last blockers for dropping a
bunch of legacy platform data for mach-omap2.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/mmc/host/omap.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index ed56868..43c66ad 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -22,6 +22,7 @@
 #include <linux/delay.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
+#include <linux/of.h>
 #include <linux/omap-dma.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
@@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	}
 	if (pdata->nr_slots == 0) {
 		dev_err(&pdev->dev, "no slots\n");
-		return -ENXIO;
+		return -EPROBE_DEFER;
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
 #define mmc_omap_resume		NULL
 #endif
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id mmc_omap_match[] = {
+	{ .compatible = "ti,omap2420-mmc", },
+	{ },
+};
+#endif
 static struct platform_driver mmc_omap_driver = {
 	.probe		= mmc_omap_probe,
 	.remove		= mmc_omap_remove,
@@ -1561,6 +1568,7 @@ static struct platform_driver mmc_omap_driver = {
 	.driver		= {
 		.name	= DRIVER_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(mmc_omap_match),
 	},
 };
 
-- 
1.8.1.1

[PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Tony Lindgren]

Some features can be configured by the companion I2C chips,
which may not be available at the probe time. Fix the issue
by returning -EPROBE_DEFER when the MMC controller slots
are not configured.

While at it, let's also add minimal device tree support so
omap24xx platforms can use this driver without legacy mode
since we claim to support device tree for mach-omap2 based
systems.

Although adding the minimal device tree support is not strictly
a fix, it does remove one of the last blockers for dropping a
bunch of legacy platform data for mach-omap2.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/mmc/host/omap.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index ed56868..43c66ad 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -22,6 +22,7 @@
 #include <linux/delay.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
+#include <linux/of.h>
 #include <linux/omap-dma.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
@@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	}
 	if (pdata->nr_slots == 0) {
 		dev_err(&pdev->dev, "no slots\n");
-		return -ENXIO;
+		return -EPROBE_DEFER;
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
 #define mmc_omap_resume		NULL
 #endif
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id mmc_omap_match[] = {
+	{ .compatible = "ti,omap2420-mmc", },
+	{ },
+};
+#endif
 static struct platform_driver mmc_omap_driver = {
 	.probe		= mmc_omap_probe,
 	.remove		= mmc_omap_remove,
@@ -1561,6 +1568,7 @@ static struct platform_driver mmc_omap_driver = {
 	.driver		= {
 		.name	= DRIVER_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(mmc_omap_match),
 	},
 };
 
-- 
1.8.1.1

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.

Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9967a6f..f04afd1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
 };
 
 #ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_NO_FIFO |
+			OMAP_I2C_FLAG_SIMPLE_CLOCK |
+			OMAP_I2C_FLAG_16BIT_DATA_REG |
+			OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+			OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
 static struct omap_i2c_bus_platform_data omap3_pdata = {
 	.rev = OMAP_I2C_IP_VERSION_1,
 	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
 		.compatible = "ti,omap3-i2c",
 		.data = &omap3_pdata,
 	},
+	{
+		.compatible = "ti,omap2430-i2c",
+		.data = &omap2430_pdata,
+	},
+	{
+		.compatible = "ti,omap2420-i2c",
+		.data = &omap2420_pdata,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
-- 
1.8.1.1

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.

Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9967a6f..f04afd1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
 };
 
 #ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_NO_FIFO |
+			OMAP_I2C_FLAG_SIMPLE_CLOCK |
+			OMAP_I2C_FLAG_16BIT_DATA_REG |
+			OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+			OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
 static struct omap_i2c_bus_platform_data omap3_pdata = {
 	.rev = OMAP_I2C_IP_VERSION_1,
 	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
 		.compatible = "ti,omap3-i2c",
 		.data = &omap3_pdata,
 	},
+	{
+		.compatible = "ti,omap2430-i2c",
+		.data = &omap2430_pdata,
+	},
+	{
+		.compatible = "ti,omap2420-i2c",
+		.data = &omap2420_pdata,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
-- 
1.8.1.1

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
states in private data) improved things in general, but caused a
regression for setting the GPIO output direction.

The change reorganized twl_direction_out() and twl_set() and swapped
the function names around in the process. While doing that, a bug got
introduced that's not obvious while reading the patch as it appears
as no change to the code.

The bug is we now call function twl4030_set_gpio_dataout() twice in
both twl_direction_out() and twl_set(). Instead, we should first
call twl_direction_out() in twl_direction_out() followed by
twl4030_set_gpio_dataout() in twl_set().

This regression probably has gone unnoticed for a long time as the
bootloader may have set the GPIO direction properly in many cases.
This fixes at least the LCD panel not turning on omap3 LDP for
example.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/gpio/gpio-twl4030.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 0c7e891..5738d5a 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
 static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
 	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+	int ret = -EINVAL;
 
 	mutex_lock(&priv->mutex);
 	if (offset < TWL4030_GPIO_MAX)
-		twl4030_set_gpio_dataout(offset, value);
+		ret = twl4030_set_gpio_direction(offset, 0);
 
 	priv->direction |= BIT(offset);
 	mutex_unlock(&priv->mutex);
 
 	twl_set(chip, offset, value);
 
-	return 0;
+	return ret;
 }
 
 static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
-- 
1.8.1.1

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
states in private data) improved things in general, but caused a
regression for setting the GPIO output direction.

The change reorganized twl_direction_out() and twl_set() and swapped
the function names around in the process. While doing that, a bug got
introduced that's not obvious while reading the patch as it appears
as no change to the code.

The bug is we now call function twl4030_set_gpio_dataout() twice in
both twl_direction_out() and twl_set(). Instead, we should first
call twl_direction_out() in twl_direction_out() followed by
twl4030_set_gpio_dataout() in twl_set().

This regression probably has gone unnoticed for a long time as the
bootloader may have set the GPIO direction properly in many cases.
This fixes at least the LCD panel not turning on omap3 LDP for
example.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: linux-gpio at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/gpio/gpio-twl4030.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 0c7e891..5738d5a 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
 static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
 	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+	int ret = -EINVAL;
 
 	mutex_lock(&priv->mutex);
 	if (offset < TWL4030_GPIO_MAX)
-		twl4030_set_gpio_dataout(offset, value);
+		ret = twl4030_set_gpio_direction(offset, 0);
 
 	priv->direction |= BIT(offset);
 	mutex_unlock(&priv->mutex);
 
 	twl_set(chip, offset, value);
 
-	return 0;
+	return ret;
 }
 
 static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
-- 
1.8.1.1

[PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case

[Tony Lindgren]

We still have some legacy code needing the callback functions
that won't work properly without platform data. To use platform
data for twl4030-gpio, we need to not trash the possible data.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/gpio/gpio-twl4030.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 5738d5a..e6ecbe3 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -436,7 +436,8 @@ static int gpio_twl4030_debounce(u32 debounce, u8 mmc_cd)
 
 static int gpio_twl4030_remove(struct platform_device *pdev);
 
-static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev,
+				struct twl4030_gpio_platform_data *pdata)
 {
 	struct twl4030_gpio_platform_data *omap_twl_info;
 
@@ -444,6 +445,9 @@ static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
 	if (!omap_twl_info)
 		return NULL;
 
+	if (pdata)
+		memcpy(omap_twl_info, pdata, sizeof(*omap_twl_info));
+
 	omap_twl_info->use_leds = of_property_read_bool(dev->of_node,
 			"ti,use-leds");
 
@@ -501,7 +505,7 @@ no_irqs:
 	mutex_init(&priv->mutex);
 
 	if (node)
-		pdata = of_gpio_twl4030(&pdev->dev);
+		pdata = of_gpio_twl4030(&pdev->dev, pdata);
 
 	if (pdata == NULL) {
 		dev_err(&pdev->dev, "Platform data is missing\n");
-- 
1.8.1.1

[PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case

[Tony Lindgren]

We still have some legacy code needing the callback functions
that won't work properly without platform data. To use platform
data for twl4030-gpio, we need to not trash the possible data.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.

---
 drivers/gpio/gpio-twl4030.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 5738d5a..e6ecbe3 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -436,7 +436,8 @@ static int gpio_twl4030_debounce(u32 debounce, u8 mmc_cd)
 
 static int gpio_twl4030_remove(struct platform_device *pdev);
 
-static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev,
+				struct twl4030_gpio_platform_data *pdata)
 {
 	struct twl4030_gpio_platform_data *omap_twl_info;
 
@@ -444,6 +445,9 @@ static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
 	if (!omap_twl_info)
 		return NULL;
 
+	if (pdata)
+		memcpy(omap_twl_info, pdata, sizeof(*omap_twl_info));
+
 	omap_twl_info->use_leds = of_property_read_bool(dev->of_node,
 			"ti,use-leds");
 
@@ -501,7 +505,7 @@ no_irqs:
 	mutex_init(&priv->mutex);
 
 	if (node)
-		pdata = of_gpio_twl4030(&pdev->dev);
+		pdata = of_gpio_twl4030(&pdev->dev, pdata);
 
 	if (pdata == NULL) {
 		dev_err(&pdev->dev, "Platform data is missing\n");
-- 
1.8.1.1

[PATCH 7/8] ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x

[Tony Lindgren]

Commit f2bf0e72d000 (ARM: OMAP2+: Add minimal 8250 support
for GPMC) added support for using bootloader timings for some
devices. Turns out we can do the same by looking at the compatible
flags of the child without adding a new function as smc91x has
a similar issue as 8250 with the bootloader timings.

And let's fix the 8250 naming, we should use the device type as
the name like uart instead of 8250 for zoom dts file.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap-zoom-common.dtsi |  2 +-
 arch/arm/mach-omap2/gpmc.c              | 58 +++++++++++----------------------
 2 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/omap-zoom-common.dtsi b/arch/arm/boot/dts/omap-zoom-common.dtsi
index b0ee342..68221fa 100644
--- a/arch/arm/boot/dts/omap-zoom-common.dtsi
+++ b/arch/arm/boot/dts/omap-zoom-common.dtsi
@@ -13,7 +13,7 @@
 	 * they probably share the same GPIO IRQ
 	 * REVISIT: Add timing support from slls644g.pdf
 	 */
-	8250@3,0 {
+	uart@3,0 {
 		compatible = "ns16550a";
 		reg = <3 0 0x100>;
 		bank-width = <2>;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 51525fa..e09e5ba 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1482,6 +1482,22 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 	}
 
 	/*
+	 * For some GPMC devices we still need to rely on the bootloader
+	 * timings because the devices can be connected via FPGA. So far
+	 * the list is smc91x on the omap2 SDP boards, and 8250 on zooms.
+	 * REVISIT: Add timing support from slls644g.pdf and from the
+	 * lan91c96 manual.
+	 */
+	if (of_device_is_compatible(child, "ns16550a") ||
+	    of_device_is_compatible(child, "smsc,lan91c94") ||
+	    of_device_is_compatible(child, "smsc,lan91c111")) {
+		dev_warn(&pdev->dev,
+			 "%s using bootloader timings on CS%d\n",
+			 child->name, cs);
+		goto no_timings;
+	}
+
+	/*
 	 * FIXME: gpmc_cs_request() will map the CS to an arbitary
 	 * location in the gpmc address space. When booting with
 	 * device-tree we want the NOR flash to be mapped to the
@@ -1509,6 +1525,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 	gpmc_read_timings_dt(child, &gpmc_t);
 	gpmc_cs_set_timings(cs, &gpmc_t);
 
+no_timings:
 	if (of_platform_device_create(child, NULL, &pdev->dev))
 		return 0;
 
@@ -1521,42 +1538,6 @@ err:
 	return ret;
 }
 
-/*
- * REVISIT: Add timing support from slls644g.pdf
- */
-static int gpmc_probe_8250(struct platform_device *pdev,
-				struct device_node *child)
-{
-	struct resource res;
-	unsigned long base;
-	int ret, cs;
-
-	if (of_property_read_u32(child, "reg", &cs) < 0) {
-		dev_err(&pdev->dev, "%s has no 'reg' property\n",
-			child->full_name);
-		return -ENODEV;
-	}
-
-	if (of_address_to_resource(child, 0, &res) < 0) {
-		dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
-			child->full_name);
-		return -ENODEV;
-	}
-
-	ret = gpmc_cs_request(cs, resource_size(&res), &base);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "cannot request GPMC CS %d\n", cs);
-		return ret;
-	}
-
-	if (of_platform_device_create(child, NULL, &pdev->dev))
-		return 0;
-
-	dev_err(&pdev->dev, "failed to create gpmc child %s\n", child->name);
-
-	return -ENODEV;
-}
-
 static int gpmc_probe_dt(struct platform_device *pdev)
 {
 	int ret;
@@ -1598,10 +1579,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 		else if (of_node_cmp(child->name, "onenand") == 0)
 			ret = gpmc_probe_onenand_child(pdev, child);
 		else if (of_node_cmp(child->name, "ethernet") == 0 ||
-			 of_node_cmp(child->name, "nor") == 0)
+			 of_node_cmp(child->name, "nor") == 0 ||
+			 of_node_cmp(child->name, "uart") == 0)
 			ret = gpmc_probe_generic_child(pdev, child);
-		else if (of_node_cmp(child->name, "8250") == 0)
-			ret = gpmc_probe_8250(pdev, child);
 
 		if (WARN(ret < 0, "%s: probing gpmc child %s failed\n",
 			 __func__, child->full_name))
-- 
1.8.1.1

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

[PATCH 7/8] ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x

[Tony Lindgren]

Commit f2bf0e72d000 (ARM: OMAP2+: Add minimal 8250 support
for GPMC) added support for using bootloader timings for some
devices. Turns out we can do the same by looking at the compatible
flags of the child without adding a new function as smc91x has
a similar issue as 8250 with the bootloader timings.

And let's fix the 8250 naming, we should use the device type as
the name like uart instead of 8250 for zoom dts file.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap-zoom-common.dtsi |  2 +-
 arch/arm/mach-omap2/gpmc.c              | 58 +++++++++++----------------------
 2 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/omap-zoom-common.dtsi b/arch/arm/boot/dts/omap-zoom-common.dtsi
index b0ee342..68221fa 100644
--- a/arch/arm/boot/dts/omap-zoom-common.dtsi
+++ b/arch/arm/boot/dts/omap-zoom-common.dtsi
@@ -13,7 +13,7 @@
 	 * they probably share the same GPIO IRQ
 	 * REVISIT: Add timing support from slls644g.pdf
 	 */
-	8250 at 3,0 {
+	uart at 3,0 {
 		compatible = "ns16550a";
 		reg = <3 0 0x100>;
 		bank-width = <2>;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 51525fa..e09e5ba 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1482,6 +1482,22 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 	}
 
 	/*
+	 * For some GPMC devices we still need to rely on the bootloader
+	 * timings because the devices can be connected via FPGA. So far
+	 * the list is smc91x on the omap2 SDP boards, and 8250 on zooms.
+	 * REVISIT: Add timing support from slls644g.pdf and from the
+	 * lan91c96 manual.
+	 */
+	if (of_device_is_compatible(child, "ns16550a") ||
+	    of_device_is_compatible(child, "smsc,lan91c94") ||
+	    of_device_is_compatible(child, "smsc,lan91c111")) {
+		dev_warn(&pdev->dev,
+			 "%s using bootloader timings on CS%d\n",
+			 child->name, cs);
+		goto no_timings;
+	}
+
+	/*
 	 * FIXME: gpmc_cs_request() will map the CS to an arbitary
 	 * location in the gpmc address space. When booting with
 	 * device-tree we want the NOR flash to be mapped to the
@@ -1509,6 +1525,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 	gpmc_read_timings_dt(child, &gpmc_t);
 	gpmc_cs_set_timings(cs, &gpmc_t);
 
+no_timings:
 	if (of_platform_device_create(child, NULL, &pdev->dev))
 		return 0;
 
@@ -1521,42 +1538,6 @@ err:
 	return ret;
 }
 
-/*
- * REVISIT: Add timing support from slls644g.pdf
- */
-static int gpmc_probe_8250(struct platform_device *pdev,
-				struct device_node *child)
-{
-	struct resource res;
-	unsigned long base;
-	int ret, cs;
-
-	if (of_property_read_u32(child, "reg", &cs) < 0) {
-		dev_err(&pdev->dev, "%s has no 'reg' property\n",
-			child->full_name);
-		return -ENODEV;
-	}
-
-	if (of_address_to_resource(child, 0, &res) < 0) {
-		dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
-			child->full_name);
-		return -ENODEV;
-	}
-
-	ret = gpmc_cs_request(cs, resource_size(&res), &base);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "cannot request GPMC CS %d\n", cs);
-		return ret;
-	}
-
-	if (of_platform_device_create(child, NULL, &pdev->dev))
-		return 0;
-
-	dev_err(&pdev->dev, "failed to create gpmc child %s\n", child->name);
-
-	return -ENODEV;
-}
-
 static int gpmc_probe_dt(struct platform_device *pdev)
 {
 	int ret;
@@ -1598,10 +1579,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 		else if (of_node_cmp(child->name, "onenand") == 0)
 			ret = gpmc_probe_onenand_child(pdev, child);
 		else if (of_node_cmp(child->name, "ethernet") == 0 ||
-			 of_node_cmp(child->name, "nor") == 0)
+			 of_node_cmp(child->name, "nor") == 0 ||
+			 of_node_cmp(child->name, "uart") == 0)
 			ret = gpmc_probe_generic_child(pdev, child);
-		else if (of_node_cmp(child->name, "8250") == 0)
-			ret = gpmc_probe_8250(pdev, child);
 
 		if (WARN(ret < 0, "%s: probing gpmc child %s failed\n",
 			 __func__, child->full_name))
-- 
1.8.1.1

[PATCH 8/8] ARM: dts: Fix omap2 specific dtsi files by adding the missing entries

[Tony Lindgren]

Looks like we're missing few entries for omap2 and the drivers
have only worked because of the omap hwmod building the devices
for the missing entries.

Let's fix the missing entries so we don't need to rely on hwmod
for the basic data and can then later on remove the duplicate
data from hwmod. Otherwise device tree only drivers will not
work properly.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap2.dtsi    | 96 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap2420.dtsi | 23 ++++++++++
 arch/arm/boot/dts/omap2430.dtsi | 49 +++++++++++++++++++++
 3 files changed, 168 insertions(+)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index a2bfcde..d0c5b37 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -9,6 +9,7 @@
  */
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/pinctrl/omap.h>
 
 #include "skeleton.dtsi"
@@ -21,6 +22,8 @@
 		serial0 = &uart1;
 		serial1 = &uart2;
 		serial2 = &uart3;
+		i2c0 = &i2c1;
+		i2c1 = &i2c2;
 	};
 
 	cpus {
@@ -53,6 +56,28 @@
 		ranges;
 		ti,hwmods = "l3_main";
 
+		aes: aes@480a6000 {
+			compatible = "ti,omap2-aes";
+			ti,hwmods = "aes";
+			reg = <0x480a6000 0x50>;
+			dmas = <&sdma 9 &sdma 10>;
+			dma-names = "tx", "rx";
+		};
+
+		hdq1w: 1w@480b2000 {
+			compatible = "ti,omap2420-1w";
+			ti,hwmods = "hdq1w";
+			reg = <0x480b2000 0x1000>;
+			interrupts = <58>;
+		};
+
+		mailbox: mailbox@48094000 {
+			compatible = "ti,omap2-mailbox";
+			ti,hwmods = "mailbox";
+			reg = <0x48094000 0x200>;
+			interrupts = <26>;
+		};
+
 		intc: interrupt-controller@1 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
@@ -63,6 +88,7 @@
 
 		sdma: dma-controller@48056000 {
 			compatible = "ti,omap2430-sdma", "ti,omap2420-sdma";
+			ti,hwmods = "dma";
 			reg = <0x48056000 0x1000>;
 			interrupts = <12>,
 				     <13>,
@@ -73,21 +99,91 @@
 			#dma-requests = <64>;
 		};
 
+		i2c1: i2c@48070000 {
+			compatible = "ti,omap2-i2c";
+			ti,hwmods = "i2c1";
+			reg = <0x48070000 0x80>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <56>;
+			dmas = <&sdma 27 &sdma 28>;
+			dma-names = "tx", "rx";
+		};
+
+		i2c2: i2c@48072000 {
+			compatible = "ti,omap2-i2c";
+			ti,hwmods = "i2c2";
+			reg = <0x48072000 0x80>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <57>;
+			dmas = <&sdma 29 &sdma 30>;
+			dma-names = "tx", "rx";
+		};
+
+		mcspi1: mcspi@48098000 {
+			compatible = "ti,omap2-mcspi";
+			ti,hwmods = "mcspi1";
+			reg = <0x48098000 0x100>;
+			interrupts = <65>;
+			dmas = <&sdma 35 &sdma 36 &sdma 37 &sdma 38
+				&sdma 39 &sdma 40 &sdma 41 &sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
+		};
+
+		mcspi2: mcspi@4809a000 {
+			compatible = "ti,omap2-mcspi";
+			ti,hwmods = "mcspi2";
+			reg = <0x4809a000 0x100>;
+			interrupts = <66>;
+			dmas = <&sdma 43 &sdma 44 &sdma 45 &sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		rng: rng@480a0000 {
+			compatible = "ti,omap2-rng";
+			ti,hwmods = "rng";
+			reg = <0x480a0000 0x50>;
+			interrupts = <36>;
+		};
+
+		sham: sham@480a4000 {
+			compatible = "ti,omap2-sham";
+			ti,hwmods = "sham";
+			reg = <0x480a4000 0x64>;
+			interrupts = <51>;
+			dmas = <&sdma 13>;
+			dma-names = "rx";
+		};
+
 		uart1: serial@4806a000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart1";
+			reg = <0x4806a000 0x2000>;
+			interrupts = <72>;
+			dmas = <&sdma 49 &sdma 50>;
+			dma-names = "tx", "rx";
 			clock-frequency = <48000000>;
 		};
 
 		uart2: serial@4806c000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart2";
+			reg = <0x4806c000 0x400>;
+			interrupts = <73>;
+			dmas = <&sdma 51 &sdma 52>;
+			dma-names = "tx", "rx";
 			clock-frequency = <48000000>;
 		};
 
 		uart3: serial@4806e000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart3";
+			reg = <0x4806e000 0x400>;
+			interrupts = <74>;
+			dmas = <&sdma 53 &sdma 54>;
+			dma-names = "tx", "rx";
 			clock-frequency = <48000000>;
 		};
 
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index c8f9c55..60c605d 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -114,6 +114,15 @@
 			dma-names = "tx", "rx";
 		};
 
+		msdi1: mmc@4809c000 {
+			compatible = "ti,omap2420-mmc";
+			ti,hwmods = "msdi1";
+			reg = <0x4809c000 0x80>;
+			interrupts = <83>;
+			dmas = <&sdma 61 &sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
 		timer1: timer@48028000 {
 			compatible = "ti,omap2420-timer";
 			reg = <0x48028000 0x400>;
@@ -121,5 +130,19 @@
 			ti,hwmods = "timer1";
 			ti,timer-alwon;
 		};
+
+		wd_timer2: wdt@48022000 {
+			compatible = "ti,omap2-wdt";
+			ti,hwmods = "wd_timer2";
+			reg = <0x48022000 0x80>;
+		};
 	};
 };
+
+&i2c1 {
+	compatible = "ti,omap2420-i2c";
+};
+
+&i2c2 {
+	compatible = "ti,omap2420-i2c";
+};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c535a5a..d624345 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -175,6 +175,25 @@
 			dma-names = "tx", "rx";
 		};
 
+		mmc1: mmc@4809c000 {
+			compatible = "ti,omap2-hsmmc";
+			reg = <0x4809c000 0x200>;
+			interrupts = <83>;
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc2: mmc@480b4000 {
+			compatible = "ti,omap2-hsmmc";
+			reg = <0x480b4000 0x200>;
+			interrupts = <86>;
+			ti,hwmods = "mmc2";
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
+		};
+
 		timer1: timer@49018000 {
 			compatible = "ti,omap2420-timer";
 			reg = <0x49018000 0x400>;
@@ -182,5 +201,35 @@
 			ti,hwmods = "timer1";
 			ti,timer-alwon;
 		};
+
+		mcspi3: mcspi@480b8000 {
+			compatible = "ti,omap2-mcspi";
+			ti,hwmods = "mcspi3";
+			reg = <0x480b8000 0x100>;
+			interrupts = <91>;
+			dmas = <&sdma 15 &sdma 16 &sdma 23 &sdma 24>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		usb_otg_hs: usb_otg_hs@480ac000 {
+			compatible = "ti,omap2-musb";
+			ti,hwmods = "usb_otg_hs";
+			reg = <0x480ac000 0x1000>;
+			interrupts = <93>;
+		};
+
+		wd_timer2: wdt@49016000 {
+			compatible = "ti,omap2-wdt";
+			ti,hwmods = "wd_timer2";
+			reg = <0x49016000 0x80>;
+		};
 	};
 };
+
+&i2c1 {
+	compatible = "ti,omap2430-i2c";
+};
+
+&i2c2 {
+	compatible = "ti,omap2430-i2c";
+};
-- 
1.8.1.1

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

[PATCH 8/8] ARM: dts: Fix omap2 specific dtsi files by adding the missing entries

[Tony Lindgren]

Looks like we're missing few entries for omap2 and the drivers
have only worked because of the omap hwmod building the devices
for the missing entries.

Let's fix the missing entries so we don't need to rely on hwmod
for the basic data and can then later on remove the duplicate
data from hwmod. Otherwise device tree only drivers will not
work properly.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap2.dtsi    | 96 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap2420.dtsi | 23 ++++++++++
 arch/arm/boot/dts/omap2430.dtsi | 49 +++++++++++++++++++++
 3 files changed, 168 insertions(+)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index a2bfcde..d0c5b37 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -9,6 +9,7 @@
  */
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/pinctrl/omap.h>
 
 #include "skeleton.dtsi"
@@ -21,6 +22,8 @@
 		serial0 = &uart1;
 		serial1 = &uart2;
 		serial2 = &uart3;
+		i2c0 = &i2c1;
+		i2c1 = &i2c2;
 	};
 
 	cpus {
@@ -53,6 +56,28 @@
 		ranges;
 		ti,hwmods = "l3_main";
 
+		aes: aes at 480a6000 {
+			compatible = "ti,omap2-aes";
+			ti,hwmods = "aes";
+			reg = <0x480a6000 0x50>;
+			dmas = <&sdma 9 &sdma 10>;
+			dma-names = "tx", "rx";
+		};
+
+		hdq1w: 1w at 480b2000 {
+			compatible = "ti,omap2420-1w";
+			ti,hwmods = "hdq1w";
+			reg = <0x480b2000 0x1000>;
+			interrupts = <58>;
+		};
+
+		mailbox: mailbox at 48094000 {
+			compatible = "ti,omap2-mailbox";
+			ti,hwmods = "mailbox";
+			reg = <0x48094000 0x200>;
+			interrupts = <26>;
+		};
+
 		intc: interrupt-controller at 1 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
@@ -63,6 +88,7 @@
 
 		sdma: dma-controller at 48056000 {
 			compatible = "ti,omap2430-sdma", "ti,omap2420-sdma";
+			ti,hwmods = "dma";
 			reg = <0x48056000 0x1000>;
 			interrupts = <12>,
 				     <13>,
@@ -73,21 +99,91 @@
 			#dma-requests = <64>;
 		};
 
+		i2c1: i2c at 48070000 {
+			compatible = "ti,omap2-i2c";
+			ti,hwmods = "i2c1";
+			reg = <0x48070000 0x80>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <56>;
+			dmas = <&sdma 27 &sdma 28>;
+			dma-names = "tx", "rx";
+		};
+
+		i2c2: i2c at 48072000 {
+			compatible = "ti,omap2-i2c";
+			ti,hwmods = "i2c2";
+			reg = <0x48072000 0x80>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <57>;
+			dmas = <&sdma 29 &sdma 30>;
+			dma-names = "tx", "rx";
+		};
+
+		mcspi1: mcspi at 48098000 {
+			compatible = "ti,omap2-mcspi";
+			ti,hwmods = "mcspi1";
+			reg = <0x48098000 0x100>;
+			interrupts = <65>;
+			dmas = <&sdma 35 &sdma 36 &sdma 37 &sdma 38
+				&sdma 39 &sdma 40 &sdma 41 &sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
+		};
+
+		mcspi2: mcspi at 4809a000 {
+			compatible = "ti,omap2-mcspi";
+			ti,hwmods = "mcspi2";
+			reg = <0x4809a000 0x100>;
+			interrupts = <66>;
+			dmas = <&sdma 43 &sdma 44 &sdma 45 &sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		rng: rng at 480a0000 {
+			compatible = "ti,omap2-rng";
+			ti,hwmods = "rng";
+			reg = <0x480a0000 0x50>;
+			interrupts = <36>;
+		};
+
+		sham: sham at 480a4000 {
+			compatible = "ti,omap2-sham";
+			ti,hwmods = "sham";
+			reg = <0x480a4000 0x64>;
+			interrupts = <51>;
+			dmas = <&sdma 13>;
+			dma-names = "rx";
+		};
+
 		uart1: serial at 4806a000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart1";
+			reg = <0x4806a000 0x2000>;
+			interrupts = <72>;
+			dmas = <&sdma 49 &sdma 50>;
+			dma-names = "tx", "rx";
 			clock-frequency = <48000000>;
 		};
 
 		uart2: serial at 4806c000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart2";
+			reg = <0x4806c000 0x400>;
+			interrupts = <73>;
+			dmas = <&sdma 51 &sdma 52>;
+			dma-names = "tx", "rx";
 			clock-frequency = <48000000>;
 		};
 
 		uart3: serial at 4806e000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart3";
+			reg = <0x4806e000 0x400>;
+			interrupts = <74>;
+			dmas = <&sdma 53 &sdma 54>;
+			dma-names = "tx", "rx";
 			clock-frequency = <48000000>;
 		};
 
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index c8f9c55..60c605d 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -114,6 +114,15 @@
 			dma-names = "tx", "rx";
 		};
 
+		msdi1: mmc at 4809c000 {
+			compatible = "ti,omap2420-mmc";
+			ti,hwmods = "msdi1";
+			reg = <0x4809c000 0x80>;
+			interrupts = <83>;
+			dmas = <&sdma 61 &sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
 		timer1: timer at 48028000 {
 			compatible = "ti,omap2420-timer";
 			reg = <0x48028000 0x400>;
@@ -121,5 +130,19 @@
 			ti,hwmods = "timer1";
 			ti,timer-alwon;
 		};
+
+		wd_timer2: wdt at 48022000 {
+			compatible = "ti,omap2-wdt";
+			ti,hwmods = "wd_timer2";
+			reg = <0x48022000 0x80>;
+		};
 	};
 };
+
+&i2c1 {
+	compatible = "ti,omap2420-i2c";
+};
+
+&i2c2 {
+	compatible = "ti,omap2420-i2c";
+};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c535a5a..d624345 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -175,6 +175,25 @@
 			dma-names = "tx", "rx";
 		};
 
+		mmc1: mmc at 4809c000 {
+			compatible = "ti,omap2-hsmmc";
+			reg = <0x4809c000 0x200>;
+			interrupts = <83>;
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc2: mmc at 480b4000 {
+			compatible = "ti,omap2-hsmmc";
+			reg = <0x480b4000 0x200>;
+			interrupts = <86>;
+			ti,hwmods = "mmc2";
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
+		};
+
 		timer1: timer at 49018000 {
 			compatible = "ti,omap2420-timer";
 			reg = <0x49018000 0x400>;
@@ -182,5 +201,35 @@
 			ti,hwmods = "timer1";
 			ti,timer-alwon;
 		};
+
+		mcspi3: mcspi at 480b8000 {
+			compatible = "ti,omap2-mcspi";
+			ti,hwmods = "mcspi3";
+			reg = <0x480b8000 0x100>;
+			interrupts = <91>;
+			dmas = <&sdma 15 &sdma 16 &sdma 23 &sdma 24>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		usb_otg_hs: usb_otg_hs at 480ac000 {
+			compatible = "ti,omap2-musb";
+			ti,hwmods = "usb_otg_hs";
+			reg = <0x480ac000 0x1000>;
+			interrupts = <93>;
+		};
+
+		wd_timer2: wdt at 49016000 {
+			compatible = "ti,omap2-wdt";
+			ti,hwmods = "wd_timer2";
+			reg = <0x49016000 0x80>;
+		};
 	};
 };
+
+&i2c1 {
+	compatible = "ti,omap2430-i2c";
+};
+
+&i2c2 {
+	compatible = "ti,omap2430-i2c";
+};
-- 
1.8.1.1

Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Wolfram Sang]

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

On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote:
> As we claim to support device tree for mach-omap2, we
> should have the necessary flags in the driver to make it
> usable.
> 
> Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

Acked-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>

It would have been helpful if the message "PATCH [0/x]" would have been
sent to the i2c-list also.

Thanks,

   Wolfram


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

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Wolfram Sang]

On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote:
> As we claim to support device tree for mach-omap2, we
> should have the necessary flags in the driver to make it
> usable.
> 
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-i2c at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Wolfram Sang <wsa@the-dreams.de>

It would have been helpful if the message "PATCH [0/x]" would have been
sent to the i2c-list also.

Thanks,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131114/2a1363a3/attachment-0001.sig>

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Peter Ujfalusi]

Hi Tony,

On 11/14/2013 04:35 AM, Tony Lindgren wrote:
> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
> 
> The change reorganized twl_direction_out() and twl_set() and swapped
> the function names around in the process. While doing that, a bug got
> introduced that's not obvious while reading the patch as it appears
> as no change to the code.
> 
> The bug is we now call function twl4030_set_gpio_dataout() twice in
> both twl_direction_out() and twl_set(). Instead, we should first
> call twl_direction_out() in twl_direction_out() followed by
> twl4030_set_gpio_dataout() in twl_set().
> 
> This regression probably has gone unnoticed for a long time as the
> bootloader may have set the GPIO direction properly in many cases.
> This fixes at least the LCD panel not turning on omap3 LDP for
> example.

Thanks for catching this. I have a recollection that I have tested the GPIO
and it appeared to be working fine..

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: linux-gpio@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  drivers/gpio/gpio-twl4030.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 0c7e891..5738d5a 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
>  static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
>  {
>  	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
> +	int ret = -EINVAL;
>  
>  	mutex_lock(&priv->mutex);
>  	if (offset < TWL4030_GPIO_MAX)
> -		twl4030_set_gpio_dataout(offset, value);
> +		ret = twl4030_set_gpio_direction(offset, 0);
>  
>  	priv->direction |= BIT(offset);
>  	mutex_unlock(&priv->mutex);
>  
>  	twl_set(chip, offset, value);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
> 


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

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Peter Ujfalusi]

Hi Tony,

On 11/14/2013 04:35 AM, Tony Lindgren wrote:
> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
> 
> The change reorganized twl_direction_out() and twl_set() and swapped
> the function names around in the process. While doing that, a bug got
> introduced that's not obvious while reading the patch as it appears
> as no change to the code.
> 
> The bug is we now call function twl4030_set_gpio_dataout() twice in
> both twl_direction_out() and twl_set(). Instead, we should first
> call twl_direction_out() in twl_direction_out() followed by
> twl4030_set_gpio_dataout() in twl_set().
> 
> This regression probably has gone unnoticed for a long time as the
> bootloader may have set the GPIO direction properly in many cases.
> This fixes at least the LCD panel not turning on omap3 LDP for
> example.

Thanks for catching this. I have a recollection that I have tested the GPIO
and it appeared to be working fine..

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  drivers/gpio/gpio-twl4030.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 0c7e891..5738d5a 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
>  static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
>  {
>  	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
> +	int ret = -EINVAL;
>  
>  	mutex_lock(&priv->mutex);
>  	if (offset < TWL4030_GPIO_MAX)
> -		twl4030_set_gpio_dataout(offset, value);
> +		ret = twl4030_set_gpio_direction(offset, 0);
>  
>  	priv->direction |= BIT(offset);
>  	mutex_unlock(&priv->mutex);
>  
>  	twl_set(chip, offset, value);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
> 


-- 
P?ter

Re: [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Mark Rutland]

On Thu, Nov 14, 2013 at 02:35:30AM +0000, Tony Lindgren wrote:
> Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
> added minimal device tree support to smc91x, but it's not working on
> many platforms because of the lack of some key configuration bits.
> 
> Fix the issue by parsing the necessary configuration like the
> smc911x driver is doing.
> 
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 ++
>  drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++++++++++-----
>  2 files changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> index 953049b..53d69e3 100644
> --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> @@ -8,3 +8,7 @@ Required properties:
>  Optional properties:
>  - phy-device : phandle to Ethernet phy
>  - local-mac-address : Ethernet mac address to use
> +- reg-io-width : Specify the size (in bytes) of the IO accesses that
> +  should be performed on the device.  Valid value for SMSC LAN is
> +  1, 2 or 4.  If it's omitted or invalid, the size would be 2.

In the driver the supported access sizes are not mutually exclusive.  It
would be nice for the binding to have the same property.

> +- smsc,nowait : Setup for fast register access with no waits

I'm confused by what this means. When would this be selected, and when
wouldn't it be?

Thanks,
Mark.

[PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Mark Rutland]

On Thu, Nov 14, 2013 at 02:35:30AM +0000, Tony Lindgren wrote:
> Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
> added minimal device tree support to smc91x, but it's not working on
> many platforms because of the lack of some key configuration bits.
> 
> Fix the issue by parsing the necessary configuration like the
> smc911x driver is doing.
> 
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev at vger.kernel.org
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 ++
>  drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++++++++++-----
>  2 files changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> index 953049b..53d69e3 100644
> --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> @@ -8,3 +8,7 @@ Required properties:
>  Optional properties:
>  - phy-device : phandle to Ethernet phy
>  - local-mac-address : Ethernet mac address to use
> +- reg-io-width : Specify the size (in bytes) of the IO accesses that
> +  should be performed on the device.  Valid value for SMSC LAN is
> +  1, 2 or 4.  If it's omitted or invalid, the size would be 2.

In the driver the supported access sizes are not mutually exclusive.  It
would be nice for the binding to have the same property.

> +- smsc,nowait : Setup for fast register access with no waits

I'm confused by what this means. When would this be selected, and when
wouldn't it be?

Thanks,
Mark.

Re: [PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Mark Rutland]

On Thu, Nov 14, 2013 at 02:35:32AM +0000, Tony Lindgren wrote:
> Some features can be configured by the companion I2C chips,
> which may not be available at the probe time. Fix the issue
> by returning -EPROBE_DEFER when the MMC controller slots
> are not configured.
> 
> While at it, let's also add minimal device tree support so
> omap24xx platforms can use this driver without legacy mode
> since we claim to support device tree for mach-omap2 based
> systems.
> 
> Although adding the minimal device tree support is not strictly
> a fix, it does remove one of the last blockers for dropping a
> bunch of legacy platform data for mach-omap2.
> 
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  drivers/mmc/host/omap.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index ed56868..43c66ad 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -22,6 +22,7 @@
>  #include <linux/delay.h>
>  #include <linux/spinlock.h>
>  #include <linux/timer.h>
> +#include <linux/of.h>
>  #include <linux/omap-dma.h>
>  #include <linux/mmc/host.h>
>  #include <linux/mmc/card.h>
> @@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
>  	}
>  	if (pdata->nr_slots == 0) {
>  		dev_err(&pdev->dev, "no slots\n");
> -		return -ENXIO;
> +		return -EPROBE_DEFER;
>  	}
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
>  #define mmc_omap_resume		NULL
>  #endif
>  
> +#if IS_BUILTIN(CONFIG_OF)
> +static const struct of_device_id mmc_omap_match[] = {
> +	{ .compatible = "ti,omap2420-mmc", },

Missing binding document.

Thanks,
Mark.

[PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Mark Rutland]

On Thu, Nov 14, 2013 at 02:35:32AM +0000, Tony Lindgren wrote:
> Some features can be configured by the companion I2C chips,
> which may not be available at the probe time. Fix the issue
> by returning -EPROBE_DEFER when the MMC controller slots
> are not configured.
> 
> While at it, let's also add minimal device tree support so
> omap24xx platforms can use this driver without legacy mode
> since we claim to support device tree for mach-omap2 based
> systems.
> 
> Although adding the minimal device tree support is not strictly
> a fix, it does remove one of the last blockers for dropping a
> bunch of legacy platform data for mach-omap2.
> 
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  drivers/mmc/host/omap.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index ed56868..43c66ad 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -22,6 +22,7 @@
>  #include <linux/delay.h>
>  #include <linux/spinlock.h>
>  #include <linux/timer.h>
> +#include <linux/of.h>
>  #include <linux/omap-dma.h>
>  #include <linux/mmc/host.h>
>  #include <linux/mmc/card.h>
> @@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
>  	}
>  	if (pdata->nr_slots == 0) {
>  		dev_err(&pdev->dev, "no slots\n");
> -		return -ENXIO;
> +		return -EPROBE_DEFER;
>  	}
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
>  #define mmc_omap_resume		NULL
>  #endif
>  
> +#if IS_BUILTIN(CONFIG_OF)
> +static const struct of_device_id mmc_omap_match[] = {
> +	{ .compatible = "ti,omap2420-mmc", },

Missing binding document.

Thanks,
Mark.

Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Mark Rutland]

On Thu, Nov 14, 2013 at 02:35:33AM +0000, Tony Lindgren wrote:
> As we claim to support device tree for mach-omap2, we
> should have the necessary flags in the driver to make it
> usable.
> 
> Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)

[...]

> +	{
> +		.compatible = "ti,omap2430-i2c",
> +		.data = &omap2430_pdata,
> +	},
> +	{
> +		.compatible = "ti,omap2420-i2c",
> +		.data = &omap2420_pdata,

Please update Documentation/devicetree/bindings/i2c/i2c-omap.txt

Otherwise, this is fine.

Thanks,
Mark.

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Mark Rutland]

On Thu, Nov 14, 2013 at 02:35:33AM +0000, Tony Lindgren wrote:
> As we claim to support device tree for mach-omap2, we
> should have the necessary flags in the driver to make it
> usable.
> 
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-i2c at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
>  drivers/i2c/busses/i2c-omap.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)

[...]

> +	{
> +		.compatible = "ti,omap2430-i2c",
> +		.data = &omap2430_pdata,
> +	},
> +	{
> +		.compatible = "ti,omap2420-i2c",
> +		.data = &omap2420_pdata,

Please update Documentation/devicetree/bindings/i2c/i2c-omap.txt

Otherwise, this is fine.

Thanks,
Mark.

Re: [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Mark Rutland <mark.rutland@arm.com> [131114 03:04]:
> On Thu, Nov 14, 2013 at 02:35:30AM +0000, Tony Lindgren wrote:
> > Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
> > added minimal device tree support to smc91x, but it's not working on
> > many platforms because of the lack of some key configuration bits.
> > 
> > Fix the issue by parsing the necessary configuration like the
> > smc911x driver is doing.
> > 
> > Cc: Nicolas Pitre <nico@fluxnic.net>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > 
> > If this looks OK, I'd like to merge this as a fix via arm-soc tree
> > along with the other patches in this series as my later patches
> > depend on patches in this series.
> > 
> > ---
> >  .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 ++
> >  drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++++++++++-----
> >  2 files changed, 46 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> > index 953049b..53d69e3 100644
> > --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> > +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> > @@ -8,3 +8,7 @@ Required properties:
> >  Optional properties:
> >  - phy-device : phandle to Ethernet phy
> >  - local-mac-address : Ethernet mac address to use
> > +- reg-io-width : Specify the size (in bytes) of the IO accesses that
> > +  should be performed on the device.  Valid value for SMSC LAN is
> > +  1, 2 or 4.  If it's omitted or invalid, the size would be 2.
> 
> In the driver the supported access sizes are not mutually exclusive.  It
> would be nice for the binding to have the same property.

Hmm indeed. How about we add reg-io-width-mask:

	1 = 8-bit access
	2 = 16-bit access
	4 = 32-bit access
	...

So for a driver to support 8, 16 and 32-bit access the mask would
be:
	reg-io-width-mask = <7>;

Although the values for reg-io-width would support masks too, it
might be better to have reg-io-width-mask to avoid confusion.

Or do you have any better ideas?
 
> > +- smsc,nowait : Setup for fast register access with no waits
> 
> I'm confused by what this means. When would this be selected, and when
> wouldn't it be?

The driver has a module parameter for it and the comments say:

"nowait  = 0 for normal wait states, 1 eliminates additional wait states"

Most platforms seem to set it, but the default is to not set it.
I guess we could that be a module parameter for now as that's a
timing optimization.

Regards,

Tony

[PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Mark Rutland <mark.rutland@arm.com> [131114 03:04]:
> On Thu, Nov 14, 2013 at 02:35:30AM +0000, Tony Lindgren wrote:
> > Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
> > added minimal device tree support to smc91x, but it's not working on
> > many platforms because of the lack of some key configuration bits.
> > 
> > Fix the issue by parsing the necessary configuration like the
> > smc911x driver is doing.
> > 
> > Cc: Nicolas Pitre <nico@fluxnic.net>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev at vger.kernel.org
> > Cc: devicetree at vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > 
> > If this looks OK, I'd like to merge this as a fix via arm-soc tree
> > along with the other patches in this series as my later patches
> > depend on patches in this series.
> > 
> > ---
> >  .../devicetree/bindings/net/smsc-lan91c111.txt     |  4 ++
> >  drivers/net/ethernet/smsc/smc91x.c                 | 52 +++++++++++++++++-----
> >  2 files changed, 46 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> > index 953049b..53d69e3 100644
> > --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> > +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> > @@ -8,3 +8,7 @@ Required properties:
> >  Optional properties:
> >  - phy-device : phandle to Ethernet phy
> >  - local-mac-address : Ethernet mac address to use
> > +- reg-io-width : Specify the size (in bytes) of the IO accesses that
> > +  should be performed on the device.  Valid value for SMSC LAN is
> > +  1, 2 or 4.  If it's omitted or invalid, the size would be 2.
> 
> In the driver the supported access sizes are not mutually exclusive.  It
> would be nice for the binding to have the same property.

Hmm indeed. How about we add reg-io-width-mask:

	1 = 8-bit access
	2 = 16-bit access
	4 = 32-bit access
	...

So for a driver to support 8, 16 and 32-bit access the mask would
be:
	reg-io-width-mask = <7>;

Although the values for reg-io-width would support masks too, it
might be better to have reg-io-width-mask to avoid confusion.

Or do you have any better ideas?
 
> > +- smsc,nowait : Setup for fast register access with no waits
> 
> I'm confused by what this means. When would this be selected, and when
> wouldn't it be?

The driver has a module parameter for it and the comments say:

"nowait  = 0 for normal wait states, 1 eliminates additional wait states"

Most platforms seem to set it, but the default is to not set it.
I guess we could that be a module parameter for now as that's a
timing optimization.

Regards,

Tony

Re: [PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Tony Lindgren]

* Mark Rutland <mark.rutland@arm.com> [131114 03:06]:
>
> Missing binding document.

Here's this one updated with a minimal binding document. The
ti,hwmods is still needed until we have removed the dependencies
to hwmod code for omaps.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] mmc: omap: Fix I2C dependency and make driver usable with device tree

Some features can be configured by the companion I2C chips,
which may not be available at the probe time. Fix the issue
by returning -EPROBE_DEFER when the MMC controller slots
are not configured.

While at it, let's also add minimal device tree support so
omap24xx platforms can use this driver without legacy mode
since we claim to support device tree for mach-omap2 based
systems.

Although adding the minimal device tree support is not strictly
a fix, it does remove one of the last blockers for dropping a
bunch of legacy platform data for mach-omap2.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

+++ b/Documentation/devicetree/bindings/mmc/ti-omap.txt
@@ -0,0 +1,27 @@
+* TI MMC host controller for OMAP1 and 2420
+
+The MMC Host Controller on TI OMAP1 and 2420 family provides
+an interface for MMC, SD, and SDIO types of memory cards.
+
+This file documents differences between the core properties described
+by mmc.txt and the properties used by the omap mmc driver.
+
+Note that this driver will not work with omap2430 or later omaps,
+please see the omap hsmmc driver for the current omaps.
+
+Required properties:
+- compatible: Must be "ti,omap2420-mmc", for OMAP2420 controllers
+- ti,hwmods: For 2420, must be "msdi<n>", where n is controller
+  instance starting 1
+
+Examples:
+
+	msdi1: mmc@4809c000 {
+		compatible = "ti,omap2420-mmc";
+		ti,hwmods = "msdi1";
+		reg = <0x4809c000 0x80>;
+		interrupts = <83>;
+		dmas = <&sdma 61 &sdma 62>;
+		dma-names = "tx", "rx";
+	};
+
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -22,6 +22,7 @@
 #include <linux/delay.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
+#include <linux/of.h>
 #include <linux/omap-dma.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
@@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	}
 	if (pdata->nr_slots == 0) {
 		dev_err(&pdev->dev, "no slots\n");
-		return -ENXIO;
+		return -EPROBE_DEFER;
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
 #define mmc_omap_resume		NULL
 #endif
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id mmc_omap_match[] = {
+	{ .compatible = "ti,omap2420-mmc", },
+	{ },
+};
+#endif
 static struct platform_driver mmc_omap_driver = {
 	.probe		= mmc_omap_probe,
 	.remove		= mmc_omap_remove,
@@ -1561,6 +1568,7 @@ static struct platform_driver mmc_omap_driver = {
 	.driver		= {
 		.name	= DRIVER_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(mmc_omap_match),
 	},
 };
 

[PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Tony Lindgren]

* Mark Rutland <mark.rutland@arm.com> [131114 03:06]:
>
> Missing binding document.

Here's this one updated with a minimal binding document. The
ti,hwmods is still needed until we have removed the dependencies
to hwmod code for omaps.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] mmc: omap: Fix I2C dependency and make driver usable with device tree

Some features can be configured by the companion I2C chips,
which may not be available at the probe time. Fix the issue
by returning -EPROBE_DEFER when the MMC controller slots
are not configured.

While at it, let's also add minimal device tree support so
omap24xx platforms can use this driver without legacy mode
since we claim to support device tree for mach-omap2 based
systems.

Although adding the minimal device tree support is not strictly
a fix, it does remove one of the last blockers for dropping a
bunch of legacy platform data for mach-omap2.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

+++ b/Documentation/devicetree/bindings/mmc/ti-omap.txt
@@ -0,0 +1,27 @@
+* TI MMC host controller for OMAP1 and 2420
+
+The MMC Host Controller on TI OMAP1 and 2420 family provides
+an interface for MMC, SD, and SDIO types of memory cards.
+
+This file documents differences between the core properties described
+by mmc.txt and the properties used by the omap mmc driver.
+
+Note that this driver will not work with omap2430 or later omaps,
+please see the omap hsmmc driver for the current omaps.
+
+Required properties:
+- compatible: Must be "ti,omap2420-mmc", for OMAP2420 controllers
+- ti,hwmods: For 2420, must be "msdi<n>", where n is controller
+  instance starting 1
+
+Examples:
+
+	msdi1: mmc at 4809c000 {
+		compatible = "ti,omap2420-mmc";
+		ti,hwmods = "msdi1";
+		reg = <0x4809c000 0x80>;
+		interrupts = <83>;
+		dmas = <&sdma 61 &sdma 62>;
+		dma-names = "tx", "rx";
+	};
+
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -22,6 +22,7 @@
 #include <linux/delay.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
+#include <linux/of.h>
 #include <linux/omap-dma.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
@@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	}
 	if (pdata->nr_slots == 0) {
 		dev_err(&pdev->dev, "no slots\n");
-		return -ENXIO;
+		return -EPROBE_DEFER;
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
 #define mmc_omap_resume		NULL
 #endif
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id mmc_omap_match[] = {
+	{ .compatible = "ti,omap2420-mmc", },
+	{ },
+};
+#endif
 static struct platform_driver mmc_omap_driver = {
 	.probe		= mmc_omap_probe,
 	.remove		= mmc_omap_remove,
@@ -1561,6 +1568,7 @@ static struct platform_driver mmc_omap_driver = {
 	.driver		= {
 		.name	= DRIVER_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(mmc_omap_match),
 	},
 };
 

Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

* Mark Rutland <mark.rutland@arm.com> [131114 03:08]:
> 
> Please update Documentation/devicetree/bindings/i2c/i2c-omap.txt
> 
> Otherwise, this is fine.

Here's this one with updated documentation.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] i2c: omap: Fix missing device tree flags for omap2

As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.

Cc: linux-i2c@vger.kernel.org
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-omap.txt
@@ -1,7 +1,8 @@
 I2C for OMAP platforms
 
 Required properties :
-- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
+- compatible : Must be "ti,omap2420-i2c", "ti,omap2430-i2c", "ti,omap3-i2c"
+  or "ti,omap4-i2c"
 - ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
 - #address-cells = <1>;
 - #size-cells = <0>;
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
 };
 
 #ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_NO_FIFO |
+			OMAP_I2C_FLAG_SIMPLE_CLOCK |
+			OMAP_I2C_FLAG_16BIT_DATA_REG |
+			OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+			OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
 static struct omap_i2c_bus_platform_data omap3_pdata = {
 	.rev = OMAP_I2C_IP_VERSION_1,
 	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
 		.compatible = "ti,omap3-i2c",
 		.data = &omap3_pdata,
 	},
+	{
+		.compatible = "ti,omap2430-i2c",
+		.data = &omap2430_pdata,
+	},
+	{
+		.compatible = "ti,omap2420-i2c",
+		.data = &omap2420_pdata,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, omap_i2c_of_match);

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

* Mark Rutland <mark.rutland@arm.com> [131114 03:08]:
> 
> Please update Documentation/devicetree/bindings/i2c/i2c-omap.txt
> 
> Otherwise, this is fine.

Here's this one with updated documentation.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] i2c: omap: Fix missing device tree flags for omap2

As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.

Cc: linux-i2c at vger.kernel.org
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-omap.txt
@@ -1,7 +1,8 @@
 I2C for OMAP platforms
 
 Required properties :
-- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
+- compatible : Must be "ti,omap2420-i2c", "ti,omap2430-i2c", "ti,omap3-i2c"
+  or "ti,omap4-i2c"
 - ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
 - #address-cells = <1>;
 - #size-cells = <0>;
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
 };
 
 #ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_NO_FIFO |
+			OMAP_I2C_FLAG_SIMPLE_CLOCK |
+			OMAP_I2C_FLAG_16BIT_DATA_REG |
+			OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+	.rev = OMAP_I2C_IP_VERSION_1,
+	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+			OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
 static struct omap_i2c_bus_platform_data omap3_pdata = {
 	.rev = OMAP_I2C_IP_VERSION_1,
 	.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
 		.compatible = "ti,omap3-i2c",
 		.data = &omap3_pdata,
 	},
+	{
+		.compatible = "ti,omap2430-i2c",
+		.data = &omap2430_pdata,
+	},
+	{
+		.compatible = "ti,omap2420-i2c",
+		.data = &omap2420_pdata,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, omap_i2c_of_match);

Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [131113 22:59]:
> On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote:
> > As we claim to support device tree for mach-omap2, we
> > should have the necessary flags in the driver to make it
> > usable.
> > 
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: linux-i2c@vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
> 
> It would have been helpful if the message "PATCH [0/x]" would have been
> sent to the i2c-list also.

Thanks, next time I'll try check the cc list in the cover letter
manually after running git format patch. I guess there's no way
to deal with that in an automated way.

Here's a link to the whole thread for reference:

http://www.spinics.net/lists/arm-kernel/msg286246.html

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [131113 22:59]:
> On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote:
> > As we claim to support device tree for mach-omap2, we
> > should have the necessary flags in the driver to make it
> > usable.
> > 
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: linux-i2c at vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
> 
> It would have been helpful if the message "PATCH [0/x]" would have been
> sent to the i2c-list also.

Thanks, next time I'll try check the cc list in the cover letter
manually after running git format patch. I guess there's no way
to deal with that in an automated way.

Here's a link to the whole thread for reference:

http://www.spinics.net/lists/arm-kernel/msg286246.html

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [131114 01:46]:
> Hi Tony,
> 
> On 11/14/2013 04:35 AM, Tony Lindgren wrote:
> > Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> > states in private data) improved things in general, but caused a
> > regression for setting the GPIO output direction.
> > 
> > The change reorganized twl_direction_out() and twl_set() and swapped
> > the function names around in the process. While doing that, a bug got
> > introduced that's not obvious while reading the patch as it appears
> > as no change to the code.
> > 
> > The bug is we now call function twl4030_set_gpio_dataout() twice in
> > both twl_direction_out() and twl_set(). Instead, we should first
> > call twl_direction_out() in twl_direction_out() followed by
> > twl4030_set_gpio_dataout() in twl_set().
> > 
> > This regression probably has gone unnoticed for a long time as the
> > bootloader may have set the GPIO direction properly in many cases.
> > This fixes at least the LCD panel not turning on omap3 LDP for
> > example.
> 
> Thanks for catching this. I have a recollection that I have tested the GPIO
> and it appeared to be working fine..

Yes it probably worked fine if the bootloader set the direction :)
This is cc stable kind of patch for sure.

Regards,

Tony

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [131114 01:46]:
> Hi Tony,
> 
> On 11/14/2013 04:35 AM, Tony Lindgren wrote:
> > Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> > states in private data) improved things in general, but caused a
> > regression for setting the GPIO output direction.
> > 
> > The change reorganized twl_direction_out() and twl_set() and swapped
> > the function names around in the process. While doing that, a bug got
> > introduced that's not obvious while reading the patch as it appears
> > as no change to the code.
> > 
> > The bug is we now call function twl4030_set_gpio_dataout() twice in
> > both twl_direction_out() and twl_set(). Instead, we should first
> > call twl_direction_out() in twl_direction_out() followed by
> > twl4030_set_gpio_dataout() in twl_set().
> > 
> > This regression probably has gone unnoticed for a long time as the
> > bootloader may have set the GPIO direction properly in many cases.
> > This fixes at least the LCD panel not turning on omap3 LDP for
> > example.
> 
> Thanks for catching this. I have a recollection that I have tested the GPIO
> and it appeared to be working fine..

Yes it probably worked fine if the bootloader set the direction :)
This is cc stable kind of patch for sure.

Regards,

Tony

Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Wolfram Sang]

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


> > It would have been helpful if the message "PATCH [0/x]" would have been
> > sent to the i2c-list also.
> 
> Thanks, next time I'll try check the cc list in the cover letter
> manually after running git format patch. I guess there's no way
> to deal with that in an automated way.

I use this hackish script as --cc-cmd with git:

#! /bin/sh
#
# cocci_cc - send cover letter to all mailing lists referenced in a patch series
# done by Wolfram Sang in 2012 - WTFPLv2

name=${1##*/}
num=${name%%-*}

if [ "$num" = "0000" ]; then
	dir=${1%/*}
	for f in $dir/*; do
		patchname=${f##*/}
		[ "${patchname%%-*}" = "0000" ] && continue
		scripts/get_maintainer.pl --no-m $f
	done | sort -u
else
	scripts/get_maintainer.pl $1
fi


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

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Wolfram Sang]

> > It would have been helpful if the message "PATCH [0/x]" would have been
> > sent to the i2c-list also.
> 
> Thanks, next time I'll try check the cc list in the cover letter
> manually after running git format patch. I guess there's no way
> to deal with that in an automated way.

I use this hackish script as --cc-cmd with git:

#! /bin/sh
#
# cocci_cc - send cover letter to all mailing lists referenced in a patch series
# done by Wolfram Sang in 2012 - WTFPLv2

name=${1##*/}
num=${name%%-*}

if [ "$num" = "0000" ]; then
	dir=${1%/*}
	for f in $dir/*; do
		patchname=${f##*/}
		[ "${patchname%%-*}" = "0000" ] && continue
		scripts/get_maintainer.pl --no-m $f
	done | sort -u
else
	scripts/get_maintainer.pl $1
fi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131114/147fd74a/attachment-0001.sig>

Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [131114 09:49]:
> 
> > > It would have been helpful if the message "PATCH [0/x]" would have been
> > > sent to the i2c-list also.
> > 
> > Thanks, next time I'll try check the cc list in the cover letter
> > manually after running git format patch. I guess there's no way
> > to deal with that in an automated way.
> 
> I use this hackish script as --cc-cmd with git:
> 
> #! /bin/sh
> #
> # cocci_cc - send cover letter to all mailing lists referenced in a patch series
> # done by Wolfram Sang in 2012 - WTFPLv2
> 
> name=${1##*/}
> num=${name%%-*}
> 
> if [ "$num" = "0000" ]; then
> 	dir=${1%/*}
> 	for f in $dir/*; do
> 		patchname=${f##*/}
> 		[ "${patchname%%-*}" = "0000" ] && continue
> 		scripts/get_maintainer.pl --no-m $f
> 	done | sort -u
> else
> 	scripts/get_maintainer.pl $1
> fi
> 

Cool thanks :) I'll give it a try next time.

Tony

[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [131114 09:49]:
> 
> > > It would have been helpful if the message "PATCH [0/x]" would have been
> > > sent to the i2c-list also.
> > 
> > Thanks, next time I'll try check the cc list in the cover letter
> > manually after running git format patch. I guess there's no way
> > to deal with that in an automated way.
> 
> I use this hackish script as --cc-cmd with git:
> 
> #! /bin/sh
> #
> # cocci_cc - send cover letter to all mailing lists referenced in a patch series
> # done by Wolfram Sang in 2012 - WTFPLv2
> 
> name=${1##*/}
> num=${name%%-*}
> 
> if [ "$num" = "0000" ]; then
> 	dir=${1%/*}
> 	for f in $dir/*; do
> 		patchname=${f##*/}
> 		[ "${patchname%%-*}" = "0000" ] && continue
> 		scripts/get_maintainer.pl --no-m $f
> 	done | sort -u
> else
> 	scripts/get_maintainer.pl $1
> fi
> 

Cool thanks :) I'll give it a try next time.

Tony

[PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Tony Lindgren]

Looks like we're missing two lines needed to make it
work properly with device tree.

Cc: linux-i2c@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Wolfram, I found one more bug booting omaps with device tree.

--- a/drivers/i2c/busses/i2c-cbus-gpio.c
+++ b/drivers/i2c/busses/i2c-cbus-gpio.c
@@ -246,6 +246,7 @@ static int cbus_i2c_probe(struct platform_device *pdev)
 	adapter->owner		= THIS_MODULE;
 	adapter->class		= I2C_CLASS_HWMON;
 	adapter->dev.parent	= &pdev->dev;
+	adapter->dev.of_node	= pdev->dev.of_node;
 	adapter->nr		= pdev->id;
 	adapter->timeout	= HZ;
 	adapter->algo		= &cbus_i2c_algo;
@@ -289,6 +290,7 @@ static struct platform_driver cbus_i2c_driver = {
 	.driver	= {
 		.owner	= THIS_MODULE,
 		.name	= "i2c-cbus-gpio",
+		.of_match_table = of_match_ptr(i2c_cbus_dt_ids),
 	},
 };
 module_platform_driver(cbus_i2c_driver);

[PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Tony Lindgren]

Looks like we're missing two lines needed to make it
work properly with device tree.

Cc: linux-i2c at vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

Wolfram, I found one more bug booting omaps with device tree.

--- a/drivers/i2c/busses/i2c-cbus-gpio.c
+++ b/drivers/i2c/busses/i2c-cbus-gpio.c
@@ -246,6 +246,7 @@ static int cbus_i2c_probe(struct platform_device *pdev)
 	adapter->owner		= THIS_MODULE;
 	adapter->class		= I2C_CLASS_HWMON;
 	adapter->dev.parent	= &pdev->dev;
+	adapter->dev.of_node	= pdev->dev.of_node;
 	adapter->nr		= pdev->id;
 	adapter->timeout	= HZ;
 	adapter->algo		= &cbus_i2c_algo;
@@ -289,6 +290,7 @@ static struct platform_driver cbus_i2c_driver = {
 	.driver	= {
 		.owner	= THIS_MODULE,
 		.name	= "i2c-cbus-gpio",
+		.of_match_table = of_match_ptr(i2c_cbus_dt_ids),
 	},
 };
 module_platform_driver(cbus_i2c_driver);

Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Aaro Koskinen]

Hi,

On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
> Looks like we're missing two lines needed to make it
> work properly with device tree.
> 
> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>

You can change this to: Tested-by: <aaro.koskinen-X3B1VOXEql0@public.gmane.org>

I booted DT-N800 with Tony's patches, and it works.

Thanks,

A.

[PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Aaro Koskinen]

Hi,

On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
> Looks like we're missing two lines needed to make it
> work properly with device tree.
> 
> Cc: linux-i2c at vger.kernel.org
> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>

You can change this to: Tested-by: <aaro.koskinen@iki.fi>

I booted DT-N800 with Tony's patches, and it works.

Thanks,

A.

Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Wolfram Sang]

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

On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
> Looks like we're missing two lines needed to make it
> work properly with device tree.
> 
> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
> Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

Applied to for-next, thanks!


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

[PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Wolfram Sang]

On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
> Looks like we're missing two lines needed to make it
> work properly with device tree.
> 
> Cc: linux-i2c at vger.kernel.org
> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131115/44668d17/attachment-0001.sig>

Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Tony Lindgren]

* Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> [131115 14:27]:
> On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
> > Looks like we're missing two lines needed to make it
> > work properly with device tree.
> > 
> > Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
> > Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> 
> Applied to for-next, thanks!

Thanks, will drop this one from my fixes series.

Tony 

[PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio

[Tony Lindgren]

* Wolfram Sang <wsa@the-dreams.de> [131115 14:27]:
> On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
> > Looks like we're missing two lines needed to make it
> > work properly with device tree.
> > 
> > Cc: linux-i2c at vger.kernel.org
> > Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Applied to for-next, thanks!

Thanks, will drop this one from my fixes series.

Tony 

Re: [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131114 08:09]:
> * Mark Rutland <mark.rutland@arm.com> [131114 03:04]:
> > 
> > In the driver the supported access sizes are not mutually exclusive.  It
> > would be nice for the binding to have the same property.
> 
> Hmm indeed. How about we add reg-io-width-mask:
> 
> 	1 = 8-bit access
> 	2 = 16-bit access
> 	4 = 32-bit access
> 	...
> 
> So for a driver to support 8, 16 and 32-bit access the mask would
> be:
> 	reg-io-width-mask = <7>;
> 
> Although the values for reg-io-width would support masks too, it
> might be better to have reg-io-width-mask to avoid confusion.
> 
> Or do you have any better ideas?
>  
> > > +- smsc,nowait : Setup for fast register access with no waits
> > 
> > I'm confused by what this means. When would this be selected, and when
> > wouldn't it be?
> 
> The driver has a module parameter for it and the comments say:
> 
> "nowait  = 0 for normal wait states, 1 eliminates additional wait states"
> 
> Most platforms seem to set it, but the default is to not set it.
> I guess we could that be a module parameter for now as that's a
> timing optimization.

Here's what I was thinking with the reg-io-width-mask. Anybody
have comments on using reg-io-width vs reg-io-width-mask?

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] net: smc91x: Fix device tree based configuration so it's usable

Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.

Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.

Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
 Optional properties:
 - phy-device : phandle to Ethernet phy
 - local-mac-address : Ethernet mac address to use
+- reg-io-width-mask : Mask of sizes (in bytes) of the IO accesses that
+  are supported on the device.  Valid value for SMSC LAN91c111 are
+  1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
+  16-bit access only.
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
 #include <linux/mii.h>
 #include <linux/workqueue.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
@@ -2189,6 +2190,15 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 	}
 }
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+	{ .compatible = "smsc,lan91c94", },
+	{ .compatible = "smsc,lan91c111", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
 /*
  * smc_init(void)
  *   Input parameters:
@@ -2203,6 +2213,8 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 static int smc_drv_probe(struct platform_device *pdev)
 {
 	struct smc91x_platdata *pd = dev_get_platdata(&pdev->dev);
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match = NULL;
 	struct smc_local *lp;
 	struct net_device *ndev;
 	struct resource *res, *ires;
@@ -2222,11 +2234,31 @@ static int smc_drv_probe(struct platform_device *pdev)
 	 */
 
 	lp = netdev_priv(ndev);
+	lp->cfg.flags = 0;
 
 	if (pd) {
 		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
 		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
-	} else {
+	}
+
+#if IS_BUILTIN(CONFIG_OF)
+	match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
+	if (match) {
+		u32 val;
+
+		of_property_read_u32(np, "reg-io-width", &val);
+		if (val == 0)
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+		if (val & 1)
+			lp->cfg.flags |= SMC91X_USE_8BIT;
+		if (val & 2)
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+		if (val & 4)
+			lp->cfg.flags |= SMC91X_USE_32BIT;
+	}
+#endif
+
+	if (!pd && !match) {
 		lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2375,15 +2407,6 @@ static int smc_drv_resume(struct device *dev)
 	return 0;
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
-	{ .compatible = "smsc,lan91c94", },
-	{ .compatible = "smsc,lan91c111", },
-	{},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
 static struct dev_pm_ops smc_drv_pm_ops = {
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,

[PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131114 08:09]:
> * Mark Rutland <mark.rutland@arm.com> [131114 03:04]:
> > 
> > In the driver the supported access sizes are not mutually exclusive.  It
> > would be nice for the binding to have the same property.
> 
> Hmm indeed. How about we add reg-io-width-mask:
> 
> 	1 = 8-bit access
> 	2 = 16-bit access
> 	4 = 32-bit access
> 	...
> 
> So for a driver to support 8, 16 and 32-bit access the mask would
> be:
> 	reg-io-width-mask = <7>;
> 
> Although the values for reg-io-width would support masks too, it
> might be better to have reg-io-width-mask to avoid confusion.
> 
> Or do you have any better ideas?
>  
> > > +- smsc,nowait : Setup for fast register access with no waits
> > 
> > I'm confused by what this means. When would this be selected, and when
> > wouldn't it be?
> 
> The driver has a module parameter for it and the comments say:
> 
> "nowait  = 0 for normal wait states, 1 eliminates additional wait states"
> 
> Most platforms seem to set it, but the default is to not set it.
> I guess we could that be a module parameter for now as that's a
> timing optimization.

Here's what I was thinking with the reg-io-width-mask. Anybody
have comments on using reg-io-width vs reg-io-width-mask?

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] net: smc91x: Fix device tree based configuration so it's usable

Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.

Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.

Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev at vger.kernel.org
Cc: devicetree at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
 Optional properties:
 - phy-device : phandle to Ethernet phy
 - local-mac-address : Ethernet mac address to use
+- reg-io-width-mask : Mask of sizes (in bytes) of the IO accesses that
+  are supported on the device.  Valid value for SMSC LAN91c111 are
+  1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
+  16-bit access only.
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
 #include <linux/mii.h>
 #include <linux/workqueue.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
@@ -2189,6 +2190,15 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 	}
 }
 
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+	{ .compatible = "smsc,lan91c94", },
+	{ .compatible = "smsc,lan91c111", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
 /*
  * smc_init(void)
  *   Input parameters:
@@ -2203,6 +2213,8 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
 static int smc_drv_probe(struct platform_device *pdev)
 {
 	struct smc91x_platdata *pd = dev_get_platdata(&pdev->dev);
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match = NULL;
 	struct smc_local *lp;
 	struct net_device *ndev;
 	struct resource *res, *ires;
@@ -2222,11 +2234,31 @@ static int smc_drv_probe(struct platform_device *pdev)
 	 */
 
 	lp = netdev_priv(ndev);
+	lp->cfg.flags = 0;
 
 	if (pd) {
 		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
 		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
-	} else {
+	}
+
+#if IS_BUILTIN(CONFIG_OF)
+	match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
+	if (match) {
+		u32 val;
+
+		of_property_read_u32(np, "reg-io-width", &val);
+		if (val == 0)
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+		if (val & 1)
+			lp->cfg.flags |= SMC91X_USE_8BIT;
+		if (val & 2)
+			lp->cfg.flags |= SMC91X_USE_16BIT;
+		if (val & 4)
+			lp->cfg.flags |= SMC91X_USE_32BIT;
+	}
+#endif
+
+	if (!pd && !match) {
 		lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
 		lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2375,15 +2407,6 @@ static int smc_drv_resume(struct device *dev)
 	return 0;
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
-	{ .compatible = "smsc,lan91c94", },
-	{ .compatible = "smsc,lan91c111", },
-	{},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
 static struct dev_pm_ops smc_drv_pm_ops = {
 	.suspend	= smc_drv_suspend,
 	.resume		= smc_drv_resume,

Re: [PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131113 18:37]:
> We still have some legacy code needing the callback functions
> that won't work properly without platform data. To use platform
> data for twl4030-gpio, we need to not trash the possible data.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-gpio@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

Here's this one with a fix from Fengguang Wu to use struct assignment
instead of memcpy folded in.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 14 Nov 2013 15:25:08 -0800
Subject: [PATCH] gpio: twl4030: Fix passing of pdata in the device tree case

We still have some legacy code needing the callback functions
that won't work properly without platform data. To use platform
data for twl4030-gpio, we need to not trash the possible data.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
[tony@atomide.com: folded in fix from Fengguang to use struct assignment]
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -436,7 +436,8 @@ static int gpio_twl4030_debounce(u32 debounce, u8 mmc_cd)
 
 static int gpio_twl4030_remove(struct platform_device *pdev);
 
-static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev,
+				struct twl4030_gpio_platform_data *pdata)
 {
 	struct twl4030_gpio_platform_data *omap_twl_info;
 
@@ -444,6 +445,9 @@ static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
 	if (!omap_twl_info)
 		return NULL;
 
+	if (pdata)
+		*omap_twl_info = *pdata;
+
 	omap_twl_info->use_leds = of_property_read_bool(dev->of_node,
 			"ti,use-leds");
 
@@ -501,7 +505,7 @@ no_irqs:
 	mutex_init(&priv->mutex);
 
 	if (node)
-		pdata = of_gpio_twl4030(&pdev->dev);
+		pdata = of_gpio_twl4030(&pdev->dev, pdata);
 
 	if (pdata == NULL) {
 		dev_err(&pdev->dev, "Platform data is missing\n");

[PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131113 18:37]:
> We still have some legacy code needing the callback functions
> that won't work properly without platform data. To use platform
> data for twl4030-gpio, we need to not trash the possible data.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

Here's this one with a fix from Fengguang Wu to use struct assignment
instead of memcpy folded in.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 14 Nov 2013 15:25:08 -0800
Subject: [PATCH] gpio: twl4030: Fix passing of pdata in the device tree case

We still have some legacy code needing the callback functions
that won't work properly without platform data. To use platform
data for twl4030-gpio, we need to not trash the possible data.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio at vger.kernel.org
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
[tony at atomide.com: folded in fix from Fengguang to use struct assignment]
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -436,7 +436,8 @@ static int gpio_twl4030_debounce(u32 debounce, u8 mmc_cd)
 
 static int gpio_twl4030_remove(struct platform_device *pdev);
 
-static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev,
+				struct twl4030_gpio_platform_data *pdata)
 {
 	struct twl4030_gpio_platform_data *omap_twl_info;
 
@@ -444,6 +445,9 @@ static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
 	if (!omap_twl_info)
 		return NULL;
 
+	if (pdata)
+		*omap_twl_info = *pdata;
+
 	omap_twl_info->use_leds = of_property_read_bool(dev->of_node,
 			"ti,use-leds");
 
@@ -501,7 +505,7 @@ no_irqs:
 	mutex_init(&priv->mutex);
 
 	if (node)
-		pdata = of_gpio_twl4030(&pdev->dev);
+		pdata = of_gpio_twl4030(&pdev->dev, pdata);
 
 	if (pdata == NULL) {
 		dev_err(&pdev->dev, "Platform data is missing\n");

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131113 18:36]:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
> 
> Fix the issue by using the standard resources like we should.
> 
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

Looks like we need sig initialized in this patch to avoid some
uninitialized warnings.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 14 Nov 2013 15:25:06 -0800
Subject: [PATCH] mmc: omap: Fix DMA configuration to not rely on device id

We are wrongly relying on device id for the DMA configuration
which can lead to wrong DMA channel being selected.

Fix the issue by using the standard resources like we should.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -90,17 +90,6 @@
 #define OMAP_MMC_CMDTYPE_AC	2
 #define OMAP_MMC_CMDTYPE_ADTC	3
 
-#define OMAP_DMA_MMC_TX		21
-#define OMAP_DMA_MMC_RX		22
-#define OMAP_DMA_MMC2_TX	54
-#define OMAP_DMA_MMC2_RX	55
-
-#define OMAP24XX_DMA_MMC2_TX	47
-#define OMAP24XX_DMA_MMC2_RX	48
-#define OMAP24XX_DMA_MMC1_TX	61
-#define OMAP24XX_DMA_MMC1_RX	62
-
-
 #define DRIVER_NAME "mmci-omap"
 
 /* Specifies how often in millisecs to poll for card status changes
@@ -1331,7 +1320,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	struct mmc_omap_host *host = NULL;
 	struct resource *res;
 	dma_cap_mask_t mask;
-	unsigned sig;
+	unsigned sig = 0;
 	int i, ret = 0;
 	int irq;
 
@@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	host->dma_tx_burst = -1;
 	host->dma_rx_burst = -1;
 
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
-	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+	if (res)
+		sig = res->start;
+	host->dma_tx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "tx");
 	if (!host->dma_tx)
 		dev_warn(host->dev, "unable to obtain TX DMA engine channel %u\n",
 			sig);
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_RX : OMAP24XX_DMA_MMC2_RX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_RX : OMAP_DMA_MMC2_RX;
-	host->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+	if (res)
+		sig = res->start;
+	host->dma_rx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "rx");
 	if (!host->dma_rx)
 		dev_warn(host->dev, "unable to obtain RX DMA engine channel %u\n",
 			sig);

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131113 18:36]:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
> 
> Fix the issue by using the standard resources like we should.
> 
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

Looks like we need sig initialized in this patch to avoid some
uninitialized warnings.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 14 Nov 2013 15:25:06 -0800
Subject: [PATCH] mmc: omap: Fix DMA configuration to not rely on device id

We are wrongly relying on device id for the DMA configuration
which can lead to wrong DMA channel being selected.

Fix the issue by using the standard resources like we should.

Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -90,17 +90,6 @@
 #define OMAP_MMC_CMDTYPE_AC	2
 #define OMAP_MMC_CMDTYPE_ADTC	3
 
-#define OMAP_DMA_MMC_TX		21
-#define OMAP_DMA_MMC_RX		22
-#define OMAP_DMA_MMC2_TX	54
-#define OMAP_DMA_MMC2_RX	55
-
-#define OMAP24XX_DMA_MMC2_TX	47
-#define OMAP24XX_DMA_MMC2_RX	48
-#define OMAP24XX_DMA_MMC1_TX	61
-#define OMAP24XX_DMA_MMC1_RX	62
-
-
 #define DRIVER_NAME "mmci-omap"
 
 /* Specifies how often in millisecs to poll for card status changes
@@ -1331,7 +1320,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	struct mmc_omap_host *host = NULL;
 	struct resource *res;
 	dma_cap_mask_t mask;
-	unsigned sig;
+	unsigned sig = 0;
 	int i, ret = 0;
 	int irq;
 
@@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
 	host->dma_tx_burst = -1;
 	host->dma_rx_burst = -1;
 
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
-	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+	if (res)
+		sig = res->start;
+	host->dma_tx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "tx");
 	if (!host->dma_tx)
 		dev_warn(host->dev, "unable to obtain TX DMA engine channel %u\n",
 			sig);
-	if (mmc_omap2())
-		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_RX : OMAP24XX_DMA_MMC2_RX;
-	else
-		sig = host->id == 0 ? OMAP_DMA_MMC_RX : OMAP_DMA_MMC2_RX;
-	host->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+	if (res)
+		sig = res->start;
+	host->dma_rx = dma_request_slave_channel_compat(mask,
+				omap_dma_filter_fn, &sig, &pdev->dev, "rx");
 	if (!host->dma_rx)
 		dev_warn(host->dev, "unable to obtain RX DMA engine channel %u\n",
 			sig);

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Linus Walleij]

On Thu, Nov 14, 2013 at 3:35 AM, Tony Lindgren <tony@atomide.com> wrote:

> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
>
> The change reorganized twl_direction_out() and twl_set() and swapped
> the function names around in the process. While doing that, a bug got
> introduced that's not obvious while reading the patch as it appears
> as no change to the code.
>
> The bug is we now call function twl4030_set_gpio_dataout() twice in
> both twl_direction_out() and twl_set(). Instead, we should first
> call twl_direction_out() in twl_direction_out() followed by
> twl4030_set_gpio_dataout() in twl_set().
>
> This regression probably has gone unnoticed for a long time as the
> bootloader may have set the GPIO direction properly in many cases.
> This fixes at least the LCD panel not turning on omap3 LDP for
> example.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: linux-gpio@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

Sure:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Linus Walleij]

On Thu, Nov 14, 2013 at 3:35 AM, Tony Lindgren <tony@atomide.com> wrote:

> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
>
> The change reorganized twl_direction_out() and twl_set() and swapped
> the function names around in the process. While doing that, a bug got
> introduced that's not obvious while reading the patch as it appears
> as no change to the code.
>
> The bug is we now call function twl4030_set_gpio_dataout() twice in
> both twl_direction_out() and twl_set(). Instead, we should first
> call twl_direction_out() in twl_direction_out() followed by
> twl4030_set_gpio_dataout() in twl_set().
>
> This regression probably has gone unnoticed for a long time as the
> bootloader may have set the GPIO direction properly in many cases.
> This fixes at least the LCD panel not turning on omap3 LDP for
> example.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

Sure:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case

[Linus Walleij]

On Mon, Nov 18, 2013 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [131113 18:37]:
>> We still have some legacy code needing the callback functions
>> that won't work properly without platform data. To use platform
>> data for twl4030-gpio, we need to not trash the possible data.
>>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: linux-gpio@vger.kernel.org
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> ---
>>
>> If this looks OK, I'd like to merge this as a fix via arm-soc tree
>> along with the other patches in this series as my later patches
>> depend on patches in this series.
>
> Here's this one with a fix from Fengguang Wu to use struct assignment
> instead of memcpy folded in.

Looks allright:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case

[Linus Walleij]

On Mon, Nov 18, 2013 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [131113 18:37]:
>> We still have some legacy code needing the callback functions
>> that won't work properly without platform data. To use platform
>> data for twl4030-gpio, we need to not trash the possible data.
>>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: linux-gpio at vger.kernel.org
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> ---
>>
>> If this looks OK, I'd like to merge this as a fix via arm-soc tree
>> along with the other patches in this series as my later patches
>> depend on patches in this series.
>
> Here's this one with a fix from Fengguang Wu to use struct assignment
> instead of memcpy folded in.

Looks allright:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Chris Ball]

Hi Tony,

On Mon, Nov 18 2013, Tony Lindgren wrote:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
>
> Fix the issue by using the standard resources like we should.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Feel free to merge via your tree:

Acked-by: Chris Ball <cjb@laptop.org>

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Chris Ball]

Hi Tony,

On Mon, Nov 18 2013, Tony Lindgren wrote:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
>
> Fix the issue by using the standard resources like we should.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Feel free to merge via your tree:

Acked-by: Chris Ball <cjb@laptop.org>

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

Re: [PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Chris Ball]

Hi Tony,

On Thu, Nov 14 2013, Tony Lindgren wrote:
> Some features can be configured by the companion I2C chips,
> which may not be available at the probe time. Fix the issue
> by returning -EPROBE_DEFER when the MMC controller slots
> are not configured.
>
> While at it, let's also add minimal device tree support so
> omap24xx platforms can use this driver without legacy mode
> since we claim to support device tree for mach-omap2 based
> systems.
>
> Although adding the minimal device tree support is not strictly
> a fix, it does remove one of the last blockers for dropping a
> bunch of legacy platform data for mach-omap2.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Feel free to merge via your tree:

Acked-by: Chris Ball <cjb@laptop.org>

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

[PATCH 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree

[Chris Ball]

Hi Tony,

On Thu, Nov 14 2013, Tony Lindgren wrote:
> Some features can be configured by the companion I2C chips,
> which may not be available at the probe time. Fix the issue
> by returning -EPROBE_DEFER when the MMC controller slots
> are not configured.
>
> While at it, let's also add minimal device tree support so
> omap24xx platforms can use this driver without legacy mode
> since we claim to support device tree for mach-omap2 based
> systems.
>
> Although adding the minimal device tree support is not strictly
> a fix, it does remove one of the last blockers for dropping a
> bunch of legacy platform data for mach-omap2.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Feel free to merge via your tree:

Acked-by: Chris Ball <cjb@laptop.org>

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Chris Ball <cjb@laptop.org> [131126 15:35]:
> Hi Tony,
> 
> On Mon, Nov 18 2013, Tony Lindgren wrote:
> > We are wrongly relying on device id for the DMA configuration
> > which can lead to wrong DMA channel being selected.
> >
> > Fix the issue by using the standard resources like we should.
> >
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: linux-mmc@vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Feel free to merge via your tree:
> 
> Acked-by: Chris Ball <cjb@laptop.org>

OK thanks will merge both mmc fixes.

Tony

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Chris Ball <cjb@laptop.org> [131126 15:35]:
> Hi Tony,
> 
> On Mon, Nov 18 2013, Tony Lindgren wrote:
> > We are wrongly relying on device id for the DMA configuration
> > which can lead to wrong DMA channel being selected.
> >
> > Fix the issue by using the standard resources like we should.
> >
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: linux-mmc at vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Feel free to merge via your tree:
> 
> Acked-by: Chris Ball <cjb@laptop.org>

OK thanks will merge both mmc fixes.

Tony

Re: [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131116 07:17]:
>
> Here's what I was thinking with the reg-io-width-mask. Anybody
> have comments on using reg-io-width vs reg-io-width-mask?
...

> --- a/drivers/net/ethernet/smsc/smc91x.c
> +++ b/drivers/net/ethernet/smsc/smc91x.c
> @@ -2222,11 +2234,31 @@ static int smc_drv_probe(struct platform_device *pdev)
>  	 */
>  
>  	lp = netdev_priv(ndev);
> +	lp->cfg.flags = 0;
>  
>  	if (pd) {
>  		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
>  		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
> -	} else {
> +	}
> +
> +#if IS_BUILTIN(CONFIG_OF)
> +	match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
> +	if (match) {
> +		u32 val;
> +
> +		of_property_read_u32(np, "reg-io-width", &val);
> +		if (val == 0)
> +			lp->cfg.flags |= SMC91X_USE_16BIT;
> +		if (val & 1)
> +			lp->cfg.flags |= SMC91X_USE_8BIT;
> +		if (val & 2)
> +			lp->cfg.flags |= SMC91X_USE_16BIT;
> +		if (val & 4)
> +			lp->cfg.flags |= SMC91X_USE_32BIT;
> +	}
> +#endif
> +
> +	if (!pd && !match) {
>  		lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
>  		lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
>  		lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;

Looks this patch is missing the check for the return value for
of_property_read_u32(), will repost this patch separately as the
others in this series are out of the way now.

Regards,

Tony

[PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131116 07:17]:
>
> Here's what I was thinking with the reg-io-width-mask. Anybody
> have comments on using reg-io-width vs reg-io-width-mask?
...

> --- a/drivers/net/ethernet/smsc/smc91x.c
> +++ b/drivers/net/ethernet/smsc/smc91x.c
> @@ -2222,11 +2234,31 @@ static int smc_drv_probe(struct platform_device *pdev)
>  	 */
>  
>  	lp = netdev_priv(ndev);
> +	lp->cfg.flags = 0;
>  
>  	if (pd) {
>  		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
>  		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
> -	} else {
> +	}
> +
> +#if IS_BUILTIN(CONFIG_OF)
> +	match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
> +	if (match) {
> +		u32 val;
> +
> +		of_property_read_u32(np, "reg-io-width", &val);
> +		if (val == 0)
> +			lp->cfg.flags |= SMC91X_USE_16BIT;
> +		if (val & 1)
> +			lp->cfg.flags |= SMC91X_USE_8BIT;
> +		if (val & 2)
> +			lp->cfg.flags |= SMC91X_USE_16BIT;
> +		if (val & 4)
> +			lp->cfg.flags |= SMC91X_USE_32BIT;
> +	}
> +#endif
> +
> +	if (!pd && !match) {
>  		lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
>  		lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
>  		lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;

Looks this patch is missing the check for the return value for
of_property_read_u32(), will repost this patch separately as the
others in this series are out of the way now.

Regards,

Tony

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi Chris

On Tue, 26 Nov 2013 18:33:50 -0500
Chris Ball <cjb@laptop.org> wrote:

> Hi Tony,
> 
> On Mon, Nov 18 2013, Tony Lindgren wrote:
> > We are wrongly relying on device id for the DMA configuration
> > which can lead to wrong DMA channel being selected.
> >
> > Fix the issue by using the standard resources like we should.
> >
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: linux-mmc@vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Feel free to merge via your tree:
> 
> Acked-by: Chris Ball <cjb@laptop.org>
> 
Can you enlighten me what's the proper way to get patches to mmc since
I cannot figure out working methodology from MAINTAINERS file?

I happened to notice that Tony had this similar patch in linux-omap
list I sent first time already September to you and linux-mmc (sorry
linux-omap folks, I didn't want to spam multiple lists):

http://www.spinics.net/lists/linux-mmc/msg22137.html

After that I've resend the set a few times including a fix to
user triggable NULL pointer dereference:

http://www.spinics.net/lists/linux-mmc/msg22610.html

I'm fine if mmc patches should go through other subsystems but at least
it should be documented in MAINTAINERS file.

-- 
Jarkko

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi Chris

On Tue, 26 Nov 2013 18:33:50 -0500
Chris Ball <cjb@laptop.org> wrote:

> Hi Tony,
> 
> On Mon, Nov 18 2013, Tony Lindgren wrote:
> > We are wrongly relying on device id for the DMA configuration
> > which can lead to wrong DMA channel being selected.
> >
> > Fix the issue by using the standard resources like we should.
> >
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: linux-mmc at vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> Feel free to merge via your tree:
> 
> Acked-by: Chris Ball <cjb@laptop.org>
> 
Can you enlighten me what's the proper way to get patches to mmc since
I cannot figure out working methodology from MAINTAINERS file?

I happened to notice that Tony had this similar patch in linux-omap
list I sent first time already September to you and linux-mmc (sorry
linux-omap folks, I didn't want to spam multiple lists):

http://www.spinics.net/lists/linux-mmc/msg22137.html

After that I've resend the set a few times including a fix to
user triggable NULL pointer dereference:

http://www.spinics.net/lists/linux-mmc/msg22610.html

I'm fine if mmc patches should go through other subsystems but at least
it should be documented in MAINTAINERS file.

-- 
Jarkko

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula <jarkko.nikula@bitmer.com> [131127 12:55]:
> Hi Chris
> 
> On Tue, 26 Nov 2013 18:33:50 -0500
> Chris Ball <cjb@laptop.org> wrote:
> 
> > Hi Tony,
> > 
> > On Mon, Nov 18 2013, Tony Lindgren wrote:
> > > We are wrongly relying on device id for the DMA configuration
> > > which can lead to wrong DMA channel being selected.
> > >
> > > Fix the issue by using the standard resources like we should.
> > >
> > > Cc: Chris Ball <cjb@laptop.org>
> > > Cc: linux-mmc@vger.kernel.org
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > Feel free to merge via your tree:
> > 
> > Acked-by: Chris Ball <cjb@laptop.org>
> > 
> Can you enlighten me what's the proper way to get patches to mmc since
> I cannot figure out working methodology from MAINTAINERS file?
> 
> I happened to notice that Tony had this similar patch in linux-omap
> list I sent first time already September to you and linux-mmc (sorry
> linux-omap folks, I didn't want to spam multiple lists):
> 
> http://www.spinics.net/lists/linux-mmc/msg22137.html
> 
> After that I've resend the set a few times including a fix to
> user triggable NULL pointer dereference:
> 
> http://www.spinics.net/lists/linux-mmc/msg22610.html
> 
> I'm fine if mmc patches should go through other subsystems but at least
> it should be documented in MAINTAINERS file.

Bummer, sounds like some duplicate work could have been avoided :(
I suggest resend to Chris and linux-mmc one more time as Chris should
pick up the MMC patches in general.

I've been just trying to get things working in general for v3.13-rc
series for omaps with device tree based booting and patching all over
the place. This is to make it easy for us to just drop the legacy
platform based booting for v3.14 while keeping things working.

Chris, as far as I'm concerned, Aaro and Jarkko are good people to
review and ack the drivers/mmc/omap.c patches, so adding Aaro to
Cc as well.

Regards,

Tony

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula <jarkko.nikula@bitmer.com> [131127 12:55]:
> Hi Chris
> 
> On Tue, 26 Nov 2013 18:33:50 -0500
> Chris Ball <cjb@laptop.org> wrote:
> 
> > Hi Tony,
> > 
> > On Mon, Nov 18 2013, Tony Lindgren wrote:
> > > We are wrongly relying on device id for the DMA configuration
> > > which can lead to wrong DMA channel being selected.
> > >
> > > Fix the issue by using the standard resources like we should.
> > >
> > > Cc: Chris Ball <cjb@laptop.org>
> > > Cc: linux-mmc at vger.kernel.org
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > Feel free to merge via your tree:
> > 
> > Acked-by: Chris Ball <cjb@laptop.org>
> > 
> Can you enlighten me what's the proper way to get patches to mmc since
> I cannot figure out working methodology from MAINTAINERS file?
> 
> I happened to notice that Tony had this similar patch in linux-omap
> list I sent first time already September to you and linux-mmc (sorry
> linux-omap folks, I didn't want to spam multiple lists):
> 
> http://www.spinics.net/lists/linux-mmc/msg22137.html
> 
> After that I've resend the set a few times including a fix to
> user triggable NULL pointer dereference:
> 
> http://www.spinics.net/lists/linux-mmc/msg22610.html
> 
> I'm fine if mmc patches should go through other subsystems but at least
> it should be documented in MAINTAINERS file.

Bummer, sounds like some duplicate work could have been avoided :(
I suggest resend to Chris and linux-mmc one more time as Chris should
pick up the MMC patches in general.

I've been just trying to get things working in general for v3.13-rc
series for omaps with device tree based booting and patching all over
the place. This is to make it easy for us to just drop the legacy
platform based booting for v3.14 while keeping things working.

Chris, as far as I'm concerned, Aaro and Jarkko are good people to
review and ack the drivers/mmc/omap.c patches, so adding Aaro to
Cc as well.

Regards,

Tony

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Chris Ball]

Hi,

On Wed, Nov 27 2013, Jarkko Nikula wrote:
> Can you enlighten me what's the proper way to get patches to mmc since
> I cannot figure out working methodology from MAINTAINERS file?

Sorry about this, Jarkko.

Since I don't have omap.c hardware, I'm generally going to wait for
a Tested-by/Acked-by from someone else on patches like these.  We
actually have a maintainer already listed for the driver, Jarkko
Lavinen <jarkko.lavinen@nokia.com>.

So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
an update?  Feel free to send me patches to it.  Either way, I'll
start treating Aaro and Jarkko (Nikula) as maintainers for this
driver.

Thanks!

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Chris Ball]

Hi,

On Wed, Nov 27 2013, Jarkko Nikula wrote:
> Can you enlighten me what's the proper way to get patches to mmc since
> I cannot figure out working methodology from MAINTAINERS file?

Sorry about this, Jarkko.

Since I don't have omap.c hardware, I'm generally going to wait for
a Tested-by/Acked-by from someone else on patches like these.  We
actually have a maintainer already listed for the driver, Jarkko
Lavinen <jarkko.lavinen@nokia.com>.

So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
an update?  Feel free to send me patches to it.  Either way, I'll
start treating Aaro and Jarkko (Nikula) as maintainers for this
driver.

Thanks!

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Chris Ball <cjb@laptop.org> [131127 13:48]:
> Hi,
> 
> On Wed, Nov 27 2013, Jarkko Nikula wrote:
> > Can you enlighten me what's the proper way to get patches to mmc since
> > I cannot figure out working methodology from MAINTAINERS file?
> 
> Sorry about this, Jarkko.
> 
> Since I don't have omap.c hardware, I'm generally going to wait for
> a Tested-by/Acked-by from someone else on patches like these.  We
> actually have a maintainer already listed for the driver, Jarkko
> Lavinen <jarkko.lavinen@nokia.com>.
> 
> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
> an update?  Feel free to send me patches to it.  Either way, I'll
> start treating Aaro and Jarkko (Nikula) as maintainers for this
> driver.

Hmm looks like here's a reasonably recent update that we've missed
from Jarkko Lavinen to update his email address:

http://lkml.org/lkml/2013/10/4/142

I've updated Jarkko Lavinen's address in this mail, we should
probably also patch the MAINTAINERS file for that, and then see if
Aaro and Jarkko Nikula are interested to be listed there as well.

Regards,

Tony

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Chris Ball <cjb@laptop.org> [131127 13:48]:
> Hi,
> 
> On Wed, Nov 27 2013, Jarkko Nikula wrote:
> > Can you enlighten me what's the proper way to get patches to mmc since
> > I cannot figure out working methodology from MAINTAINERS file?
> 
> Sorry about this, Jarkko.
> 
> Since I don't have omap.c hardware, I'm generally going to wait for
> a Tested-by/Acked-by from someone else on patches like these.  We
> actually have a maintainer already listed for the driver, Jarkko
> Lavinen <jarkko.lavinen@nokia.com>.
> 
> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
> an update?  Feel free to send me patches to it.  Either way, I'll
> start treating Aaro and Jarkko (Nikula) as maintainers for this
> driver.

Hmm looks like here's a reasonably recent update that we've missed
from Jarkko Lavinen to update his email address:

http://lkml.org/lkml/2013/10/4/142

I've updated Jarkko Lavinen's address in this mail, we should
probably also patch the MAINTAINERS file for that, and then see if
Aaro and Jarkko Nikula are interested to be listed there as well.

Regards,

Tony

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi

On 11/27/2013 11:59 PM, Tony Lindgren wrote:
> * Chris Ball <cjb@laptop.org> [131127 13:48]:
>> Hi,
>>
>> On Wed, Nov 27 2013, Jarkko Nikula wrote:
>>> Can you enlighten me what's the proper way to get patches to mmc since
>>> I cannot figure out working methodology from MAINTAINERS file?
>>
>> Sorry about this, Jarkko.
>>
>> Since I don't have omap.c hardware, I'm generally going to wait for
>> a Tested-by/Acked-by from someone else on patches like these.  We
>> actually have a maintainer already listed for the driver, Jarkko
>> Lavinen <jarkko.lavinen@nokia.com>.
>>
>> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
>> an update?  Feel free to send me patches to it.  Either way, I'll
>> start treating Aaro and Jarkko (Nikula) as maintainers for this
>> driver.
> 
Oh, I see. I even didn't check ./scripts/get_maintainer.pl nor check
MAINTAINERS file further than main MMC entry as I knew Jarkko L. is not
working anymore for Nokia. Sorry, we should have noticed that.

> Hmm looks like here's a reasonably recent update that we've missed
> from Jarkko Lavinen to update his email address:
> 
> http://lkml.org/lkml/2013/10/4/142
> 
> I've updated Jarkko Lavinen's address in this mail, we should
> probably also patch the MAINTAINERS file for that, and then see if
> Aaro and Jarkko Nikula are interested to be listed there as well.
> 
I can volunteer. Not that I know much about mmc but I like to keep my
legacy hw still running :-)

-- 
Jarkko

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi

On 11/27/2013 11:59 PM, Tony Lindgren wrote:
> * Chris Ball <cjb@laptop.org> [131127 13:48]:
>> Hi,
>>
>> On Wed, Nov 27 2013, Jarkko Nikula wrote:
>>> Can you enlighten me what's the proper way to get patches to mmc since
>>> I cannot figure out working methodology from MAINTAINERS file?
>>
>> Sorry about this, Jarkko.
>>
>> Since I don't have omap.c hardware, I'm generally going to wait for
>> a Tested-by/Acked-by from someone else on patches like these.  We
>> actually have a maintainer already listed for the driver, Jarkko
>> Lavinen <jarkko.lavinen@nokia.com>.
>>
>> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
>> an update?  Feel free to send me patches to it.  Either way, I'll
>> start treating Aaro and Jarkko (Nikula) as maintainers for this
>> driver.
> 
Oh, I see. I even didn't check ./scripts/get_maintainer.pl nor check
MAINTAINERS file further than main MMC entry as I knew Jarkko L. is not
working anymore for Nokia. Sorry, we should have noticed that.

> Hmm looks like here's a reasonably recent update that we've missed
> from Jarkko Lavinen to update his email address:
> 
> http://lkml.org/lkml/2013/10/4/142
> 
> I've updated Jarkko Lavinen's address in this mail, we should
> probably also patch the MAINTAINERS file for that, and then see if
> Aaro and Jarkko Nikula are interested to be listed there as well.
> 
I can volunteer. Not that I know much about mmc but I like to keep my
legacy hw still running :-)

-- 
Jarkko

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi

On 11/27/2013 11:37 PM, Tony Lindgren wrote:
> * Jarkko Nikula <jarkko.nikula@bitmer.com> [131127 12:55]:
> Bummer, sounds like some duplicate work could have been avoided :(
> I suggest resend to Chris and linux-mmc one more time as Chris should
> pick up the MMC patches in general.
> 
Before that should Chris merge your 2 patches in order to avoid couple
trivial merge conflicts with my set when linux-omap and mmc are merged?

-- 
Jarkko

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi

On 11/27/2013 11:37 PM, Tony Lindgren wrote:
> * Jarkko Nikula <jarkko.nikula@bitmer.com> [131127 12:55]:
> Bummer, sounds like some duplicate work could have been avoided :(
> I suggest resend to Chris and linux-mmc one more time as Chris should
> pick up the MMC patches in general.
> 
Before that should Chris merge your 2 patches in order to avoid couple
trivial merge conflicts with my set when linux-omap and mmc are merged?

-- 
Jarkko

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula <jarkko.nikula@bitmer.com> [131128 09:03]:
> Hi
> 
> On 11/27/2013 11:37 PM, Tony Lindgren wrote:
> > * Jarkko Nikula <jarkko.nikula@bitmer.com> [131127 12:55]:
> > Bummer, sounds like some duplicate work could have been avoided :(
> > I suggest resend to Chris and linux-mmc one more time as Chris should
> > pick up the MMC patches in general.
> > 
> Before that should Chris merge your 2 patches in order to avoid couple
> trivial merge conflicts with my set when linux-omap and mmc are merged?

Those are already queued to arm-soc/fixes branch and should hit the
mainline tree within next few days, hopefully before -rc2 so it's probably
to wait for that for that for further fixes.

Regards,

Tony

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula <jarkko.nikula@bitmer.com> [131128 09:03]:
> Hi
> 
> On 11/27/2013 11:37 PM, Tony Lindgren wrote:
> > * Jarkko Nikula <jarkko.nikula@bitmer.com> [131127 12:55]:
> > Bummer, sounds like some duplicate work could have been avoided :(
> > I suggest resend to Chris and linux-mmc one more time as Chris should
> > pick up the MMC patches in general.
> > 
> Before that should Chris merge your 2 patches in order to avoid couple
> trivial merge conflicts with my set when linux-omap and mmc are merged?

Those are already queued to arm-soc/fixes branch and should hit the
mainline tree within next few days, hopefully before -rc2 so it's probably
to wait for that for that for further fixes.

Regards,

Tony

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula <jarkko.nikula@bitmer.com> [131128 08:14]:
> Hi
> 
> On 11/27/2013 11:59 PM, Tony Lindgren wrote:
> > * Chris Ball <cjb@laptop.org> [131127 13:48]:
> >> Hi,
> >>
> >> On Wed, Nov 27 2013, Jarkko Nikula wrote:
> >>> Can you enlighten me what's the proper way to get patches to mmc since
> >>> I cannot figure out working methodology from MAINTAINERS file?
> >>
> >> Sorry about this, Jarkko.
> >>
> >> Since I don't have omap.c hardware, I'm generally going to wait for
> >> a Tested-by/Acked-by from someone else on patches like these.  We
> >> actually have a maintainer already listed for the driver, Jarkko
> >> Lavinen <jarkko.lavinen@nokia.com>.
> >>
> >> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
> >> an update?  Feel free to send me patches to it.  Either way, I'll
> >> start treating Aaro and Jarkko (Nikula) as maintainers for this
> >> driver.
> > 
> Oh, I see. I even didn't check ./scripts/get_maintainer.pl nor check
> MAINTAINERS file further than main MMC entry as I knew Jarkko L. is not
> working anymore for Nokia. Sorry, we should have noticed that.
> 
> > Hmm looks like here's a reasonably recent update that we've missed
> > from Jarkko Lavinen to update his email address:
> > 
> > http://lkml.org/lkml/2013/10/4/142
> > 
> > I've updated Jarkko Lavinen's address in this mail, we should
> > probably also patch the MAINTAINERS file for that, and then see if
> > Aaro and Jarkko Nikula are interested to be listed there as well.
> > 
> I can volunteer. Not that I know much about mmc but I like to keep my
> legacy hw still running :-)

Sounds good to me, good to hear :)

Regards,

Tony

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula <jarkko.nikula@bitmer.com> [131128 08:14]:
> Hi
> 
> On 11/27/2013 11:59 PM, Tony Lindgren wrote:
> > * Chris Ball <cjb@laptop.org> [131127 13:48]:
> >> Hi,
> >>
> >> On Wed, Nov 27 2013, Jarkko Nikula wrote:
> >>> Can you enlighten me what's the proper way to get patches to mmc since
> >>> I cannot figure out working methodology from MAINTAINERS file?
> >>
> >> Sorry about this, Jarkko.
> >>
> >> Since I don't have omap.c hardware, I'm generally going to wait for
> >> a Tested-by/Acked-by from someone else on patches like these.  We
> >> actually have a maintainer already listed for the driver, Jarkko
> >> Lavinen <jarkko.lavinen@nokia.com>.
> >>
> >> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
> >> an update?  Feel free to send me patches to it.  Either way, I'll
> >> start treating Aaro and Jarkko (Nikula) as maintainers for this
> >> driver.
> > 
> Oh, I see. I even didn't check ./scripts/get_maintainer.pl nor check
> MAINTAINERS file further than main MMC entry as I knew Jarkko L. is not
> working anymore for Nokia. Sorry, we should have noticed that.
> 
> > Hmm looks like here's a reasonably recent update that we've missed
> > from Jarkko Lavinen to update his email address:
> > 
> > http://lkml.org/lkml/2013/10/4/142
> > 
> > I've updated Jarkko Lavinen's address in this mail, we should
> > probably also patch the MAINTAINERS file for that, and then see if
> > Aaro and Jarkko Nikula are interested to be listed there as well.
> > 
> I can volunteer. Not that I know much about mmc but I like to keep my
> legacy hw still running :-)

Sounds good to me, good to hear :)

Regards,

Tony

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Joel Fernandes]

On 11/13/2013 08:35 PM, Tony Lindgren wrote:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
> 
> Fix the issue by using the standard resources like we should.
> 
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
> 
>  drivers/mmc/host/omap.c | 32 +++++++++++---------------------
>  1 file changed, 11 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index b94f38e..ed56868 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -90,17 +90,6 @@
>  #define OMAP_MMC_CMDTYPE_AC	2
>  #define OMAP_MMC_CMDTYPE_ADTC	3
>  
> -#define OMAP_DMA_MMC_TX		21
> -#define OMAP_DMA_MMC_RX		22
> -#define OMAP_DMA_MMC2_TX	54
> -#define OMAP_DMA_MMC2_RX	55
> -
> -#define OMAP24XX_DMA_MMC2_TX	47
> -#define OMAP24XX_DMA_MMC2_RX	48
> -#define OMAP24XX_DMA_MMC1_TX	61
> -#define OMAP24XX_DMA_MMC1_RX	62
> -
> -
>  #define DRIVER_NAME "mmci-omap"
>  
>  /* Specifies how often in millisecs to poll for card status changes
> @@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
>  	host->dma_tx_burst = -1;
>  	host->dma_rx_burst = -1;
>  
> -	if (mmc_omap2())
> -		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
> -	else
> -		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
> -	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> +	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> +	if (res)
> +		sig = res->start;
> +	host->dma_tx = dma_request_slave_channel_compat(mask,
> +				omap_dma_filter_fn, &sig, &pdev->dev, "tx");

Minor comment, since we're moving to DT-only for platforms using this driver
(hope I'm right about that), why not just do:
	dma_request_slave_channel_(&pdev->dev, "tx");

IORESOURCE_DMA is not created by OF layer so I guess no need to call
platform_get_resource either.

thanks,

-Joel

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Joel Fernandes]

On 11/13/2013 08:35 PM, Tony Lindgren wrote:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
> 
> Fix the issue by using the standard resources like we should.
> 
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
> 
> ---
> 
>  drivers/mmc/host/omap.c | 32 +++++++++++---------------------
>  1 file changed, 11 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index b94f38e..ed56868 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -90,17 +90,6 @@
>  #define OMAP_MMC_CMDTYPE_AC	2
>  #define OMAP_MMC_CMDTYPE_ADTC	3
>  
> -#define OMAP_DMA_MMC_TX		21
> -#define OMAP_DMA_MMC_RX		22
> -#define OMAP_DMA_MMC2_TX	54
> -#define OMAP_DMA_MMC2_RX	55
> -
> -#define OMAP24XX_DMA_MMC2_TX	47
> -#define OMAP24XX_DMA_MMC2_RX	48
> -#define OMAP24XX_DMA_MMC1_TX	61
> -#define OMAP24XX_DMA_MMC1_RX	62
> -
> -
>  #define DRIVER_NAME "mmci-omap"
>  
>  /* Specifies how often in millisecs to poll for card status changes
> @@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
>  	host->dma_tx_burst = -1;
>  	host->dma_rx_burst = -1;
>  
> -	if (mmc_omap2())
> -		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
> -	else
> -		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
> -	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> +	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> +	if (res)
> +		sig = res->start;
> +	host->dma_tx = dma_request_slave_channel_compat(mask,
> +				omap_dma_filter_fn, &sig, &pdev->dev, "tx");

Minor comment, since we're moving to DT-only for platforms using this driver
(hope I'm right about that), why not just do:
	dma_request_slave_channel_(&pdev->dev, "tx");

IORESOURCE_DMA is not created by OF layer so I guess no need to call
platform_get_resource either.

thanks,

-Joel

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Joel Fernandes <joelf@ti.com> [131129 16:39]:
> On 11/13/2013 08:35 PM, Tony Lindgren wrote:
> > --- a/drivers/mmc/host/omap.c
> > +++ b/drivers/mmc/host/omap.c
> > @@ -90,17 +90,6 @@
> >  #define OMAP_MMC_CMDTYPE_AC	2
> >  #define OMAP_MMC_CMDTYPE_ADTC	3
> >  
> > -#define OMAP_DMA_MMC_TX		21
> > -#define OMAP_DMA_MMC_RX		22
> > -#define OMAP_DMA_MMC2_TX	54
> > -#define OMAP_DMA_MMC2_RX	55
> > -
> > -#define OMAP24XX_DMA_MMC2_TX	47
> > -#define OMAP24XX_DMA_MMC2_RX	48
> > -#define OMAP24XX_DMA_MMC1_TX	61
> > -#define OMAP24XX_DMA_MMC1_RX	62
> > -
> > -
> >  #define DRIVER_NAME "mmci-omap"
> >  
> >  /* Specifies how often in millisecs to poll for card status changes
> > @@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
> >  	host->dma_tx_burst = -1;
> >  	host->dma_rx_burst = -1;
> >  
> > -	if (mmc_omap2())
> > -		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
> > -	else
> > -		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
> > -	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> > +	if (res)
> > +		sig = res->start;
> > +	host->dma_tx = dma_request_slave_channel_compat(mask,
> > +				omap_dma_filter_fn, &sig, &pdev->dev, "tx");
> 
> Minor comment, since we're moving to DT-only for platforms using this driver
> (hope I'm right about that), why not just do:
> 	dma_request_slave_channel_(&pdev->dev, "tx");
> 
> IORESOURCE_DMA is not created by OF layer so I guess no need to call
> platform_get_resource either.

Well this is not the omap_hsmmc.c driver, this is the one for earlier hardware
that's available on omap1 and 2420. All the later ones use the omap_hsmmc.c
driver instead. So this one we cannot make DT only unless we make mach-omap1
DT only, which is doable, but may never happen because of the effort needed.

Most of the effort would be quite trivial, except for the conversion to use
the common clock framework.

Regards,

Tony

[PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Joel Fernandes <joelf@ti.com> [131129 16:39]:
> On 11/13/2013 08:35 PM, Tony Lindgren wrote:
> > --- a/drivers/mmc/host/omap.c
> > +++ b/drivers/mmc/host/omap.c
> > @@ -90,17 +90,6 @@
> >  #define OMAP_MMC_CMDTYPE_AC	2
> >  #define OMAP_MMC_CMDTYPE_ADTC	3
> >  
> > -#define OMAP_DMA_MMC_TX		21
> > -#define OMAP_DMA_MMC_RX		22
> > -#define OMAP_DMA_MMC2_TX	54
> > -#define OMAP_DMA_MMC2_RX	55
> > -
> > -#define OMAP24XX_DMA_MMC2_TX	47
> > -#define OMAP24XX_DMA_MMC2_RX	48
> > -#define OMAP24XX_DMA_MMC1_TX	61
> > -#define OMAP24XX_DMA_MMC1_RX	62
> > -
> > -
> >  #define DRIVER_NAME "mmci-omap"
> >  
> >  /* Specifies how often in millisecs to poll for card status changes
> > @@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev)
> >  	host->dma_tx_burst = -1;
> >  	host->dma_rx_burst = -1;
> >  
> > -	if (mmc_omap2())
> > -		sig = host->id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX;
> > -	else
> > -		sig = host->id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX;
> > -	host->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> > +	if (res)
> > +		sig = res->start;
> > +	host->dma_tx = dma_request_slave_channel_compat(mask,
> > +				omap_dma_filter_fn, &sig, &pdev->dev, "tx");
> 
> Minor comment, since we're moving to DT-only for platforms using this driver
> (hope I'm right about that), why not just do:
> 	dma_request_slave_channel_(&pdev->dev, "tx");
> 
> IORESOURCE_DMA is not created by OF layer so I guess no need to call
> platform_get_resource either.

Well this is not the omap_hsmmc.c driver, this is the one for earlier hardware
that's available on omap1 and 2420. All the later ones use the omap_hsmmc.c
driver instead. So this one we cannot make DT only unless we make mach-omap1
DT only, which is doable, but may never happen because of the effort needed.

Most of the effort would be quite trivial, except for the conversion to use
the common clock framework.

Regards,

Tony

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Roger Quadros]

Hi Tony,

On 11/14/2013 04:35 AM, Tony Lindgren wrote:
> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
> 
> The change reorganized twl_direction_out() and twl_set() and swapped
> the function names around in the process. While doing that, a bug got
> introduced that's not obvious while reading the patch as it appears
> as no change to the code.
> 
> The bug is we now call function twl4030_set_gpio_dataout() twice in
> both twl_direction_out() and twl_set(). Instead, we should first
> call twl_direction_out() in twl_direction_out() followed by
> twl4030_set_gpio_dataout() in twl_set().
> 
> This regression probably has gone unnoticed for a long time as the
> bootloader may have set the GPIO direction properly in many cases.
> This fixes at least the LCD panel not turning on omap3 LDP for
> example.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: linux-gpio@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
As one of the LED GPO is used for USB host on beagleboard, it will cause failure
of USB host probe.

I'll explain why below.
> 
> ---
>  drivers/gpio/gpio-twl4030.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 0c7e891..5738d5a 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
>  static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
>  {
>  	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
> +	int ret = -EINVAL;
>  
>  	mutex_lock(&priv->mutex);
>  	if (offset < TWL4030_GPIO_MAX)
> -		twl4030_set_gpio_dataout(offset, value);
> +		ret = twl4030_set_gpio_direction(offset, 0);

twl_direction_out() is supposed to return 0 on success and non-zero only on failure.

for (offset >= TWL4030_GPIO_MAX) i.e. LED output case we now return -EINVAL, which
causes the LED GPO set_direction_out to fail. LED outputs are always outputs so
this function shouldn't fail.

>  
>  	priv->direction |= BIT(offset);
>  	mutex_unlock(&priv->mutex);
>  
>  	twl_set(chip, offset, value);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
> 


Below is a proposed fix for this.

>From 7c36c8952ee3c7220ea21396cd3f84a1f9e9ea73 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq@ti.com>
Date: Tue, 3 Dec 2013 15:24:05 +0200
Subject: [PATCH] gpio: twl4030: Fix regression for twl gpio LED output

Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.

This causes USB host probe failures for Beagleboard C4.

[    2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests probe deferral
[    2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[    2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register regulator: -22
[    2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with error -22

direction_out/direction_in must return 0 if the operation succeeded.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/gpio/gpio-twl4030.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..0999ed1 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -294,13 +294,13 @@ out:
 static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
 {
 	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
-	int ret;
+	int ret = 0;
 
 	mutex_lock(&priv->mutex);
 	if (offset < TWL4030_GPIO_MAX)
-		ret = twl4030_set_gpio_direction(offset, 1);
+		twl4030_set_gpio_direction(offset, 1);
 	else
-		ret = -EINVAL;
+		ret = -EINVAL;	/* LED outputs can't be set as input */
 
 	if (!ret)
 		priv->direction &= ~BIT(offset);
@@ -354,18 +354,21 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
 static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
 	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
-	int ret = -EINVAL;
 
 	mutex_lock(&priv->mutex);
 	if (offset < TWL4030_GPIO_MAX)
-		ret = twl4030_set_gpio_direction(offset, 0);
+		twl4030_set_gpio_direction(offset, 0);
+
+	/*
+	 *  LED gpio's i.e. offset >= TWL4030_GPIO_MAX are always output
+	 */
 
 	priv->direction |= BIT(offset);
 	mutex_unlock(&priv->mutex);
 
 	twl_set(chip, offset, value);
 
-	return ret;
+	return 0;
 }
 
 static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
-- 
1.8.3.2

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Roger Quadros]

Hi Tony,

On 11/14/2013 04:35 AM, Tony Lindgren wrote:
> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
> 
> The change reorganized twl_direction_out() and twl_set() and swapped
> the function names around in the process. While doing that, a bug got
> introduced that's not obvious while reading the patch as it appears
> as no change to the code.
> 
> The bug is we now call function twl4030_set_gpio_dataout() twice in
> both twl_direction_out() and twl_set(). Instead, we should first
> call twl_direction_out() in twl_direction_out() followed by
> twl4030_set_gpio_dataout() in twl_set().
> 
> This regression probably has gone unnoticed for a long time as the
> bootloader may have set the GPIO direction properly in many cases.
> This fixes at least the LCD panel not turning on omap3 LDP for
> example.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.

This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
As one of the LED GPO is used for USB host on beagleboard, it will cause failure
of USB host probe.

I'll explain why below.
> 
> ---
>  drivers/gpio/gpio-twl4030.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 0c7e891..5738d5a 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
>  static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
>  {
>  	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
> +	int ret = -EINVAL;
>  
>  	mutex_lock(&priv->mutex);
>  	if (offset < TWL4030_GPIO_MAX)
> -		twl4030_set_gpio_dataout(offset, value);
> +		ret = twl4030_set_gpio_direction(offset, 0);

twl_direction_out() is supposed to return 0 on success and non-zero only on failure.

for (offset >= TWL4030_GPIO_MAX) i.e. LED output case we now return -EINVAL, which
causes the LED GPO set_direction_out to fail. LED outputs are always outputs so
this function shouldn't fail.

>  
>  	priv->direction |= BIT(offset);
>  	mutex_unlock(&priv->mutex);
>  
>  	twl_set(chip, offset, value);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
> 


Below is a proposed fix for this.

>From 7c36c8952ee3c7220ea21396cd3f84a1f9e9ea73 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq@ti.com>
Date: Tue, 3 Dec 2013 15:24:05 +0200
Subject: [PATCH] gpio: twl4030: Fix regression for twl gpio LED output

Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.

This causes USB host probe failures for Beagleboard C4.

[    2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests probe deferral
[    2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[    2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register regulator: -22
[    2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with error -22

direction_out/direction_in must return 0 if the operation succeeded.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/gpio/gpio-twl4030.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..0999ed1 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -294,13 +294,13 @@ out:
 static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
 {
 	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
-	int ret;
+	int ret = 0;
 
 	mutex_lock(&priv->mutex);
 	if (offset < TWL4030_GPIO_MAX)
-		ret = twl4030_set_gpio_direction(offset, 1);
+		twl4030_set_gpio_direction(offset, 1);
 	else
-		ret = -EINVAL;
+		ret = -EINVAL;	/* LED outputs can't be set as input */
 
 	if (!ret)
 		priv->direction &= ~BIT(offset);
@@ -354,18 +354,21 @@ static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
 static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int value)
 {
 	struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
-	int ret = -EINVAL;
 
 	mutex_lock(&priv->mutex);
 	if (offset < TWL4030_GPIO_MAX)
-		ret = twl4030_set_gpio_direction(offset, 0);
+		twl4030_set_gpio_direction(offset, 0);
+
+	/*
+	 *  LED gpio's i.e. offset >= TWL4030_GPIO_MAX are always output
+	 */
 
 	priv->direction |= BIT(offset);
 	mutex_unlock(&priv->mutex);
 
 	twl_set(chip, offset, value);
 
-	return ret;
+	return 0;
 }
 
 static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
-- 
1.8.3.2

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Linus Walleij]

On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:

(...)
> This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
> As one of the LED GPO is used for USB host on beagleboard, it will cause failure
> of USB host probe.
(...)
> Below is a proposed fix for this.

Roger, Tony: what happened with this? Have you hashed this out?
I ACK Roger's fixup too if that needs to be merged into the OMAP
tree.

Yours,
Linus Walleij

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Linus Walleij]

On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:

(...)
> This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
> As one of the LED GPO is used for USB host on beagleboard, it will cause failure
> of USB host probe.
(...)
> Below is a proposed fix for this.

Roger, Tony: what happened with this? Have you hashed this out?
I ACK Roger's fixup too if that needs to be merged into the OMAP
tree.

Yours,
Linus Walleij

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [131209 05:10]:
> On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:
> 
> (...)
> > This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
> > As one of the LED GPO is used for USB host on beagleboard, it will cause failure
> > of USB host probe.
> (...)
> > Below is a proposed fix for this.
> 
> Roger, Tony: what happened with this? Have you hashed this out?
> I ACK Roger's fixup too if that needs to be merged into the OMAP
> tree.

There's an updated version from Roger posted that I acked:

[PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output

http://lkml.org/lkml/2013/12/5/65

I also commented on the dependencies there, but basically you can
pick it up unless you want me to. Should be cc stable as well.

Regards,

Tony

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [131209 05:10]:
> On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:
> 
> (...)
> > This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
> > As one of the LED GPO is used for USB host on beagleboard, it will cause failure
> > of USB host probe.
> (...)
> > Below is a proposed fix for this.
> 
> Roger, Tony: what happened with this? Have you hashed this out?
> I ACK Roger's fixup too if that needs to be merged into the OMAP
> tree.

There's an updated version from Roger posted that I acked:

[PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output

http://lkml.org/lkml/2013/12/5/65

I also commented on the dependencies there, but basically you can
pick it up unless you want me to. Should be cc stable as well.

Regards,

Tony

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Linus Walleij]

On Mon, Dec 9, 2013 at 6:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [131209 05:10]:
>> On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:
>>
>> (...)
>> > This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
>> > As one of the LED GPO is used for USB host on beagleboard, it will cause failure
>> > of USB host probe.
>> (...)
>> > Below is a proposed fix for this.
>>
>> Roger, Tony: what happened with this? Have you hashed this out?
>> I ACK Roger's fixup too if that needs to be merged into the OMAP
>> tree.
>
> There's an updated version from Roger posted that I acked:
>
> [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output
>
> http://lkml.org/lkml/2013/12/5/65
>
> I also commented on the dependencies there, but basically you can
> pick it up unless you want me to. Should be cc stable as well.

OK I have picked this now, I'll add a CC to stable.

Yours,
Linus Walleij

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Linus Walleij]

On Mon, Dec 9, 2013 at 6:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [131209 05:10]:
>> On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:
>>
>> (...)
>> > This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
>> > As one of the LED GPO is used for USB host on beagleboard, it will cause failure
>> > of USB host probe.
>> (...)
>> > Below is a proposed fix for this.
>>
>> Roger, Tony: what happened with this? Have you hashed this out?
>> I ACK Roger's fixup too if that needs to be merged into the OMAP
>> tree.
>
> There's an updated version from Roger posted that I acked:
>
> [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output
>
> http://lkml.org/lkml/2013/12/5/65
>
> I also commented on the dependencies there, but basically you can
> pick it up unless you want me to. Should be cc stable as well.

OK I have picked this now, I'll add a CC to stable.

Yours,
Linus Walleij

Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [131210 04:18]:
> On Mon, Dec 9, 2013 at 6:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Linus Walleij <linus.walleij@linaro.org> [131209 05:10]:
> >> On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:
> >>
> >> (...)
> >> > This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
> >> > As one of the LED GPO is used for USB host on beagleboard, it will cause failure
> >> > of USB host probe.
> >> (...)
> >> > Below is a proposed fix for this.
> >>
> >> Roger, Tony: what happened with this? Have you hashed this out?
> >> I ACK Roger's fixup too if that needs to be merged into the OMAP
> >> tree.
> >
> > There's an updated version from Roger posted that I acked:
> >
> > [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output
> >
> > http://lkml.org/lkml/2013/12/5/65
> >
> > I also commented on the dependencies there, but basically you can
> > pick it up unless you want me to. Should be cc stable as well.
> 
> OK I have picked this now, I'll add a CC to stable.

Thanks!

Tony

[PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [131210 04:18]:
> On Mon, Dec 9, 2013 at 6:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Linus Walleij <linus.walleij@linaro.org> [131209 05:10]:
> >> On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros <rogerq@ti.com> wrote:
> >>
> >> (...)
> >> > This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2.
> >> > As one of the LED GPO is used for USB host on beagleboard, it will cause failure
> >> > of USB host probe.
> >> (...)
> >> > Below is a proposed fix for this.
> >>
> >> Roger, Tony: what happened with this? Have you hashed this out?
> >> I ACK Roger's fixup too if that needs to be merged into the OMAP
> >> tree.
> >
> > There's an updated version from Roger posted that I acked:
> >
> > [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output
> >
> > http://lkml.org/lkml/2013/12/5/65
> >
> > I also commented on the dependencies there, but basically you can
> > pick it up unless you want me to. Should be cc stable as well.
> 
> OK I have picked this now, I'll add a CC to stable.

Thanks!

Tony