user/sven/linux.git/include/linux/mmc, branch v4.4.3

mmc: mmc: extend the mmc_send_tuning()

2015-10-27T09:38:41Z

The mmc_execute_tuning() has already prepared the opcode, there is no need to prepare it again at mmc_send_tuning(), and, there is a BUG of mmc_send_tuning() to determine the opcode by bus width, assume eMMC was running at HS200, 4bit mode, then the mmc_send_tuning() will overwrite the opcode from CMD21 to CMD19, then got error. in addition, extend an argument of "cmd_error" to allow getting if there was cmd error when tune response. Signed-off-by: Chaotian Jing [Ulf: Rebased patch] Signed-off-by: Ulf Hansson

mmc: dw_mmc: Add external dma interface support

2015-10-26T15:00:16Z

DesignWare MMC Controller can supports two types of DMA mode: external dma and internal dma. We get a RK312x platform integrated dw_mmc and ARM pl330 dma controller. This patch add edmac ops to support these platforms. I've tested it on RK31xx platform with edmac mode and RK3288 platform with idmac mode. Signed-off-by: Shawn Lin Signed-off-by: Jaehoon Chung Signed-off-by: Ulf Hansson

mmc: core: Add mmc_regulator_set_vqmmc()

2015-10-26T15:00:10Z

This adds logic to the MMC core to set VQMMC. This is expected to be called by MMC drivers like dw_mmc as part of (or instead of) their start_signal_voltage_switch() callback. A few notes: * When setting the signal voltage to 3.3V we do our best to make VQMMC and VMMC match. It's been reported that this makes some old cards happy since they were tested back in the day before UHS when VQMMC and VMMC were provided by the same regulator. A nice side effect of this is that we don't end up on the hairy edge of VQMMC (2.7V), which some EEs claim is a little too close to the minimum for comfort. This is done in two steps. At first we try to find a VQMMC within a 0.3V tolerance of VMMC and if this is not supported by the supplying regulator we try to find a suitable voltage within the whole 2.7V-3.6V area of the spec. * The two step approach is currently necessary, as the used regulator_set_voltage_triplet(min, target, max) uses a simple implementation that just tries two basic steps: regulator_set_voltage(target, max); regulator_set_voltage(min, target); So with only one step with 2.7-3.6V borders, if a suitable voltage is a bit below VMMC, we would directly get the lowest 2.7V which some boards (like Rockchips) don't like at all. * When setting the signal voltage to 1.8V or 1.2V we aim for that specific voltage instead of picking the lowest one in the range. * We very purposely don't print errors in mmc_regulator_set_vqmmc(). There are cases where the MMC core will try several different voltages and we don't want to pollute the logs. Signed-off-by: Douglas Anderson Signed-off-by: Heiko Stuebner Signed-off-by: Ulf Hansson

mmc: core: Remove MMC_CLKGATE

2015-10-26T15:00:09Z

MMC_CLKGATE was once invented to save power by gating the bus clock at request inactivity. At that time it served its purpose. The modern way to deal with power saving for these scenarios, is by using runtime PM. Nowadays, several host drivers have deployed runtime PM, but for those that haven't and which still cares power saving at request inactivity, it's certainly time to deploy runtime PM as it has been around for several years now. To simplify code to mmc core and thus decrease maintenance efforts, this patch removes all code related to MMC_CLKGATE. Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij

mmc: core: Convert __mmc_switch() into an internal core function

2015-10-26T14:59:54Z

As there are no users of the __mmc_switch() API, except for the mmc core itself, let's convert it from an exported function into an internal. Signed-off-by: Ulf Hansson

mmc: block: skip trim for some kingston eMMCs

2015-08-27T12:50:52Z

For some mass production of kingston eMMCs which adopt Phison's firmware will meet an unrecoverable data conrruption occasionally if performing trim due to a firmware bug confirmed by vendor. We found it on Intel-C3230RK platform. So we add fixup of broken trim for it. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: dw_mmc: add quirk for broken data transfer over scheme

2015-08-17T10:45:28Z

This patch add a new quirk to add a s/w timer to notify the driver to terminate current transfer and report a data timeout to the core, if DTO interrupt does NOT come within the given time. dw_mmc call mmc_request_done func to finish transfer depends on DTO interrupt. If DTO interrupt does not come in sending data state, the current transfer will be blocked. We got the reply from synopsys: There are two counters but both use the same value of [31:8] bits. Data timeout counter doesn't wait for stop clock and you should get DRTO even when the clock is not stopped. Host Starvation timeout counter is triggered with stop clock condition. This means that host should get DRTO and DTO interrupt. But this case really exists, when driver reads tuning data from card on RK3288-pink2 board. I measured waveforms by oscilloscope and found that card clock was always on and data lines were always holded high level in sending data state. There are two possibility that data over interrupt doesn't come in reading data state on RK3X SoCs: - get command done interrupt, but doesn't get any data-related interrupt. - get data error interrupt, but doesn't get data over interrupt. Signed-off-by: Addy Ke Signed-off-by: Heiko Stuebner Signed-off-by: Jaehoon Chung

mmc: dw_mmc: remove the unused blk_setting

2015-08-17T10:45:27Z

"blk_setting" doesn't use anywhere. Signed-off-by: Jaehoon Chung

mmc: dw_mmc: fix pio mode when internal dmac is enabled

2015-08-17T10:44:43Z

The dw_mci_init_dma() may decide to not use dma, but pio instead, caused by things like wrong dma settings in the system. Till now the code dw_mci_init_slot() always assumed that dma is available when CONFIG_MMC_DW_IDMAC was defined, ignoring the host->use_dma var set during dma init. So when now the dma init failed for whatever reason, the transfer sizes would still be set for dma transfers, especially including the maximum block-count calculated from host->ring_size and resulting in a [ 4.991109] ------------[ cut here ]------------ [ 4.991111] kernel BUG at drivers/mmc/core/core.c:256! [ 4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM because host->ring_size is 0 in this case and the slot init code uses the wrong code to calculate the values. Fix this by selecting the correct calculations using the host->use_dma variable instead of the CONFIG_MMC_DW_IDMAC config option. Signed-off-by: Heiko Stuebner Signed-off-by: Jaehoon Chung

mmc: sdio: avoid using NULL sdio_irq_thread pointer

2015-08-17T09:32:46Z

For Freescale QorIQ LS1021AQDS board, there is a SDIO interrupt in the process of resume without inserting SD adapter because of some unknown issue. But the driver doesn't assign sdio_irq_thread pointer. This will block the resume of kernel. This patch is used to avoid using NULL sdio_irq_thread pointer. Signed-off-by: Yangbo Lu Signed-off-by: Ulf Hansson