Message ID | 20180608095154.22413-1-feng.tang@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 8 June 2018 at 11:51, Feng Tang <feng.tang@intel.com> 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. > > Signed-off-by: Feng Tang <feng.tang@intel.com> > --- > 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. > # 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 > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@intel.com> 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. > > > > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > --- > > 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. Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12 June 2018 at 10:42, Feng Tang <feng.tang@intel.com> 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@intel.com> 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. > >> >> > >> > Signed-off-by: Feng Tang <feng.tang@intel.com> >> > --- >> > 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. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018/6/12 18:29, Ulf Hansson wrote: > On 12 June 2018 at 10:42, Feng Tang <feng.tang@intel.com> 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@intel.com> 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. Sorry to chime in. We could also reduce the "power on" delay via hosts' ->set_ios() callback. > > 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. Also DT based platform is allowed to add no-sd and no-sdio for the eMMC node, which could slighly help reduce the boot time. You could refer to Documentation/devicetree/bindings/mmc/mmc.txt for details. > >> >>> >>>> >>>> Signed-off-by: Feng Tang <feng.tang@intel.com> >>>> --- >>>> 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. > > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >
On Tue, Jun 12, 2018 at 12:29:50PM +0200, Ulf Hansson wrote: > On 12 June 2018 at 10:42, Feng Tang <feng.tang@intel.com> 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@intel.com> 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@intel.com> > >> > --- > >> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 12, 2018 at 08:05:25PM +0800, Shawn Lin wrote: > On 2018/6/12 18:29, Ulf Hansson wrote: > > On 12 June 2018 at 10:42, Feng Tang <feng.tang@intel.com> 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@intel.com> 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. > > Sorry to chime in. We could also reduce the "power on" delay via hosts' > ->set_ios() callback. > > > > > 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. > > Also DT based platform is allowed to add no-sd and no-sdio for the eMMC > node, which could slighly help reduce the boot time. > You could refer to Documentation/devicetree/bindings/mmc/mmc.txt for > details. Thanks Shawn for your tips, we did simliar thing :) for no-sd and no-sdio, and even disabled SDHCI controller that has nothing connected. - Feng -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Ulf, On Tue, Jun 12, 2018 at 12:29:50PM +0200, Ulf Hansson wrote: > On 12 June 2018 at 10:42, Feng Tang <feng.tang@intel.com> 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@intel.com> 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. I've followed your suggestion to try 4.18-rc4 kernel, and there is around 15% reduction in the rootfs mount's waiting for eMMC storage. And our SDHCI pci controller does support MMC_CAP_WAIT_WHILE_BUSY. > > 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. Our platform is NUC with Celeron processors, whose most IO controllers are PCI device. > > > > >> > >> > > >> > Signed-off-by: Feng Tang <feng.tang@intel.com> > >> > --- > >> > 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. IMHO I don't think the 100ms waiting is a problem of mmc core or SDHCI host controller :), complex HWs' initializations take time, like the SATA disk, the GFX. Currently the mmc folder is too late in the drivers/Makefile, and network device, thermal, spi, usb and many other controllers get initialized before mmc (which is the common rootfs storage for smartphones and embedded devices), which triggers the not necessary "Waiting for rootfs device" (like the 100ms extra boot time in our platform). That's why I propose the leap the mmc subsystem earlier to avoid it. Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Greg, Ulf Could you help to review this? many thanks! - Feng On Thu, Aug 02, 2018 at 05:15:39PM +0800, Feng Tang wrote: > Hi Ulf, > > On Tue, Jun 12, 2018 at 12:29:50PM +0200, Ulf Hansson wrote: > > On 12 June 2018 at 10:42, Feng Tang <feng.tang@intel.com> 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@intel.com> 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. > > I've followed your suggestion to try 4.18-rc4 kernel, and there is around > 15% reduction in the rootfs mount's waiting for eMMC storage. And our > SDHCI pci controller does support MMC_CAP_WAIT_WHILE_BUSY. > > > > > 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. > > Our platform is NUC with Celeron processors, whose most IO controllers > are PCI device. > > > > > > > > >> > > >> > > > >> > Signed-off-by: Feng Tang <feng.tang@intel.com> > > >> > --- > > >> > 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. > > IMHO I don't think the 100ms waiting is a problem of mmc core or SDHCI > host controller :), complex HWs' initializations take time, like the > SATA disk, the GFX. > > Currently the mmc folder is too late in the drivers/Makefile, and network > device, thermal, spi, usb and many other controllers get initialized > before mmc (which is the common rootfs storage for smartphones and > embedded devices), which triggers the not necessary "Waiting for rootfs > device" (like the 100ms extra boot time in our platform). > > That's why I propose the leap the mmc subsystem earlier to avoid it. > > Thanks, > Feng > > > > >
On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote: > Hi Greg, Ulf > > Could you help to review this? many thanks! Review what? I see no patch here. And why would I need to review a mmc patch in the middle of the merge window? totally confused, greg k-h
Hi Greg, On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote: > > Hi Greg, Ulf > > > > Could you help to review this? many thanks! > > Review what? I see no patch here. And why would I need to review a mmc > patch in the middle of the merge window? > > totally confused, Sorry for the confusion! I didn't noticed the 4.19 merge window. The patch was originally posted in June, and has gone through some review discussions with mmc maintainers, my last mail was trying to keep some discussion info. Thanks, Feng The original patch is: ----- From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001 From: Feng Tang <feng.tang@intel.com> Date: Fri, 8 Jun 2018 17:10:30 +0800 Subject: [PATCH] mmc: Move the mmc driver init earlier 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. And it should benefit other non-x86 platforms which see the similar waiting for emmc rootfs. Signed-off-by: Feng Tang <feng.tang@intel.com> --- 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/
On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote: > Hi Greg, > > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote: > > > Hi Greg, Ulf > > > > > > Could you help to review this? many thanks! > > > > Review what? I see no patch here. And why would I need to review a mmc > > patch in the middle of the merge window? > > > > totally confused, > > Sorry for the confusion! I didn't noticed the 4.19 merge window. > > The patch was originally posted in June, and has gone through some > review discussions with mmc maintainers, my last mail was trying > to keep some discussion info. Ok, then why ask me? I'm not the mmc maintainer. > The original patch is: > ----- > > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001 > From: Feng Tang <feng.tang@intel.com> > Date: Fri, 8 Jun 2018 17:10:30 +0800 > Subject: [PATCH] mmc: Move the mmc driver init earlier > > 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. And it should benefit other non-x86 platforms > which see the similar waiting for emmc rootfs. > > Signed-off-by: Feng Tang <feng.tang@intel.com> > --- > 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 Spelling error :) > +obj-y += mmc/ > + > # tty/ comes before char/ so that the VT console is the boot-time > # default. > obj-y += tty/ Everyone wants to be first. Watch out if you try to put stuff before tty, you have to be very careful. There are sd serial devices, right? Anyway, nothing we can do now until after 4.19-rc1 is out. thanks, greg k-h
Hi Greg, Thanks for the prompt review. On Tue, Aug 14, 2018 at 09:40:41AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote: > > Hi Greg, > > > > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote: > > > > Hi Greg, Ulf > > > > > > > > Could you help to review this? many thanks! > > > > > > Review what? I see no patch here. And why would I need to review a mmc > > > patch in the middle of the merge window? > > > > > > totally confused, > > > > Sorry for the confusion! I didn't noticed the 4.19 merge window. > > > > The patch was originally posted in June, and has gone through some > > review discussions with mmc maintainers, my last mail was trying > > to keep some discussion info. > > Ok, then why ask me? I'm not the mmc maintainer. The reason is this patch not only touches the mmc, but also affects many other subsystems in drivers/ as the init order is changed. And the get_maintainer.pl shows you are the first suggested reviewer for changes to drivers/Makefile :) > > > The original patch is: > > ----- > > > > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001 > > From: Feng Tang <feng.tang@intel.com> > > Date: Fri, 8 Jun 2018 17:10:30 +0800 > > Subject: [PATCH] mmc: Move the mmc driver init earlier > > > > 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. And it should benefit other non-x86 platforms > > which see the similar waiting for emmc rootfs. > > > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > --- > > 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 > > Spelling error :) Will change it. > > > +obj-y += mmc/ > > + > > # tty/ comes before char/ so that the VT console is the boot-time > > # default. > > obj-y += tty/ > > Everyone wants to be first. Watch out if you try to put stuff before > tty, you have to be very careful. There are sd serial devices, right? As the eMMC/SD card initialization takes quite some time, the SDHCI host controller's module init function will quickly return, while leaving a worker to do the real card detection/initialization, so other subsystems should not be blocked. And yes, it is safer to move it after tty/ > > Anyway, nothing we can do now until after 4.19-rc1 is out. Understood, will send v2 after the merge window. Thanks again. - Feng
On Tue, Aug 14, 2018 at 04:08:51PM +0800, Feng Tang wrote: > Hi Greg, > > Thanks for the prompt review. > > On Tue, Aug 14, 2018 at 09:40:41AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote: > > > Hi Greg, > > > > > > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote: > > > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote: > > > > > Hi Greg, Ulf > > > > > > > > > > Could you help to review this? many thanks! > > > > > > > > Review what? I see no patch here. And why would I need to review a mmc > > > > patch in the middle of the merge window? > > > > > > > > totally confused, > > > > > > Sorry for the confusion! I didn't noticed the 4.19 merge window. > > > > > > The patch was originally posted in June, and has gone through some > > > review discussions with mmc maintainers, my last mail was trying > > > to keep some discussion info. > > > > Ok, then why ask me? I'm not the mmc maintainer. > > The reason is this patch not only touches the mmc, but also affects many other > subsystems in drivers/ as the init order is changed. And the get_maintainer.pl > shows you are the first suggested reviewer for changes to drivers/Makefile :) Fair enough, but then I could not make that change without the mmc maintainer agreeing with it. > > > > > > The original patch is: > > > ----- > > > > > > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001 > > > From: Feng Tang <feng.tang@intel.com> > > > Date: Fri, 8 Jun 2018 17:10:30 +0800 > > > Subject: [PATCH] mmc: Move the mmc driver init earlier > > > > > > 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. And it should benefit other non-x86 platforms > > > which see the similar waiting for emmc rootfs. > > > > > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > > --- > > > 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 > > > > Spelling error :) > > Will change it. > > > > > > +obj-y += mmc/ > > > + > > > # tty/ comes before char/ so that the VT console is the boot-time > > > # default. > > > obj-y += tty/ > > > > Everyone wants to be first. Watch out if you try to put stuff before > > tty, you have to be very careful. There are sd serial devices, right? > > As the eMMC/SD card initialization takes quite some time, the SDHCI > host controller's module init function will quickly return, while leaving > a worker to do the real card detection/initialization, so other subsystems > should not be blocked. > > And yes, it is safer to move it after tty/ Again, everyone wants to be first, saving 100ms is great, but make sure this will not break anything else. It's a huge change to a long-standing "we know this works" linker order. Personally, I would not want to accept this patch for that reason alone. Also given you ignored the comment for the tty line doesn't make me feel comfortable either. If you really really need this, I would suggest just doing it in your device-specific tree for a few years and when this is the only out-of-tree patch you are carrying, then revisit it :) thanks, greg k-h
Hi Greg, On Tue, Aug 14, 2018 at 10:42:41AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 14, 2018 at 04:08:51PM +0800, Feng Tang wrote: > > Hi Greg, > > > > Thanks for the prompt review. > > > > On Tue, Aug 14, 2018 at 09:40:41AM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Aug 14, 2018 at 03:38:10PM +0800, Feng Tang wrote: > > > > Hi Greg, > > > > > > > > On Tue, Aug 14, 2018 at 09:18:34AM +0200, Greg Kroah-Hartman wrote: > > > > > On Tue, Aug 14, 2018 at 02:39:59PM +0800, Feng Tang wrote: > > > > > > Hi Greg, Ulf > > > > > > > > > > > > Could you help to review this? many thanks! > > > > > > > > > > Review what? I see no patch here. And why would I need to review a mmc > > > > > patch in the middle of the merge window? > > > > > > > > > > totally confused, > > > > > > > > Sorry for the confusion! I didn't noticed the 4.19 merge window. > > > > > > > > The patch was originally posted in June, and has gone through some > > > > review discussions with mmc maintainers, my last mail was trying > > > > to keep some discussion info. > > > > > > Ok, then why ask me? I'm not the mmc maintainer. > > > > The reason is this patch not only touches the mmc, but also affects many other > > subsystems in drivers/ as the init order is changed. And the get_maintainer.pl > > shows you are the first suggested reviewer for changes to drivers/Makefile :) > > Fair enough, but then I could not make that change without the mmc > maintainer agreeing with it. > > > > > > > > > > The original patch is: > > > > ----- > > > > > > > > >From 1514c7d56e887ace37466dded09bc43f2a4c9a4a Mon Sep 17 00:00:00 2001 > > > > From: Feng Tang <feng.tang@intel.com> > > > > Date: Fri, 8 Jun 2018 17:10:30 +0800 > > > > Subject: [PATCH] mmc: Move the mmc driver init earlier > > > > > > > > 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. And it should benefit other non-x86 platforms > > > > which see the similar waiting for emmc rootfs. > > > > > > > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > > > --- > > > > 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 > > > > > > Spelling error :) > > > > Will change it. > > > > > > > > > +obj-y += mmc/ > > > > + > > > > # tty/ comes before char/ so that the VT console is the boot-time > > > > # default. > > > > obj-y += tty/ > > > > > > Everyone wants to be first. Watch out if you try to put stuff before > > > tty, you have to be very careful. There are sd serial devices, right? > > > > As the eMMC/SD card initialization takes quite some time, the SDHCI > > host controller's module init function will quickly return, while leaving > > a worker to do the real card detection/initialization, so other subsystems > > should not be blocked. > > > > And yes, it is safer to move it after tty/ > > Again, everyone wants to be first, saving 100ms is great, but make sure > this will not break anything else. It's a huge change to a > long-standing "we know this works" linker order. Personally, I would > not want to accept this patch for that reason alone. Valid concern. > > Also given you ignored the comment for the tty line doesn't make me feel > comfortable either. > > If you really really need this, I would suggest just doing it in your > device-specific tree for a few years and when this is the only > out-of-tree patch you are carrying, then revisit it :) It's already in one of our tree, and we'll keep testing it. Actually I've asked some developer to test on their arm or other socs, but got no response so far :) Anyway, thanks for the suggestion! - Feng
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/
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@intel.com> --- drivers/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)