lkml.org 
[lkml]   [2013]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] wait while adding MMC host to ensure root mounts
On 04/04/13 13:59, Sergey Yanovich wrote:
> On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
>> No, I am booting from eMMC.
>
> Well, in this case you should be aware, that your system is not
> concurrency-safe without the patch. It may or may not boot each time
> depending on the large number of factors.

Not true. You know nothing of my boot time characteristics.

>
>>> Maybe introduce mmc_is_hosting_root() and do something like:
>>>
>>> - mmc_flush_scheduled_work();
>>> + if (mmc_is_hosting_root())
>>> + mmc_flush_scheduled_work();
>>
>> No, I am booting from eMMC. Perhaps a host capability:
>>
>> if (host->caps2 & MMC_CAP2_ROOTWAIT)
>> mmc_flush_scheduled_work();
>>
>
> Neither my variant, nor yours will help to handle the increased boot
> time.

Not true. I would not set MMC_CAP2_ROOTWAIT.

> The root cause is that probing several devices is done sequentially and
> mmc was reporting end of its probing before it was actually happening.

Not true. The probe of the MMC Host Controller finishes when the host
controller is initialized.

> My patch makes mmc report end of probing on-time. The correct way to fix
> the additional delay, my patch introduces, is to rewrite the probing to
> be parallel instead of sequential. I understand that it is much easier
> just to revert the patch.
>
> If the patch is reverted, something like this somewhere in
> 'init/do_mounts.c' could conditionally activate 'root_wait':
>
> if (mmc_is_hosting_root())
> root_wait = 1;
>
> IMHO this is wrong and my patch is right, but better this than broken
> mmc boot.

No. Your patch is not right for my platform.



\
 
 \ /
  Last update: 2013-04-04 14:01    [W:0.062 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site