[PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Jerome Brunet]

The goal of the patchset was mainly to address the following warning:

WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
Hardware name: Some A113 Board (DT)
pstate: 40000085 (nZcv daIf -PAN -UAO)
pc : meson_mmc_irq+0xc0/0x1e0
lr : __handle_irq_event_percpu+0x70/0x180
sp : ffff000008003980
x29: ffff000008003980 x28: 0000000000000000
[...]
x1 : ffff80001a71bd40 x0 : 0000000000000000
Call trace:
 meson_mmc_irq+0xc0/0x1e0
 __handle_irq_event_percpu+0x70/0x180
 handle_irq_event_percpu+0x34/0x88
 handle_irq_event+0x48/0x78
 handle_fasteoi_irq+0xa0/0x180
 generic_handle_irq+0x24/0x38
 __handle_domain_irq+0x5c/0xb8
 gic_handle_irq+0x58/0xa8

This happens when using the chained descriptor mode. If there is an
error, we call mmc_request_done(), loosing any reference to the cmd. It
turns out that the chained descriptor does really stops when we do so, at
least not completly. Most of the time, it can be seen with this harmless
warning because the descriptor will raise another unexpected IRQ. On rare
occasion, it will completly break the MMC.

This is mostly adressed by patch #1.
With this fixed, I took (yet) another look at the ultra-high speed modes
and the tuning.

I came up with new settings in patch 3 and 4. I've tested them on eMMC,
sdcard and sdio on the following platforms:
 * gxbb p200
 * gxl p230, libretech (eMMC only), kvim.
 * axg s400

So far, these new settings seems to be working great but I think it
would be nice if others could test this and provide their feedback.
This why  patch 3 and 4 are RFT tagged.

Jerome Brunet (4):
  mmc: meson-gx: make sure the descriptor is stopped on errors
  mmc: meson-gx: remove useless lock
  mmc: meson-gx: align default phase on soc vendor tree
  mmc: meson-gx: add signal resampling

 drivers/mmc/host/meson-gx-mmc.c | 100 ++++++++++++++++++++++++--------
 1 file changed, 75 insertions(+), 25 deletions(-)

-- 
2.19.2


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH 1/4] mmc: meson-gx: make sure the descriptor is stopped on errors

[Jerome Brunet]

On errors, if we don't stop the descriptor chain, it may continue to
run and raise IRQ after we have called mmc_request_done(). This is bad
because we won't be able to get cmd anymore and properly deal with the
IRQ.

This patch makes sure the descriptor chain is stopped before
calling mmc_request_done()

Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 73 ++++++++++++++++++++++++++++-----
 1 file changed, 63 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index c201c378537e..fcb5d693c897 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -21,6 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
@@ -90,9 +91,11 @@
 #define   CFG_CLK_ALWAYS_ON BIT(18)
 #define   CFG_CHK_DS BIT(20)
 #define   CFG_AUTO_CLK BIT(23)
+#define   CFG_ERR_ABORT BIT(27)
 
 #define SD_EMMC_STATUS 0x48
 #define   STATUS_BUSY BIT(31)
+#define   STATUS_DESC_BUSY BIT(30)
 #define   STATUS_DATI GENMASK(23, 16)
 
 #define SD_EMMC_IRQ_EN 0x4c
@@ -928,6 +931,7 @@ static void meson_mmc_start_cmd(struct mmc_host *mmc, struct mmc_command *cmd)
 
 	cmd_cfg |= FIELD_PREP(CMD_CFG_CMD_INDEX_MASK, cmd->opcode);
 	cmd_cfg |= CMD_CFG_OWNER;  /* owned by CPU */
+	cmd_cfg |= CMD_CFG_ERROR; /* stop in case of error */
 
 	meson_mmc_set_response_bits(cmd, &cmd_cfg);
 
@@ -1022,6 +1026,17 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
 	u32 irq_en, status, raw_status;
 	irqreturn_t ret = IRQ_NONE;
 
+	irq_en = readl(host->regs + SD_EMMC_IRQ_EN);
+	raw_status = readl(host->regs + SD_EMMC_STATUS);
+	status = raw_status & irq_en;
+
+	if (!status) {
+		dev_dbg(host->dev,
+			"Unexpected IRQ! irq_en 0x%08x - status 0x%08x\n",
+			 irq_en, raw_status);
+		return IRQ_NONE;
+	}
+
 	if (WARN_ON(!host) || WARN_ON(!host->cmd))
 		return IRQ_NONE;
 
@@ -1029,22 +1044,18 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
 
 	cmd = host->cmd;
 	data = cmd->data;
