summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-05-28mmc: sdio: Fix macro name for Marvell device with ID 0x9134Pali Rohár2-2/+2
Marvell SDIO device ID 0x9134 is used in SDIO Common CIS (Card Information Structure) and not in SDIO wlan function (with ID 1). SDIO Common CIS is accessed by function ID 0. So change this misleading macro name to SDIO_DEVICE_ID_MARVELL_8887_F0 as it does not refer to wlan function. It refers to function 0. Wlan module on this SDIO card is available at function ID 1 and is identified by different SDIO device ID 0x9135. Kernel quirks for SDIO devices are matched against device ID from SDIO Common CIS. Therefore device ID used in quirk is correct, just has misleading name. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200522144412.19712-2-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28Merge branch 'fixes' into nextUlf Hansson2-4/+7
2020-05-28m68k: coldfire/clk.c: move m5441x specific codeAngelo Dureghello2-15/+15
Moving specific m5441x clk-related code in more appropriate location, since breaking compilation for other targets. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Link: https://lore.kernel.org/r/20200525102324.2723438-1-angelo.dureghello@timesys.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-of-esdhc: exit HS400 properly before setting any speed modeYangbo Lu1-0/+34
The eSDHC HS400 timing requires many specific registers setting, unlike other speed modes which need to set only host controller 2 register. When driver needs to downgrade HS400 mode to other speed mode, the controller have to exit HS400 timing properly first. This patch is to support the procedure of HS400 exiting at the beginning of esdhc_set_uhs_signaling. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200522031256.856-1-yangbo.lu@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-msm: dump vendor specific registers during errorSarthak Garg1-0/+31
Implement dump_vendor_registers host operation to print the vendor specific registers in addition to standard SDHC register during error conditions. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590139950-7288-9-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-msm: Introduce new ops to dump vendor specific registersSarthak Garg2-0/+4
Introduce new sdhci ops to dump vendor specific registers in the sdhci_dumpregs during error. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590139950-7288-8-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-msm: Read and use DLL Config property from device tree fileSarthak Garg1-2/+11
Certain platforms require different settings in the SDCC_HC_REG_DLL_CONFIG register. This setting can change from platform to platform. So the driver should check whether a particular platform require a different setting by reading the DT file and use it. Also use msm_cm_dll_set_freq only when DLL not supplied. Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590139950-7288-7-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-msm: Update DDR_CONFIG as per device tree fileSarthak Garg1-1/+16
Certain platforms require different settings in the SDCC_HC_REG_DDR_CONFIG register. This setting can change from platform to platform. So the driver should check whether a particular platform require a different setting by reading the device tree file and use it. Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590139950-7288-6-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-msm: Update dll_config_3 as per HSRSarthak Garg1-0/+13
Update dll_config_3 as per the host clock frequency as specified in the DLL Hardware Reference Guide. Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590139950-7288-5-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: host: sdhci-msm: Configure dll-user-control in dll init sequenceVeerabhadrarao Badiganti1-0/+29
With SDCC v5.1.0, additional setting needed for enabling DLL output. The dll-user-control register need to be configured during dll initialization for getting proper dll output. Without this configuration, we don't get the DLL lock status properly. Also update the DLL register settings according to the SDCC Hardware Programming Guide. Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590139950-7288-4-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28dt-bindings: mmc: Add information for DLL register propertiesSarthak Garg1-0/+13
Add information regarding DLL register properties for getting board specific configurations. These DLL register settings may vary from board to board. Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Link: https://lore.kernel.org/r/1590139950-7288-3-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28dt-bindings: mmc: Add new compatible string for sm8250 targetSarthak Garg1-0/+1
Add new compatible string for sm8250 target. Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org> Link: https://lore.kernel.org/r/1590139950-7288-2-git-send-email-sartgarg@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28sdhci: tegra: Avoid reading autocal timeout values when not applicableSowjanya Komatineni1-24/+33
When auto calibration timeouts, calibration is disabled and fail-safe drive strength values are programmed based on the signal voltage. Different fail-safe drive strength values based on voltage are applicable only for SoCs supporting 3V3 and 1V8 pad controls. So, this patch avoids reading these properties from the device tree for SoCs not using pad controls and the warning of missing properties will not show up on these SoC platforms. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1590005337-1087-1-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: renesas_sdhi: remove manual clk handlingWolfram Sang1-8/+2
The SDHI driver en-/disabled its main clock on its own, e.g. during probe() and remove(). Now, we leave all handling to RPM. clk_summary before: sd0 1 1 0 12480000 0 0 50000 sdif0 2 2 0 12480000 0 0 50000 clk_summary after: sd0 1 1 0 12480000 0 0 50000 sdif0 1 1 0 12480000 0 0 50000 Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20200519164251.5430-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-28mmc: tmio: Make sure the PM domain is 'started' while probingUlf Hansson2-2/+3
If the tmio device is attached to a genpd (PM domain), that genpd may have ->start|stop() callback assigned to it. To make sure the device is accessible during ->probe(), genpd's ->start() callback must be invoked, which is currently managed by tmio_mmc_host_probe(). However, it's likely that may be too late for some cases, as registers may be read and written way before that point. To fix the behaviour, let's move the call to dev_pm_domain_start() from tmio_mmc_host_probe() into those clients that needs it. From discussions at linux-mmc mailing list, it turned out that it should be sufficient to do this for the SDHI renesas variants, hence the call is move to renesas_sdhi_probe(). Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20200519152445.6922-1-ulf.hansson@linaro.org Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-28mmc: tmio: Further fixup runtime PM management at removeUlf Hansson1-2/+4
Before calling tmio_mmc_host_probe(), the caller is required to enable clocks for its device, as to make it accessible when reading/writing registers during probe. Therefore, the responsibility to disable these clocks, in the error path of ->probe() and during ->remove(), is better managed outside tmio_mmc_host_remove(). As a matter of fact, callers of tmio_mmc_host_remove() already expects this to be the behaviour. However, there's a problem with tmio_mmc_host_remove() when the Kconfig option, CONFIG_PM, is set. More precisely, tmio_mmc_host_remove() may then disable the clock via runtime PM, which leads to clock enable/disable imbalance problems, when the caller of tmio_mmc_host_remove() also tries to disable the same clocks. To solve the problem, let's make sure tmio_mmc_host_remove() leaves the device with clocks enabled, but also make sure to disable the IRQs, as we normally do at ->runtime_suspend(). Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200519152434.6867-1-ulf.hansson@linaro.org Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-05-28MAINTAINERS: add myself to maintain M5441X mmc host driverAngelo Dureghello1-0/+7
Since actively working on Freescale ColdFire M5441X, adding myself as a maintainer of this driver. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Link: https://lore.kernel.org/r/20200518191742.1251440-4-angelo.dureghello@timesys.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: host: add Coldfire esdhc supportAngelo Dureghello3-0/+535
This driver has been developed as a separate module starting from the similar sdhci-esdhc-imx.c. Reasons for a separate sdchi-esdhc-mcf driver: - m68K architecture does not support devicetrees, so modifying sdhci-of-esdhc.c that is devicetree-related adding platform data seems not appropriate, - clock-related part, has to be implemented specifically for mcf5441x family (see esdhc_mcf_pltfm_set_clock()), - this is a big endian cpu accessing a big endian controller, but about sdma, this controller does not support hw swap, which needs to be handled with specific code, - some other minor differences but mainly to avoid risks on tweaking inside largely used imx driver. Adding just a small size ColdFire-specific driver, with benefits in a further less risky maintenance. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200518191742.1251440-3-angelo.dureghello@timesys.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci: add quirks for be to le byte swappingAngelo Dureghello2-3/+10
Some controller as the ColdFire eshdc may require an endianness byte swap, because DMA read endianness is not configurable. Facilitate using the bounce buffer for this by adding ->copy_to_bounce_buffer(). Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200518191742.1251440-2-angelo.dureghello@timesys.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28m68k: mcf5441x: add support for esdhc mmc controllerAngelo Dureghello6-3/+91
Add support for sdhci-edshc mmc controller. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Link: https://lore.kernel.org/r/20200518191742.1251440-1-angelo.dureghello@timesys.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28dt-bindings: mmc: renesas,sdhi: Document r8a7742 supportLad Prabhakar1-0/+1
Document SDHI controller for RZ/G1H (R8A7742) SoC, which is compatible with R-Car Gen2 SoC family. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1589555337-5498-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: meson-mx-sdhc: Don't use literal 0 to initialize structsMartin Blumenstingl1-2/+2
Kbuild test robot reports the following warning in lines 56 and 87 of drivers/mmc/host/meson-mx-sdhc-clkc.c: Using plain integer as NULL pointer Drop the integer value from the struct initialization to fix that warning. This will still ensure that the compiler will zero out the struct so it's in a well-defined state. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200517222907.1277787-2-martin.blumenstingl@googlemail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: meson-mx-sdhc: Fix manual RX FIFO flushingMartin Blumenstingl1-2/+9
For Meson8 and Meson8b SoCs the vendor driver follows the following pattern: - for eMMC and SD cards in .set_pdma it sets: pdma->rxfifo_manual_flush = 1; - for SDIO cards in .set_pdma it sets: pdma->rxfifo_manual_flush = 0; - before syncing the DMA read buffer is sets: pdma->rxfifo_manual_flush |= 0x02; Set the second bit of MESON_SDHC_PDMA_RXFIFO_MANUAL_FLUSH without clearing the first bit before syncing the DMA read buffer. This fixes a problem where Meson8 and Meson8b SoCs would read random garbage from SD cards. It is not clear why it worked for eMMC cards. This manifested in the following errors when plugging in an SD card: unrecognised SCR structure version <random number> Cc: Thomas Graichen <thomas.graichen@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200517222907.1277787-1-martin.blumenstingl@googlemail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-esdhc-imx: Add HS400 support for i.MX6SLLHaibo Chen1-0/+1
i.MX6SLL support MMC up to V5.0, which means support HS400 mode. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1589527703-19108-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: meson-mx-sdhc: Fix building with CONFIG_MMC_MESON_MX_SDHC=mMartin Blumenstingl2-1/+2
For an x86_64 allmodconfig build Stephen reports that building meson-mx-sdhc-clkc.o warns that MODULE_LICENSE is missing and when linking meson_mx_sdhc_register_clkc cannot be found. Compile the MMC controller driver together with the build-in clock controller driver into one module rather than using two separate modules to fix these issues. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200518060811.1499962-1-martin.blumenstingl@googlemail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-of-dwcmshc: add suspend/resume supportJisheng Zhang1-0/+43
Add dwcmshc specific system-level suspend and resume support. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200515141926.52e088fe@xhacker.debian Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-of-dwcmshc: implement specific set_uhs_signalingJisheng Zhang1-1/+30
We need a different set_uhs_signaling implementation for MMC_TIMING_MMC_HS and MMC_TIMING_MMC_HS400. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200513182602.3636a551@xhacker.debian Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC hostMartin Blumenstingl5-0/+1221
The SDHC MMC host controller on Amlogic SoCs provides an eMMC and MMC card interface with 1/4/8-bit bus width. It supports eMMC spec 4.4x/4.5x including HS200 (up to 100MHz clock). The public S805 datasheet [0] contains a short documentation about the registers. Unfortunately it does not describe how to use the registers to make the hardware work. Thus this driver is based on reading (and understanding) the Amlogic 3.10 GPL kernel code. Some hardware details are not easy to see. Jianxin Pan was kind enough to answer my questions: The hardware has built-in busy timeout support. The maximum timeout is 30 seconds. This is only documented in Amlogic's internal documentation. The controller only works with very specific clock configurations. The details are not part of the public datasheet. In my own words the supported configurations are: - 399.812kHz: clkin = 850MHz div = 2126 sd_rx_phase = 63 - 1MHz: clkin = 850MHz div = 850 sd_rx_phase = 55 - 5.986MHz: clkin = 850MHz div = 142 sd_rx_phase = 24 - 25MHz: clkin = 850MHz div = 34 sd_rx_phase = 15 - 47.222MHz: clkin = 850MHz div = 18 sd_rx_phase = 11/15 (SDR50/HS) - 53.125MHz: clkin = 850MHz div = 16 sd_rx_phase = (tuning) - 70.833MHz: clkin = 850MHz div = 12 sd_rx_phase = (tuning) - 85MHz: clkin = 850MHz div = 10 sd_rx_phase = (tuning) - 94.44MHz: clkin = 850MHz div = 9 sd_rx_phase = (tuning) - 106.25MHz: clkin = 850MHz div = 8 sd_rx_phase = (tuning) - 127.5MHz: clkin = 1275MHz div = 10 sd_rx_phase = (tuning) - 141.667MHz: clkin = 850MHz div = 6 sd_rx_phase = (tuning) - 159.375MHz: clkin = 1275MHz div = 8 sd_rx_phase = (tuning) - 212.5MHz: clkin = 1275MHz div = 6 sd_rx_phase = (tuning) - (sd_tx_phase is always 1, 94.44MHz is not listed in the datasheet but this is what the 3.10 BSP kernel on Odroid-C1 actually uses) NOTE: CMD23 support is disabled for now because it results in command timeouts and thus decreases read performance. Tested-by: Wei Wang <lnykww@gmail.com> Tested-by: Xin Yin <yinxin_1989@aliyun.com> Reviewed-by: Xin Yin <yinxin_1989@aliyun.com> Tested-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200512204147.504087-3-martin.blumenstingl@googlemail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28dt-bindings: mmc: Document the Amlogic Meson SDHC MMC host controllerMartin Blumenstingl1-0/+68
This documents the devicetree bindings for the SDHC MMC host controller found in Meson6, Meson8, Meson8b and Meson8m2 SoCs. It can use a bus-width of 1/4/8-bit and it supports eMMC spec 4.4x/4.5x including HS200 mode (up to 100MHz clock). It embeds an internal clock controller which outputs four clocks (mod_clk, sd_clk, tx_clk and rx_clk) and is fed by four external input clocks (clkin[0-3]). "pclk" is the module register clock, it has to be enabled to access the registers. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200512204147.504087-2-martin.blumenstingl@googlemail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: fix compilation of user APIJérôme Pouiller1-0/+1
The definitions of MMC_IOC_CMD and of MMC_IOC_MULTI_CMD rely on MMC_BLOCK_MAJOR: #define MMC_IOC_CMD _IOWR(MMC_BLOCK_MAJOR, 0, struct mmc_ioc_cmd) #define MMC_IOC_MULTI_CMD _IOWR(MMC_BLOCK_MAJOR, 1, struct mmc_ioc_multi_cmd) However, MMC_BLOCK_MAJOR is defined in linux/major.h and linux/mmc/ioctl.h did not include it. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200511161902.191405-1-Jerome.Pouiller@silabs.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci: use FIELD_GET/PREP for current capabilities bit masksMasahiro Yamada3-25/+19
Use FIELD_GET and FIELD_PREP to get access to the register fields. Delete the shift macros and use GENMASK() for the touched macros. Note that, this has the side-effect of changing the constants to 64-bit on 64-bit platforms. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20200511062828.1791484-1-yamada.masahiro@socionext.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: uniphier-sd: call devm_request_irq() after tmio_mmc_host_probe()Masahiro Yamada1-5/+7
Currently, tmio_mmc_irq() handler is registered before the host is fully initialized by tmio_mmc_host_probe(). I did not previously notice this problem. The boot ROM of a new Socionext SoC unmasks interrupts (CTL_IRQ_MASK) somehow. The handler is invoked before tmio_mmc_host_probe(), then emits noisy call trace. Move devm_request_irq() below tmio_mmc_host_probe(). Fixes: 3fd784f745dd ("mmc: uniphier-sd: add UniPhier SD/eMMC controller driver") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200511062158.1790924-1-yamada.masahiro@socionext.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-pci-gli: Add Genesys Logic GL9763E supportBen Chuang3-0/+109
GL9763E supports High Speed SDR, High Speed DDR, HS200, HS400, Enhanced Strobe in HS400 mode, 1/4/8 bits data bus and 3.3/1.8V. Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw> Link: https://lore.kernel.org/r/20200508064154.13473-1-benchuanggli@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: host: Drop redundant MMC_CAP_ERASEUlf Hansson16-25/+12
The MMC_CAP_ERASE bit is no longer used by the mmc core as erase, discard and trim operations are now always supported. Therefore, drop the bit and move all mmc hosts away from using it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20200508112902.23575-1-ulf.hansson@linaro.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-05-28mmc: core: Enable erase/discard/trim support for all mmc hostsUlf Hansson1-4/+2
Step by step, mmc host drivers and the mmc core have been improved in regards to support erase/discard/trim operations. We have now reached a point when it no longer seems reasonable to use an opt-in approach to enable the functionality. Therefore, let's switch to make the operations always supported. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200508112853.23525-1-ulf.hansson@linaro.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-05-28mmc: sdricoh_cs: Respect the cmd->busy_timeout from the mmc coreUlf Hansson1-2/+5
Using a fixed 1s polling timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Note that, even if the sdricoh_cs driver may currently not support HW busy detection on DAT0, some comments in the code refer to that the HW may support it. Therefore, it seems better to be proactive in this case. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200508095228.14230-1-ulf.hansson@linaro.org
2020-05-28mmc: sdricoh_cs: Throttle polling rate for commandsUlf Hansson1-17/+16
Rather than to poll in a busy-loop, let's convert into using read_poll_timeout() and insert a small delay between each polling attempts. In particular, this avoids hogging the CPU. Additionally, to convert to read_poll_timeout() we also need to switch from using a specific number of polling attempts, into a specific timeout in us instead. The previous 100000 attempts, is translated into a total timeout of total 1s, as that seemed like reasonable value to pick. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200508095218.14177-1-ulf.hansson@linaro.org
2020-05-28mmc: sdricoh_cs: Throttle polling rate for data transfersUlf Hansson1-11/+15
Rather than to poll in a busy-loop, let's convert into using read_poll_timeout() and insert a small delay between each polling attempts. In particular, this avoids hogging the CPU. Additionally, to convert to read_poll_timeout() we also need to switch from using a specific number of polling attempts, into a specific timeout in us instead. The previous 100000 attempts, is translated into a total timeout of total 1s, as that seemed like reasonable value to pick. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200508095210.14123-1-ulf.hansson@linaro.org
2020-05-28mmc: cb710: Inform the mmc core about the maximum busy timeoutUlf Hansson1-0/+8
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 2s, like erase (CMD38) for example. Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200414161413.3036-7-ulf.hansson@linaro.org
2020-05-28memstick: Replace zero-length array with flexible-arrayGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192218.GA16315@embeddedor Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: meson-mx-sdio: trigger a soft reset after a timeout or CRC errorMartin Blumenstingl1-0/+3
The vendor driver (from the 3.10 kernel) triggers a soft reset every time before starting a new command. While this fixes a problem where SDIO cards are not detected at all (because all commands simply timed out) this hurts SD card read performance a bit (in my tests between 10% to 20%). Trigger a soft reset after we got a CRC error or if the previous command timed out (just like the vendor driver from the same 3.10 kernel for the newer SDHC controller IP does). This fixes detection of SDIO cards and doesn't hurt SD card read performance at the same time. With this patch the initialization of an RTL8723BS SDIO card looks like this: req done (CMD52): -110: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 1 timing 0 starting CMD0 arg 00000000 flags 000000c0 req done (CMD0): 0: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 0 starting CMD8 arg 000001aa flags 000002f5 req done (CMD8): -110: 00000000 00000000 00000000 00000000 starting CMD5 arg 00000000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD5 arg 00200000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD3 arg 00000000 flags 00000075 req done (CMD3): 0: 00010000 00000000 00000000 00000000 starting CMD7 arg 00010000 flags 00000015 req done (CMD7): 0: 00001e00 00000000 00000000 00000000 starting CMD52 arg 00000000 flags 00000195 req done (CMD52): 0: 00001032 00000000 00000000 00000000 [... more CMD52 omitted ...] clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 starting CMD52 arg 00000e00 flags 00000195 req done (CMD52): 0: 00001000 00000000 00000000 00000000 starting CMD52 arg 80000e02 flags 00000195 req done (CMD52): 0: 00001002 00000000 00000000 00000000 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 4 timing 2 starting CMD52 arg 00020000 flags 00000195 req done (CMD52): 0: 00001007 00000000 00000000 00000000 [... more CMD52 omitted ...] new high speed SDIO card at address 0001 Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200503222805.2668941-1-martin.blumenstingl@googlemail.com Tested-by: Tobias Baumann <017623705678@o2online.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28dt-bindings: mmc: renesas,mmcif: Document r8a7742 DT bindingsLad Prabhakar1-2/+3
Add support for r8a7742 SoC. Renesas RZ/G1H (R8A7742) MMCIF is identical to the R-Car Gen2 family. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1588794695-27852-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdhci-esdhc: update contact emailWolfram Sang2-2/+2
The 'pengutronix' address is defunct for years. Use the proper contact address. Signed-off-by: Wolfram Sang <wsa@kernel.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200502142840.19418-1-wsa@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: core: expose info about enhanced rpmb supportKrishna Konda3-0/+8
Following eMMC JEDEC JESD84-B51 standard, an enhanced form of rpmb is supported. What this enhanced mode supports is in addition to be able to write one rpmb or two rpmb frames at a time, 32 frames can be written at a time. Expose this information present in ext csd field so that the user space application that wants to make use of this can do so. Signed-off-by: Krishna Konda <kkonda@codeaurora.org> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1588341189-4371-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: sdio: Align the initialization commands in retry path for UHS-IUlf Hansson1-27/+26
According to the comment in mmc_sdio_reinit_card(), some SDIO cards may require a "[CMD5,5,3,7] init sequence", which isn't always obeyed in mmc_sdio_init_card(). Especially, when we end up retrying the UHS-I specific initialization, there is a missing CMD5. Let's update the code to make the behaviour consistent and let's also take the opportunity to clean up the code a bit, to avoid open coding. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-5-ulf.hansson@linaro.org
2020-05-28mmc: sdio: Re-use negotiated OCR mask when re-sending CMD8Ulf Hansson1-4/+4
While initializing an SDIO card in mmc_sdio_init_card(), we may need to retry the UHS-I specific initialization, in case the first attempt fails. This leads to resending a CMD8, but also to restart from scratch with the so called OCR mask negotiations. This is unnecessary as we already have a negotiated OCR mask, so let's use that instead. In this way, the behaviour also becomes more consistent with other similar paths. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-4-ulf.hansson@linaro.org
2020-05-28mmc: sdio: Fix several potential memory leaks in mmc_sdio_init_card()Ulf Hansson1-31/+27
Over the years, the code in mmc_sdio_init_card() has grown to become quite messy. Unfortunate this has also lead to that several paths are leaking memory in form of an allocated struct mmc_card, which includes additional data, such as initialized struct device for example. Unfortunate, it's a too complex task find each offending commit. Therefore, this change fixes all memory leaks at once. Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-3-ulf.hansson@linaro.org
2020-05-28mmc: sdio: Fix potential NULL pointer error in mmc_sdio_init_card()Ulf Hansson1-2/+1
During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I specific initialization, which leads to removal of the previously allocated card. A new card is then re-allocated while retrying. However, in one of the corresponding error paths we may end up to remove an already removed card, which likely leads to a NULL pointer exception. So, let's fix this. Fixes: 5fc3d80ef496 ("mmc: sdio: don't use rocr to check if the card could support UHS mode") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org
2020-05-28mmc: sdhci-msm: Fix error handling for dev_pm_opp_of_add_table()Rajendra Nayak1-11/+16
Even though specifying OPP's in device tree is optional, ignoring all errors reported by dev_pm_opp_of_add_table() means we can't distinguish between a missing OPP table and a wrong/buggy OPP table. While missing OPP table (dev_pm_opp_of_add_table() returns a -ENODEV in such case) can be ignored, a wrong/buggy OPP table in device tree should make the driver error out. while we fix that, lets also fix the variable names for opp/opp_table to avoid confusion and name them opp_table/has_opp_table instead. Suggested-by: Matthias Kaehlcke <matthias@chromium.org> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Link: https://lore.kernel.org/r/1588080785-6812-10-git-send-email-rnayak@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-28mmc: renesas_sdhi: Avoid bad TAP in HS400Takeshi Saito2-8/+48
With R-Car Gen3, CRC error occue at the following TAPs. H3, M3W 1.3, M3N... TAP=2,3,6,7 M3W 3.0 ... TAP=1,3,5,7 (Note: for 4tap SoCs, the numbers get divided by 2) Do not use these TAPs in HS400, and also don't use auto correction but manual correction. We check for bad taps in two places: 1) After tuning HS400: Then, we select a neighbouring TAP. One of them must be good, because there are never three bad taps in a row. Retuning won't help because we just finished tuning. 2) After a manual correction request: Here, we can't switch to the requested TAP. But we can retune (if the HS200 tuning was good) because the environment might have changed since the last tuning. If not, we stay on the same TAP. Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: refactored to match upstream driver, reworded commit msg] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200423130432.9990-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 12:44:39 +0000