[U-Boot] [PATCH v2] mmc: Split device init to decouple OCR-polling delay

Simon Glass sjg at chromium.org
Mon Dec 17 04:44:14 CET 2012


Hi,

On Sun, Dec 16, 2012 at 6:12 PM, Jaehoon Chung <jh80.chung at samsung.com> wrote:
> On 12/16/2012 02:18 AM, Simon Glass wrote:
>> Hi,
>>
>> On Fri, Nov 30, 2012 at 3:13 PM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Jaehoon,
>>>
>>> On Fri, Nov 30, 2012 at 12:25 AM, Jaehoon Chung <jh80.chung at samsung.com> wrote:
>>>> Hi,
>>>>
>>>> This concept is very good.
>>>> But I have one question. I think need to call mmc_init() one more, right?
>>>> how did you save the boot time(200ms)?
>>>>
>>>> On 11/29/2012 10:21 AM, Simon Glass wrote:
>>>>> From: Che-Liang Chiou <clchiou at chromium.org>
>>>>>
>>>>> Most of time that MMC driver spends on initializing a device is polling
>>>>> OCR (operation conditions register).  To decouple this polling loop,
>>>>> device init is split into two parts: The first part fires the OCR query
>>>>> command, and the second part polls the result.  So the caller is now no
>>>>> longer bound to the OCR-polling delay; he may fire the query, go
>>>>> somewhere and then come back later for the result.
>>>>>
>>>>> To use this, call mmc_set_preinit() on any device which needs this.
>>>>>
>>>>> This can save significant amounts of time on boot (e.g. 200ms) by
>>>>> hiding the MMC init time behind other init.
>>>> snip..
>>>>> +int mmc_init(struct mmc *mmc)
>>>>> +{
>>>>> +     int err = IN_PROGRESS;
>>>>> +     unsigned start = get_timer(0);
>>>>> +
>>>>> +     if (mmc->has_init)
>>>>> +             return 0;
>>>>> +     if (!mmc->init_in_progress)
>>>>> +             err = mmc_start_init(mmc);
>>>> It need not to return? if err is IN_PROGRESS, next condition is immediately run.
>>>> Then i think we didn't save the time before adjust this patch.
>>>
>>> It's a little confusing, but the way it works is that mmc_preinit()
>>> calls mmc_start_init() early in boot. Then when mmc_init() finally
>>> gets called (later) it finishes off the init. We still need mmc_init()
>>> to actually fully complete the init. If it were to return before
>>> completing the init then we would be unable to use the MMC.
>>>
>>>>> +
>>>>> +     if (!err || err == IN_PROGRESS)
>>>>> +             err = mmc_complete_init(mmc);
>>>>> +     debug("%s: %d, time %lu\n", __func__, err, get_timer(start));
>>>>>       return err;
>>>>>  }
>>>
>>
>> Does this patch look good now? I am wondering if it will be including
>> in release, or in next?
> Well, concept is very good. But i didn't see the any benefit yet.
> I will test more...and share the result.

OK thanks. Assuming that make sure that the pre-init is definitely
done, I suggest you then make U-Boot go and do something else for
200ms, then do the full mmc init after that. It should complete
immediately.

So there is no time saving in mmc init, but you can do something else
while waiting for the MMC init to complete (it takes 200ms or so for
me).

Another thing to note with eMMC is that we probe for SD first. This
takes a little bit of time. We could perhaps use device tree to
provide information about the type of attached memory, and thus avoid
that probe.

Regards,
Simon

>
> Best Regards,
> Jaehoon Chung
>>
>> Regards,
>> Simon
>>
>>> [snip]
>>>
>>> Regards,
>>> Simon
>>
>


More information about the U-Boot mailing list