linux-stable.git/drivers/mmc, branch v4.6.2 Linux kernel stable tree mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers 2016-06-01T19:18:00+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-20T07:33:47+00:00 dee5ae282cecfd139be32d61a6fac2947017b83b commit 822969369482166050c5b2f7013501505e025c39 upstream. The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 822969369482166050c5b2f7013501505e025c39 upstream.

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: longer timeout for long read time quirk 2016-06-01T19:18:00+00:00 Matt Gumbel matthew.k.gumbel@intel.com 2016-05-20T07:33:46+00:00 926c2c0bdd2eb09796ea4211f41a61c146ef5ba7 commit 32ecd320db39bcb007679ed42f283740641b81ea upstream. 008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 32ecd320db39bcb007679ed42f283740641b81ea upstream.

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers 2016-06-01T19:18:00+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-20T07:33:48+00:00 86accaa9a06395d28e9872dbeb56887b74b7e566 commit 265984b36ce82fec67957d452dd2b22e010611e4 upstream. The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 265984b36ce82fec67957d452dd2b22e010611e4 upstream.

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: sdhci-acpi: Ensure connected devices are powered when probing 2016-06-01T19:18:00+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-19T13:25:42+00:00 98e4743f6c58eefd00a34d681a5c6f6d6df0e2b8 commit e5bbf30733f930a1d17b4ccf19eac88e30a39cc7 upstream. Some devices connected to the SDHCI controller may have separate enabling lines that are controlled through GPIO. These devices need to be powered on and enabled before probing. This is to ensure all devices connected can be seen by the controller. Note, for "stable" this patch depends on the following change: commit 78a898d0e395 ("ACPI / PM: Export acpi_device_fix_up_power()") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reported-and-tested-by: Laszlo Fiat <laszlo.fiat@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571 Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e5bbf30733f930a1d17b4ccf19eac88e30a39cc7 upstream.

Some devices connected to the SDHCI controller may have separate enabling
lines that are controlled through GPIO. These devices need to be powered
on and enabled before probing. This is to ensure all devices connected can
be seen by the controller.

Note, for "stable" this patch depends on the following change:
commit 78a898d0e395 ("ACPI / PM: Export acpi_device_fix_up_power()")

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reported-and-tested-by: Laszlo Fiat <laszlo.fiat@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571
Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: mmc: Fix partition switch timeout for some eMMCs 2016-06-01T19:17:59+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-05T05:12:28+00:00 74b9f53139b52b276bbc10bf9c3714944c65c01a commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 upstream. Some eMMCs set the partition switch timeout too low. Now typically eMMCs are considered a critical component (e.g. because they store the root file system) and consequently are expected to be reliable. Thus we can neglect the use case where eMMCs can't switch reliably and we might want a lower timeout to facilitate speedy recovery. Although we could employ a quirk for the cards that are affected (if we could identify them all), as described above, there is little benefit to having a low timeout, so instead simply set a minimum timeout. The minimum is set to 300ms somewhat arbitrarily - the examples that have been seen had a timeout of 10ms but were sometimes taking 60-70ms. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 upstream.

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: sunxi: Disable eMMC HS-DDR (MMC_CAP_1_8V_DDR) for Allwinner A80 2016-04-28T09:43:54+00:00 Chen-Yu Tsai wens@csie.org 2016-04-26T15:37:26+00:00 2963070a0f8184fe40be11927344e3fcc7e18e7c eMMC HS-DDR no longer works on the A80, despite it working when support for this developed. Disable it for now. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
eMMC HS-DDR no longer works on the A80, despite it working when support
for this developed.

Disable it for now.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: sdhci-acpi: Reduce Baytrail eMMC/SD/SDIO hangs 2016-04-18T09:22:53+00:00 Adrian Hunter adrian.hunter@intel.com 2016-04-15T11:06:57+00:00 6e1c7d6103fe7031035cec321307c6356809adf4 Baytrail eMMC/SD/SDIO host controllers have been known to hang. A change to a hardware setting has been found to reduce the occurrence of such hangs. This patch ensures the correct setting. This patch applies cleanly to v4.4+. It could go to earlier kernels also, so I will send backports to the stable list in due course. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Baytrail eMMC/SD/SDIO host controllers have been known to
hang.  A change to a hardware setting has been found to
reduce the occurrence of such hangs.  This patch ensures
the correct setting.

This patch applies cleanly to v4.4+.  It could go to
earlier kernels also, so I will send backports to the
stable list in due course.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: tegra: Disable UHS-I modes for Tegra124 2016-04-14T09:40:01+00:00 Jon Hunter jonathanh@nvidia.com 2016-04-13T14:35:56+00:00 70ad7f7e40af31e7ab4a1719602542856b7ea856 Tegra124 has been randomly hanging during system suspend when entering the Tegra LP1 low power state. The hang is caused by the Tegra SDHCI driver and linked to the UHS-I tuning sequence. Disabling the UHS-I modes for Tegra124 prevents any hangs from occurring when entering system suspend. Unfortunately, the tuning sequence described in the public Tegra documentation is incomplete and on inspection of the current tuning sequence that has been implemented is also incomplete and may cause problems. In the short-term it is safer to disable UHS-I modes for now and fix later because it would be too large of a change to simply patch now. Therefore, disable UHS-I modes for Tegra124. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Tegra124 has been randomly hanging during system suspend when entering
the Tegra LP1 low power state. The hang is caused by the Tegra SDHCI
driver and linked to the UHS-I tuning sequence. Disabling the UHS-I
modes for Tegra124 prevents any hangs from occurring when entering
system suspend.

Unfortunately, the tuning sequence described in the public Tegra
documentation is incomplete and on inspection of the current tuning
sequence that has been implemented is also incomplete and may cause
problems. In the short-term it is safer to disable UHS-I modes for now
and fix later because it would be too large of a change to simply patch
now. Therefore, disable UHS-I modes for Tegra124.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: block: Use the mmc host device index as the mmcblk device index 2016-04-14T09:39:34+00:00 Ulf Hansson ulf.hansson@linaro.org 2016-04-06T14:12:08+00:00 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d Commit 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards simultaneously") causes regressions for some platforms. These platforms relies on fixed mmcblk device indexes, instead of deploying the defacto standard with UUID/PARTUUID. In other words their rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2. Such guarantees have never been made by the kernel, but clearly the above commit changes the behaviour. More precisely, because of that the order changes of how cards becomes detected, so do their corresponding mmcblk device indexes. As the above commit significantly improves boot time for some platforms (magnitude of seconds), let's avoid reverting this change but instead restore the behaviour of how mmcblk device indexes becomes picked. By using the same index for the mmcblk device as for the corresponding mmc host device, the probe order of mmc host devices decides the index we get for the mmcblk device. For those platforms that suffers from a regression, one could expect that this updated behaviour should be sufficient to meet their expectations of "fixed" mmcblk device indexes. Another side effect from this change, is that the same index is used for the mmc host device, the mmcblk device and the mmc block queue. That should clarify their relationship. Reported-by: Peter Hurley <peter@hurleysoftware.com> Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Fixes: 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards simultaneously") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Commit 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
simultaneously") causes regressions for some platforms.

These platforms relies on fixed mmcblk device indexes, instead of
deploying the defacto standard with UUID/PARTUUID. In other words their
rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2.

Such guarantees have never been made by the kernel, but clearly the above
commit changes the behaviour. More precisely, because of that the order
changes of how cards becomes detected, so do their corresponding mmcblk
device indexes.

As the above commit significantly improves boot time for some platforms
(magnitude of seconds), let's avoid reverting this change but instead
restore the behaviour of how mmcblk device indexes becomes picked.

By using the same index for the mmcblk device as for the corresponding mmc
host device, the probe order of mmc host devices decides the index we get
for the mmcblk device.

For those platforms that suffers from a regression, one could expect that
this updated behaviour should be sufficient to meet their expectations of
"fixed" mmcblk device indexes.

Another side effect from this change, is that the same index is used for
the mmc host device, the mmcblk device and the mmc block queue. That
should clarify their relationship.

Reported-by: Peter Hurley <peter@hurleysoftware.com>
Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Fixes: 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
simultaneously")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge tag 'mmc-v4.6-rc1' of git://git.linaro.org/people/ulf.hansson/mmc 2016-04-11T00:38:55+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-04-11T00:38:55+00:00 2f422f94eea83f50755df76be8f5ff86ef89ad80 Pull MMC fixes from Ulf Hansson: "Here are a couple of mmc fixes intended for v4.6 rc3: MMC host: - sdhci: Fix regression setting power on Trats2 board - sdhci-pci: Add support and PCI IDs for more Broxton host controllers" * tag 'mmc-v4.6-rc1' of git://git.linaro.org/people/ulf.hansson/mmc: mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers mmc: sdhci: Fix regression setting power on Trats2 board 
Pull MMC fixes from Ulf Hansson:
 "Here are a couple of mmc fixes intended for v4.6 rc3:

  MMC host:
   - sdhci: Fix regression setting power on Trats2 board
   - sdhci-pci: Add support and PCI IDs for more Broxton host controllers"

* tag 'mmc-v4.6-rc1' of git://git.linaro.org/people/ulf.hansson/mmc:
  mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers
  mmc: sdhci: Fix regression setting power on Trats2 board