- 21 Dec, 2021 15 commits
-
-
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:
Mårten Lindahl <marten.lindahl@axis.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211220113026.21129-4-marten.lindahl@axis.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
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 21 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:
-
Jacky Bai authored
The USDHC on i.MX8ULP is derived from i.MX8MM, it uses two compatible strings, so update the compatible string for i.MX8ULP. Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Acked-by:
Jacky Bai <ping.bai@nxp.com> Signed-off-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20211112082930.3809351-3-peng.fan@oss.nxp.comSigned-off-by:
-
Mårten Lindahl authored
If we get a data error during a block transfer command, a stop command (CMD12) is normally initiated. But this does not work for the general command (CMD56), but instead the action is ignored and an uninitialized command struct is used for the stop action, with unexpected result. Fix this by adding a check for GEN_CMD when preparing stop transmission. Signed-off-by:
-
H. Nikolaus Schaller authored
Due to recent changes to the mmc core, card quirks can be applied based upon a compatible string in child OF node. The quirk needed for wl1251 (SDIO card) is managed in the core, therefore there is no longer any reason to deal with this in omap_hsmmc too, so let's remove it. Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/77d313b97d1e18b0eb7ed2d88d718d960f329bb0.1636564631.git.hns@goldelico.com [Ulf: Re-wrote the commit message to make it more clear] Signed-off-by:
-
H. Nikolaus Schaller authored
The TiWi WL1251 WiFi chip needs special setup of the sdio interface before it can be probed. So far, this is done in omap_hsmmc_init_card() in omap_hsmmc.c which makes it useable only if connected to omap devices which use the omap_hsmmc. The OpenPandora is the most promient example. There are plans to switch to a newer sdhci-omap driver and retire omap_hsmmc. Hence this quirk must be reworked or moved somewhere else. Ideally to some location that is not dependent on the specific SoC mmc host driver. This is achieved by the new mmc_fixup_device() option introduced by ("mmc: allow to match the device tree to apply quirks") to match through device tree compatible string. This quirk will be called early right after where host->ops->init_card() and thus omap_hsmmc_init_card() was previously called. Note that we do not need to transplant card->ocr = 0x80; because we rely on ("mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD_SDIO"). Signed-off-by: -
Ulf Hansson authored
The mmc core takes a specific path to support initializing of a non-standard SDIO card. This is triggered by looking for the card-quirk, MMC_QUIRK_NONSTD_SDIO. In mmc_sdio_init_card() this gets rather messy, as it causes the code to bail out earlier, compared to the usual path. This leads to that the OCR doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops. To make the behaviour consistent, let's instead rely on the core to save the OCR in card->ocr during initialization. Reported-by:
-
