[PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Wolfram Sang]

So, here is the series to enable basic SD support on r8a7795; no DMA and UHS-I
for now. Will be added incrementally. It turns out that the driver needs a
little love, so some refactoring is also in place before adding the actual
support.

eMMC works in 4-bit mode, too. 8-bit mode sadly fails currently. I'll post MMC
support patches once this issue is fixed.

These patches have been tested on Gen3 (Salvator-X) and Gen2 (Lager), doing
basic operations with SD cards and running the mmc_test driver (its results
point out some potential corner cases to check later).

A branch can be found here (including clock and DTS patches):

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdhi

Changes since RFC (only sent to sh-devel lists):

* patches 1,7,8 are new
* patch 4 drops 10ms wait also for set_clock
* patch 9 also sets MMC_CAP_WAIT_WHILE_BUSY (see comment there)
* some commit message rewording

Please test, comment, apply...

Thanks,

   Wolfram


Shinobu Uehara (1):
  mmc: sdhi: Add EXT_ACC register busy check

Wolfram Sang (8):
  mmc: tmio_dma: remove debug messages with little information
  mmc: sdhi: error message on ENOMEM is superfluous
  mmc: tmio: add flag to reduce delay after changing clock status
  mmc: tmio: remove stale comments
  mmc: sdhi: use faster clock handling on RCar Gen2
  mmc: tmio: refactor set_clock a little
  mmc: tmio: disable clock before changing it
  mmc: sdhi: Add r8a7795 support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/Kconfig                           |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c                  | 54 +++++++++++++++-------
 drivers/mmc/host/tmio_mmc_dma.c                    | 12 -----
 drivers/mmc/host/tmio_mmc_pio.c                    | 27 ++++++-----
 include/linux/mfd/tmio.h                           |  4 ++
 include/linux/mmc/tmio.h                           |  5 ++
 7 files changed, 63 insertions(+), 42 deletions(-)

-- 
2.1.4

[PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Wolfram Sang]

So, here is the series to enable basic SD support on r8a7795; no DMA and UHS-I
for now. Will be added incrementally. It turns out that the driver needs a
little love, so some refactoring is also in place before adding the actual
support.

eMMC works in 4-bit mode, too. 8-bit mode sadly fails currently. I'll post MMC
support patches once this issue is fixed.

These patches have been tested on Gen3 (Salvator-X) and Gen2 (Lager), doing
basic operations with SD cards and running the mmc_test driver (its results
point out some potential corner cases to check later).

A branch can be found here (including clock and DTS patches):

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdhi

Changes since RFC (only sent to sh-devel lists):

* patches 1,7,8 are new
* patch 4 drops 10ms wait also for set_clock
* patch 9 also sets MMC_CAP_WAIT_WHILE_BUSY (see comment there)
* some commit message rewording

Please test, comment, apply...

Thanks,

   Wolfram


Shinobu Uehara (1):
  mmc: sdhi: Add EXT_ACC register busy check

Wolfram Sang (8):
  mmc: tmio_dma: remove debug messages with little information
  mmc: sdhi: error message on ENOMEM is superfluous
  mmc: tmio: add flag to reduce delay after changing clock status
  mmc: tmio: remove stale comments
  mmc: sdhi: use faster clock handling on RCar Gen2
  mmc: tmio: refactor set_clock a little
  mmc: tmio: disable clock before changing it
  mmc: sdhi: Add r8a7795 support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/Kconfig                           |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c                  | 54 +++++++++++++++-------
 drivers/mmc/host/tmio_mmc_dma.c                    | 12 -----
 drivers/mmc/host/tmio_mmc_pio.c                    | 27 ++++++-----
 include/linux/mfd/tmio.h                           |  4 ++
 include/linux/mmc/tmio.h                           |  5 ++
 7 files changed, 63 insertions(+), 42 deletions(-)

-- 
2.1.4

[PATCH 1/9] mmc: tmio_dma: remove debug messages with little information

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

When compiling the driver with CONFIG_MMC_DEBUG set, I get:

=drivers/mmc/host/tmio_mmc_dma.c: In function 'tmio_mmc_start_dma':
include/linux/device.h:1186:2: warning: 'cookie' may be used uninitialized in this function [-Wmaybe-uninitialized]
...

drivers/mmc/host/tmio_mmc_dma.c:52:15: note: 'cookie' was declared here
  dma_cookie_t cookie;
...

drivers/mmc/host/tmio_mmc_dma.c:128:15: note: 'cookie' was declared here
  dma_cookie_t cookie;
=
Because these debug messages look random anyhow (some duplicate
information printed etc), let's just drop them and rather re-add
something consistent if that should ever be needed.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_dma.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index e4b05dbb9ca822..67543587382312 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -95,9 +95,6 @@ static void tmio_mmc_start_dma_rx(struct tmio_mmc_host *host)
 			ret = cookie;
 		}
 	}
-	dev_dbg(&host->pdev->dev, "%s(): mapped %d -> %d, cookie %d, rq %p\n",
-		__func__, host->sg_len, ret, cookie, host->mrq);
-
 pio:
 	if (!desc) {
 		/* DMA failed, fall back to PIO */
@@ -115,9 +112,6 @@ pio:
 		dev_warn(&host->pdev->dev,
 			 "DMA failed: %d, falling back to PIO\n", ret);
 	}
-
-	dev_dbg(&host->pdev->dev, "%s(): desc %p, cookie %d, sg[%d]\n", __func__,
-		desc, cookie, host->sg_len);
 }
 
 static void tmio_mmc_start_dma_tx(struct tmio_mmc_host *host)
@@ -175,9 +169,6 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host *host)
 			ret = cookie;
 		}
 	}
-	dev_dbg(&host->pdev->dev, "%s(): mapped %d -> %d, cookie %d, rq %p\n",
-		__func__, host->sg_len, ret, cookie, host->mrq);
-
 pio:
 	if (!desc) {
 		/* DMA failed, fall back to PIO */
@@ -195,9 +186,6 @@ pio:
 		dev_warn(&host->pdev->dev,
 			 "DMA failed: %d, falling back to PIO\n", ret);
 	}
-
-	dev_dbg(&host->pdev->dev, "%s(): desc %p, cookie %d\n", __func__,
-		desc, cookie);
 }
 
 void tmio_mmc_start_dma(struct tmio_mmc_host *host,
-- 
2.1.4

[PATCH 1/9] mmc: tmio_dma: remove debug messages with little information

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

When compiling the driver with CONFIG_MMC_DEBUG set, I get:

===
drivers/mmc/host/tmio_mmc_dma.c: In function 'tmio_mmc_start_dma':
include/linux/device.h:1186:2: warning: 'cookie' may be used uninitialized in this function [-Wmaybe-uninitialized]
...

drivers/mmc/host/tmio_mmc_dma.c:52:15: note: 'cookie' was declared here
  dma_cookie_t cookie;
...

drivers/mmc/host/tmio_mmc_dma.c:128:15: note: 'cookie' was declared here
  dma_cookie_t cookie;
===

Because these debug messages look random anyhow (some duplicate
information printed etc), let's just drop them and rather re-add
something consistent if that should ever be needed.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_dma.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index e4b05dbb9ca822..67543587382312 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -95,9 +95,6 @@ static void tmio_mmc_start_dma_rx(struct tmio_mmc_host *host)
 			ret = cookie;
 		}
 	}
-	dev_dbg(&host->pdev->dev, "%s(): mapped %d -> %d, cookie %d, rq %p\n",
-		__func__, host->sg_len, ret, cookie, host->mrq);
-
 pio:
 	if (!desc) {
 		/* DMA failed, fall back to PIO */
@@ -115,9 +112,6 @@ pio:
 		dev_warn(&host->pdev->dev,
 			 "DMA failed: %d, falling back to PIO\n", ret);
 	}
-
-	dev_dbg(&host->pdev->dev, "%s(): desc %p, cookie %d, sg[%d]\n", __func__,
-		desc, cookie, host->sg_len);
 }
 
 static void tmio_mmc_start_dma_tx(struct tmio_mmc_host *host)
@@ -175,9 +169,6 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host *host)
 			ret = cookie;
 		}
 	}
-	dev_dbg(&host->pdev->dev, "%s(): mapped %d -> %d, cookie %d, rq %p\n",
-		__func__, host->sg_len, ret, cookie, host->mrq);
-
 pio:
 	if (!desc) {
 		/* DMA failed, fall back to PIO */
@@ -195,9 +186,6 @@ pio:
 		dev_warn(&host->pdev->dev,
 			 "DMA failed: %d, falling back to PIO\n", ret);
 	}
-
-	dev_dbg(&host->pdev->dev, "%s(): desc %p, cookie %d\n", __func__,
-		desc, cookie);
 }
 
 void tmio_mmc_start_dma(struct tmio_mmc_host *host,
-- 
2.1.4

[PATCH 2/9] mmc: sdhi: Add EXT_ACC register busy check

[Wolfram Sang]

From: Shinobu Uehara <shinobu.uehara.xc@renesas.com>

All the docs I have access to say that this register needs the bus busy
check.

Signed-off-by: Shinobu Uehara <shinobu.uehara.xc@renesas.com>
Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 354f4f335ed57a..61671f3fa09a11 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -163,6 +163,7 @@ static int sh_mobile_sdhi_write16_hook(struct tmio_mmc_host *host, int addr)
 	case CTL_SD_MEM_CARD_OPT:
 	case CTL_TRANSACTION_CTL:
 	case CTL_DMA_ENABLE:
+	case EXT_ACC:
 		return sh_mobile_sdhi_wait_idle(host);
 	}
 
-- 
2.1.4

[PATCH 2/9] mmc: sdhi: Add EXT_ACC register busy check

[Wolfram Sang]

From: Shinobu Uehara <shinobu.uehara.xc@renesas.com>

All the docs I have access to say that this register needs the bus busy
check.

Signed-off-by: Shinobu Uehara <shinobu.uehara.xc@renesas.com>
Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 354f4f335ed57a..61671f3fa09a11 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -163,6 +163,7 @@ static int sh_mobile_sdhi_write16_hook(struct tmio_mmc_host *host, int addr)
 	case CTL_SD_MEM_CARD_OPT:
 	case CTL_TRANSACTION_CTL:
 	case CTL_DMA_ENABLE:
+	case EXT_ACC:
 		return sh_mobile_sdhi_wait_idle(host);
 	}
 
-- 
2.1.4

[PATCH 3/9] mmc: sdhi: error message on ENOMEM is superfluous

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

We will get a full dump anyhow.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 61671f3fa09a11..5a10fb3c01a1dd 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -214,10 +214,8 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		return -EINVAL;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(struct sh_mobile_sdhi), GFP_KERNEL);
-	if (priv = NULL) {
-		dev_err(&pdev->dev, "kzalloc failed\n");
+	if (!priv)
 		return -ENOMEM;
-	}
 
 	mmc_data = &priv->mmc_data;
 	dma_priv = &priv->dma_priv;
-- 
2.1.4

[PATCH 3/9] mmc: sdhi: error message on ENOMEM is superfluous

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

We will get a full dump anyhow.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 61671f3fa09a11..5a10fb3c01a1dd 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -214,10 +214,8 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		return -EINVAL;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(struct sh_mobile_sdhi), GFP_KERNEL);
-	if (priv == NULL) {
-		dev_err(&pdev->dev, "kzalloc failed\n");
+	if (!priv)
 		return -ENOMEM;
-	}
 
 	mmc_data = &priv->mmc_data;
 	dma_priv = &priv->dma_priv;
-- 
2.1.4

[PATCH 4/9] mmc: tmio: add flag to reduce delay after changing clock status

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

The docs for RCar Gen2 & 3 I have access to, mention delays of 5ms after
stop and 1ms after start. Make it possible to apply these values.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 7 ++++---
 include/linux/mfd/tmio.h        | 4 ++++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index a10fde40b6c3dd..ffff687e98b1e3 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -172,7 +172,8 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 		host->set_clk_div(host->pdev, (clk>>22) & 1);
 
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & 0x1ff);
-	msleep(10);
+	if (!(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG))
+		msleep(10);
 }
 
 static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
@@ -185,14 +186,14 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~0x0100 &
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
-	msleep(10);
+	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 5 : 10);
 }
 
 static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
 {
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, 0x0100 |
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
-	msleep(10);
+	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 1 : 10);
 
 	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 24b86d538e8852..05d58ee5e6a78f 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -65,6 +65,10 @@
  * Some controllers can support SDIO IRQ signalling.
  */
 #define TMIO_MMC_SDIO_IRQ		(1 << 2)
+
+/* Some controllers don't need to wait 10ms for clock changes */
+#define TMIO_MMC_FAST_CLK_CHG		(1 << 3)
+
 /*
  * Some controllers require waiting for the SD bus to become
  * idle before writing to some registers.
-- 
2.1.4

[PATCH 4/9] mmc: tmio: add flag to reduce delay after changing clock status

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

The docs for RCar Gen2 & 3 I have access to, mention delays of 5ms after
stop and 1ms after start. Make it possible to apply these values.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 7 ++++---
 include/linux/mfd/tmio.h        | 4 ++++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index a10fde40b6c3dd..ffff687e98b1e3 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -172,7 +172,8 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 		host->set_clk_div(host->pdev, (clk>>22) & 1);
 
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & 0x1ff);
-	msleep(10);
+	if (!(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG))
+		msleep(10);
 }
 
 static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
@@ -185,14 +186,14 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~0x0100 &
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
-	msleep(10);
+	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 5 : 10);
 }
 
 static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
 {
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, 0x0100 |
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
-	msleep(10);
+	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 1 : 10);
 
 	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 24b86d538e8852..05d58ee5e6a78f 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -65,6 +65,10 @@
  * Some controllers can support SDIO IRQ signalling.
  */
 #define TMIO_MMC_SDIO_IRQ		(1 << 2)
+
+/* Some controllers don't need to wait 10ms for clock changes */
+#define TMIO_MMC_FAST_CLK_CHG		(1 << 3)
+
 /*
  * Some controllers require waiting for the SD bus to become
  * idle before writing to some registers.
-- 
2.1.4

[PATCH 5/9] mmc: tmio: remove stale comments

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

These don't make sense anymore. Since commit 5d60e500541ed1 ("mmc: tmio:
add new TMIO_MMC_HAVE_HIGH_REG flags"), we don't deal with a resource
here.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index ffff687e98b1e3..207e77a09cda51 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -178,7 +178,6 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 
 static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 {
-	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
 		sd_ctrl_write16(host, CTL_CLK_AND_WAIT_CTL, 0x0000);
 		msleep(10);
@@ -195,7 +194,6 @@ static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 1 : 10);
 
-	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
 		sd_ctrl_write16(host, CTL_CLK_AND_WAIT_CTL, 0x0100);
 		msleep(10);
@@ -206,7 +204,6 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
 {
 	/* FIXME - should we set stop clock reg here */
 	sd_ctrl_write16(host, CTL_RESET_SD, 0x0000);
-	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
 		sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0000);
 	msleep(10);
-- 
2.1.4

[PATCH 5/9] mmc: tmio: remove stale comments

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

These don't make sense anymore. Since commit 5d60e500541ed1 ("mmc: tmio:
add new TMIO_MMC_HAVE_HIGH_REG flags"), we don't deal with a resource
here.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index ffff687e98b1e3..207e77a09cda51 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -178,7 +178,6 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 
 static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 {
-	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
 		sd_ctrl_write16(host, CTL_CLK_AND_WAIT_CTL, 0x0000);
 		msleep(10);
@@ -195,7 +194,6 @@ static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 1 : 10);
 
-	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
 		sd_ctrl_write16(host, CTL_CLK_AND_WAIT_CTL, 0x0100);
 		msleep(10);
@@ -206,7 +204,6 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
 {
 	/* FIXME - should we set stop clock reg here */
 	sd_ctrl_write16(host, CTL_RESET_SD, 0x0000);
-	/* implicit BUG_ON(!res) */
 	if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
 		sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0000);
 	msleep(10);