-	irq_en = readl(host->regs + SD_EMMC_IRQ_EN);
-	raw_status = readl(host->regs + SD_EMMC_STATUS);
-	status = raw_status & irq_en;
-
 	cmd->error = 0;
 	if (status & IRQ_CRC_ERR) {
 		dev_dbg(host->dev, "CRC Error - status 0x%08x\n", status);
 		cmd->error = -EILSEQ;
-		ret = IRQ_HANDLED;
+		ret = IRQ_WAKE_THREAD;
 		goto out;
 	}
 
 	if (status & IRQ_TIMEOUTS) {
 		dev_dbg(host->dev, "Timeout - status 0x%08x\n", status);
 		cmd->error = -ETIMEDOUT;
-		ret = IRQ_HANDLED;
+		ret = IRQ_WAKE_THREAD;
 		goto out;
 	}
 
@@ -1069,17 +1080,49 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
 	/* ack all enabled interrupts */
 	writel(irq_en, host->regs + SD_EMMC_STATUS);
 
+	if (cmd->error) {
+		/* Stop desc in case of errors */
+		u32 start = readl(host->regs + SD_EMMC_START);
+
+		start &= ~START_DESC_BUSY;
+		writel(start, host->regs + SD_EMMC_START);
+	}
+
 	if (ret == IRQ_HANDLED)
 		meson_mmc_request_done(host->mmc, cmd->mrq);
-	else if (ret == IRQ_NONE)
-		dev_warn(host->dev,
-			 "Unexpected IRQ! status=0x%08x, irq_en=0x%08x\n",
-			 raw_status, irq_en);
 
 	spin_unlock(&host->lock);
 	return ret;
 }
 
+static int meson_mmc_wait_desc_stop(struct meson_host *host)
+{
+	int loop;
+	u32 status;
+
+	/*
+	 * It may sometimes take a while for it to actually halt. Here, we
+	 * are giving it 5ms to comply
+	 *
+	 * If we don't confirm the descriptor is stopped, it might raise new
+	 * IRQs after we have called mmc_request_done() which is bad.
+	 */
+	for (loop = 50; loop; loop--) {
+		status = readl(host->regs + SD_EMMC_STATUS);
+		if (status & (STATUS_BUSY | STATUS_DESC_BUSY))
+			udelay(100);
+		else
+			break;
+	}
+
+	if (status & (STATUS_BUSY | STATUS_DESC_BUSY)) {
+		dev_err(host->dev, "Timed out waiting for host to stop\n");
+		return -ETIMEDOUT;
+	}
+
+	return 0;
+}
+
 static irqreturn_t meson_mmc_irq_thread(int irq, void *dev_id)
 {
 	struct meson_host *host = dev_id;
@@ -1090,6 +1133,13 @@ static irqreturn_t meson_mmc_irq_thread(int irq, void *dev_id)
 	if (WARN_ON(!cmd))
 		return IRQ_NONE;
 
+	if (cmd->error) {
+		meson_mmc_wait_desc_stop(host);
+		meson_mmc_request_done(host->mmc, cmd->mrq);
+
+		return IRQ_HANDLED;
+	}
+
 	data = cmd->data;
 	if (meson_mmc_bounce_buf_read(data)) {
 		xfer_bytes = data->blksz * data->blocks;
@@ -1130,6 +1180,9 @@ static void meson_mmc_cfg_init(struct meson_host *host)
 	cfg |= FIELD_PREP(CFG_RC_CC_MASK, ilog2(SD_EMMC_CFG_CMD_GAP));
 	cfg |= FIELD_PREP(CFG_BLK_LEN_MASK, ilog2(SD_EMMC_CFG_BLK_SIZE));
 
+	/* abort chain on R/W errors */
+	cfg |= CFG_ERR_ABORT;
+
 	writel(cfg, host->regs + SD_EMMC_CFG);
 }
 
-- 
2.19.2


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH 2/4] mmc: meson-gx: remove useless lock

[Jerome Brunet]

The spinlock is only used within the irq handler so it does not
seem very useful.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index fcb5d693c897..5cc31e434ca1 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -26,7 +26,6 @@
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/ioport.h>
-#include <linux/spinlock.h>
 #include <linux/dma-mapping.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>
@@ -159,7 +158,6 @@ struct meson_host {
 	struct	mmc_host	*mmc;
 	struct	mmc_command	*cmd;
 
-	spinlock_t lock;
 	void __iomem *regs;
 	struct clk *core_clk;
 	struct clk *mmc_clk;
@@ -1040,8 +1038,6 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
 	if (WARN_ON(!host) || WARN_ON(!host->cmd))
 		return IRQ_NONE;
 
-	spin_lock(&host->lock);
-
 	cmd = host->cmd;
 	data = cmd->data;
 	cmd->error = 0;
@@ -1091,7 +1087,6 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
 	if (ret == IRQ_HANDLED)
 		meson_mmc_request_done(host->mmc, cmd->mrq);
 
-	spin_unlock(&host->lock);
 	return ret;
 }
 
