linux-stable.git/drivers/mmc/host, branch v3.16.78

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

mmc: jz4740: Fix race condition in IRQ mask update

2018-10-21T07:45:11+00:00

commit a04f0017c22453613d5f423326b190c61e3b4f98 upstream.

A spinlock is held while updating the internal copy of the IRQ mask,
but not while writing it to the actual IMASK register. After the lock
is released, an IRQ can occur before the IMASK register is written.
If handling this IRQ causes the mask to be changed, when the handler
returns back to the middle of the first mask update, a stale value
will be written to the mask register.

If this causes an IRQ to become unmasked that cannot have its status
cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ,
then we can end up stuck with the same IRQ repeatedly being fired but
not handled. Normally the MMC IRQ handler attempts to clear any
unexpected IRQs by writing IREG, but for those that cannot be cleared
in this way then the IRQ will just repeatedly fire.

This was resulting in lockups after a while of using Wi-Fi on the
CI20 (GitHub issue #19).

Resolve by holding the spinlock until after the IMASK register has
been updated.

Link: https://github.com/MIPS/CI20_linux/issues/19
Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.")
Tested-by: Mathieu Malaterre 
Signed-off-by: Alex Smith 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: dw_mmc: Fix out-of-bounds access for slot's caps

2018-06-16T21:22:28+00:00

commit 0d84b9e5631d923744767dc6608672df906dd092 upstream.

Add num_caps field for dw_mci_drv_data to validate the controller
id from DT alias and non-DT ways.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Shawn Lin 
Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks")
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16:
 - Drop changes to dw_mmc-{k3,rockchip,zx}.c
 - Adjust context]
Signed-off-by: Ben Hutchings

mmc: dw_mmc: Factor out dw_mci_init_slot_caps

2018-06-16T21:22:28+00:00

commit a4faa4929ed3be15e2d500d2405f992f6dedc8eb upstream.

Factor out dw_mci_init_slot_caps to consolidate parsing
all differents types of capabilities from host contrllers.
No functional change intended.

Signed-off-by: Shawn Lin 
Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks")
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16:
 - We don't set MMC_CAP_ERASE or MMC_CAP2_SDIO_IRQ_NOTHREAD capabilities
 - Fold in required changes to the exit path from commits 51da2240906c
   "mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators" and
   3cf890fc42b2 "mmc: dw_mmc: Pass back errors from mmc_of_parse()"
 - Adjust context]
Signed-off-by: Ben Hutchings

mmc: sdhci-pci: Fix S0i3 for Intel BYT-based controllers

2018-06-16T21:22:28+00:00

commit f8870ae6e2d6be75b1accc2db981169fdfbea7ab upstream.

Tuning can leave the IP in an active state (Buffer Read Enable bit set)
which prevents the entry to low power states (i.e. S0i3). Data reset will
clear it.

Generally tuning is followed by a data transfer which will anyway sort out
the state, so it is rare that S0i3 is actually prevented.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16:
 - Drop chnages in ni_byt_sdio_probe_slot(), byt_sd_probe_slot()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings