| Message ID | 1436541284-11800-1-git-send-email-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Fri, Jul 10, 2015 at 05:14:44PM +0200, Hans de Goede 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. > > This commit fixes this, thereby fixing the wifi reliability issues on > the Cubietruck and other sunxi boards using sdio wifi. > > Reported-by: Eugene K <sigintmailru@gmail.com> > Suggested-by: Eugene K <sigintmailru@gmail.com> > Cc: Eugene K <sigintmailru@gmail.com> You should use the "real" name here, and not some shortening. Maxime
Hi, On 20-07-15 10:00, Maxime Ripard wrote: > Hi, > > On Fri, Jul 10, 2015 at 05:14:44PM +0200, Hans de Goede 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. >> >> This commit fixes this, thereby fixing the wifi reliability issues on >> the Cubietruck and other sunxi boards using sdio wifi. >> >> Reported-by: Eugene K <sigintmailru@gmail.com> >> Suggested-by: Eugene K <sigintmailru@gmail.com> >> Cc: Eugene K <sigintmailru@gmail.com> > > You should use the "real" name here, and not some shortening. I don't know the real name, and AFAIK this is really only important for S-o-b lines. Eugene, care to share your full name with us? Regards, Hans -- 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
On 10 July 2015 at 17:14, Hans de Goede <hdegoede@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. 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... 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 <sigintmailru@gmail.com> > Suggested-by: Eugene K <sigintmailru@gmail.com> > Cc: Eugene K <sigintmailru@gmail.com> > Cc: Arend van Spriel <arend@broadcom.com> > Signed-off-by: Hans de Goede <hdegoede@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 20, 2015 at 05:23:36PM +0200, Hans de Goede wrote: > Hi, > > On 20-07-15 10:00, Maxime Ripard wrote: > >Hi, > > > >On Fri, Jul 10, 2015 at 05:14:44PM +0200, Hans de Goede 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. > >> > >>This commit fixes this, thereby fixing the wifi reliability issues on > >>the Cubietruck and other sunxi boards using sdio wifi. > >> > >>Reported-by: Eugene K <sigintmailru@gmail.com> > >>Suggested-by: Eugene K <sigintmailru@gmail.com> > >>Cc: Eugene K <sigintmailru@gmail.com> > > > >You should use the "real" name here, and not some shortening. > > I don't know the real name, and AFAIK this is really only important > for S-o-b lines. This is mandatory only for SoB, but it's pointless to have it in the other tags. This is to identify the developper that sets these tags, and we can't do that without a full name. Maxime
On 07/21/2015 02:15 PM, Ulf Hansson wrote: > On 10 July 2015 at 17:14, Hans de Goede <hdegoede@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. > 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 <sigintmailru@gmail.com> >> Suggested-by: Eugene K <sigintmailru@gmail.com> >> Cc: Eugene K <sigintmailru@gmail.com> >> Cc: Arend van Spriel <arend@broadcom.com> >> Signed-off-by: Hans de Goede <hdegoede@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 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 <hdegoede@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 <sigintmailru@gmail.com> >>> Suggested-by: Eugene K <sigintmailru@gmail.com> >>> Cc: Eugene K <sigintmailru@gmail.com> >>> Cc: Arend van Spriel <arend@broadcom.com> >>> Signed-off-by: Hans de Goede <hdegoede@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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >
Hi, On 21-07-15 14:15, Ulf Hansson wrote: > On 10 July 2015 at 17:14, Hans de Goede <hdegoede@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? The code were things get stuck when not waiting for the busy signal uses the following sdio helper functions: sdio_readb/sdio_writeb sdio_f0_readb/sdio_f0_writeb sdio_readw/sdio_writew sdio_readl/sdio_writel sdio_readsb sdio_memcpy_fromio/sdio_memcpy_toio And directly issues the following command: mmc_dat.flags = write ? MMC_DATA_WRITE : MMC_DATA_READ; mmc_cmd.opcode = SD_IO_RW_EXTENDED; mmc_cmd.arg = write ? 1<<31 : 0; /* write flag */ mmc_cmd.arg |= (fn & 0x7) << 28; /* SDIO func num */ mmc_cmd.arg |= 1<<27; /* block mode */ /* for function 1 the addr will be incremented */ mmc_cmd.arg |= (fn == 1) ? 1<<26 : 0; mmc_cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC; I do not know if the busy wait is necessary for all of these, but the hack in the android kernel code, which inserts calls to a wait_card_busy function directly into: drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c Does so for all of these. > 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. Agreed, recent dw-mmc patches address the same issue, also involving broadcom sdio wifi chips. > 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... I'm fine with solving this either way, implementing host_ops->card_busy() for sunxi is easy, and if the core os modified to call that function before issue sdio io ops (which seems to be the common thing here), then that indeed is better then having the sunxi code always do the busy check. > Within this context, could I ask whether you controller supports IRQ > based HW-busy detection? Or you need polling of the status register? I'm afraid that we need to poll the status register. I've been unable to find an irq flag corresponding to this. Regards, Hans >> This commit fixes this, thereby fixing the wifi reliability issues on >> the Cubietruck and other sunxi boards using sdio wifi. >> >> Reported-by: Eugene K <sigintmailru@gmail.com> >> Suggested-by: Eugene K <sigintmailru@gmail.com> >> Cc: Eugene K <sigintmailru@gmail.com> >> Cc: Arend van Spriel <arend@broadcom.com> >> Signed-off-by: Hans de Goede <hdegoede@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 1 August 2015 at 11:01, Hans de Goede <hdegoede@redhat.com> wrote: > Hi, > > On 21-07-15 14:15, Ulf Hansson wrote: >> >> On 10 July 2015 at 17:14, Hans de Goede <hdegoede@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? > > > The code were things get stuck when not waiting for the busy signal uses > the following sdio helper functions: > > sdio_readb/sdio_writeb > sdio_f0_readb/sdio_f0_writeb > sdio_readw/sdio_writew > sdio_readl/sdio_writel > sdio_readsb > sdio_memcpy_fromio/sdio_memcpy_toio > > And directly issues the following command: > > mmc_dat.flags = write ? MMC_DATA_WRITE : MMC_DATA_READ; > mmc_cmd.opcode = SD_IO_RW_EXTENDED; > mmc_cmd.arg = write ? 1<<31 : 0; /* write flag */ > mmc_cmd.arg |= (fn & 0x7) << 28; /* SDIO func num */ > mmc_cmd.arg |= 1<<27; /* block mode */ > /* for function 1 the addr will be incremented */ > mmc_cmd.arg |= (fn == 1) ? 1<<26 : 0; > mmc_cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC; > > I do not know if the busy wait is necessary for all > of these, but the hack in the android kernel code, > which inserts calls to a wait_card_busy function directly > into: drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c > > Does so for all of these. > >> 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. > > > Agreed, recent dw-mmc patches address the same issue, also involving > broadcom sdio wifi chips. > >> 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... > > > I'm fine with solving this either way, implementing host_ops->card_busy() > for sunxi is easy, and if the core os modified to call that function > before issue sdio io ops (which seems to be the common thing here), > then that indeed is better then having the sunxi code always do > the busy check. Okay, so let's make the core to call the ->card_busy() callback and then it's up to each host driver to implement that callback. As an optimization, we might consider (in a separate step) to add MMC_RSP_BUSY to the response type. I realize that would somewhat be a violation of the spec, but apparently the SDIO spec isn't really clear on this area. > >> Within this context, could I ask whether you controller supports IRQ >> based HW-busy detection? Or you need polling of the status register? > > > I'm afraid that we need to poll the status register. I've been unable > to find an irq flag corresponding to this. Okay, thanks for the info. [...] Kind regards Uffe -- 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
Hi, On 25-08-15 14:05, Ulf Hansson wrote: > On 1 August 2015 at 11:01, Hans de Goede <hdegoede@redhat.com> wrote: >> Hi, >> >> On 21-07-15 14:15, Ulf Hansson wrote: >>> >>> On 10 July 2015 at 17:14, Hans de Goede <hdegoede@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? >> >> >> The code were things get stuck when not waiting for the busy signal uses >> the following sdio helper functions: >> >> sdio_readb/sdio_writeb >> sdio_f0_readb/sdio_f0_writeb >> sdio_readw/sdio_writew >> sdio_readl/sdio_writel >> sdio_readsb >> sdio_memcpy_fromio/sdio_memcpy_toio >> >> And directly issues the following command: >> >> mmc_dat.flags = write ? MMC_DATA_WRITE : MMC_DATA_READ; >> mmc_cmd.opcode = SD_IO_RW_EXTENDED; >> mmc_cmd.arg = write ? 1<<31 : 0; /* write flag */ >> mmc_cmd.arg |= (fn & 0x7) << 28; /* SDIO func num */ >> mmc_cmd.arg |= 1<<27; /* block mode */ >> /* for function 1 the addr will be incremented */ >> mmc_cmd.arg |= (fn == 1) ? 1<<26 : 0; >> mmc_cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC; >> >> I do not know if the busy wait is necessary for all >> of these, but the hack in the android kernel code, >> which inserts calls to a wait_card_busy function directly >> into: drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c >> >> Does so for all of these. >> >>> 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. >> >> >> Agreed, recent dw-mmc patches address the same issue, also involving >> broadcom sdio wifi chips. >> >>> 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... >> >> >> I'm fine with solving this either way, implementing host_ops->card_busy() >> for sunxi is easy, and if the core os modified to call that function >> before issue sdio io ops (which seems to be the common thing here), >> then that indeed is better then having the sunxi code always do >> the busy check. > > Okay, so let's make the core to call the ->card_busy() callback and > then it's up to each host driver to implement that callback. Ok, do you plan to do a patch for this, or do you expect to get one submitted to you ? Regards, Hans > As an optimization, we might consider (in a separate step) to add > MMC_RSP_BUSY to the response type. I realize that would somewhat be a > violation of the spec, but apparently the SDIO spec isn't really clear > on this area. > >> >>> Within this context, could I ask whether you controller supports IRQ >>> based HW-busy detection? Or you need polling of the status register? >> >> >> I'm afraid that we need to poll the status register. I've been unable >> to find an irq flag corresponding to this. > > Okay, thanks for the info. > > [...] > > Kind regards > Uffe > -- 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
On 25 August 2015 at 14:09, Hans de Goede <hdegoede@redhat.com> wrote: > Hi, > > > On 25-08-15 14:05, Ulf Hansson wrote: >> >> On 1 August 2015 at 11:01, Hans de Goede <hdegoede@redhat.com> wrote: >>> >>> Hi, >>> >>> On 21-07-15 14:15, Ulf Hansson wrote: >>>> >>>> >>>> On 10 July 2015 at 17:14, Hans de Goede <hdegoede@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? >>> >>> >>> >>> The code were things get stuck when not waiting for the busy signal uses >>> the following sdio helper functions: >>> >>> sdio_readb/sdio_writeb >>> sdio_f0_readb/sdio_f0_writeb >>> sdio_readw/sdio_writew >>> sdio_readl/sdio_writel >>> sdio_readsb >>> sdio_memcpy_fromio/sdio_memcpy_toio >>> >>> And directly issues the following command: >>> >>> mmc_dat.flags = write ? MMC_DATA_WRITE : MMC_DATA_READ; >>> mmc_cmd.opcode = SD_IO_RW_EXTENDED; >>> mmc_cmd.arg = write ? 1<<31 : 0; /* write flag */ >>> mmc_cmd.arg |= (fn & 0x7) << 28; /* SDIO func num */ >>> mmc_cmd.arg |= 1<<27; /* block mode */ >>> /* for function 1 the addr will be incremented */ >>> mmc_cmd.arg |= (fn == 1) ? 1<<26 : 0; >>> mmc_cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC; >>> >>> I do not know if the busy wait is necessary for all >>> of these, but the hack in the android kernel code, >>> which inserts calls to a wait_card_busy function directly >>> into: drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c >>> >>> Does so for all of these. >>> >>>> 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. >>> >>> >>> >>> Agreed, recent dw-mmc patches address the same issue, also involving >>> broadcom sdio wifi chips. >>> >>>> 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... >>> >>> >>> >>> I'm fine with solving this either way, implementing host_ops->card_busy() >>> for sunxi is easy, and if the core os modified to call that function >>> before issue sdio io ops (which seems to be the common thing here), >>> then that indeed is better then having the sunxi code always do >>> the busy check. >> >> >> Okay, so let's make the core to call the ->card_busy() callback and >> then it's up to each host driver to implement that callback. > > > Ok, do you plan to do a patch for this, or do you expect to get > one submitted to you ? I prefer to get a patch submitted to me. My bandwidth has been limited and still have a lot to catch up with... Kind regards Uffe -- 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
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) {
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. This commit fixes this, thereby fixing the wifi reliability issues on the Cubietruck and other sunxi boards using sdio wifi. Reported-by: Eugene K <sigintmailru@gmail.com> Suggested-by: Eugene K <sigintmailru@gmail.com> Cc: Eugene K <sigintmailru@gmail.com> Cc: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hans de Goede <hdegoede@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(+)