@@ -1244,8 +1239,6 @@ static int meson_mmc_probe(struct platform_device *pdev)
 	host->dev = &pdev->dev;
 	dev_set_drvdata(&pdev->dev, host);
 
-	spin_lock_init(&host->lock);
-
 	/* Get regulators and the supported OCR mask */
 	host->vqmmc_enabled = false;
 	ret = mmc_regulator_get_supply(mmc);
-- 
2.19.2


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[RFT PATCH 3/4] mmc: meson-gx: align default phase on soc vendor tree

[Jerome Brunet]

Align the default Core and Tx phase with the SoC vendor tree.
Even if the Tx phase is different from what the documentation
recommends, it seems to provide better results.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 5cc31e434ca1..837bed0b8c01 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -634,14 +634,8 @@ static int meson_mmc_clk_init(struct meson_host *host)
 	if (ret)
 		return ret;
 
-	/*
-	 * Set phases : These values are mostly the datasheet recommended ones
-	 * except for the Tx phase. Datasheet recommends 180 but some cards
-	 * fail at initialisation with it. 270 works just fine, it fixes these
-	 * initialisation issues and enable eMMC DDR52 mode.
-	 */
 	clk_set_phase(host->mmc_clk, 180);
-	clk_set_phase(host->tx_clk, 270);
+	clk_set_phase(host->tx_clk, 0);
 	clk_set_phase(host->rx_clk, 0);
 
 	return clk_prepare_enable(host->mmc_clk);
-- 
2.19.2


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[RFT PATCH 4/4] mmc: meson-gx: add signal resampling

[Jerome Brunet]

With some eMMC devices, there is still issues with the new phase
settings. Enabling signal resampling seems to solve the problem
for these.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 837bed0b8c01..c2690c1a50ff 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -66,6 +66,9 @@
 
 #define SD_EMMC_DELAY 0x4
 #define SD_EMMC_ADJUST 0x8
+#define   ADJUST_ADJ_DELAY_MASK GENMASK(21, 16)
+#define   ADJUST_DS_EN BIT(15)
+#define   ADJUST_ADJ_EN BIT(13)
 
 #define SD_EMMC_DELAY1 0x4
 #define SD_EMMC_DELAY2 0x8
@@ -143,6 +146,7 @@ struct meson_mmc_data {
 	unsigned int tx_delay_mask;
 	unsigned int rx_delay_mask;
 	unsigned int always_on;
+	unsigned int adjust;
 };
 
 struct sd_emmc_desc {
@@ -1162,7 +1166,7 @@ static int meson_mmc_get_cd(struct mmc_host *mmc)
 
 static void meson_mmc_cfg_init(struct meson_host *host)
 {
-	u32 cfg = 0;
+	u32 cfg = 0, adj = 0;
 
 	cfg |= FIELD_PREP(CFG_RESP_TIMEOUT_MASK,
 			  ilog2(SD_EMMC_CFG_RESP_TIMEOUT));
@@ -1173,6 +1177,10 @@ static void meson_mmc_cfg_init(struct meson_host *host)
 	cfg |= CFG_ERR_ABORT;
 
 	writel(cfg, host->regs + SD_EMMC_CFG);
+
+	/* enable signal resampling w/o delay */
+	adj = ADJUST_ADJ_EN;
+	writel(adj, host->regs + host->data->adjust);
 }
 
 static int meson_mmc_card_busy(struct mmc_host *mmc)
@@ -1396,12 +1404,14 @@ static const struct meson_mmc_data meson_gx_data = {
 	.tx_delay_mask	= CLK_V2_TX_DELAY_MASK,
 	.rx_delay_mask	= CLK_V2_RX_DELAY_MASK,
 	.always_on	= CLK_V2_ALWAYS_ON,
+	.adjust		= SD_EMMC_ADJUST,
 };
 
 static const struct meson_mmc_data meson_axg_data = {
 	.tx_delay_mask	= CLK_V3_TX_DELAY_MASK,
 	.rx_delay_mask	= CLK_V3_RX_DELAY_MASK,
 	.always_on	= CLK_V3_ALWAYS_ON,
+	.adjust		= SD_EMMC_V3_ADJUST,
 };
 
 static const struct of_device_id meson_mmc_of_match[] = {
-- 
2.19.2


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Kevin Hilman]

Jerome Brunet <jbrunet@baylibre.com> writes:

> The goal of the patchset was mainly to address the following warning:
>
> WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
> Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
> Hardware name: Some A113 Board (DT)
> pstate: 40000085 (nZcv daIf -PAN -UAO)
> pc : meson_mmc_irq+0xc0/0x1e0
> lr : __handle_irq_event_percpu+0x70/0x180
> sp : ffff000008003980
> x29: ffff000008003980 x28: 0000000000000000
> [...]
> x1 : ffff80001a71bd40 x0 : 0000000000000000
> Call trace:
>  meson_mmc_irq+0xc0/0x1e0
>  __handle_irq_event_percpu+0x70/0x180
>  handle_irq_event_percpu+0x34/0x88
>  handle_irq_event+0x48/0x78
>  handle_fasteoi_irq+0xa0/0x180
>  generic_handle_irq+0x24/0x38
>  __handle_domain_irq+0x5c/0xb8
>  gic_handle_irq+0x58/0xa8
>
> This happens when using the chained descriptor mode. If there is an
> error, we call mmc_request_done(), loosing any reference to the cmd. It
> turns out that the chained descriptor does really stops when we do so, at

I think you mean...

s/does really stops/does not really stop/

> least not completly. Most of the time, it can be seen with this harmless
> warning because the descriptor will raise another unexpected IRQ. On rare
> occasion, it will completly break the MMC.
>
> This is mostly adressed by patch #1.
> With this fixed, I took (yet) another look at the ultra-high speed modes
> and the tuning.
>
> I came up with new settings in patch 3 and 4. I've tested them on eMMC,
> sdcard and sdio on the following platforms:
>  * gxbb p200
>  * gxl p230, libretech (eMMC only), kvim.
>  * axg s400
>
> So far, these new settings seems to be working great but I think it
> would be nice if others could test this and provide their feedback.
> This why  patch 3 and 4 are RFT tagged.

For broader testing, I've added this to my v4.21/testing branch, which
is included in my integ branch which gets a spin through kernelCI.

Kevin


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Jerome Brunet]

