- 21 May, 2018 9 commits
-
-
Christoph Hellwig authored
This handles highmem pages, and also cleans up the code. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Shawn Lin authored
It's pointless to switch and trace partition type if the current selected device partition is the same with that one. Moreover, cycled claiming host associated with mmc_blk_part_switch() could make mmc_blk_remove() end up waiting for grabbing the context if it's occupied, which lead requests could still hit the low-level drivers, if an asynchronous unbind for host drivers happened, as the card hasn't been set removed in the remove path. So a simple dd in background: dd if=/dev/mmcblk0 of=/dev/null bs=512k count=100000 & and doing unbind then: echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind could make the console stuck for quite a while depending on the numbers of requests. Suggested-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
Jerome Brunet authored
Trigger the reset line of the mmc controller while probing, if available. The reset should be optional for now, at least until all related DT nodes have the reset property. Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
-
Jerome Brunet authored
Add the reset to the documentation of the meson-gx mmc controller bindings. Reviewed-by:
-
Liming Sun authored
This commit adds "mellanox,bluefield-dw-mshc" for dwmmc driver extension on Mellanox BlueField SoC platform. Signed-off-by:
Liming Sun <lsun@mellanox.com> Reviewed-by:
David Woods <dwoods@mellanox.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Liming Sun authored
This commit adds extension to the dw_mmc driver for Mellanox BlueField SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on this SoC. Signed-off-by:
-
Shawn Lin authored
The hard-coded 10ms delay in mmc_power_up came from commit 79bccc5a ("mmc: increase power up delay"), which said "The TI controller on Toshiba Tecra M5 needs more time to power up or the cards will init incorrectly or not at all." But it's too engineering solution for a special board but force all platforms to wait for that long time, especially painful for mmc_power_up for eMMC when booting. However, it's added since 2009, and we can't tell if other platforms benefit from it. But in practise, the modern hardware are most likely to have a stable power supply with 1ms after setting it for no matter PMIC or discrete power. And more importnatly, most regulators implement the callback of ->set_voltage_time_sel() for regulator core to wait for specific period of time for the power supply to be stable, which means once regulator_set_voltage_* return, the power should reach the the minimum voltage that works for initialization. Of course, if there are some other ways for host to power the card, we should allow them to argue a suitable delay as well. With this patch, we could assign the delay from firmware, or we could assigne it via ->set_ios() callback from host drivers. Signed-off-by:
-
Shawn Lin authored
post-power-on-delay-ms woule be reused to substitute the hard-coded 10ms delay waiting for power supply to be stable, specificed by individual platform/board. Default to 10ms as before, if no available. Signed-off-by:
-
Masaharu Hayakawa authored
This patch adds r8a77965 support in SDHI. Signed-off-by:
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Tested-by:
Simon Horman <horms+renesas@verge.net.au> Tested-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
- 08 May, 2018 10 commits
-
-
Aapo Vienamo authored
A redundant return statement is removed from tegra_sdhci_set_uhs_signaling(). The function returns void and the return does not affect the control flow of the function. Signed-off-by:
Aapo Vienamo <aapo.vienamo@iki.fi> Acked-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Ulf Hansson authored
MMC_CORE_TIMEOUT_MS isn't being used no more, let's drop it. Signed-off-by: -
Ulf Hansson authored
Signed-off-by:
Michał Pecio <michal.pecio@gmail.com>
-
Ulf Hansson authored
Instead of using a fixed 3s timeout for commands with R1B responses, convert to use the per request calculated busy timeout from the mmc core. This is needed to cope with requests that requires longer timeout, for example erase/discard commands. Signed-off-by:
-
Ulf Hansson authored
Instead of having to return -EINVAL when requested to send SDIO specific commands, let's set MMC_CAP2_NO_SDIO as it completely prevents them. Signed-off-by:
-
Ulf Hansson authored
Let's implement the ->sw_reset() bus ops to allow SDIO func drivers, in particular, to make a SW reset without doing a full power cycle of the SDIO card. Signed-off-by:
Quentin Schulz <quentin.schulz@bootlin.com> Reviewed-by:
-
Ulf Hansson authored
Move the corresponding code for setting the initial signal voltage, from mmc_power_up() into a new function, mmc_set_initial_signal_voltage(). Make the function internally available to the mmc core, as to allow the following changes to make use of it. Signed-off-by:
-
Ulf Hansson authored
It's rather common that a firmware is loaded into an SDIO func device memory, by the corresponding SDIO func driver during ->probe() time. However, to actually start running the new firmware, sometimes a soft reset (no power cycle) and a re-initialization of the card is needed. This is for example the case with the Espressif ESP8089 WiFi chips, when connected to an SDIO interface. To cope with this scenario, let's add a new exported function, mmc_sw_reset(), which may be called when a soft reset and re-initialization of the card are needed. The mmc_sw_reset() is implemented on top of a new bus ops callback, similar to how the mmc_hw_reset() has been implemented. Signed-off-by:
-
Ulf Hansson authored
The bus ops ->reset() executes a full HW reset of the card, as the calling function mmc_hw_reset() also indicates by its name. Let's convert to follow the similar names, for both the bus ops callback and for the corresponding bus ops functions, as to clarify the purpose of code. Signed-off-by:
-
Ulf Hansson authored
The mmc_sdio_init_card() function has a couple of callers. In the re-initialization cases, some additional reset commands are issued before mmc_sdio_init_card() is called. As these additional reset commands are the same, let's move these into a new static function, mmc_sdio_reinit_card() and call mmc_sdio_init_card() from there. In this way we avoid the open coding. Signed-off-by:
-
- 03 May, 2018 17 commits
-
-
Ulf Hansson authored
Merge immutable branch for sdhci-omap to add UHS/HS200 mode support. Signed-off-by: -
Shawn Lin authored
Allow to use tunable delay before detecting card after card is inserted, which either comes from firmware node, or comes from debounce value passed on to mmc_gpiod_request_cd(). If the platform doesn't support debounce, then we fall back to use the debounce period as the delay, otherwise, it behaves the same as before that a HW debounce(if set) plus a 200ms hardcode delay before detecting the card. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Shawn Lin authored
cd-gpios uses a fixed delay, 200ms, before detecting card after the card is inserted. 200ms doesn't work for some platforms, so some host drivers added their own properties for parsing that from DT, for instance, dw_mmc and pxamci. That being said, it should also be tunable when using cd-gpios. Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 8d20b2ea ("mmc: sdhci_omap: Add support to set IODELAY values") stored IODelay values for all MM/SD modes in pinctrl_state structure member of sdhci_omap_host. However for DDR mode it gets IODelay values only for 1.8v DDR mode. Since some of the platforms which uses sdhci-omap has IO lines connected to 3.3v, get IODelay values for 3.3v DDR mode. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
Add pinctrl binding rquired to get the mux mode and IODelay values from devicetree. Signed-off-by:
-
Kishon Vijay Abraham I authored
Add sdhci_omap_enable_sdio_irq to set CTPL and CLKEXTFREE bits in MMCHS_CON register required to detect asynchronous card interrupt on DAT[1]. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
Add support for the new compatible added specifically to support k2g's MMC/SD controller. Signed-off-by:
-
Kishon Vijay Abraham I authored
Add binding for the TI's sdhci-omap controller present in K2G. Signed-off-by:
-
Kishon Vijay Abraham I authored
Errata i834 in AM572x Sitara Processors Silicon Revision 2.0, 1.1 (SPRZ429K July 2014–Revised March 2017 [1]) mentions the maximum obtainable timeout through MMC host controller is 700ms. And for commands taking longer than 700ms, hardware timeout should be disabled and software timeout should be used. The workaround for Errata i834 can be achieved by adding SDHCI_QUIRK2_DISABLE_HW_TIMEOUT quirk in sdhci-omap. [1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdfSigned-off-by:
-
Kishon Vijay Abraham I authored
sdhci has a 10 second timeout to catch devices that stop responding. In the case of quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, instead of programming 10 second arbitrary value, calculate the total time it would take for the entire transfer to happen and program the timeout value accordingly. Signed-off-by:
-
Adrian Hunter authored
Factor out the target_timeout calculation so it can be re-used. Signed-off-by:
-
Adrian Hunter authored
Add quirk to disable HW timeout if the requested timeout is more than the maximum obtainable timeout. Also, if the quirk is set and ->get_max_timeout_count() is not implemented, max_busy_timeout is set to zero. Based-on-patch-by:
-
Kishon Vijay Abraham I authored
The SDHCI controller in a SoC might support HS200/HS400 (indicated using mmc-hs200-1_8v/mmc-hs400-1_8v dt property), but if the board is modeled such that the IO lines are not connected to 1.8v then HS200/HS400 cannot be supported. Disable HS200/HS400 if the board does not have 1.8v connected to the IO lines. Also Disable DDR/UHS in 1.8v if the IO lines are not connected to 1.8v. Signed-off-by:
-
Kishon Vijay Abraham I authored
Invoke sdhci_get_of_property defined in sdhci-pltfm.c to read sdhci specific properties from dt node. Signed-off-by:
-
Kishon Vijay Abraham I authored
Errata i843 in AM572x Sitara Processors Silicon Revision 2.0, 1.1 (SPRZ429K July 2014–Revised March 2017 [1]) mentions PG 1.0/1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3 can operate. Use soc_device_match() to identify rev 1.0/1.1 silicon and override mmc->f_max according to the errata workaround. "max-frequency" dt property cannot be used since the device tree is added for rev 2.0 silicon. soc_device_match() is also used in order to get the IODelay values for rev 1.0/1.1 silicon. [1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdfSigned-off-by:
-
Kishon Vijay Abraham I authored
sdhci can directly get ADMA capability from MMCHS_CAPA register. Remove explicitly setting ADMA here as some instances might not have ADMA enabled. (sdhci_read_caps() is also removed from here since sdhci_setup_host() invokes it). Signed-off-by:
-
Kishon Vijay Abraham I authored
sdhci_omap_config_iodelay_pinctrl_state() requires caps and caps2 to be initialized (speed mode capabilities like UHS/HS200) before it is invoked. While mmc_of_parse() initializes caps/caps2 if capabilities is populated in device tree, it will remain uninitialized for capabilities obtained from SDHCI_CAPABILITIES register. Fix sdhci_omap_config_iodelay_pinctrl_state() to be used even while getting the capabilities from SDHCI_CAPABILITIES register by invoking sdhci_setup_host() before sdhci_omap_config_iodelay_pinctrl_state(). Signed-off-by:
-
- 02 May, 2018 4 commits
-
-
Chaotian Jing authored
MT2712 MSDC supports 64G DRAM DMA access, it needs update gpd/bd structure. Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
-
Thomas Gleixner authored
On !RT interrupt runs with interrupts disabled. On RT it's in a thread, so no need to disable interrupts at all. Remove the local_irq_save() invocation. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Andrew Gabbasov authored
While performing R/W access in PIO mode, the common SDHCI driver checks the buffer ready status once per whole block processing. That is, after getting an appropriate interrupt, or checking an appropriate status bit, the driver makes buffer accesses for the whole block size (e.g. 128 reads for 512 bytes block). This is done in accordance with SD Host Controller Specification. At the same time, the Ultra Secured Digital Host Controller (uSDHC), used in i.MX6 (and, probably, earlier i.MX series too), uses a separate Watermark Levels register, controlling the amount of data or space available when raising status bit or interrupt. For default watermark setting of 16 words, the controller expects (and guarantees) no more than 16 buffer accesses after raising buffer ready status bit and generating an appropriate interrupt. If the driver tries to access the whole block size, it will get incorrect data at the end, and a new interrupt will appear later, when the driver already doesn't expect it. This happens sometimes, more likely on low frequencies, e.g. when reading EXT_CSD at MMC card initialization phase (which makes that initialization fail). Such behavior of i.MX uSDHC seems to be non-compliant to SDHCI Specification, but this is the way it works now. In order not to rewrite the SDHCI driver PIO mode access logic, the IMX specific driver can just set the watermark level to default block size (128 words or 512 bytes), so that the controller behavior will be consistent to generic specification. This patch does this for PIO mode accesses only, restoring default values for DMA accesses to avoid any possible side effects from performance point of view. Signed-off-by:
Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by:
Harish Jenny K N <harish_kandiga@mentor.com> Acked-by:
-
Vijay Viswanath authored
The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs have a control signal (io_pad_pwr_switch/mode18 ) that indicates whether the PAD works in 3v or 1.8v. SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset based on actual voltage used for IO lines. So when power irq is triggered for io high or io low, the driver should check the voltages supported and set the pad accordingly. Signed-off-by:
Krishna Konda <kkonda@codeaurora.org> Signed-off-by:
Venkat Gopalakrishnan <venkatg@codeaurora.org> Signed-off-by:
Vijay Viswanath <vviswana@codeaurora.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
