[PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Russell King - ARM Linux]

All,

This is where I'm at with trying to clean up the SDHCI mess, and sort out
issues I've noticed when trying to get UHS support working on CuBoxes.
This is my full patch set, but I recommend not applying patch 37 as there
appears to be a hardware issue preventing it working reliably.

In any case, patches 0-33 inclusive are the SDHCI clean up, based against
v3.15-rc1.  Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
those, and 38 adds the Broadcom Wifi and BT support for CuBox.

The questions over how to handle these devices were never properly settled,
so I recommend against merging patch 34 onwards.  As for the rest, I'm not
planning on any further work, so it may be a good idea for people to
consider testing them with a view to getting them merged.

 Documentation/devicetree/bindings/mmc/mmc.txt |  11 +
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi        |  34 +-
 arch/arm/boot/dts/imx6qdl-microsom.dtsi       |  98 ++++
 drivers/mmc/core/core.c                       |  42 ++
 drivers/mmc/core/host.c                       |  68 +++
 drivers/mmc/core/sdio_irq.c                   |  41 +-
 drivers/mmc/host/Kconfig                      |  63 +--
 drivers/mmc/host/dw_mmc.c                     |   2 +
 drivers/mmc/host/sdhci-acpi.c                 |   8 +
 drivers/mmc/host/sdhci-bcm-kona.c             |   4 +
 drivers/mmc/host/sdhci-bcm2835.c              |   4 +
 drivers/mmc/host/sdhci-cns3xxx.c              |  13 +-
 drivers/mmc/host/sdhci-dove.c                 |   4 +
 drivers/mmc/host/sdhci-esdhc-imx.c            |  82 +--
 drivers/mmc/host/sdhci-esdhc.h                |   4 +-
 drivers/mmc/host/sdhci-of-arasan.c            |   4 +
 drivers/mmc/host/sdhci-of-esdhc.c             |  70 ++-
 drivers/mmc/host/sdhci-of-hlwd.c              |   4 +
 drivers/mmc/host/sdhci-pci.c                  |   9 +-
 drivers/mmc/host/sdhci-pltfm.c                |   4 +
 drivers/mmc/host/sdhci-pxav2.c                |  14 +-
 drivers/mmc/host/sdhci-pxav3.c                |  13 +-
 drivers/mmc/host/sdhci-s3c.c                  |  36 +-
 drivers/mmc/host/sdhci-sirf.c                 |   4 +
 drivers/mmc/host/sdhci-spear.c                |   5 +-
 drivers/mmc/host/sdhci-tegra.c                |  27 +-
 drivers/mmc/host/sdhci.c                      | 728 +++++++++++++-------------
 drivers/mmc/host/sdhci.h                      |  20 +-
 include/linux/mmc/host.h                      |   8 +
 include/linux/mmc/sdhci.h                     |  15 +-
 30 files changed, 885 insertions(+), 554 deletions(-)


-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 34/38] mmc: add support for power-on sequencing through DT

[Russell King]

From: Olof Johansson <olof@lixom.net>

This patch enables support for power-on sequencing of SDIO peripherals through DT.

In general, it's quite common that wifi modules and other similar
peripherals have several signals in addition to the SDIO interface that
needs wiggling before the module will power on. It's common to have a
reference clock, one or several power rails and one or several lines
for reset/enable type functions.

The binding as written today introduces a number of reset gpios,
a regulator and a clock specifier. The code will handle up to 2 gpio
reset lines, but it's trivial to increase to more than that if needed
at some point.

Implementation-wise, the MMC core has been changed to handle this during
host power up, before the host interface is powered on. I have not yet
implemented the power-down side, I wanted people to have a chance for
reporting back w.r.t. issues (or comments on the bindings) first.

I have not tested the regulator portion, since the system and module
I'm working on doesn't need one (Samsung Chromebook with Marvell
8797-based wifi). Testing of those portions (and reporting back) would
be appreciated.

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++
 drivers/mmc/core/core.c                       | 42 +++++++++++++++++++++++++++
 drivers/mmc/core/host.c                       | 30 ++++++++++++++++++-
 include/linux/mmc/host.h                      |  5 ++++
 4 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 9dce540771fb..b9b534ebc0c5 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -5,6 +5,8 @@ these definitions.
 Interpreted by the OF core:
 - reg: Registers location and length.
 - interrupts: Interrupts used by the MMC controller.
+- clocks: Clocks needed for the host controller, if any.
+- clock-names: Goes with clocks above.
 
 Card detection:
 If no property below is supplied, host native card detect is used.
@@ -39,6 +41,15 @@ If no property below is supplied, host native card detect is used.
 - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
 - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
 