On Thu, 2018-12-06 at 20:14 -0800, Kevin Hilman wrote:
> Jerome Brunet <jbrunet@baylibre.com> writes:
> 
> > The goal of the patchset was mainly to address the following warning:
> > 
> > WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-
> > mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
> > Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
> > CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
> > Hardware name: Some A113 Board (DT)
> > pstate: 40000085 (nZcv daIf -PAN -UAO)
> > pc : meson_mmc_irq+0xc0/0x1e0
> > lr : __handle_irq_event_percpu+0x70/0x180
> > sp : ffff000008003980
> > x29: ffff000008003980 x28: 0000000000000000
> > [...]
> > x1 : ffff80001a71bd40 x0 : 0000000000000000
> > Call trace:
> >  meson_mmc_irq+0xc0/0x1e0
> >  __handle_irq_event_percpu+0x70/0x180
> >  handle_irq_event_percpu+0x34/0x88
> >  handle_irq_event+0x48/0x78
> >  handle_fasteoi_irq+0xa0/0x180
> >  generic_handle_irq+0x24/0x38
> >  __handle_domain_irq+0x5c/0xb8
> >  gic_handle_irq+0x58/0xa8
> > 
> > This happens when using the chained descriptor mode. If there is an
> > error, we call mmc_request_done(), loosing any reference to the cmd. It
> > turns out that the chained descriptor does really stops when we do so, at
> 
> I think you mean...
> 
> s/does really stops/does not really stop/

indeed

> 
> > least not completly. Most of the time, it can be seen with this harmless
> > warning because the descriptor will raise another unexpected IRQ. On rare
> > occasion, it will completly break the MMC.
> > 
> > This is mostly adressed by patch #1.
> > With this fixed, I took (yet) another look at the ultra-high speed modes
> > and the tuning.
> > 
> > I came up with new settings in patch 3 and 4. I've tested them on eMMC,
> > sdcard and sdio on the following platforms:
> >  * gxbb p200
> >  * gxl p230, libretech (eMMC only), kvim.
> >  * axg s400
> > 
> > So far, these new settings seems to be working great but I think it
> > would be nice if others could test this and provide their feedback.
> > This why  patch 3 and 4 are RFT tagged.
> 
> For broader testing, I've added this to my v4.21/testing branch, which
> is included in my integ branch which gets a spin through kernelCI.

Thx

> 
> Kevin
> 



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Ulf Hansson]

