Messages in this thread | | | Date | Thu, 04 Apr 2013 14:35:04 +0300 | From | Adrian Hunter <> | Subject | Re: [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.
| |