It's possible that there are some reasons to turn the PHY on while the
clock is 0. In this case we just won't wait for the DLL to lock.
This is a bit of a stopgap until we figure out exactly when we're
supposed to wait for the DLL to lock and when we're supposed to power
cycle the PHY.
Note: this patch should help with suspend/resume where the system will
try to turn the PHY back on when the clock is 0.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit 4ac0d5f245e1 ("mmc: sdhci-of-arasan: Always power
the PHY off/on when clock changes"), resolving conflicts with other
patches that have come after. It appears that on some boards / with
some eMMC devices that the patch is causing problems.
Presumably turning the phy off and on again at the wrong time while
initially setting up the card is confusing the card, the host, or the
PHY. We have lots of power cycles while initially setting up the card
because the main sdhci driver often turns off the clock by clearing
SDHCI_CLOCK_CARD_EN and then calls host->ops->set_clock() to set the
clock again. With all of those, we ended up with lots of power cycles.
Presumably the arguments made in the original patch still hold. That
is, whenever the card clock is turned off and on again (or changed) we
really should wait for the DLL to lock again. However, perhaps it's
really not that critical for the lower speeds.
It's possible that the right answer here is:
* Whenever set_clock() is called we should double-check that the DLL is
locked.
* Whenever set_clock() is called and we're actually changing clocks we
should do a power cycle around that.
* When we're doing a power cycle just because the clock changed, we
probably shouldn't do quite as many things (maybe don't need to
recalibarate, etc).
Unfortunately the interaction between SDHCI and the PHY is extremely
limited because of the limited PHY API. The PHY does have a reference
to the card clock and could theoretically register for notifications,
except that our clock is query only (it uses CLK_GET_RATE_NOCACHE) and
so can't really be notified about updates. I believe we would need a
major redesign of clock handling in SDHCI core to do better than that,
or we would need to make our one fake notifications. :(
Let's hope that we can eventually get more information from Arasan on
how all this should be handled before doing tons more work. Until then,
let's get back to a known working state. Note that the rest of the
patches in the 150 MHz series should still work fine even without this
one.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enabling support for ultra high speed mode cards requires some
voltage switching and interaction with the PMIC via a special
power IRQ. Add support for this.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To allow UHS mode to work properly, we need to implement a Qualcomm
specific set_uhs_signaling() callback function. This function differs
from the sdhci_set_uhs_signaling() in that we need check the clock
rate and enable UHS timing only if the frequency is above 100MHz.
This patch resolves the mmc_select_hs200 timeouts noticed after merging
commit a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after
speed mode switch")
mmc0: mmc_select_hs200 failed, error -110
mmc0: error -110 whilst initialising MMC card
mmc0: Reset 0x1 never completed.
sdhci: =========== REGISTER DUMP (mmc0)===========
sdhci: Sys addr: 0x00000000 | Version: 0x00002e02
sdhci: Blk size: 0x00004000 | Blk cnt: 0x00000000
sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci: Present: 0x01f80000 | Host ctl: 0x00000000
sdhci: Power: 0x00000000 | Blk gap: 0x00000000
sdhci: Wake-up: 0x00000000 | Clock: 0x00000003
sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000
sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
sdhci: Host ctl2: 0x00000000
sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000
sdhci: ===========================================
Fixes: a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after...")
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The controller does not clear the "reset bit" when it is reset without
a card in the slot. Because of this, the following error message is seen
while booting with no plugged SD card.
mmc1: Reset 0x1 never completed.
Add the SDHCI_QUIRK_NO_CARD_NO_RESET quirk to avoid this.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To support UHS modes for Tegra an external regulator must be present
to adjust the IO voltage accordingly. Even if the regulator is not
present but the host supports the UHS modes and the device supports the
UHS modes, then we will attempt to switch to a high-speed mode. Without
an external regulator, Tegra will fail to switch to the high-speed
mode.
It has been found that with some SD cards, that once it has been switch
to operate at a high-speed mode, all subsequent commands issues to the
card will fail and so it will not be possible to switch back to a non
high-speed mode and so the SD card initialisation will fail.
The SDHCI core does not require that the host have an external regulator
when switching to UHS modes and therefore, the Tegra SDHCI host
controller should only advertise the UHS modes as being supported if the
regulator for the IO voltage is present. Fortunately, Tegra has a vendor
specific register which can be used to control which modes are
advertised via the SDHCI_CAPABILITIES register. Hence, if there is no IO
voltage regulator available for the Tegra SDHCI host, then don't
advertise the UHS modes.
Note that if the regulator is not available, we also don't advertise that
the SDHCI is compatible with v3.0 of the SDHCI specification because
this will read the SDHCI_CAPABILITIES_1 register which will enable other
UHS modes.
This fixes commit 7ad2ed1dfc ("mmc: tegra: enable UHS-I modes") which
enables UHS mode without checking if the board can support them.
Fixes: 7ad2ed1dfc ("mmc: tegra: enable UHS-I modes")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The capabilities of the SDHCI host controller are read early during the
SDHCI host initialisation in sdhci_setup_host() and before any
regulators for the host have been requested. This means that if the host
supports some high-speed modes (according to its capabilities register),
but the board cannot because the appropriate voltage regulator is not
available, then the host cannot easily override the capabilities that
are supported.
To allow a SDHCI host controller to determine if it can support UHS high
speed modes via the presence of the MMC regulators, request the
regulators before reading the capabilities of the host controller. This
will allow the SDHCI host to use the 'reset' callback to take the
appropriate action (set flags, configure registers, etc) before the
capabilities register(s) are read.
Please note that some SDHCI hosts, such as the Tegra SDHCI host, has
the ability to mask bits in the capabilities register to prevent
certain capabilities from being advertised.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Everywhere else in the code MRFLD abbreviation is used for Intel Merrifield. Do
the same for sdhci-pci.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The tuning bits like FBCLK_SEL, SMP_CLK_SEL and DLY_CELL which affects
timing may have already been set by ROM if booting from SD3.0 mode like
SDR104. Let's clear it first during driver probe before doing the new
card enumeration to avoid working on the wrong timing.
Note that tuning bits are dynamical settings which may need to be kept
during MMC_PM_KEEP_POWER suspend, so we did not put them into hwinit
function.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci_esdhc_imx_hwinit() includes all basic hw intialization.
Calling it after resume to re-initialize hw in case its state
is already lost in low power mode.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Move tuning static configuration into basic hwinit function.
Tuning configuration may also be lost in low power mode, so
need restore in hwinit().
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Move all hw related static initializations into a separate function
which helps concentrate the hw related initialization code.
And that function could also be called by other places later as a
basic hw state restore.
e.g. suspend/resume where the hw state is possible to lost due to
low power mode.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When enable DDR, the clock factor definition is changed.
e.g. original 200Mhz will become 100Mhz once MIX_CTRL_DDREN bit is set
So we need to update the clock setting then the strobe dll can lock
the correct clock rate.
Additionally we also need disable the clock before locking strobe dll.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Indicating hw auto retuning support for mx6qdl in the fake caps_1
register and enable auto retuning in post_tuning process after
tuning completes.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enable HW auto retuning when set SDHCI_CTRL_EXEC_TUNING and clear it
when clear SDHCI_CTRL_TUNED_CLK.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If HW supports SDHCI_TUNING_MODE_3 which is auto retuning, we won't
retune during runtime suspend and resume, instead we use Re-tuning
Request signaled via SDHCI_INT_RETUNE interrupt to do retuning and
hw auto retuning during data transfer to guarantee the signal sample
window correction.
This can avoid a mass of repeatedly retuning during small file system
data access and improve the performance.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The delay cells of some SoCs may have less delay per one cell,
for such SoCs, user could set the start delay cell point to bypass
the first a few meaningless tuning commands.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Disable DLL delay line settings explicitly during driver initialization
in case ROM/uBoot had set an invalid delay.
e.g. MX6DL ROM has set the default delay line(DLLCTRL) to 0x1000021,
the uSDHC clock timing will become marginal when works on DDR mode
due to default delay and will possibly see CRC errors in case the board
is not perfectly designed on the eMMC chip layout.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently, we config the watermark_level register only in probe.
This will cause the mmc write operation timeout issue after system
resume back in LPSR mode. Because in LPSR mode, after system resume
back, the watermark_level register(0x44) changes to 0x08000880, which
set the write watermark level as 0, and set the read watermark level
as 128. This value is incorrect.
This patch restores the setting of watermark level register after
system resume back.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It will be used for platform specific suspend/resume state save/restore
work for some low power mode like Mega/Fast or LPSR mode.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver has already implemented the private .set_timeout()
callback for common SDHCI code to do correct timeout value setting,
it does not need call sdhci_calc_timeout(), so this quirk actually
is not working. Remove it now.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Switch to use the more robust common mmc_regulator_set_vqmmc()
function in MMC core which set the target voltage as close as
possible to target voltage.
We did not re-factor the whole sdhci_start_signal_voltage_switch()
cause we want to keep the original signal switch order between host
and card to avoid potential break.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This makes the error handling much more simpler than open-coding everything
and in addition makes the probe function smaller an tidier.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Export DSR register through sysfs same as we did for the CID, CSD and
OCR registers.
Signed-off-by: Bojan Prtvar <prtvar.b@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In dw_mmc.c, it's enabled by default.
It doesn't need to set MMC_CAP_ERASE in rockchip anymore.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This flag needs to use the trim/discard/erase commands.
dwmmc controller enables this flag by default.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The reason for why we expose these to dt is that some of
the controller is unable to send special cmd type due to
the hw limitation.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch adds description for no-sd, no-sdio, no-mmc. We expose
these to DT as some of the controllers are unable to deal with
special cmd type due to hw limitation.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Registers CID and CSD are already exported through sysfs so let's make
this interface complete by adding missing OCR register.
Signed-off-by: Bojan Prtvar <prtvar.b@gmail.com>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The capabilities in iproc platform data are magic numbers. So
replace them with the proper capability defines to make it
readable.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch adds the missing define for the suspend/resume
capability (according to SD Host Controller spec).
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Host drivers which needs to valdiate for non-supported MMC
commands and returnn error code for such requests.
To improve and simplify the behaviour, let's invent MMC_CAP2_NO_MMC
which these host drivers can set to tell the mmc core to skip sending MMC
commands during card initialization.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver registered for CPU frequency transitions to recalculate its
clock when ARM clock frequency changes (ratio between frequencies of
ARM's parent clock (fclk) and clock for peripherals remains fixed).
This is needed only on S3C24xx platform when cpufreq driver is enabled
so limit the ifdef to respective cpufreq Kconfig.
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci_send_command() starts a timer to catch cases where the host
controller fails. The timer is normally deleted when the request completes,
but in the case of sdhci_execute_tuning() the request is handled
differently and the timer is left running. This goes unnoticed because
tuning is done before another command so the timer gets reset then.
That should not be relied upon, so make sdhci_execute_tuning() delete the
timer.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The STOP command is sent in error conditions, even when the command is
not finished. Avoid triggering the warning for that in sdhci_send_command()
by setting host->cmd to NULL first.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, it will be possible to
need to reset the command circuit while the data circuit is in use, and
vice versa. It is now easy to determine whether the command or data circuit
is in use, and so just skip the corresponding reset if it is.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Factor out sdhci_auto_cmd12() so that there is a single place that controls
whether auto-CMD12 is used.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, there will have to be up
to two active requests (mrqs) at a time, instead of just one. That means
recording which request is finished. Doing that obsoletes host->mrq which
is therefore removed.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, there will have to be up
to two active requests (mrqs) at a time, instead of just one. Provide two
timers instead of just one. One of the timers is for requests that do not
use the data lines, and the other one is for requests that do.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Factor out sdhci_data_line_cmd() to improve readability and because it is
used in multiple places.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, there will have to be up
to two active requests (mrqs) at a time, instead of just one. That means
ensuring that all requests get errored out in the cases of card or driver
removal.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Several pointers are used to identify when interrupts are expected. Namely,
host->cmd, host->data_cmd and host->data. Ensure those are cleared when
a request finishes. That tidies the case when a request is errored out
before normal processing has completed, ensuring any interrupts that occur
subsequently are not acted upon.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDHCI recovers from errors by resetting the cmd and data circuits. Until
that is done, there very well might be more interrupts, so ignore them in
that case.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Factor out sdhci_needs_reset() so it can be reused.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, there will have to be up
to two active requests (mrqs) at a time, instead of just one. That means
the driver must identify which one to finish. Prepare for that by factoring
out sdhci_finish_mrq().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, it will be possible
that host->data is not NULL when preparing a new request. Move a warning
that assumes otherwise.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, there will have to be up
to two active requests (mrqs) at a time, instead of just one. That means
host->mrq will not be able to be used.
In several places, host->mrq is used when instead the mrq can be determined
from the cmd or data pointers. Reduce the use of host->mrq by doing that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Now that there is host->data_cmd to record the command for which a data
interrupt is expected, it is possible to determine whether a command with
busy signaling has completed without an extra flag. So host->busy_handle
is not needed. Remove it.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to support commands during data transfer, there must be a
distinction between the command that is using the command line (and
for which a command interrupt is expected) and the command that is
using the data lines (for which a data interrupt is expected).
There is host->cmd for the command line, but there is only host->data
for the data lines, which is a different structure, does not represent
the command in use, and is anyway NULL in the case of commands that use
the data lines for busy signalling instead of data transfer.
Introduce host->data_cmd to record what command is using the data lines,
and use that instead of host->cmd when referring to the data command.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
