- 20 Jun, 2017 40 commits
-
-
Benoît Thébaudeau authored
The SDHCI_QUIRK_NO_MULTIBLOCK quirk was used as a workaround for the ENGcm07207 erratum. However, it caused excruciatingly slow SD transfers (300 kB/s on average), and this erratum actually does not imply that multiple-block transfers are not supported, so this was overkill. The suggested workaround for this erratum is to set SYSCTL.RSTA, but the simple DAT line software reset (which resets the DMA circuit among others) triggered by sdhci_finish_data() in case of errors seems to be sufficient. Indeed, generating errors in a controlled manner on i.MX25 using the FEVT register right in the middle of read data transfers without this quirk shows that nothing is written to the buffer by the eSDHC past CMD12, and no extra Auto CMD12 is sent with AC12EN set, so the data transfers on AHB are properly aborted. For write data transfers, neither extra data nor extra Auto CMD12 is sent, as expected. Moreover, after intensive stress tests on i.MX25, removing SDHCI_QUIRK_NO_MULTIBLOCK seems to be safe. SDHCI_QUIRK_BROKEN_ADMA has nothing to do with ENGcm07207, so set ESDHC_FLAG_ERR004536 for the devices that had ESDHC_FLAG_ENGCM07207 set in order to continue getting SDHCI_QUIRK_BROKEN_ADMA. Signed-off-by:
Benoît Thébaudeau <benoit@wsystem.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Benoît Thébaudeau authored
On i.MX, SYSCTL.SDCLKFS may always be set to 0 in order to make the SD clock frequency prescaler divide by 1 in SDR mode, even with the eSDHC. The previous minimum prescaler value of 2 in SDR mode with the eSDHC was a code remnant from PowerPC, which actually has this limitation on earlier revisions. In DDR mode, the prescaler can divide by up to 512. The maximum SD clock frequency in High Speed mode is 50 MHz. On i.MX25, this change makes it possible to get 48 MHz from the USB PLL (240 MHz / 5 / 1) instead of only 40 MHz from the USB PLL (240 MHz / 3 / 2) or 33.25 MHz from the AHB clock (133 MHz / 2 / 2). Signed-off-by:
-
Benoît Thébaudeau authored
On i.MX25, the eSDHC DAT line software reset (SYSCTL.RSTD) unexpectedly clears at least the data transfer width (PROCTL.DTW), which then results in data CRC errors. This behavior is not documented, but it has actually been observed. Consequently, the DAT line software resets triggered by sdhci.c in case of errors caused unrecoverable errors. Fix this by making sure that the DAT line software reset does not alter the Host Control register. This behavior being undocumented, it may also be present on other i.MX SoCs, so apply this fix for the whole i.MX family. Signed-off-by:
-
Benoît Thébaudeau authored
The eSDHC can only DMA from 32-bit-aligned addresses. This fixes the following test cases of mmc_test: 11: Badly aligned write 12: Badly aligned read 13: Badly aligned multi-block write 14: Badly aligned multi-block read Signed-off-by:
-
Benoît Thébaudeau authored
Fix various English mistakes and typos in comments and in printed strings. Signed-off-by:
-
Phong LE authored
The dma gpd dma_free_coherent call size in invalid. Fixes: 20848903 ("mmc: mediatek: Add Mediatek MMC driver") Signed-off-by:
Phong LE <ple@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Null check at line 1165: if (mrq->cmd), implies that mrq->cmd might be NULL. Add null checks before dereferencing pointer mrq->cmd in order to avoid any potential NULL pointer dereference. Addresses-Coverity-ID: 1408740 Tested-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Wolfram Sang authored
It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
David Woods authored
Using the device_property interfaces allows mmc drivers to work on platforms which run on either device tree or ACPI. Signed-off-by:
David Woods <dwoods@mellanox.com> Reviewed-by:
Chris Metcalf <cmetcalf@mellanox.com> Cc: stable@vger.linux.org Signed-off-by:
-
David Woods authored
Using the device_property interfaces allows the dw_mmc driver to work on platforms which run on either device tree or ACPI. Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Shawn Lin authored
Add "rockchip,rk3328-dw-mshc", "rockchip,rk3288-dw-mshc" for dwmmc on rk3328 platform. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
Fabio Estevam authored
clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Signed-off-by:
-
Wu Fengguang authored
drivers/mmc/core/block.c:1929:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Ulf Hansson authored
The only reason to why the mmc block device driver needs to implements its own version of how to get the status of the card, is that it needs to specify a different amount of retries. Therefore add a new exported function which allows the caller to specify the number of retries and convert everybody to use it, as this simplifies the code. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This moves the boot partition lock command (issued from sysfs) into a custom block layer request, just like the ioctl()s, getting rid of yet another instance of mmc_get_card(). Since we now have two operations issuing special DRV_OP's, we rename the result variable ->drv_op_result. Tested by locking the boot partition from userspace: > cd /sys/devices/platform/soc/80114000.sdi4_per2/mmc_host/mmc3/ mmc3:0001/block/mmcblk3/mmcblk3boot0 > echo 1 > ro_lock_until_next_power_on [ 178.645324] mmcblk3boot1: Locking boot partition ro until next power on [ 178.652221] mmcblk3boot0: Locking boot partition ro until next power on Also tested this with a huge dd job in the background: it is now possible to lock the boot partitions on the card even under heavy I/O. Signed-off-by: -
Linus Walleij authored
We will need to access static functions above the pure block layer operations in the file, so move the driver operations issue function down so we can see all non-blocklayer symbols. Signed-off-by:
-
Linus Walleij authored
We will expand the DRV_OP usage, so we need to know which operation we're performing. Tag the operations with an enum:ed type and rename the function so it is clear that it deals with any command and put a switch statement in it. Currently only ioctls are supported. Signed-off-by:
-
Linus Walleij authored
Just as we can use blk_mq_rq_from_pdu() to get the per-request tag we can use blk_mq_rq_to_pdu() to get a request from a tag. Introduce a static inline helper so we are on the clear what is happening. Suggested-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
-
Wolfram Sang authored
Plain code move with no changes. Needed for refactoring. Also, looks nicer if request and finish_request are next to each other. Reviewed-by:
-
Wolfram Sang authored
The obviously wrong comment was added in 2011 with commit df3ef2d3 ("mmc: protect the tmio_mmc driver against a theoretical race") but already obsoleted half a year later with commit b9269fdd ("mmc: tmio: fix recursive spinlock, don't schedule with interrupts disabled"). Fixes: b9269fdd ("mmc: tmio: fix recursive spinlock, don't schedule with interrupts disabled") Reviewed-by:
-
Wolfram Sang authored
Split handling mrq into a seperate function. We need to call it from another place soon. Reviewed-by:
-
Wolfram Sang authored
This part confused me and I had to read it twice until I got it. Let's follow the standard pattern to bail out if something is wrong and keep in the body of the function when everything is as expected. Reviewed-by:
-
Markus Elfring authored
Omit an extra message for memory allocation failures. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
Omit an extra message for a memory allocation failure. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by:
-
Linus Walleij authored
commit cdf8a6fb "mmc: block: Introduce queue semantics" deleted the last user of mmc_req_is_special() and it was a horrible hack to classify requests as "special" or "not special" to begin with, so delete the helper. Signed-off-by:
-
Linus Walleij authored
This switches also the multiple-command ioctl() call to issue all ioctl()s through the block layer instead of going directly to the device. We extend the passed argument with an argument count and loop over all passed commands in the ioctl() issue function called from the block layer. By doing this we are again loosening the grip on the big host lock, since two calls to mmc_get_card()/mmc_put_card() are removed. Signed-off-by:
Avri Altman <Avri.Altman@sandisk.com>
-
Linus Walleij authored
This wraps single ioctl() commands into block requests using the custom block layer request types REQ_OP_DRV_IN and REQ_OP_DRV_OUT. By doing this we are loosening the grip on the big host lock, since two calls to mmc_get_card()/mmc_put_card() are removed. We are storing the ioctl() in/out argument as a pointer in the per-request struct mmc_blk_request container. Since we now let the block layer allocate this data, blk_get_request() will allocate it for us and we can immediately dereference it and use it to pass the argument into the block layer. We refactor the if/else/if/else ladder in mmc_blk_issue_rq() as part of the job, keeping some extra attention to the case when a NULL req is passed into this function and making that pipeline flush more explicit. Tested on the ux500 with the userspace: mmc extcsd read /dev/mmcblk3 resulting in a successful EXTCSD info dump back to the console. This commit fixes a starvation issue in the MMC/SD stack that can be easily provoked in the following way by issueing the following commands in sequence: > dd if=/dev/mmcblk3 of=/dev/null bs=1M & > mmc extcs read /dev/mmcblk3 Before this patch, the extcsd read command would hang (starve) while waiting for the dd command to finish since the block layer was holding the card/host lock. After this patch, the extcsd ioctl() command is nicely interpersed with the rest of the block commands and we can issue a bunch of ioctl()s from userspace while there is some busy block IO going on without any problems. Conversely userspace ioctl()s can no longer starve the block layer by holding the card/host lock. Signed-off-by:
-
Linus Walleij authored
The variable is_rpmb is clearly a bool and even assigned true and false, yet declared as an int. Signed-off-by:
-
Linus Walleij authored
The mmc_queue_req is a per-request state container the MMC core uses to carry bounce buffers, pointers to asynchronous requests and so on. Currently allocated as a static array of objects, then as a request comes in, a mmc_queue_req is assigned to it, and used during the lifetime of the request. This is backwards compared to how other block layer drivers work: they usally let the block core provide a per-request struct that get allocated right beind the struct request, and which can be obtained using the blk_mq_rq_to_pdu() helper. (The _mq_ infix in this function name is misleading: it is used by both the old and the MQ block layer.) The per-request struct gets allocated to the size stored in the queue variable .cmd_size initialized using the .init_rq_fn() and cleaned up using .exit_rq_fn(). The block layer code makes the MMC core rely on this mechanism to allocate the per-request mmc_queue_req state container. Doing this make a lot of complicated queue handling go away. We only need to keep the .qnct that keeps count of how many request are currently being processed by the MMC layer. The MQ block layer will replace also this once we transition to it. Doing this refactoring is necessary to move the ioctl() operations into custom block layer requests tagged with REQ_OP_DRV_[IN|OUT] instead of the custom code using the BigMMCHostLock that we have today: those require that per-request data be obtainable easily from a request after creating a custom request with e.g.: struct request *rq = blk_get_request(q, REQ_OP_DRV_IN, __GFP_RECLAIM); struct mmc_queue_req *mq_rq = req_to_mq_rq(rq); And this is not possible with the current construction, as the request is not immediately assigned the per-request state container, but instead it gets assigned when the request finally enters the MMC queue, which is way too late for custom requests. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com>
-
Linus Walleij authored
This option is activated by all multiplatform configs and what not so we almost always have it turned on, and the memory it saves is negligible, even more so moving forward. The actual bounce buffer only gets allocated only when used, the only thing the ifdefs are saving is a little bit of code. It is highly improper to have this as a Kconfig option that get turned on by Kconfig, make this a pure runtime-thing and let the host decide whether we use bounce buffers. We add a new property "disable_bounce" to the host struct. Notice that mmc_queue_calc_bouncesz() already disables the bounce buffers if host->max_segs != 1, so any arch that has a maximum number of segments higher than 1 will have bounce buffers disabled. The option CONFIG_MMC_BLOCK_BOUNCE is default y so the majority of platforms in the kernel already have it on, and it then gets turned off at runtime since most of these have a host->max_segs > 1. The few exceptions that have host->max_segs == 1 and still turn off the bounce buffering are those that disable it in their defconfig. Those are the following: arch/arm/configs/colibri_pxa300_defconfig arch/arm/configs/zeus_defconfig - Uses MMC_PXA, drivers/mmc/host/pxamci.c - Sets host->max_segs = NR_SG, which is 1 - This needs its bounce buffer deactivated so we set host->disable_bounce to true in the host driver arch/arm/configs/davinci_all_defconfig - Uses MMC_DAVINCI, drivers/mmc/host/davinci_mmc.c - This driver sets host->max_segs to MAX_NR_SG, which is 16 - That means this driver anyways disabled bounce buffers - No special action needed for this platform arch/arm/configs/lpc32xx_defconfig arch/arm/configs/nhk8815_defconfig arch/arm/configs/u300_defconfig - Uses MMC_ARMMMCI, drivers/mmc/host/mmci.[c|h] - This driver by default sets host->max_segs to NR_SG, which is 128, unless a DMA engine is used, and in that case the number of segments are also > 1 - That means this driver already disables bounce buffers - No special action needed for these platforms arch/arm/configs/sama5_defconfig - Uses MMC_SDHCI, MMC_SDHCI_PLTFM, MMC_SDHCI_OF_AT91, MMC_ATMELMCI - Uses drivers/mmc/host/sdhci.c - Normally sets host->max_segs to SDHCI_MAX_SEGS which is 128 and thus disables bounce buffers - Sets host->max_segs to 1 if SDHCI_USE_SDMA is set - SDHCI_USE_SDMA is only set by SDHCI on PCI adapers - That means that for this platform bounce buffers are already disabled at runtime - No special action needed for this platform arch/blackfin/configs/CM-BF533_defconfig arch/blackfin/configs/CM-BF537E_defconfig - Uses MMC_SPI (a simple MMC card connected on SPI pins) - Uses drivers/mmc/host/mmc_spi.c - Sets host->max_segs to MMC_SPI_BLOCKSATONCE which is 128 - That means this platform already disables bounce buffers at runtime - No special action needed for these platforms arch/mips/configs/cavium_octeon_defconfig - Uses MMC_CAVIUM_OCTEON, drivers/mmc/host/cavium.c - Sets host->max_segs to 16 or 1 - Setting host->disable_bounce to be sure for the 1 case arch/mips/configs/qi_lb60_defconfig - Uses MMC_JZ4740, drivers/mmc/host/jz4740_mmc.c - This sets host->max_segs to 128 so bounce buffers are already runtime disabled - No action needed for this platform It would be interesting to come up with a list of the platforms that actually end up using bounce buffers. I have not been able to infer such a list, but it occurs when host->max_segs == 1 and the bounce buffering is not explicitly disabled. Signed-off-by:
-
Simon Horman authored
Make renesas_sdhi_sys_dmac.c a top-level module file that makes use of library code supplied by renesas_sdhi_core.c This is in order to facilitate adding other variants of SDHI; in particular SDHI using different DMA controllers. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Simon Horman authored
Rename the source file SDHI. A follow-up patch will make it a library file used by a different top-level module file. The name "renesas" is chosen as the SDHI driver is applicable to a wider range of SoCs than SH-Mobile it seems to be a more appropriate name. However, the SDHI driver source itself, is left as sh_mobile_sdhi to avoid unnecessary churn. the name "core" was chosen to reflect the desired role of this file, to provide core functionality to the sdhi driver. A follow-up patch will move the file into that role. Internal symbols have also been renamed to reflect the filename change. The .name member of struct platform_driver and parameter to MODULE_ALIAS() have not been changed in order to avoid the complication of potentially breaking SH SoCs which still use platform drivers. Signed-off-by:
-
Simon Horman authored
Rename the source file for DMA for SDHI as a follow-up to attaching DMA code to the SDHI driver rather than the tmio_core driver. The name "renesas" is chosen as the SDHI driver is applicable to a wider range of SoCs than SH-Mobile it seems to be a more appropriate name. However, the SDHI driver source itself, is left as sh_mobile_sdhi to avoid unnecessary churn. The name sys_dmac was chosen to reflect the type of DMA used. Internal symbols have also been renamed to reflect the filename change. A follow-up patch will re-organise the SDHI driver removing the need for renesas_sdhi_get_dma_ops(). Signed-off-by:
-
Simon Horman authored
Rename tmio_mmc_pio.c to tmio_mmc_core.c to more accurately reflect its function: to provide core code for the tmio-mmc and sh-mobole-sdhi drivers. Signed-off-by:
-
Simon Horman authored
Refactor DMA support to allow it to be provided by a set of call-backs that are provided by a host driver. The motivation is to allow multiple DMA implementations to be provided and instantiated at run-time. Instantiate the existing DMA implementation from the sh_mobile_sdhi driver which appears to match the current use-case. This has the side effect of moving the DMA code from the tmio_core to the sh_mobile_sdhi driver. A follow-up patch will change the source file for the SDHI DMA implementation accordingly. Another follow-up patch will re-organise the SDHI driver removing the need for tmio_mmc_get_dma_ops(). Signed-off-by:
-
Simon Horman authored
Reshuffle the comment at the top of the source dropping filenames and moving up human readable strings. This seems to be somewhat more useful information to start the source file with. It is also less fragile, f.e. to file renames. Signed-off-by:
-
Ulf Hansson authored
This reverts commit a6db2c86 ("mmc: dw_mmc: Don't allow Runtime PM for SDIO cards")' As dw_mmc now is capable of preventing runtime PM suspend while SDIO IRQs are enabled, let's drop the less fine-grained method, which is preventing runtime PM suspend for all SDIO cards - no matter of whether SDIO IRQs are being enabled or not. In this way we don't keep the host runtime PM resumed, unless it's really needed, thus avoiding to waste power. Especially when SDIO IRQs is supported via a separate out-of-band IRQ line, which isn't defined by the SDIO standard, typically the SDIO func driver doesn't enable SDIO IRQs via sdio_claim_irq(). So, for these cases we can now allow the dwmmc device to be runtime PM suspended in-between requests. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
Ulf Hansson authored
To be able to handle SDIO IRQs the dw_mmc device needs to be powered and providing clock to the SDIO card. Therefore, we must not allow the device to be runtime PM suspended while SDIO IRQs are enabled. To fix this, let's increase the runtime PM usage count while the mmc core enables SDIO IRQs. Later when the mmc core tells dw_mmc to disable SDIO IRQs, we drop the usage count to again allow runtime PM suspend. This now becomes the default behaviour for dw_mmc. In cases where SDIO IRQs can be re-routed as GPIO wake-ups during runtime PM suspend, one could potentially allow runtime PM suspend. However, that will have to be addressed as a separate change on top of this one. Signed-off-by:
-
