- May 08, 2018
-
-
Ulf Hansson authored
MMC_CORE_TIMEOUT_MS isn't being used no more, let's drop it. Signed-off-by:Ulf Hansson <ulf.hansson@linaro.org>
-
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:
Shawn Lin <shawn.lin@rock-chips.com>
-
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:
-
- May 03, 2018
-
-
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:
Rob Herring <robh@kernel.org> 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:
Adrian Hunter <adrian.hunter@intel.com> Acked-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.pdf Signed-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.pdf Signed-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:
-
- May 02, 2018
-
-
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:
-
Vijay Viswanath authored
During probe check whether the vdd-io regulator of sdhc platform device can support 1.8V and 3V and store this information as a capability of platform device. Signed-off-by:
-
Sergei Shtylyov authored
I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single SDHI core anyway, so can't be a subject of the known RX DMA errata... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Currently, the code block inside the for loop will never execute more than once, because the function returns immediately after the first iteration, hence the execution of the code at the second iteration is structurally dead and, code at line 281: return 0; is never reached. Fix this by checking _ret_ before return. Addresses-Coverity-ID: 1468009 ("Logically dead code") Addresses-Coverity-ID: 1468002 ("Structurally dead code") Suggested-by:Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
-
Wolfram Sang authored
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by:
-
Ryder Lee authored
The usage of of_device_get_match_data() reduce the code size a bit. Also, the only way to call msdc_drv_probe() is to match an entry in msdc_of_ids[], so of_id cannot be NULL. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Adrian Hunter authored
Fix 3.3V voltage switch for some BYT-based Intel controllers by making use of the ACPI DSM. Signed-off-by:
-
Sergei Shtylyov authored
Document the R-Car V3H (R8A77980) SoC in the Renesas SDHI bindings. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au>
-
Wolfram Sang authored
The WARN can never trigger because we limited the max_seg number in renesas_sdhi_of_data already. Remove it and update the comment. Signed-off-by:
-
Wolfram Sang authored
Whitelisting every ES version does not scale. So, we whitelist whole SoCs independent of ES version. If we need specific handling for an ES version, we put it to the front, so it will be matched first. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Nguyen Viet Dung <dung.nguyen.aj@renesas.com> Signed-off-by:
-
Masaharu Hayakawa authored
Sometimes sg->offset is not used for buffer addresses allocated by dma_map_sg(), so alignment checks should be done on the allocated buffer addresses. Delete the alignment check for sg->offset that is done before dma_map_sg(). Instead, it performs the alignment check for sg->dma_address after dma_map_sg(). Signed-off-by:
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> [Niklas: broke this commit in two and tidied small style issue] Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> [rebased to mmc/next] Signed-off-by:
-
