All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ziyuan Xu <xzy.xu@rock-chips.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mmc: dw_mmc: reduce timeout detection cycle
Date: Tue, 19 Jul 2016 16:08:20 +0800	[thread overview]
Message-ID: <578DDFF4.4090602@rock-chips.com> (raw)
In-Reply-To: <578DDBEF.60307@samsung.com>

Hi Jaehoon,

On 2016?07?19? 15:51, Jaehoon Chung wrote:
> Hi,
>
> On 07/19/2016 04:40 PM, Ziyuan Xu wrote:
>> Hi Jaehoon,
>>
>> On 2016?07?19? 12:22, Jaehoon Chung wrote:
>>> Hi Ziyuan,
>>>
>>> On 07/19/2016 11:33 AM, Ziyuan Xu wrote:
>>>> Hi Jaehoon,
>>>>
>>>> On 2016?07?19? 10:03, Jaehoon Chung wrote:
>>>>> Hi Ziyuan,
>>>>>
>>>>> On 07/19/2016 10:38 AM, Ziyuan Xu wrote:
>>>>>> It's no need to speed 10 seconds to wait the mmc device out from busy
>>>>>> status. 500 milliseconds enough.
>>>>> I agreed that 10 seconds is too big..
>>>>> Could you explain more how you get 500ms and feel enough?
>>>> Ordinarily, there are 3 types of scenarios that the mmc device was busy:
>>>> 1. The mmc interface didn't initialize (eg. gpio  iomux)
>>>> The device will be busy status until gpio iomux.
>>>>
>>>> 2. The last command with data transfer.
>>>> The maximum value of data timeout is 0xffffff cyles(see dwi databook Timeout Register), and the clock is up to 52MHZ under high speed mode.
>>>> timeout = 0xffffff * 1/52M = 0.32s
>>>>
>>>> 3. voltage switch
>>>> U-BOOT doesn't support voltage switch.
>>>>
>>>> In summary, I think 500 milliseconds is enough. What do you think?
>>> I think it's not important thing.
>>>
>>> This is for checking whether card is busy or not before sending command.
>>> I think it's not relevant to Timeout register. Just ensure that card is not busy before sending command.
>>> And there is no effect for I/O performance, isn't?
>> Yup,  I agree with you.  For scenarios 2, I mean that if the last command with data transfer, we will hit data_busy assertion probably. If the mmc device remains in a busy state more than 500ms, I think it may also be busy state after 10s.
>>> But 50ms is not bad. :) It's personal preference.
>> BTW, the timeout value is 500ms in kernel.
> Yep, it looks good to me. :)
> I have tested your patch with Exynos SoCs.
>
> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
> Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Thanks for your test and review!
>
> Best Regards,
> Jaehoon Chung
>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>>>> Best Regards,
>>>>> Jaehoon Chung
>>>>>
>>>>>> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
>>>>>> ---
>>>>>>
>>>>>>     drivers/mmc/dw_mmc.c | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
>>>>>> index 2cf7bae..790a166 100644
>>>>>> --- a/drivers/mmc/dw_mmc.c
>>>>>> +++ b/drivers/mmc/dw_mmc.c
>>>>>> @@ -195,7 +195,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
>>>>>>         ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, cur_idmac,
>>>>>>                      data ? DIV_ROUND_UP(data->blocks, 8) : 0);
>>>>>>         int ret = 0, flags = 0, i;
>>>>>> -    unsigned int timeout = 100000;
>>>>>> +    unsigned int timeout = 500;
>>>>>>         u32 retry = 100000;
>>>>>>         u32 mask, ctrl;
>>>>>>         ulong start = get_timer(0);
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>

  reply	other threads:[~2016-07-19  8:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20160719013855epcas1p473dab263942467b94c8b5f1a89271d5b@epcas1p4.samsung.com>
2016-07-19  1:38 ` [U-Boot] [PATCH] mmc: dw_mmc: reduce timeout detection cycle Ziyuan Xu
2016-07-19  2:03   ` Jaehoon Chung
2016-07-19  2:33     ` Ziyuan Xu
2016-07-19  4:22       ` Jaehoon Chung
2016-07-19  7:40         ` Ziyuan Xu
2016-07-19  7:51           ` Jaehoon Chung
2016-07-19  8:08             ` Ziyuan Xu [this message]
2016-07-25  2:07               ` Simon Glass

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=578DDFF4.4090602@rock-chips.com \
    --to=xzy.xu@rock-chips.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.