kernel/linux.git/drivers/mmc/core/core.c, branch linux-4.7.y

mmc: longer timeout for long read time quirk

2016-05-23T09:52:40+00:00

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

mmc: core: Do regular power cycle when lacking eMMC HW reset support

2016-05-02T08:33:24+00:00

The eMMC HW reset may be implemented either via the host ops ->hw_reset() callback or through DT and the eMMC pwrseq. Additionally some eMMC cards don't support HW reset. To allow a reset to be done for the different combinations of mmc hosts and eMMC/MMC cards, let's implement a fallback via trying a regular power cycle. This improves the mmc block layer retry mechanism of failing I/O requests. Signed-off-by: Gwendal Grignou [Ulf: Rewrote changelog] Signed-off-by: Ulf Hansson

mmc: core: Provide tracepoints for request processing

2016-05-02T08:33:11+00:00

This patch provides some tracepoints for the lifecycle of a mmc request from starting to completion to help with performance analysis of MMC subsystem. Signed-off-by: Baolin Wang Signed-off-by: Ulf Hansson

mmc: core: report tuning command execution failure reason

2016-02-29T10:03:08+00:00

Print the error code when the tuning command fails. This allows the reason for the failure to be reported, which aids debugging. Signed-off-by: Russell King Signed-off-by: Ulf Hansson

mmc: core: improve mmc_of_parse_voltage() to return better status

2016-02-29T10:03:07+00:00

Improve mmc_of_parse_voltage()'s return values so that drivers can tell whether a voltage-range specification was present, and whether it has been successfully parsed, or there was an error while parsing. We return a negative errno when parsing fails, zero if no voltage-range specification is present, or one if a voltage-range specification is successfully parsed. No users need modifying as no users check the return value. Signed-off-by: Russell King Signed-off-by: Ulf Hansson

mmc: core: shut up "voltage-ranges unspecified" pr_info()

2016-02-29T10:03:07+00:00

Each time a driver such as sdhci-esdhc-imx is probed, we get a info printk complaining that the DT voltage-ranges property has not been specified. However, the DT binding specifically says that the voltage-ranges property is optional. That means we should not be complaining that DT hasn't specified this property: by indicating that it's optional, it is valid not to have the property in DT. Silence the warning if the property is missing. Signed-off-by: Russell King Signed-off-by: Ulf Hansson

mmc: sanitize 'bus width' in debug output

2016-02-29T10:02:56+00:00

The bus width is sometimes the actual bus width, and sometimes indices to different arrays encoding the bus width. In my debugging case "2" could mean 8-bit as well as 4-bit, which was extremly confusing. Let's use the human-readable actual bus width in all places. Signed-off-by: Wolfram Sang Signed-off-by: Ulf Hansson

mmc: core: use the defined function to check whether card is removable

2016-02-29T10:02:56+00:00

In linux/mmc/host.h, mmc_card_is_removable() is already defined. There is no reason that it doesn't use. Signed-off-by: Jaehoon Chung Signed-off-by: Ulf Hansson

mmc: core: Optimize boot time by detecting cards simultaneously

2015-12-28T09:08:09+00:00

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: Introduce MMC_CAP2_NO_SDIO cap

2015-12-22T10:32:13+00:00

This patch introduce a new MMC_CAP2_NO_SDIO cap used to tell the mmc core to not send SDIO specific commands. Signed-off-by: Carlo Caione Signed-off-by: Ulf Hansson