On 11 February 2015 at 04:46, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> wrote:
> Dear, Ulf.
>
> On 02/11/2015 12:25 PM, Ulf Hansson wrote:
>> On 11 February 2015 at 03:57, Addy <addy.ke@xxxxxxxxxxxxxx> wrote:
>>>
>>> On 2015/02/10 23:22, Alim Akhtar wrote:
>>>>
>>>> Hi Addy,
>>>>
>>>> On Mon, Feb 9, 2015 at 12:55 PM, Addy Ke <addy.ke@xxxxxxxxxxxxxx> wrote:
>>>>>
>>>>> Because of some uncertain factors, such as worse card or worse hardware,
>>>>> DAT[3:0](the data lines) may be pulled down by card, and mmc controller
>>>>> will be in busy state. This should not happend when mmc controller
>>>>> send command to update card clocks. If this happends, mci_send_cmd will
>>>>> be failed and we will get 'Timeout sending command', and then system will
>>>>> be blocked. To avoid this, we need reset mmc controller.
>>>>>
>>>>> Signed-off-by: Addy Ke <addy.ke@xxxxxxxxxxxxxx>
>>>>> ---
>>>>> drivers/mmc/host/dw_mmc.c | 28 ++++++++++++++++++++++++++++
>>>>> 1 file changed, 28 insertions(+)
>>>>>
>>>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>>>> index 4d2e3c2..b0b57e3 100644
>>>>> --- a/drivers/mmc/host/dw_mmc.c
>>>>> +++ b/drivers/mmc/host/dw_mmc.c
>>>>> @@ -100,6 +100,7 @@ struct idmac_desc {
>>>>> };
>>>>> #endif /* CONFIG_MMC_DW_IDMAC */
>>>>>
>>>>> +static int dw_mci_card_busy(struct mmc_host *mmc);
>>>>> static bool dw_mci_reset(struct dw_mci *host);
>>>>> static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>>>>>
>>>>> @@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot *slot,
>>>>> u32 cmd, u32 arg)
>>>>> cmd, arg, cmd_status);
>>>>> }
>>>>>
>>>>> +static void dw_mci_wait_busy(struct dw_mci_slot *slot)
>>>>> +{
>>>>> + struct dw_mci *host = slot->host;
>>>>> + unsigned long timeout = jiffies + msecs_to_jiffies(500);
>>>>> +
>>>>
>>>> Why 500 msec?
>>>
>>> This timeout value is the same as mci_send_cmd:
>>> static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
>>> {
>>> struct dw_mci *host = slot->host;
>>> unsigned long timeout = jiffies + msecs_to_jiffies(500);
>>> ....
>>> }
>>>
>>> I have not clear that which is suitable.
>>> Do you have any suggestion on it?
>>>>
>>>>
>>>>> + do {
>>>>> + if (!dw_mci_card_busy(slot->mmc))
>>>>> + return;
>>>>> + cpu_relax();
>>>>> + } while (time_before(jiffies, timeout));
>>>>> +
>>>>> + dev_err(host->dev, "Data busy (status %#x)\n",
>>>>> + mci_readl(slot->host, STATUS));
>>>>> +
>>>>> + /*
>>>>> + * Data busy, this should not happend when mmc controller send
>>>>> command
>>>>> + * to update card clocks in non-volt-switch state. If it
>>>>> happends, we
>>>>> + * should reset controller to avoid getting "Timeout sending
>>>>> command".
>>>>> + */
>>>>> + dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
>>>>> +
>>>>
>>>> Why you need to reset all blocks? may be CTRL_RESET is good enough here.
>>>
>>> I have tested on rk3288, if only reset ctroller, data busy bit will not be
>>> cleaned,and we will still get
>>>
>>> "Timeout sending command".
>>>
>>>>
>>>>> + /* Fail to reset controller or still data busy, WARN_ON! */
>>>>> + WARN_ON(dw_mci_card_busy(slot->mmc));
>>>>> +}
>>>>> +
>>>>> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
>>>>> force_clkinit)
>>>>> {
>>>>> struct dw_mci *host = slot->host;
>>>>> @@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot
>>>>> *slot, bool force_clkinit)
>>>>> /* We must continue to set bit 28 in CMD until the change is
>>>>> complete */
>>>>> if (host->state == STATE_WAITING_CMD11_DONE)
>>>>> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
>>>>> + else
>>>>> + dw_mci_wait_busy(slot);
>>>>>
>>>> hmm...I would suggest you to call dw_mci_wait_busy() from inside
>>>> mci_send_cmd(), seems like dw_mmc hangs while sending update clock cmd
>>>> in multiple cases.see [1]
>>>>
>>>> [1]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31140
>>>
>>> I think this patch is more reasonable.
>>> So I will resend patches based on this patch.
>>> thank you!
>>
>> Addy, Jaehoon,
>>
>> It would simply things if I could get pull requests for patches of
>> dw_mmc. It's currently a bit hard to keep track and follow the
>> progress all the time.
>> Anyone volunteering in helping out here? :-)
>
> If you are ok, i will do it..
Great! Much appreciated!
Don't hesitate to send several PR during a release cycle.
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
