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. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
