在 2015/7/29 3:22, Arend van Spriel 写道:
On 07/21/2015 02:15 PM, Ulf Hansson wrote:
On 10 July 2015 at 17:14, Hans de Goede <hdego...@redhat.com> wrote:
Some sdio wifi modules have not been working reliable with the sunxi-mmc
host code. This turns out to be caused by it starting new commands while
the card signals that it is still busy processing a previous command.
Which are those commands? Or more interesting, which response types do
these commands expect?
I don't think this is a sunxi specific issue, I have seen similar
issues for other host controllers.
Indeed. A similar fix was needed for dw_mmc host controller.
bit 10 in STATUS register of sysnopsys dw_mmc should be issued each time
you start a new cmd. It's hard to say whetehr a local hack or not,
because it's a mandatory requirement from IP databook(refer to
"Sysnopsys DesignWare cores Mobile Storage Host Databook" Chapter 7-
Programming the DWC_mobile_storage).
Bit 10: indicate state-machine is ready, controller MUST guarantee all
I/O used in "free state", actually high.
If dw_mmc's state-machine isn't ready, NO cmd can be issued, which means
even we configure cmd and cmdarg, start bit cannot be auto-clean by
controller that leads to no cmd_done interrupt generated which dw_mmc's
tasklet state-machine need.
I am thinking that perhaps this should be managed by the mmc core
instead of local hacks to sunxi. Potentially we could make the core to
invoke the already existing host_ops->card_busy() callback when
needed...
The problem here is that there are a number of host controllers out
there not implementing that callback. That may be because the hardware
is dealing properly with busy signalling, but I would not bet on that.
Regards,
Arend
Within this context, could I ask whether you controller supports IRQ
based HW-busy detection? Or you need polling of the status register?
This commit fixes this, thereby fixing the wifi reliability issues on
the Cubietruck and other sunxi boards using sdio wifi.
Reported-by: Eugene K <sigintmai...@gmail.com>
Suggested-by: Eugene K <sigintmai...@gmail.com>
Cc: Eugene K <sigintmai...@gmail.com>
Cc: Arend van Spriel <ar...@broadcom.com>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
Changes in v2:
-Properly accredit Eugene K for coming up with the fix for this
---
drivers/mmc/host/sunxi-mmc.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..daa90b7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -289,6 +289,24 @@ static int sunxi_mmc_init_host(struct mmc_host
*mmc)
return 0;
}
+/* Wait for card to report ready before starting a new cmd */
+static int sunxi_mmc_wait_card_ready(struct sunxi_mmc_host *host)
+{
+ unsigned long expire = jiffies + msecs_to_jiffies(500);
+ u32 rval;
+
+ do {
+ rval = mmc_readl(host, REG_STAS);
+ } while (time_before(jiffies, expire) && (rval &
SDXC_CARD_DATA_BUSY));
+
+ if (rval & SDXC_CARD_DATA_BUSY) {
+ dev_err(mmc_dev(host->mmc), "Error R1 ready timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static void sunxi_mmc_init_idma_des(struct sunxi_mmc_host *host,
struct mmc_data *data)
{
@@ -383,6 +401,8 @@ static void sunxi_mmc_send_manual_stop(struct
sunxi_mmc_host *host,
u32 arg, cmd_val, ri;
unsigned long expire = jiffies + msecs_to_jiffies(1000);
+ sunxi_mmc_wait_card_ready(host);
+
cmd_val = SDXC_START | SDXC_RESP_EXPIRE |
SDXC_STOP_ABORT_CMD | SDXC_CHECK_RESPONSE_CRC;
@@ -597,6 +617,11 @@ static int sunxi_mmc_oclk_onoff(struct
sunxi_mmc_host *host, u32 oclk_en)
{
unsigned long expire = jiffies + msecs_to_jiffies(250);
u32 rval;
+ int ret;
+
+ ret = sunxi_mmc_wait_card_ready(host);
+ if (ret)
+ return ret;
rval = mmc_readl(host, REG_CLKCR);
rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
@@ -785,6 +810,13 @@ static void sunxi_mmc_request(struct mmc_host
*mmc, struct mmc_request *mrq)
return;
}
+ ret = sunxi_mmc_wait_card_ready(host);
+ if (ret) {
+ mrq->cmd->error = ret;
+ mmc_request_done(mmc, mrq);
+ return;
+ }
+
if (data) {
ret = sunxi_mmc_map_dma(host, data);
if (ret < 0) {
--
2.4.3
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shawn Lin
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
