- 12 Apr, 2021 6 commits
-
-
Wolfram Sang authored
Now that we got the timeout handling in the driver correct, we can use this capability to avoid polling via the MMC core. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Aniruddha Tvs Rao authored
CMD8 is not supported with Command Queue Enabled. Add required callback to clear CQE_EN and CQE_INTR fields in the host controller register before sending CMD8. Add corresponding callback in the CQHCI resume path to re-enable CQE_EN and CQE_INTR fields. Reported-by:
Kamal Mostafa <kamal@canonical.com> Tested-by:
Aniruddha Tvs Rao <anrao@nvidia.com> Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210407094617.770495-1-jonathanh@nvidia.com Cc: stable@vger.kernel.org # v5.10+ Signed-off-by:
-
Ben Chuang authored
For GL9763E, although there is the best performance at the maximum delay. Change the value to 20us in order to have better power consumption. This change may reduce the maximum performance by 10%. Signed-off-by:
Ben Chuang <ben.chuang@genesyslogic.com.tw> Link: https://lore.kernel.org/r/20210407093816.8863-1-benchuanggli@gmail.comSigned-off-by:
-
Nicolas Saenz Julienne authored
Convert the brcm,iproc-sdhci binding to DT schema format using json-schema Signed-off-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210406104802.20898-2-nsaenz@kernel.orgSigned-off-by:
-
Yang Li authored
Fixes the following W=1 kernel build warning(s): drivers/mmc/host/moxart-mmc.c:257:7: warning: variable ‘dma_time’ set but not used drivers/mmc/host/moxart-mmc.c:395:7: warning: variable ‘pio_time’ set but not used Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1617357231-93064-1-git-send-email-yang.lee@linux.alibaba.comSigned-off-by:
-
Bean Huo authored
As the density increases, the 4-minute timeout value for sanitize is no longer feasible. At the same time, devices of different densities have different timeout values, which makes it difficult to use a common timeout value. Therefore, let's pass down the userland-specified sanitize timeout value so it can be used. Signed-off-by:
Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20210402092432.25069-2-huobean@gmail.comSigned-off-by:
-
- 31 Mar, 2021 2 commits
-
-
Adrian Hunter authored
Bus power may control card power, but the full reset done by SDHCI at initialization still may not reset the power, whereas a direct write to SDHCI_POWER_CONTROL can. That might be needed to initialize correctly, if the card was left powered on previously. Signed-off-by:
-
Hao Fang authored
s/Hisilicon/HiSilicon/g. It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. Signed-off-by:
Hao Fang <fanghao11@huawei.com> Acked-by:
Zhangfei Gao <zhangfei.gao@linaro.org> Link: https://lore.kernel.org/r/1617086448-51054-1-git-send-email-fanghao11@huawei.comSigned-off-by:
-
- 30 Mar, 2021 32 commits
-
-
Shawn Guo authored
As indicated by function esdhc_change_pinstate(), SDR50 and DDR50 require pins_100mhz, while SDR104 and HS400 require pins_200mhz. Some system design may support SDR50 and DDR50 with 100mhz pin state only (without 200mhz one). Currently the combined 100/200 MHz pinctrl state check prevents such system from running SDR50 and DDR50. Separate the check to support such system design. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Reviewed-by:
Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/20210326110214.28416-1-shawnguo@kernel.orgSigned-off-by:
-
Al Cooper authored
Remove the CQHCI_QUIRK_SHORT_TXFR_DESC_SZ quirk because the latest chips have this fixed and earlier chips have other CQE problems that prevent the feature from being enabled. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210325192834.42955-1-alcooperx@gmail.comSigned-off-by:
-
Jisheng Zhang authored
As pointed out by Ulf, "both "mmc->parent" and mmc_dev(mmc) are being used in the entire c-file". Convert all the mmc->parent usage in all sdhci host driver to mmc_dev() for consistency. Suggested-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20210324155013.1e5faa3c@xhacker.debianSigned-off-by:
-
Jisheng Zhang authored
The host supports HW busy detection of the device busy signaling over dat0 line. Set MMC_CAP_wAIT_WHILE_BUSY host capability. Signed-off-by:
-
Wei Yongjun authored
Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: c2c4da37837e ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210323112956.1016884-1-weiyongjun1@huawei.comSigned-off-by:
-
Liming Sun authored
This commit adds ACPI support in the sdhci-of-dwcmshc driver for BlueField-3 SoC. It has changes to only use the clock hierarchy for Deviec Tree since the clk is not supported by ACPI. Instead, ACPI can define 'clock-frequency' which is parsed by existing sdhci_get_property(). This clock value will be returned in function dwcmshc_get_max_clock(). Signed-off-by:
Liming Sun <limings@nvidia.com> Reviewed-by:
Khalil Blaiech <kblaiech@nvidia.com> Link: https://lore.kernel.org/r/1616453211-275165-1-git-send-email-limings@nvidia.comSigned-off-by:
-
Adrian Hunter authored
Add PCI IDs for Intel LKF eMMC and SD card host controllers. Signed-off-by:
-
Wolfram Sang authored
After reset, we manually flagged retune in runtime resume, but missed it in the workqueue. To fix that and avoid the problem in the future, let's flag retune in the reset handler directly whenever a card is present. Reported-by:
Takeshi Saito <takeshi.saito.xv@renesas.com> Signed-off-by:
-
Takeshi Saito authored
Resetting the IP core will lose the bus width information and not all code paths recover it. So, make sure the latest bus width gets restored in the reset routine. For that, tmio_mmc_set_bus_width() is moved, but not modified. Signed-off-by:
-
Bean Huo authored
Use preferred way '"%s...", __func__' to print function name. Signed-off-by:
-
James Young authored
This variant is present on a Lenovo IdeaPad Slim 1, which uses an AMD Dali/Athlon Silver 3050e. The Windows AMD SD Host Controller driver also lists this as a valid device ID. Adding this device ID makes the internal eMMC storage on the Lenovo accessible. Consequently this makes Linux installable and usable on it as well. Signed-off-by:
James Young <james@pocketfluff.org> Link: https://lore.kernel.org/r/20210318124025.3002861-1-james@pocketfluff.orgSigned-off-by:
-
Seiya Wang authored
This commit adds dt-binding documentation of mmc for Mediatek MT8195 SoC Platform. Signed-off-by:
Seiya Wang <seiya.wang@mediatek.com> Link: https://lore.kernel.org/r/20210319023427.16711-6-seiya.wang@mediatek.comSigned-off-by:
-
Wolfram Sang authored
All recent SDHI instances can be reset via the reset controller. If one is found, use it instead of the open coded reset. This is to get a future-proof sane reset state. Reviewed-by:
-
Wolfram Sang authored
renesas_sdhi_reset used to mainly reset the SCC but is now doing more and even more will be added. So, factor out SCC reset to have a clear distinction when we want to reset either SCC or SDHI+SCC. Reviewed-by:
-
Wolfram Sang authored
We will soon allow resetting the whole IP core via a reset controller. For this case, DMA must be terminated before the actual reset. For the other cases, it is probably better, too. Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
-
Shawn Lin authored
sdhci based synopsys MMC IP is also used on some rockchip platforms, so add a basic support here. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/1615879102-45919-3-git-send-email-shawn.lin@rock-chips.comSigned-off-by:
-
Shawn Lin authored
This patch adds rockchip support in sdhci-of-dwcmhsc.yaml Signed-off-by:
-
Shawn Lin authored
This patch converts sdhci-of-dwcmshc.txt to sdhci-of-dwcmshc.yaml Signed-off-by:
-
Fabio Estevam authored
The retrieval of driver data can be a bit simplified by using device_get_match_data(), so switch to it. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20210314230824.148969-2-festevam@gmail.comSigned-off-by:
-
Fabio Estevam authored
i.MX has been converted to a devicetree only platform, so remove the non-DT stub for sdhci_esdhc_imx_probe_dt(). Also, make the driver depend on OF now. Signed-off-by:
-
Joey Pabalan authored
Remove else branch on line 334 of memstick.c, after the return of the previous branch. Found by checkpatch. Signed-off-by:
Joey Pabalan <jpabalanb@gmail.com> Link: https://lore.kernel.org/r/20210313173740.GA580681@joeylaptopSigned-off-by:
-
Ulf Hansson authored
The mmc core uses a PM notifier to temporarily during system suspend, turn off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO cards. Additionally, the notifier may be used to remove an SDIO card entirely, if a corresponding SDIO functional driver don't have the system suspend/resume callbacks assigned. This behaviour has been around for a very long time. However, a recent bug report tells us there are problems with this approach. More precisely, when receiving the PM_SUSPEND_PREPARE notification, we may end up hanging on I/O to be completed, thus also preventing the system from getting suspended. In the end what happens, is that the cancel_delayed_work_sync() in mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since mmc_rescan() wants to claim the host, it needs to wait for the I/O to be completed first. Typically, this problem is triggered in Android, if there is ongoing I/O while the user decides to suspend, resume and then suspend the system again. This due to that after the resume, an mmc_rescan() work gets punted to the workqueue, which job is to verify that the card remains inserted after the system has resumed. To fix this problem, userspace needs to become frozen to suspend the I/O, prior to turning off the card detection mechanism. Therefore, let's drop the PM notifiers for mmc subsystem altogether and rely on the card detection to be turned off/on as a part of the system_freezable_wq, that we are already using. Moreover, to allow and SDIO card to be removed during system suspend, let's manage this from a ->prepare() callback, assigned at the mmc_host_class level. In this way, we can use the parent device (the mmc_host_class device), to remove the card device that is the child, in the device_prepare() phase. Reported-by:
Kiwoong Kim <kwmad.kim@samsung.com> Cc: stable@vger.kernel.org # v4.5+ Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.orgReviewed-by:
-
Jisheng Zhang authored
I believe "Spev" is typo, should be "Spec". Signed-off-by:
-
Jisheng Zhang authored
Clean up the code to use the "mmc" directly instead of "host->mmc". If the code sits in hot code path, this clean up also brings trvial performance improvement. Take the sdhci_post_req() for example: before the patch: ... 8d0: a9be7bfd stp x29, x30, [sp, #-32]! 8d4: 910003fd mov x29, sp 8d8: f9000bf3 str x19, [sp, #16] 8dc: f9400833 ldr x19, [x1, #16] 8e0: b9404261 ldr w1, [x19, #64] 8e4: 34000161 cbz w1, 910 <sdhci_post_req+0x50> 8e8: f9424400 ldr x0, [x0, #1160] 8ec: d2800004 mov x4, #0x0 // #0 8f0: b9401a61 ldr w1, [x19, #24] 8f4: b9403262 ldr w2, [x19, #48] 8f8: f9400000 ldr x0, [x0] 8fc: f278003f tst x1, #0x100 900: f9401e61 ldr x1, [x19, #56] 904: 1a9f17e3 cset w3, eq // eq = none 908: 11000463 add w3, w3, #0x1 90c: 94000000 bl 0 <dma_unmap_sg_attrs> ... After the patch: ... 8d0: a9be7bfd stp x29, x30, [sp, #-32]! 8d4: 910003fd mov x29, sp 8d8: f9000bf3 str x19, [sp, #16] 8dc: f9400833 ldr x19, [x1, #16] 8e0: b9404261 ldr w1, [x19, #64] 8e4: 34000141 cbz w1, 90c <sdhci_post_req+0x4c> 8e8: b9401a61 ldr w1, [x19, #24] 8ec: d2800004 mov x4, #0x0 // #0 8f0: b9403262 ldr w2, [x19, #48] 8f4: f9400000 ldr x0, [x0] 8f8: f278003f tst x1, #0x100 8fc: f9401e61 ldr x1, [x19, #56] 900: 1a9f17e3 cset w3, eq // eq = none 904: 11000463 add w3, w3, #0x1 908: 94000000 bl 0 <dma_unmap_sg_attrs> ... We saved one ldr instruction: "ldr x0, [x0, #1160]" Signed-off-by: -
Jisheng Zhang authored
Use semicolons. Signed-off-by:
-
Yang Li authored
Fix the following coccicheck warning: ./drivers/mmc/host/via-sdmmc.c:1274:5-8: Unneeded variable: "ret". Return "0" on line 1295 Reported-by:
-
Philipp Zabel authored
As of commit bb475230 ("reset: make optional functions really optional"), the reset framework API calls use NULL pointers to describe optional, non-present reset controls. This allows to return errors from devm_reset_control_get_optional and to call reset_control_(de)assert unconditionally. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20210305090724.18832-1-p.zabel@pengutronix.deSigned-off-by:
-
Philipp Zabel authored
As of commit bb475230 ("reset: make optional functions really optional"), the reset framework API calls use NULL pointers to describe optional, non-present reset controls. This allows to return errors from devm_reset_control_get_optional and to call reset_control_(de)assert unconditionally. Signed-off-by:
-
Jia-Ju Bai authored
When mspro_block_init_card() fails, no error return code of mspro_block_resume() is assigned/propagated. Let's fix this. Reported-by:
TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Link: https://lore.kernel.org/r/20210305021445.3435-1-baijiaju1990@gmail.comSigned-off-by:
-
Luca Porzio authored
The host->cqe_enabled is already containing the needed information about whether the CQE is enabled or not, hence there is no need to keep another copy of it around. Signed-off-by:
Luca Porzio <lporzio@micron.com> Signed-off-by:
Zhan Liu <zliua@micron.com> Link: https://lore.kernel.org/r/20210215003217.GA12240@lupo-laptopSigned-off-by:
-
Ulf Hansson authored
Returning zero to indicate success, when we actually have failed to probe is wrong. As a matter of fact, it leads to that mmc_blk_remove() gets called at a card removal and then triggers "NULL pointer dereference" splats. This is because mmc_blk_remove() relies on data structures and pointers to be setup from mmc_blk_probe(), of course. There have been no errors reported about this, which is most likely because mmc_blk_probe() never fails like this. Nevertheless, let's fix the code by propagating the error codes correctly and prevent us from leaking memory by calling also destroy_workqueue() in the error path. Signed-off-by:
-
Ulf Hansson authored
To simplify the code, move the logging into the common mmc_blk_alloc_req() and drop the rather useless information about the partition type/id. Signed-off-by:
-
