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.
mmc: sdhci-esdhc-imx: support setting tuning start point
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.
mmc: sdhci-esdhci-imx: disable DLL delay line settings explicitly
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.
mmc: sdhci-esdhc-imx: restore watermark level setting after resume
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.
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.
mmc: sdhci: using common mmc_regulator_set_vqmmc()
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.
Shawn Lin [Thu, 14 Jul 2016 08:26:03 +0000 (16:26 +0800)]
Documentation: mmc: add description for new no-sd* and no-mmc
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>
Shawn Lin [Fri, 1 Jul 2016 07:45:28 +0000 (15:45 +0800)]
mmc: core: Allow hosts to specify non-support for MMC commands
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>
mmc: s3cmci: Register cpufreq notifier only on S3C24xx
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:38 +0000 (16:24 +0300)]
mmc: sdhci: sdhci_execute_tuning() must delete timer
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:37 +0000 (16:24 +0300)]
mmc: sdhci: Avoid STOP cmd triggering warning in sdhci_send_command()
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:36 +0000 (16:24 +0300)]
mmc: sdhci: Do not reset cmd or data circuits that are in use
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:34 +0000 (16:24 +0300)]
mmc: sdhci: Allow for finishing multiple requests
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:33 +0000 (16:24 +0300)]
mmc: sdhci: Separate timer timeout for command and data requests
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:31 +0000 (16:24 +0300)]
mmc: sdhci: Ensure all requests get errored out
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:30 +0000 (16:24 +0300)]
mmc: sdhci: Clear pointers when a request finishes
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:29 +0000 (16:24 +0300)]
mmc: sdhci: Track whether a reset is pending
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:27 +0000 (16:24 +0300)]
mmc: sdhci: Factor out sdhci_finish_mrq()
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:26 +0000 (16:24 +0300)]
mmc: sdhci: Move host->data warning
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:25 +0000 (16:24 +0300)]
mmc: sdhci: Reduce the use of host->mrq
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:24 +0000 (16:24 +0300)]
mmc: sdhci: Get rid of host->busy_handle
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:23 +0000 (16:24 +0300)]
mmc: sdhci: Record what command is using the data lines
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>
Adrian Hunter [Wed, 29 Jun 2016 13:24:22 +0000 (16:24 +0300)]
mmc: sdhci: Simplify sdhci_finish_command() by clearing host->cmd at the start
sdhci_finish_command() is going to set host->cmd to NULL. Simplify the
code by using a local variable to hold host->cmd and set host->cmd to
NULL at the start.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:21 +0000 (16:24 +0300)]
mmc: sdhci: Get rid of redundant BUG_ONs
BUG is never the right thing for SDHCI to do. Get rid of BUG_ON in cases it
will oops anyway if the pointer is NULL, or if the condition is logically
impossible.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:20 +0000 (16:24 +0300)]
mmc: sdhci: Move busy signal handling into sdhci_finish_cmd()
In order to support commands during data transfer, command and data
handling needs to be untangled.
That means sdhci_finish_cmd() must not be called from the data IRQ
handler. It is being called because of busy signal handling, which
is treating the command as not finished until the busy signal is
released.
Instead, move busy signal handling from sdhci_cmd_irq() into
sdhci_finish_cmd(). Then the data IRQ handler does not need to call
sdhci_finish_cmd() and can instead finish the request.
What this means in practice for a command with busy signaling, is that
the command response is read from the host controller when the command
complete interrupt is received, thus freeing up the command circuit for
other commands.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:19 +0000 (16:24 +0300)]
mmc: sdhci-pci: Do not runtime suspend at the end of sdhci_pci_probe()
At the successful conclusion of sdhci_pci_probe(), if runtime pm was
allowed, the device would be runtime suspended. That wastes a lot of time
during initialization. Instead leave the device active until the mmc core
scans for a card.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:18 +0000 (16:24 +0300)]
mmc: sdhci: Add sdhci_read_caps()
Add sdhci_read_caps() and __sdhci_read_caps() to make it easier for drivers
to fix the version and capabilities registers.
Pedantically, the SDHCI specification states that the capabilities
registers are valid when the host controller resets the Software Reset For
All bit. That requirement has always been satisfied by performing a reset
at the start of initialization, and consequently that is now part of the
new functions.
Although the SDHCI_QUIRK_MISSING_CAPS quirk has not yet been removed,
drivers that want to provide their own caps can now use these functions
instead of that quirk.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:16 +0000 (16:24 +0300)]
mmc: sdhci: Make signal voltage support explicit
Signal voltage support is not a quirk, it is a capability. According to the
SDHCI specification, support for 1.8V signaling is determined by the
presence of one of the capability bits SDHCI_SUPPORT_SDR50,
SDHCI_SUPPORT_SDR104, or SDHCI_SUPPORT_DDR50. This is complicated by also
supporting eMMC which has 1.8V modes and 1.2V modes. It would be possible
to use the transfer mode to determine signal voltage support, except for
eMMC DDR52 mode which uses the same capability (MMC_CAP_1_8V_DDR) for 1.8V
signaling and 3V signaling.
In addition, the mmc core will fail over from one signaling voltage to the
next (refer mmc_power_up()) which means SDHCI really needs to validate
which voltages are actually supported.
Introduce SDHCI flags for signal voltage support and set them based on the
supported transfer modes. In general, drivers should prefer to set the
supported transfer modes correctly rather than change the signal voltage
capability, except in the case where 3V DDR52 is supported but 1.8V is
not.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:15 +0000 (16:24 +0300)]
mmc: sdhci: Split sdhci_add_host()
Split sdhci-add_host() in order to further our objective to make
sdhci into a library.
The split divides code that sets up mmc and sdhci parameters, from
code that actually activates things - such as tasklet initialization,
requesting the irq, and adding (and starting) the host.
This gives drivers an opportunity to change various settings before
committing to start the host.
Drivers can continue to call sdhci_add_host() but drivers that want
to take advantage of the split instead call sdhci_setup_host() followed
by __sdhci_add_host().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Wed, 29 Jun 2016 13:24:14 +0000 (16:24 +0300)]
mmc: sdhci: Do not call implementations of mmc host ops directly
Drivers must be able to provide their own implementations for mmc host
operations. Consequently, SDHCI should call those not the default
implementations. Do that by calling indirectly through the mmc host ops
function pointers.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Chaotian Jing [Thu, 30 Jun 2016 02:01:00 +0000 (10:01 +0800)]
mmc: mediatek: fix CMD21/CMD19 timeout issue
we did not deal with the read data of CMD21/CMD19 if there is
response CRC error of CMD21/CMD19, in this case, eMMC/SD may
still in send-data state. therefore, all of next commands cannot
get response as device is not in transfer state.
for resolving this issue, still need deal with the data receive
to make device back to transfer state.
Chaotian Jing [Thu, 30 Jun 2016 02:00:59 +0000 (10:00 +0800)]
mmc: mediatek: fix CRC error when calling mmc_select_hs400()
the tune result of hs200 mode at 200Mhz is not suitable for 50Mhz,
mmc_select_hs400() will set clock frequency to 50Mhz, use defalut
tune setting for 50Mhz to avoid CRC error.
Chaotian Jing [Thu, 30 Jun 2016 02:00:58 +0000 (10:00 +0800)]
mmc: mediatek: do not tune data for HS400 mode
for hs400 mode, should only tune DS delay, should not
tune PAD_TUNE for data path.
if eMMC will run at hs400 mode, do not tune data while
call ops->execute_tuning().
Shawn Lin [Fri, 24 Jun 2016 07:39:52 +0000 (15:39 +0800)]
mmc: dw_mmc: fix unmap sg twice when finding data err
DATA_OVER(the same for RI/TI of IDMAC) interrupt may come
up together with data error interrupts. If so, the interrupt
routine set EVENT_DATA_ERR to the pending_events and schedule
the tasklet but we may still fallback to the IDMAC interrupt
case as the tasklet may come up a little late, namely right
after the IDMAC interrupt checking. This will casue dw_mmc
unmap sg twice. We can easily see it with CONFIG_DMA_API_DEBUG
enabled.
WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1096 check_unmap+0x7bc/0xb38
dwmmc_exynos 12200000.mmc: DMA-API: device driver tries to free DMA memory it
has not allocated [device address=0x000000006d9d2200]
[size=128 bytes]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc4 #26
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0112b4c>] (unwind_backtrace) from [<c010d888>] (show_stack+0x20/0x24)
[<c010d888>] (show_stack) from [<c03fab0c>] (dump_stack+0x80/0x94)
[<c03fab0c>] (dump_stack) from [<c0123548>] (__warn+0xf8/0x110)
[<c0123548>] (__warn) from [<c01235a8>] (warn_slowpath_fmt+0x48/0x50)
[<c01235a8>] (warn_slowpath_fmt) from [<c042ac90>] (check_unmap+0x7bc/0xb38)
[<c042ac90>] (check_unmap) from [<c042b25c>] (debug_dma_unmap_sg+0x118/0x148)
[<c042b25c>] (debug_dma_unmap_sg) from [<c077512c>] (dw_mci_dma_cleanup+0x7c/0xb8)
[<c077512c>] (dw_mci_dma_cleanup) from [<c0773f24>] (dw_mci_stop_dma+0x40/0x50)
[<c0773f24>] (dw_mci_stop_dma) from [<c0777d04>] (dw_mci_tasklet_func+0x130/0x3b4)
[<c0777d04>] (dw_mci_tasklet_func) from [<c0129760>] (tasklet_action+0xb4/0x150)
..[snip]..
---[ end trace 256f83eed365daf0 ]---
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Jaehoon Chung [Tue, 21 Jun 2016 05:35:38 +0000 (14:35 +0900)]
mmc: dw_mmc: add the card write threshold for HS400 mode
Since v2.80a, dwmmc controller introduced the card write threshold for
HS400 mode. So CardThrCtl can be supported during write operation, not
only read operation.
(Note: Only use the write threshold when mode is HS400.)
To use more compatible, removed "_rd_" from function name.
Jaehoon Chung [Tue, 21 Jun 2016 05:35:37 +0000 (14:35 +0900)]
mmc: dw_mmc: remove the quirks flags
Remove the quirks flag. (DW_MCI_QUIRK_BROKEN_DTO)
For removing this, enabled the dto_timer by defaults.
It doesn't see any I/O performance degression.
In future, dwmmc controller should not use the quirks flag.
Seung-Woo Kim [Mon, 20 Jun 2016 04:09:45 +0000 (13:09 +0900)]
mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()
This patch removes following UBSAN warnings in dw_mci_setup_bus().
UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14
shift exponent 250 is too large for 32-bit type 'unsigned int'
Call trace:
[<ffffff90080908a8>] dump_backtrace+0x0/0x380
[<ffffff9008090c3c>] show_stack+0x14/0x20
[<ffffff90087457b8>] dump_stack+0xe0/0x120
[<ffffff90087b1360>] ubsan_epilogue+0x18/0x68
[<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc
[<ffffff9008d89cb8>] dw_mci_setup_bus+0x3a0/0x438
[...]
UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1132:27
shift exponent 250 is too large for 32-bit type 'unsigned int'
Call trace:
[<ffffff90080908a8>] dump_backtrace+0x0/0x380
[<ffffff9008090c3c>] show_stack+0x14/0x20
[<ffffff90087457b8>] dump_stack+0xe0/0x120
[<ffffff90087b1360>] ubsan_epilogue+0x18/0x68
[<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc
[<ffffff9008d89c9c>] dw_mci_setup_bus+0x384/0x438
[...]
The warnings are caused because of bit shift which is used to
filter spamming message for CONFIG_MMC_CLKGATE, but the config is
already removed. So this patch just removes the shift.
Doug Anderson [Tue, 26 Apr 2016 08:03:58 +0000 (10:03 +0200)]
mmc: dw_mmc: Wait for data transfer after response errors.
According to the DesignWare state machine description, after we get a
"response error" or "response CRC error" we move into data transfer
mode. That means that we don't necessarily need to special case
trying to deal with the failure right away. We can wait until we are
notified that the data transfer is complete (with or without errors)
and then we can deal with the failure.
It may sound strange to defer dealing with a command that we know will
fail anyway, but this appears to fix a bug. During tuning (CMD19) on
a specific card on an rk3288-based system, we found that we could get
a "response CRC error". Sending the stop command after the "response
CRC error" would then throw the system into a confused state causing
all future tuning phases to report failure.
When in the confused state, the controller would show these (hex codes
are interrupt status register):
CMD ERR: 0x00000046 (cmd=19)
CMD ERR: 0x0000004e (cmd=12)
DATA ERR: 0x00000208
DATA ERR: 0x0000020c
CMD ERR: 0x00000104 (cmd=19)
CMD ERR: 0x00000104 (cmd=12)
DATA ERR: 0x00000208
DATA ERR: 0x0000020c
...
...
It is inherently difficult to deal with the complexity of trying to
correctly send a stop command while a data transfer is taking place
since you need to deal with different corner cases caused by the fact
that the data transfer could complete (with errors or without errors)
during various places in sending the stop command (dw_mci_stop_dma,
send_stop_abort, etc)
Instead of adding a bunch of extra complexity to deal with this, it
seems much simpler to just use the more straightforward (and less
error-prone) path of letting the data transfer finish. There
shouldn't be any huge benefit to sending the stop command slightly
earlier, anyway.
Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Alim Akhtar <alim.akhtar@gmail.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ben Dooks [Tue, 7 Jun 2016 13:37:19 +0000 (14:37 +0100)]
mmc: dw_mmc: fix 32bit little-endian access of des1 field
The IDMAC_SET_BUFFER1_SIZE() macro modifies des1, but does
not check if the value being passed is big or little endian
desptire the des1 field being marked as __le32.
Fix the issue by ensuring the values are changed from the
cpu endian to the descriptor endian by using cpu_to_le32.
Spotted whilst doing big endian conversion work on Exynos,
and stops the mmc worker thread from stalling.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Doug Anderson [Tue, 10 Mar 2015 15:48:10 +0000 (08:48 -0700)]
mmc: dw_mmc: Consider HLE errors to be data and command errors
The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but
nothing in the interrupt handler actually handles them and ACKs them.
That means that if we ever get an HLE error we'll just keep getting
interrupts and we'll wedge things.
We really don't expect HLE errors but if we ever get them we shouldn't
silently ignore them.
Note that I have seen HLE errors while constantly ejecting and
inserting cards (ejecting while inserting, etc).
Shawn Lin [Fri, 27 May 2016 06:37:05 +0000 (14:37 +0800)]
mmc: dw_mmc: check card present before starting request
The main reason to add this check is to avoid unnecessary
mmc_request like the on-going cmd and the corresponding sbc
if the card is removed. Although we have already checked this in
dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot
for noremovable devices, but there is a timing gap before it really
calls dw_mci_get_cd as mmc_detect_change needs some delay here.
Another gain here is that we could save some checkings of card status
after sd card been removed.
Ulf Hansson [Tue, 21 Jun 2016 13:12:50 +0000 (15:12 +0200)]
mmc: sh_mmcif: Use a 10s timeout in the error recovery path
The current value means an mdelay(1) may execute up to 10000000 times,
which translates to around ~2.8 hours. This is probably not what the
orignal author had in mind. Let's instead use 10s, which is the same value
sh_mmcif is using for other timeouts.
Ulf Hansson [Tue, 21 Jun 2016 13:12:49 +0000 (15:12 +0200)]
mmc: sh_mmcif: Inform the mmc core about the max busy timeout
The sh_mmcif driver is already using a 10s request timeout. Let's also
inform the mmc core about this value, as there are situations when it
needs to know about it.
Ulf Hansson [Tue, 21 Jun 2016 13:12:48 +0000 (15:12 +0200)]
mmc: sh_mmcif: Use response type to know when to enable busy detection
The sh_mmcif explicity checks for certain commands to decide when to
enable HW busy detection. Instead, it should only check the response type
as it tells if busy detection is needed.
In this way, the mmc core also gets full control whether it thinks busy
detection should be done or not. In some specific scenarios, like for
ERASE and STOP commands it may decide to fall back to use a CMD13 to poll
the card status instead.
Ulf Hansson [Tue, 21 Jun 2016 13:12:47 +0000 (15:12 +0200)]
mmc: sh_mmcif: Enable MMC_CAP2_NO_SD and MMC_CAP2_NO_SDIO
Enable the capabilities which tells the mmc core to prevent sending SD and
SDIO commands during card initialization. In this way, we can also remove
the validation of non-supported commands in the ->request() callback.
Ulf Hansson [Tue, 21 Jun 2016 13:12:46 +0000 (15:12 +0200)]
mmc: core: Allow hosts to specify non-support for SD commands
There are host drivers which needs to valdiate for non-supported SD
commands and returnn error code for such requests.
To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD
which these host drivers can set to tell the mmc core to skip sending SD
commands during card initialization.
trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Chuanxiao Dong [Wed, 22 Jun 2016 11:40:01 +0000 (14:40 +0300)]
mmc: sdhci: use pr_err for sdhci_dumpregs
sdhci_dumpregs is used to dump registers when error happens. Thus it should
use pr_err instead of pr_debug to show more information about the hardware.
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
[Fix whitespace and checkpatch warnings] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:53 +0000 (10:56 -0700)]
phy: rockchip-emmc: Set phyctrl_frqsel based on card clock
The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the
frequency range of DLL operation". Although the Rockchip variant of
this PHY has different ranges than the reference Arasan PHY it appears
as if the functionality is similar. We should set this phyctrl field
properly.
Note: as per Rockchip engineers, apparently the "phyctrl_frqsel" is
actually only useful in HS200 / HS400 modes even though the DLL itself
it used for some purposes in all modes. See the discussion in the
earlier change in this series: ("mmc: sdhci-of-arasan: Always power the
PHY off/on when clock changes"). In any case, it shouldn't hurt to set
this always.
Note that this change should allow boards to run at HS200 / HS400 speed
modes while running at 100 MHz or 150 MHz. In fact, running HS400 at
150 MHz (giving 300 MB/s) is the main motivation of this series, since
performance is still good but signal integrity problems are less
prevelant at 150 MHz.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:52 +0000 (10:56 -0700)]
phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()
There's no reason to store the return value of rockchip_emmc_phy_power()
in a variable nor to check it. Just return it.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:51 +0000 (10:56 -0700)]
Documentation: phy: Let the rockchip eMMC PHY get an exported card clock
As of an earlier change in this series ("Documentation: mmc:
sdhci-of-arasan: Add ability to export card clock") the SDHCI driver
used on Rockchip SoCs can now expose its clock. Let's now specify that
the PHY can use it.
Letting the PHY get access to this clock means it can adjust
phyctrl_frqsel field appropriately. Although the Rockchip PHY appears
slightly different than the reference Arasan one, you can see that the
Arasan datasheet [1] had it defined as:
Select the frequency range of DLL operation:
3b'000 => 200MHz to 170 MHz
3b'001 => 170MHz to 140 MHz
3b'010 => 140MHz to 110 MHz
3b'011 => 110MHz to 80MHz
3b'100 => 80MHz to 50 MHz
3b'101 => 275Mhz to 250MHz
3b'110 => 250MHz to 225MHz
3b'111 => 225MHz to 200MHz
On the Rockchip version of the PHY we have less granularity but the idea
is the same.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:50 +0000 (10:56 -0700)]
mmc: sdhci-of-arasan: Add ability to export card clock
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work
with arasan,sdhci-5.1) need to know the card clock in order to function
properly. Let's add the ability to expose this clock. Any PHY that
needs to know the clock rate can add a reference and query the clock
rate.
At the moment we register a CLK_GET_RATE_NOCACHE clock that simply
allows querying the clock. This allows us to be less intrusive with
regards to the main SDHCI driver, which has complex logic for adjusting
the SD clock. Right now we always fully power cycle the PHY when the
clock changes and that gives the PHY a good chance to query our clock.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:49 +0000 (10:56 -0700)]
Documentation: mmc: sdhci-of-arasan: Add ability to export card clock
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work
with arasan,sdhci-5.1) need to know the card clock frequency in order to
function properly. Physically in a SoC this clock is exported from the
SDHCI IP block to the PHY IP block and the PHY needs to know the speed.
Let's export the SDHCI card clock using a standard device tree mechanism
so that the PHY can get access to it and query the card clock frequency.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:47 +0000 (10:56 -0700)]
mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
In the the earlier change in this series ("Documentation: mmc:
sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the
mechansim for specifying a syscon to properly set corecfg registers in
sdhci-of-arasan. Now let's use this mechanism to properly set
corecfg_baseclkfreq on rk3399.
>From [1] the corecfg_baseclkfreq is supposed to be set to:
Base Clock Frequency for SD Clock.
This is the frequency of the xin_clk.
This is a relatively easy thing to do. Note that we assume that xin_clk
is not dynamic and we can check the clock at probe time. If any real
devices have a dynamic xin_clk future patches could register for
notifiers for the clock.
At the moment, setting corecfg_baseclkfreq is only supported for rk3399
since we need a specific map for each implementation. The code is
written in a generic way that should make this easy to extend to other
SoCs. Note that a specific compatible string for rk3399 is already in
use and so we add that to the table to match rk3399.
Douglas Anderson [Mon, 20 Jun 2016 17:56:46 +0000 (10:56 -0700)]
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs
As can be seen in Arasan's datasheet [1] there are several "corecfg"
settings in their SDHCI IP Block that are supposed to be controlled by
software. Although the datasheet referenced is a bit vague about how to
access corecfg, in Figure 5 you can see that for Arasan's PHY (a
separate component than their SDHCI component) they describe the
"phyctrl" registers as being "FROM SOC CTL REG", implying that it's up
to the licensee of the Arasan IP block to implement these registers. It
seems sane to assume that the "corecfg" registers in their SDHCI IP
block works in a similar way for all licensees of the IP Block.
Device tree has a model that allows a device to get a reference to
random registers located elsewhere in the SoC: sysctl. Let's leverage
this model and allow adding a sysctl reference to access the control
registers for the Arasan SDHCI PHYs.
Having a reference to the control registers doesn't do much for us on
its own since the Arasan spec doesn't specify how these corecfg values
are laid out in memory. In the SDHCI driver we'll need a map detailing
where each corecfg can be found in each implementation. This map can be
found using the primary compatible string of the SDHCI device. In that
spirit, document that existing rk3399 device trees already have a
specific compatible string, though up to now they've always been relying
on the driver supporting the generic.
Note that since existing devices seem to work fairly well as-is, we'll
list the syscon reference as "optional", but it's likely that we'll run
into much fewer problems if we can actually set the proper values in the
syscon, so it is strongly suggested that any SoCs where we have a map to
set the corecfg also include a reference to the syscon.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:45 +0000 (10:56 -0700)]
mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes
In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy
is supported") we added code to power the PHY off and on whenever the
clock was changed but we avoided doing the power cycle code when the
clock was low speed. Let's now do it always.
Although there may be other reasons for power cycling the PHY when the
clock changes, one of the main reasons is that we need to give the DLL a
chance to re-lock with the new clock.
One of the things that the DLL is for is tuning the Receive Clock in
HS200 mode and STRB in HS400 mode. Thus it is clear that we should make
sure we power cycle the PHY (and wait for the DLL to lock) when we know
we'll be in one of these two speed modes. That's what the original code
did, though it used the clock rate rather than the speed mode. However,
even in speed modes other than HS200,/HS400 the DLL is used for
something since it can be clearly observed that the PHY doesn't function
properly if you leave the DLL off.
Although it appears less important to power cycle the PHY and wait for
the DLL to lock when not in HS200/HS400 modes (no bugs were reported),
it still seems wise to let the locking always happen nevertheless.
Note: as part of this, we make sure that we never try to turn the PHY on
when the clock is off (when the clock rate is 0). The PHY cannot work
when the clock is off since its DLL can't lock.
This change requires ("phy: rockchip-emmc: Increase lock time
allowance") and will cause problems if picked without that change.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Douglas Anderson [Mon, 20 Jun 2016 17:56:44 +0000 (10:56 -0700)]
phy: rockchip-emmc: Increase lock time allowance
Previous PHY code waited a fixed amount of time for the DLL to lock at
power on time. Unfortunately, the time for the DLL to lock is actually
a bit more dynamic and can be longer if the card clock is slower.
Instead of waiting a fixed 30 us, let's now dynamically wait until the
lock bit gets set. We'll wait up to 10 ms which should be OK even if
the card clock is at the super slow 100 kHz.
On its own, this change makes the PHY power on code a little more
robust. Before this change the PHY was relying on the eMMC code to make
sure the PHY was only powered on when the card clock was set to at least
50 MHz before, though this reliance wasn't documented anywhere.
This change will be even more useful in future changes where we actually
need to be able to wait for a DLL lock at slower clock speeds.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Brian Norris [Mon, 20 Jun 2016 17:56:43 +0000 (10:56 -0700)]
phy: rockchip-emmc: reindent the register definitions
Some of the spacing was wrong (spaces instead of tabs), and due to
longer entries added later, the columns weren't aligned. Let's get
everything consistent.
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Brian Norris [Mon, 20 Jun 2016 17:56:42 +0000 (10:56 -0700)]
phy: rockchip-emmc: configure default output tap delay
The output tap delay controls helps maintain the hold requirements for
eMMC. The exact value is dependent on the SoC and other factors, though
it isn't really an exact science. But the default of 0 is not very good,
as it doesn't give the eMMC much hold time, so let's bump up to 4
(approx 90 degree phase?). If we need to configure this any further
(e.g., based on board or speed factors), we may need to consider a
device tree representation.
Suggested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Mon, 20 Jun 2016 17:56:41 +0000 (10:56 -0700)]
phy: rockchip-emmc: configure frequency range and drive impedance
Signal integrity analysis has suggested we set these values. Do this in
power_on(), so that they get reconfigured after suspend/resume.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Mon, 20 Jun 2016 17:56:40 +0000 (10:56 -0700)]
phy: rockchip-emmc: give DLL some extra time to be ready
According to the databook, 10.2us is the max time for dll to be ready to
work. However in testing, some chips need 20us for dll to be ready. This
patch adds some extra margin for dllrdy to be ready, fixing our
-ETIMEDOUT issues.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Al Cooper [Thu, 16 Jun 2016 16:47:16 +0000 (12:47 -0400)]
mmc: sdhci-brcmstb: Add driver for Broadcom BRCMSTB SoCs
Add SDHCI driver for Broadcom BRCMSTB SoCs.
This driver works with all ARM based SoCs and the 7425, 7429
and 7435 MIPS based SoCs.
The driver disables all UHS speed modes by default and relies
on the Device Tree node properties to enable these modes for
SoC/Board combinations that support them.
Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Pratibhasagar V [Thu, 9 Jun 2016 22:09:31 +0000 (18:09 -0400)]
mmc: core: Disable HPI for certain Hynix eMMC cards
Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.
As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[gdavis: Forward port and cleanup] Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Gwendal Grignou [Fri, 3 Jun 2016 16:08:52 +0000 (09:08 -0700)]
mmc: Set pref erase size based on size
If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase
size. As some high capacity eMMC (64MB) reports this size to 512kB, the
discard operations end up taking very long time.
Improve the behaviour by instead calculating the preferred erase size
based on the eMMC size. In this way the discard operations becomes faster.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
[Ulf: Updated changelog and improved comment in code] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ziyuan Xu [Thu, 26 May 2016 05:50:32 +0000 (13:50 +0800)]
mmc: mmc: Fix HS switch failure in mmc_select_hs400()
To slove the issue which was found on gru board for hs400.
[ 4.616946] sdhci: Secure Digital Host Controller Interface driver
[ 4.623135] sdhci: Copyright(c) Pierre Ossman
[ 4.722575] sdhci-pltfm: SDHCI platform and OF driver helper
[ 4.730962] sdhci-arasan fe330000.sdhci: No vmmc regulator found
[ 4.737444] sdhci-arasan fe330000.sdhci: No vqmmc regulator found
[ 4.774930] mmc0: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[ 4.980295] mmc0: switch to high-speed from hs200 failed, err:-84
[ 4.986487] mmc0: error -84 whilst initialising MMC card
We should change HS400 mode selection timing to meet JEDEC
specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ
after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode
selection:
Set the "Timing Interface" parameter in the HS_TIMING[185] field of the
Extended CSD register to 0x1 to switch to High Speed mode and then set
the clock frequency to a value not greater than 52MHZ.
Chaotian Jing [Thu, 19 May 2016 08:47:42 +0000 (16:47 +0800)]
mmc: mmc: fix switch timeout issue caused by jiffies precision
with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.
Chaotian Jing [Thu, 19 May 2016 08:47:41 +0000 (16:47 +0800)]
mmc: mmc: do not use CMD13 to get status after speed mode switch
Per JEDEC spec, it is not recommended to use CMD13 to get card status
after speed mode switch. below are two reason about this:
1. CMD13 cannot be guaranteed due to the asynchronous operation.
Therefore it is not recommended to use CMD13 to check busy completion
of the timing change indication.
2. After switch to HS200, CMD13 will get response of 0x800, and even the
busy signal gets de-asserted, the response of CMD13 is aslo 0x800.
Chaotian Jing [Thu, 19 May 2016 08:47:40 +0000 (16:47 +0800)]
mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()
Some MMC hosts do not support MMC_CAP_WAIT_WHILE_BUSY, but implements the
->card_busy() callback. In such cases, extend __mmc_switch() to use this
method to check card status after switch command.
Adrian Hunter [Thu, 23 Jun 2016 11:00:58 +0000 (14:00 +0300)]
mmc: sdhci: Fix sdhci_card_busy()
host->card_busy() was introduced for SD voltage switching which checks all
4 data lines.
Increasingly, host->card_busy is being used to poll the the busy signal
which is only data line 0 (DAT[0]).
The current logic in sdhci_card_busy() does not work in that case because
it returns false if any of the data lines is high. It also ignores
possibilities:
- data lines 1-3 are not connected and could show at any level
- data lines 1-2 can be used by SDIO for other purposes
According to the SD specification, it is OK to check any of the data lines
for voltage switching, so change to use DAT[0] only.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently sdhci-arasan 5.1 can support enhanced strobe function,
and we now limit it just for "arasan,sdhci-5.1". Add
mmc-hs400-enhanced-strobe in DT to enable the function if we're
sure our controller can support it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We introduce HS400 with enhanced strobe function, so we need
to add it for debug show.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Thu, 26 May 2016 01:56:22 +0000 (09:56 +0800)]
mmc: core: implement enhanced strobe support
Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Thu, 26 May 2016 01:56:12 +0000 (09:56 +0800)]
mmc: core: add mmc-hs400-enhanced-strobe support
This patch introduce mmc-hs400-enhanced-strobe for platforms
which want to enable enhanced strobe function from DT if the
mmc host controller claims to support enhanced strobe.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Thu, 26 May 2016 01:56:02 +0000 (09:56 +0800)]
Documentation: mmc: add mmc-hs400-enhanced-strobe
mmc-hs400-enhanced-strobe is used to claim that the
host can support hs400 mode with enhanced strobe
introduced by emmc 5.1 spec.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
projects / linux-beck.git / log