This enables access the actual_clock via sys.
root@imx6qsabreauto:~# cat /sys/kernel/debug/mmc0/ios
clock:          198000000 Hz
actual clock:   198000000 Hz
vdd:            17 (2.9 ~ 3.0 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 0 (1.80 V)
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

According to spec, the pre_div for imx6q should be 1, or the biggest
clock rate we can get is a half of host clock rate.  This may cause
we can not get the proper clock rate as we want.  e.g. if the desired
clock is 200Mhz, however, the host clock is 200Mhz too, then it causes
the actual clock we get is 100Mhz due to pre_div is 2.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Without proper pinctrl state, the card may not be able to work
on high speed stablely. e.g. SDR104.

This patch add pinctrl state switch code according to different
uhs mode include 100mhz sate, 200mhz sate and normal state
(50Mhz and below).
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Freescale i.MX6Q/DL uSDHC clock tuning progress is a little different from
the standard tuning process defined in host controller spec v3.0.
Thus we use platform_execute_tuning instead of standard sdhci tuning.

The main difference are:
1) not only generate Buffer Read Ready interrupt when tuning is performing.
   It generates all other DATA interrupts like the normal data command.
2) SDHCI_CTRL_EXEC_TUNING is not automatically cleared by HW,
   instead it's controlled by SW.
3) SDHCI_CTRL_TUNED_CLK is not automatically set by HW,
   it's controlled by SW.
4) the clock delay for every tuning is set by SW.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The signal voltage switch flow requires to shutdown and output
clock in a specific sequence according to standard host controller
v3.0 spec. In that timing, the card must really receive clock or not.

However, for i.MX6Q, the uSDHC will not output clock even the clock
is enabled until there is command or data in transfer on the bus,
which will then cause singal voltage switch always to fail.

For i.MX6Q, we clear ESDHC_VENDOR_SPEC_FRC_SDCLK_ON bit to let
controller to gate off clock automatically and set that bit
to force clock output if clock is on.

This is required by SD3.0 support.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

We need a lot of imx6 specific things into common esdhc_set_clock
for support SD3.0 and eMMC DDR mode which is not needed for power pc
platforms, so esdhc_set_clock seems not so common anymore.

Instead of keeping add platform specfics things into this common API,
we choose to move that code into platform driver itself to handle.
This can also exclude the dependency between imx and power pc on this
headfile and is easy for maintain in the future.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

It helps for platform code to use it send tuning commands.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The tuning of some platforms may not follow the standard host control
spec v3.0, e.g. Freescale uSDHC on i.MX6Q/DL.
Add a hook here to allow execute platform specific tuning instead of
standard host controller tuning.

The hook only replaces the tuning process, so it's placed after tuning
checking and before the real tuning process.

Some notes for the tuning hook:
1) it needs handle lock itself if it wants to access host controller
according platform specific implementation.
2) do not need to handle runtime pm since it executes with runtime pm
get already.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This avoid duplicated implementation.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This avoid duplicated implementation and also fixes missing iounmap() and
release_mem_region() calls in sdhci_bcm_kona_remove().  sdhci_pltfm_init()
calls request_mem_region() and ioremap(), thus we need to call the
corresponding iounmap() and release_mem_region() calls in
sdhci_bcm_kona_remove().
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

'dw_mci_socfpga_probe' is used only in this file. Make it static.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

'dw_mci_socfpga_match' is always compiled in.
Hence of_match_ptr is not necessary.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

devm_request_and_ioremap() is deprecated. Use devm_ioremap_resource()
instead.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Clean up the duplicate macros:
mmc_sd_card_uhs -> mmc_card_uhs
mmc_sd_card_set_uhs -> mmc_card_set_uhs
Signed-off-by: NJackey Shen <jackey.shen@amd.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In some cases, a NULL pointer dereference happens because data is NULL when
STATE_END_REQUEST case is reached in atmci_tasklet_func.

Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: NRodolfo Giometti <giometti@enneenne.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

When a software timeout occurs, the transfer is not stopped. In DMA case,
it causes DMA channel to be stuck because the transfer is still active
causing following transfers to be queued but not computed.

Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Reported-by: NAlexander Morozov <etesial@gmail.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

While speed mode is changed, CMD13 cannot be guaranteed.
According to the spec., it is not recommended to use CMD13
to check the busy completion of the timing change.
If CMD13 is used in this case, CRC error must be ignored.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

In IDMAC mode EVENT_XFER_COMPLETE is set when RI/TI of last descriptor
is done. So if errors are happened in the middle of data transfers,
'dw_mci_stop_dma' during error handing can be called and eventually
prevents this flag to be set.  This results in permanent wait for
EVENT_XFER_COMPLETE in 'dw_mci_tasklet_func'.  Therefore, if dma
running is stopped forcibly, EVENT_XFER_COMPLETE should be set.
Reported-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

First, compiling warning along with previous change is removed.
[drivers/mmc/host/dw_mmc.c:1890:7: warning: unused variable 'ctrl']
And with the recommendation in manual, IDMAC software reset is followed
by dma-reset of the CTRL register in order to terminate the transfer.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are three resets in CTRL register.  FIFO reset is especially used
in several points with the same routine. It could be replaced with one
function and the others may be applied similarly if needed.  So,
mci_wait_reset() is modified to allow various bit field of reset.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Main change corresponds to dw_mci_command_complete().  And EBE is
divided into read and write.  Some minor changes for code readability.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In error cases, DTO interrupt may or may not be generated depending
on remained data. Stop/Abort command ensures DTO generation for that
situation. Currently if 'stop' field of data is empty, there is no
stop/abort command. So, it could hang waiting DTO. This change
reinforces these cases.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Even if response error is detected in case data command, data transfer
is continued. It means that data can live in FIFO. Current handling
just breaks out the request when seeing the command error. This causes
kernel panic in dw_mci_read_data_pio() [host->data = NULL]. And also,
FIFO should be guaranteed to be empty.

Unable to handle kernel NULL pointer dereference at virtual address 00000018
<...>
[<c02af814>] (dw_mci_read_data_pio+0x68/0x198) from [<c02b04b4>] (dw_mci_interrupt+0x374/0x3a0)
[<c02b04b4>] (dw_mci_interrupt+0x374/0x3a0) from [<c006b094>] (handle_irq_event_percpu+0x50/0x194)
[<c006b094>] (handle_irq_event_percpu+0x50/0x194) from [<c006b214>] (handle_irq_event+0x3c/0x5c)
[<c006b214>] (handle_irq_event+0x3c/0x5c) from [<c006de1c>] (handle_fasteoi_irq+0xa4/0x148)
[<c006de1c>] (handle_fasteoi_irq+0xa4/0x148) from [<c006aa88>] (generic_handle_irq+0x20/0x30)
[<c006aa88>] (generic_handle_irq+0x20/0x30) from [<c000f154>] (handle_IRQ+0x38/0x90)
[<c000f154>] (handle_IRQ+0x38/0x90) from [<c00085bc>] (gic_handle_irq+0x34/0x68)
[<c00085bc>] (gic_handle_irq+0x34/0x68) from [<c0011f40>] (__irq_svc+0x40/0x70)
Exception stack(0xef0b1c00 to 0xef0b1c48)
1c00: 000eb0cf ffffffff 00001300 c01a7738 ef295e10 0000000a c04df298 ef0b1dc0
1c20: ef295ec0 00000000 00000000 00000006 00000000 ef0b1c48 c02b1274 c01a7764
1c40: 20000113 ffffffff
[<c0011f40>] (__irq_svc+0x40/0x70) from 	[<c01a7764>] (__loop_delay+0x0/0xc)
Code: e1a00005 e0891006 e0662004 e12fff33 (e59a3018)
---[ end trace a7043b9ba9aed1db ]---
Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Card Read Threshold should be ensured that the card clock does not stop
in the middle of a block of data being transferred from the card to the
Host. Specially, clock stop is allowed in fast transfer such as HS200
or SDR104 mode. And so, it should be enabled.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This change helps to choose msize, rx_watermark and tx_watermark
depending on block size for IDMAC mode.  For SDIO block size can be
variable, so if these values are set incorrectly, card clock may stop.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Both f_max and f_min will be informed for core layer to request
valid clock rate. But current setting from 'host->bus_hz' may
not represent the max/min frequency properly. Even if host can
actually support high speed than bus_hz, core layer will not
request clock rate over bus_hz. Basically, f_max/f_min can be set
with the values according to spec. And then host will make its best
effort to meet the rate.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

'supports-highspeed' is not one of the quirks but is a capability.
So, it's removed from quirks.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

As host controller can support eMMC's HS200 mode at 1.8V or 1.2V,
these capability will be added.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Exynos's host has divider logic before 'cclk_in' to controller core.
It means that actual clock rate of ciu clock comes from this divider
value. So, source clock should be adjusted along with 'ciu_div' which
indicates the host's divider ratio. Setting clock rate basically fits
the required speed. Specially, 'cclk_in' should have double rate of
target speed in case of DDR 8-bit mode.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Implements variable delay tuning. In this change, exynos host can
determine the correct sampling point for the HS200 and SDR104 speed mode.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For the speed modes HS200 and SDR104, tuning is needed to determine the
correct sampling point. Actual tuning procedure is provided by specific
host controller driver.  This patch defines the tuning command and
tuning data.  Additionally, 'struct dw_mci_slot' is moved to header
file to consider the extensive usages in driver.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Exynos5420 Mobile Storage Host controller has Security Management
Unit (SMU) for channel 0 and channel 1 (mainly for eMMC).
This time, SMU configuration is set for non-encryption mode.
Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Current platform specific private data initialization call
dw_mci_exynos_priv_init() can be used to do platform specific
initialization of SMU and others in future. So the drv_data->init
call has moved to dw_mci_probe().
Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Currently platform specific private data initialization is done by
dw_mci_socfpga_priv_init and dw_mci_socfpga_parse_dt. As we already have
separate platform specific device tree parser dw_mci_socfpga_parse_dt,
move the dw_mci_socfpga_priv_init code to dw_mci_socfpga_parse_dt.
We can use the dw_mci_socfpga_priv_init to do some actual platform
specific initialization.
Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Currently platform specific private data initialization is done by
dw_mci_exynos_priv_init and dw_mci_exynos_parse_dt. As we already have
separate platform specific device tree parser dw_mci_exynos_parse_dt,
move the dw_mci_exynos_priv_init code to dw_mci_exynos_parse_dt.
We can use the dw_mci_exynos_priv_init to do some actual platform
specific initialization of SMU and etc.
Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The TMOUT register is set to 0xffffffff at probe time but isn't
set after suspend/resume.  Add an init of this value.

No problems were observed without this (it will also be set in
__dw_mci_start_request if there is data to send), but it makes the
register dump before and after suspend cleaner.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Previously the dw_mmc driver would ignore any requests to disable the
card's clock.  This doesn't seem like a good thing in general, but had
one extra bad side effect in the following situation:
* mmc core would set clk to 400kHz at boot time while scanning
* mmc core would set clk to 0 since no card, but it would be ignored.
* suspend to ram and resume; clocks in the dw_mmc IP block are now 0
  but dw_mmc thinks that they're 400kHz (it ignored the set to 0).
* insert card
* mmc core would set clk to 400kHz which would be considered a no-op.

Note that if there is no card in the slot and we do a suspend/resume
cycle, we _do_ still end up with differences in a dw_mmc register
dump, but the differences are clock related and we've got the clock
disabled both before and after, so this should be OK.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
looping around forever.  This has been seen to happen on exynos5420
silicon despite the fact that we haven't enabled any wakeup events due
to a silicon errata.  It is safe to do on all exynos variants.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The MMC subsystem handles looking for a card at probe time. Queuing up our
own can race with the rest of the MMC subsystem and cause problems if we
get unlucky with timing. Just remove driver own detection triggering.  While
progressing the request from 'mmc_rescan', if 'dw_mci_work_routine_card'
routine is activated, it will cancel the current request. The problem case
is that 'mmc_rescan' is prior to 'dw_mci_work_routine_card' from host own.
Specifically, the following message shows the detection problem in driver's
probing. It would get an err -123 (-ENOMEDIUM) during probe.

[    4.216595] dwmmc_exynos 12210000.dwmmc1: Using internal DMA controller.
[    4.395935] dwmmc_exynos 12210000.dwmmc1: Version ID is 250a
[    4.401948] dwmmc_exynos 12210000.dwmmc1: DW MMC controller at irq 108, 64 bit host data width, 64 deep fifo
[    4.424430] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.453975] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.459592] mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz, actual 400000HZ div = 125)
[    4.484258] dwmmc_exynos 12210000.dwmmc1: 1 slots initialized
[    4.485406] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.487606] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.489794] dwmmc_exynos 12210000.dwmmc1: sdr0 mode (irq=108, width=0)
[    4.509757] mmc1: error -123 whilst initialising SDIO card
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

cscope says there are no callers for mmc_try_claim_host in the kernel.
No reason to keep it.
Signed-off-by: NGrant Grundler <grundler@chromium.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>