[PATCH v2] mmc: sunxi: Don't start commands while the card is busy

[Ulf Hansson]

On 1 August 2015 at 11:01, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 21-07-15 14:15, Ulf Hansson wrote:
>>
>> On 10 July 2015 at 17:14, Hans de Goede <hdegoede at 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