user/sven/linux.git/drivers/mmc, branch v4.4.2

mmc: remove bondage between REQ_META and reliable write

2015-11-09T13:04:52Z

Anytime a write operation is performed with Reliable Write flag enabled, the eMMC device is enforced to bypass the cache and do a write to the underling NVM device by Jedec specification; this causes a performance penalty since write operations can't be optimized by the device cache. In our tests, we replayed a typical mobile daily trace pattern and found ~9% overall time reduction in trace replay by using this patch. Also the write ops within 4KB~64KB chunk size range get a 40~60% performance improvement by using the patch (as this range of write chunks are the ones affected by REQ_META). This patch has been discussed in the Mobile & Embedded Linux Storage Forum and it's the results of feedbacks from many people. We also checked with fsdevl and f2fs mailing list developers that this change in the usage of REQ_META is not affecting FS behavior and we got positive feedbacks. Reporting here the feedbacks: http://comments.gmane.org/gmane.linux.file-systems/97219 http://thread.gmane.org/gmane.linux.file-systems.f2fs/3178/focus=3183 Signed-off-by: Bruce Ford Signed-off-by: Luca Porzio Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices") Signed-off-by: Ulf Hansson

mmc: MMC_GOLDFISH should depend on HAS_DMA

2015-11-09T12:16:45Z

If NO_DMA=y: ERROR: dma_unmap_sg [drivers/mmc/host/android-goldfish.ko] undefined! ERROR: dma_alloc_coherent [drivers/mmc/host/android-goldfish.ko] undefined! ERROR: dma_map_sg [drivers/mmc/host/android-goldfish.ko] undefined! ERROR: dma_free_coherent [drivers/mmc/host/android-goldfish.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson

mmc: mediatek: Preinitialize delay_phase in get_best_delay()

2015-11-09T12:16:44Z

drivers/mmc/host/mtk-sd.c: In function ‘get_best_delay’: drivers/mmc/host/mtk-sd.c:1284: warning: ‘delay_phase.start’ is used uninitialized in this function drivers/mmc/host/mtk-sd.c:1284: warning: ‘delay_phase.maxlen’ is used uninitialized in this function If delay is zero, these fields are indeed not initialized. Let the compiler preinitialize the whole struct to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson

mmc: mmc: Improve reliability of mmc_select_hs400()

2015-11-09T12:16:32Z

mmc_select_hs400() calls __mmc_switch() which checks the switch is successful using CMD13 (SEND_STATUS). The problem is that it does that using the timing settings of the previous mode. That is prone to error, especially when switching from HS to HS400 because the timing parameters for HS mode are tighter than the timing parameters for HS400 mode. In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY) with the switch command, it must be assumed that using different modes on the card and host must work. However in the case when CMD13 polling is not used (i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs400() can be made more reliable by setting the host to the correct timing before sending CMD13. This patch does that. Signed-off-by: Adrian Hunter Cc: # 4.2+ Tested-by: Alim Akhtar Signed-off-by: Ulf Hansson

mmc: mmc: Move mmc_switch_status()

2015-11-09T12:16:26Z

Move the mmc_switch_status() function in preparation for calling it in mmc_select_hs400(). Signed-off-by: Adrian Hunter Cc: # 4.2+ Tested-by: Alim Akhtar Signed-off-by: Ulf Hansson

mmc: mmc: Fix HS setting in mmc_select_hs400()

2015-11-09T12:16:20Z

mmc_select_hs400() begins with the card and host in HS200 mode. Therefore, any commands sent to the card should use HS200 timing. It is incorrect to set the host to High Speed (HS) timing before sending the switch command. Doing so is unreliable because the timing parameters for HS mode are tighter than the timing parameters for HS200 mode. Thus the HS timings should be set only after the card has switched mode. However, it is not unreasonable first to reduce the frequency to the HS mode frequency, which should make the switch command and subsequent CMD13 commands more reliable. This patch does that. Signed-off-by: Adrian Hunter Cc: # 4.2+ Tested-by: Alim Akhtar Signed-off-by: Ulf Hansson

mmc: mmc: Improve reliability of mmc_select_hs200()

2015-11-09T12:12:08Z

Currently mmc_select_hs200() uses __mmc_switch() which checks the success of the switch to HS200 mode using CMD13 (SEND_STATUS). The problem is that it does that using the timing settings of legacy mode. That is prone to error, not least because the timing parameters for legacy mode are tighter than the timing parameters for HS200 mode. In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY) with the switch command, it must be assumed that using different modes on the card and host must work. However in the case when CMD13 polling is not used (i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs200() can be made more reliable by setting the host to the correct timing before sending CMD13. This patch does that. A complication is that the caller, mmc_select_timing(), will ignore a switch error (indicated by -EBADMSG), assume the old mode is valid and continue, so the old timing must be restored in that case. Signed-off-by: Adrian Hunter Cc: # 4.2+ Tested-by: Alim Akhtar Signed-off-by: Ulf Hansson

mmc: pxamci: fix read-only gpio detection polarity

2015-11-09T12:04:03Z

The commit converting pxamci to slot-gpio API inverted the logic of the read-only gpio. Fix it by inverting the logic again. Fixes: fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API") Signed-off-by: Robert Jarzmik Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson

Merge tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2015-11-05T21:15:12Z

Pull spi updates from Mark Brown: "Quite a lot of activity in SPI this cycle, almost all of it in drivers with a few minor improvements and tweaks in the core. - Updates to pxa2xx to support Intel Broxton and multiple chip selects. - Support for big endian in the bcm63xx driver. - Multiple slave support for the mt8173 - New driver for the auxiliary SPI controller in bcm2835 SoCs. - Support for Layerscale SoCs in the Freescale DSPI driver" * tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits) spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI spi: pxa2xx: Add support for Intel Broxton spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals spi: pxa2xx: Add output control for multiple Intel LPSS chip selects spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific spi: Add DSPI support for layerscape family spi: ti-qspi: improve ->remove() callback spi/spi-xilinx: Fix race condition on last word read spi: Drop owner assignment from spi_drivers spi: Add THIS_MODULE to spi_driver in SPI core spi: Setup the master controller driver before setting the chipselect spi: dw: replace magic constant by DW_SPI_DR spi: mediatek: mt8173 spi multiple devices support spi: mediatek: handle controller_data in mtk_spi_setup spi: mediatek: remove mtk_spi_config spi: mediatek: Update document devicetree bindings to support multiple devices spi: fix kernel-doc warnings about missing return desc in spi.c spi: fix kernel-doc warnings about missing return desc in spi.h spi: pxa2xx: Align a few defines spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select ...

Merge remote-tracking branches 'spi/topic/omap-100k', 'spi/topic/omap-uwire', 'spi/topic/owner', 'spi/topic/pxa' and 'spi/topic/pxa2xx' into spi-next

2015-11-04T11:02:12Z