← Back to team overview

kernel-packages team mailing list archive

[Bug 1559870] Re: mmc_select_hs400 failed, error -74

 

commit 1815e61b1a7efe81017a883e817292daf7d2f922
Author: Adrian Hunter <adrian.hunter@xxxxxxxxx>
Date:   Wed Oct 28 14:25:40 2015 +0200

    mmc: mmc: Improve reliability of mmc_select_hs200()
   
    Currently mmc_select_hs200() uses __mmc_switch() which checks the
    success of the switch to HS200 mode using CMD13 (SEND_STATUS).
    The problem is that it does that using the timing settings of legacy
    mode.  That is prone to error, not least because the timing parameters
    for legacy mode are tighter than the timing parameters for HS200 mode.
   
    In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
    with the switch command, it must be assumed that using different modes on
    the card and host must work.
   
    However in the case when CMD13 polling is not used
    (i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs200() can be made more
    reliable by setting the host to the correct timing before sending CMD13.
   
    This patch does that.
   
    A complication is that the caller, mmc_select_timing(), will ignore a
    switch error (indicated by -EBADMSG), assume the old mode is valid
    and continue, so the old timing must be restored in that case.
   
    Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
    Cc: <stable@xxxxxxxxxxxxxxx> # 4.2+
    Tested-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>
    Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>

commit 51b12f7764fa8bb464cbd0f7bbd3a408d21ade16
Author: Adrian Hunter <adrian.hunter@xxxxxxxxx>
Date:   Wed Oct 28 14:25:41 2015 +0200

    mmc: mmc: Fix HS setting in mmc_select_hs400()
   
    mmc_select_hs400() begins with the card and host in HS200 mode.
    Therefore, any commands sent to the card should use HS200 timing.
    It is incorrect to set the host to High Speed (HS) timing before
    sending the switch command.  Doing so is unreliable because
    the timing parameters for HS mode are tighter than the timing
    parameters for HS200 mode.  Thus the HS timings should be set
    only after the card has switched mode.
   
    However, it is not unreasonable first to reduce the frequency to
    the HS mode frequency, which should make the switch command and
    subsequent CMD13 commands more reliable.
   
    This patch does that.
   
    Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
    Cc: <stable@xxxxxxxxxxxxxxx> # 4.2+
    Tested-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>
    Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>

commit 974007aaf240aa195b31c34cfdb013524a2dcfca
Author: Adrian Hunter <adrian.hunter@xxxxxxxxx>
Date:   Wed Oct 28 14:25:42 2015 +0200

    mmc: mmc: Move mmc_switch_status()
   
    Move the mmc_switch_status() function in preparation for calling it
    in mmc_select_hs400().
   
    Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
    Cc: <stable@xxxxxxxxxxxxxxx> # 4.2+
    Tested-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>
    Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>

commit d23029332c3d51fb5ac117ba5cde4dc0a3ec3fa6
Author: Adrian Hunter <adrian.hunter@xxxxxxxxx>
Date:   Wed Oct 28 14:25:43 2015 +0200

    mmc: mmc: Improve reliability of mmc_select_hs400()
   
    mmc_select_hs400() calls __mmc_switch() which checks the switch is
    successful using CMD13 (SEND_STATUS).  The problem is that it does that
    using the timing settings of the previous mode.  That is prone to error,
    especially when switching from HS to HS400 because the timing parameters
    for HS mode are tighter than the timing parameters for HS400 mode.
   
    In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
    with the switch command, it must be assumed that using different modes on
    the card and host must work.
   
    However in the case when CMD13 polling is not used
    (i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs400() can be made more
    reliable by setting the host to the correct timing before sending CMD13.
   
    This patch does that.
   
    Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
    Cc: <stable@xxxxxxxxxxxxxxx> # 4.2+
    Tested-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>
    Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>

commit 1ca896856281d3f1ad4f6f7d4e32e2943452de23
Author: Adrian Hunter <adrian.hunter@xxxxxxxxx>
Date:   Thu Nov 26 14:00:45 2015 +0200

    mmc: sdhci-pci: Do not default to 33 Ohm driver strength for Intel SPT
   
    In some cases, the stronger 33 Ohm driver strength must not be used
    so it is not a suitable default.  Change it to the standard default
    50 Ohm value.
   
    The patch applies to v4.2+ except the file name changed.  It is
    drivers/mmc/host/sdhci-pci.c prior to v.4.4.
   
    Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx # v4.2+
    Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>

commit adb24d42a516bca8b9741ed21206509daaab5b13
Author: Wenkai Du <wenkai.du@xxxxxxxxx>
Date:   Thu Nov 26 14:00:44 2015 +0200

    mmc: mmc: Fix incorrect use of driver strength switching HS200 and HS400
   
    Commit cc4f414c885c ("mmc: mmc: Add driver strength selection")
    added driver strength selection for eMMC HS200 and HS400 modes.
    That patch also set the driver stength when transitioning through
    High Speed mode to HS200/HS400, but driver strength is not defined
    for High Speed mode.  While the JEDEC specification is not clear
    on this point it has been observed to cause problems for some eMMC,
    and removing the driver strength setting in this case makes it
    consistent with the normal use of High Speed mode.
   
    Signed-off-by: Wenkai Du <wenkai.du@xxxxxxxxx>
    Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx # v4.2+
    Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1559870

Title:
  mmc_select_hs400 failed, error -74

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I used "Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307)" from http://cdimage.ubuntu.com/daily-live/current/.
  But it can not find the built-in eMMC storage and it shows the following messages.

  [   12.355182] sdhci-pci 0000:00:1e.4: No vmmc regulator found
  [   12.355185] sdhci-pci 0000:00:1e.4: No vqmmc regulator found
  [   12.358331] mmc0: SDHCI controller on PCI [0000:00:1e.4] using ADMA 64-bit
  [   12.359549] sdhci-pci 0000:00:1e.6: No vmmc regulator found
  [   12.359552] sdhci-pci 0000:00:1e.6: No vqmmc regulator found
  [   12.362713] mmc1: SDHCI controller on PCI [0000:00:1e.6] using ADMA 64-bit
  [   12.472768] mmc0: MAN_BKOPS_EN bit is not set
  [   12.489132] mmc0: mmc_select_hs400 failed, error -74
  [   12.489134] mmc0: error -74 whilst initialising MMC card
  [   12.601333] mmc0: MAN_BKOPS_EN bit is not set
  [   12.617263] mmc0: mmc_select_hs400 failed, error -74
  [   12.617280] mmc0: error -74 whilst initialising MMC card
  [   12.745957] mmc0: MAN_BKOPS_EN bit is not set
  [   12.764502] mmc0: mmc_select_hs400 failed, error -74
  [   12.764519] mmc0: error -74 whilst initialising MMC card
  [   12.923969] mmc0: MAN_BKOPS_EN bit is not set
  [   12.948561] mmc0: mmc_select_hs400 failed, error -74
  [   12.948580] mmc0: error -74 whilst initialising MMC card

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-10-generic 4.4.0-10.25
  ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3
  Uname: Linux 4.4.0-10-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  CasperVersion: 1.367
  CurrentDesktop: Unity
  Date: Mon Mar 21 06:20:39 2016
  LiveMediaBuild: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz.efi file=/cdrom/preseed/username.seed boot=casper quiet splash ---
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.board.name: STCK2MV64CC
  dmi.product.name: STCK2MV64CC

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1559870/+subscriptions


References