SD controller with SDHCI_QUIRK_NO_HISPD_BIT quirk probably
use high speed enable bit for other purpose. So this bit
shouldn't be changed for high speed enabling for this type of
SD controller.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Hosts supporting 8-bit bus are marked accordingly. If MMC_CAP_8_BIT_DATA
is not among host capabilities, 8BITBUS bit will never be set and it
is not cleared in case some non-SDHCI3 host uses it for something else.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch adds sdma_boundary member to struct sdhci_host to give more
flexibility to drivers to control the sdma boundary buffer value and
also to fix issue on some sdhci controllers which are broken when
HOST SDMA Buffer Boundary is programmed in Block Size Register (0x04)
when using ADMA. Qualcomm sdhci controller is one of such type, writing
to this bits is un-supported.

Default value of sdma_boundary is set to SDHCI_DEFAULT_BOUNDARY_ARG.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

One issue was found on a removable high speed sd card with
runtime pm enabled.
When SD card is unplugged, it keep printing "Switching to 3.3V
signalling voltage failed".
And found below sequence triggers the error.

mmc_rescan
	-> mmc_sd_detect
		-> mmc_power_off  -- mmc->ios.vdd is updated to 0.
	-> mmc_claim_host
		-> sdhci_runtime_resume_host
			-> sdhci_start_signal_voltage_switch
				-> mmc_regulator_set_vqmmc
					-> mmc_ocrbitnum_to_vdd

When mmc_ocrbitnum_to_vdd is called, the mmc->ios.vdd is 0, so it
always return -EINVAL. The signal switch will always fail and
print out warning.
Ignore restoring the I/O state when runtime resume if MMC_POWER_OFF.
Signed-off-by: NZhoujie Wu <zjwu@marvell.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci uses CONFIG_MMC_DEBUG for showing ADMA descriptor
when occurring ADMA error. And it's also used to  dump the
registers whenever calling sdhci_add_host.

On one hand, I don't see any burden to always print the state
ADMA descriptor as it's rare and will help folks better understand
what was happening when seeing ADMA error.

On the other, folks may be interested in checking some registers
at probe time. So we remove the sdhci_dumpregs from __sdhci_add_host
and print some really useful registers in sdhci_setup_host.
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The delay between tuning commands for SD cards is not part of the
specification. A driver that needs it probably needs it for eMMC
too, whereas most drivers would probably like to set it to 0. Make
it a host member (host->tuning_delay) that defaults to the existing
behaviour. Drivers can set it to zero to eliminate the delay, or
set it to a positive value to always have a delay.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Export sdhci_enable_sdio_irq() from sdhci.c.
Thus vendor SDHC driver can implement its specific SDIO irq
control.
Signed-off-by: NHu Ziji <huziji@marvell.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.
Signed-off-by: NHu Ziji <huziji@marvell.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Export sdhci_set_ios() in sdhci.c.
Thus vendor sdhci driver can implement its own set_ios() routine.
Signed-off-by: NHu Ziji <huziji@marvell.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use new core function mmc_get_dma_dir().
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently the get_timeout_clock callback doesn't clearly
have a statement that it needs the variant drivers to return
the timeout clock rate in kHz if the SDHCI_TIMEOUT_CLK_UNIT
isn't present, otherwise the variant drivers should return it
in MHz. It's also very likely that further variant drivers which
are going to use this callback will be confused by this situation.
Given the fact that moderm sdhci variant hosts are very prone to get
the timeout clock from common clock framework (actually the only three
users did that), it's more natural to return the value in Hz and we
make an explicit comment there. Then we put the unit conversion inside
the sdhci core. Thus will improve the code and prevent further misuses.
Reported-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add an interrupt hook and helper functions for enabling, disabling and
delivering interrupts to a CQE.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Factor out sdhci_set_default_irqs().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Add sdhci_cleanup_host() to cleanup __sdhci_add_host().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Export sdhci_dumpregs so that it can be called by drivers.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Ensure all prints start with the mmc host name, and the text all lines up.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Use sdhci io wrappers consistently.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Add response register to register dump.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Ensure all debug prints start with the mmc host name.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Tuning execution is already synchronized with respect to other host
operations by upper layers "claiming" the host, which also takes care of
runtime pm. There can be no requests in progress. Retain the spin lock
usage only for ensuring that sending tuning commands is synchronized with
respect to the interrupt handler.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

The spin lock is not necessary in set_ios. Anything that is racing with
changes to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host. So remove spin_lock and friends
from sdhci_set_ios and related callbacks.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Drivers can use the host operation directly, so remove this now unused
callback.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Devices might save and restore tuning values so that re-tuning might not be
needed after a pm transition.  Let drivers decide by pushing the
mmc_retune_needed() logic down to them.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