-- 
2.1.4

[PATCH 6/9] mmc: sdhi: use faster clock handling on RCar Gen2

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 5a10fb3c01a1dd..557e2b9dadeec7 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -59,7 +59,7 @@ static const struct sh_mobile_sdhi_of_data of_rcar_gen1_compatible = {
 
 static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
 	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
-			  TMIO_MMC_CLK_ACTUAL,
+			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
 	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
 	.dma_buswidth	= DMA_SLAVE_BUSWIDTH_4_BYTES,
 	.dma_rx_offset	= 0x2000,
-- 
2.1.4

[PATCH 6/9] mmc: sdhi: use faster clock handling on RCar Gen2

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 5a10fb3c01a1dd..557e2b9dadeec7 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -59,7 +59,7 @@ static const struct sh_mobile_sdhi_of_data of_rcar_gen1_compatible = {
 
 static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
 	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
-			  TMIO_MMC_CLK_ACTUAL,
+			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
 	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
 	.dma_buswidth	= DMA_SLAVE_BUSWIDTH_4_BYTES,
 	.dma_rx_offset	= 0x2000,
-- 
2.1.4

[PATCH 7/9] mmc: tmio: refactor set_clock a little

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Some of the indentation made the code awful to read. Fix that. Also,
introduce defines instead of magic hex values. Note that this includes
one change: We mask out know 0xff instead of 0x1ff. But 0x100 has always
been the clock enable bit. It doesn't make any sense to set it depending
on the clock calculation. Update copyright notices, too. I'll be working
on those files some more in the future.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

copy
---
 drivers/mmc/host/tmio_mmc_pio.c | 15 +++++++++------
 include/linux/mmc/tmio.h        |  5 +++++
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 207e77a09cda51..7f6b5adf12094b 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1,6 +1,8 @@
 /*
  * linux/drivers/mmc/host/tmio_mmc_pio.c
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2011 Guennadi Liakhovetski
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
@@ -159,19 +161,20 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 
 	if (new_clock) {
 		for (clock = host->mmc->f_min, clk = 0x80000080;
-			new_clock >= (clock<<1); clk >>= 1)
+		     new_clock >= (clock << 1);
+		     clk >>= 1)
 			clock <<= 1;
 
 		/* 1/1 clock is option */
 		if ((host->pdata->flags & TMIO_MMC_CLK_ACTUAL) &&
-		    ((clk >> 22) & 0x1))
+		   ((clk >> 22) & 0x1))
 			clk |= 0xff;
 	}
 
 	if (host->set_clk_div)
-		host->set_clk_div(host->pdev, (clk>>22) & 1);
+		host->set_clk_div(host->pdev, (clk >> 22) & 1);
 
-	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & 0x1ff);
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & CLK_CTL_DIV_MASK);
 	if (!(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG))
 		msleep(10);
 }
@@ -183,14 +186,14 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 		msleep(10);
 	}
 
-	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~0x0100 &
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 5 : 10);
 }
 
 static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
 {
-	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, 0x0100 |
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 1 : 10);
 
diff --git a/include/linux/mmc/tmio.h b/include/linux/mmc/tmio.h
index 84d9053b5dca3e..5f5cd80e976500 100644
--- a/include/linux/mmc/tmio.h
+++ b/include/linux/mmc/tmio.h
@@ -1,6 +1,8 @@
 /*
  * include/linux/mmc/tmio.h
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
  *
@@ -61,6 +63,9 @@
 #define TMIO_STAT_CMD_BUSY      0x40000000
 #define TMIO_STAT_ILL_ACCESS    0x80000000
 
+#define	CLK_CTL_DIV_MASK	0xff
+#define	CLK_CTL_SCLKEN		BIT(8)
+
 #define TMIO_BBS		512		/* Boot block size */
 
 #endif /* LINUX_MMC_TMIO_H */
-- 
2.1.4

[PATCH 7/9] mmc: tmio: refactor set_clock a little

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Some of the indentation made the code awful to read. Fix that. Also,
introduce defines instead of magic hex values. Note that this includes
one change: We mask out know 0xff instead of 0x1ff. But 0x100 has always
been the clock enable bit. It doesn't make any sense to set it depending
on the clock calculation. Update copyright notices, too. I'll be working
on those files some more in the future.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

copy
---
 drivers/mmc/host/tmio_mmc_pio.c | 15 +++++++++------
 include/linux/mmc/tmio.h        |  5 +++++
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 207e77a09cda51..7f6b5adf12094b 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1,6 +1,8 @@
 /*
  * linux/drivers/mmc/host/tmio_mmc_pio.c
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2011 Guennadi Liakhovetski
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
@@ -159,19 +161,20 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 
 	if (new_clock) {
 		for (clock = host->mmc->f_min, clk = 0x80000080;
-			new_clock >= (clock<<1); clk >>= 1)
+		     new_clock >= (clock << 1);
+		     clk >>= 1)
 			clock <<= 1;
 
 		/* 1/1 clock is option */
 		if ((host->pdata->flags & TMIO_MMC_CLK_ACTUAL) &&
-		    ((clk >> 22) & 0x1))
+		   ((clk >> 22) & 0x1))
 			clk |= 0xff;
 	}
 
 	if (host->set_clk_div)
-		host->set_clk_div(host->pdev, (clk>>22) & 1);
+		host->set_clk_div(host->pdev, (clk >> 22) & 1);
 
-	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & 0x1ff);
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & CLK_CTL_DIV_MASK);
 	if (!(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG))
 		msleep(10);
 }
@@ -183,14 +186,14 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 		msleep(10);
 	}
 
-	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~0x0100 &
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 5 : 10);
 }
 
 static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
 {
-	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, 0x0100 |
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
 		sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	msleep(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG ? 1 : 10);
 
diff --git a/include/linux/mmc/tmio.h b/include/linux/mmc/tmio.h
index 84d9053b5dca3e..5f5cd80e976500 100644
--- a/include/linux/mmc/tmio.h
+++ b/include/linux/mmc/tmio.h
@@ -1,6 +1,8 @@
 /*
  * include/linux/mmc/tmio.h
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2007 Ian Molton
  * Copyright (C) 2004 Ian Molton
  *
@@ -61,6 +63,9 @@
 #define TMIO_STAT_CMD_BUSY      0x40000000
 #define TMIO_STAT_ILL_ACCESS    0x80000000
 
+#define	CLK_CTL_DIV_MASK	0xff
+#define	CLK_CTL_SCLKEN		BIT(8)
+
 #define TMIO_BBS		512		/* Boot block size */
 
 #endif /* LINUX_MMC_TMIO_H */
-- 
2.1.4

[PATCH 8/9] mmc: tmio: disable clock before changing it

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Rcar2 & 3 docs state that for going to and coming from the 0xff setting,
the clock must first be disabled before the DIV bits are changed.
Instead of tracking this, let's just do this unconditionally.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 7f6b5adf12094b..03f6e74c190691 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -174,6 +174,8 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 	if (host->set_clk_div)
 		host->set_clk_div(host->pdev, (clk >> 22) & 1);
 
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
+			sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & CLK_CTL_DIV_MASK);
 	if (!(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG))
 		msleep(10);
-- 
2.1.4

[PATCH 8/9] mmc: tmio: disable clock before changing it

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Rcar2 & 3 docs state that for going to and coming from the 0xff setting,
the clock must first be disabled before the DIV bits are changed.
Instead of tracking this, let's just do this unconditionally.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 7f6b5adf12094b..03f6e74c190691 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -174,6 +174,8 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 	if (host->set_clk_div)
 		host->set_clk_div(host->pdev, (clk >> 22) & 1);
 
+	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
+			sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 	sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & CLK_CTL_DIV_MASK);
 	if (!(host->pdata->flags & TMIO_MMC_FAST_CLK_CHG))
 		msleep(10);
-- 
2.1.4

[PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Registers are 64bit apart, so we refactor bus_shift handling a little
and set it based on the DT compatible. Also, EXT_ACC is different.

Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

@MMC maintainers: I set the MMC_CAP_WAIT_WHILE_BUSY flage here and it is needed
to probe the eMMC (implementing RSP_R1 without CRC would also work). However, I
can't find an explicit statement in the documentation saying that it really
waits when the bus is busy. Is my "it works, let's use it" approach enough, or
is there more I can do to verify that setting MMC_CAP_WAIT_WHILE_BUSY is valid
for this hardware?

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/Kconfig                           |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c                  | 47 ++++++++++++++++------
 3 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 400b640fabc768..7fb746dd1a68ca 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -22,6 +22,7 @@ Required properties:
 		"renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
 		"renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
 		"renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
+		"renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
 
 Optional properties:
 - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1526b8a10b094e..dd1499bd218b16 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -560,7 +560,7 @@ config MMC_TMIO
 
 config MMC_SDHI
 	tristate "SH-Mobile SDHI SD/SDIO controller support"
-	depends on SUPERH || ARM
+	depends on SUPERH || ARM || ARM64
 	depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
 	select MMC_TMIO_CORE
 	help
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 557e2b9dadeec7..f7eff5f53e0013 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -1,6 +1,8 @@
 /*
  * SuperH Mobile SDHI
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2009 Magnus Damm
  *
  * This program is free software; you can redistribute it and/or modify
@@ -43,6 +45,7 @@ struct sh_mobile_sdhi_of_data {
 	unsigned long capabilities2;
 	enum dma_slave_buswidth dma_buswidth;
 	dma_addr_t dma_rx_offset;
+	unsigned bus_shift;
 };
 
 static const struct sh_mobile_sdhi_of_data sh_mobile_sdhi_of_cfg[] = {
@@ -65,6 +68,13 @@ static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
 	.dma_rx_offset	= 0x2000,
 };
 
+static const struct sh_mobile_sdhi_of_data of_rcar_gen3_compatible = {
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
+			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
+	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY,
+	.bus_shift	= 2,
+};
+
 static const struct of_device_id sh_mobile_sdhi_of_match[] = {
 	{ .compatible = "renesas,sdhi-shmobile" },
 	{ .compatible = "renesas,sdhi-sh7372" },
@@ -78,6 +88,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
 	{ .compatible = "renesas,sdhi-r8a7792", .data = &of_rcar_gen2_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7793", .data = &of_rcar_gen2_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7794", .data = &of_rcar_gen2_compatible, },
+	{ .compatible = "renesas,sdhi-r8a7795", .data = &of_rcar_gen3_compatible, },
 	{},
 };
 MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
@@ -103,6 +114,15 @@ static void sh_mobile_sdhi_sdbuf_width(struct tmio_mmc_host *host, int width)
 	case 0xCB0D:
 		val = (width = 32) ? 0x0000 : 0x0001;
 		break;
+	case 0xCC10: /* Gen3, SD only */
+	case 0xCD10: /* Gen3, SD + MMC */
+		if (width = 64)
+			val = 0x0000;
+		else if (width = 32)
+			val = 0x0101;
+		else
+			val = 0x0001;
+		break;
 	default:
 		/* nothing to do */
 		return;
@@ -233,16 +253,26 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		goto eprobe;
 	}
 
+	if (of_id && of_id->data) {
+		const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
+
+		mmc_data->flags |= of_data->tmio_flags;
+		mmc_data->capabilities |= of_data->capabilities;
+		mmc_data->capabilities2 |= of_data->capabilities2;
+		mmc_data->dma_rx_offset = of_data->dma_rx_offset;
+		dma_priv->dma_buswidth = of_data->dma_buswidth;
+		host->bus_shift = of_data->bus_shift;
+	}
+
 	host->dma		= dma_priv;
 	host->write16_hook	= sh_mobile_sdhi_write16_hook;
 	host->clk_enable	= sh_mobile_sdhi_clk_enable;
 	host->clk_disable	= sh_mobile_sdhi_clk_disable;
 	host->multi_io_quirk	= sh_mobile_sdhi_multi_io_quirk;
-	/* SD control register space size is 0x100, 0x200 for bus_shift=1 */
-	if (resource_size(res) > 0x100)
+
+	/* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
+	if (!host->bus_shift && resource_size(res) > 0x100) /* old way to determine the shift */
 		host->bus_shift = 1;
-	else
-		host->bus_shift = 0;
 
 	if (mmd)
 		*mmc_data = *mmd;
@@ -274,15 +304,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 	 */
 	mmc_data->flags |= TMIO_MMC_SDIO_STATUS_QUIRK;
 
-	if (of_id && of_id->data) {
-		const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
-		mmc_data->flags |= of_data->tmio_flags;
-		mmc_data->capabilities |= of_data->capabilities;
-		mmc_data->capabilities2 |= of_data->capabilities2;
-		mmc_data->dma_rx_offset = of_data->dma_rx_offset;
-		dma_priv->dma_buswidth = of_data->dma_buswidth;
-	}
-
 	ret = tmio_mmc_host_probe(host, mmc_data);
 	if (ret < 0)
 		goto efree;
-- 
2.1.4

[PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

Registers are 64bit apart, so we refactor bus_shift handling a little
and set it based on the DT compatible. Also, EXT_ACC is different.

Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

@MMC maintainers: I set the MMC_CAP_WAIT_WHILE_BUSY flage here and it is needed
to probe the eMMC (implementing RSP_R1 without CRC would also work). However, I
can't find an explicit statement in the documentation saying that it really
waits when the bus is busy. Is my "it works, let's use it" approach enough, or
is there more I can do to verify that setting MMC_CAP_WAIT_WHILE_BUSY is valid
for this hardware?

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/Kconfig                           |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c                  | 47 ++++++++++++++++------
 3 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 400b640fabc768..7fb746dd1a68ca 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -22,6 +22,7 @@ Required properties:
 		"renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
 		"renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
 		"renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
+		"renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
 
 Optional properties:
 - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1526b8a10b094e..dd1499bd218b16 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -560,7 +560,7 @@ config MMC_TMIO
 
 config MMC_SDHI
 	tristate "SH-Mobile SDHI SD/SDIO controller support"
-	depends on SUPERH || ARM
+	depends on SUPERH || ARM || ARM64
 	depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
 	select MMC_TMIO_CORE
 	help
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 557e2b9dadeec7..f7eff5f53e0013 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -1,6 +1,8 @@
 /*
  * SuperH Mobile SDHI
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2009 Magnus Damm
  *
  * This program is free software; you can redistribute it and/or modify
@@ -43,6 +45,7 @@ struct sh_mobile_sdhi_of_data {
 	unsigned long capabilities2;
 	enum dma_slave_buswidth dma_buswidth;
 	dma_addr_t dma_rx_offset;
+	unsigned bus_shift;
 };
 
 static const struct sh_mobile_sdhi_of_data sh_mobile_sdhi_of_cfg[] = {
@@ -65,6 +68,13 @@ static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
 	.dma_rx_offset	= 0x2000,
 };
 
+static const struct sh_mobile_sdhi_of_data of_rcar_gen3_compatible = {
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
+			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
+	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY,
+	.bus_shift	= 2,
+};
+
 static const struct of_device_id sh_mobile_sdhi_of_match[] = {
 	{ .compatible = "renesas,sdhi-shmobile" },
 	{ .compatible = "renesas,sdhi-sh7372" },
@@ -78,6 +88,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
 	{ .compatible = "renesas,sdhi-r8a7792", .data = &of_rcar_gen2_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7793", .data = &of_rcar_gen2_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7794", .data = &of_rcar_gen2_compatible, },
+	{ .compatible = "renesas,sdhi-r8a7795", .data = &of_rcar_gen3_compatible, },
 	{},
 };
 MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
@@ -103,6 +114,15 @@ static void sh_mobile_sdhi_sdbuf_width(struct tmio_mmc_host *host, int width)
 	case 0xCB0D:
 		val = (width == 32) ? 0x0000 : 0x0001;
 		break;
+	case 0xCC10: /* Gen3, SD only */
+	case 0xCD10: /* Gen3, SD + MMC */
+		if (width == 64)
+			val = 0x0000;
+		else if (width == 32)
+			val = 0x0101;
+		else
+			val = 0x0001;
+		break;
 	default:
 		/* nothing to do */
 		return;
@@ -233,16 +253,26 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		goto eprobe;
 	}
 
+	if (of_id && of_id->data) {
+		const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
+
+		mmc_data->flags |= of_data->tmio_flags;
+		mmc_data->capabilities |= of_data->capabilities;
+		mmc_data->capabilities2 |= of_data->capabilities2;
+		mmc_data->dma_rx_offset = of_data->dma_rx_offset;
+		dma_priv->dma_buswidth = of_data->dma_buswidth;
+		host->bus_shift = of_data->bus_shift;
+	}
+
 	host->dma		= dma_priv;
 	host->write16_hook	= sh_mobile_sdhi_write16_hook;
 	host->clk_enable	= sh_mobile_sdhi_clk_enable;
 	host->clk_disable	= sh_mobile_sdhi_clk_disable;
 	host->multi_io_quirk	= sh_mobile_sdhi_multi_io_quirk;
-	/* SD control register space size is 0x100, 0x200 for bus_shift=1 */
-	if (resource_size(res) > 0x100)
+
+	/* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
+	if (!host->bus_shift && resource_size(res) > 0x100) /* old way to determine the shift */
 		host->bus_shift = 1;
-	else
-		host->bus_shift = 0;
 
 	if (mmd)
 		*mmc_data = *mmd;
@@ -274,15 +304,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 	 */
 	mmc_data->flags |= TMIO_MMC_SDIO_STATUS_QUIRK;
 
-	if (of_id && of_id->data) {
-		const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
-		mmc_data->flags |= of_data->tmio_flags;
-		mmc_data->capabilities |= of_data->capabilities;
-		mmc_data->capabilities2 |= of_data->capabilities2;
-		mmc_data->dma_rx_offset = of_data->dma_rx_offset;
-		dma_priv->dma_buswidth = of_data->dma_buswidth;
-	}
-
 	ret = tmio_mmc_host_probe(host, mmc_data);
 	if (ret < 0)
 		goto efree;
-- 
2.1.4

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 25 January 2016 at 20:15, Wolfram Sang <wsa@the-dreams.de> wrote:
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Registers are 64bit apart, so we refactor bus_shift handling a little
> and set it based on the DT compatible. Also, EXT_ACC is different.
>
> Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> @MMC maintainers: I set the MMC_CAP_WAIT_WHILE_BUSY flage here and it is needed
> to probe the eMMC (implementing RSP_R1 without CRC would also work). However, I
> can't find an explicit statement in the documentation saying that it really
> waits when the bus is busy. Is my "it works, let's use it" approach enough, or
> is there more I can do to verify that setting MMC_CAP_WAIT_WHILE_BUSY is valid
> for this hardware?

In general from the mmc core perspective, when a host announces
MMC_CAP_WAIT_WHILE_BUSY it won't send a CMD13 to poll for busy.

I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check
that a following CMD13 command always states that the card isn't busy.
I think the best path to try this is when sending a big write data
request, as in that case you can be quite certain that the card gets
busy between the requests.

So somewhere in the mmc block layer add some debug prints, that should do it.

Kind regards
Uffe

>
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
>  drivers/mmc/host/Kconfig                           |  2 +-
>  drivers/mmc/host/sh_mobile_sdhi.c                  | 47 ++++++++++++++++------
>  3 files changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 400b640fabc768..7fb746dd1a68ca 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -22,6 +22,7 @@ Required properties:
>                 "renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
>                 "renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
>                 "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
> +               "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
>
>  Optional properties:
>  - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1526b8a10b094e..dd1499bd218b16 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -560,7 +560,7 @@ config MMC_TMIO
>
>  config MMC_SDHI
>         tristate "SH-Mobile SDHI SD/SDIO controller support"
> -       depends on SUPERH || ARM
> +       depends on SUPERH || ARM || ARM64
>         depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>         select MMC_TMIO_CORE
>         help
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
> index 557e2b9dadeec7..f7eff5f53e0013 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -1,6 +1,8 @@
>  /*
>   * SuperH Mobile SDHI
>   *
> + * Copyright (C) 2016 Sang Engineering, Wolfram Sang
> + * Copyright (C) 2015-16 Renesas Electronics Corporation
>   * Copyright (C) 2009 Magnus Damm
>   *
>   * This program is free software; you can redistribute it and/or modify
> @@ -43,6 +45,7 @@ struct sh_mobile_sdhi_of_data {
>         unsigned long capabilities2;
>         enum dma_slave_buswidth dma_buswidth;
>         dma_addr_t dma_rx_offset;
> +       unsigned bus_shift;
>  };
>
>  static const struct sh_mobile_sdhi_of_data sh_mobile_sdhi_of_cfg[] = {
> @@ -65,6 +68,13 @@ static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
>         .dma_rx_offset  = 0x2000,
>  };
>
> +static const struct sh_mobile_sdhi_of_data of_rcar_gen3_compatible = {
> +       .tmio_flags     = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
> +                         TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
> +       .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY,
> +       .bus_shift      = 2,
> +};
> +
>  static const struct of_device_id sh_mobile_sdhi_of_match[] = {
>         { .compatible = "renesas,sdhi-shmobile" },
>         { .compatible = "renesas,sdhi-sh7372" },
> @@ -78,6 +88,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
>         { .compatible = "renesas,sdhi-r8a7792", .data = &of_rcar_gen2_compatible, },
>         { .compatible = "renesas,sdhi-r8a7793", .data = &of_rcar_gen2_compatible, },
>         { .compatible = "renesas,sdhi-r8a7794", .data = &of_rcar_gen2_compatible, },
> +       { .compatible = "renesas,sdhi-r8a7795", .data = &of_rcar_gen3_compatible, },
>         {},
>  };
>  MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
> @@ -103,6 +114,15 @@ static void sh_mobile_sdhi_sdbuf_width(struct tmio_mmc_host *host, int width)
>         case 0xCB0D:
>                 val = (width = 32) ? 0x0000 : 0x0001;
>                 break;
> +       case 0xCC10: /* Gen3, SD only */
> +       case 0xCD10: /* Gen3, SD + MMC */
> +               if (width = 64)
> +                       val = 0x0000;
> +               else if (width = 32)
> +                       val = 0x0101;
> +               else
> +                       val = 0x0001;
> +               break;
>         default:
>                 /* nothing to do */
>                 return;
> @@ -233,16 +253,26 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
>                 goto eprobe;
>         }
>
> +       if (of_id && of_id->data) {
> +               const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
> +
> +               mmc_data->flags |= of_data->tmio_flags;
> +               mmc_data->capabilities |= of_data->capabilities;
> +               mmc_data->capabilities2 |= of_data->capabilities2;
> +               mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> +               dma_priv->dma_buswidth = of_data->dma_buswidth;
> +               host->bus_shift = of_data->bus_shift;
> +       }
> +
>         host->dma               = dma_priv;
>         host->write16_hook      = sh_mobile_sdhi_write16_hook;
>         host->clk_enable        = sh_mobile_sdhi_clk_enable;
>         host->clk_disable       = sh_mobile_sdhi_clk_disable;
>         host->multi_io_quirk    = sh_mobile_sdhi_multi_io_quirk;
> -       /* SD control register space size is 0x100, 0x200 for bus_shift=1 */
> -       if (resource_size(res) > 0x100)
> +
> +       /* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
> +       if (!host->bus_shift && resource_size(res) > 0x100) /* old way to determine the shift */
>                 host->bus_shift = 1;
> -       else
> -               host->bus_shift = 0;
>
>         if (mmd)
>                 *mmc_data = *mmd;
> @@ -274,15 +304,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
>          */
>         mmc_data->flags |= TMIO_MMC_SDIO_STATUS_QUIRK;
>
> -       if (of_id && of_id->data) {
> -               const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
> -               mmc_data->flags |= of_data->tmio_flags;
> -               mmc_data->capabilities |= of_data->capabilities;
> -               mmc_data->capabilities2 |= of_data->capabilities2;
> -               mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> -               dma_priv->dma_buswidth = of_data->dma_buswidth;
> -       }
> -
>         ret = tmio_mmc_host_probe(host, mmc_data);
>         if (ret < 0)
>                 goto efree;
> --
> 2.1.4
>
> --
> 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 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 25 January 2016 at 20:15, Wolfram Sang <wsa@the-dreams.de> wrote:
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Registers are 64bit apart, so we refactor bus_shift handling a little
> and set it based on the DT compatible. Also, EXT_ACC is different.
>
> Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> @MMC maintainers: I set the MMC_CAP_WAIT_WHILE_BUSY flage here and it is needed
> to probe the eMMC (implementing RSP_R1 without CRC would also work). However, I
> can't find an explicit statement in the documentation saying that it really
> waits when the bus is busy. Is my "it works, let's use it" approach enough, or
> is there more I can do to verify that setting MMC_CAP_WAIT_WHILE_BUSY is valid
> for this hardware?

In general from the mmc core perspective, when a host announces
MMC_CAP_WAIT_WHILE_BUSY it won't send a CMD13 to poll for busy.

I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check
that a following CMD13 command always states that the card isn't busy.
I think the best path to try this is when sending a big write data
request, as in that case you can be quite certain that the card gets
busy between the requests.

So somewhere in the mmc block layer add some debug prints, that should do it.

Kind regards
Uffe

>
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
>  drivers/mmc/host/Kconfig                           |  2 +-
>  drivers/mmc/host/sh_mobile_sdhi.c                  | 47 ++++++++++++++++------
>  3 files changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 400b640fabc768..7fb746dd1a68ca 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -22,6 +22,7 @@ Required properties:
>                 "renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
>                 "renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
>                 "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
> +               "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
>
>  Optional properties:
>  - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1526b8a10b094e..dd1499bd218b16 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -560,7 +560,7 @@ config MMC_TMIO
>
>  config MMC_SDHI
>         tristate "SH-Mobile SDHI SD/SDIO controller support"
> -       depends on SUPERH || ARM
> +       depends on SUPERH || ARM || ARM64
>         depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>         select MMC_TMIO_CORE
>         help
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
> index 557e2b9dadeec7..f7eff5f53e0013 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -1,6 +1,8 @@
>  /*
>   * SuperH Mobile SDHI
>   *
> + * Copyright (C) 2016 Sang Engineering, Wolfram Sang
> + * Copyright (C) 2015-16 Renesas Electronics Corporation
>   * Copyright (C) 2009 Magnus Damm
>   *
>   * This program is free software; you can redistribute it and/or modify
> @@ -43,6 +45,7 @@ struct sh_mobile_sdhi_of_data {
>         unsigned long capabilities2;
>         enum dma_slave_buswidth dma_buswidth;
>         dma_addr_t dma_rx_offset;
> +       unsigned bus_shift;
>  };
>
>  static const struct sh_mobile_sdhi_of_data sh_mobile_sdhi_of_cfg[] = {
> @@ -65,6 +68,13 @@ static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
>         .dma_rx_offset  = 0x2000,
>  };
>
> +static const struct sh_mobile_sdhi_of_data of_rcar_gen3_compatible = {
> +       .tmio_flags     = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
> +                         TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
> +       .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY,
> +       .bus_shift      = 2,
> +};
> +
>  static const struct of_device_id sh_mobile_sdhi_of_match[] = {
>         { .compatible = "renesas,sdhi-shmobile" },
>         { .compatible = "renesas,sdhi-sh7372" },
> @@ -78,6 +88,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
>         { .compatible = "renesas,sdhi-r8a7792", .data = &of_rcar_gen2_compatible, },
>         { .compatible = "renesas,sdhi-r8a7793", .data = &of_rcar_gen2_compatible, },
>         { .compatible = "renesas,sdhi-r8a7794", .data = &of_rcar_gen2_compatible, },
> +       { .compatible = "renesas,sdhi-r8a7795", .data = &of_rcar_gen3_compatible, },
>         {},
>  };
>  MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
> @@ -103,6 +114,15 @@ static void sh_mobile_sdhi_sdbuf_width(struct tmio_mmc_host *host, int width)
>         case 0xCB0D:
>                 val = (width == 32) ? 0x0000 : 0x0001;
>                 break;
> +       case 0xCC10: /* Gen3, SD only */
> +       case 0xCD10: /* Gen3, SD + MMC */
> +               if (width == 64)
> +                       val = 0x0000;
> +               else if (width == 32)
> +                       val = 0x0101;
> +               else
> +                       val = 0x0001;
> +               break;
>         default:
>                 /* nothing to do */
>                 return;
> @@ -233,16 +253,26 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
>                 goto eprobe;
>         }
>
> +       if (of_id && of_id->data) {
> +               const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
> +
> +               mmc_data->flags |= of_data->tmio_flags;
> +               mmc_data->capabilities |= of_data->capabilities;
> +               mmc_data->capabilities2 |= of_data->capabilities2;
> +               mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> +               dma_priv->dma_buswidth = of_data->dma_buswidth;
> +               host->bus_shift = of_data->bus_shift;
> +       }
> +
>         host->dma               = dma_priv;
>         host->write16_hook      = sh_mobile_sdhi_write16_hook;
>         host->clk_enable        = sh_mobile_sdhi_clk_enable;
>         host->clk_disable       = sh_mobile_sdhi_clk_disable;
>         host->multi_io_quirk    = sh_mobile_sdhi_multi_io_quirk;
> -       /* SD control register space size is 0x100, 0x200 for bus_shift=1 */
> -       if (resource_size(res) > 0x100)
> +
> +       /* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
> +       if (!host->bus_shift && resource_size(res) > 0x100) /* old way to determine the shift */
>                 host->bus_shift = 1;
> -       else
> -               host->bus_shift = 0;
>
>         if (mmd)
>                 *mmc_data = *mmd;
> @@ -274,15 +304,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
>          */
>         mmc_data->flags |= TMIO_MMC_SDIO_STATUS_QUIRK;
>
> -       if (of_id && of_id->data) {
> -               const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
> -               mmc_data->flags |= of_data->tmio_flags;
> -               mmc_data->capabilities |= of_data->capabilities;
> -               mmc_data->capabilities2 |= of_data->capabilities2;
> -               mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> -               dma_priv->dma_buswidth = of_data->dma_buswidth;
> -       }
> -
>         ret = tmio_mmc_host_probe(host, mmc_data);
>         if (ret < 0)
>                 goto efree;
> --
> 2.1.4
>
> --
> 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 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Ulf Hansson]

On 25 January 2016 at 20:15, Wolfram Sang <wsa@the-dreams.de> wrote:
> So, here is the series to enable basic SD support on r8a7795; no DMA and UHS-I
> for now. Will be added incrementally. It turns out that the driver needs a
> little love, so some refactoring is also in place before adding the actual
> support.
>
> eMMC works in 4-bit mode, too. 8-bit mode sadly fails currently. I'll post MMC
> support patches once this issue is fixed.
>
> These patches have been tested on Gen3 (Salvator-X) and Gen2 (Lager), doing
> basic operations with SD cards and running the mmc_test driver (its results
> point out some potential corner cases to check later).
>
> A branch can be found here (including clock and DTS patches):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdhi
>
> Changes since RFC (only sent to sh-devel lists):
>
> * patches 1,7,8 are new
> * patch 4 drops 10ms wait also for set_clock
> * patch 9 also sets MMC_CAP_WAIT_WHILE_BUSY (see comment there)
> * some commit message rewording
>
> Please test, comment, apply...
>
> Thanks,
>
>    Wolfram
>
>
> Shinobu Uehara (1):
>   mmc: sdhi: Add EXT_ACC register busy check
>
> Wolfram Sang (8):
>   mmc: tmio_dma: remove debug messages with little information
>   mmc: sdhi: error message on ENOMEM is superfluous
>   mmc: tmio: add flag to reduce delay after changing clock status
>   mmc: tmio: remove stale comments
>   mmc: sdhi: use faster clock handling on RCar Gen2
>   mmc: tmio: refactor set_clock a little
>   mmc: tmio: disable clock before changing it
>   mmc: sdhi: Add r8a7795 support
>
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
>  drivers/mmc/host/Kconfig                           |  2 +-
>  drivers/mmc/host/sh_mobile_sdhi.c                  | 54 +++++++++++++++-------
>  drivers/mmc/host/tmio_mmc_dma.c                    | 12 -----
>  drivers/mmc/host/tmio_mmc_pio.c                    | 27 ++++++-----
>  include/linux/mfd/tmio.h                           |  4 ++
>  include/linux/mmc/tmio.h                           |  5 ++
>  7 files changed, 63 insertions(+), 42 deletions(-)
>
> --
> 2.1.4
>

