> 2011/9/29 Luca Tettamanti <kronos.it@xxxxxxxxx>: > > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@xxxxxxx> wrote: > >> From: Barry Song <baohua.song@xxxxxxx> > >> > >> Some devices like mmc are async detected very slow. For example, > >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect > >> mmc partitions then add disk. > >> > >> we do have wait_for_device_probe and scsi_complete_async_scans > >> before calling swsusp_check, but it is not enough to wait mmc. > >> > >> This patch adds resumewait kernel param just like rootwait so > >> that we have enough time to wait mmc ready. The differene is > >> here we wait for resume partition but rootwait waits for rootfs > >> partition. > > > > I assume that such a device would need "rootwait" to boot in the first > > place; why don't you "overload" the param to also enable waiting in > > the resume path? > > not real. for an embedded product, the type of the rootfs, the place > of the rootfs and the way to mount rootfs are pretty flexible. > even though both rootfs and resume file use mmc, they will be in > different partitions at least. so i don't think rootwait can overload > resumewait. It would be good to at least model it the same way. rootdelay allows you to specify time, which is important for USB devices... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
