linux/drivers/mmc/core, branch v4.5

mmc: pwrseq_simple: Make reset-gpios optional to match doc

2016-01-21T12:52:27Z

The DT binding doc says reset-gpios is an optional property but the code currently bails out if it is omitted. This is a regression since it breaks previously working device trees. Fix it by restoring the original documented behaviour. Fixes: ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API") Tested-by: Tony Lindgren Signed-off-by: Martin Fuzzey Signed-off-by: Ulf Hansson

mmc: sdio_cis: fix unknown tuple for CISTPL_SDIO_STD

2016-01-20T11:39:24Z

CISTPL_SDIO_STD(0x91) is a known tuple, but sdio_cis don't define it, so we get the warning below while probing several sdio wifi cards. Refer to SDIO spec, it's not needed to parse the tuple, so this patch make it a known one. [ 4.098980] mmc2: queuing unknown CIS tuple 0x91 (3 bytes) [ 4.099033] mmc2: new ultra high speed SDR104 SDIO card at address 0001 Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: debugfs: correct wrong voltage value

2016-01-19T09:14:22Z

Correct the wrong voltage value shown in debugfs for mmc/sd/sdio. Signed-off-by: Chuanxiao Dong Signed-off-by: Pawel Wodkowski Fixes: 42cd95a0603e ("mmc: core: debugfs: Add signal_voltage to ios dump") Signed-off-by: Ulf Hansson

mmc: core: Enable tuning according to the actual timing

2016-01-14T09:59:09Z

While in sdhci_execute_tuning() the choice whether or not to enable the tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the check is done on the capability of the card. This difference is causing some issues with some SDIO cards in DDR50 mode where the CDM19 is wrongly issued. With this patch we modify the check in both mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision only according to the actual timing specification. Cc: stable@vger.kernel.org Signed-off-by: Carlo Caione Signed-off-by: Ulf Hansson

mmc: sd: limit SD card power limit according to cards capabilities

2016-01-13T09:56:27Z

The SD card specification allows cards to error out a SWITCH command where the requested function in a group is not supported. The spec provides for a set of capabilities which indicate which functions are supported. In the case of the power limit, requesting an unsupported power level via the SWITCH command fails, resulting in the power level remaining at the power-on default of 0.72W, even though the host and card may support higher powers levels. This has been seen with SanDisk 8GB cards, which support the default 0.72W and 1.44W (200mA and 400mA) in combination with an iMX6 host, supporting up to 2.88W (800mA). This currently causes us to try to set a power limit function value of '3' (2.88W) which the card errors out on, and thereby causes the power level to remain at 0.72W rather than the desired 1.44W. Arrange to limit the selected current limit by the capabilities reported by the card to avoid the SWITCH command failing. Select the highest current limit that the host and card combination support. Signed-off-by: Russell King Fixes: a39ca6ae0a08 ("mmc: core: Simplify and fix for SD switch processing") Signed-off-by: Ulf Hansson

mmc: It is not an error for the card to be removed while suspended

2015-12-28T11:51:38Z

A card can be removed while it is runtime suspended. Do not print an error message. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson

mmc: core: Optimize boot time by detecting cards simultaneously

2015-12-28T09:08:09Z

The mmc workqueue is an ordered workqueue, allowing only one work to execute per given time. As this workqueue is used for card detection, the conseqeunce is that cards will be detected one by one waiting for each other. Moreover, most of the time spent during card initialization is waiting for the card's internal firmware to be ready. From a CPU perspective this typically means waiting for a completion variable to be kicked via an IRQ-handler or waiting for a sleep timer to finish. This behaviour of detecting/initializing cards is sub-optimal, especially for SOCs having several controllers/cards. Let's convert to use the system_freezable_wq for the mmc detect works. This enables several works to be executed simultaneously and thus also cards to be detected like so. Tests on UX500, which holds two eMMC cards and an SD-card (actually also an SDIO card, currently not detected), shows a significant improved behaviour due to this change. Before this change, both the eMMC cards waited for the SD card to be initialized as its detect work entered the workqueue first. In some cases, depending on the characteristic of the SD-card, they got delayed 1-1.5 s. Additionally for the second eMMC, it needed to wait for the first eMMC to be initialized which added another 120-190 ms. Converting to the system_freezable_wq, removed these delays and made both the eMMC cards available far earlier in the boot sequence. Selecting the system_freezable_wq, in favour of for example the system_wq, is because we need card detection mechanism to be disabled once userspace are frozen during system PM. Currently the mmc core deal with this via PM notifiers, but following patches may utilize the behaviour of the system_freezable_wq, to simplify the use of the PM notifiers. Signed-off-by: Ulf Hansson Tested-by: Alan Cooper Tested-by: Shawn Lin

mmc: core: fix __mmc_switch timeout caused by preempt

2015-12-22T10:32:18Z

there is a time window between __mmc_send_status() and time_afer(), on some eMMC chip, the timeout_ms is only 10ms, if this thread was scheduled out during this period, then, even card has already changes to transfer state by the result of CMD13, this part of code also treat it to timeout error. So, need calculate timeout first, then call __mmc_send_status(), if already timeout and card still in programing state, then treat it to the real timeout error. Signed-off-by: Chaotian Jing Signed-off-by: Ulf Hansson

mmc: enable MMC/SD/SDIO device to suspend/resume asynchronously

2015-12-22T10:32:16Z

Now, PM core supports asynchronous suspend/resume mode for devices during system suspend/resume, and the power state transition of one device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch enables MMC/SD/SDIO card and SDIO function devices to suspend/resume asynchronously. This will take advantage of multicore and improve system suspend/resume speed. After applying this patch and enabling all SDIO function's child devices to suspend/resume asynchronously on ASUS T100TA, the system suspend-to-idle time is reduced from 1645ms to 1108ms, and the system resume time is reduced from 940ms to 918ms. Signed-off-by: Zhonghui Fu Signed-off-by: Ulf Hansson

mmc: sdio: Fix invalid vdd in voltage switch power cycle

2015-12-22T10:32:15Z

The 'ocr' parameter passed to mmc_set_signal_voltage() defines the power-on voltage used when power cycling after a failure to set the voltage. However, in the case of mmc_sdio_init_card(), the value passed has the R4_18V_PRESENT flag set which is not valid for power-on and results in an invalid vdd. Fix by passing the card's ocr value which does not have the flag. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Ulf Hansson