Patch 1->8 looks good.

Although, I couldn't apply patch1, could you please send a new version
rebased onto my next branch.

Kind regards
Uffe

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Ulf Hansson]

On 25 January 2016 at 20:15, Wolfram Sang <wsa@the-dreams.de> wrote:
> So, here is the series to enable basic SD support on r8a7795; no DMA and UHS-I
> for now. Will be added incrementally. It turns out that the driver needs a
> little love, so some refactoring is also in place before adding the actual
> support.
>
> eMMC works in 4-bit mode, too. 8-bit mode sadly fails currently. I'll post MMC
> support patches once this issue is fixed.
>
> These patches have been tested on Gen3 (Salvator-X) and Gen2 (Lager), doing
> basic operations with SD cards and running the mmc_test driver (its results
> point out some potential corner cases to check later).
>
> A branch can be found here (including clock and DTS patches):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdhi
>
> Changes since RFC (only sent to sh-devel lists):
>
> * patches 1,7,8 are new
> * patch 4 drops 10ms wait also for set_clock
> * patch 9 also sets MMC_CAP_WAIT_WHILE_BUSY (see comment there)
> * some commit message rewording
>
> Please test, comment, apply...
>
> Thanks,
>
>    Wolfram
>
>
> Shinobu Uehara (1):
>   mmc: sdhi: Add EXT_ACC register busy check
>
> Wolfram Sang (8):
>   mmc: tmio_dma: remove debug messages with little information
>   mmc: sdhi: error message on ENOMEM is superfluous
>   mmc: tmio: add flag to reduce delay after changing clock status
>   mmc: tmio: remove stale comments
>   mmc: sdhi: use faster clock handling on RCar Gen2
>   mmc: tmio: refactor set_clock a little
>   mmc: tmio: disable clock before changing it
>   mmc: sdhi: Add r8a7795 support
>
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
>  drivers/mmc/host/Kconfig                           |  2 +-
>  drivers/mmc/host/sh_mobile_sdhi.c                  | 54 +++++++++++++++-------
>  drivers/mmc/host/tmio_mmc_dma.c                    | 12 -----
>  drivers/mmc/host/tmio_mmc_pio.c                    | 27 ++++++-----
>  include/linux/mfd/tmio.h                           |  4 ++
>  include/linux/mmc/tmio.h                           |  5 ++
>  7 files changed, 63 insertions(+), 42 deletions(-)
>
> --
> 2.1.4
>

Patch 1->8 looks good.

Although, I couldn't apply patch1, could you please send a new version
rebased onto my next branch.

Kind regards
Uffe

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Wolfram Sang]

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


> Although, I couldn't apply patch1, could you please send a new version
> rebased onto my next branch.

I rebased to your tree (especially patch 1, rest stayed the same) and
pushed patches 1-8 here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git mmc/sdhi-refactor

Is pulling okay, or do you want me to resend?

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Wolfram Sang]

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


> Although, I couldn't apply patch1, could you please send a new version
> rebased onto my next branch.

I rebased to your tree (especially patch 1, rest stayed the same) and
pushed patches 1-8 here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git mmc/sdhi-refactor

Is pulling okay, or do you want me to resend?

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Ulf Hansson]

On 2 February 2016 at 15:06, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> Although, I couldn't apply patch1, could you please send a new version
>> rebased onto my next branch.
>
> I rebased to your tree (especially patch 1, rest stayed the same) and
> pushed patches 1-8 here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git mmc/sdhi-refactor
>
> Is pulling okay, or do you want me to resend?

This is fine! I have picked them up from your tree and applied them for next!

Do note that I am re-basing my next branch from time to time, so I
assume the branch you shared with me isn't an immutable branch!?

Thanks and kind regards
Uffe

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Ulf Hansson]

On 2 February 2016 at 15:06, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> Although, I couldn't apply patch1, could you please send a new version
>> rebased onto my next branch.
>
> I rebased to your tree (especially patch 1, rest stayed the same) and
> pushed patches 1-8 here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git mmc/sdhi-refactor
>
> Is pulling okay, or do you want me to resend?

This is fine! I have picked them up from your tree and applied them for next!

Do note that I am re-basing my next branch from time to time, so I
assume the branch you shared with me isn't an immutable branch!?

Thanks and kind regards
Uffe

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Wolfram Sang]

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


> Do note that I am re-basing my next branch from time to time, so I
> assume the branch you shared with me isn't an immutable branch!?

No prob, it was just for you :)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support

[Wolfram Sang]

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


> Do note that I am re-basing my next branch from time to time, so I
> assume the branch you shared with me isn't an immutable branch!?

No prob, it was just for you :)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

^
> I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check
> that a following CMD13 command always states that the card isn't busy.
> I think the best path to try this is when sending a big write data
> request, as in that case you can be quite certain that the card gets
> busy between the requests.
> 
> So somewhere in the mmc block layer add some debug prints, that should do it.

I'd think the mmc_test driver already helped me with this. I ran tests
like 31 (Consecutive write performance by transfer size) or 36 (Large
sequential write from scattered pages) which both succeeded without any
warnings printed. And the code explicitly sends a CMD13 after transfer,
checks for busy and prints a warning when MMC_CAP_WAIT_WHILE_BUSY is
set and a busy state is detected. Nice test thing this driver is :)

So, it looks to me that patch 9 is fine to go in?

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

^
> I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check
> that a following CMD13 command always states that the card isn't busy.
> I think the best path to try this is when sending a big write data
> request, as in that case you can be quite certain that the card gets
> busy between the requests.
> 
> So somewhere in the mmc block layer add some debug prints, that should do it.

I'd think the mmc_test driver already helped me with this. I ran tests
like 31 (Consecutive write performance by transfer size) or 36 (Large
sequential write from scattered pages) which both succeeded without any
warnings printed. And the code explicitly sends a CMD13 after transfer,
checks for busy and prints a warning when MMC_CAP_WAIT_WHILE_BUSY is
set and a busy state is detected. Nice test thing this driver is :)

So, it looks to me that patch 9 is fine to go in?

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 10 February 2016 at 17:36, Wolfram Sang <wsa@the-dreams.de> wrote:
> ^
>> I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check
>> that a following CMD13 command always states that the card isn't busy.
>> I think the best path to try this is when sending a big write data
>> request, as in that case you can be quite certain that the card gets
>> busy between the requests.
>>
>> So somewhere in the mmc block layer add some debug prints, that should do it.
>
> I'd think the mmc_test driver already helped me with this. I ran tests
> like 31 (Consecutive write performance by transfer size) or 36 (Large
> sequential write from scattered pages) which both succeeded without any
> warnings printed. And the code explicitly sends a CMD13 after transfer,
> checks for busy and prints a warning when MMC_CAP_WAIT_WHILE_BUSY is
> set and a busy state is detected. Nice test thing this driver is :)

That should do it!

>
> So, it looks to me that patch 9 is fine to go in?
>

Not yet. :-)

I suspect you are using a delayed work in this driver to deal with
request timeouts.

The value for the delay that is used, needs to be informed towards the
mmc core via the "->max_busy_timeout".

One more thing, as the documentation of your host controllers lacks
some information about the busy mode, perhaps it's worth to add some
comments about this in the code and as well in the change-log!?

