On Tue, Jun 12, 2018 at 12:29:50PM +0200, Ulf Hansson wrote: > On 12 June 2018 at 10:42, Feng Tang <feng.tang@xxxxxxxxx> wrote: > > Hi Ulf, > > > > Thanks for the review. > > > > On Tue, Jun 12, 2018 at 08:25:44AM +0200, Ulf Hansson wrote: > >> On 8 June 2018 at 11:51, Feng Tang <feng.tang@xxxxxxxxx> wrote: > >> > When doing some boot time optimization for an eMMC rootfs NUCs, > >> > we found the rootfs may spend around 100 microseconds waiting > >> > for eMMC card to be initialized, then the rootfs could be > >> > mounted. > >> > [ 1.216561] Waiting for root device /dev/mmcblk1p1... > >> > [ 1.289262] mmc1: new HS400 MMC card at address 0001 > >> > [ 1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB > >> > [ 1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB > >> > [ 1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB > >> > [ 1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB > >> > [ 1.292798] mmcblk1: p1 p2 p3 > >> > [ 1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to feature incompatibilities > >> > [ 1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to feature incompatibilities > >> > > >> > And this is a common problem for smartphones, tablets, embedded > >> > devices and automotive products. This patch will make the eMMC/SD > >> > card start initializing earlier, by changing its order in drivers/Makefile. > >> > > >> > On our platform, the waiting for eMMC card is almost eliminated with the patch, > >> > which is critical to boot time. > >> > >> I am wondering what kernel version you are running here. There have > >> been some changes to the mmc initialization path, which perhaps can > >> help. > > These logs in commit msg are based on kernel 4.14, and the patch is generated > > against kernel 4.17. > > Right. So it's quite recent, even if lot's of changes have been made > to the mmc core since then. > > A few things (old/new) that is important. > 1) Check if your mmc host driver support MMC_CAP_WAIT_WHILE_BUSY. That > should have some effect, avoiding unnecessary polling. > > 2) Since 4.18 rc1, you will be able to configure an over estimated > "power on" delay (via DT as well). Look at commit > 6d796c68cd15234a33a4bd2ef7231125fea2dc6c. > > 3) If you use a DT based platform, I think what people do is to > re-organize the order of device nodes, such that as many as possible > -EPROBE_DEFER is avoided to be returned by drivers. This is also not a > good solution, but the best we have at this moment. Thanks for the detailed info! Will try this out, but it may take a while as we need to migrate the whole BSP to latest kernel first. > > > >> > >> > > >> > Signed-off-by: Feng Tang <feng.tang@xxxxxxxxx> > >> > --- > >> > drivers/Makefile | 4 +++- > >> > 1 file changed, 3 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/Makefile b/drivers/Makefile > >> > index 24cd47014657..c473afd3c688 100644 > >> > --- a/drivers/Makefile > >> > +++ b/drivers/Makefile > >> > @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR) += regulator/ > >> > # reset controllers early, since gpu drivers might rely on them to initialize > >> > obj-$(CONFIG_RESET_CONTROLLER) += reset/ > >> > > >> > +# put mmc early as many morden devices use emm/sd card as rootfs storage > >> > +obj-y += mmc/ > >> > + > >> > >> Your suggested approach isn't really a solution, as it may work for > >> your particular case but not for everybody else. > > > > Do you mean the patch may break some platforms? Yes, I only tested on > > some IA based NUCs, and I did think about other architectures, things > > that may affect MMC are gpio/clk/pinctrl, and those are still earlier > > than mmc after change. > > I don't know if it breaks things, potentially it could, if drivers > don't implement support for -EPROBE_DEFER properly. > > However, more importantly, it's not real fix to the problem, just > something that seems to work for you. Got your point. Acutally I profiled the time for every function of mmc init, for example, mmc_init_card() will take about 40ms, mostly due to its mmc operation model: send a CMD and wait for completion, which time is HW bound and doesn't have much space to optimize. Thanks, Feng -- 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