On Thu, 6 Dec 2018 at 16:18, Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> The goal of the patchset was mainly to address the following warning:
>
> WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
> Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
> Hardware name: Some A113 Board (DT)
> pstate: 40000085 (nZcv daIf -PAN -UAO)
> pc : meson_mmc_irq+0xc0/0x1e0
> lr : __handle_irq_event_percpu+0x70/0x180
> sp : ffff000008003980
> x29: ffff000008003980 x28: 0000000000000000
> [...]
> x1 : ffff80001a71bd40 x0 : 0000000000000000
> Call trace:
>  meson_mmc_irq+0xc0/0x1e0
>  __handle_irq_event_percpu+0x70/0x180
>  handle_irq_event_percpu+0x34/0x88
>  handle_irq_event+0x48/0x78
>  handle_fasteoi_irq+0xa0/0x180
>  generic_handle_irq+0x24/0x38
>  __handle_domain_irq+0x5c/0xb8
>  gic_handle_irq+0x58/0xa8
>
> This happens when using the chained descriptor mode. If there is an
> error, we call mmc_request_done(), loosing any reference to the cmd. It
> turns out that the chained descriptor does really stops when we do so, at
> least not completly. Most of the time, it can be seen with this harmless
> warning because the descriptor will raise another unexpected IRQ. On rare
> occasion, it will completly break the MMC.
>
> This is mostly adressed by patch #1.
> With this fixed, I took (yet) another look at the ultra-high speed modes
> and the tuning.
>
> I came up with new settings in patch 3 and 4. I've tested them on eMMC,
> sdcard and sdio on the following platforms:
>  * gxbb p200
>  * gxl p230, libretech (eMMC only), kvim.
>  * axg s400
>
> So far, these new settings seems to be working great but I think it
> would be nice if others could test this and provide their feedback.
> This why  patch 3 and 4 are RFT tagged.
>
> Jerome Brunet (4):
>   mmc: meson-gx: make sure the descriptor is stopped on errors
>   mmc: meson-gx: remove useless lock
>   mmc: meson-gx: align default phase on soc vendor tree
>   mmc: meson-gx: add signal resampling
>
>  drivers/mmc/host/meson-gx-mmc.c | 100 ++++++++++++++++++++++++--------
>  1 file changed, 75 insertions(+), 25 deletions(-)
>

Following Kevin's approach, applied for next to get this tested, thanks!

Kind regards
Uffe

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Martin Blumenstingl]

Hi Jerome,

On Thu, Dec 6, 2018 at 4:18 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> The goal of the patchset was mainly to address the following warning:
>
> WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
> Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
> Hardware name: Some A113 Board (DT)
> pstate: 40000085 (nZcv daIf -PAN -UAO)
> pc : meson_mmc_irq+0xc0/0x1e0
> lr : __handle_irq_event_percpu+0x70/0x180
> sp : ffff000008003980
> x29: ffff000008003980 x28: 0000000000000000
> [...]
> x1 : ffff80001a71bd40 x0 : 0000000000000000
> Call trace:
>  meson_mmc_irq+0xc0/0x1e0
>  __handle_irq_event_percpu+0x70/0x180
>  handle_irq_event_percpu+0x34/0x88
>  handle_irq_event+0x48/0x78
>  handle_fasteoi_irq+0xa0/0x180
>  generic_handle_irq+0x24/0x38
>  __handle_domain_irq+0x5c/0xb8
>  gic_handle_irq+0x58/0xa8
>
> This happens when using the chained descriptor mode. If there is an
> error, we call mmc_request_done(), loosing any reference to the cmd. It
> turns out that the chained descriptor does really stops when we do so, at
> least not completly. Most of the time, it can be seen with this harmless
> warning because the descriptor will raise another unexpected IRQ. On rare
> occasion, it will completly break the MMC.
>
> This is mostly adressed by patch #1.
> With this fixed, I took (yet) another look at the ultra-high speed modes
> and the tuning.
>
> I came up with new settings in patch 3 and 4. I've tested them on eMMC,
> sdcard and sdio on the following platforms:
>  * gxbb p200
>  * gxl p230, libretech (eMMC only), kvim.
>  * axg s400
>
> So far, these new settings seems to be working great but I think it
> would be nice if others could test this and provide their feedback.
> This why  patch 3 and 4 are RFT tagged.
>
> Jerome Brunet (4):
>   mmc: meson-gx: make sure the descriptor is stopped on errors
>   mmc: meson-gx: remove useless lock
>   mmc: meson-gx: align default phase on soc vendor tree
>   mmc: meson-gx: add signal resampling
I gave all four patches a go on my Khadas VIM2 Basic (16GB eMMC).
regardless of whether I have your patch applied or not: eMMC
sporadically fails tuning (if I reboot the board a few times it starts
to work)
[    4.172686] mmc1: tuning execution failed: -5
[    4.182535] mmc1: error -5 whilst initialising MMC card

I'm not sure if this issue is specific to my Khadas VIM2 so this is
*not* a nack for your patches.


Regards
Martin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Jerome Brunet]