The delay loops for reset and clock enable always take at least 1 ms
because they use mdelay(1). However they can take a lot less time e.g. less
than 50us. Use ktime and reduce the delay to 10 microseconds per loop.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

SDIO cards may need clock to send the card interrupt to the host.

On a cherrytrail tablet with a RTL8723BS wifi chip, without this patch
pinging the tablet results in:

PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=78.6 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1760 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=753 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=3.88 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=795 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1841 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=810 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1860 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=812 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=48.6 ms

Where as with this patch I get:

PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=3.96 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1.97 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=17.2 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=2.46 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=2.83 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1.40 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=2.10 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1.40 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=2.04 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=1.40 ms

Cc: Dong Aisheng <b29396@freescale.com>
Cc: Ian W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NDong Aisheng <aisheng.dong@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when sdhci changes clock frequency because it
waits for the clock to become stable under a spin lock.

The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.

Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>

Clear SDHCI_HS400_TUNING flag after platform_execute_tuning
so that platform_execute_tuning may use it if needed.
Signed-off-by: NRitesh Harjani <riteshh@codeaurora.org>
Tested-by: NJeremy McNicoll <jeremymc@redhat.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In the MMC subsystem, we see such initializers that only clears the
first member explicitly.

For example,

  struct mmc_request mrq = {NULL};

sets the first member (.sbc) to NULL explicitly.  However, this is
an unstable form because we may insert a non-pointer member at the
top of the struct mmc_request in the future. (if we do so, the
compiler will spit warnings.)

So, using a designated initializer is preferred coding style.  The
expression above is equivalent to:

  struct mmc_request mrq = { .sbc = NULL };

Of course, this does not express our intention.  We want to fill
all struct members with zeros.  Please note struct members are
implicitly zero-cleared unless otherwise specified in the initializer.

After all, the most reasonable (and stable) form is:

  struct mmc_request mrq = {};

Do likewise for mmc_command, mmc_data as well.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

One of our kernelCI boxes hanged at boot because a faulty eSDHC device
was triggering spurious CARD_INT interrupts for SD cards, causing CMD52
reads, which are not allowed for SD devices.  This adds a sanity check
to the interruption path, preventing that illegal command from getting
sent if the CARD_INT interruption should be disabled.

This quirk allows that particular machine to resume boot despite the
faulty hardware, instead of getting hung dealing with thousands of
mishandled interrupts.
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Cc: <stable@vger.kernel.org>

Since commit c2c24819 ("mmc: core: Don't power off the card when
starting the host"), the power state can still be MMC_POWER_UNDEFINED after
mmc_start_host() is called. That can trigger a warning in SDHCI during
runtime resume as it tries to restore the I/O state. Handle
MMC_POWER_UNDEFINED simply by not updating the I/O state in that case.

Fixes: c2c24819 ("mmc: core: Don't power off the card when starting the host")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some SDHCI-compat controllers support not only SD, but also eMMC,
but they use different commands for tuning: CMD19 for SD, CMD21 for
eMMC.

Due to the difference of the underlying mechanism, some controllers
(at least, the Cadence IP is the case) provide their own registers
for the eMMC tuning.

This commit will be useful when we want to override .execute_tuning
callback (for eMMC HS200 tuning), but still let it fall back to
sdhci_execute_tuning() for SD timing.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Tidy the tuning loop by moving it to a separate function and making it a
for-loop.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There are only 2 possible block sizes, so simplify 2 if-statements into 1.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Factor out some functions to tidy up the code in sdhci_execute_tuning.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use mmc_abort_tuning() instead of open-coding the stop command.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SDHCI falls back to fixed sampling if there is an error during tuning.
However it also reports an error unless there is periodic re-tuning.
That is not the best option because:
a) there is a reasonable chance that fixed sampling will work, especially
at room temperature.
b) re-tuning will be done again anyway if there are CRC errors.
Change to return no error always when falling back to fixed sampling.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If the driver has exhausted the maximum number of tuning loops, then fixed
sampling is used. To do that both SDHCI_CTRL_TUNED_CLK and
SDHCI_CTRL_EXEC_TUNING must be reset to 0, but only SDHCI_CTRL_TUNED_CLK
was being reset. Reset SDHCI_CTRL_EXEC_TUNING to 0 also.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3 ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NDan O'Donovan <dan@emutex.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This reverts commit fe5fb2e3 ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").

A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The void (*pre_req) callback in the struct mmc_host_ops vtable
is passing an argument "is_first_req" indicating whether this is
the first request or not.

None of the in-kernel users use this parameter: instead, since
they all just do variants of dma_map* they use the DMA cookie
to indicate whether a pre* callback has already been done for
a request when they decide how to handle it.

Delete the parameter from the callback and all users, as it is
just pointless cruft.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>