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. 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/ + # tty/ comes before char/ so that the VT console is the boot-time # default. obj-y += tty/ @@ -128,7 +131,6 @@ obj-$(CONFIG_EISA) += eisa/ obj-$(CONFIG_PM_OPP) += opp/ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_CPU_IDLE) += cpuidle/ -obj-y += mmc/ obj-$(CONFIG_MEMSTICK) += memstick/ obj-$(CONFIG_NEW_LEDS) += leds/ obj-$(CONFIG_INFINIBAND) += infiniband/ -- 2.14.1 -- 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