On Sat, 2018-12-22 at 18:28 +0100, Martin Blumenstingl wrote:
> Hi Jerome,
> 
> On Thu, Dec 6, 2018 at 4:18 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
> > The goal of the patchset was mainly to address the following warning:
> > 
> > WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-
> > mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
> > Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
> > CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
> > Hardware name: Some A113 Board (DT)
> > pstate: 40000085 (nZcv daIf -PAN -UAO)
> > pc : meson_mmc_irq+0xc0/0x1e0
> > lr : __handle_irq_event_percpu+0x70/0x180
> > sp : ffff000008003980
> > x29: ffff000008003980 x28: 0000000000000000
> > [...]
> > x1 : ffff80001a71bd40 x0 : 0000000000000000
> > Call trace:
> >  meson_mmc_irq+0xc0/0x1e0
> >  __handle_irq_event_percpu+0x70/0x180
> >  handle_irq_event_percpu+0x34/0x88
> >  handle_irq_event+0x48/0x78
> >  handle_fasteoi_irq+0xa0/0x180
> >  generic_handle_irq+0x24/0x38
> >  __handle_domain_irq+0x5c/0xb8
> >  gic_handle_irq+0x58/0xa8
> > 
> > This happens when using the chained descriptor mode. If there is an
> > error, we call mmc_request_done(), loosing any reference to the cmd. It
> > turns out that the chained descriptor does really stops when we do so, at
> > least not completly. Most of the time, it can be seen with this harmless
> > warning because the descriptor will raise another unexpected IRQ. On rare
> > occasion, it will completly break the MMC.
> > 
> > This is mostly adressed by patch #1.
> > With this fixed, I took (yet) another look at the ultra-high speed modes
> > and the tuning.
> > 
> > I came up with new settings in patch 3 and 4. I've tested them on eMMC,
> > sdcard and sdio on the following platforms:
> >  * gxbb p200
> >  * gxl p230, libretech (eMMC only), kvim.
> >  * axg s400
> > 
> > So far, these new settings seems to be working great but I think it
> > would be nice if others could test this and provide their feedback.
> > This why  patch 3 and 4 are RFT tagged.
> > 
> > Jerome Brunet (4):
> >   mmc: meson-gx: make sure the descriptor is stopped on errors
> >   mmc: meson-gx: remove useless lock
> >   mmc: meson-gx: align default phase on soc vendor tree
> >   mmc: meson-gx: add signal resampling
> I gave all four patches a go on my Khadas VIM2 Basic (16GB eMMC).
> regardless of whether I have your patch applied or not: eMMC
> sporadically fails tuning (if I reboot the board a few times it starts
> to work)
> [    4.172686] mmc1: tuning execution failed: -5
> [    4.182535] mmc1: error -5 whilst initialising MMC card

Damn ...

This particular device is set to use hs400 ATM. Could you try with hs200 only
? (removing mmc-hs400-1_8v from meson-gxm-khadas-vim2.dts) 

I might be wrong but I think tuning is supposed to be done with hs200, before
activating DDR mode to switch to hs400. In theory, removing hs400 should not
change anything (so I expect the tuning to still fail) but it is worth
checking.

> 
> I'm not sure if this issue is specific to my Khadas VIM2 so this is
> *not* a nack for your patches.

I'll check if I can get my hands on this device.

When cooking this series, I tried another trick which was cycling on the
resampling delays (see ADJUST_ADJ_DELAY_MASK). At the time, I could not see
any significant improvement while doing it, so I dropped it.

If possible. could you check if any particular value in this field, between 0
and 5, makes things any better ?

Alternatively, if you find another combination of phase for the mmc_clk and
tx_clk that works better for this device, feel free to let me know. Maybe we
can work something out.

Cheers

> 
> 
> Regards
> Martin



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH 0/4] mmc: meson-gx: chained descriptor fixup and improvements

[Martin Blumenstingl]

Hi Jerome,