Kind regards
Uffe

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 10 February 2016 at 17:36, Wolfram Sang <wsa@the-dreams.de> wrote:
> ^
>> I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check
>> that a following CMD13 command always states that the card isn't busy.
>> I think the best path to try this is when sending a big write data
>> request, as in that case you can be quite certain that the card gets
>> busy between the requests.
>>
>> So somewhere in the mmc block layer add some debug prints, that should do it.
>
> I'd think the mmc_test driver already helped me with this. I ran tests
> like 31 (Consecutive write performance by transfer size) or 36 (Large
> sequential write from scattered pages) which both succeeded without any
> warnings printed. And the code explicitly sends a CMD13 after transfer,
> checks for busy and prints a warning when MMC_CAP_WAIT_WHILE_BUSY is
> set and a busy state is detected. Nice test thing this driver is :)

That should do it!

>
> So, it looks to me that patch 9 is fine to go in?
>

Not yet. :-)

I suspect you are using a delayed work in this driver to deal with
request timeouts.

The value for the delay that is used, needs to be informed towards the
mmc core via the "->max_busy_timeout".

One more thing, as the documentation of your host controllers lacks
some information about the busy mode, perhaps it's worth to add some
comments about this in the code and as well in the change-log!?

Kind regards
Uffe

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

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

> I suspect you are using a delayed work in this driver to deal with
> request timeouts.
> 
> The value for the delay that is used, needs to be informed towards the
> mmc core via the "->max_busy_timeout".

Shouldn't that be a seperate patch? In patch 9, I add support for
another SoC. But your requested change will affect all SoCs.

> One more thing, as the documentation of your host controllers lacks
> some information about the busy mode, perhaps it's worth to add some
> comments about this in the code and as well in the change-log!?

Do you mean documenting my findings with the mmc_test driver? Or
something else?

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

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

> I suspect you are using a delayed work in this driver to deal with
> request timeouts.
> 
> The value for the delay that is used, needs to be informed towards the
> mmc core via the "->max_busy_timeout".

Shouldn't that be a seperate patch? In patch 9, I add support for
another SoC. But your requested change will affect all SoCs.

> One more thing, as the documentation of your host controllers lacks
> some information about the busy mode, perhaps it's worth to add some
> comments about this in the code and as well in the change-log!?

Do you mean documenting my findings with the mmc_test driver? Or
something else?

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
>> I suspect you are using a delayed work in this driver to deal with
>> request timeouts.
>>
>> The value for the delay that is used, needs to be informed towards the
>> mmc core via the "->max_busy_timeout".
>
> Shouldn't that be a seperate patch? In patch 9, I add support for
> another SoC. But your requested change will affect all SoCs.

This is related to how the core treat hosts that announces
MMC_CAP_WAIT_WHILE_BUSY.

Therefore max_busy_timeout needs to be set within the same patch.

>
>> One more thing, as the documentation of your host controllers lacks
>> some information about the busy mode, perhaps it's worth to add some
>> comments about this in the code and as well in the change-log!?
>
> Do you mean documenting my findings with the mmc_test driver? Or
> something else?

It doesn't have to be very much data, just that the documentation
isn't clear and therefore some tests has been done to verify that it
works as expected.

Kind regards
Uffe

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
>> I suspect you are using a delayed work in this driver to deal with
>> request timeouts.
>>
>> The value for the delay that is used, needs to be informed towards the
>> mmc core via the "->max_busy_timeout".
>
> Shouldn't that be a seperate patch? In patch 9, I add support for
> another SoC. But your requested change will affect all SoCs.

This is related to how the core treat hosts that announces
MMC_CAP_WAIT_WHILE_BUSY.

Therefore max_busy_timeout needs to be set within the same patch.

>
>> One more thing, as the documentation of your host controllers lacks
>> some information about the busy mode, perhaps it's worth to add some
>> comments about this in the code and as well in the change-log!?
>
> Do you mean documenting my findings with the mmc_test driver? Or
> something else?

It doesn't have to be very much data, just that the documentation
isn't clear and therefore some tests has been done to verify that it
works as expected.

Kind regards
Uffe

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote:
> On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
> >> I suspect you are using a delayed work in this driver to deal with
> >> request timeouts.
> >>
> >> The value for the delay that is used, needs to be informed towards the
> >> mmc core via the "->max_busy_timeout".
> >
> > Shouldn't that be a seperate patch? In patch 9, I add support for
> > another SoC. But your requested change will affect all SoCs.
> 
> This is related to how the core treat hosts that announces
> MMC_CAP_WAIT_WHILE_BUSY.
> 
> Therefore max_busy_timeout needs to be set within the same patch.

Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY
already, so this step would then have to be taken seperately to catch
all SoC. But I was wrong.

I meanwhile found the timeout bits which are present in Gen3 and also in
Gen2 and are currently unused by the driver. While this helps explaining
that the HW has internal busy detection, its full potential is not
implemented yet.

So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and
will implement timeout handling incrementally as a seperate series.

Sounds good?

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote:
> On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
> >> I suspect you are using a delayed work in this driver to deal with
> >> request timeouts.
> >>
> >> The value for the delay that is used, needs to be informed towards the
> >> mmc core via the "->max_busy_timeout".
> >
> > Shouldn't that be a seperate patch? In patch 9, I add support for
> > another SoC. But your requested change will affect all SoCs.
> 
> This is related to how the core treat hosts that announces
> MMC_CAP_WAIT_WHILE_BUSY.
> 
> Therefore max_busy_timeout needs to be set within the same patch.

Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY
already, so this step would then have to be taken seperately to catch
all SoC. But I was wrong.

I meanwhile found the timeout bits which are present in Gen3 and also in
Gen2 and are currently unused by the driver. While this helps explaining
that the HW has internal busy detection, its full potential is not
implemented yet.

So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and
will implement timeout handling incrementally as a seperate series.

Sounds good?

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 11 February 2016 at 14:32, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote:
>> On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
>> >> I suspect you are using a delayed work in this driver to deal with
>> >> request timeouts.
>> >>
>> >> The value for the delay that is used, needs to be informed towards the
>> >> mmc core via the "->max_busy_timeout".
>> >
>> > Shouldn't that be a seperate patch? In patch 9, I add support for
>> > another SoC. But your requested change will affect all SoCs.
>>
>> This is related to how the core treat hosts that announces
>> MMC_CAP_WAIT_WHILE_BUSY.
>>
>> Therefore max_busy_timeout needs to be set within the same patch.
>
> Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY
> already, so this step would then have to be taken seperately to catch
> all SoC. But I was wrong.
>
> I meanwhile found the timeout bits which are present in Gen3 and also in
> Gen2 and are currently unused by the driver. While this helps explaining
> that the HW has internal busy detection, its full potential is not
> implemented yet.
>
> So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and
> will implement timeout handling incrementally as a seperate series.
>
> Sounds good?

Yes, please!

Kind regards
Uffe

Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support

[Ulf Hansson]

On 11 February 2016 at 14:32, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote:
>> On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
>> >> I suspect you are using a delayed work in this driver to deal with
>> >> request timeouts.
>> >>
>> >> The value for the delay that is used, needs to be informed towards the
>> >> mmc core via the "->max_busy_timeout".
>> >
>> > Shouldn't that be a seperate patch? In patch 9, I add support for
>> > another SoC. But your requested change will affect all SoCs.
>>
>> This is related to how the core treat hosts that announces
>> MMC_CAP_WAIT_WHILE_BUSY.
>>
>> Therefore max_busy_timeout needs to be set within the same patch.
>
> Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY
> already, so this step would then have to be taken seperately to catch
> all SoC. But I was wrong.
>
> I meanwhile found the timeout bits which are present in Gen3 and also in
> Gen2 and are currently unused by the driver. While this helps explaining
> that the HW has internal busy detection, its full potential is not
> implemented yet.
>
> So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and
> will implement timeout handling incrementally as a seperate series.
>
> Sounds good?

Yes, please!

Kind regards
Uffe