- 03 May, 2018 1 commit
-
-
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: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
- 02 May, 2018 39 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: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Vijay Viswanath <vviswana@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Fix 3.3V voltage switch for some BYT-based Intel controllers by making use of the ACPI DSM. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Sergei Shtylyov authored
Document the R-Car V3H (R8A77980) SoC in the Renesas SDHI bindings. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-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 <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Tested-by: Nguyen Viet Dung <dung.nguyen.aj@renesas.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
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: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Niklas Söderlund authored
Instead of directly accessing the members of struct scatterlist use the helpers mmc_get_dma_dir() and sg_dma_address() in renesas_sdhi_internal_dmac_start_dma(). Based on previous work by Masaharu Hayakawa. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> [rebased to mmc/next] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kyle Roeschley authored
On some NI 904x devices, using 3.3V signaling for extended periods of time will physically damage the pads connected to the SDHC, eventually causing complete failure of the controller. To work around this, require that we avoid 3.3V signaling. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kyle Roeschley authored
Some SD host controllers cannot handle extended use of 3.3V signaling. To accommodate these controllers, add a capability that requires us to negotiate the voltage down from 3.3V during card initialization. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Geert Uytterhoeven authored
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
Our set_ios hook is, when the card is power up or down, either doing a full init or put our controller back into a reset mode. Since we're also doing that in our runtime_pm hooks, and at possibly much more often, we can drop it from the set_ios, and either rely on our runtime_pm hooks or our probe to do it. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
So far, even if our card was not in use, we didn't shut down our MMC controller, which meant that it was still active and clocking the bus. While this obviously means that we could save some power there, it also creates issues when it comes to EMC control since we'll have a perfect peak at the card clock rate. Let's implement runtime_pm with autosuspend so that we will shut down the controller when it's not been in use for quite some time. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
In order to improve readibility and reusability, let's move the card setup to a small function called by our .set_ios hook. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
In order to improve readibility and reusability, let's move the clock setup to a small function called by our .set_ios hook. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
In order to improve readibility and reusability, let's move the bus width setup to a small function called by our .set_ios hook. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
All the other functions in the driver take a struct sunxi_mmc_host pointer. Let's make it consistent. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Maxime Ripard authored
Our headers sort algorithm has had pretty chaotic results. Let's fix that. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
Now that we have MMC support, enable ext2/3/4 support in the CI20 defconfig. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Acked-by: James Hogan <jhogan@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Diwakar Sharma authored
This patch uses limit clock rate quirk to reduce clock rate for "SDR104" mode on IMX side for Marvell 8887 WiFi + Bluetooth chip side, as Marvell does not recommend to use SDIO at the speed of higher than 150MHz. Signed-off-by: Diwakar Sharma <diwakar.sharma@in.bosch.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
harish_kandiga@mentor.com authored
This patch adds a quirk to limit clock rate which can be used to reduce the SDIO clock rate for some chips with broken UHS. Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Shawn Lin authored
DDR52 with 8-bit mode should be handled in a different way when requesting ciu_clk. However DDR50 is used for SDMMC/SDIO and could never be possible with 8-bit mode. It's trival but misleading. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Masahiro Yamada authored
Cadence sent out an errata report to their customers of this IP. This errata is not so severe, but the tune request should be sent twice to avoid the potential issue. Quote from the report: Problem Summary --------------- The IP6116 SD/eMMC PHY design has a timing issue on receive data path. This issue may lead to an incorrect values of read/write pointers of the synchronization FIFO. Such a situation can happen at the SDR104 and HS200 tuning procedure when the PHY is requested to change a phase of sampling clock when moving to the next tuning iteration. Workarounds ----------- The following are valid workarounds to resolve the issue: 1. In eMMC mode, software sends tune request twice instead of once at each iteration. This means that the clock phase is not changed on the second request so there is no potential for clock instability. 2. In SD mode, software must not use the hardware tuning and instead perform an almost identical procedure to eMMC, using the HRS34 Tune Force register. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Nan Li authored
Explicitly update the docomentation to support the Meson-AXG platform. Signed-off-by: Nan Li <nan.li@amlogic.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@baylibre.com>
-
Nan Li authored
Introduce the compatible data to cover the register offset & mask change of the eMMC controller in Amlogic's Meson-AXG SoC. Signed-off-by: Nan Li <nan.li@amlogic.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@baylibre.com>
-
Nan Li authored
Update the documentation to list support for Meson-AXG SoC explicitly. The new binding string is necessary since this SoC introduce a few IP difference comparing to previous old generation. Signed-off-by: Nan Li <nan.li@amlogic.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@baylibre.com>
-
Andrew Gabbasov authored
Since RPMB area is accessible via special ioctl only and boot areas are unlikely to contain any partitions, exclude them all from listing in /proc/partitions. This will hide them from various user-level software (e.g. fdisk), thus avoiding unnecessary access attempts. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
Enable the SD/MMC support, along with DMA engine support in the CI20 defconfig. Acked-by: James Hogan <jhogan@kernel.org> Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
Now that we have support for JZ480 SoCs in the MMC driver, let's enable it on the devicetree. Acked-by: James Hogan <jhogan@kernel.org> Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
Add the devicetree node to support the MMC host controller available in JZ480 SoCs. Acked-by: James Hogan <jhogan@kernel.org> Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
Add the devicetree node to support the DMA controller found in JZ480 SoCs. Tested-by: Mathieu Malaterre <malat@debian.org> Acked-by: James Hogan <jhogan@kernel.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
Replace dma_request_channel() with dma_request_chan(), which also supports probing from the devicetree. Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-