On Wed, Jan 2, 2019 at 1:46 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On Sat, 2018-12-22 at 18:28 +0100, Martin Blumenstingl wrote:
> > Hi Jerome,
> >
> > On Thu, Dec 6, 2018 at 4:18 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
> > > The goal of the patchset was mainly to address the following warning:
> > >
> > > WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-
> > > mmc.c:1025 meson_mmc_irq+0xc0/0x1e0
> > > Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
> > > CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.1 #1
> > > Hardware name: Some A113 Board (DT)
> > > pstate: 40000085 (nZcv daIf -PAN -UAO)
> > > pc : meson_mmc_irq+0xc0/0x1e0
> > > lr : __handle_irq_event_percpu+0x70/0x180
> > > sp : ffff000008003980
> > > x29: ffff000008003980 x28: 0000000000000000
> > > [...]
> > > x1 : ffff80001a71bd40 x0 : 0000000000000000
> > > Call trace:
> > >  meson_mmc_irq+0xc0/0x1e0
> > >  __handle_irq_event_percpu+0x70/0x180
> > >  handle_irq_event_percpu+0x34/0x88
> > >  handle_irq_event+0x48/0x78
> > >  handle_fasteoi_irq+0xa0/0x180
> > >  generic_handle_irq+0x24/0x38
> > >  __handle_domain_irq+0x5c/0xb8
> > >  gic_handle_irq+0x58/0xa8
> > >
> > > This happens when using the chained descriptor mode. If there is an
> > > error, we call mmc_request_done(), loosing any reference to the cmd. It
> > > turns out that the chained descriptor does really stops when we do so, at
> > > least not completly. Most of the time, it can be seen with this harmless
> > > warning because the descriptor will raise another unexpected IRQ. On rare
> > > occasion, it will completly break the MMC.
> > >
> > > This is mostly adressed by patch #1.
> > > With this fixed, I took (yet) another look at the ultra-high speed modes
> > > and the tuning.
> > >
> > > I came up with new settings in patch 3 and 4. I've tested them on eMMC,
> > > sdcard and sdio on the following platforms:
> > >  * gxbb p200
> > >  * gxl p230, libretech (eMMC only), kvim.
> > >  * axg s400
> > >
> > > So far, these new settings seems to be working great but I think it
> > > would be nice if others could test this and provide their feedback.
> > > This why  patch 3 and 4 are RFT tagged.
> > >
> > > Jerome Brunet (4):
> > >   mmc: meson-gx: make sure the descriptor is stopped on errors
> > >   mmc: meson-gx: remove useless lock
> > >   mmc: meson-gx: align default phase on soc vendor tree
> > >   mmc: meson-gx: add signal resampling
> > I gave all four patches a go on my Khadas VIM2 Basic (16GB eMMC).
> > regardless of whether I have your patch applied or not: eMMC
> > sporadically fails tuning (if I reboot the board a few times it starts
> > to work)
> > [    4.172686] mmc1: tuning execution failed: -5
> > [    4.182535] mmc1: error -5 whilst initialising MMC card
>
> Damn ...
>
> This particular device is set to use hs400 ATM. Could you try with hs200 only
> ? (removing mmc-hs400-1_8v from meson-gxm-khadas-vim2.dts)
I put that on my TODO-list to re-try it
last year that "fixed" it for me, see [0]

