- 29 Jun, 2017 7 commits
-
-
Jaehoon Chung authored
Remove the 'cur_slot'. Instead, just use 'slot'. There is no multiple slots, so we need to consider only one slot. Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Jaehoon Chung authored
Doesn't need to pass the id value for slot functions. Signed-off-by:
-
Jaehoon Chung authored
It doesn't need to use the array of slots anymore. Signed-off-by:
-
Jaehoon Chung authored
dwmmc controller has used the only one slot. It doesn't need to check the other slots. Remove the loop about finding slots. Signed-off-by:
-
Jaehoon Chung authored
dwmmc controller is supporting only one slot per a IP. Even though DWMMC IP is provided the multiple slot, but there is no usage in real world. In mmc subsystem, not allow the multiple slot concept. Then "num-slots" property is deprecated. Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.comi> Reviewed-by:
-
Shawn Lin authored
Currently we unconditionally do tuning for each degree, which costs 900ms for each boot and resume. May someone argue that this is a question of accuracy VS time. But I would say it's a trick of how we need to do decision for our boards. If we don't care the time we spend at all, we could definitely do tuning for each degree. But when we need to improve the user experience, for instance, speed up resuming from S3, we should also have the right to do that. This patch add parsing "rockchip,desired-num-phases", for folks to specify the number of doing tuning. If not specified, 360 will be used as before. Signed-off-by:
-
Shawn Lin authored
By default, dw_mmc-rockchip will execute tuning for each degree. So we won't miss every point of the good sample windows. However, probably the phases are linear inside the good sample window. Actually we don't need to do tuning for each degree so that we could save some time, for instance, probe the driver or resume from S3. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 20 Jun, 2017 33 commits
-
-
Simon Horman authored
Trivial updates to improve checkpatch cleanness. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
-
Simon Horman authored
Trivial updates to improve checkpatch cleanness. Signed-off-by:
-
Adrian Hunter authored
Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Adrian Hunter authored
Add host capability MMC_CAP_CD_WAKE to enable irq wake on the card detect irq. Signed-off-by:
-
Ulf Hansson authored
The MMC_CAP2_HC_ERASE_SZ is used only by a few mmc host drivers. Its intent is to enable eMMC's high-capacity erase size, as to improve the behaviour of the erase operations. We should strive to avoid software configuration options that aren't necessary, but instead deploy common behaviours. For these reasons, let's remove the capability bit for MMC_CAP2_HC_ERASE_SZ and make it the default behaviour. Note that this change doesn't affect eMMCs supporting trim/discard, because these commands operates on sectors and takes precedence over erase commands. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Wolfram Sang authored
Some errors are flagged only with the next command after a multiblock transfer, e.g. ECC error. So, when checking for data transfer errors, we check the result from the stop command as well. Signed-off-by:
-
Wolfram Sang authored
To detect errors like ECC errors, we must parse the R1 response bits. Introduce a helper function to also set the error value of a command when R1 error bits are set. Add ECC error to list of flags checked. Use the new helper for the stop command to call mmc_blk_recovery when detecting ECC errors which are only flagged on the next command after multiblock. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Ulf Hansson authored
To make the code more consistent and to increase readability, add an mmc_spi_send_csd() function, which gets called from mmc_send_csd() in case of SPI mode. Signed-off-by:
-
Ulf Hansson authored
Signed-off-by:
-
Ulf Hansson authored
Instead of having the caller to check for SPI mode, let's leave that to internals of mmc_send_cid(). In this way the code gets cleaner and it becomes clear what is specific to SPI and non-SPI mode. Signed-off-by:
-
Ulf Hansson authored
The mmc_send_cid() is never called using non SPI mode. Thus, let's remove the redundant code dealing with this. Signed-off-by:
-
Ulf Hansson authored
Signed-off-by:
-
Ulf Hansson authored
The mmc_flush_cache() is a eMMC specific function, let's move it to mmc_ops.c to make that clear. Signed-off-by:
-
Ulf Hansson authored
The mmc_interrupt_hpi() is a eMMC specific function, let's move it to mmc_ops.c to make that clear. The move also enables us to make mmc_send_hpi_cmd() static, so let's do that change as well. Signed-off-by:
-
Ulf Hansson authored
The mmc_start_bkops(), mmc_stop_bkops() and mmc_read_bkops_status() functions are all specific to eMMCs. To make this clear, let's move them from from core.c to mmc_ops.c and take the opportunity to make mmc_read_bkops_status() static. While moving them, get rid of MMC_BKOPS_MAX_TIMEOUT (4 min) and use the common default timeout MMC_OPS_TIMEOUT_MS (10 min) instead, as there is no need to have specific default timeout for bkops. Signed-off-by:
-
Ulf Hansson authored
The mmc_start|stop_bkops(), mmc_read_bkops_status() and mmc_interrupt_hpi() functions are all used from within the mmc core module, thus there are no need to use EXPORT_SYMBOL() for them, so let's remove it. Signed-off-by:
-
Kishon Vijay Abraham I authored
Document deprecation of "vmmc_aux" for io regulator and use of generic mmc binding "vqmmc" in omap-hsmmc. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Acked-by:
-
Kishon Vijay Abraham I authored
In preparation for using the generic mmc binding for io regulator ("vqmmc"), use mmc_regulator_get_supply() to get vmmc and vqmmc regulators. Only if "vqmmc" regulator isn't found, fallback to use "vmmc_aux" regulator. Signed-off-by: -
Kishon Vijay Abraham I authored
Do not initialize MMC regulators to NULL on error in omap_hsmmc driver similar to what is done in mmc_regulator_get_supply(). This is in preparation for using mmc_regulator_get_supply() to get MMC regulators. Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 94647a30 ("ARM: dts: omap3-overo: Enable WiFi/BT combo") while enabling WiFi/BT combo added regulator to trigger the nReset signal of the Bluetooth module in vqmmc-supply. However BT should be handled by UART. Moreover "vqmmc" is not a defined binding for omap_hsmmc. While "vqmmc" in mmc2 hasn't caused any issues so far, mmc2 will start to mis-behave once omap_hsmmc defines "vqmmc" binding. Remove "vqmmc-supply" property in mmc2 here. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Adrian Hunter authored
Drivers core will runtime suspend a device with no driver. That means the SDIO card will be runtime suspended as soon as it is added. It is then runtime resumed to add each function. That is entirely pointless, so add pm runtime get/put to keep the SDIO card runtime resumed until the function devices have been added. Signed-off-by:
-
Adrian Hunter authored
The error path deletes the device by calling mmc_sdio_remove() which must be called without the host claimed. Simplify the error path so it does just that and add a comment about why we don't disable runtime PM. Signed-off-by:
-
Adrian Hunter authored
Add PCI ids and enhanced strobe support for Intel CNP. This is combined with GLK due to the pending CMDQ support which they both share. Signed-off-by:
-
Simon Horman authored
Update copyrights to reflect work by Wolfram Sang and myself since last year. Signed-off-by:
-
Simon Horman authored
Use EXPORT_SYMBOL_GPL rather than the non _GPL variant as there seems to be no reason not to. Signed-off-by:
-
Simon Horman authored
Update files for tmio/sdhi MMC driver to reflect recent filename changes. Signed-off-by:
-
Hans de Goede authored
The acpi-subsys already calls acpi_bus_get_status() and checks that device->status.present is set before even registering the platform_device so out probe function will never get called if device->status.present is false and there is no need for this check. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Wolfram Sang authored
To achieve that, we set the registers in the generic HW reset routine which gets called at both, init and resume. We also make sure to move SDIO initialization before reset gets called in probe(). Signed-off-by:
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by:
-
Matthias Kraemer authored
This patch applies customized PCI_DEVICE_ macros to specify the pci_ids instead of open-coding them within the sdhci-pci driver. By introducing device specific macros the pci_ids table becomes much shorter and easier to comprehend than it would be possible using the generic version of the PCI_DEVICE_ macros. Signed-off-by:
Matthias Kraemer <matthiasmartinsson@gmail.com> Acked-by:
-
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:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
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:
-
