Date:   Tue, 14 Aug 2018 14:39:59 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>, arjan@...ux.intel.com,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] mmc: Move the mmc driver init earlier

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@...el.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@...el.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@...el.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
> 
> 
> 
> 
> 

Powered by blists - more mailing lists