Skip to contentSkip to conversation

mmc: mmci: Improve DT support

PATCH Superseded Ulf Hansson 4 participants 41 messages Mar 21, 2014 – Mar 31, 2014

Subsystems (7)

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

cover mmc: mmci: Improve DT support

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
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH 1/20 mmc: mmci: Convert to the mmc gpio API

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

---
 drivers/mmc/host/mmci.c |   97 ++++++++---------------------------------------
 drivers/mmc/host/mmci.h |    3 --
 2 files changed, 15 insertions(+), 85 deletions(-)
drivers/mmc/host/mmci.c +15 -82
index 771c60a..b0b81ac 100644
@@ -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);
 
drivers/mmc/host/mmci.h +0 -3
index 58b1b88..8fc5814 100644
@@ -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;
Signature · 1 line
1.7.9.5
#2 lore raw

PATCH 2/20 mmc: mmci: Convert to devm functions

In reply to Ulf Hansson

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

---
 drivers/mmc/host/mmci.c |   51 ++++++++++++++++++-----------------------------
 1 file changed, 19 insertions(+), 32 deletions(-)
drivers/mmc/host/mmci.c +19 -32
index b0b81ac..d6f20ba 100644
@@ -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;
Signature · 1 line
1.7.9.5
#3 lore raw

PATCH 3/20 mmc: mmci: Update DT documentation

In reply to Ulf Hansson

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

---
 Documentation/devicetree/bindings/mmc/mmci.txt |   35 ++++++++++++++++++++++--
 1 file changed, 33 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/mmc/mmci.txt +33 -2
index 2b584ca..d167562 100644
@@ -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 at 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>;
+};
Signature · 1 line
1.7.9.5
#4 lore raw

PATCH 3/20 mmc: mmci: Update DT documentation

Quoted 13 lines · Ulf Hansson

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

---
 Documentation/devicetree/bindings/mmc/mmci.txt |   35 ++++++++++++++++++++++--
 1 file changed, 33 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/mmc/mmci.txt +0 -0
index 2b584ca..d167562 100644

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 11

Quoted 3 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0 -0
@@ -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.

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 12

Quoted 1 line
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
+- 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.

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 17

Quoted 6 lines
Documentation/devicetree/bindings/mmc/mmci.txt +3 -2
 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.

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 23

Quoted 6 lines
Documentation/devicetree/bindings/mmc/mmci.txt +6 -0
+
+Example:
+
+sdi0_per1 at 80126000 {
+       compatible = "arm,pl18x", "arm,primecell";
+       arm,primecell-periphid = <0x10480180>;

Drop this from the example.

Quoted 30 lines
Documentation/devicetree/bindings/mmc/mmci.txt +23 -1
+       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 at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw

PATCH 3/20 mmc: mmci: Update DT documentation

Quoted 9 lines · Rob Herring
Quoted 8 lines · Ulf Hansson

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

---
 Documentation/devicetree/bindings/mmc/mmci.txt |   35 ++++++++++++++++++++++--
 1 file changed, 33 insertions(+), 2 deletions(-)
Quoted 11 lines

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 11

Quoted 8 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0 -0
index 2b584ca..d167562 100644
@@ -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.

Quoted 6 lines

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 12

Quoted 2 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
+- 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.

Quoted 10 lines

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 17

Quoted 7 lines
Documentation/devicetree/bindings/mmc/mmci.txt +3 -2
 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?

Quoted 36 lines

Documentation/devicetree/bindings/mmc/mmci.txt by mmc.txt and the properties used by the mmci driver. · line 23

Quoted 7 lines
Documentation/devicetree/bindings/mmc/mmci.txt +6 -0
+
+Example:
+
+sdi0_per1 at 80126000 {
+       compatible = "arm,pl18x", "arm,primecell";
+       arm,primecell-periphid = <0x10480180>;

Drop this from the example.

Quoted 26 lines
Documentation/devicetree/bindings/mmc/mmci.txt +23 -1
+       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

Quoted 4 lines
Quoted 4 lines

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

Thanks for reviewing!

Kind regards
Ulf Hansson

#6 lore raw

PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file

In reply to Ulf Hansson

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

---
 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
include/dt-bindings/mmc/mmci.h new file +21 -0
new file mode 100644
index 0000000..8c55254
@@ -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
include/linux/amba/mmci.h +1 -13
index 32a89cf..47ff176 100644
@@ -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;
Signature · 1 line
1.7.9.5
#7 lore raw

PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file

Quoted 4 lines · Ulf Hansson

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

(...)

include/dt-bindings/mmc/mmci.h line 19

Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3 -0
+#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

#8 lore raw

PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file

Quoted 5 lines · Linus Walleij
Quoted 3 lines · Ulf Hansson

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

Quoted 8 lines
Quoted 1 line

(...)

include/dt-bindings/mmc/mmci.h line 19

Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3 -0
+#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.

Quoted 7 lines

Or can you convince me ...

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

Review line 128

Quoted 10 lines
(quoted diff) +4 -0
@@ -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?

Quoted 3 lines

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

We need a DT binding, see above.

Quoted 3 lines

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

#9 lore raw

PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file

Quoted 24 lines · Ulf Hansson
Quoted 5 lines · Linus Walleij
Quoted 3 lines · Ulf Hansson

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

Quoted 8 lines
Quoted 1 line

(...)

include/dt-bindings/mmc/mmci.h line 19

Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3 -0
+#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.

Quoted 7 lines

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.

Quoted 17 lines
Quoted 4 lines

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

Review line 128

Quoted 10 lines
(quoted diff) +4 -0
@@ -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

#10 lore raw

PATCH 4/20 mmc: mmci: Move signal directions bits into DT include file

Quoted 60 lines · Linus Walleij
Quoted 24 lines · Ulf Hansson
Quoted 5 lines · Linus Walleij
Quoted 3 lines · Ulf Hansson

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

Quoted 8 lines
Quoted 1 line

(...)

include/dt-bindings/mmc/mmci.h line 19

Quoted 3 lines
include/dt-bindings/mmc/mmci.h new file +3 -0
+#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.

Quoted 7 lines

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.

Quoted 17 lines
Quoted 4 lines

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

Review line 128

Quoted 10 lines
(quoted diff) +4 -0
@@ -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.

Quoted 4 lines

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

Quoted 3 lines

Yours,
Linus Walleij

#11 lore raw

PATCH 5/20 mmc: mmci: Add DT bindings for signal direction

In reply to 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.

---
 Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
 drivers/mmc/host/mmci.c                        |    7 +++++++
 2 files changed, 11 insertions(+)
Documentation/devicetree/bindings/mmc/mmci.txt +4 -0
index d167562..eb9ad86 100644
@@ -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 at 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>;
 
drivers/mmc/host/mmci.c +7 -0
index d6f20ba..76e41ba 100644
@@ -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);
 
Signature · 1 line
1.7.9.5
#12 lore raw

PATCH 5/20 mmc: mmci: Add DT bindings for signal direction

Quoted 17 lines · 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.

---
 Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
 drivers/mmc/host/mmci.c                        |    7 +++++++
 2 files changed, 11 insertions(+)
Documentation/devicetree/bindings/mmc/mmci.txt +0 -0
index d167562..eb9ad86 100644

Documentation/devicetree/bindings/mmc/mmci.txt Optional properties: · line 18

Quoted 4 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
@@ -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.

Documentation/devicetree/bindings/mmc/mmci.txt sdi0_per1 at 80126000 { · line 42

Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +2 -0
 Example:
 
@@ -37,6 +38,9 @@ sdi0_per1 at 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.

Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
+
        vmmc-supply = <&ab8500_ldo_aux3_reg>;
        vqmmc-supply = <&vmmci>;
 
drivers/mmc/host/mmci.c +0 -0
index d6f20ba..76e41ba 100644

drivers/mmc/host/mmci.c static struct mmc_host_ops mmci_ops = { · line 1398

Quoted 9 lines
drivers/mmc/host/mmci.c +4 -0
@@ -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

#13 lore raw

PATCH 5/20 mmc: mmci: Add DT bindings for signal direction

Quoted 13 lines · Rob Herring
Quoted 12 lines · 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.

---
 Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
 drivers/mmc/host/mmci.c                        |    7 +++++++
 2 files changed, 11 insertions(+)
Quoted 11 lines

Documentation/devicetree/bindings/mmc/mmci.txt Optional properties: · line 18

Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
index d167562..eb9ad86 100644
@@ -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.

Quoted 8 lines
Quoted 8 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0 -0
 Example:
 
@@ -37,6 +38,9 @@ sdi0_per1 at 80126000 {
        mmc-cap-mmc-highspeed;
        cd-gpios  = <&gpio2 31 0x4>; // 95
 
Quoted 5 lines

Documentation/devicetree/bindings/mmc/mmci.txt sdi0_per1 at 80126000 { · line 42

Quoted 2 lines
Documentation/devicetree/bindings/mmc/mmci.txt +2 -0
+       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.

Quoted 4 lines

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.

Quoted 15 lines
Quoted 15 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
+
        vmmc-supply = <&ab8500_ldo_aux3_reg>;
        vqmmc-supply = <&vmmci>;
 
drivers/mmc/host/mmci.c +1 -0
index d6f20ba..76e41ba 100644
@@ -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;
 
Quoted 7 lines

drivers/mmc/host/mmci.c static struct mmc_host_ops mmci_ops = { · line 1398

Quoted 3 lines
drivers/mmc/host/mmci.c +3 -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

#14 lore raw

PATCH 5/20 mmc: mmci: Add DT bindings for signal direction

Quoted 26 lines · Ulf Hansson
Quoted 13 lines · Rob Herring
Quoted 12 lines · 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.

---
 Documentation/devicetree/bindings/mmc/mmci.txt |    4 ++++
 drivers/mmc/host/mmci.c                        |    7 +++++++
 2 files changed, 11 insertions(+)
Quoted 11 lines

Documentation/devicetree/bindings/mmc/mmci.txt Optional properties: · line 18

Quoted 9 lines
Documentation/devicetree/bindings/mmc/mmci.txt +1 -0
index d167562..eb9ad86 100644
@@ -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.

Quoted 2 lines

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.

Quoted 14 lines
Quoted 8 lines
Quoted 8 lines
Documentation/devicetree/bindings/mmc/mmci.txt +0 -0
 Example:
 
@@ -37,6 +38,9 @@ sdi0_per1 at 80126000 {
        mmc-cap-mmc-highspeed;
        cd-gpios  = <&gpio2 31 0x4>; // 95
 
Quoted 5 lines

Documentation/devicetree/bindings/mmc/mmci.txt sdi0_per1 at 80126000 { · line 42

Quoted 2 lines
Documentation/devicetree/bindings/mmc/mmci.txt +2 -0
+       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.

Quoted 5 lines

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.

Quoted 9 lines
Quoted 3 lines

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

#15 lore raw

PATCH 6/20 mmc: mmci: Use the common mmc DT parser

In reply to 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.

---
 drivers/mmc/host/mmci.c |   92 +++++++++++++++++------------------------------
 1 file changed, 33 insertions(+), 59 deletions(-)
drivers/mmc/host/mmci.c +33 -59
index 76e41ba..2e1d1b2 100644
@@ -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;
Signature · 1 line
1.7.9.5
#16 lore raw

PATCH 7/20 ARM: ux500: Add mmci signal directions in DT for href

In reply to Ulf Hansson
---
 arch/arm/boot/dts/ste-href.dtsi |    5 +++++
 1 file changed, 5 insertions(+)
arch/arm/boot/dts/ste-href.dtsi +5 -0
index 6cb9b68..d50fe24 100644
@@ -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";
Signature · 1 line
1.7.9.5
#17 lore raw

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

In reply to Ulf Hansson

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

---
 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(-)
arch/arm/boot/dts/ste-ccu9540.dts +3 -3
index 2295087..651c56d 100644
@@ -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";
arch/arm/boot/dts/ste-href.dtsi +4 -4
index d50fe24..e830c37 100644
@@ -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>;
arch/arm/boot/dts/ste-snowball.dts +2 -2
index a2f632d..474ef832 100644
@@ -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>;
Signature · 1 line
1.7.9.5
#19 lore raw

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

In reply to 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 <[email protected]>
---
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi +2 -2
index 5acc044..d316c95 100644
@@ -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";
Signature · 1 line
1.7.9.5
#21 lore raw

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

In reply to Ulf Hansson

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

---
 arch/arm/boot/dts/ste-u300.dts |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/ste-u300.dts +2 -2
index 6fe688e..82a6616 100644
@@ -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>;
Signature · 1 line
1.7.9.5
#23 lore raw

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

In reply to 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.

---
 Documentation/devicetree/bindings/mmc/mmci.txt |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/mmc/mmci.txt +6 -4
index eb9ad86..f9fbcb4 100644
@@ -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 at 80126000 {
@@ -34,8 +36,8 @@ sdi0_per1 at 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 |
Signature · 1 line
1.7.9.5
#24 lore raw

PATCH 12/20 mmc: mmci: Enable MMC_CAP_CMD23

In reply to 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.

---
 drivers/mmc/host/mmci.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/mmc/host/mmci.c +3 -0
index 2e1d1b2..edf3cfd 100644
@@ -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);
Signature · 1 line
1.7.9.5
#25 lore raw

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

In reply to Ulf Hansson
---
 arch/arm/boot/dts/ste-href.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/boot/dts/ste-href.dtsi +6 -0
index e830c37..be34beb 100644
@@ -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>;
Signature · 1 line
1.7.9.5
#27 lore raw

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

In reply to 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 <[email protected]>
Cc Mark Brown <[email protected]>

---

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(+)
drivers/regulator/db8500-prcmu.c +2 -0
index 846acf2..617c1ad 100644
@@ -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,
 	},
Signature · 1 line
1.7.9.5
maintainer
#28 lore raw

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

Quoted 2 lines · Ulf Hansson

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/7f798cb9/attachment.sig>

#29 lore raw

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

Quoted 8 lines · Mark Brown
Quoted 2 lines · Ulf Hansson

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

Quoted 6 lines

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

maintainer
#30 lore raw

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

In reply to Ulf Hansson
Quoted 2 lines · 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.

Applied, thanks. If the rest of the series can get applied I can
easily drop this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/cda303ca/attachment-0001.sig>

#31 lore raw

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

In reply to 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.

---
 arch/arm/boot/dts/ste-href.dtsi |    1 +
 1 file changed, 1 insertion(+)
arch/arm/boot/dts/ste-href.dtsi +1 -0
index be34beb..bf449de 100644
@@ -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>;
Signature · 1 line
1.7.9.5
#32 lore raw

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

Quoted 17 lines · 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.

---
 arch/arm/boot/dts/ste-href.dtsi |    1 +
 1 file changed, 1 insertion(+)
arch/arm/boot/dts/ste-href.dtsi +0 -0
index be34beb..bf449de 100644

arch/arm/boot/dts/ste-href.dtsi line 158

Quoted 4 lines
arch/arm/boot/dts/ste-href.dtsi +1 -0
@@ -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...

Yours,
Linus Walleij

#33 lore raw

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

Quoted 14 lines · Linus Walleij
Quoted 12 lines · 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.

---
 arch/arm/boot/dts/ste-href.dtsi |    1 +
 1 file changed, 1 insertion(+)
Quoted 12 lines

arch/arm/boot/dts/ste-href.dtsi line 158

Quoted 9 lines
arch/arm/boot/dts/ste-href.dtsi +1 -0
index be34beb..bf449de 100644
@@ -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

Quoted 5 lines

Yours,
Linus Walleij

#34 lore raw

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

Quoted 28 lines · Ulf Hansson
Quoted 14 lines · Linus Walleij
Quoted 12 lines · 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.

---
 arch/arm/boot/dts/ste-href.dtsi |    1 +
 1 file changed, 1 insertion(+)
Quoted 12 lines

arch/arm/boot/dts/ste-href.dtsi line 158

Quoted 9 lines
arch/arm/boot/dts/ste-href.dtsi +1 -0
index be34beb..bf449de 100644
@@ -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...

Quoted 6 lines

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

Quoted 9 lines

Kind regards
Ulf Hansson

Quoted 5 lines

Yours,
Linus Walleij

#35 lore raw

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

In reply to 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.

---
 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
arch/arm/mach-ux500/Makefile +1 -2
index de544aa..9741de95 100644
@@ -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
arch/arm/mach-ux500/board-mop500-sdi.c deleted +0 -166

166 lines not on this page · raw message

arch/arm/mach-ux500/board-mop500.h +0 -5
index 32cc0d8..7c7b0ad 100644
@@ -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;
arch/arm/mach-ux500/cpu-db8500.c +0 -4
index 8820f60..fa308f0 100644
@@ -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,
Signature · 1 line
1.7.9.5
#37 lore raw

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

In reply to Ulf Hansson

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

---
 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(-)
drivers/mmc/host/mmci.c +8 -16
index edf3cfd..bef3f85 100644
@@ -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;
drivers/mmc/host/mmci.h +1 -0
index 8fc5814..6fdd11b 100644
@@ -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;
include/linux/amba/mmci.h +0 -4
index 47ff176..0d3ff95 100644
@@ -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;
Signature · 1 line
1.7.9.5
#38 lore raw

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

In reply to Ulf Hansson

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

---
 drivers/mmc/host/mmci.c   |    2 --
 include/linux/amba/mmci.h |    5 -----
 2 files changed, 7 deletions(-)
drivers/mmc/host/mmci.c +0 -2
index bef3f85..a7bda79 100644
@@ -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;
include/linux/amba/mmci.h +0 -5
index 0d3ff95..b992fc9 100644
@@ -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;
Signature · 1 line
1.7.9.5
#39 lore raw

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

In reply to Ulf Hansson

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

---
 drivers/mmc/host/mmci.c   |   24 +-----------------------
 include/linux/amba/mmci.h |   17 -----------------
 2 files changed, 1 insertion(+), 40 deletions(-)
drivers/mmc/host/mmci.c +1 -23
index a7bda79..181445e 100644
@@ -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;
 }
include/linux/amba/mmci.h +0 -17
index b992fc9..bf339ff 100644
@@ -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
Signature · 1 line
1.7.9.5
#40 lore raw

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

In reply to Ulf Hansson

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

---
 drivers/mmc/host/mmci.c   |    5 +----
 include/linux/amba/mmci.h |    4 ----
 2 files changed, 1 insertion(+), 8 deletions(-)
drivers/mmc/host/mmci.c +1 -4
index 181445e..cbbb87e 100644
@@ -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);
include/linux/amba/mmci.h +0 -4
index bf339ff..8c98113 100644
@@ -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 *);
Signature · 1 line
1.7.9.5