- 24 Mar, 2020 40 commits
-
-
Baolin Wang authored
The Spreadtrum host controller supports HW busy detection for commands with R1B responses, but also for I/O operations. This means when the host gets a transfer complete event, that always indicates the busy signal is released. Let's inform the mmc core about this, via setting the corresponding MMC_CAP_WAIT_WHILE_BUSY flag, as to remove some redundant software busy polling. Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/96f16647f6a6e8cb058c44e46c61b122df027059.1582535202.git.baolin.wang7@gmail.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Jérôme Pouiller authored
sdio_single_irq_set() was indented with a mix of tabs and spaces. Signed-off-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20200221163147.608677-1-Jerome.Pouiller@silabs.comSigned-off-by:
-
Haibo Chen authored
In some low power mode, SoC will lose the pin state, so need to restore the pin state when resume back. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/1582100757-20683-8-git-send-email-haibo.chen@nxp.comSigned-off-by:
-
Haibo Chen authored
Currently, when use standard tuning, driver default disable DMA just before send tuning command. But on i.MX8 usdhc, this is not enough. Need also clear DMA_SEL. If not, once the DMA_SEL select AMDA2 before, even dma already disabled, when send tuning command, usdhc will still prefetch the ADMA script from wrong DMA address, then we will see IOMMU report some error which show lack of TLB mapping. Signed-off-by:
-
Haibo Chen authored
On i.MX8MM, we are running Dual Linux OS, with 1st Linux using SD Card as rootfs storage, 2nd Linux using eMMC as rootfs storage. We let the the 1st linux configure power/clock for the 2nd Linux. When the 2nd Linux is booting into rootfs stage, we let the 1st Linux to destroy the 2nd linux, then restart the 2nd linux, we met SDHCI dump as following, after we clear the pending interrupt and halt CQCTL, issue gone. [ 1.334594] mmc2: Got command interrupt 0x00000001 even though no command operation was in progress. [ 1.334595] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 1.334599] mmc2: sdhci: Sys addr: 0xa05dcc00 | Version: 0x00000002 [ 1.345538] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000000 [ 1.345541] mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000033 [ 1.345543] mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000031 [ 1.345547] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 [ 1.357903] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000003f [ 1.357905] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000 [ 1.357908] mmc2: sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b [ 1.357911] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502 [ 1.370268] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400 [ 1.370270] mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff [ 1.370273] mmc2: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0xffffffff [ 1.370276] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00 [ 1.382132] mmc2: sdhci: Host ctl2: 0x00000000 [ 1.382135] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xa2040208 [ 2.060932] mmc2: Unexpected interrupt 0x00004000. [ 2.065538] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 2.071720] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00000002 [ 2.077902] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 [ 2.084083] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 [ 2.090264] mmc2: sdhci: Present: 0x01f88009 | Host ctl: 0x00000011 [ 2.096446] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 [ 2.102627] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x000010ff [ 2.108809] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00004000 [ 2.114990] mmc2: sdhci: Int enab: 0x007f1003 | Sig enab: 0x007f1003 [ 2.121171] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502 [ 2.127353] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400 [ 2.133534] mmc2: sdhci: Cmd: 0x0000371a | Max curr: 0x00ffffff [ 2.139715] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff [ 2.145896] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00 [ 2.152077] mmc2: sdhci: Host ctl2: 0x00000000 [ 2.156342] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000 Signed-off-by:
-
Haibo Chen authored
Add new esdhc_soc_data, with compatible string "fsl,imx8mm-usdhc". Signed-off-by:
-
Haibo Chen authored
Since L4.15, community involve the commit 105819c8 ("mmc: core: use mrq->sbc when sending CMD23 for RPMB"), let the usdhc to decide whether to use ACMD23 for RPMB. This CMD23 for RPMB need to set the bit 31 to its argument, if not, the RPMB write operation will return general fail. According to the sdhci logic, SDMA mode will disable the ACMD23, and only in ADMA mode, it will chose to use ACMD23 if the host support. But according to debug, and confirm with IC, the imx6qpdl/imx6sx/imx6sl/imx7d do not support the ACMD23 feature completely. These SoCs only use the 16 bit block count of the register 0x4 (BLOCK_ATT) as the CMD23's argument in ACMD23 mode, which means it will ignore the upper 16 bit of the CMD23's argument. This will block the reliable write operation in RPMB, because RPMB reliable write need to set the bit31 of the CMD23's argument. This is the hardware limitation. So for imx6qpdl/imx6sx/imx6sl/imx7d, it need to broke the ACMD23 for eMMC, SD card do not has this limitation, because SD card do not support reliable write. For imx6ul/imx6ull/imx6sll/imx7ulp/imx8, it support the ACMD23 completely, it change to use the 0x0 register (DS_ADDR) to put the CMD23's argument in ADMA mode. This patch add a new flag ESDHC_FLAG_BROKEN_AUTO_CMD23, and add this flag to imx6q/imx6sx/imx6sl/imx7d, and due to the imx6sll share the same compatible string with imx6sx before, and imx6sll do not has this limitation, so add a new compatible string for imx6sll. Signed-off-by:
-
Haibo Chen authored
After set the STROBE SLV delay target value, it need to wait some time to let the usdhc lock the REF and SLV clock. In normal case, 1~2us is enough for imx8/imx6 and imx7d, and 4~5us is enough for imx7ulp, but when do reboot stress test or do the bind/unbind stress test, sometimes need to wait about 10us to get the status lock. This patch optimize delay handle method, only print the warning message if the status is still not lock after 1ms delay. Signed-off-by:
-
Haibo Chen authored
When force clock off, check the SDOFF of register PRSSTAT to make sure the clock is gate off. Before force clock on, check the SDSTB of register PRSSTAT to make sure the clock is stable, this will eliminate the clock glitch. Signed-off-by:
-
Haibo Chen authored
strobe-dll-delay-target is the delay cell add on the strobe line. Strobe line the the uSDHC loopback read clock which is use in HS400 mode. Different strobe-dll-delay-target may need to set for different board/SoC. If this delay cell is not set to an appropriate value, we may see some read operation meet CRC error after HS400 mode select which already pass the tuning. This patch add the strobe-dll-delay-target setting in driver, so that user can easily config this delay cell in dts file. Signed-off-by:
-
Haibo Chen authored
Add fsl,strobe-dll-delay-target binding. Signed-off-by:
-
Haibo Chen authored
When pm_runtime_suspend is run, a call to SCFW power off the SS (SS is a power domain, usdhc belong to this SS power domain) in which the resource resides is made. The SCFW can power off the SS if no other resource in active in that SS. If so, all state associated with all the resources within the SS that is powered off is lost, this includes the clock rates, clock state etc. When pm_runtime_resume is called, the SS associated with that resource is powered up. But the clocks are left in the default state. This patch restore clock rate in pm_runtime_resume, make sure the clock is right rather than depending on the default state setting by SCFW. Signed-off-by:
-
Haibo Chen authored
For Mega/Mix enabled SoCs like MX7D and MX6SX, uSDHC will lost power in LP mode no matter whether the MMC_KEEP_POWER flag is set or not. This may cause state misalign between kernel and HW, especially for SDIO3.0 WiFi cards. e.g. SDIO WiFi driver usually will keep power during system suspend. And after resume, no card re-enumeration called. But the tuning state is lost due to Mega/Mix. Then CRC error may happen during next data transfer. So we should always fire a mmc_retune_needed() for such type SoC to tell MMC core retuning is needed for next data transfer. mmc: sdhci-esdhci-imx: retune needed for Mega/Mix enabled SoCs Signed-off-by:
-
Haibo Chen authored
When using jailhouse to support two Linux on i.MX8MQ EVK, we use the 1st Linux to configure pinctrl for the 2nd Linux. Then the 2nd Linux could use the mmc without pinctrl driver. So give a warning message when no pinctrl available, but no fail probe. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1582100563-20555-3-git-send-email-haibo.chen@nxp.comSigned-off-by:
-
Haibo Chen authored
Except SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE, we also do not need to handle controller native card detect interrupt for gpio cd type. If we wrong enabled the card detect interrupt for gpio case, it will cause a lot of unexpected card detect interrupts during data transfer which should not happen. Signed-off-by:
-
Faiz Abbas authored
Its recommended that DLL must only be enabled for SDR50, DDR50, DDR52, SDR104, HS200 and HS400 speed modes. Move DLL configuration to its own function and call it only in the above speed modes. Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Acked-by:
-
Faiz Abbas authored
According to the latest AM65x Data Manual[1], a different output tap delay value is optimum for a given speed mode. Therefore, deprecate the ti,otap-del-sel binding and introduce a new binding for each of the possible MMC/SD speed modes. If the legacy mode is not found, fall back to old binding to maintain dts compatibility. [1] http://www.ti.com/lit/gpn/am6526Signed-off-by:
-
Faiz Abbas authored
According to latest AM65x Data Manual[1], a different output tap delay value is recommended for all speed modes. Therefore, replace the ti,otap-del-sel binding with one ti,otap-del-sel- for each MMC/SD speed mode. [1] http://www.ti.com/lit/gpn/am6526Signed-off-by:
-
Baolin Wang authored
Add missing MODULE_LICENSE() and MODULE_DESCRIPTION() in hsq driver to fix below warning when compiling the hsq as a module. "WARNING: modpost: missing MODULE_LICENSE() in drivers/mmc/host/mmc_hsq.o". Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Ludovic Barre authored
This patch adds a sdmmc variant revision 2.0. This revision is backward compatible with 1.1, but adds DMA linked list support. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-10-ludovic.barre@st.comSigned-off-by:
-
Ludovic Barre authored
To prepare the voltage switch procedure, the VSWITCHEN bit must be set before sending the CMD11. To confirm completion of voltage switch, the VSWEND flag must be checked. Signed-off-by:
-
Ludovic Barre authored
A variant may need to define some actions before and after a voltage switch. This patch adds 2 callbacks to manage signal voltage switch in the struct mmci_host_ops. ->pre_sig_volt_switch() allows to prepare a signal voltage switch before sending the SD_SWITCH_VOLTAGE command (CMD11). ->post_sig_volt_switch callback allows specific actions to be executed, after the I/O signal voltage level has been changed. Signed-off-by:
-
Ludovic Barre authored
The hardware delay block is used to align the sampling clock on the data received by SDMMC. It is mandatory for SDMMC to support the SDR104 mode. The delay block is used to generate an output clock which is dephased from the input clock. The phase of the output clock must be programmed by the execute tuning interface. Signed-off-by:
-
Ludovic Barre authored
To support the sdr104 mode, the sdmmc variant has a hardware delay block to manage the clock phase when sampling data received by the card. This patch adds a second base register (optional) for sdmmc delay block. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200128090636.13689-6-ludovic.barre@st.comSigned-off-by:
-
Ludovic Barre authored
In variant init function, some references may be allocated for variant specific usage. Add a private void* to mmci_host struct allows at variant functions to access on this references by mmci_host structure. Signed-off-by:
-
Ludovic Barre authored
The variant init function may need to add a mmc_host_ops, for example to add the execute_tuning support if this feature is available. This patch adds mmc_host_ops pointer in mmci struct. Signed-off-by:
-
Ludovic Barre authored
This patch renames sdmmc_priv struct to sdmmc_idma which is assigned to host->dma_priv. Signed-off-by:
-
Ludovic Barre authored
sg_dma_xxx should be used after a dma_map_sg call has been done to get bus addresses of each of the SG entries and their lengths. But mmci_host_ops validate_data can be called before dma_map_sg. This patch replaces theses macros by sg->offset and sg->length which are always defined. Signed-off-by:
-
Ulf Hansson authored
In case the host specify a max_busy_timeout, we need to validate that the needed timeout for the HPI command conforms to that requirement. If that's not the case, let's convert from a R1B response to a R1 response, as to instruct the host to avoid HW busy detection. Additionally, when R1B is used we must also inform the host about the busy timeout for the command, so let's do that via updating cmd.busy_timeout. Finally, when R1B is used and in case the host supports HW busy detection, there should be no need for doing polling, so then skip that. Signed-off-by:
-
Ulf Hansson authored
Rather than open coding the polling loop in mmc_interrupt_hpi(), let's convert to use mmc_poll_for_busy(). Note that, moving to mmc_poll_for_busy() for HPI also improves the behaviour according to below. - Adds support for polling via the optional ->card_busy() host ops. - Require R1_READY_FOR_DATA to be set in the CMD13 response before exiting the polling loop. - Adds a throttling mechanism to avoid CPU hogging when polling. Signed-off-by:
-
Ulf Hansson authored
The 'u32 *status' is unused by the caller, so let's drop it. Signed-off-by:
-
Ulf Hansson authored
Rather than open coding the polling loop in mmc_do_erase(), let's convert to use mmc_poll_for_busy(). To allow a slightly different error parsing during polling, compared to the __mmc_switch() case, a new in-parameter to mmc_poll_for_busy() is needed, but other than that the conversion is straight forward. Besides addressing the open coding issue, moving to mmc_poll_for_busy() for erase/trim/discard improves the behaviour according to below. - Adds support for polling via the optional ->card_busy() host ops. - Returns zero to indicate success when the final polling attempt finds the card non-busy, even if the timeout expired. - Exits the polling loop when state moves to R1_STATE_TRAN, rather than when leaving R1_STATE_PRG. - Decreases the starting range for throttling to 32-64us. Signed-off-by:
-
Ulf Hansson authored
Through mmc_poll_for_busy() a CMD13 may be sent to get the status of the (e)MMC card. If the state of the card is R1_STATE_PRG, the card is considered as being busy, which means we continue to poll with CMD13. This seems to be sufficient, but it's also unnecessary fragile, as it means a new command/request could potentially be sent to the card when it's in an unknown state. To try to improve the situation, but also to move towards a more consistent CMD13 polling behaviour in the mmc core, let's deploy the same policy we use for regular I/O write requests. In other words, let's check that card returns to the R1_STATE_TRAN and that the R1_READY_FOR_DATA bit is set in the CMD13 response, before exiting the polling loop. Note that, potentially this changed behaviour could lead to unnecessary waiting for the timeout to expire, if the card for some reason, moves to an unexpected error state. However, as we bail out from the polling loop when R1_SWITCH_ERROR bit is set or when the CMD13 fails, this shouldn't be an issue. Signed-off-by:
-
Ulf Hansson authored
To allow subsequent changes to re-use the code from the static function mmc_blk_in_tran_state(), let's move it to a public header. While at it, let's also rename it to mmc_ready_for_data(), as to try to better describe its purpose. Signed-off-by:
-
Ulf Hansson authored
To make the code more readable, move the part that gets the busy status of the card out into a separate function, mmc_busy_status(). Then call it from mmc_poll_for_busy(). Signed-off-by:
-
Ulf Hansson authored
The use_busy_signal in-parameter is set true by all callers of __mmc_switch(), hence it's redundant so drop it. Signed-off-by:
-
Ulf Hansson authored
To simplify code, let's extend mmc_switch_status() to cope with needs addressed in __mmc_switch_status(). Then move all users to the updated mmc_switch_status() API and drop __mmc_switch_status() altogether. Signed-off-by:
-
Ulf Hansson authored
The last user of MMC_OPS_TIMEOUT_MS was recently removed, however the define stayed around. Let's remove it. Signed-off-by:
-
Ulf Hansson authored
In mmc_poll_for_busy() we loop continuously, either by sending a CMD13 or by invoking the ->card_busy() host ops, as to detect when the card stops signaling busy. This behaviour is problematic as it may cause CPU hogging, especially when the busy signal time reaches beyond a few ms. Let's fix the issue by adding a throttling mechanism, that inserts a usleep_range() in between the polling attempts. The sleep range starts at 32-64us, but increases for each loop by a factor of 2, up until the range reaches ~32-64ms. In this way, we are able to keep the loop fine-grained enough for short busy signaling times, while also not hogging the CPU for longer times. Note that, this change is inspired by the similar throttling mechanism that we already use for mmc_do_erase(). Reported-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Baolin Wang authored
Add software queue support to improve the performance. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
-