> I might be wrong but I think tuning is supposed to be done with hs200, before
> activating DDR mode to switch to hs400. In theory, removing hs400 should not
> change anything (so I expect the tuning to still fail) but it is worth
> checking.
>
> >
> > I'm not sure if this issue is specific to my Khadas VIM2 so this is
> > *not* a nack for your patches.
>
> I'll check if I can get my hands on this device.
>
> When cooking this series, I tried another trick which was cycling on the
> resampling delays (see ADJUST_ADJ_DELAY_MASK). At the time, I could not see
> any significant improvement while doing it, so I dropped it.
>
> If possible. could you check if any particular value in this field, between 0
> and 5, makes things any better ?
>
> Alternatively, if you find another combination of phase for the mmc_clk and
> tx_clk that works better for this device, feel free to let me know. Maybe we
> can work something out.
I booted whatever Android / Linux is on the eMMC of my Khadas VIM2:
kvim2:/ $ dmesg | grep -i emmc
[    2.605927@2] aml_sd_emmc_probe: line 3608
[    2.609368@2] mmc driver version: 1.07, 2017-4-26: Support new emmc
host controller for version 3
[    2.618678@2] aml_sd_emmc_reg_init 1152
[    2.647411@2] get property:                  pinname, str:emmc
[    2.669798@2] emmc:pdata->caps = c0000d47
[    2.673712@2] emmc:pdata->caps2 = 18060
[    2.677509@2] emmc:pdata->pm_caps = 0
[    2.725316@2] [aml_sd_emmc_probe] aml_sd_emmc_probe() success!
[    2.725543@2] aml_sd_emmc_probe: line 3608
[    2.729971@2] aml_sd_emmc_reg_init 1152
[    2.845635@2] [aml_sd_emmc_probe] aml_sd_emmc_probe() success!
[    2.845871@2] aml_sd_emmc_probe: line 3608
[    2.850305@2] aml_sd_emmc_reg_init 1152
[    2.890367@0] emmc: BKOPS_EN bit is not set
[    2.896816@0] emmc: trying cali 0-th time(s)
[    2.903969@0] emmc: delay[0]= 1000 padding= 4, bidx=1
[    2.903971@0] emmc: delay[1]= 1000 padding= 4, bidx=1
[    2.903973@0] emmc: delay[2]=  750 padding= 1, bidx=0
[    2.903975@0] emmc: delay[3]= 1250 padding= 3, bidx=1
[    2.903977@0] emmc: delay[4]= 1250 padding= 3, bidx=1
[    2.903979@0] emmc: delay[5]= 1250 padding= 3, bidx=1
[    2.903981@0] emmc: delay[6]= 1000 padding= 4, bidx=1
[    2.903983@0] emmc: delay[7]= 1250 padding= 3, bidx=1
[    2.903985@0] emmc: calibration result @ 0: max(1250), min(750)
[    2.903988@0] emmc: line_delay =0x1000211, max_cal_result =1250
[    2.903990@0] emmc: base_index_max 1, base_index_min 0
[    2.903996@0] emmc: clk 100000000 SDR mode tuning start
[    2.904428@0] emmc: rx_tuning_result[1] = 10
[    2.904795@0] emmc: rx_tuning_result[2] = 10
[    2.905159@0] emmc: rx_tuning_result[3] = 10
[    2.905530@0] emmc: rx_tuning_result[4] = 10
[    2.905896@0] emmc: rx_tuning_result[5] = 10
[    2.906260@0] emmc: rx_tuning_result[6] = 10
[    2.906626@0] emmc: rx_tuning_result[7] = 10
[    2.906991@0] emmc: rx_tuning_result[8] = 10
[    2.907357@0] emmc: rx_tuning_result[9] = 10
[    2.907360@0] emmc: best_win_start =1, best_win_size =9
[    2.907362@0] emmc:
sd_emmc_regs->gclock=0x100024a,sd_emmc_regs->gadjust=0x52000
[    2.907365@0] emmc: gclock =0x100024a, gdelay=0x1000211, gadjust=0x52000
[    2.907506@0] emmc: support driver strength type 1
[    2.907575@0] emmc: try set sd/emmc to DDR mode
[    2.907579@0] emmc: try set sd/emmc to DDR mode
[    2.907710@0] emmc: new HS400 MMC card at address 0001
[    2.908238@1] emmc: clock 100000000, 8-bit-bus-width
[    2.908239@1] mmcblk0: emmc:0001 AJNB4R 14.5 GiB
[    2.908375@1] mmcblk0boot0: emmc:0001 AJNB4R partition 1 4.00 MiB
[    2.908504@1] mmcblk0boot1: emmc:0001 AJNB4R partition 2 4.00 MiB
[    2.908631@1] mmcblk0rpmb: emmc:0001 AJNB4R partition 3 4.00 MiB
[    2.909793@0] [aml_sd_emmc_irq] emmc: warning... response
crc,vstat:0xa1ff2400,virqc:3fff
[    2.909801@0] [aml_host_bus_fsm_show] emmc: err: wait for irq
service, bus_fsm:0x8
[    2.909801@0] [mmc_cmd_LBA_show] emmc: cmd 18, arg 0x12000,
operation is in [reserved] disk!
[    2.909819@6] aml_sd_emmc_data_thread 2642 emmc: cmd:18
[    2.909824@6] [aml_sd_emmc_data_thread] aml_sd_emmc_data_thread()
2658: set 1st retry!
[    2.909827@6] [aml_sd_emmc_data_thread] retry cmd 18 the 10-th time(s)
[    2.909829@6] [aml_sd_emmc_data_thread] cmd_delay change to 2
[    2.909840@0] [aml_sd_emmc_irq] emmc:
resp_timeout,vstat:0xa1ff2800,virqc:3fff
[    2.909858@6] aml_sd_emmc_data_thread : 2589
[    2.910078@1] add_emmc_partition
[    2.911868@0] emmc_key_init:527 emmc key lba_start:0x12020,lba_end:0x12220
[    2.911870@0] emmc key: emmc_key_init:552 ok.
[    2.916963@1] Exit aml_emmc_partition_ops OK.
[    2.919073@1] clear_emmc_wait_flag
[    3.355313@2] [aml_sd_emmc_probe] aml_sd_emmc_probe() success!
[    9.546113@4] emmc_key_read:428, read ok
[   19.016202@0] [aml_sd_emmc_irq] sdio:
resp_timeout,vstat:0xa3ff2800,virqc:3fff
[   19.028652@6] aml_sd_emmc_data_thread 2642 sdio: cmd:52
[   19.035022@0] [aml_sd_emmc_irq] sdio:
resp_timeout,vstat:0xa3ff2800,virqc:3fff
[   19.048492@6] aml_sd_emmc_data_thread 2642 sdio: cmd:52
[   19.058504@0] [aml_sd_emmc_irq] sdio:
resp_timeout,vstat:0xa3ff2800,virqc:3fff
[   19.068332@6] aml_sd_emmc_data_thread 2642 sdio: cmd:8
[   19.251397@1] sdio:
sd_emmc_regs->gclock=0x1000245,sd_emmc_regs->gadjust=0x32000
[   20.509105@4] sdio:
sd_emmc_regs->gclock=0x1000245,sd_emmc_regs->gadjust=0x32000
[   21.970494@4] sdio:
sd_emmc_regs->gclock=0x1000245,sd_emmc_regs->gadjust=0x32000

the register values of the clock, delay and adjust registers are
printed by Amlogic's 3.14 kernel - in case that helps you


Regards
Martin


[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006251.html

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic