linux.git/drivers/mmc, branch v4.1.29

mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers

2016-06-06T23:12:33+00:00

[ Upstream commit 265984b36ce82fec67957d452dd2b22e010611e4 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: longer timeout for long read time quirk

2016-06-06T23:12:33+00:00

[ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]

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 
Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: mmc: Fix partition switch timeout for some eMMCs

2016-06-06T23:12:22+00:00

[ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ]

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.

Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: atmel-mci: Check pdata for NULL before dereferencing it at DMA config

2016-04-18T12:51:01+00:00

[ Upstream commit 93c77d2999b09f2084b033ea6489915e0104ad9c ]

Using an at91sam9g20ek development board with DTS configuration may trigger
a kernel panic because of a NULL pointer dereference exception, while
configuring DMA. Let's fix this by adding a check for pdata before
dereferencing it.

Signed-off-by: Brent Taylor 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: atmel-mci: restore dma on AVR32

2016-04-18T12:51:01+00:00

[ Upstream commit 74843787158e9dff249f0528e7d4806102cc2c26 ]

Commit ecb89f2f5f3e7 ("mmc: atmel-mci: remove compat for non DT board
when requesting dma chan") broke dma on AVR32 and any other boards not
using DT.  This restores a fallback mechanism for such cases.

Signed-off-by: Mans Rullgard 
Acked-by: Hans-Christian Noren Egtvedt 
Acked-by: Ludovic Desroches 
Acked-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout

2016-04-18T12:51:00+00:00

[ Upstream commit 995136247915c5cee633d55ba23f6eebf67aa567 ]

Normally the timeout clock frequency is read from the capabilities
register.  It is also possible to set the value prior to calling
sdhci_add_host() in which case that value will override the
capabilities register value.  However that was being done after
calculating max_busy_timeout so that max_busy_timeout was being
calculated using the wrong value of timeout_clk.

Fix that by moving the override before max_busy_timeout is
calculated.

The result is that the max_busy_timeout and max_discard
increase for BSW devices so that, for example, the time for
mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds
to about 20 seconds.

Note, in the future, the capabilities setting will be tidied up
and this override won't be used anymore.  However this fix is
needed for stable.

Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case

2016-04-18T12:50:59+00:00

[ Upstream commit bcdc9f260bdce09913db1464be9817170d51044a ]

This patch fixes the MMC SPI driver from doing polling card detect when a
CD GPIO that supports interrupts is specified using the gpios DT property.

Without this patch the DT node below results in the following output:

 spi_gpio: spi-gpio { /* SD2 @ CN12 */
         compatible = "spi-gpio";
         #address-cells = <1>;
         #size-cells = <0>;
         gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>;
         gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>;
         gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>;
         num-chipselects = <1>;
         cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>;
         status = "okay";

         spi@0 {
                 compatible = "mmc-spi-slot";
                 reg = <0>;
                 voltage-ranges = <3200 3400>;
                 spi-max-frequency = <25000000>;
                 gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;   /* CD */
         };
 };

 # dmesg | grep mmc
 mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling
 mmc0: host does not support reading read-only switch, assuming write-enable
 mmc0: new SDHC card on SPI
 mmcblk0: mmc0:0000 SU04G 3.69 GiB
 mmcblk0: p1

With this patch applied the "cd polling" portion above disappears.

Signed-off-by: Magnus Damm 
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci: fix data timeout (part 2)

2016-04-18T12:50:42+00:00

[ Upstream commit 7f05538af71c7d30b5fc821cbe9f318edc645961 ]

The calculation for the timeout based on the number of card clocks is
incorrect.  The calculation assumed:

	timeout in microseconds = clock cycles / clock in Hz

which is clearly a several orders of magnitude wrong.  Fix this by
multiplying the clock cycles by 1000000 prior to dividing by the Hz
based clock.  Also, as per part 1, ensure that the division rounds
up.

As this needs 64-bit math via do_div(), avoid it if the clock cycles
is zero.

Signed-off-by: Russell King 
Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v3.15+
Tested-by: Gregory CLEMENT 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci: fix data timeout (part 1)

2016-04-18T12:50:42+00:00

[ Upstream commit fafcfda9e78cae8796d1799f14e6457790797555 ]

The data timeout gives the minimum amount of time that should be
waited before timing out if no data is received from the card.
Simply dividing the nanosecond part by 1000 does not give this
required guarantee, since such a division rounds down.  Use
DIV_ROUND_UP() to give the desired timeout.

Signed-off-by: Russell King 
Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v3.15+
Tested-by: Gregory CLEMENT 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-pxav3: fix higher speed mode capabilities

2016-04-18T12:50:42+00:00

[ Upstream commit 0ca33b4ad9cfc133bb3d93eec1ad0eea83d6f252 ]

Commit 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the
SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes
being used.

The commit claims that SDR50 and DDR50 require clock adjustments in
the SDIO3 Configuration register, which is located via the "conf-sdio3"
resource.  However, when this resource is given, we fail to read the
host capabilities 1 register, resulting in host->caps1 being zero.
Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain
zero, disabling the SDR50 and DDR50 modes.

The underlying idea in this function appears to be to read the device
capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause
our modified capabilities to be used.  Implement exactly that.

Fixes: 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes")
Signed-off-by: Russell King 
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Adrian Hunter 
Tested-by: Gregory CLEMENT 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin