[PATCH 00/20] mmc: mmci: Improve DT support

[PATCH 00/20] mmc: mmci: Improve DT support

[Ulf Hansson]

Step by step, improve the DT support for the mmci host driver.

This enables us to move the final pieces of platform data for mmci for ux500
into DT. We are then able to remove yet another machine specific file for ux500.

This patchset needs to be merged together. I suggest we go through Russell's
ARM tree, since most of the patches are mmci specific which he maintains -
unless someone think there is a better alternative.

I will thus seek acks from the SOC maintainers as well as the regulator
maintainers. Note, one minor patch was needed for a specific regulator used by
ux500, I assumes it will be a trivial patch to ack, but let's see. :-)

The goal is to queue this for 3.16, thus I might need to rebase the patches for
3.15 rc[n]. Still I would appreciate any comments at this point.


Ulf Hansson (20):
  mmc: mmci: Convert to the mmc gpio API
  mmc: mmci: Convert to devm functions
  mmc: mmci: Update DT documentation
  mmc: mmci: Move signal directions bits into DT include file
  mmc: mmci: Add DT bindings for signal direction
  mmc: mmci: Use the common mmc DT parser
  ARM: ux500: Add mmci signal directions in DT for href
  ARM: ux500: Convert to the common mmc DT bindings for highspeed mode
  ARM: nomadik: Convert to the common mmc DT bindings for highspeed
    mode
  ARM: u300: Convert to the common mmc DT bindings for highspeed mode
  mmc: mmci: Mark the DT bindings for highspeed mode as deprecated
  mmc: mmci: Enable MMC_CAP_CMD23
  ARM: ux500: Add the mmc capabilities flags to DT
  regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2
  ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for
    href
  ARM: ux500: Remove redundant board file for mmci platform data
  mmc: mmci: Enforce DT for signal direction
  mmc: mmci: Enforce mmc capabilities through DT
  mmc: mmci: Enforce DMA configuration through DT
  mmc: mmci: Enforce max frequency configuration through DT

 Documentation/devicetree/bindings/mmc/mmci.txt |   41 +++-
 arch/arm/boot/dts/ste-ccu9540.dts              |    6 +-
 arch/arm/boot/dts/ste-href.dtsi                |   20 +-
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi     |    4 +-
 arch/arm/boot/dts/ste-snowball.dts             |    4 +-
 arch/arm/boot/dts/ste-u300.dts                 |    4 +-
 arch/arm/mach-ux500/Makefile                   |    3 +-
 arch/arm/mach-ux500/board-mop500-sdi.c         |  166 ---------------
 arch/arm/mach-ux500/board-mop500.h             |    5 -
 arch/arm/mach-ux500/cpu-db8500.c               |    4 -
 drivers/mmc/host/mmci.c                        |  259 ++++++------------------
 drivers/mmc/host/mmci.h                        |    4 +-
 drivers/regulator/db8500-prcmu.c               |    2 +
 include/dt-bindings/mmc/mmci.h                 |   21 ++
 include/linux/amba/mmci.h                      |   42 ----
 15 files changed, 153 insertions(+), 432 deletions(-)
 delete mode 100644 arch/arm/mach-ux500/board-mop500-sdi.c
 create mode 100644 include/dt-bindings/mmc/mmci.h

-- 
1.7.9.5

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

[PATCH 01/20] mmc: mmci: Convert to the mmc gpio API

[Ulf Hansson]

To avoid duplication of code while handling card detect and write
protect GPIO pins/irqs, let's convert to use the mmc gpio API.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c |   97 ++++++++---------------------------------------
 drivers/mmc/host/mmci.h |    3 --
 2 files changed, 15 insertions(+), 85 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 771c60a..b0b81ac 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -23,6 +23,7 @@
 #include <linux/mmc/pm.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
+#include <linux/mmc/slot-gpio.h>
 #include <linux/amba/bus.h>
 #include <linux/clk.h>
 #include <linux/scatterlist.h>
@@ -1326,35 +1327,18 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	pm_runtime_put_autosuspend(mmc_dev(mmc));
 }
 
-static int mmci_get_ro(struct mmc_host *mmc)
-{
-	struct mmci_host *host = mmc_priv(mmc);
-
-	if (host->gpio_wp == -ENOSYS)
-		return -ENOSYS;
-
-	return gpio_get_value_cansleep(host->gpio_wp);
-}
-
 static int mmci_get_cd(struct mmc_host *mmc)
 {
 	struct mmci_host *host = mmc_priv(mmc);
 	struct mmci_platform_data *plat = host->plat;
-	unsigned int status;
+	unsigned int status = mmc_gpio_get_cd(mmc);
 
-	if (host->gpio_cd == -ENOSYS) {
+	if (status == -ENOSYS) {
 		if (!plat->status)
 			return 1; /* Assume always present */
 
 		status = plat->status(mmc_dev(host->mmc));
-	} else
-		status = !!gpio_get_value_cansleep(host->gpio_cd)
-			^ plat->cd_invert;
-
-	/*
-	 * Use positive logic throughout - status is zero for no card,
-	 * non-zero for card inserted.
-	 */
+	}
 	return status;
 }
 
@@ -1391,21 +1375,12 @@ static int mmci_sig_volt_switch(struct mmc_host *mmc, struct mmc_ios *ios)
 	return ret;
 }
 
-static irqreturn_t mmci_cd_irq(int irq, void *dev_id)
-{
-	struct mmci_host *host = dev_id;
-
-	mmc_detect_change(host->mmc, msecs_to_jiffies(500));
-
-	return IRQ_HANDLED;
-}
-
 static struct mmc_host_ops mmci_ops = {
 	.request	= mmci_request,
 	.pre_req	= mmci_pre_request,
 	.post_req	= mmci_post_request,
 	.set_ios	= mmci_set_ios,
-	.get_ro		= mmci_get_ro,
+	.get_ro		= mmc_gpio_get_ro,
 	.get_cd		= mmci_get_cd,
 	.start_signal_voltage_switch = mmci_sig_volt_switch,
 };
@@ -1494,10 +1469,6 @@ static int mmci_probe(struct amba_device *dev,
 	host = mmc_priv(mmc);
 	host->mmc = mmc;
 
-	host->gpio_wp = -ENOSYS;
-	host->gpio_cd = -ENOSYS;
-	host->gpio_cd_irq = -1;
-
 	host->hw_designer = amba_manf(dev);
 	host->hw_revision = amba_rev(dev);
 	dev_dbg(mmc_dev(mmc), "designer ID = 0x%02x\n", host->hw_designer);
@@ -1568,6 +1539,9 @@ static int mmci_probe(struct amba_device *dev,
 
 	mmc->caps = plat->capabilities;
 	mmc->caps2 = plat->capabilities2;
+	if (!plat->cd_invert)
+		mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+	mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
 
 	if (variant->busy_detect) {
 		mmci_ops.card_busy = mmci_card_busy;
@@ -1621,49 +1595,23 @@ static int mmci_probe(struct amba_device *dev,
 		goto err_gpio_cd;
 	}
 	if (gpio_is_valid(plat->gpio_cd)) {
-		ret = gpio_request(plat->gpio_cd, DRIVER_NAME " (cd)");
-		if (ret == 0)
-			ret = gpio_direction_input(plat->gpio_cd);
-		if (ret == 0)
-			host->gpio_cd = plat->gpio_cd;
-		else if (ret != -ENOSYS)
+		ret = mmc_gpio_request_cd(mmc, plat->gpio_cd, 0);
+		if (ret)
 			goto err_gpio_cd;
-
-		/*
-		 * A gpio pin that will detect cards when inserted and removed
-		 * will most likely want to trigger on the edges if it is
-		 * 0 when ejected and 1 when inserted (or mutatis mutandis
-		 * for the inverted case) so we request triggers on both
-		 * edges.
-		 */
-		ret = request_any_context_irq(gpio_to_irq(plat->gpio_cd),
-				mmci_cd_irq,
-				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
-				DRIVER_NAME " (cd)", host);
-		if (ret >= 0)
-			host->gpio_cd_irq = gpio_to_irq(plat->gpio_cd);
 	}
 	if (plat->gpio_wp == -EPROBE_DEFER) {
 		ret = -EPROBE_DEFER;
-		goto err_gpio_wp;
+		goto err_gpio_cd;
 	}
 	if (gpio_is_valid(plat->gpio_wp)) {
-		ret = gpio_request(plat->gpio_wp, DRIVER_NAME " (wp)");
-		if (ret == 0)
-			ret = gpio_direction_input(plat->gpio_wp);
-		if (ret == 0)
-			host->gpio_wp = plat->gpio_wp;
-		else if (ret != -ENOSYS)
-			goto err_gpio_wp;
+		ret = mmc_gpio_request_ro(mmc, plat->gpio_wp);
+		if (ret)
+			goto err_gpio_cd;
 	}
 
-	if ((host->plat->status || host->gpio_cd != -ENOSYS)
-	    && host->gpio_cd_irq < 0)
-		mmc->caps |= MMC_CAP_NEEDS_POLL;
-
 	ret = request_irq(dev->irq[0], mmci_irq, IRQF_SHARED, DRIVER_NAME " (cmd)", host);
 	if (ret)
-		goto unmap;
+		goto err_gpio_cd;
 
 	if (!dev->irq[1])
 		host->singleirq = true;
@@ -1695,14 +1643,6 @@ static int mmci_probe(struct amba_device *dev,
 
  irq0_free:
 	free_irq(dev->irq[0], host);
- unmap:
-	if (host->gpio_wp != -ENOSYS)
-		gpio_free(host->gpio_wp);
- err_gpio_wp:
-	if (host->gpio_cd_irq >= 0)
-		free_irq(host->gpio_cd_irq, host);
-	if (host->gpio_cd != -ENOSYS)
-		gpio_free(host->gpio_cd);
  err_gpio_cd:
 	iounmap(host->base);
  clk_disable:
@@ -1741,13 +1681,6 @@ static int mmci_remove(struct amba_device *dev)
 		if (!host->singleirq)
 			free_irq(dev->irq[1], host);
 
-		if (host->gpio_wp != -ENOSYS)
-			gpio_free(host->gpio_wp);
-		if (host->gpio_cd_irq >= 0)
-			free_irq(host->gpio_cd_irq, host);
-		if (host->gpio_cd != -ENOSYS)
-			gpio_free(host->gpio_cd);
-
 		iounmap(host->base);
 		clk_disable_unprepare(host->clk);
 
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 58b1b88..8fc5814 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -176,9 +176,6 @@ struct mmci_host {
 	struct mmc_data		*data;
 	struct mmc_host		*mmc;
 	struct clk		*clk;
-	int			gpio_cd;
-	int			gpio_wp;
-	int			gpio_cd_irq;
 	bool			singleirq;
 
 	spinlock_t		lock;
-- 
1.7.9.5

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

[PATCH 02/20] mmc: mmci: Convert to devm functions

[Ulf Hansson]

Converting to devm functions to simplify error handling in ->probe() and
to cleanup ->remove().

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c |   51 ++++++++++++++++++-----------------------------
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index b0b81ac..d6f20ba 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -13,6 +13,7 @@
 #include <linux/init.h>
 #include <linux/ioport.h>
 #include <linux/device.h>
+#include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
@@ -1456,15 +1457,13 @@ static int mmci_probe(struct amba_device *dev,
 	if (np)
 		mmci_dt_populate_generic_pdata(np, plat);
 
-	ret = amba_request_regions(dev, DRIVER_NAME);
-	if (ret)
-		goto out;
+	if (!devm_request_mem_region(&dev->dev, dev->res.start,
+				resource_size(&dev->res), DRIVER_NAME))
+		return -ENOMEM;
 
 	mmc = mmc_alloc_host(sizeof(struct mmci_host), &dev->dev);
-	if (!mmc) {
-		ret = -ENOMEM;
-		goto rel_regions;
-	}
+	if (!mmc)
+		return -ENOMEM;
 
 	host = mmc_priv(mmc);
 	host->mmc = mmc;
@@ -1500,8 +1499,10 @@ static int mmci_probe(struct amba_device *dev,
 		dev_dbg(mmc_dev(mmc), "eventual mclk rate: %u Hz\n",
 			host->mclk);
 	}
+
 	host->phybase = dev->res.start;
-	host->base = ioremap(dev->res.start, resource_size(&dev->res));
+	host->base = devm_ioremap(&dev->dev, host->phybase,
+				resource_size(&dev->res));
 	if (!host->base) {
 		ret = -ENOMEM;
 		goto clk_disable;
@@ -1592,34 +1593,35 @@ static int mmci_probe(struct amba_device *dev,
 
 	if (plat->gpio_cd == -EPROBE_DEFER) {
 		ret = -EPROBE_DEFER;
-		goto err_gpio_cd;
+		goto clk_disable;
 	}
 	if (gpio_is_valid(plat->gpio_cd)) {
 		ret = mmc_gpio_request_cd(mmc, plat->gpio_cd, 0);
 		if (ret)
-			goto err_gpio_cd;
+			goto clk_disable;
 	}
 	if (plat->gpio_wp == -EPROBE_DEFER) {
 		ret = -EPROBE_DEFER;
-		goto err_gpio_cd;
+		goto clk_disable;
 	}
 	if (gpio_is_valid(plat->gpio_wp)) {
 		ret = mmc_gpio_request_ro(mmc, plat->gpio_wp);
 		if (ret)
-			goto err_gpio_cd;
+			goto clk_disable;
 	}
 
-	ret = request_irq(dev->irq[0], mmci_irq, IRQF_SHARED, DRIVER_NAME " (cmd)", host);
+	ret = devm_request_irq(&dev->dev, dev->irq[0], mmci_irq, IRQF_SHARED,
+			DRIVER_NAME " (cmd)", host);
 	if (ret)
-		goto err_gpio_cd;
+		goto clk_disable;
 
 	if (!dev->irq[1])
 		host->singleirq = true;
 	else {
-		ret = request_irq(dev->irq[1], mmci_pio_irq, IRQF_SHARED,
-				  DRIVER_NAME " (pio)", host);
+		ret = devm_request_irq(&dev->dev, dev->irq[1], mmci_pio_irq,
+				IRQF_SHARED, DRIVER_NAME " (pio)", host);
 		if (ret)
-			goto irq0_free;
+			goto clk_disable;
 	}
 
 	writel(MCI_IRQENABLE, host->base + MMCIMASK0);
@@ -1641,17 +1643,10 @@ static int mmci_probe(struct amba_device *dev,
 
 	return 0;
 
- irq0_free:
-	free_irq(dev->irq[0], host);
- err_gpio_cd:
-	iounmap(host->base);
  clk_disable:
 	clk_disable_unprepare(host->clk);
  host_free:
 	mmc_free_host(mmc);
- rel_regions:
-	amba_release_regions(dev);
- out:
 	return ret;
 }
 
@@ -1677,16 +1672,8 @@ static int mmci_remove(struct amba_device *dev)
 		writel(0, host->base + MMCIDATACTRL);
 
 		mmci_dma_release(host);
-		free_irq(dev->irq[0], host);
-		if (!host->singleirq)
-			free_irq(dev->irq[1], host);
-
-		iounmap(host->base);
 		clk_disable_unprepare(host->clk);
-
 		mmc_free_host(mmc);
-
-		amba_release_regions(dev);
 	}
 
 	return 0;
-- 
1.7.9.5

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

[PATCH 03/20] mmc: mmci: Update DT documentation

[Ulf Hansson]

Document how to configure the regulator supplies and add an example of
a typical mmci DT node.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 Documentation/devicetree/bindings/mmc/mmci.txt |   35 ++++++++++++++++++++++--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
index 2b584ca..d167562 100644
--- a/Documentation/devicetree/bindings/mmc/mmci.txt
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -9,7 +9,38 @@ by mmc.txt and the properties used by the mmci driver.
 Required properties:
 - compatible             : contains "arm,pl18x", "arm,primecell".
 - arm,primecell-periphid : contains the PrimeCell Peripheral ID.
+- vmmc-supply            : phandle to the regulator device tree node.
 
 Optional properties:
-- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
-- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
+- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
+- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
+- vqmmc-supply           : phandle to the regulator device tree node.
+
+Example:
+
+sdi0_per1@80126000 {
+	compatible = "arm,pl18x", "arm,primecell";
+	arm,primecell-periphid = <0x10480180>;
+	reg = <0x80126000 0x1000>;
+	interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
+
+	dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */
+	       <&dma 29 0 0x0>; /* Logical - MemToDev */
+	dma-names = "rx", "tx";
+
+	clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>;
+	clock-names = "sdi", "apb_pclk";
+
+	max-frequency = <100000000>;
+	bus-width = <4>;
+	mmc-cap-sd-highspeed;
+	mmc-cap-mmc-highspeed;
+	cd-gpios  = <&gpio2 31 0x4>; // 95
+
+	vmmc-supply = <&ab8500_ldo_aux3_reg>;
+	vqmmc-supply = <&vmmci>;
+
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&sdi0_default_mode>;
+	pinctrl-1 = <&sdi0_sleep_mode>;
+};
-- 
1.7.9.5

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

[PATCH 04/20] mmc: mmci: Move signal directions bits into DT include file

[Ulf Hansson]

These bits is currently used from platform data, but will be needed
from DT as well, so let's make them available.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 include/dt-bindings/mmc/mmci.h |   21 +++++++++++++++++++++
 include/linux/amba/mmci.h      |   14 +-------------
 2 files changed, 22 insertions(+), 13 deletions(-)
 create mode 100644 include/dt-bindings/mmc/mmci.h

diff --git a/include/dt-bindings/mmc/mmci.h b/include/dt-bindings/mmc/mmci.h
new file mode 100644
index 0000000..8c55254
--- /dev/null
+++ b/include/dt-bindings/mmc/mmci.h
@@ -0,0 +1,21 @@
+/*
+ * This header provides constants for the mmci bindings.
+ *
+ */
+
+#ifndef _DT_BINDINGS_MMC_MMCI_H
+#define _DT_BINDINGS_MMC_MMCI_H
+
+/*
+ * Bus signal direction bits.
+ * The ST Micro version does not have ROD and reuse the voltage registers
+ * for direction settings.
+ */
+#define MCI_ST_DATA2DIREN	(1 << 2)
+#define MCI_ST_CMDDIREN		(1 << 3)
+#define MCI_ST_DATA0DIREN	(1 << 4)
+#define MCI_ST_DATA31DIREN	(1 << 5)
+#define MCI_ST_FBCLKEN		(1 << 7)
+#define MCI_ST_DATA74DIREN	(1 << 8)
+
+#endif
diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h
index 32a89cf..47ff176 100644
--- a/include/linux/amba/mmci.h
+++ b/include/linux/amba/mmci.h
@@ -5,19 +5,7 @@
 #define AMBA_MMCI_H
 
 #include <linux/mmc/host.h>
-
-
-/*
- * These defines is places here due to access is needed from machine
- * configuration files. The ST Micro version does not have ROD and
- * reuse the voltage registers for direction settings.
- */
-#define MCI_ST_DATA2DIREN	(1 << 2)
-#define MCI_ST_CMDDIREN		(1 << 3)
-#define MCI_ST_DATA0DIREN	(1 << 4)
-#define MCI_ST_DATA31DIREN	(1 << 5)
-#define MCI_ST_FBCLKEN		(1 << 7)
-#define MCI_ST_DATA74DIREN	(1 << 8)
+#include <dt-bindings/mmc/mmci.h>
 
 /* Just some dummy forwarding */
 struct dma_chan;
-- 
1.7.9.5

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

[PATCH 05/20] mmc: mmci: Add DT bindings for signal direction

[Ulf Hansson]

Some variants have support for indicating the bus signal directions,
which currently are configured through platform data.

Add corresponding DT bindings to enable us to move away from using the
platform data.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
 drivers/mmc/host/mmci.c                        |    7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
index d167562..eb9ad86 100644
--- a/Documentation/devicetree/bindings/mmc/mmci.txt
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -15,6 +15,7 @@ Optional properties:
 - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
 - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
 - vqmmc-supply           : phandle to the regulator device tree node.
+- signal-direction       : a bit pattern, indicating bus signals directions.
 
 Example:
 
@@ -37,6 +38,9 @@ sdi0_per1@80126000 {
 	mmc-cap-mmc-highspeed;
 	cd-gpios  = <&gpio2 31 0x4>; // 95
 
+	signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
+			MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;
+
 	vmmc-supply = <&ab8500_ldo_aux3_reg>;
 	vqmmc-supply = <&vmmci>;
 
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index d6f20ba..76e41ba 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1390,8 +1390,15 @@ static struct mmc_host_ops mmci_ops = {
 static void mmci_dt_populate_generic_pdata(struct device_node *np,
 					struct mmci_platform_data *pdata)
 {
+	u32 sigdir = 0;
 	int bus_width = 0;
 
+	if (!of_property_read_u32(np, "signal-direction", &sigdir)) {
+		sigdir &= MCI_ST_DATA2DIREN|MCI_ST_CMDDIREN|MCI_ST_DATA0DIREN|
+			MCI_ST_DATA31DIREN|MCI_ST_FBCLKEN|MCI_ST_DATA74DIREN;
+		pdata->sigdir = sigdir;
+	}
+
 	pdata->gpio_wp = of_get_named_gpio(np, "wp-gpios", 0);
 	pdata->gpio_cd = of_get_named_gpio(np, "cd-gpios", 0);
 
-- 
1.7.9.5

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

[PATCH 06/20] mmc: mmci: Use the common mmc DT parser

[Ulf Hansson]

Let mmci DT parser only handle the specific bindings related to mmci
and extend the DT support by converting to the common mmc DT parser.

While both DT and platform data exist, DT takes precedence. If there
are supplied DT data, the card detect and write protect GPIOS are
enforced to be provided through it.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c |   92 +++++++++++++++++------------------------------
 1 file changed, 33 insertions(+), 59 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 76e41ba..2e1d1b2 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1386,58 +1386,31 @@ static struct mmc_host_ops mmci_ops = {
 	.start_signal_voltage_switch = mmci_sig_volt_switch,
 };
 
-#ifdef CONFIG_OF
 static void mmci_dt_populate_generic_pdata(struct device_node *np,
 					struct mmci_platform_data *pdata)
 {
 	u32 sigdir = 0;
-	int bus_width = 0;
 
 	if (!of_property_read_u32(np, "signal-direction", &sigdir)) {
 		sigdir &= MCI_ST_DATA2DIREN|MCI_ST_CMDDIREN|MCI_ST_DATA0DIREN|
 			MCI_ST_DATA31DIREN|MCI_ST_FBCLKEN|MCI_ST_DATA74DIREN;
 		pdata->sigdir = sigdir;
 	}
+}
 
-	pdata->gpio_wp = of_get_named_gpio(np, "wp-gpios", 0);
-	pdata->gpio_cd = of_get_named_gpio(np, "cd-gpios", 0);
-
-	if (of_get_property(np, "cd-inverted", NULL))
-		pdata->cd_invert = true;
-	else
-		pdata->cd_invert = false;
-
-	of_property_read_u32(np, "max-frequency", &pdata->f_max);
-	if (!pdata->f_max)
-		pr_warn("%s has no 'max-frequency' property\n", np->full_name);
+static int mmci_of_parse(struct device_node *np, struct mmc_host *mmc)
+{
+	int ret = mmc_of_parse(mmc);
+	if (ret)
+		return ret;
 
 	if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
-		pdata->capabilities |= MMC_CAP_MMC_HIGHSPEED;
+		mmc->caps |= MMC_CAP_MMC_HIGHSPEED;
 	if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
-		pdata->capabilities |= MMC_CAP_SD_HIGHSPEED;
+		mmc->caps |= MMC_CAP_SD_HIGHSPEED;
 
-	of_property_read_u32(np, "bus-width", &bus_width);
-	switch (bus_width) {
-	case 0 :
-		/* No bus-width supplied. */
-		break;
-	case 4 :
-		pdata->capabilities |= MMC_CAP_4_BIT_DATA;
-		break;
-	case 8 :
-		pdata->capabilities |= MMC_CAP_8_BIT_DATA;
-		break;
-	default :
-		pr_warn("%s: Unsupported bus width\n", np->full_name);
-	}
-}
-#else
-static void mmci_dt_populate_generic_pdata(struct device_node *np,
-					struct mmci_platform_data *pdata)
-{
-	return;
+	return 0;
 }
-#endif
 
 static int mmci_probe(struct amba_device *dev,
 	const struct amba_id *id)
@@ -1472,6 +1445,10 @@ static int mmci_probe(struct amba_device *dev,
 	if (!mmc)
 		return -ENOMEM;
 
+	ret = mmci_of_parse(np, mmc);
+	if (ret)
+		goto host_free;
+
 	host = mmc_priv(mmc);
 	host->mmc = mmc;
 
@@ -1525,14 +1502,15 @@ static int mmci_probe(struct amba_device *dev,
 	else
 		mmc->f_min = DIV_ROUND_UP(host->mclk, 512);
 	/*
-	 * If the platform data supplies a maximum operating
-	 * frequency, this takes precedence. Else, we fall back
-	 * to using the module parameter, which has a (low)
-	 * default value in case it is not specified. Either
-	 * value must not exceed the clock rate into the block,
-	 * of course.
+	 * If no maximum operating frequency is supplied, fall back to use
+	 * the module parameter, which has a (low) default value in case it
+	 * is not specified. Either value must not exceed the clock rate into
+	 * the block, of course. Also note that DT takes precedence over
+	 * platform data.
 	 */
-	if (plat->f_max)
+	if (mmc->f_max)
+		mmc->f_max = min(host->mclk, mmc->f_max);
+	else if (plat->f_max)
 		mmc->f_max = min(host->mclk, plat->f_max);
 	else
 		mmc->f_max = min(host->mclk, fmax);
@@ -1545,11 +1523,14 @@ static int mmci_probe(struct amba_device *dev,
 	else if (plat->ocr_mask)
 		dev_warn(mmc_dev(mmc), "Platform OCR mask is ignored\n");
 
-	mmc->caps = plat->capabilities;
-	mmc->caps2 = plat->capabilities2;
-	if (!plat->cd_invert)
-		mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
-	mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+	/* DT takes precedence over platform data. */
+	mmc->caps = np ? mmc->caps : plat->capabilities;
+	mmc->caps2 = np ? mmc->caps2 : plat->capabilities2;
+	if (!np) {
+		if (!plat->cd_invert)
+			mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+		mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+	}
 
 	if (variant->busy_detect) {
 		mmci_ops.card_busy = mmci_card_busy;
@@ -1561,7 +1542,7 @@ static int mmci_probe(struct amba_device *dev,
 	mmc->ops = &mmci_ops;
 
 	/* We support these PM capabilities. */
-	mmc->pm_caps = MMC_PM_KEEP_POWER;
+	mmc->pm_caps |= MMC_PM_KEEP_POWER;
 
 	/*
 	 * We can do SGIO
@@ -1598,20 +1579,13 @@ static int mmci_probe(struct amba_device *dev,
 	writel(0, host->base + MMCIMASK1);
 	writel(0xfff, host->base + MMCICLEAR);
 
-	if (plat->gpio_cd == -EPROBE_DEFER) {
-		ret = -EPROBE_DEFER;
-		goto clk_disable;
-	}
-	if (gpio_is_valid(plat->gpio_cd)) {
+	/* If DT, cd/wp gpios must be supplied through it. */
+	if (!np && gpio_is_valid(plat->gpio_cd)) {
 		ret = mmc_gpio_request_cd(mmc, plat->gpio_cd, 0);
 		if (ret)
 			goto clk_disable;
 	}
-	if (plat->gpio_wp == -EPROBE_DEFER) {
-		ret = -EPROBE_DEFER;
-		goto clk_disable;
-	}
-	if (gpio_is_valid(plat->gpio_wp)) {
+	if (!np && gpio_is_valid(plat->gpio_wp)) {
 		ret = mmc_gpio_request_ro(mmc, plat->gpio_wp);
 		if (ret)
 			goto clk_disable;
-- 
1.7.9.5

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

[PATCH 07/20] ARM: ux500: Add mmci signal directions in DT for href

[Ulf Hansson]

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/ste-href.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
index 6cb9b68..d50fe24 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/mmc/mmci.h>
 #include "ste-dbx5x0.dtsi"
 #include "ste-href-family-pinctrl.dtsi"
 
@@ -118,6 +119,10 @@
 			bus-width = <4>;
 			mmc-cap-sd-highspeed;
 			mmc-cap-mmc-highspeed;
+			signal-direction = <(MCI_ST_DATA2DIREN |
+						MCI_ST_CMDDIREN |
+						MCI_ST_DATA0DIREN |
+						MCI_ST_FBCLKEN)>;
 			vmmc-supply = <&ab8500_ldo_aux3_reg>;
 			vqmmc-supply = <&vmmci>;
 			pinctrl-names = "default", "sleep";
-- 
1.7.9.5

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

[PATCH 08/20] ARM: ux500: Convert to the common mmc DT bindings for highspeed mode

[Ulf Hansson]

The mmci host driver supports the common mmc DT parser, which enables
us to use the use common names instead.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/ste-ccu9540.dts  |    6 +++---
 arch/arm/boot/dts/ste-href.dtsi    |    8 ++++----
 arch/arm/boot/dts/ste-snowball.dts |    4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/ste-ccu9540.dts b/arch/arm/boot/dts/ste-ccu9540.dts
index 2295087..651c56d 100644
--- a/arch/arm/boot/dts/ste-ccu9540.dts
+++ b/arch/arm/boot/dts/ste-ccu9540.dts
@@ -38,8 +38,8 @@
 			arm,primecell-periphid = <0x10480180>;
 			max-frequency = <100000000>;
 			bus-width = <4>;
-			mmc-cap-sd-highspeed;
-			mmc-cap-mmc-highspeed;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
 			vmmc-supply = <&ab8500_ldo_aux3_reg>;
 
 			cd-gpios  = <&gpio7 6 0x4>; // 230
@@ -63,7 +63,7 @@
 			arm,primecell-periphid = <0x10480180>;
 		        max-frequency = <100000000>;
 			bus-width = <8>;
-			mmc-cap-mmc-highspeed;
+			cap-mmc-highspeed;
 			vmmc-supply = <&ab8500_ldo_aux2_reg>;
 
 			status = "okay";
diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
index d50fe24..e830c37 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -117,8 +117,8 @@
 			arm,primecell-periphid = <0x10480180>;
 			max-frequency = <100000000>;
 			bus-width = <4>;
-			mmc-cap-sd-highspeed;
-			mmc-cap-mmc-highspeed;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
 			signal-direction = <(MCI_ST_DATA2DIREN |
 						MCI_ST_CMDDIREN |
 						MCI_ST_DATA0DIREN |
@@ -149,7 +149,7 @@
 			arm,primecell-periphid = <0x10480180>;
 			max-frequency = <100000000>;
 			bus-width = <8>;
-			mmc-cap-mmc-highspeed;
+			cap-mmc-highspeed;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi2_default_mode>;
 			pinctrl-1 = <&sdi2_sleep_mode>;
@@ -162,7 +162,7 @@
 			arm,primecell-periphid = <0x10480180>;
 		        max-frequency = <100000000>;
 			bus-width = <8>;
-			mmc-cap-mmc-highspeed;
+			cap-mmc-highspeed;
 			vmmc-supply = <&ab8500_ldo_aux2_reg>;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi4_default_mode>;
diff --git a/arch/arm/boot/dts/ste-snowball.dts b/arch/arm/boot/dts/ste-snowball.dts
index a2f632d..474ef832 100644
--- a/arch/arm/boot/dts/ste-snowball.dts
+++ b/arch/arm/boot/dts/ste-snowball.dts
@@ -156,7 +156,7 @@
 			arm,primecell-periphid = <0x10480180>;
 			max-frequency = <100000000>;
 			bus-width = <4>;
-			mmc-cap-mmc-highspeed;
+			cap-mmc-highspeed;
 			vmmc-supply = <&ab8500_ldo_aux3_reg>;
 			vqmmc-supply = <&vmmci>;
 			pinctrl-names = "default", "sleep";
@@ -195,7 +195,7 @@
 			arm,primecell-periphid = <0x10480180>;
 		        max-frequency = <100000000>;
 			bus-width = <8>;
-			mmc-cap-mmc-highspeed;
+			cap-mmc-highspeed;
 			vmmc-supply = <&ab8500_ldo_aux2_reg>;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi4_default_mode>;
-- 
1.7.9.5

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

[PATCH 09/20] ARM: nomadik: Convert to the common mmc DT bindings for highspeed mode

[Ulf Hansson]

The mmci host driver supports the common mmc DT parser, which enables
us to use the use common names instead.

Cc: Alessandro Rubini <rubini-9wsNiZum9E8@public.gmane.org>
Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index 5acc044..d316c95 100644
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@ -840,8 +840,8 @@
 			interrupts = <22>;
 			max-frequency = <48000000>;
 			bus-width = <4>;
-			mmc-cap-mmc-highspeed;
-			mmc-cap-sd-highspeed;
+			cap-mmc-highspeed;
+			cap-sd-highspeed;
 			cd-gpios = <&gpio3 15 0x1>;
 			cd-inverted;
 			pinctrl-names = "default";
-- 
1.7.9.5

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

[PATCH 10/20] ARM: u300: Convert to the common mmc DT bindings for highspeed mode

[Ulf Hansson]

The mmci host driver supports the common mmc DT parser, which enables
us to use the use common names instead.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/ste-u300.dts |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 6fe688e..82a6616 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -442,8 +442,8 @@
 			clock-names = "apb_pclk", "mclk";
 			max-frequency = <24000000>;
 			bus-width = <4>; // SD-card slot
-			mmc-cap-mmc-highspeed;
-			mmc-cap-sd-highspeed;
+			cap-mmc-highspeed;
+			cap-sd-highspeed;
 			cd-gpios = <&gpio 12 0x4>;
 			cd-inverted;
 			vmmc-supply = <&ab3100_ldo_g_reg>;
-- 
1.7.9.5

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

[PATCH 11/20] mmc: mmci: Mark the DT bindings for highspeed mode as deprecated

[Ulf Hansson]

The common mmc DT parser supports bindings for highspeed mode, thus
there are no need for mmci to provide it's own versions for these. Mark
them as deprecated in the documentation.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 Documentation/devicetree/bindings/mmc/mmci.txt |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
index eb9ad86..f9fbcb4 100644
--- a/Documentation/devicetree/bindings/mmc/mmci.txt
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -12,11 +12,13 @@ Required properties:
 - vmmc-supply            : phandle to the regulator device tree node.
 
 Optional properties:
-- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
-- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
 - vqmmc-supply           : phandle to the regulator device tree node.
 - signal-direction       : a bit pattern, indicating bus signals directions.
 
+Deprecated properties:
+- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
+- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
+
 Example:
 
 sdi0_per1@80126000 {
@@ -34,8 +36,8 @@ sdi0_per1@80126000 {
 
 	max-frequency = <100000000>;
 	bus-width = <4>;
-	mmc-cap-sd-highspeed;
-	mmc-cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cap-mmc-highspeed;
 	cd-gpios  = <&gpio2 31 0x4>; // 95
 
 	signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
-- 
1.7.9.5

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

[PATCH 12/20] mmc: mmci: Enable MMC_CAP_CMD23

[Ulf Hansson]

This is pure software configuration, which mmci has been supporting for
a while. Let's enable it as default so we can take benefit from it.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 2e1d1b2..edf3cfd 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1532,6 +1532,9 @@ static int mmci_probe(struct amba_device *dev,
 		mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
 	}
 
+	/* We support these capabilities. */
+	mmc->caps |= MMC_CAP_CMD23;
+
 	if (variant->busy_detect) {
 		mmci_ops.card_busy = mmci_card_busy;
 		mmci_write_datactrlreg(host, MCI_ST_DPSM_BUSYMODE);
-- 
1.7.9.5

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

[PATCH 13/20] ARM: ux500: Add the mmc capabilities flags to DT

[Ulf Hansson]

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/ste-href.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
index e830c37..be34beb 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -119,10 +119,13 @@
 			bus-width = <4>;
 			cap-sd-highspeed;
 			cap-mmc-highspeed;
+			full-pwr-cycle;
 			signal-direction = <(MCI_ST_DATA2DIREN |
 						MCI_ST_CMDDIREN |
 						MCI_ST_DATA0DIREN |
 						MCI_ST_FBCLKEN)>;
+			sd-uhs-sdr12;
+			sd-uhs-sdr25;
 			vmmc-supply = <&ab8500_ldo_aux3_reg>;
 			vqmmc-supply = <&vmmci>;
 			pinctrl-names = "default", "sleep";
@@ -137,6 +140,7 @@
 			arm,primecell-periphid = <0x10480180>;
 			max-frequency = <100000000>;
 			bus-width = <4>;
+			non-removable;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi1_default_mode>;
 			pinctrl-1 = <&sdi1_sleep_mode>;
@@ -150,6 +154,7 @@
 			max-frequency = <100000000>;
 			bus-width = <8>;
 			cap-mmc-highspeed;
+			non-removable;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi2_default_mode>;
 			pinctrl-1 = <&sdi2_sleep_mode>;
@@ -163,6 +168,7 @@
 		        max-frequency = <100000000>;
 			bus-width = <8>;
 			cap-mmc-highspeed;
+			non-removable;
 			vmmc-supply = <&ab8500_ldo_aux2_reg>;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi4_default_mode>;
-- 
1.7.9.5

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

[PATCH 14/20] regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2

[Ulf Hansson]

This regulator is used for system IO and is fixed to 1.8V. Let's give
consumers the option to fetch the voltage level.

Cc: Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---

Hi Mark and Liam,

Then intent is to merge this complete patchset all together to not break
anything. Thus I only request for an ack for this particular patch.

Kind regards
Ulf Hansson 

---
 drivers/regulator/db8500-prcmu.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
index 846acf2..617c1ad 100644
--- a/drivers/regulator/db8500-prcmu.c
+++ b/drivers/regulator/db8500-prcmu.c
@@ -263,6 +263,8 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
 			.ops	= &db8500_regulator_ops,
 			.type	= REGULATOR_VOLTAGE,
 			.owner	= THIS_MODULE,
+			.fixed_uV = 1800000,
+			.n_voltages = 1,
 		},
 		.exclude_from_power_state = true,
 	},
-- 
1.7.9.5

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

[PATCH 15/20] ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href

[Ulf Hansson]

Add a node in DT for the proper regulator which means we can move away
from the mmci platform data which currently holds the corresponding OCR
mask.

The mmci driver can then calculate the OCR mask based on the voltages
supported by the regulator, instead of relying on the platform data.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/ste-href.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
index be34beb..bf449de 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -155,6 +155,7 @@
 			bus-width = <8>;
 			cap-mmc-highspeed;
 			non-removable;
+			vmmc-supply = <&db8500_vsmps2_reg>;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi2_default_mode>;
 			pinctrl-1 = <&sdi2_sleep_mode>;
-- 
1.7.9.5

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

[PATCH 16/20] ARM: ux500: Remove redundant board file for mmci platform data

[Ulf Hansson]

Since all platform data has been transfered to DT, we don't need the
container for the mmci platform data anymore. Remove the file and the
corresponding references to it's data.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/mach-ux500/Makefile           |    3 +-
 arch/arm/mach-ux500/board-mop500-sdi.c |  166 --------------------------------
 arch/arm/mach-ux500/board-mop500.h     |    5 -
 arch/arm/mach-ux500/cpu-db8500.c       |    4 -
 4 files changed, 1 insertion(+), 177 deletions(-)
 delete mode 100644 arch/arm/mach-ux500/board-mop500-sdi.c

diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index de544aa..9741de95 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -5,8 +5,7 @@
 obj-y				:= cpu.o id.o timer.o pm.o
 obj-$(CONFIG_CACHE_L2X0)	+= cache-l2x0.o
 obj-$(CONFIG_UX500_SOC_DB8500)	+= cpu-db8500.o
-obj-$(CONFIG_MACH_MOP500)	+= board-mop500-sdi.o \
-				board-mop500-regulators.o \
+obj-$(CONFIG_MACH_MOP500)	+= board-mop500-regulators.o \
 				board-mop500-audio.o
 obj-$(CONFIG_SMP)		+= platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)	+= hotplug.o
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
deleted file mode 100644
index fcbf3a1..0000000
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ /dev/null
@@ -1,166 +0,0 @@
-/*
- * Copyright (C) ST-Ericsson SA 2010
- *
- * Author: Hanumath Prasad <hanumath.prasad-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
- * License terms: GNU General Public License (GPL) version 2
- */
-
-#include <linux/kernel.h>
-#include <linux/gpio.h>
-#include <linux/amba/bus.h>
-#include <linux/amba/mmci.h>
-#include <linux/mmc/host.h>
-#include <linux/platform_device.h>
-#include <linux/platform_data/dma-ste-dma40.h>
-
-#include <asm/mach-types.h>
-
-#include "db8500-regs.h"
-#include "board-mop500.h"
-#include "ste-dma40-db8500.h"
-
-/*
- * v2 has a new version of this block that need to be forced, the number found
- * in hardware is incorrect
- */
-#define U8500_SDI_V2_PERIPHID 0x10480180
-
-/*
- * SDI 0 (MicroSD slot)
- */
-
-#ifdef CONFIG_STE_DMA40
-struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_DEV_TO_MEM,
-	.dev_type = DB8500_DMA_DEV29_SD_MM0,
-};
-
-static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_MEM_TO_DEV,
-	.dev_type = DB8500_DMA_DEV29_SD_MM0,
-};
-#endif
-
-struct mmci_platform_data mop500_sdi0_data = {
-	.f_max		= 100000000,
-	.capabilities	= MMC_CAP_4_BIT_DATA |
-				MMC_CAP_SD_HIGHSPEED |
-				MMC_CAP_MMC_HIGHSPEED |
-				MMC_CAP_ERASE |
-				MMC_CAP_UHS_SDR12 |
-				MMC_CAP_UHS_SDR25,
-	.gpio_wp	= -1,
-	.sigdir		= MCI_ST_FBCLKEN |
-				MCI_ST_CMDDIREN |
-				MCI_ST_DATA0DIREN |
-				MCI_ST_DATA2DIREN,
-#ifdef CONFIG_STE_DMA40
-	.dma_filter	= stedma40_filter,
-	.dma_rx_param	= &mop500_sdi0_dma_cfg_rx,
-	.dma_tx_param	= &mop500_sdi0_dma_cfg_tx,
-#endif
-};
-
-/*
- * SDI1 (SDIO WLAN)
- */
-#ifdef CONFIG_STE_DMA40
-static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_DEV_TO_MEM,
-	.dev_type = DB8500_DMA_DEV32_SD_MM1,
-};
-
-static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_MEM_TO_DEV,
-	.dev_type = DB8500_DMA_DEV32_SD_MM1,
-};
-#endif
-
-struct mmci_platform_data mop500_sdi1_data = {
-	.ocr_mask	= MMC_VDD_29_30,
-	.f_max		= 100000000,
-	.capabilities	= MMC_CAP_4_BIT_DATA |
-				MMC_CAP_NONREMOVABLE,
-	.gpio_cd	= -1,
-	.gpio_wp	= -1,
-#ifdef CONFIG_STE_DMA40
-	.dma_filter	= stedma40_filter,
-	.dma_rx_param	= &sdi1_dma_cfg_rx,
-	.dma_tx_param	= &sdi1_dma_cfg_tx,
-#endif
-};
-
-/*
- * SDI 2 (POP eMMC, not on DB8500ed)
- */
-
-#ifdef CONFIG_STE_DMA40
-struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_DEV_TO_MEM,
-	.dev_type =  DB8500_DMA_DEV28_SD_MM2,
-};
-
-static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_MEM_TO_DEV,
-	.dev_type = DB8500_DMA_DEV28_SD_MM2,
-};
-#endif
-
-struct mmci_platform_data mop500_sdi2_data = {
-	.ocr_mask	= MMC_VDD_165_195,
-	.f_max		= 100000000,
-	.capabilities	= MMC_CAP_4_BIT_DATA |
-				MMC_CAP_8_BIT_DATA |
-				MMC_CAP_NONREMOVABLE |
-				MMC_CAP_MMC_HIGHSPEED |
-				MMC_CAP_ERASE |
-				MMC_CAP_CMD23,
-	.gpio_cd	= -1,
-	.gpio_wp	= -1,
-#ifdef CONFIG_STE_DMA40
-	.dma_filter	= stedma40_filter,
-	.dma_rx_param	= &mop500_sdi2_dma_cfg_rx,
-	.dma_tx_param	= &mop500_sdi2_dma_cfg_tx,
-#endif
-};
-
-/*
- * SDI 4 (on-board eMMC)
- */
-
-#ifdef CONFIG_STE_DMA40
-struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_DEV_TO_MEM,
-	.dev_type =  DB8500_DMA_DEV42_SD_MM4,
-};
-
-static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
-	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = DMA_MEM_TO_DEV,
-	.dev_type = DB8500_DMA_DEV42_SD_MM4,
-};
-#endif
-
-struct mmci_platform_data mop500_sdi4_data = {
-	.f_max		= 100000000,
-	.capabilities	= MMC_CAP_4_BIT_DATA |
-				MMC_CAP_8_BIT_DATA |
-				MMC_CAP_NONREMOVABLE |
-				MMC_CAP_MMC_HIGHSPEED |
-				MMC_CAP_ERASE |
-				MMC_CAP_CMD23,
-	.gpio_cd	= -1,
-	.gpio_wp	= -1,
-#ifdef CONFIG_STE_DMA40
-	.dma_filter	= stedma40_filter,
-	.dma_rx_param	= &mop500_sdi4_dma_cfg_rx,
-	.dma_tx_param	= &mop500_sdi4_dma_cfg_tx,
-#endif
-};
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index 32cc0d8..7c7b0ad 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -8,12 +8,7 @@
 #define __BOARD_MOP500_H
 
 #include <linux/platform_data/asoc-ux500-msp.h>
-#include <linux/amba/mmci.h>
 
-extern struct mmci_platform_data mop500_sdi0_data;
-extern struct mmci_platform_data mop500_sdi1_data;
-extern struct mmci_platform_data mop500_sdi2_data;
-extern struct mmci_platform_data mop500_sdi4_data;
 extern struct msp_i2s_platform_data msp0_platform_data;
 extern struct msp_i2s_platform_data msp1_platform_data;
 extern struct msp_i2s_platform_data msp2_platform_data;
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 8820f60..fa308f0 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -146,10 +146,6 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	/* Requires call-back bindings. */
 	OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
 	/* Requires DMA bindings. */
-	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  &mop500_sdi0_data),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1",  &mop500_sdi1_data),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2",  &mop500_sdi2_data),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  &mop500_sdi4_data),
 	OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80123000,
 		       "ux500-msp-i2s.0", &msp0_platform_data),
 	OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80124000,
-- 
1.7.9.5

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

[PATCH 17/20] mmc: mmci: Enforce DT for signal direction

[Ulf Hansson]

Remove the option to provide signal direction configuration as platform
data, enforce it through DT.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c   |   24 ++++++++----------------
 drivers/mmc/host/mmci.h   |    1 +
 include/linux/amba/mmci.h |    4 ----
 3 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index edf3cfd..bef3f85 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -34,6 +34,7 @@
 #include <linux/dmaengine.h>
 #include <linux/dma-mapping.h>
 #include <linux/amba/mmci.h>
+#include <dt-bindings/mmc/mmci.h>
 #include <linux/pm_runtime.h>
 #include <linux/types.h>
 #include <linux/pinctrl/consumer.h>
@@ -1287,7 +1288,7 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		 * indicating signal direction for the signals in
 		 * the SD/MMC bus and feedback-clock usage.
 		 */
-		pwr |= host->plat->sigdir;
+		pwr |= host->sigdir;
 
 		if (ios->bus_width == MMC_BUS_WIDTH_4)
 			pwr &= ~MCI_ST_DATA74DIREN;
@@ -1386,24 +1387,18 @@ static struct mmc_host_ops mmci_ops = {
 	.start_signal_voltage_switch = mmci_sig_volt_switch,
 };
 
-static void mmci_dt_populate_generic_pdata(struct device_node *np,
-					struct mmci_platform_data *pdata)
-{
-	u32 sigdir = 0;
-
-	if (!of_property_read_u32(np, "signal-direction", &sigdir)) {
-		sigdir &= MCI_ST_DATA2DIREN|MCI_ST_CMDDIREN|MCI_ST_DATA0DIREN|
-			MCI_ST_DATA31DIREN|MCI_ST_FBCLKEN|MCI_ST_DATA74DIREN;
-		pdata->sigdir = sigdir;
-	}
-}
-
 static int mmci_of_parse(struct device_node *np, struct mmc_host *mmc)
 {
+	struct mmci_host *host = mmc_priv(mmc);
 	int ret = mmc_of_parse(mmc);
 	if (ret)
 		return ret;
 
+	if (!of_property_read_u32(np, "signal-direction", &host->sigdir))
+		host->sigdir &= MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
+			MCI_ST_DATA0DIREN | MCI_ST_DATA31DIREN |
+			MCI_ST_FBCLKEN | MCI_ST_DATA74DIREN;
+
 	if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
 		mmc->caps |= MMC_CAP_MMC_HIGHSPEED;
 	if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
@@ -1434,9 +1429,6 @@ static int mmci_probe(struct amba_device *dev,
 			return -ENOMEM;
 	}
 
-	if (np)
-		mmci_dt_populate_generic_pdata(np, plat);
-
 	if (!devm_request_mem_region(&dev->dev, dev->res.start,
 				resource_size(&dev->res), DRIVER_NAME))
 		return -ENOMEM;
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 8fc5814..6fdd11b 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -188,6 +188,7 @@ struct mmci_host {
 	u32			busy_status;
 	bool			vqmmc_enabled;
 	struct mmci_platform_data *plat;
+	u32			sigdir;
 	struct variant_data	*variant;
 
 	u8			hw_designer;
diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h
index 47ff176..0d3ff95 100644
--- a/include/linux/amba/mmci.h
+++ b/include/linux/amba/mmci.h
@@ -5,7 +5,6 @@
 #define AMBA_MMCI_H
 
 #include <linux/mmc/host.h>
-#include <dt-bindings/mmc/mmci.h>
 
 /* Just some dummy forwarding */
 struct dma_chan;
@@ -33,8 +32,6 @@ struct dma_chan;
  * @capabilities: the capabilities of the block as implemented in
  * this platform, signify anything MMC_CAP_* from mmc/host.h
  * @capabilities2: more capabilities, MMC_CAP2_* from mmc/host.h
- * @sigdir: a bit field indicating for what bits in the MMC bus the host
- * should enable signal direction indication.
  * @dma_filter: function used to select an appropriate RX and TX
  * DMA channel to be used for DMA, if and only if you're deploying the
  * generic DMA engine
@@ -57,7 +54,6 @@ struct mmci_platform_data {
 	bool	cd_invert;
 	unsigned long capabilities;
 	unsigned long capabilities2;
-	u32 sigdir;
 	bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
 	void *dma_rx_param;
 	void *dma_tx_param;
-- 
1.7.9.5

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

[PATCH 18/20] mmc: mmci: Enforce mmc capabilities through DT

[Ulf Hansson]

Remove the option to provide the flags for mmc capabilities as platform
data, enforce it through DT.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c   |    2 --
 include/linux/amba/mmci.h |    5 -----
 2 files changed, 7 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index bef3f85..a7bda79 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1516,8 +1516,6 @@ static int mmci_probe(struct amba_device *dev,
 		dev_warn(mmc_dev(mmc), "Platform OCR mask is ignored\n");
 
 	/* DT takes precedence over platform data. */
-	mmc->caps = np ? mmc->caps : plat->capabilities;
-	mmc->caps2 = np ? mmc->caps2 : plat->capabilities2;
 	if (!np) {
 		if (!plat->cd_invert)
 			mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h
index 0d3ff95..b992fc9 100644
--- a/include/linux/amba/mmci.h
+++ b/include/linux/amba/mmci.h
@@ -29,9 +29,6 @@ struct dma_chan;
  * @gpio_wp: read this GPIO pin to see if the card is write protected
  * @gpio_cd: read this GPIO pin to detect card insertion
  * @cd_invert: true if the gpio_cd pin value is active low
- * @capabilities: the capabilities of the block as implemented in
- * this platform, signify anything MMC_CAP_* from mmc/host.h
- * @capabilities2: more capabilities, MMC_CAP2_* from mmc/host.h
  * @dma_filter: function used to select an appropriate RX and TX
  * DMA channel to be used for DMA, if and only if you're deploying the
  * generic DMA engine
@@ -52,8 +49,6 @@ struct mmci_platform_data {
 	int	gpio_wp;
 	int	gpio_cd;
 	bool	cd_invert;
-	unsigned long capabilities;
-	unsigned long capabilities2;
 	bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
 	void *dma_rx_param;
 	void *dma_tx_param;
-- 
1.7.9.5

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

[PATCH 19/20] mmc: mmci: Enforce DMA configuration through DT

[Ulf Hansson]

Remove the option to provide DMA configuration as platform data,
enforce it through DT.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c   |   24 +-----------------------
 include/linux/amba/mmci.h |   17 -----------------
 2 files changed, 1 insertion(+), 40 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a7bda79..181445e 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -367,7 +367,6 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
 #ifdef CONFIG_DMA_ENGINE
 static void mmci_dma_setup(struct mmci_host *host)
 {
-	struct mmci_platform_data *plat = host->plat;
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
 
@@ -381,25 +380,6 @@ static void mmci_dma_setup(struct mmci_host *host)
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
-	if (plat && plat->dma_filter) {
-		if (!host->dma_rx_channel && plat->dma_rx_param) {
-			host->dma_rx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_rx_param);
-			/* E.g if no DMA hardware is present */
-			if (!host->dma_rx_channel)
-				dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
-		}
-
-		if (!host->dma_tx_channel && plat->dma_tx_param) {
-			host->dma_tx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_tx_param);
-			if (!host->dma_tx_channel)
-				dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
-		}
-	}
-
 	/*
 	 * If only an RX channel is specified, the driver will
 	 * attempt to use it bidirectionally, however if it is
@@ -447,11 +427,9 @@ static void mmci_dma_setup(struct mmci_host *host)
  */
 static inline void mmci_dma_release(struct mmci_host *host)
 {
-	struct mmci_platform_data *plat = host->plat;
-
 	if (host->dma_rx_channel)
 		dma_release_channel(host->dma_rx_channel);
-	if (host->dma_tx_channel && plat->dma_tx_param)
+	if (host->dma_tx_channel)
 		dma_release_channel(host->dma_tx_channel);
 	host->dma_rx_channel = host->dma_tx_channel = NULL;
 }
diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h
index b992fc9..bf339ff 100644
--- a/include/linux/amba/mmci.h
+++ b/include/linux/amba/mmci.h
@@ -6,9 +6,6 @@
 
 #include <linux/mmc/host.h>
 
-/* Just some dummy forwarding */
-struct dma_chan;
-
 /**
  * struct mmci_platform_data - platform configuration for the MMCI
  * (also known as PL180) block.
@@ -29,17 +26,6 @@ struct dma_chan;
  * @gpio_wp: read this GPIO pin to see if the card is write protected
  * @gpio_cd: read this GPIO pin to detect card insertion
  * @cd_invert: true if the gpio_cd pin value is active low
- * @dma_filter: function used to select an appropriate RX and TX
- * DMA channel to be used for DMA, if and only if you're deploying the
- * generic DMA engine
- * @dma_rx_param: parameter passed to the DMA allocation
- * filter in order to select an appropriate RX channel. If
- * there is a bidirectional RX+TX channel, then just specify
- * this and leave dma_tx_param set to NULL
- * @dma_tx_param: parameter passed to the DMA allocation
- * filter in order to select an appropriate TX channel. If this
- * is NULL the driver will attempt to use the RX channel as a
- * bidirectional channel
  */
 struct mmci_platform_data {
 	unsigned int f_max;
@@ -49,9 +35,6 @@ struct mmci_platform_data {
 	int	gpio_wp;
 	int	gpio_cd;
 	bool	cd_invert;
-	bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
-	void *dma_rx_param;
-	void *dma_tx_param;
 };
 
 #endif
-- 
1.7.9.5

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

[PATCH 20/20] mmc: mmci: Enforce max frequency configuration through DT

[Ulf Hansson]

Remove the option to provide a maximum frequency as platform data,
enforce it through DT.

Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/host/mmci.c   |    5 +----
 include/linux/amba/mmci.h |    4 ----
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 181445e..cbbb87e 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1475,13 +1475,10 @@ static int mmci_probe(struct amba_device *dev,
 	 * If no maximum operating frequency is supplied, fall back to use
 	 * the module parameter, which has a (low) default value in case it
 	 * is not specified. Either value must not exceed the clock rate into
-	 * the block, of course. Also note that DT takes precedence over
-	 * platform data.
+	 * the block, of course.
 	 */
 	if (mmc->f_max)
 		mmc->f_max = min(host->mclk, mmc->f_max);
-	else if (plat->f_max)
-		mmc->f_max = min(host->mclk, plat->f_max);
 	else
 		mmc->f_max = min(host->mclk, fmax);
 	dev_dbg(mmc_dev(mmc), "clocking block at %u Hz\n", mmc->f_max);
diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h
index bf339ff..8c98113 100644
--- a/include/linux/amba/mmci.h
+++ b/include/linux/amba/mmci.h
@@ -9,9 +9,6 @@
 /**
  * struct mmci_platform_data - platform configuration for the MMCI
  * (also known as PL180) block.
- * @f_max: the maximum operational frequency for this host in this
- * platform configuration. When this is specified it takes precedence
- * over the module parameter for the same frequency.
  * @ocr_mask: available voltages on the 4 pins from the block, this
  * is ignored if a regulator is used, see the MMC_VDD_* masks in
  * mmc/host.h
@@ -28,7 +25,6 @@
  * @cd_invert: true if the gpio_cd pin value is active low
  */
 struct mmci_platform_data {
-	unsigned int f_max;
 	unsigned int ocr_mask;
 	int (*ios_handler)(struct device *, struct mmc_ios *);
 	unsigned int (*status)(struct device *);
-- 
1.7.9.5

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

Re: [PATCH 14/20] regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2

[Mark Brown]

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

On Fri, Mar 21, 2014 at 01:14:11PM +0100, Ulf Hansson wrote:

> Then intent is to merge this complete patchset all together to not break
> anything. Thus I only request for an ack for this particular patch.

TBH given that we're at -rc7 and you're unlikely to get the rest of
whatever this is merged before the merge window it's as easy for me to
just apply it.  Make sense?

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

Re: [PATCH 14/20] regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2

[Ulf Hansson]

On 21 March 2014 13:25, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Mar 21, 2014 at 01:14:11PM +0100, Ulf Hansson wrote:
>
>> Then intent is to merge this complete patchset all together to not break
>> anything. Thus I only request for an ack for this particular patch.
>
> TBH given that we're at -rc7 and you're unlikely to get the rest of
> whatever this is merged before the merge window it's as easy for me to
> just apply it.  Make sense?

Absolutely, go ahead! Thanks!

Kind regards
Uffe

>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/20] mmc: mmci: Update DT documentation

[Rob Herring]

On Fri, Mar 21, 2014 at 7:14 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Document how to configure the regulator supplies and add an example of
> a typical mmci DT node.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mmc/mmci.txt |   35 ++++++++++++++++++++++--
>  1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
> index 2b584ca..d167562 100644
> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> @@ -9,7 +9,38 @@ by mmc.txt and the properties used by the mmci driver.
>  Required properties:
>  - compatible             : contains "arm,pl18x", "arm,primecell".
>  - arm,primecell-periphid : contains the PrimeCell Peripheral ID.

This should not be required. This is only for if the peripheral ID is
wrong in the h/w.

> +- vmmc-supply            : phandle to the regulator device tree node.

You cannot add new required properties as that breaks the ABI. The
exception is if you *know* it is okay to break all users of this
binding.

>  Optional properties:
> -- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
> -- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
> +- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
> +- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
> +- vqmmc-supply           : phandle to the regulator device tree node.

Is this a standard property? If not, explain what vmmc and vgmmc are
for and what the difference is.

> +
> +Example:
> +
> +sdi0_per1@80126000 {
> +       compatible = "arm,pl18x", "arm,primecell";
> +       arm,primecell-periphid = <0x10480180>;

Drop this from the example.

> +       reg = <0x80126000 0x1000>;
> +       interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
> +
> +       dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */
> +              <&dma 29 0 0x0>; /* Logical - MemToDev */
> +       dma-names = "rx", "tx";
> +
> +       clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>;
> +       clock-names = "sdi", "apb_pclk";
> +
> +       max-frequency = <100000000>;
> +       bus-width = <4>;
> +       mmc-cap-sd-highspeed;
> +       mmc-cap-mmc-highspeed;
> +       cd-gpios  = <&gpio2 31 0x4>; // 95
> +
> +       vmmc-supply = <&ab8500_ldo_aux3_reg>;
> +       vqmmc-supply = <&vmmci>;
> +
> +       pinctrl-names = "default", "sleep";
> +       pinctrl-0 = <&sdi0_default_mode>;
> +       pinctrl-1 = <&sdi0_sleep_mode>;
> +};
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/20] mmc: mmci: Add DT bindings for signal direction

[Rob Herring]

On Fri, Mar 21, 2014 at 7:14 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Some variants have support for indicating the bus signal directions,
> which currently are configured through platform data.
>
> Add corresponding DT bindings to enable us to move away from using the
> platform data.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
>  drivers/mmc/host/mmci.c                        |    7 +++++++
>  2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
> index d167562..eb9ad86 100644
> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> @@ -15,6 +15,7 @@ Optional properties:
>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
>  - vqmmc-supply           : phandle to the regulator device tree node.
> +- signal-direction       : a bit pattern, indicating bus signals directions.

You need to define the bit positions.

>
>  Example:
>
> @@ -37,6 +38,9 @@ sdi0_per1@80126000 {
>         mmc-cap-mmc-highspeed;
>         cd-gpios  = <&gpio2 31 0x4>; // 95
>
> +       signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
> +                       MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;

The "ST" here is for STMicro or some ST based company? Use the vendor
prefix here.

I don't really understand why you need to specify the direction here.
Data lines are bi-directional and cmd and clk are outputs.

> +
>         vmmc-supply = <&ab8500_ldo_aux3_reg>;
>         vqmmc-supply = <&vmmci>;
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index d6f20ba..76e41ba 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1390,8 +1390,15 @@ static struct mmc_host_ops mmci_ops = {
>  static void mmci_dt_populate_generic_pdata(struct device_node *np,
>                                         struct mmci_platform_data *pdata)
>  {
> +       u32 sigdir = 0;
>         int bus_width = 0;
>
> +       if (!of_property_read_u32(np, "signal-direction", &sigdir)) {
> +               sigdir &= MCI_ST_DATA2DIREN|MCI_ST_CMDDIREN|MCI_ST_DATA0DIREN|
> +                       MCI_ST_DATA31DIREN|MCI_ST_FBCLKEN|MCI_ST_DATA74DIREN;

Spaces around the '|'.

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

Re: [PATCH 14/20] regulator: db8500-prcmu: Set 1.8V as a fixed voltage for vsmps2

[Mark Brown]

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

On Fri, Mar 21, 2014 at 01:14:11PM +0100, Ulf Hansson wrote:
> This regulator is used for system IO and is fixed to 1.8V. Let's give
> consumers the option to fetch the voltage level.

Applied, thanks.  If the rest of the series can get applied I can
easily drop this one. 

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

Re: [PATCH 03/20] mmc: mmci: Update DT documentation

[Ulf Hansson]

On 21 March 2014 16:03, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Mar 21, 2014 at 7:14 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> Document how to configure the regulator supplies and add an example of
>> a typical mmci DT node.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/mmc/mmci.txt |   35 ++++++++++++++++++++++--
>>  1 file changed, 33 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
>> index 2b584ca..d167562 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
>> @@ -9,7 +9,38 @@ by mmc.txt and the properties used by the mmci driver.
>>  Required properties:
>>  - compatible             : contains "arm,pl18x", "arm,primecell".
>>  - arm,primecell-periphid : contains the PrimeCell Peripheral ID.
>
> This should not be required. This is only for if the peripheral ID is
> wrong in the h/w.

You are right, I will move it to the optional section and add better
comment for it.

>
>> +- vmmc-supply            : phandle to the regulator device tree node.
>
> You cannot add new required properties as that breaks the ABI. The
> exception is if you *know* it is okay to break all users of this
> binding.

It's okay, this is already supported by the users.

>
>>  Optional properties:
>> -- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
>> -- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
>> +- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
>> +- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
>> +- vqmmc-supply           : phandle to the regulator device tree node.
>
> Is this a standard property? If not, explain what vmmc and vgmmc are
> for and what the difference is.

Currently both vqmmc and vmmc are handled through an API provided by
the mmc core. It's up to each mmc host driver to use it. So, yes -
this is a standard mmc binding, but it depends on the host if it's
supported.

I suppose I could add it as an optional binding for the generic mmc
bindings and then keep them here for mmci as well?

>
>> +
>> +Example:
>> +
>> +sdi0_per1@80126000 {
>> +       compatible = "arm,pl18x", "arm,primecell";
>> +       arm,primecell-periphid = <0x10480180>;
>
> Drop this from the example.
>
>> +       reg = <0x80126000 0x1000>;
>> +       interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> +       dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */
>> +              <&dma 29 0 0x0>; /* Logical - MemToDev */
>> +       dma-names = "rx", "tx";
>> +
>> +       clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>;
>> +       clock-names = "sdi", "apb_pclk";
>> +
>> +       max-frequency = <100000000>;
>> +       bus-width = <4>;
>> +       mmc-cap-sd-highspeed;
>> +       mmc-cap-mmc-highspeed;
>> +       cd-gpios  = <&gpio2 31 0x4>; // 95
>> +
>> +       vmmc-supply = <&ab8500_ldo_aux3_reg>;
>> +       vqmmc-supply = <&vmmci>;
>> +
>> +       pinctrl-names = "default", "sleep";
>> +       pinctrl-0 = <&sdi0_default_mode>;
>> +       pinctrl-1 = <&sdi0_sleep_mode>;
>> +};
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks for reviewing!

Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/20] mmc: mmci: Add DT bindings for signal direction

[Ulf Hansson]

On 21 March 2014 16:20, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Mar 21, 2014 at 7:14 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> Some variants have support for indicating the bus signal directions,
>> which currently are configured through platform data.
>>
>> Add corresponding DT bindings to enable us to move away from using the
>> platform data.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
>>  drivers/mmc/host/mmci.c                        |    7 +++++++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
>> index d167562..eb9ad86 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
>> @@ -15,6 +15,7 @@ Optional properties:
>>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
>>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
>>  - vqmmc-supply           : phandle to the regulator device tree node.
>> +- signal-direction       : a bit pattern, indicating bus signals directions.
>
> You need to define the bit positions.

May I refer to the <dt-bindings/mmc/mmci.h> instead? To me, it seems a
bit silly to duplicate that information in the documentation.

>
>>
>>  Example:
>>
>> @@ -37,6 +38,9 @@ sdi0_per1@80126000 {
>>         mmc-cap-mmc-highspeed;
>>         cd-gpios  = <&gpio2 31 0x4>; // 95
>>
>> +       signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
>> +                       MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;
>
> The "ST" here is for STMicro or some ST based company? Use the vendor
> prefix here.

We have way back already concluded to use "ST" as prefix for all
STMicro specific defines used in mmci. Please have a look at
drivers/mmc/host/mmci.h.
I would prefer to keep these aligned with the other defines, though if
you have strong feelings about it, sure I can change them.

>
> I don't really understand why you need to specify the direction here.
> Data lines are bi-directional and cmd and clk are outputs.
>

These bits are being used when you have an external levelshifter.

Without going into too much details, it all depends on how the
different pins are connected to the levelshifter, which isn't possible
to figure out in runtime.

>> +
>>         vmmc-supply = <&ab8500_ldo_aux3_reg>;
>>         vqmmc-supply = <&vmmci>;
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index d6f20ba..76e41ba 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -1390,8 +1390,15 @@ static struct mmc_host_ops mmci_ops = {
>>  static void mmci_dt_populate_generic_pdata(struct device_node *np,
>>                                         struct mmci_platform_data *pdata)
>>  {
>> +       u32 sigdir = 0;
>>         int bus_width = 0;
>>
>> +       if (!of_property_read_u32(np, "signal-direction", &sigdir)) {
>> +               sigdir &= MCI_ST_DATA2DIREN|MCI_ST_CMDDIREN|MCI_ST_DATA0DIREN|
>> +                       MCI_ST_DATA31DIREN|MCI_ST_FBCLKEN|MCI_ST_DATA74DIREN;
>
> Spaces around the '|'.
>
> Rob

Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/20] mmc: mmci: Add DT bindings for signal direction

[Rob Herring]

On Mon, Mar 24, 2014 at 4:14 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 21 March 2014 16:20, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Mar 21, 2014 at 7:14 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> Some variants have support for indicating the bus signal directions,
>>> which currently are configured through platform data.
>>>
>>> Add corresponding DT bindings to enable us to move away from using the
>>> platform data.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> ---
>>>  Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
>>>  drivers/mmc/host/mmci.c                        |    7 +++++++
>>>  2 files changed, 11 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
>>> index d167562..eb9ad86 100644
>>> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
>>> @@ -15,6 +15,7 @@ Optional properties:
>>>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
>>>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
>>>  - vqmmc-supply           : phandle to the regulator device tree node.
>>> +- signal-direction       : a bit pattern, indicating bus signals directions.
>>
>> You need to define the bit positions.
>
> May I refer to the <dt-bindings/mmc/mmci.h> instead? To me, it seems a
> bit silly to duplicate that information in the documentation.

We really prefer that the binding doc stand on it's own such that you
could write the header based on the binding.

>>
>>>
>>>  Example:
>>>
>>> @@ -37,6 +38,9 @@ sdi0_per1@80126000 {
>>>         mmc-cap-mmc-highspeed;
>>>         cd-gpios  = <&gpio2 31 0x4>; // 95
>>>
>>> +       signal-direction = <(MCI_ST_DATA2DIREN | MCI_ST_CMDDIREN |
>>> +                       MCI_ST_DATA0DIREN | MCI_ST_FBCLKEN)>;
>>
>> The "ST" here is for STMicro or some ST based company? Use the vendor
>> prefix here.
>
> We have way back already concluded to use "ST" as prefix for all
> STMicro specific defines used in mmci. Please have a look at
> drivers/mmc/host/mmci.h.
> I would prefer to keep these aligned with the other defines, though if
> you have strong feelings about it, sure I can change them.

I don't mean change the defines. I mean name the property
"st,signal-direction" and indicate it only applies to the STMicro
variant.

>> I don't really understand why you need to specify the direction here.
>> Data lines are bi-directional and cmd and clk are outputs.
>>
>
> These bits are being used when you have an external levelshifter.
>
> Without going into too much details, it all depends on how the
> different pins are connected to the levelshifter, which isn't possible
> to figure out in runtime.

Okay.

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

Re: [PATCH 04/20] mmc: mmci: Move signal directions bits into DT include file

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> These bits is currently used from platform data, but will be needed
> from DT as well, so let's make them available.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
(...)
> +#define MCI_ST_DATA31DIREN     (1 << 5)
> +#define MCI_ST_FBCLKEN         (1 << 7)
> +#define MCI_ST_DATA74DIREN     (1 << 8)

Isn't MCI_ST_FBCLKEN = feedback clock enable and nothing
to do with directions really?

Or can you convince me ...

Maybe we should just have single strings for these
things in the binding instead, like:

@@ -118,6 +119,10 @@
                        bus-width = <4>;
                        mmc-cap-sd-highspeed;
                        mmc-cap-mmc-highspeed;
+                       st,signal-direction-data2;
+                       st,signal-direction-cmd;
+                       st,signal-direction-data0;
+                       st,feedback-clock-enable;
                        vmmc-supply = <&ab8500_ldo_aux3_reg>;
                        vqmmc-supply = <&vmmci>;
                        pinctrl-names = "default", "sleep";

And for FBCLKEN is that really something that should
be configured... in the device tree after all?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/20] ARM: ux500: Convert to the common mmc DT bindings for highspeed mode

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> The mmci host driver supports the common mmc DT parser, which enables
> us to use the use common names instead.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/20] ARM: nomadik: Convert to the common mmc DT bindings for highspeed mode

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> The mmci host driver supports the common mmc DT parser, which enables
> us to use the use common names instead.
>
> Cc: Alessandro Rubini <rubini-9wsNiZum9E8@public.gmane.org>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/20] ARM: u300: Convert to the common mmc DT bindings for highspeed mode

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> The mmci host driver supports the common mmc DT parser, which enables
> us to use the use common names instead.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/20] ARM: ux500: Add the mmc capabilities flags to DT

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/20] ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> Add a node in DT for the proper regulator which means we can move away
> from the mmci platform data which currently holds the corresponding OCR
> mask.
>
> The mmci driver can then calculate the OCR mask based on the voltages
> supported by the regulator, instead of relying on the platform data.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm/boot/dts/ste-href.dtsi |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
> index be34beb..bf449de 100644
> --- a/arch/arm/boot/dts/ste-href.dtsi
> +++ b/arch/arm/boot/dts/ste-href.dtsi
> @@ -155,6 +155,7 @@
>                         bus-width = <8>;
>                         cap-mmc-highspeed;
>                         non-removable;
> +                       vmmc-supply = <&db8500_vsmps2_reg>;

Don't you need a similar oneliner to ste-snowball.dts?
That board is not including this file...

Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/20] ARM: ux500: Remove redundant board file for mmci platform data

[Linus Walleij]

On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> Since all platform data has been transfered to DT, we don't need the
> container for the mmci platform data anymore. Remove the file and the
> corresponding references to it's data.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/20] mmc: mmci: Move signal directions bits into DT include file

[Ulf Hansson]

On 25 March 2014 22:22, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> These bits is currently used from platform data, but will be needed
>> from DT as well, so let's make them available.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> (...)
>> +#define MCI_ST_DATA31DIREN     (1 << 5)
>> +#define MCI_ST_FBCLKEN         (1 << 7)
>> +#define MCI_ST_DATA74DIREN     (1 << 8)
>
> Isn't MCI_ST_FBCLKEN = feedback clock enable and nothing
> to do with directions really?

You do have a point here, but then we are about to go into the details. :-)

What MCI_ST_FBCLKEN means, is that the internal logic in the primecell
can decide whether to use the signal from clockout pin or the
feebackclock pin, when its latching incoming signals on the data bus.

That said, we for sure need a dt binding for bit as well, since this
is not possible to figure out how pins are routed in runtime.

Also, I do believe it is very closely related to the other sigdir
pins, since it's all about how pins is being routed, even if it's as
you say - in this case a matter of signal directions.

So, I guess we have two options here; Either move the MCI_ST_FBCLKEN
out of the signal-direction binding and invent a separate binding for
it, or just keep them as is.

>
> Or can you convince me ...
>
> Maybe we should just have single strings for these
> things in the binding instead, like:
>
> @@ -118,6 +119,10 @@
>                         bus-width = <4>;
>                         mmc-cap-sd-highspeed;
>                         mmc-cap-mmc-highspeed;
> +                       st,signal-direction-data2;
> +                       st,signal-direction-cmd;
> +                       st,signal-direction-data0;
> +                       st,feedback-clock-enable;
>                         vmmc-supply = <&ab8500_ldo_aux3_reg>;
>                         vqmmc-supply = <&vmmci>;
>                         pinctrl-names = "default", "sleep";

I guess this is an option. To me it just seems a bit silly to have one
separate binding for each single bit, but maybe it becomes clearer?

>
> And for FBCLKEN is that really something that should
> be configured... in the device tree after all?

We need a DT binding, see above.

>
> Yours,
> Linus Walleij

Thanks for reviewing.

Please tell me your ideas on how to proceed, I happy to change to
whatever you like. :-)

Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/20] ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href

[Ulf Hansson]

On 25 March 2014 22:45, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> Add a node in DT for the proper regulator which means we can move away
>> from the mmci platform data which currently holds the corresponding OCR
>> mask.
>>
>> The mmci driver can then calculate the OCR mask based on the voltages
>> supported by the regulator, instead of relying on the platform data.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>>  arch/arm/boot/dts/ste-href.dtsi |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
>> index be34beb..bf449de 100644
>> --- a/arch/arm/boot/dts/ste-href.dtsi
>> +++ b/arch/arm/boot/dts/ste-href.dtsi
>> @@ -155,6 +155,7 @@
>>                         bus-width = <8>;
>>                         cap-mmc-highspeed;
>>                         non-removable;
>> +                       vmmc-supply = <&db8500_vsmps2_reg>;
>
> Don't you need a similar oneliner to ste-snowball.dts?
> That board is not including this file...

Snowball don't have the poped eMMC, which mean the vsmps2 is not used
as the vmmc-supply.

I still plan to have a look at snowball, handled as a separate task,
since I have heard people complaining about the SD card and/or the
eMMC is working properly.

Kind regards
Ulf Hansson

>
> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/20] ARM: ux500: Add a vmmc regulator through DT for the poped eMMC for href

[Ulf Hansson]

On 26 March 2014 10:27, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 25 March 2014 22:45, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>
>>> Add a node in DT for the proper regulator which means we can move away
>>> from the mmci platform data which currently holds the corresponding OCR
>>> mask.
>>>
>>> The mmci driver can then calculate the OCR mask based on the voltages
>>> supported by the regulator, instead of relying on the platform data.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> ---
>>>  arch/arm/boot/dts/ste-href.dtsi |    1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
>>> index be34beb..bf449de 100644
>>> --- a/arch/arm/boot/dts/ste-href.dtsi
>>> +++ b/arch/arm/boot/dts/ste-href.dtsi
>>> @@ -155,6 +155,7 @@
>>>                         bus-width = <8>;
>>>                         cap-mmc-highspeed;
>>>                         non-removable;
>>> +                       vmmc-supply = <&db8500_vsmps2_reg>;
>>
>> Don't you need a similar oneliner to ste-snowball.dts?
>> That board is not including this file...
>
> Snowball don't have the poped eMMC, which mean the vsmps2 is not used
> as the vmmc-supply.
>
> I still plan to have a look at snowball, handled as a separate task,
> since I have heard people complaining about the SD card and/or the
> eMMC is working properly.

/s /is /is not

>
> Kind regards
> Ulf Hansson
>
>>
>> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>
>> Yours,
>> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/20] mmc: mmci: Move signal directions bits into DT include file

[Linus Walleij]

On Wed, Mar 26, 2014 at 12:05 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 25 March 2014 22:22, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>
>>> These bits is currently used from platform data, but will be needed
>>> from DT as well, so let's make them available.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> (...)
>>> +#define MCI_ST_DATA31DIREN     (1 << 5)
>>> +#define MCI_ST_FBCLKEN         (1 << 7)
>>> +#define MCI_ST_DATA74DIREN     (1 << 8)
>>
>> Isn't MCI_ST_FBCLKEN = feedback clock enable and nothing
>> to do with directions really?
>
> You do have a point here, but then we are about to go into the details. :-)
>
> What MCI_ST_FBCLKEN means, is that the internal logic in the primecell
> can decide whether to use the signal from clockout pin or the
> feebackclock pin, when its latching incoming signals on the data bus.
>
> That said, we for sure need a dt binding for bit as well, since this
> is not possible to figure out how pins are routed in runtime.
>
> Also, I do believe it is very closely related to the other sigdir
> pins, since it's all about how pins is being routed, even if it's as
> you say - in this case a matter of signal directions.
>
> So, I guess we have two options here; Either move the MCI_ST_FBCLKEN
> out of the signal-direction binding and invent a separate binding for
> it, or just keep them as is.

If they are very closely related I guess that will become very
clear when you document it in the requested explicit bindings,
so no strong opinion here. I'd probably ACK either version.

>> Maybe we should just have single strings for these
>> things in the binding instead, like:
>>
>> @@ -118,6 +119,10 @@
>>                         bus-width = <4>;
>>                         mmc-cap-sd-highspeed;
>>                         mmc-cap-mmc-highspeed;
>> +                       st,signal-direction-data2;
>> +                       st,signal-direction-cmd;
>> +                       st,signal-direction-data0;
>> +                       st,feedback-clock-enable;
>>                         vmmc-supply = <&ab8500_ldo_aux3_reg>;
>>                         vqmmc-supply = <&vmmci>;
>>                         pinctrl-names = "default", "sleep";
>
> I guess this is an option. To me it just seems a bit silly to have one
> separate binding for each single bit, but maybe it becomes clearer?

The idea with device trees is to be very human-readable, so I guess
if you have preprocessor macro things |:ing the arguments together
to a singular 32bit value it serves the same purpose. Arguably this
version is even easier for a human to read though.

What we should avoid is using magic number assignments to
save space (e.g. have magic numbers in the tree rather than
readable strings) so I lean toward this, but it's admittedly in a
grey area, so again no strong opinion.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/20] mmc: mmci: Move signal directions bits into DT include file

[Ulf Hansson]

On 28 March 2014 22:03, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Mar 26, 2014 at 12:05 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 25 March 2014 22:22, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> On Fri, Mar 21, 2014 at 1:14 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>
>>>> These bits is currently used from platform data, but will be needed
>>>> from DT as well, so let's make them available.
>>>>
>>>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> (...)
>>>> +#define MCI_ST_DATA31DIREN     (1 << 5)
>>>> +#define MCI_ST_FBCLKEN         (1 << 7)
>>>> +#define MCI_ST_DATA74DIREN     (1 << 8)
>>>
>>> Isn't MCI_ST_FBCLKEN = feedback clock enable and nothing
>>> to do with directions really?
>>
>> You do have a point here, but then we are about to go into the details. :-)
>>
>> What MCI_ST_FBCLKEN means, is that the internal logic in the primecell
>> can decide whether to use the signal from clockout pin or the
>> feebackclock pin, when its latching incoming signals on the data bus.
>>
>> That said, we for sure need a dt binding for bit as well, since this
>> is not possible to figure out how pins are routed in runtime.
>>
>> Also, I do believe it is very closely related to the other sigdir
>> pins, since it's all about how pins is being routed, even if it's as
>> you say - in this case a matter of signal directions.
>>
>> So, I guess we have two options here; Either move the MCI_ST_FBCLKEN
>> out of the signal-direction binding and invent a separate binding for
>> it, or just keep them as is.
>
> If they are very closely related I guess that will become very
> clear when you document it in the requested explicit bindings,
> so no strong opinion here. I'd probably ACK either version.
>
>>> Maybe we should just have single strings for these
>>> things in the binding instead, like:
>>>
>>> @@ -118,6 +119,10 @@
>>>                         bus-width = <4>;
>>>                         mmc-cap-sd-highspeed;
>>>                         mmc-cap-mmc-highspeed;
>>> +                       st,signal-direction-data2;
>>> +                       st,signal-direction-cmd;
>>> +                       st,signal-direction-data0;
>>> +                       st,feedback-clock-enable;
>>>                         vmmc-supply = <&ab8500_ldo_aux3_reg>;
>>>                         vqmmc-supply = <&vmmci>;
>>>                         pinctrl-names = "default", "sleep";
>>
>> I guess this is an option. To me it just seems a bit silly to have one
>> separate binding for each single bit, but maybe it becomes clearer?
>
> The idea with device trees is to be very human-readable, so I guess
> if you have preprocessor macro things |:ing the arguments together
> to a singular 32bit value it serves the same purpose. Arguably this
> version is even easier for a human to read though.
>
> What we should avoid is using magic number assignments to
> save space (e.g. have magic numbers in the tree rather than
> readable strings) so I lean toward this, but it's admittedly in a
> grey area, so again no strong opinion.

Thanks for your advise. I seems like a good idea to move to use
readable strings instead.

In that way, we also get the clean cut between signal directions and
the feedback clock pin.

Kind regards
Ulf Hansson

>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html