+Card power and reset control:
+The following properties can be specified for cases where the MMC
+peripheral needs additional reset, regulator and clock lines. It is for
+example common for WiFi/BT adapters to have these separate from the main
+MMC bus:
+  - card-reset-gpios: Specify GPIOs for card reset (reset active low)
+  - card-external-vcc-supply: Regulator to drive (independent) card VCC
+  - clock with name "card_ext_clock": External clock provided to the card
+
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
 line levels. We choose to follow the SDHCI standard, which specifies both those
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2aaaf9..41c4033ec765 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -13,11 +13,13 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/clk.h>
 #include <linux/completion.h>
 #include <linux/device.h>
 #include <linux/delay.h>
 #include <linux/pagemap.h>
 #include <linux/err.h>
+#include <linux/gpio.h>
 #include <linux/leds.h>
 #include <linux/scatterlist.h>
 #include <linux/log2.h>
@@ -1504,6 +1506,43 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type)
 	mmc_host_clk_release(host);
 }
 
+static void mmc_card_power_up(struct mmc_host *host)
+{
+	int i;
+	struct gpio_desc **gds = host->card_reset_gpios;
+
+	for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
+		if (gds[i]) {
+			dev_dbg(host->parent, "Asserting reset line %d", i);
+			gpiod_set_value(gds[i], 1);
+		}
+	}
+
+	if (host->card_regulator) {
+		dev_dbg(host->parent, "Enabling external regulator");
+		if (regulator_enable(host->card_regulator))
+			dev_err(host->parent, "Failed to enable external regulator");
+	}
+
+	if (host->card_clk) {
+		dev_dbg(host->parent, "Enabling external clock");
+		clk_prepare_enable(host->card_clk);
+	}
+
+	/* 2ms delay to let clocks and power settle */
+	mmc_delay(20);
+
+	for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
+		if (gds[i]) {
+			dev_dbg(host->parent, "Deasserting reset line %d", i);
+			gpiod_set_value(gds[i], 0);
+		}
+	}
+
+	/* 2ms delay to after reset release */
+	mmc_delay(20);
+}
+
 /*
  * Apply power to the MMC stack.  This is a two-stage process.
  * First, we enable power to the card without the clock running.
@@ -1520,6 +1559,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
 	if (host->ios.power_mode == MMC_POWER_ON)
 		return;
 
+	/* Power up the card/module first, if needed */
+	mmc_card_power_up(host);
+
 	mmc_host_clk_hold(host);
 
 	host->ios.vdd = fls(ocr) - 1;
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index fdea825dbb24..abc60f39aa7e 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -12,14 +12,18 @@
  *  MMC host class device management
  */
 
+#include <linux/kernel.h>
+#include <linux/clk.h>
 #include <linux/device.h>
 #include <linux/err.h>
+#include <linux/gpio/consumer.h>
 #include <linux/idr.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
 #include <linux/pagemap.h>
 #include <linux/export.h>
 #include <linux/leds.h>
+#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 #include <linux/suspend.h>
 
@@ -312,7 +316,7 @@ int mmc_of_parse(struct mmc_host *host)
 	u32 bus_width;
 	bool explicit_inv_wp, gpio_inv_wp = false;
 	enum of_gpio_flags flags;
-	int len, ret, gpio;
+	int i, len, ret, gpio;
 
 	if (!host->parent || !host->parent->of_node)
 		return 0;
@@ -415,6 +419,30 @@ int mmc_of_parse(struct mmc_host *host)
 	if (explicit_inv_wp ^ gpio_inv_wp)
 		host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
 
+	/* Parse card power/reset/clock control */
+	if (of_find_property(np, "card-reset-gpios", NULL)) {
+		struct gpio_desc *gpd;
+		for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
+			gpd = devm_gpiod_get_index(host->parent, "card-reset", i);
+			if (IS_ERR(gpd))
+				break;
+			gpiod_direction_output(gpd, 0);
+			host->card_reset_gpios[i] = gpd;
+		}
+
+		gpd = devm_gpiod_get_index(host->parent, "card-reset", ARRAY_SIZE(host->card_reset_gpios));
+		if (!IS_ERR(gpd)) {
+			dev_warn(host->parent, "More reset gpios than we can handle");
+			gpiod_put(gpd);
+		}
+	}
+
+	host->card_clk = of_clk_get_by_name(np, "card_ext_clock");
+	if (IS_ERR(host->card_clk))
+		host->card_clk = NULL;
+
+	host->card_regulator = regulator_get(host->parent, "card-external-vcc");
+
 	if (of_find_property(np, "cap-sd-highspeed", &len))
 		host->caps |= MMC_CAP_SD_HIGHSPEED;
 	if (of_find_property(np, "cap-mmc-highspeed", &len))
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 28c5e796292f..c3a8c5f6c9b8 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -294,6 +294,11 @@ struct mmc_host {
 	unsigned long           clkgate_delay;
 #endif
 
+	/* card specific properties to deal with power and reset */
+	struct regulator	*card_regulator; /* External VCC needed by the card */
+	struct gpio_desc	*card_reset_gpios[2]; /* External resets, active low */
+	struct clk		*card_clk;	/* External clock needed by the card */
+
 	/* host specific block data */
 	unsigned int		max_seg_size;	/* see blk_queue_max_segment_size */
 	unsigned short		max_segs;	/* see blk_queue_max_segments */
-- 
1.8.3.1

[PATCH 37/38] ARM: cubox-i: add support for SD UHS-1 cards

[Russell King]

Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
---
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index c2a24888a276..c928c0a5e3cc 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -111,6 +111,28 @@
 				MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
 			>;
 		};
+
+		pinctrl_cubox_i_usdhc2_100mhz: cubox-i-usdhc2-100mhz {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD    0x170b9
+				MX6QDL_PAD_SD2_CLK__SD2_CLK    0x100b9
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130b9
+			>;
+		};
+
+		pinctrl_cubox_i_usdhc2_200mhz: cubox-i-usdhc2-200mhz {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD    0x170f9
+				MX6QDL_PAD_SD2_CLK__SD2_CLK    0x100f9
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130f9
+			>;
+		};
 	};
 };
 
@@ -131,8 +153,10 @@
 };
 
 &usdhc2 {
-	pinctrl-names = "default";
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
 	pinctrl-0 = <&pinctrl_cubox_i_usdhc2_aux &pinctrl_cubox_i_usdhc2>;
+	pinctrl-1 = <&pinctrl_cubox_i_usdhc2_aux &pinctrl_cubox_i_usdhc2_100mhz>;
+	pinctrl-2 = <&pinctrl_cubox_i_usdhc2_aux &pinctrl_cubox_i_usdhc2_200mhz>;
 	vmmc-supply = <&reg_3p3v>;
 	cd-gpios = <&gpio1 4 0>;
 	status = "okay";
-- 
1.8.3.1

--
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 38/38] ARM: cubox-i: add support for Wifi/BT

[Russell King]

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi  |  8 +++
 arch/arm/boot/dts/imx6qdl-microsom.dtsi | 98 +++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index c928c0a5e3cc..67fe5585f6dd 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -152,6 +152,14 @@
 	status = "okay";
 };
 
+&uart4 {
+	status = "okay";
+};
+
+&usdhc1 {
+	status = "okay";
+};
+
 &usdhc2 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
 	pinctrl-0 = <&pinctrl_cubox_i_usdhc2_aux &pinctrl_cubox_i_usdhc2>;
diff --git a/arch/arm/boot/dts/imx6qdl-microsom.dtsi b/arch/arm/boot/dts/imx6qdl-microsom.dtsi
index d729d0b15f25..a5d72895d9ce 100644
--- a/arch/arm/boot/dts/imx6qdl-microsom.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-microsom.dtsi
@@ -1,9 +1,69 @@
 /*
  * Copyright (C) 2013,2014 Russell King
  */
+#include <dt-bindings/gpio/gpio.h>
+/ {
+	regulators {
+		compatible = "simple-bus";
+
+		reg_brcm_osc: brcm-osc-reg {
+			compatible = "regulator-fixed";
+			enable-active-high;
+			gpio = <&gpio5 5 0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_microsom_brcm_osc_reg>;
+			regulator-name = "brcm_osc_reg";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		reg_brcm: brcm-reg {
+			compatible = "regulator-fixed";
+			enable-active-high;
+			gpio = <&gpio3 19 0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_microsom_brcm_reg>;
+			regulator-name = "brcm_reg";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			startup-delay-us = <200000>;
+		};
+	};
+};
 
 &iomuxc {
 	microsom {
+		pinctrl_microsom_brcm_osc_reg: microsom-brcm-osc-reg {
+			fsl,pins = <
+				MX6QDL_PAD_DISP0_DAT11__GPIO5_IO05 0x40013070
+			>;
+		};
+
+		pinctrl_microsom_brcm_reg: microsom-brcm-reg {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x40013070
+			>;
+		};
+
+		pinctrl_microsom_brcm_wifi: microsom-brcm-wifi {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_8__XTALOSC_REF_CLK_32K	0x1b0b0
+				MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20	0x40013070
+				MX6QDL_PAD_CSI0_DAT8__GPIO5_IO26	0x40013070
+				MX6QDL_PAD_CSI0_DAT9__GPIO5_IO27	0x40013070
+			>;
+		};
+
+		pinctrl_microsom_brcm_bt: microsom-brcm-bt {
+			fsl,pins = <
+				MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00	0x40013070
+				MX6QDL_PAD_CSI0_DAT15__GPIO6_IO01	0x40013070
+				MX6QDL_PAD_CSI0_DAT18__GPIO6_IO04	0x40013070
+			>;
+		};
+
 		pinctrl_microsom_uart1: microsom-uart1 {
 			fsl,pins = <
 				MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA	0x1b0b1
@@ -11,6 +71,15 @@
 			>;
 		};
 
+		pinctrl_microsom_uart4_1: microsom-uart4 {
+			fsl,pins = <
+				MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
+				MX6QDL_PAD_CSI0_DAT13__UART4_RX_DATA 0x1b0b1
+				MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
+				MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
+			>;
+		};
+
 		pinctrl_microsom_usbotg: microsom-usbotg {
 			/*
 			 * Similar to pinctrl_usbotg_2, but we want it
@@ -18,6 +87,17 @@
 			 */
 			fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
 		};
+
+		pinctrl_microsom_usdhc1: microsom-usdhc1 {
+			fsl,pins = <
+				MX6QDL_PAD_SD1_CMD__SD1_CMD    0x17059
+				MX6QDL_PAD_SD1_CLK__SD1_CLK    0x10059
+				MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+				MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+				MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+				MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+			>;
+		};
 	};
 };
 
@@ -27,7 +107,25 @@
 	status = "okay";
 };
 
+/* UART4 - Connected to optional BRCM Wifi/BT/FM */
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_microsom_brcm_bt &pinctrl_microsom_uart4_1>;
+	fsl,uart-has-rtscts;
+};
+
 &usbotg {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_microsom_usbotg>;
 };
+
+/* USDHC1 - Connected to optional BRCM Wifi/BT/FM */
+&usdhc1 {
+	card-external-vcc-supply = <&reg_brcm>;
+	card-reset-gpios = <&gpio5 26 GPIO_ACTIVE_LOW>, <&gpio6 0 GPIO_ACTIVE_LOW>;
+	keep-power-in-suspend;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_microsom_brcm_wifi &pinctrl_microsom_usdhc1>;
+	vmmc-supply = <&reg_brcm>;
+};
-- 
1.8.3.1

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 23 April 2014 20:55, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> All,
>
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appears to be a hardware issue preventing it working reliably.
>
> In any case, patches 0-33 inclusive are the SDHCI clean up, based against
> v3.15-rc1.  Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
> those, and 38 adds the Broadcom Wifi and BT support for CuBox.
>
> The questions over how to handle these devices were never properly settled,
> so I recommend against merging patch 34 onwards.  As for the rest, I'm not
> planning on any further work, so it may be a good idea for people to
> consider testing them with a view to getting them merged.
>

I have looked though the patches up until patch 33 and this is clearly
a nice piece of clean-up /fixes work for sdhci. Besides my minor
comments per patch, I don't have any objections code-review wise to
proceed merging them.

I have also tried to applied them on Chris' mmc-next branch,
unfortunate it fails at patch 23, so it would be nice to get a
re-based patchset for the mmc-next branch.

Kind regards
Ulf Hansson

>  Documentation/devicetree/bindings/mmc/mmc.txt |  11 +
>  arch/arm/boot/dts/imx6qdl-cubox-i.dtsi        |  34 +-
>  arch/arm/boot/dts/imx6qdl-microsom.dtsi       |  98 ++++
>  drivers/mmc/core/core.c                       |  42 ++
>  drivers/mmc/core/host.c                       |  68 +++
>  drivers/mmc/core/sdio_irq.c                   |  41 +-
>  drivers/mmc/host/Kconfig                      |  63 +--
>  drivers/mmc/host/dw_mmc.c                     |   2 +
>  drivers/mmc/host/sdhci-acpi.c                 |   8 +
>  drivers/mmc/host/sdhci-bcm-kona.c             |   4 +
>  drivers/mmc/host/sdhci-bcm2835.c              |   4 +
>  drivers/mmc/host/sdhci-cns3xxx.c              |  13 +-
>  drivers/mmc/host/sdhci-dove.c                 |   4 +
>  drivers/mmc/host/sdhci-esdhc-imx.c            |  82 +--
>  drivers/mmc/host/sdhci-esdhc.h                |   4 +-
>  drivers/mmc/host/sdhci-of-arasan.c            |   4 +
>  drivers/mmc/host/sdhci-of-esdhc.c             |  70 ++-
>  drivers/mmc/host/sdhci-of-hlwd.c              |   4 +
>  drivers/mmc/host/sdhci-pci.c                  |   9 +-
>  drivers/mmc/host/sdhci-pltfm.c                |   4 +
>  drivers/mmc/host/sdhci-pxav2.c                |  14 +-
>  drivers/mmc/host/sdhci-pxav3.c                |  13 +-
>  drivers/mmc/host/sdhci-s3c.c                  |  36 +-
>  drivers/mmc/host/sdhci-sirf.c                 |   4 +
>  drivers/mmc/host/sdhci-spear.c                |   5 +-
>  drivers/mmc/host/sdhci-tegra.c                |  27 +-
>  drivers/mmc/host/sdhci.c                      | 728 +++++++++++++-------------
>  drivers/mmc/host/sdhci.h                      |  20 +-
>  include/linux/mmc/host.h                      |   8 +
>  include/linux/mmc/sdhci.h                     |  15 +-
>  30 files changed, 885 insertions(+), 554 deletions(-)
>
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 34/38] mmc: add support for power-on sequencing through DT

[Maxime Ripard]

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

Hi Russell,

On Wed, Apr 23, 2014 at 08:09:04PM +0100, Russell King wrote:
> From: Olof Johansson <olof@lixom.net>
> 
> This patch enables support for power-on sequencing of SDIO peripherals through DT.
> 
> In general, it's quite common that wifi modules and other similar
> peripherals have several signals in addition to the SDIO interface that
> needs wiggling before the module will power on. It's common to have a
> reference clock, one or several power rails and one or several lines
> for reset/enable type functions.
> 
> The binding as written today introduces a number of reset gpios,
> a regulator and a clock specifier. The code will handle up to 2 gpio
> reset lines, but it's trivial to increase to more than that if needed
> at some point.
> 
> Implementation-wise, the MMC core has been changed to handle this during
> host power up, before the host interface is powered on. I have not yet
> implemented the power-down side, I wanted people to have a chance for
> reporting back w.r.t. issues (or comments on the bindings) first.
> 
> I have not tested the regulator portion, since the system and module
> I'm working on doesn't need one (Samsung Chromebook with Marvell
> 8797-based wifi). Testing of those portions (and reporting back) would
> be appreciated.
> 
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++
>  drivers/mmc/core/core.c                       | 42 +++++++++++++++++++++++++++
>  drivers/mmc/core/host.c                       | 30 ++++++++++++++++++-
>  include/linux/mmc/host.h                      |  5 ++++
>  4 files changed, 87 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 9dce540771fb..b9b534ebc0c5 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> @@ -5,6 +5,8 @@ these definitions.
>  Interpreted by the OF core:
>  - reg: Registers location and length.
>  - interrupts: Interrupts used by the MMC controller.
> +- clocks: Clocks needed for the host controller, if any.
> +- clock-names: Goes with clocks above.
>  
>  Card detection:
>  If no property below is supplied, host native card detect is used.
> @@ -39,6 +41,15 @@ If no property below is supplied, host native card detect is used.
>  - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
>  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
>  
> +Card power and reset control:
> +The following properties can be specified for cases where the MMC
> +peripheral needs additional reset, regulator and clock lines. It is for
> +example common for WiFi/BT adapters to have these separate from the main
> +MMC bus:
> +  - card-reset-gpios: Specify GPIOs for card reset (reset active low)

That probably can use the reset frameworks bindings and the reset-gpio
driver Philipp Zabel has been working on.

> +  - card-external-vcc-supply: Regulator to drive (independent) card VCC
> +  - clock with name "card_ext_clock": External clock provided to the card

I'm not sure this is the right path.

This looks pretty harmless for now, but I'm pretty concerned that it's
just going to be an ever-increasing list of properties to deal with
the various corner-cases everyone has, like for example how to enforce
a given frequency for that card_ext_clock, or the fact that it has
several SDIO cards connected to them, each with different
clocks/reset/regulator lines.

While all of this would easily be solved by representing all this as a
bus, like it should, with subdevices grabbing their own clocks and
having whatever property they need.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Russell King - ARM Linux]

On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> I have looked though the patches up until patch 33 and this is clearly
> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> comments per patch, I don't have any objections code-review wise to
> proceed merging them.
> 
> I have also tried to applied them on Chris' mmc-next branch,
> unfortunate it fails at patch 23, so it would be nice to get a
> re-based patchset for the mmc-next branch.

I /could/ rebase it but then I wouldn't be able to produce the patch
sets/patches for others [*] (such as the Novena project) to derive
their kernel tree from my iMX6 patch set.

