linux-stable.git/drivers/mmc/host, branch linux-3.16.y

mmc: spi: Toggle SPI polarity, do not hardcode it

2020-05-22T20:19:16+00:00

commit af3ed119329cf9690598c5a562d95dfd128e91d6 upstream.

The code in mmc_spi_initsequence() tries to send a burst with
high chipselect and for this reason hardcodes the device into
SPI_CS_HIGH.

This is not good because the SPI_CS_HIGH flag indicates
logical "asserted" CS not always the physical level. In
some cases the signal is inverted in the GPIO library and
in that case SPI_CS_HIGH is already set, and enforcing
SPI_CS_HIGH again will actually drive it low.

Instead of hard-coding this, toggle the polarity so if the
default is LOW it goes high to assert chipselect but if it
is already high then toggle it low instead.

Cc: Phil Elwell 
Reported-by: Mark Brown 
Signed-off-by: Linus Walleij 
Reviewed-by: Mark Brown 
Link: https://lore.kernel.org/r/20191204152749.12652-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: sdhci: fix minimum clock rate for v3 controller

2020-04-28T18:03:33+00:00

commit 2a187d03352086e300daa2044051db00044cd171 upstream.

For SDHCIv3+ with programmable clock mode, minimal clock frequency is
still base clock / max(divider). Minimal programmable clock frequency is
always greater than minimal divided clock frequency. Without this patch,
SDHCI uses out-of-spec initial frequency when multiplier is big enough:

mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz
[for 480 MHz source clock divided by 1024]

The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode.

Fixes: c3ed3877625f ("mmc: sdhci: add support for programmable clock mode")
Signed-off-by: Michał Mirosław 
Acked-by: Adrian Hunter 
Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mmc: sdhci-s3c: solve problem with sleeping in atomic context

2020-02-11T20:03:57+00:00

commit 017210d1c0dc2e2d3b142985cb31d90b98dc0f0f upstream.

This change addresses following problem:

