* [PATCH V5 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant
@ 2019-08-13 9:59 Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature Ludovic Barre
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Ludovic Barre @ 2019-08-13 9:59 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
From: Ludovic Barre <ludovic.barre@st.com>
This patch series adds busy detect for stm32 sdmmc variant.
Some adaptations are required:
-On sdmmc the data timer is started on data transfert
and busy state, so we must add hardware busy timeout support.
-Add busy_complete callback at mmci_host_ops to allow to define
a specific busy completion by variant.
-Add sdmmc busy_complete calback.
V5:
-Replaces !cmd->data to !host->mrq->data to avoid overwrite
of datatimer register by the first command (cmd23, without data) of
SBC request.
V4:
-Re-work with busy_complete callback
-In series, move "mmc: mmci: add hardware busy timeout feature" in
first to simplify busy_complete prototype with err_msk parameter.
V3:
-rebase on latest mmc next
-replace re-read by status parameter.
V2:
-mmci_cmd_irq cleanup in separate patch.
-simplify the busy_detect_flag exclude
-replace sdmmc specific comment in
"mmc: mmci: avoid fake busy polling in mmci_irq"
to focus on common behavior
Ludovic Barre (3):
mmc: mmci: add hardware busy timeout feature
mmc: mmci: add busy_complete callback
mmc: mmci: sdmmc: add busy_complete callback
drivers/mmc/host/mmci.c | 178 +++++++++++++++++-----------
drivers/mmc/host/mmci.h | 7 +-
drivers/mmc/host/mmci_stm32_sdmmc.c | 38 ++++++
3 files changed, 151 insertions(+), 72 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
2019-08-13 9:59 [PATCH V5 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant Ludovic Barre
@ 2019-08-13 9:59 ` Ludovic Barre
2019-08-26 11:39 ` Ulf Hansson
2019-08-13 9:59 ` [PATCH V5 2/3] mmc: mmci: add busy_complete callback Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 3/3] mmc: mmci: sdmmc: " Ludovic Barre
2 siblings, 1 reply; 6+ messages in thread
From: Ludovic Barre @ 2019-08-13 9:59 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
From: Ludovic Barre <ludovic.barre@st.com>
In some variants, the data timer starts and decrements
when the DPSM enters in Wait_R or Busy state
(while data transfer or MMC_RSP_BUSY), and generates a
data timeout error if the counter reach 0.
-Define max_busy_timeout (in ms) according to clock.
-Set data timer register if the command has rsp_busy flag.
If busy_timeout is not defined by framework, the busy
length after Data Burst is defined as 1 second
(refer: 4.6.2.2 Write of sd specification part1 v6-0).
-Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
drivers/mmc/host/mmci.h | 3 +++
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index c37e70dbe250..c50586540765 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1075,6 +1075,7 @@ static void
mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
{
void __iomem *base = host->base;
+ unsigned long long clks = 0;
dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
cmd->opcode, cmd->arg, cmd->flags);
@@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
else
c |= host->variant->cmdreg_srsp;
}
+
+ if (host->variant->busy_timeout && !host->mrq->data) {
+ if (cmd->flags & MMC_RSP_BUSY) {
+ if (!cmd->busy_timeout)
+ cmd->busy_timeout = 1000;
+
+ clks = (unsigned long long)cmd->busy_timeout;
+ clks *= host->cclk;
+ do_div(clks, MSEC_PER_SEC);
+ }
+ writel_relaxed(clks, host->base + MMCIDATATIMER);
+ }
+
if (/*interrupt*/0)
c |= MCI_CPSM_INTERRUPT;
@@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
{
void __iomem *base = host->base;
bool sbc, busy_resp;
+ u32 err_msk;
if (!cmd)
return;
@@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
* handling. Note that we tag on any latent IRQs postponed
* due to waiting for busy status.
*/
- if (!((status|host->busy_status) &
- (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
+ err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
+ if (host->variant->busy_timeout && busy_resp)
+ err_msk |= MCI_DATATIMEOUT;
+
+ if (!((status | host->busy_status) &
+ (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
return;
/* Handle busy detection on DAT0 if the variant supports it. */
@@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
* while, to allow it to be set, but tests indicates that it
* isn't needed.
*/
- if (!host->busy_status &&
- !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
+ if (!host->busy_status && !(status & err_msk) &&
(readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
writel(readl(base + MMCIMASK0) |
@@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
cmd->error = -ETIMEDOUT;
} else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
cmd->error = -EILSEQ;
+ } else if (host->variant->busy_timeout && busy_resp &&
+ status & MCI_DATATIMEOUT) {
+ cmd->error = -ETIMEDOUT;
} else {
cmd->resp[0] = readl(base + MMCIRESPONSE0);
cmd->resp[1] = readl(base + MMCIRESPONSE1);
@@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
* Enable busy detection.
*/
if (variant->busy_detect) {
+ u32 max_busy_timeout = 0;
+
mmci_ops.card_busy = mmci_card_busy;
/*
* Not all variants have a flag to enable busy detection
@@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
mmci_write_datactrlreg(host,
host->variant->busy_dpsm_flag);
mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
- mmc->max_busy_timeout = 0;
+
+ if (variant->busy_timeout)
+ max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
+
+ mmc->max_busy_timeout = max_busy_timeout;
}
/* Prepare a CMD12 - needed to clear the DPSM on some variants. */
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 833236ecb31e..d8b7f6774e8f 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -287,6 +287,8 @@ struct mmci_host;
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
* @busy_detect: true if the variant supports busy detection on DAT0.
+ * @busy_timeout: true if the variant starts data timer when the DPSM
+ * enter in Wait_R or Busy state.
* @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
* @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
* indicating that the card is busy
@@ -333,6 +335,7 @@ struct variant_data {
u8 signal_direction:1;
u8 pwrreg_clkgate:1;
u8 busy_detect:1;
+ u8 busy_timeout:1;
u32 busy_dpsm_flag;
u32 busy_detect_flag;
u32 busy_detect_mask;
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH V5 2/3] mmc: mmci: add busy_complete callback
2019-08-13 9:59 [PATCH V5 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature Ludovic Barre
@ 2019-08-13 9:59 ` Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 3/3] mmc: mmci: sdmmc: " Ludovic Barre
2 siblings, 0 replies; 6+ messages in thread
From: Ludovic Barre @ 2019-08-13 9:59 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds busy_completion callback at mmci_host_ops
to allow to define a specific busy completion by variant.
The legacy code corresponding to busy completion used
by ux500 variants is moved to ux500_busy_complete function.
The busy_detect boolean property is replaced by
busy_complete callback definition.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 140 +++++++++++++++++++++-------------------
drivers/mmc/host/mmci.h | 3 +-
2 files changed, 75 insertions(+), 68 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index c50586540765..9eac3f482119 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -44,6 +44,7 @@
#define DRIVER_NAME "mmci-pl18x"
static void mmci_variant_init(struct mmci_host *host);
+static void ux500_variant_init(struct mmci_host *host);
static void ux500v2_variant_init(struct mmci_host *host);
static unsigned int fmax = 515633;
@@ -175,7 +176,6 @@ static struct variant_data variant_ux500 = {
.f_max = 100000000,
.signal_direction = true,
.pwrreg_clkgate = true,
- .busy_detect = true,
.busy_dpsm_flag = MCI_DPSM_ST_BUSYMODE,
.busy_detect_flag = MCI_ST_CARDBUSY,
.busy_detect_mask = MCI_ST_BUSYENDMASK,
@@ -184,7 +184,7 @@ static struct variant_data variant_ux500 = {
.irq_pio_mask = MCI_IRQ_PIO_MASK,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_OD,
- .init = mmci_variant_init,
+ .init = ux500_variant_init,
};
static struct variant_data variant_ux500v2 = {
@@ -208,7 +208,6 @@ static struct variant_data variant_ux500v2 = {
.f_max = 100000000,
.signal_direction = true,
.pwrreg_clkgate = true,
- .busy_detect = true,
.busy_dpsm_flag = MCI_DPSM_ST_BUSYMODE,
.busy_detect_flag = MCI_ST_CARDBUSY,
.busy_detect_mask = MCI_ST_BUSYENDMASK,
@@ -610,6 +609,67 @@ static u32 ux500v2_get_dctrl_cfg(struct mmci_host *host)
return MCI_DPSM_ENABLE | (host->data->blksz << 16);
}
+static bool ux500_busy_complete(struct mmci_host *host, u32 status, u32 err_msk)
+{
+ void __iomem *base = host->base;
+
+ /*
+ * Before unmasking for the busy end IRQ, confirm that the
+ * command was sent successfully. To keep track of having a
+ * command in-progress, waiting for busy signaling to end,
+ * store the status in host->busy_status.
+ *
+ * Note that, the card may need a couple of clock cycles before
+ * it starts signaling busy on DAT0, hence re-read the
+ * MMCISTATUS register here, to allow the busy bit to be set.
+ * Potentially we may even need to poll the register for a
+ * while, to allow it to be set, but tests indicates that it
+ * isn't needed.
+ */
+ if (!host->busy_status && !(status & err_msk) &&
+ (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
+ writel(readl(base + MMCIMASK0) |
+ host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+
+ host->busy_status = status & (MCI_CMDSENT | MCI_CMDRESPEND);
+ return false;
+ }
+
+ /*
+ * If there is a command in-progress that has been successfully
+ * sent, then bail out if busy status is set and wait for the
+ * busy end IRQ.
+ *
+ * Note that, the HW triggers an IRQ on both edges while
+ * monitoring DAT0 for busy completion, but there is only one
+ * status bit in MMCISTATUS for the busy state. Therefore
+ * both the start and the end interrupts needs to be cleared,
+ * one after the other. So, clear the busy start IRQ here.
+ */
+ if (host->busy_status &&
+ (status & host->variant->busy_detect_flag)) {
+ writel(host->variant->busy_detect_mask, base + MMCICLEAR);
+ return false;
+ }
+
+ /*
+ * If there is a command in-progress that has been successfully
+ * sent and the busy bit isn't set, it means we have received
+ * the busy end IRQ. Clear and mask the IRQ, then continue to
+ * process the command.
+ */
+ if (host->busy_status) {
+ writel(host->variant->busy_detect_mask, base + MMCICLEAR);
+
+ writel(readl(base + MMCIMASK0) &
+ ~host->variant->busy_detect_mask, base + MMCIMASK0);
+ host->busy_status = 0;
+ }
+
+ return true;
+}
+
/*
* All the DMA operation mode stuff goes inside this ifdef.
* This assumes that you have a generic DMA device interface,
@@ -953,9 +1013,16 @@ void mmci_variant_init(struct mmci_host *host)
host->ops = &mmci_variant_ops;
}
+void ux500_variant_init(struct mmci_host *host)
+{
+ host->ops = &mmci_variant_ops;
+ host->ops->busy_complete = ux500_busy_complete;
+}
+
void ux500v2_variant_init(struct mmci_host *host)
{
host->ops = &mmci_variant_ops;
+ host->ops->busy_complete = ux500_busy_complete;
host->ops->get_datactrl_cfg = ux500v2_get_dctrl_cfg;
}
@@ -1239,68 +1306,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
return;
/* Handle busy detection on DAT0 if the variant supports it. */
- if (busy_resp && host->variant->busy_detect) {
-
- /*
- * Before unmasking for the busy end IRQ, confirm that the
- * command was sent successfully. To keep track of having a
- * command in-progress, waiting for busy signaling to end,
- * store the status in host->busy_status.
- *
- * Note that, the card may need a couple of clock cycles before
- * it starts signaling busy on DAT0, hence re-read the
- * MMCISTATUS register here, to allow the busy bit to be set.
- * Potentially we may even need to poll the register for a
- * while, to allow it to be set, but tests indicates that it
- * isn't needed.
- */
- if (!host->busy_status && !(status & err_msk) &&
- (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
-
- writel(readl(base + MMCIMASK0) |
- host->variant->busy_detect_mask,
- base + MMCIMASK0);
-
- host->busy_status =
- status & (MCI_CMDSENT|MCI_CMDRESPEND);
- return;
- }
-
- /*
- * If there is a command in-progress that has been successfully
- * sent, then bail out if busy status is set and wait for the
- * busy end IRQ.
- *
- * Note that, the HW triggers an IRQ on both edges while
- * monitoring DAT0 for busy completion, but there is only one
- * status bit in MMCISTATUS for the busy state. Therefore
- * both the start and the end interrupts needs to be cleared,
- * one after the other. So, clear the busy start IRQ here.
- */
- if (host->busy_status &&
- (status & host->variant->busy_detect_flag)) {
- writel(host->variant->busy_detect_mask,
- host->base + MMCICLEAR);
+ if (busy_resp && host->ops->busy_complete)
+ if (!host->ops->busy_complete(host, status, err_msk))
return;
- }
-
- /*
- * If there is a command in-progress that has been successfully
- * sent and the busy bit isn't set, it means we have received
- * the busy end IRQ. Clear and mask the IRQ, then continue to
- * process the command.
- */
- if (host->busy_status) {
-
- writel(host->variant->busy_detect_mask,
- host->base + MMCICLEAR);
-
- writel(readl(base + MMCIMASK0) &
- ~host->variant->busy_detect_mask,
- base + MMCIMASK0);
- host->busy_status = 0;
- }
- }
host->cmd = NULL;
@@ -1541,7 +1549,7 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
* clear the corresponding IRQ.
*/
status &= readl(host->base + MMCIMASK0);
- if (host->variant->busy_detect)
+ if (host->ops->busy_complete)
writel(status & ~host->variant->busy_detect_mask,
host->base + MMCICLEAR);
else
@@ -1968,7 +1976,7 @@ static int mmci_probe(struct amba_device *dev,
/*
* Enable busy detection.
*/
- if (variant->busy_detect) {
+ if (host->ops->busy_complete) {
u32 max_busy_timeout = 0;
mmci_ops.card_busy = mmci_card_busy;
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index d8b7f6774e8f..733f9a035b06 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -286,7 +286,6 @@ struct mmci_host;
* @f_max: maximum clk frequency supported by the controller.
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
- * @busy_detect: true if the variant supports busy detection on DAT0.
* @busy_timeout: true if the variant starts data timer when the DPSM
* enter in Wait_R or Busy state.
* @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
@@ -334,7 +333,6 @@ struct variant_data {
u32 f_max;
u8 signal_direction:1;
u8 pwrreg_clkgate:1;
- u8 busy_detect:1;
u8 busy_timeout:1;
u32 busy_dpsm_flag;
u32 busy_detect_flag;
@@ -369,6 +367,7 @@ struct mmci_host_ops {
void (*dma_error)(struct mmci_host *host);
void (*set_clkreg)(struct mmci_host *host, unsigned int desired);
void (*set_pwrreg)(struct mmci_host *host, unsigned int pwr);
+ bool (*busy_complete)(struct mmci_host *host, u32 status, u32 err_msk);
};
struct mmci_host {
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH V5 3/3] mmc: mmci: sdmmc: add busy_complete callback
2019-08-13 9:59 [PATCH V5 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 2/3] mmc: mmci: add busy_complete callback Ludovic Barre
@ 2019-08-13 9:59 ` Ludovic Barre
2 siblings, 0 replies; 6+ messages in thread
From: Ludovic Barre @ 2019-08-13 9:59 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds a specific busy_complete callback for sdmmc variant.
sdmmc has 2 status flags:
-busyd0: This is a hardware status flag (inverted value of d0 line).
it does not generate an interrupt.
-busyd0end: This indicates only end of busy following a CMD response.
On busy to Not busy changes, an interrupt is generated (if unmask)
and BUSYD0END status flag is set. Status flag is cleared by writing
corresponding interrupt clear bit in MMCICLEAR.
The legacy busy completion monitors step by step the busy progression
start/in-progress/end. On sdmmc variant, the monitoring of busy steps
is difficult and not adapted (the software can miss a step and locks
the monitoring), the sdmmc has just need to wait the busyd0end bit
without monitoring all the changes.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 3 +++
drivers/mmc/host/mmci.h | 1 +
drivers/mmc/host/mmci_stm32_sdmmc.c | 38 +++++++++++++++++++++++++++++
3 files changed, 42 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 9eac3f482119..9bec82d2dbf7 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -260,6 +260,9 @@ static struct variant_data variant_stm32_sdmmc = {
.datalength_bits = 25,
.datactrl_blocksz = 14,
.stm32_idmabsize_mask = GENMASK(12, 5),
+ .busy_timeout = true,
+ .busy_detect_flag = MCI_STM32_BUSYD0,
+ .busy_detect_mask = MCI_STM32_BUSYD0ENDMASK,
.init = sdmmc_variant_init,
};
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 733f9a035b06..841c5281beb5 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -164,6 +164,7 @@
#define MCI_ST_CARDBUSY (1 << 24)
/* Extended status bits for the STM32 variants */
#define MCI_STM32_BUSYD0 BIT(20)
+#define MCI_STM32_BUSYD0END BIT(21)
#define MMCICLEAR 0x038
#define MCI_CMDCRCFAILCLR (1 << 0)
diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
index 8e83ae6920ae..bb5499cc9e81 100644
--- a/drivers/mmc/host/mmci_stm32_sdmmc.c
+++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
@@ -282,6 +282,43 @@ static u32 sdmmc_get_dctrl_cfg(struct mmci_host *host)
return datactrl;
}
+bool sdmmc_busy_complete(struct mmci_host *host, u32 status, u32 err_msk)
+{
+ void __iomem *base = host->base;
+ u32 busy_d0, busy_d0end, mask;
+
+ mask = readl_relaxed(base + MMCIMASK0);
+ busy_d0end = readl_relaxed(base + MMCISTATUS) & MCI_STM32_BUSYD0END;
+ busy_d0 = readl_relaxed(base + MMCISTATUS) & MCI_STM32_BUSYD0;
+
+ /* complete if there is an error or busy_d0end */
+ if ((status & err_msk) || busy_d0end)
+ goto complete;
+
+ /*
+ * On response the busy signaling is reflected in the BUSYD0 flag.
+ * if busy_d0 is in-progress we must activate busyd0end interrupt
+ * to wait this completion. Else this request has no busy step.
+ */
+ if (busy_d0) {
+ if (!host->busy_status) {
+ writel_relaxed(mask | host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+ host->busy_status = status &
+ (MCI_CMDSENT | MCI_CMDRESPEND);
+ }
+ return false;
+ }
+
+complete:
+ writel_relaxed(mask & ~host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+ writel_relaxed(host->variant->busy_detect_mask, base + MMCICLEAR);
+ host->busy_status = 0;
+
+ return true;
+}
+
static struct mmci_host_ops sdmmc_variant_ops = {
.validate_data = sdmmc_idma_validate_data,
.prep_data = sdmmc_idma_prep_data,
@@ -292,6 +329,7 @@ static struct mmci_host_ops sdmmc_variant_ops = {
.dma_finalize = sdmmc_idma_finalize,
.set_clkreg = mmci_sdmmc_set_clkreg,
.set_pwrreg = mmci_sdmmc_set_pwrreg,
+ .busy_complete = sdmmc_busy_complete,
};
void sdmmc_variant_init(struct mmci_host *host)
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
2019-08-13 9:59 ` [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature Ludovic Barre
@ 2019-08-26 11:39 ` Ulf Hansson
2019-09-04 15:04 ` Ludovic BARRE
0 siblings, 1 reply; 6+ messages in thread
From: Ulf Hansson @ 2019-08-26 11:39 UTC (permalink / raw)
To: Ludovic Barre
Cc: Rob Herring, Srinivas Kandagatla, Maxime Coquelin,
Alexandre Torgue, Linux ARM, Linux Kernel Mailing List, DTML,
linux-mmc, linux-stm32
On Tue, 13 Aug 2019 at 12:00, Ludovic Barre <ludovic.Barre@st.com> wrote:
>
> From: Ludovic Barre <ludovic.barre@st.com>
>
> In some variants, the data timer starts and decrements
> when the DPSM enters in Wait_R or Busy state
> (while data transfer or MMC_RSP_BUSY), and generates a
> data timeout error if the counter reach 0.
I don't quite follow here, sorry. Can you please try to elaborate on
the use case(s) more exactly?
For example, what happens when a data transfer has just finished (for
example when MCI_DATAEND has been received) and we are going to send a
CMD12 to stop it? In this case the CMD12 has the MMC_RSP_BUSY flag
set.
Another example is the CMD5, which has no data with it.
>
> -Define max_busy_timeout (in ms) according to clock.
> -Set data timer register if the command has rsp_busy flag.
> If busy_timeout is not defined by framework, the busy
> length after Data Burst is defined as 1 second
> (refer: 4.6.2.2 Write of sd specification part1 v6-0).
One second is not sufficient for all operations, like ERASE for
example. However, I understand that you want to pick some value, as a
safety. I guess that's fine.
I am thinking that if the command has the MMC_RSP_BUSY flag set, the
core should really provide a busy timeout for it. That said, maybe the
host driver should splat a WARN in case there is not busy timeout
specified.
> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> ---
> drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
> drivers/mmc/host/mmci.h | 3 +++
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c37e70dbe250..c50586540765 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1075,6 +1075,7 @@ static void
> mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> {
> void __iomem *base = host->base;
> + unsigned long long clks = 0;
>
> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
> cmd->opcode, cmd->arg, cmd->flags);
> @@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> else
> c |= host->variant->cmdreg_srsp;
> }
> +
> + if (host->variant->busy_timeout && !host->mrq->data) {
Suppose this is a CMD12 command, having the MMC_RSP_BUSY flag set. The
command would then be sent to stop the transmission and then
host->mrq->data would also be set.
If I recall earlier what you stated about the new sdmmc variant, the
CMD12 is needed to exit the DPSM. Hence don't you need to re-program a
new value for the MMCIDATATIMER register for this scenario?
> + if (cmd->flags & MMC_RSP_BUSY) {
> + if (!cmd->busy_timeout)
> + cmd->busy_timeout = 1000;
> +
> + clks = (unsigned long long)cmd->busy_timeout;
> + clks *= host->cclk;
Any problems with putting the above on one line?
> + do_div(clks, MSEC_PER_SEC);
> + }
> + writel_relaxed(clks, host->base + MMCIDATATIMER);
This is writing zero to MMCIDATATIMER in case the MMC_RSP_BUSY isn't
set, is that on purpose?
> + }
> +
> if (/*interrupt*/0)
> c |= MCI_CPSM_INTERRUPT;
>
> @@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> {
> void __iomem *base = host->base;
> bool sbc, busy_resp;
> + u32 err_msk;
>
> if (!cmd)
> return;
> @@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> * handling. Note that we tag on any latent IRQs postponed
> * due to waiting for busy status.
> */
> - if (!((status|host->busy_status) &
> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
> + err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
You might as well move the initial assignment of err_msk to the its
declaration above.
> + if (host->variant->busy_timeout && busy_resp)
> + err_msk |= MCI_DATATIMEOUT;
> +
> + if (!((status | host->busy_status) &
> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
> return;
>
> /* Handle busy detection on DAT0 if the variant supports it. */
> @@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> * while, to allow it to be set, but tests indicates that it
> * isn't needed.
> */
> - if (!host->busy_status &&
> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> + if (!host->busy_status && !(status & err_msk) &&
> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
>
> writel(readl(base + MMCIMASK0) |
> @@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> cmd->error = -ETIMEDOUT;
> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
> cmd->error = -EILSEQ;
> + } else if (host->variant->busy_timeout && busy_resp &&
> + status & MCI_DATATIMEOUT) {
> + cmd->error = -ETIMEDOUT;
> } else {
> cmd->resp[0] = readl(base + MMCIRESPONSE0);
> cmd->resp[1] = readl(base + MMCIRESPONSE1);
> @@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
> * Enable busy detection.
> */
> if (variant->busy_detect) {
> + u32 max_busy_timeout = 0;
> +
> mmci_ops.card_busy = mmci_card_busy;
> /*
> * Not all variants have a flag to enable busy detection
> @@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
> mmci_write_datactrlreg(host,
> host->variant->busy_dpsm_flag);
> mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
> - mmc->max_busy_timeout = 0;
> +
> + if (variant->busy_timeout)
> + max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
It looks like the max busy timeout is depending on the current picked
clock rate, right?
In such case, perhaps it's better to update mmc->max_busy_timeout as
part of the ->set_ios() callback, as it's from there the clock rate
gets updated. Or what do you think?
> +
> + mmc->max_busy_timeout = max_busy_timeout;
> }
>
> /* Prepare a CMD12 - needed to clear the DPSM on some variants. */
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index 833236ecb31e..d8b7f6774e8f 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -287,6 +287,8 @@ struct mmci_host;
> * @signal_direction: input/out direction of bus signals can be indicated
> * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
> * @busy_detect: true if the variant supports busy detection on DAT0.
> + * @busy_timeout: true if the variant starts data timer when the DPSM
> + * enter in Wait_R or Busy state.
> * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
> * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
> * indicating that the card is busy
> @@ -333,6 +335,7 @@ struct variant_data {
> u8 signal_direction:1;
> u8 pwrreg_clkgate:1;
> u8 busy_detect:1;
> + u8 busy_timeout:1;
> u32 busy_dpsm_flag;
> u32 busy_detect_flag;
> u32 busy_detect_mask;
> --
> 2.17.1
>
Kind regards
Uffe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
2019-08-26 11:39 ` Ulf Hansson
@ 2019-09-04 15:04 ` Ludovic BARRE
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic BARRE @ 2019-09-04 15:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Srinivas Kandagatla, Maxime Coquelin,
Alexandre Torgue, Linux ARM, Linux Kernel Mailing List, DTML,
linux-mmc, linux-stm32
hi Ulf
On 8/26/19 1:39 PM, Ulf Hansson wrote:
> On Tue, 13 Aug 2019 at 12:00, Ludovic Barre <ludovic.Barre@st.com> wrote:
>>
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> In some variants, the data timer starts and decrements
>> when the DPSM enters in Wait_R or Busy state
>> (while data transfer or MMC_RSP_BUSY), and generates a
>> data timeout error if the counter reach 0.
>
> I don't quite follow here, sorry. Can you please try to elaborate on
> the use case(s) more exactly?
>
> For example, what happens when a data transfer has just finished (for
> example when MCI_DATAEND has been received) and we are going to send a
> CMD12 to stop it? In this case the CMD12 has the MMC_RSP_BUSY flag
> set.
>
example with cmd25 (write multi block)
mmci_request
- mmci_start_data
set MMCIDATATIMER, MMCIDATALENGTH, MMCIMASK0
- mmci_start_command:
set MMCIARGUMENT, MMCICOMMAND (cmd25)
mmci_irq:
- irq MCI_CMDRESPEND
- irq MCI_DATAEND
- send cmd12 => mmci_start_command(host->stop_abort or data->stop)
these cmds have flag rsp_busy and no data associate
host->cmd = cmd (host->stop_abort or data->stop) for next irq
mmci_irq:
- irq MCI_CMDRESPEND
- irq BUSYD0END
- mmci_request_end
> Another example is the CMD5, which has no data with it.
>
>>
>> -Define max_busy_timeout (in ms) according to clock.
>> -Set data timer register if the command has rsp_busy flag.
>> If busy_timeout is not defined by framework, the busy
>> length after Data Burst is defined as 1 second
>> (refer: 4.6.2.2 Write of sd specification part1 v6-0).
>
> One second is not sufficient for all operations, like ERASE for
> example. However, I understand that you want to pick some value, as a
> safety. I guess that's fine.
>
> I am thinking that if the command has the MMC_RSP_BUSY flag set, the
> core should really provide a busy timeout for it. That said, maybe the
> host driver should splat a WARN in case there is not busy timeout
> specified.
Today, I just see a busy_timeout not defined on write request.
On erase request, the timeout is defined in function mmc_do_erase.
In core, there are several paths to done a write request, and I not
be sure to fix all. For safety, I preferred fix with the max value of
write request.
>
>> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>> ---
>> drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
>> drivers/mmc/host/mmci.h | 3 +++
>> 2 files changed, 35 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index c37e70dbe250..c50586540765 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -1075,6 +1075,7 @@ static void
>> mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>> {
>> void __iomem *base = host->base;
>> + unsigned long long clks = 0;
>>
>> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
>> cmd->opcode, cmd->arg, cmd->flags);
>> @@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>> else
>> c |= host->variant->cmdreg_srsp;
>> }
>> +
>> + if (host->variant->busy_timeout && !host->mrq->data) {
>
> Suppose this is a CMD12 command, having the MMC_RSP_BUSY flag set. The
> command would then be sent to stop the transmission and then
> host->mrq->data would also be set.
Sorry, it's a mistake introduce by v5.
I would keep the clear of datatimer when is not needed
(no data & no rsp busy, see below). But on cmd23 (set_block_count) with
datactrl_first variant property the datatimer should be protected.
To simplify and fix the code, I will remove the clear of datatimer
when there is no data & no rsp busy.
- if (host->variant->busy_timeout && !host->mrq->data) {
+ if (host->variant->busy_timeout && !cmd->flags & MMC_RSP_BUSY) {
+ ....
+ writel_relaxed(clks, host->base + MMCIDATATIMER);
+ }
>
> If I recall earlier what you stated about the new sdmmc variant, the
> CMD12 is needed to exit the DPSM. Hence don't you need to re-program a
> new value for the MMCIDATATIMER register for this scenario?
>
>> + if (cmd->flags & MMC_RSP_BUSY) {
>> + if (!cmd->busy_timeout)
>> + cmd->busy_timeout = 1000;
>> +
>> + clks = (unsigned long long)cmd->busy_timeout;
>> + clks *= host->cclk;
>
> Any problems with putting the above on one line?
No, it was just to not exceed 80 characters.
>
>> + do_div(clks, MSEC_PER_SEC);
>> + }
>> + writel_relaxed(clks, host->base + MMCIDATATIMER);
>
> This is writing zero to MMCIDATATIMER in case the MMC_RSP_BUSY isn't
> set, is that on purpose?
It was to clear the datatimer when the command has
no data & no rsp_busy. This allowed to look if the datatimer
was used and not correctly set with the right value (with datatimeout).
Like said above, I will remove this and set datatimer only
on rsp_busy flag.
>
>> + }
>> +
>> if (/*interrupt*/0)
>> c |= MCI_CPSM_INTERRUPT;
>>
>> @@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> {
>> void __iomem *base = host->base;
>> bool sbc, busy_resp;
>> + u32 err_msk;
>>
>> if (!cmd)
>> return;
>> @@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> * handling. Note that we tag on any latent IRQs postponed
>> * due to waiting for busy status.
>> */
>> - if (!((status|host->busy_status) &
>> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
>> + err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
>
> You might as well move the initial assignment of err_msk to the its
> declaration above.
>
OK, thx
>> + if (host->variant->busy_timeout && busy_resp)
>> + err_msk |= MCI_DATATIMEOUT;
>> +
>> + if (!((status | host->busy_status) &
>> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
>> return;
>>
>> /* Handle busy detection on DAT0 if the variant supports it. */
>> @@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> * while, to allow it to be set, but tests indicates that it
>> * isn't needed.
>> */
>> - if (!host->busy_status &&
>> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
>> + if (!host->busy_status && !(status & err_msk) &&
>> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
>>
>> writel(readl(base + MMCIMASK0) |
>> @@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> cmd->error = -ETIMEDOUT;
>> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
>> cmd->error = -EILSEQ;
>> + } else if (host->variant->busy_timeout && busy_resp &&
>> + status & MCI_DATATIMEOUT) {
>> + cmd->error = -ETIMEDOUT;
>> } else {
>> cmd->resp[0] = readl(base + MMCIRESPONSE0);
>> cmd->resp[1] = readl(base + MMCIRESPONSE1);
>> @@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
>> * Enable busy detection.
>> */
>> if (variant->busy_detect) {
>> + u32 max_busy_timeout = 0;
>> +
>> mmci_ops.card_busy = mmci_card_busy;
>> /*
>> * Not all variants have a flag to enable busy detection
>> @@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
>> mmci_write_datactrlreg(host,
>> host->variant->busy_dpsm_flag);
>> mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
>> - mmc->max_busy_timeout = 0;
>> +
>> + if (variant->busy_timeout)
>> + max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
>
> It looks like the max busy timeout is depending on the current picked
> clock rate, right?
>
> In such case, perhaps it's better to update mmc->max_busy_timeout as
> part of the ->set_ios() callback, as it's from there the clock rate
> gets updated. Or what do you think?
yes, it's possible
>
>> +
>> + mmc->max_busy_timeout = max_busy_timeout;
>> }
>>
>> /* Prepare a CMD12 - needed to clear the DPSM on some variants. */
>> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
>> index 833236ecb31e..d8b7f6774e8f 100644
>> --- a/drivers/mmc/host/mmci.h
>> +++ b/drivers/mmc/host/mmci.h
>> @@ -287,6 +287,8 @@ struct mmci_host;
>> * @signal_direction: input/out direction of bus signals can be indicated
>> * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
>> * @busy_detect: true if the variant supports busy detection on DAT0.
>> + * @busy_timeout: true if the variant starts data timer when the DPSM
>> + * enter in Wait_R or Busy state.
>> * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
>> * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
>> * indicating that the card is busy
>> @@ -333,6 +335,7 @@ struct variant_data {
>> u8 signal_direction:1;
>> u8 pwrreg_clkgate:1;
>> u8 busy_detect:1;
>> + u8 busy_timeout:1;
>> u32 busy_dpsm_flag;
>> u32 busy_detect_flag;
>> u32 busy_detect_mask;
>> --
>> 2.17.1
>>
>
> Kind regards
> Uffe
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-04 15:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-13 9:59 [PATCH V5 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature Ludovic Barre
2019-08-26 11:39 ` Ulf Hansson
2019-09-04 15:04 ` Ludovic BARRE
2019-08-13 9:59 ` [PATCH V5 2/3] mmc: mmci: add busy_complete callback Ludovic Barre
2019-08-13 9:59 ` [PATCH V5 3/3] mmc: mmci: sdmmc: " Ludovic Barre
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).