What I'd prefer is to keep the patch set intact, and provide Chris
with a pull request for it up to patch 33, which would need a
conflict fixed - and this would mean that I can be sure that what
I'm testing, and what I'm distributing is what Chris will also be
submitting.

* - this currently stands at 230 patches in all - mmc + l2c + fec +
    imx-drm + other iMX6 changes.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> I have looked though the patches up until patch 33 and this is clearly
>> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> comments per patch, I don't have any objections code-review wise to
>> proceed merging them.
>>
>> I have also tried to applied them on Chris' mmc-next branch,
>> unfortunate it fails at patch 23, so it would be nice to get a
>> re-based patchset for the mmc-next branch.
>
> I /could/ rebase it but then I wouldn't be able to produce the patch
> sets/patches for others [*] (such as the Novena project) to derive
> their kernel tree from my iMX6 patch set.
>
> What I'd prefer is to keep the patch set intact, and provide Chris
> with a pull request for it up to patch 33, which would need a
> conflict fixed - and this would mean that I can be sure that what
> I'm testing, and what I'm distributing is what Chris will also be
> submitting.

Whether there are more than one conflict, I don't know. I just stopped
at patch 23.

Moreover, there are other patches for sdhci that have been posted and
being discussed. In principle, we then need to put all these on hold
to prevent further conflicts. I guess that doable, as long as we don't
to that for too long. Maybe Chris have some more thoughts how to
handle this!?

Kind regards
Ulf Hansson

>
> * - this currently stands at 230 patches in all - mmc + l2c + fec +
>     imx-drm + other iMX6 changes.
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Russell King - ARM Linux]

On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> >> I have looked though the patches up until patch 33 and this is clearly
> >> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> >> comments per patch, I don't have any objections code-review wise to
> >> proceed merging them.
> >>
> >> I have also tried to applied them on Chris' mmc-next branch,
> >> unfortunate it fails at patch 23, so it would be nice to get a
> >> re-based patchset for the mmc-next branch.
> >
> > I /could/ rebase it but then I wouldn't be able to produce the patch
> > sets/patches for others [*] (such as the Novena project) to derive
> > their kernel tree from my iMX6 patch set.
> >
> > What I'd prefer is to keep the patch set intact, and provide Chris
> > with a pull request for it up to patch 33, which would need a
> > conflict fixed - and this would mean that I can be sure that what
> > I'm testing, and what I'm distributing is what Chris will also be
> > submitting.
> 
> Whether there are more than one conflict, I don't know. I just stopped
> at patch 23.
> 
> Moreover, there are other patches for sdhci that have been posted and
> being discussed. In principle, we then need to put all these on hold
> to prevent further conflicts. I guess that doable, as long as we don't
> to that for too long. Maybe Chris have some more thoughts how to
> handle this!?

This is nothing new or unexpected - it was last posted back in February,
and I elected that it should be held off until after the last merge
window.

Unfortunately, I didn't have time to post it immediately after the merge
window closed, partly because it needed to be rebased on top of tglx's
IRQ changes on which it depends.  I was carrying those as separate commits
to the ones Thomas was carrying in his tree - and in the event, Thomas had
modified his patches slightly between sending me copies of them and the
versions he sent during the merge window.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 24 April 2014 12:57, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 12:17, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
>> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> >> I have looked though the patches up until patch 33 and this is clearly
>> >> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> >> comments per patch, I don't have any objections code-review wise to
>> >> proceed merging them.
>> >>
>> >> I have also tried to applied them on Chris' mmc-next branch,
>> >> unfortunate it fails at patch 23, so it would be nice to get a
>> >> re-based patchset for the mmc-next branch.
>> >
>> > I /could/ rebase it but then I wouldn't be able to produce the patch
>> > sets/patches for others [*] (such as the Novena project) to derive
>> > their kernel tree from my iMX6 patch set.
>> >
>> > What I'd prefer is to keep the patch set intact, and provide Chris
>> > with a pull request for it up to patch 33, which would need a
>> > conflict fixed - and this would mean that I can be sure that what
>> > I'm testing, and what I'm distributing is what Chris will also be
>> > submitting.
>>
>> Whether there are more than one conflict, I don't know. I just stopped
>> at patch 23.
>>
>> Moreover, there are other patches for sdhci that have been posted and
>> being discussed. In principle, we then need to put all these on hold
>> to prevent further conflicts. I guess that doable, as long as we don't
>> to that for too long. Maybe Chris have some more thoughts how to
>> handle this!?
>
> This is nothing new or unexpected - it was last posted back in February,
> and I elected that it should be held off until after the last merge
> window.
>
> Unfortunately, I didn't have time to post it immediately after the merge
> window closed, partly because it needed to be rebased on top of tglx's
> IRQ changes on which it depends.  I was carrying those as separate commits
> to the ones Thomas was carrying in his tree - and in the event, Thomas had
> modified his patches slightly between sending me copies of them and the
> versions he sent during the merge window.

Okay, so let's keep up the frequency here then. I only had some minor
comments, please fix them and send a v2.

How about if I resolve the conflicts and send the pull request to
Chris? I suppose it makes life a bit easier for Chris.

Kind regards
Ulf Hansson

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 00/38] MMC updates, plus CuBox-i WiFi support

[Russell King - ARM Linux]

On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > This is nothing new or unexpected - it was last posted back in February,
> > and I elected that it should be held off until after the last merge
> > window.
> >
> > Unfortunately, I didn't have time to post it immediately after the merge
> > window closed, partly because it needed to be rebased on top of tglx's
> > IRQ changes on which it depends.  I was carrying those as separate commits
> > to the ones Thomas was carrying in his tree - and in the event, Thomas had
> > modified his patches slightly between sending me copies of them and the
> > versions he sent during the merge window.
> 
> Okay, so let's keep up the frequency here then. I only had some minor
> comments, please fix them and send a v2.

Right, so I've updated the patches, and added one ack to one patch.
That seems insufficient to me - the only platform these have been
tested on is iMX6, which is sdhci-esdhc-imx.c.

They _really_ need testing elsewhere too.  Or is the plan to merge
them and then see about getting people to test them and fix them up
afterwards?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 25 April 2014 11:03, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> > This is nothing new or unexpected - it was last posted back in February,
>> > and I elected that it should be held off until after the last merge
>> > window.
>> >
>> > Unfortunately, I didn't have time to post it immediately after the merge
>> > window closed, partly because it needed to be rebased on top of tglx's
>> > IRQ changes on which it depends.  I was carrying those as separate commits
>> > to the ones Thomas was carrying in his tree - and in the event, Thomas had
>> > modified his patches slightly between sending me copies of them and the
>> > versions he sent during the merge window.
>>
>> Okay, so let's keep up the frequency here then. I only had some minor
>> comments, please fix them and send a v2.
>
> Right, so I've updated the patches, and added one ack to one patch.
> That seems insufficient to me - the only platform these have been
> tested on is iMX6, which is sdhci-esdhc-imx.c.
>
> They _really_ need testing elsewhere too.  Or is the plan to merge
> them and then see about getting people to test them and fix them up
> afterwards?

I was hoping people could start doing tests, before Chris actually
decided to pull them in. Now, if that doesn't happen, we could just
merge them, as you say, and thus we have to fix potential problems
afterwards. I would expect you to help out if problem occurs.

If we decide to not merge in a while, I am not sure how long we could
prevent other sdhci patches from being merged. I guess Chris will have
to take the final call.

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Russell King - ARM Linux]

On Fri, Apr 25, 2014 at 01:18:28PM +0200, Ulf Hansson wrote:
> On 25 April 2014 11:03, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> > On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
> >> On 24 April 2014 12:57, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> >> > This is nothing new or unexpected - it was last posted back in February,
> >> > and I elected that it should be held off until after the last merge
> >> > window.
> >> >
> >> > Unfortunately, I didn't have time to post it immediately after the merge
> >> > window closed, partly because it needed to be rebased on top of tglx's
> >> > IRQ changes on which it depends.  I was carrying those as separate commits
> >> > to the ones Thomas was carrying in his tree - and in the event, Thomas had
> >> > modified his patches slightly between sending me copies of them and the
> >> > versions he sent during the merge window.
> >>
> >> Okay, so let's keep up the frequency here then. I only had some minor
> >> comments, please fix them and send a v2.
> >
> > Right, so I've updated the patches, and added one ack to one patch.
> > That seems insufficient to me - the only platform these have been
> > tested on is iMX6, which is sdhci-esdhc-imx.c.
> >
> > They _really_ need testing elsewhere too.  Or is the plan to merge
> > them and then see about getting people to test them and fix them up
> > afterwards?
> 
> I was hoping people could start doing tests, before Chris actually
> decided to pull them in. Now, if that doesn't happen, we could just
> merge them, as you say, and thus we have to fix potential problems
> afterwards. I would expect you to help out if problem occurs.
> 
> If we decide to not merge in a while, I am not sure how long we could
> prevent other sdhci patches from being merged. I guess Chris will have
> to take the final call.

Or we just drop them for yet another cycle and show how mainline kernel
development sucks, why getting stuff into mainline is utterly painful,
and why using vendor kernels is /soo/ much better than this crap.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Ulf Hansson]

On 25 April 2014 13:20, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Apr 25, 2014 at 01:18:28PM +0200, Ulf Hansson wrote:
>> On 25 April 2014 11:03, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> > On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
>> >> On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> >> > This is nothing new or unexpected - it was last posted back in February,
>> >> > and I elected that it should be held off until after the last merge
>> >> > window.
>> >> >
>> >> > Unfortunately, I didn't have time to post it immediately after the merge
>> >> > window closed, partly because it needed to be rebased on top of tglx's
>> >> > IRQ changes on which it depends.  I was carrying those as separate commits
>> >> > to the ones Thomas was carrying in his tree - and in the event, Thomas had
>> >> > modified his patches slightly between sending me copies of them and the
>> >> > versions he sent during the merge window.
>> >>
>> >> Okay, so let's keep up the frequency here then. I only had some minor
>> >> comments, please fix them and send a v2.
>> >
>> > Right, so I've updated the patches, and added one ack to one patch.
>> > That seems insufficient to me - the only platform these have been
>> > tested on is iMX6, which is sdhci-esdhc-imx.c.
>> >
>> > They _really_ need testing elsewhere too.  Or is the plan to merge
>> > them and then see about getting people to test them and fix them up
>> > afterwards?
>>
>> I was hoping people could start doing tests, before Chris actually
>> decided to pull them in. Now, if that doesn't happen, we could just
>> merge them, as you say, and thus we have to fix potential problems
>> afterwards. I would expect you to help out if problem occurs.
>>
>> If we decide to not merge in a while, I am not sure how long we could
>> prevent other sdhci patches from being merged. I guess Chris will have
>> to take the final call.
>
> Or we just drop them for yet another cycle and show how mainline kernel
> development sucks, why getting stuff into mainline is utterly painful,
> and why using vendor kernels is /soo/ much better than this crap.

Dropping them is too me a bad option and I really don't think that
should be needed.

I would like to encourage people to help out with testing and I
suppose we have to give this at least some time.

Anyway, post your new version. I will create the pull request based on that.

>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Stephen Warren]

On 04/23/2014 12:55 PM, Russell King - ARM Linux wrote:
> All,
> 
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appears to be a hardware issue preventing it working reliably.
> 
> In any case, patches 0-33 inclusive are the SDHCI clean up, based against
> v3.15-rc1.  Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
> those, and 38 adds the Broadcom Wifi and BT support for CuBox.
> 
> The questions over how to handle these devices were never properly settled,
> so I recommend against merging patch 34 onwards.  As for the rest, I'm not
> planning on any further work, so it may be a good idea for people to
> consider testing them with a view to getting them merged.

The series,
Tested-by: Stephen Warren <swarren@nvidia.com>

(On an NVIDIA Tegra "Jetson TK1" board, with the patches applied on top
of next-20140428, also with Andrew Bresticker's Tegra SDHCI patches
"mmc: tegra: disable UHS modes" and "mmc: tegra: fix reporting of base
clock frequency" applied)

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Chris Ball]

Hi,

On Mon, Apr 28 2014, Stephen Warren wrote:
> The series,
> Tested-by: Stephen Warren <swarren@nvidia.com>
>
> (On an NVIDIA Tegra "Jetson TK1" board, with the patches applied on top
> of next-20140428, also with Andrew Bresticker's Tegra SDHCI patches
> "mmc: tegra: disable UHS modes" and "mmc: tegra: fix reporting of base
> clock frequency" applied)

Thanks very much Stephen, Russell for the series, and Ulf.

This seems like a good time to merge to mmc-next and call for testing
in linux-next -- I'm happy to merge a v2 PR when ready.

- Chris.
-- 
Chris Ball   <http://printf.net/>

Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support

[Tim Kryger]

On Mon, Apr 28, 2014 at 9:52 AM, Chris Ball <chris@printf.net> wrote:
> Hi,
>
> On Mon, Apr 28 2014, Stephen Warren wrote:
>> The series,
>> Tested-by: Stephen Warren <swarren@nvidia.com>
>>
>> (On an NVIDIA Tegra "Jetson TK1" board, with the patches applied on top
>> of next-20140428, also with Andrew Bresticker's Tegra SDHCI patches
>> "mmc: tegra: disable UHS modes" and "mmc: tegra: fix reporting of base
>> clock frequency" applied)
>
> Thanks very much Stephen, Russell for the series, and Ulf.
>
> This seems like a good time to merge to mmc-next and call for testing
> in linux-next -- I'm happy to merge a v2 PR when ready.
>
> - Chris.

Hi Russell,

Do you have a rough idea about when you will post your v2 pull request?

I have a pending sdhci patch that I would like to rebase on top of
your latest work once it is available.

Thanks,
Tim Kryger