[    2.560726] ------------[ cut here ]------------
[    2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744 lockdep_trace_alloc+0xec/0x118()
[    2.574439] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    2.579821] Modules linked in:
[    2.583038] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.0-next-20141216-00002-g4ff197fc1902-dirty #1318
[    2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    2.599892] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[    2.607612] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[    2.614822] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[    2.622885] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[    2.631569] [] (warn_slowpath_fmt) from [] (lockdep_trace_alloc+0xec/0x118)
[    2.640246] [] (lockdep_trace_alloc) from [] (__kmalloc+0x3c/0x1cc)
[    2.648240] [] (__kmalloc) from [] (clk_fetch_parent_index+0xb8/0xd4)
[    2.656390] [] (clk_fetch_parent_index) from [] (clk_calc_new_rates+0xe0/0x1fc)
[    2.665415] [] (clk_calc_new_rates) from [] (clk_calc_new_rates+0x1b4/0x1fc)
[    2.674181] [] (clk_calc_new_rates) from [] (clk_set_rate+0x50/0xc8)
[    2.682265] [] (clk_set_rate) from [] (sdhci_cmu_set_clock+0x68/0x16c)
[    2.690503] [] (sdhci_cmu_set_clock) from [] (sdhci_do_set_ios+0xf0/0x64c)
[    2.699095] [] (sdhci_do_set_ios) from [] (sdhci_set_ios+0x20/0x2c)
[    2.707080] [] (sdhci_set_ios) from [] (mmc_power_up+0x118/0x1fc)
[    2.714889] [] (mmc_power_up) from [] (mmc_start_host+0x44/0x6c)
[    2.722615] [] (mmc_start_host) from [] (mmc_add_host+0x58/0x7c)
[    2.730341] [] (mmc_add_host) from [] (sdhci_add_host+0x968/0xd94)
[    2.738240] [] (sdhci_add_host) from [] (sdhci_s3c_probe+0x354/0x52c)
[    2.746406] [] (sdhci_s3c_probe) from [] (platform_drv_probe+0x48/0xa4)
[    2.754733] [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x37c)
[    2.763585] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98)
[    2.772003] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[    2.780163] [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
[    2.788322] [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[    2.796308] [] (driver_register) from [] (do_one_initcall+0xac/0x1f0)
[    2.804473] [] (do_one_initcall) from [] (kernel_init_freeable+0x10c/0x1d8)
[    2.813153] [] (kernel_init_freeable) from [] (kernel_init+0x28/0x108)
[    2.821398] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
[    2.828939] ---[ end trace 03cc00e539849d1f ]---

clk_set_rate() tries to take clk's prepare_lock mutex while being in atomic
context entered in sdhci_do_set_ios().

The solution is inspired by similar situation in sdhci_set_power() also called
from sdhci_do_set_ios():

                spin_unlock_irq(&host->lock);
                mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
                spin_lock_irq(&host->lock);

Note that since sdhci_s3c_set_clock() sets SDHCI_CLOCK_CARD_EN, proposed change
first resets this bit. It is reset anyway (by setting SDHCI_CLOCK_INT_EN bit
only) after call to clk_set_rate() in order to wait for the clock to stabilize
and is set again as soon as the clock becomes stable.

Signed-off-by: Paul Osmialowski 
Tested-by: Jaehoon Chung 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: sdhci-s3c: Check if clk_set_rate() succeeds

2020-02-11T20:03:57+00:00

commit cd0cfdd2485e6252b3c69284bf09d06c4d303116 upstream.

It is possible that we may fail to set the clock rate, if we do so then
log the failure and don't bother reprogramming the IP.

Signed-off-by: Mark Brown 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: omap: fix the maximum timeout setting

2019-07-09T21:04:06+00:00

commit a6327b5e57fdc679c842588c3be046c0b39cc127 upstream.

When running OMAP1 kernel on QEMU, MMC access is annoyingly noisy:

	MMC: CTO of 0xff and 0xfe cannot be used!
	MMC: CTO of 0xff and 0xfe cannot be used!
	MMC: CTO of 0xff and 0xfe cannot be used!
	[ad inf.]

Emulator warnings appear to be valid. The TI document SPRU680 [1]
("OMAP5910 Dual-Core Processor MultiMedia Card/Secure Data Memory Card
(MMC/SD) Reference Guide") page 36 states that the maximum timeout is 253
cycles and "0xff and 0xfe cannot be used".

Fix by using 0xfd as the maximum timeout.

Tested using QEMU 2.5 (Siemens SX1 machine, OMAP310), and also checked on
real hardware using Palm TE (OMAP310), Nokia 770 (OMAP1710) and Nokia N810
(OMAP2420) that MMC works as before.

[1] http://www.ti.com/lit/ug/spru680/spru680.pdf

Fixes: 730c9b7e6630f ("[MMC] Add OMAP MMC host driver")
Signed-off-by: Aaro Koskinen 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: tmio_mmc_core: don't claim spurious interrupts

2019-05-02T20:41:59+00:00

commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.

I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected).  It turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16:
 - tmio_mmc_sdio_irq() can be used directly as an interrupt handler, so
   make it return IRQ_NONE for unhandled interrupts
 - Adjust filename]
Signed-off-by: Ben Hutchings

mmc: spi: Fix card detection during probe

2019-05-02T20:41:59+00:00

commit c9bd505dbd9d3dc80c496f88eafe70affdcf1ba6 upstream.

When using the mmc_spi driver with a card-detect pin, I noticed that the
card was not detected immediately after probe, but only after it was
unplugged and plugged back in (and the CD IRQ fired).

The call tree looks something like this:

mmc_spi_probe
  mmc_add_host
    mmc_start_host
      _mmc_detect_change
        mmc_schedule_delayed_work(&host->detect, 0)
          mmc_rescan
            host->bus_ops->detect(host)
              mmc_detect
                _mmc_detect_card_removed
                  host->ops->get_cd(host)
                    mmc_gpio_get_cd -> -ENOSYS (ctx->cd_gpio not set)
  mmc_gpiod_request_cd
    ctx->cd_gpio = desc

To fix this issue, call mmc_detect_change after the card-detect GPIO/IRQ
is registered.

Signed-off-by: Jonathan Neuschäfer 
Reviewed-by: Linus Walleij 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: omap_hsmmc: fix DMA API warning

2019-02-11T17:54:26+00:00

commit 0b479790684192ab7024ce6a621f93f6d0a64d92 upstream.

While booting with rootfs on MMC, the following warning is encountered
on OMAP4430:

omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536]

This is because the DMA engine has a default maximum segment size of 64K
but HSMMC sets:

        mmc->max_blk_size = 512;       /* Block Length at max can be 1024 */
        mmc->max_blk_count = 0xFFFF;    /* No. of Blocks is 16 bits */
        mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
        mmc->max_seg_size = mmc->max_req_size;

