When SDHC gets reset (E.g. in runtime suspend path), CQE also gets
reset and goes to disable state. But s/w state still points it as CQE
is in enabled state. Since s/w and h/w states goes out of sync,
it results in s/w request timeout for subsequent CQE requests.

To synchronize CQE s/w and h/w state during SDHC reset,
explicitly deactivate CQE just before SDHC reset.
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1583503724-13943-3-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Host controllers can reset CQHCI either directly or as a consequence of
host controller reset. Add cqhci_deactivate() which puts the CQHCI
driver into a state that is consistent with that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/1583503724-13943-2-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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]

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 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200226223125.GA20630@embeddedorSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Supply a separate sg list for each of the request in non-blocking
IO test cases where two requests will be issued at same time.

Otherwise, sg memory may get unmapped when a request is done while
same memory is being accessed by controller from the other request,
and it leads to iommu errors with below call stack:

	__arm_lpae_unmap+0x2e0/0x478
	arm_lpae_unmap+0x54/0x70
	arm_smmu_unmap+0x64/0xa4
	__iommu_unmap+0xb8/0x1f0
	iommu_unmap_fast+0x38/0x48
	__iommu_dma_unmap+0x88/0x108
	iommu_dma_unmap_sg+0x90/0xa4
	sdhci_post_req+0x5c/0x78
	mmc_test_start_areq+0x10c/0x120 [mmc_test]
	mmc_test_area_io_seq+0x150/0x264 [mmc_test]
	mmc_test_rw_multiple+0x174/0x1c0 [mmc_test]
	mmc_test_rw_multiple_sg_len+0x44/0x6c [mmc_test]
	mmc_test_profile_sglen_wr_nonblock_perf+0x6c/0x94 [mmc_test]
	mtf_test_write+0x238/0x3cc [mmc_test]
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Tested-by: NSai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582714668-17247-1-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

CQE feature has been enabled on sdhci-msm. Add CQE reg map
and reg names that need to be supplied for supporting CQE feature.
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1582545470-11530-1-git-send-email-vbadigan@codeaurora.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NBaolin Wang <baolin.wang7@gmail.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/96f16647f6a6e8cb058c44e46c61b122df027059.1582535202.git.baolin.wang7@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdio_single_irq_set() was indented with a mix of tabs and spaces.
Signed-off-by: NJérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200221163147.608677-1-Jerome.Pouiller@silabs.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In some low power mode, SoC will lose the pin state, so need to restore
the pin state when resume back.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/1582100757-20683-8-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-7-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-6-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add new esdhc_soc_data, with compatible string "fsl,imx8mm-usdhc".
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-5-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-4-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-3-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-2-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100757-20683-1-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add fsl,strobe-dll-delay-target binding.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/1582100704-20601-1-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100563-20555-5-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1582100563-20555-4-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/1582100563-20555-3-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/1582100563-20555-2-git-send-email-haibo.chen@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NFaiz Abbas <faiz_abbas@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200108150920.14547-4-faiz_abbas@ti.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NFaiz Abbas <faiz_abbas@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200108150920.14547-3-faiz_abbas@ti.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NFaiz Abbas <faiz_abbas@ti.com>
Link: https://lore.kernel.org/r/20200108150920.14547-2-faiz_abbas@ti.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/98ce471185f037fce57520763621590588766381.1582161803.git.baolin.wang7@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-10-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-9-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-8-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-7-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200128090636.13689-6-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-5-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-4-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch renames sdmmc_priv struct to sdmmc_idma which is assigned to
host->dma_priv.
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-3-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200128090636.13689-2-ludovic.barre@st.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-12-ulf.hansson@linaro.org

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-11-ulf.hansson@linaro.org

The 'u32 *status' is unused by the caller, so let's drop it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-10-ulf.hansson@linaro.org

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-9-ulf.hansson@linaro.org

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-8-ulf.hansson@linaro.org

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-7-ulf.hansson@linaro.org

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: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NBaolin Wang <baolin.wang7@gmail.com>
Tested-by: NLudovic Barre <ludovic.barre@st.com>
Reviewed-by: NLudovic Barre <ludovic.barre@st.com>
Link: https://lore.kernel.org/r/20200204085449.32585-6-ulf.hansson@linaro.org