- 28 Dec, 2021 1 commit
-
-
AngeloGioacchino Del Regno authored
Replace all instances of open-coded while loops for polling registers with calls to readl_poll_timeout() and, while at it, also fix some possible infinite loop instances. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20211216125748.179602-1-angelogioacchino.delregno@collabora.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
- 21 Dec, 2021 19 commits
-
-
Haibo Chen authored
Add myself as the i.MX sdhci driver maintainer. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/1640076288-32714-1-git-send-email-haibo.chen@nxp.comSigned-off-by:
-
Paul Cercueil authored
Since the MMC/SD controller in Ingenic SoCs work in half-duplex, it is possible to use one single DMA channel for both TX and RX operations, instead of using separate channels. As some older Ingenic SoCs offer only a handful of DMA channels, supporting bi-directional channels allow more hardware to use the channels that would otherwise be used for the MMC/SD operation. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20211220190840.108061-3-paul@crapouillou.netSigned-off-by:
-
Paul Cercueil authored
Update the binding documentation and the examples to support bi-directional DMA channels. Signed-off-by:
-
Mårten Lindahl authored
When running the ARTPEC-8 DWMMC IP version, and a data error interrupt comes during a data read transfer, there is no guarantee for the data transfer over interrupt (DTO) to come within the specified data timeout. This case is handled by the dto_timer handler which will complete the request with the comment: /* * If DTO interrupt does NOT come in sending data state, * we should notify the driver to terminate current transfer * and report a data timeout to the core. */ But since the ARTPEC-8 DWMMC IP version, supports an extended TMOUT register which allows longer timeouts than the non ARTPEC-8 version does, waiting for the dto_timer to complete the request in error cases may cause the request to take significantly longer time than necessary. This is specifically true for the failing steps during tuning of a device. Fix this by completing the request when the error interrupt comes. Since this fix is specific for the ARTPEC-8, a quirk is added. Signed-off-by:
Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20211220113026.21129-5-marten.lindahl@axis.comSigned-off-by:
-
Mårten Lindahl authored
Current dw_mci driver supports a TMOUT register which consists of a 24 bit field (TMOUT[31:8]) for the DATA_TIMEOUT. The maximum value of this field is 0xFFFFFF, which with a 200MHz clock will give a full DRTO of: 0xFFFFFF / 200000000 => ~84 ms However, the ARTPEC-8 SoC DWMMC IP version has a TMOUT register with an extended DATA_TIMEOUT field, which supports longer timers for the DRTO. In this version the DATA_TIMEOUT field is split into two, which with the same 200MHz clock as above will allow a maximum timeout of: ((TMOUT[10:8] -1) * 0xFFFFFF + TMOUT[31:11] * 8) / 200000000 => ~587 ms Add driver callbacks for implementation specific data timeout, and implement callback functions for the ARTPEC-8 SoC. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211220113026.21129-4-marten.lindahl@axis.comSigned-off-by:
-
Mårten Lindahl authored
The ARTPEC-8 SoC has a DWMMC controller that is compatible with the Exynos 7 version v2.70a. The main differences from Exynos 7 is that it does not support HS400 and has extended data read timeout. This patch adds compatibility string "axis,artpec8-dw-mshc" for ARTPEC-8, and DW_MCI_TYPE_ARTPEC8 is added to the dw_mci_exynos_type. Signed-off-by:
-
Mårten Lindahl authored
The ARTPEC-8 SoC has a DWMMC controller that is compatible with the Exynos 7 version v2.70a. The main differences from Exynos 7 is that it does not support HS400 and has extended data read timeout. Add compatibility string "axis,artpec8-dw-mshc" for ARTPEC-8. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211220113026.21129-2-marten.lindahl@axis.comSigned-off-by:
-
Sergey Shtylyov authored
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_threaded_irq() with the invalid IRQ #s. Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoC") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20211217202717.10041-3-s.shtylyov@omp.ruSigned-off-by:
-
Sergey Shtylyov authored
The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_threaded_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_threaded_irq() with the invalid IRQ #s. Fixes: e4bf1b09 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host") Signed-off-by:
-
Dan Carpenter authored
The "0x" prefix is redundant when # flag is used. It prints "0x0x". Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Hector Martin authored
For some reason, <32-bit reads do not work on Apple ARM64 platforms with these chips (even though they do on other PCIe devices). Issue them as 32-bit reads instead. This is done unconditionally, as it shouldn't hurt even if not necessary. Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211215161045.38843-3-marcan@marcan.stSigned-off-by:
-
Hector Martin authored
This is required on some Apple ARM64 laptops using this controller. As is typical on DT platforms, pull these quirks from the device tree using the standard mmc bindings. See Documentation/devicetree/bindings/mmc/mmc-controller.yaml Acked-by:
-
Joel Stanley authored
Sparse spits out this following warning: drivers/mmc/core/queue.c:311:21: warning: incorrect type in assignment (different base types) drivers/mmc/core/queue.c:311:21: expected int ret drivers/mmc/core/queue.c:311:21: got restricted blk_status_t [usertype] drivers/mmc/core/queue.c:314:21: warning: incorrect type in assignment (different base types) drivers/mmc/core/queue.c:314:21: expected int ret drivers/mmc/core/queue.c:314:21: got restricted blk_status_t [usertype] drivers/mmc/core/queue.c:336:16: warning: incorrect type in return expression (different base types) drivers/mmc/core/queue.c:336:16: expected restricted blk_status_t drivers/mmc/core/queue.c:336:16: got int [assigned] ret ret is only used for blk_status_t types, so make it that type. Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20211215011336.194089-1-joel@jms.id.auSigned-off-by:
-
Yann Gautier authored
Use feedback clock for HS200 mode, as for SDR104. The HS200 mode can be enabled through DT by using mmc-hs200-1_8v. It is possible to use it on STM32MP13, but not STM32MP15 platforms. Signed-off-by:
Ludovic Barre <ludovic.barre@foss.st.com> Signed-off-by:
Yann Gautier <yann.gautier@foss.st.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211215141727.4901-5-yann.gautier@foss.st.comSigned-off-by:
-
Yann Gautier authored
The variant->f_max is dependent on the IP, not on the SoC where it is embedded. Set the max frequency of its source clock to 267MHz. The frequency used will be limited by the IOs max frequency, set in the SoC device tree. Signed-off-by:
-
Yann Gautier authored
The change is only hardware, and does not need driver change: Added hardware flow control during transmit packet with variable delay. The new id is then added to the ids list structure. Signed-off-by:
-
Ulf Hansson authored
-
Yann Gautier authored
During test campaign, and especially after several unbind/bind sequences, it has been seen that the SD-card on SDMMC1 thread could freeze. The freeze always appear on a CMD23 following a CMD19. Checking SDMMC internal registers shows that the tuning command (CMD19) has failed. The freeze is then due to the delay block involved in the tuning sequence. To correct this, clear the delay block register DLYB_CR register after the tuning commands. Signed-off-by:
Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by:
-
Yann Gautier authored
Although this compatible is not used in kernel, as we use the common MMCI driver, it is used by bootloaders. The U-Boot driver was merged before the kernel driver and uses this compatible. To avoid issues when aligning device tree files between kernel and boot loader, the ST dedicated compatible is added to bindings file. Signed-off-by:
-
- 20 Dec, 2021 4 commits
-
-
Martin Blumenstingl authored
Remove MESON_SDHC_NUM_BUILTIN_CLKS because it is not used anywhere in the driver. Signed-off-by:
-
Ulf Hansson authored
-
Martin Blumenstingl authored
The vendor driver implements special handling for multi-block SD_IO_RW_EXTENDED (and SD_IO_RW_DIRECT) commands which have data attached to them. It sets the MANUAL_STOP bit in the MESON_SDHC_MISC register for these commands. In all other cases this bit is cleared. Here we omit SD_IO_RW_DIRECT since that command never has any data attached to it. This fixes SDIO wifi using the brcmfmac driver which reported the following error without this change on a Netxeon S82 board using a Meson8 (S802) SoC: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 brcmf_sdiod_ramrw: membytes transfer failed brcmf_sdio_download_code_file: error -110 on writing 219557 membytes at 0x00000000 brcmf_sdio_download_firmware: dongle image file download failed And with this change: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d Fixes: e4bf1b09 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host") Signed-off-by: -
Ulf Hansson authored
It's seems prone to problems by allowing card detect and its corresponding mmc_rescan() work to run, during platform shutdown. For example, we may end up turning off the power while initializing a card, which potentially could damage it. To avoid this scenario, let's add ->shutdown_pre() callback for the mmc host class device and then turn of the card detect from there. Reported-by:
Al Cooper <alcooperx@gmail.com> Suggested-by:
-
- 14 Dec, 2021 16 commits
-
-
Ulf Hansson authored
-
Florian Fainelli authored
Convert the Broadcom STB SDHCI controller Device Tree binding to YAML. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211208003727.3596577-2-f.fainelli@gmail.comSigned-off-by:
-
lizhe authored
If there is no driver match function, the driver core assumes that each candidate pair (driver, device) matches, see driver_match_device(). Drop the mmc bus's match function that always returned 1 and so implements the same behaviour as when there is no match function. Signed-off-by:
lizhe <sensor1010@163.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211207095029.96387-1-sensor1010@163.comSigned-off-by:
-
Rob Herring authored
When 'unevaluatedProperties' support is enabled, the following warnings are generated in the mmc bindings: Documentation/devicetree/bindings/mmc/mtk-sd.example.dt.yaml: mmc@11230000: Unevaluated properties are not allowed ('reg', 'interrupts' were unexpected) Documentation/devicetree/bindings/mmc/sdhci-am654.example.dt.yaml: mmc@4f80000: Unevaluated properties are not allowed ('sdhci-caps-mask' was unexpected) Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.example.dt.yaml: mmc@5a400000: Unevaluated properties are not allowed ('dma-names', 'dmas' were unexpected) Documentation/devicetree/bindings/mmc/arm,pl18x.example.dt.yaml: mmc@80126000: Unevaluated properties are not allowed ('dmas', 'dma-names' were unexpected) Documentation/devicetree/bindings/mmc/arasan,sdhci.example.dt.yaml: mmc@80420000: Unevaluated properties are not allowed ('resets' was unexpected) Documentation/devicetree/bindings/mmc/arm,pl18x.example.dt.yaml: mmc@52007000: Unevaluated properties are not allowed ('interrupt-names' was unexpected) Documentation/devicetree/bindings/clock/imx8qxp-lpcg.example.dt.yaml: mmc@5b010000: Unevaluated properties are not allowed ('power-domains' was unexpected) Add the missing properties as necessary. For pl18x, drop interrupt-names as there isn't any use of it when there are 2 interrupts. Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Chaotian Jing <chaotian.jing@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Wenbin Mei <wenbin.mei@mediatek.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: linux-mmc@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by:Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20211206174201.2297265-1-robh@kernel.orgSigned-off-by:
-
Andy Shevchenko authored
Use write_or_read temporary variable in mmc_spi_data_do() to deduplicate the conditional code. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211206115218.73874-2-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Convert 'multiple' to be boolean in mmc_spi_data_do() since it's initially being used as boolean. Signed-off-by:
-
Jesse Taube authored
Add support for i.MXRT1050's sdhc. Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by:
Jesse Taube <Mr.Bossman075@gmail.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20211125211443.1150135-12-Mr.Bossman075@gmail.comSigned-off-by:
-
Jesse Taube authored
Add i.MXRT documentation for compatible string. Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by:
-
John Keeping authored
Move the common MMC_CAP_CMD23 capability to common_caps so that only the special case of MMC_CAP_1_8V_DDR and MMC_CAP_8_BIT_DATA are set via caps/num_caps. Both of those can, and should, be set via device tree properties instead, so we can now say that exynos_dwmmc_caps is only used for backwards compatibility. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com> Link: https://lore.kernel.org/r/20211124184603.3897245-5-john@metanate.comSigned-off-by:
-
John Keeping authored
The capabilities for all instances are the same, so use common_caps instead of caps/num_caps to remove the dependency on the mshcN device tree alias. Signed-off-by:
Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Reviewed-by:
-
John Keeping authored
The capabilities for all instances are the same, so use common_caps instead of caps/num_caps to remove the dependency on the mshcN device tree alias. Signed-off-by:
-
John Keeping authored
The caps field depends on the mshcN alias ID but for some devices this is unnecessary as the capabilities are the same for all instances sharing the same compatible. Add a common_caps field for this case which updates the host's capabilities without needing the mshcN alias ID. Signed-off-by:
-
Adrian Hunter authored
Add PCI ID for Intel ADL eMMC host controller. Signed-off-by:
-
Mårten Lindahl authored
The TMOUT register is always set with a full value for every transfer, which (with a 200MHz clock) will give a full DRTO of ~84 milliseconds. This is normally good enough to complete the request, but setting a full value makes it impossible to test shorter timeouts, when for example testing data read times on different SD cards. Add a function to set any value smaller than the maximum of 0xFFFFFF. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
Huijin Park authored
In mmc_send_op_cond(), loops are continuously performed at the same interval of 10 ms. However the behaviour is not good for some eMMC which can be out from a busy state earlier than 10 ms if normal. Rather than fixing about the interval time in mmc_send_op_cond(), let's instead convert into using the common __mmc_poll_for_busy(). The reason for adjusting the interval time is that it is important to reduce the eMMC initialization time, especially in devices that use eMMC as rootfs. Test log(eMMC:KLM8G1GETF-B041): before: 12 ms (0.311016 - 0.298729) [ 0.295823] mmc0: starting CMD0 arg 00000000 flags 000000c0 [ 0.298729] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start [ 0.311016] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish [ 0.311336] mmc0: starting CMD2 arg 00000000 flags 00000007 after: 2 ms (0.301270 - 0.298762) [ 0.295862] mmc0: starting CMD0 arg 00000000 flags 000000c0 [ 0.298762] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start [ 0.299067] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.299441] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.299879] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.300446] mmc0: starting CMD1 arg 40000080 flags 000000e1 [ 0.301270] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish [ 0.301572] mmc0: starting CMD2 arg 00000000 flags 00000007 Signed-off-by:
Huijin Park <huijin.park@samsung.com> Link: https://lore.kernel.org/r/20211104063231.2115-3-huijin.park@samsung.comSigned-off-by:
-
Huijin Park authored
This patch changes the __mmc_poll_for_busy() first parameter type from 'struct mmc_card*' to 'struct mmc_host*'. Because the function refers only 'struct mmc_host' to get hostname. Signed-off-by:
-