which ends up telling the block layer that we support a maximum segment
size of 65535*512, which exceeds the advertised DMA engine capabilities.

Fix this by clamping the maximum segment size to the lower of the
maximum request size and of the DMA engine device used for either DMA
channel.

Signed-off-by: Russell King 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

MMC: OMAP: fix broken MMC on OMAP15XX/OMAP5910/OMAP310

2019-02-11T17:54:19+00:00

commit e8cde625bfe8a714a856e1366bcbb259d7346095 upstream.

Since v2.6.22 or so there has been reports [1] about OMAP MMC being
broken on OMAP15XX based hardware (OMAP5910 and OMAP310). The breakage
seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix
omap to use MMC_POWER_ON") that changed clock enabling to be done
on MMC_POWER_ON. This can happen multiple times in a row, and on 15XX
the hardware doesn't seem to like it and the MMC just stops responding.
Fix by memorizing the power mode and do the init only when necessary.

Before the patch (on Palm TE):

	mmc0: new SD card at address b368
	mmcblk0: mmc0:b368 SDC   977 MiB
	mmci-omap mmci-omap.0: command timeout (CMD18)
	mmci-omap mmci-omap.0: command timeout (CMD13)
	mmci-omap mmci-omap.0: command timeout (CMD13)
	mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
	mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
	mmcblk0: error -110 requesting status
	mmci-omap mmci-omap.0: command timeout (CMD8)
	mmci-omap mmci-omap.0: command timeout (CMD18)
	mmci-omap mmci-omap.0: command timeout (CMD13)
	mmci-omap mmci-omap.0: command timeout (CMD13)
	mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
	mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
	mmcblk0: error -110 requesting status
	mmcblk0: recovery failed!
	print_req_error: I/O error, dev mmcblk0, sector 0
	Buffer I/O error on dev mmcblk0, logical block 0, async page read
	 mmcblk0: unable to read partition table

After the patch:

	mmc0: new SD card at address b368
	mmcblk0: mmc0:b368 SDC   977 MiB
	 mmcblk0: p1

The patch is based on a fix and analysis done by Ladislav Michl.

Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770)
and OMAP2420 (Nokia N810).

[1] https://marc.info/?t=123175197000003&r=1&w=2

Fixes: 46a6730e3ff9 ("mmc-omap: Fix omap to use MMC_POWER_ON")
Reported-by: Ladislav Michl 
Reported-by: Andrzej Zaborowski 
Tested-by: Ladislav Michl 
Acked-by: Tony Lindgren 
Signed-off-by: Aaro Koskinen 
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16: Set initial state to MMC_POWER_OFF instead of
 MMC_POWER_UNDEFINED]
Signed-off-by: Ben Hutchings

mmc: sdhci-esdhc-imx: allow 1.8V modes without 100/200MHz pinctrl states

2018-11-20T18:05:38+00:00

commit 92748beac07c471d995fbec642b63572dc01b3dc upstream.

If pinctrl nodes for 100/200MHz are missing, the controller should
not select any mode which need signal frequencies 100MHz or higher.
To prevent such speed modes the driver currently uses the quirk flag
SDHCI_QUIRK2_NO_1_8_V. This works nicely for SD cards since 1.8V
signaling is required for all faster modes and slower modes use 3.3V
signaling only.

However, there are eMMC modes which use 1.8V signaling and run below
100MHz, e.g. DDR52 at 1.8V. With using SDHCI_QUIRK2_NO_1_8_V this
mode is prevented. When using a fixed 1.8V regulator as vqmmc-supply
the stack has no valid mode to use. In this tenuous situation the
kernel continuously prints voltage switching errors:
  mmc1: Switching to 3.3V signalling voltage failed

Avoid using SDHCI_QUIRK2_NO_1_8_V and prevent faster modes by
altering the SDHCI capability register. With that the stack is able
to select 1.8V modes even if no faster pinctrl states are available:
  # cat /sys/kernel/debug/mmc1/ios
  ...
  timing spec:    8 (mmc DDR52)
  signal voltage: 1 (1.80 V)
  ...

Link: http://lkml.kernel.org/r/20180628081331.13051-1-stefan@agner.ch
Signed-off-by: Stefan Agner 
Fixes: ad93220de7da ("mmc: sdhci-esdhc-imx: change pinctrl state according
to uhs mode")
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16:
 - There is no SDHCI_SUPPORT_HS400 flag to clear
 - Adjust context]
Signed-off-by: Ben Hutchings