From: Kishon Vijay Abraham I <kishon@ti.com>
To: tony@atomide.com, ulf.hansson@linaro.org, afenkart@gmail.com,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org
Cc: nsekhar@ti.com, kishon@ti.com, mugunthanvnm@ti.com
Subject: [PATCH 11/11] mmc: host: omap_hsmmc: add software timer when timeout greater than hardware capablility
Date: Thu, 30 Jul 2015 13:16:34 +0530 [thread overview]
Message-ID: <1438242394-25599-12-git-send-email-kishon@ti.com> (raw)
In-Reply-To: <1438242394-25599-1-git-send-email-kishon@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
DRA7 Errata No i834: When using high speed HS200 and SDR104
cards, the functional clock for MMC module will be 192MHz.
At this frequency, the maximum obtainable timeout (DTO =0xE)
in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
than 700ms will be affected by this small window frame and
will be timing out frequently even without a genune timeout
from the card. Workarround for this errata is use a software
timer instead of hardware timer to provide the delay requested
by the upper layer
So adding a software timer as a work around for the errata.
Instead of using software timeout only for larger delays requested
when using HS200/SDR104 cards which results in hardware and
software timer race conditions, so move all the timeout request
to use software timer when HS200/SDR104 card is connected and
use hardware timer when other type cards are connected.
Also start the software timer after queueing to DMA to ensure
we are more likely to expire within correct limits. To be ever
more sure that we won't expire this soft timer too early, we're
adding a 1000000ns slack to the data timeout requested by the
upper layer.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/mmc/host/omap_hsmmc.c | 71 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b02c7c..3a02f86 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -168,6 +168,7 @@
#define ACNE (1 << 0)
#define MMC_AUTOSUSPEND_DELAY 100
+#define MMC_SOFT_TIMER_SLACK 1000000 /* ns */
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 20000 /* 20000 micro Sec */
#define OMAP_MMC_MIN_CLOCK 400000
@@ -245,6 +246,10 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data *pdata;
+ struct timer_list timer;
+ unsigned long data_timeout;
+ unsigned int need_i834_errata:1;
+
u32 *tuning_data;
int tuning_size;
@@ -661,8 +666,8 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
irq_mask &= ~(BRR_EN | BWR_EN);
}
- /* Disable timeout for erases */
- if (cmd->opcode == MMC_ERASE)
+ /* Disable timeout for erases or when using software timeout */
+ if (cmd->opcode == MMC_ERASE || host->need_i834_errata)
irq_mask &= ~DTO_EN;
spin_lock_irqsave(&host->irq_lock, flags);
@@ -752,6 +757,22 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host->base, HCTL, regval);
}
+ /*
+ * DRA7 Errata No i834: When using high speed HS200 and SDR104
+ * cards, the functional clock for MMC module will be 192MHz.
+ * At this frequency, the maximum obtainable timeout (DTO =0xE)
+ * in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
+ * than 700ms will be affected by this small window frame and
+ * will be timing out frequently even without a genune timeout
+ * from the card. Workarround for this errata is use a software
+ * timer instead of hardware timer to provide the delay requested
+ * by the upper layer
+ */
+ if (ios->clock == 192000000)
+ host->need_i834_errata = true;
+ else
+ host->need_i834_errata = false;
+
omap_hsmmc_start_clock(host);
}
@@ -1298,6 +1319,16 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host->base, STAT);
+
+ /*
+ * During a successful bulk data transfer command-completion
+ * interrupt and transfer-completion interrupt will be generated,
+ * but software-timeout timer should be deleted only on non-CC
+ * interrupts (transfer complete or error)
+ */
+ if (host->need_i834_errata && (status & (~CC_EN)))
+ del_timer(&host->timer);
+
while (status & (INT_EN_MASK | CIRQ_EN)) {
if (host->req_in_progress)
omap_hsmmc_do_irq(host, status);
@@ -1312,6 +1343,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static void omap_hsmmc_soft_timeout(unsigned long data)
+{
+ struct omap_hsmmc_host *host = (struct omap_hsmmc_host *)data;
+
+ hsmmc_command_incomplete(host, -ETIMEDOUT, 0);
+}
+
static void set_sd_bus_power(struct omap_hsmmc_host *host)
{
unsigned long i;
@@ -1513,6 +1551,22 @@ static void set_data_timeout(struct omap_hsmmc_host *host,
if (clkd == 0)
clkd = 1;
+ if (host->need_i834_errata) {
+ unsigned long delta;
+
+ delta = (timeout_clks / (host->clk_rate / clkd));
+
+ /*
+ * We should really be using just timeout_ns + delta,
+ * however we have no control over when DMA will
+ * actually start transferring; due to that we will add
+ * an extra slack to make sure we don't expire too
+ * early.
+ */
+ host->data_timeout = timeout_ns + delta + MMC_SOFT_TIMER_SLACK;
+ return;
+ }
+
cycle_ns = 1000000000 / (host->clk_rate / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
@@ -1551,6 +1605,13 @@ static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host)
req->data->timeout_clks);
chan = omap_hsmmc_get_dma_chan(host, req->data);
dma_async_issue_pending(chan);
+
+ if (host->need_i834_errata) {
+ unsigned long timeout;
+
+ timeout = jiffies + nsecs_to_jiffies(host->data_timeout);
+ mod_timer(&host->timer, timeout);
+ }
}
/*
@@ -2415,6 +2476,8 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
spin_lock_init(&host->irq_lock);
init_completion(&host->buf_ready);
+ setup_timer(&host->timer, omap_hsmmc_soft_timeout,
+ (unsigned long)host);
host->fclk = devm_clk_get(&pdev->dev, "fck");
if (IS_ERR(host->fclk)) {
@@ -2608,6 +2671,8 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
if (host->rx_chan)
dma_release_channel(host->rx_chan);
+ del_timer_sync(&host->timer);
+
pm_runtime_put_sync(host->dev);
pm_runtime_disable(host->dev);
device_init_wakeup(&pdev->dev, false);
@@ -2640,6 +2705,8 @@ static int omap_hsmmc_suspend(struct device *dev)
if (host->dbclk)
clk_disable_unprepare(host->dbclk);
+ del_timer_sync(&host->timer);
+
pm_runtime_put_sync(host->dev);
return 0;
}
--
1.7.9.5
next prev parent reply other threads:[~2015-07-30 7:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 7:46 [PATCH 00/11] omap_hsmmc: voltage switching and tuning Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 01/11] mmc: host: omap_hsmmc: Support vmmc_aux to switch to 1.8v Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 02/11] mmc: host: omap_hsmmc: separate setting voltage capabilities from bus power Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 03/11] mmc: host: omap_hsmmc: program HCTL based on signal_voltage set by mmc core Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 04/11] mmc: host: omap_hsmmc: add voltage switch support for UHS SD card Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 05/11] mmc: host: omap_hsmmc: set clk rate to the max frequency Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 06/11] mmc: host: omap_hsmmc: set timing in the UHSMS field Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 07/11] mmc: host: omap_hsmmc: add tuning support Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 08/11] mmc: host: omap_hsmmc: Workaround for errata id i802 Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 09/11] mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd Kishon Vijay Abraham I
2015-07-30 7:46 ` [PATCH 10/11] mmc: host: omap_hsmmc: remove incorrect voltage switch sequence Kishon Vijay Abraham I
2015-07-30 7:46 ` Kishon Vijay Abraham I [this message]
2015-08-05 10:43 ` [PATCH 00/11] omap_hsmmc: voltage switching and tuning Tony Lindgren
2015-08-05 15:00 ` Kishon Vijay Abraham I
2015-08-06 6:48 ` Tony Lindgren
2015-08-07 14:45 ` Kishon Vijay Abraham I
2015-08-11 10:40 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1438242394-25599-12-git-send-email-kishon@ti.com \
--to=kishon@ti.com \
--cc=afenkart@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mugunthanvnm@ti.com \
--cc=nsekhar@ti.com \
--cc=tony@atomide.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).