- 21 Oct, 2013 2 commits
-
-
Axel Lin authored
Simplify the code to set/clear BM_SD_OFF bit: | power_inverted: 0 | power_inverted: 1 ------------------------------------------------- enable: 0 | SET BM_SD_OFF | CLEAR BM_SD_OFF ------------------------------------------------- enable: 1 | CLEAR BM_SD_OFF | SET BM_SD_OFF Signed-off-by:Axel Lin <axel.lin@ingics.com> Acked-by:
Tony Prisk <linux@prisktech.co.nz> Signed-off-by:
Chris Ball <cjb@laptop.org>
-
David Cohen authored
Implement initial SDHCI Intel Merrifield support. This patch is based on previous one from Yunpeng Gao <yunpeng.gao@intel.com>. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
-
- 27 Sep, 2013 1 commit
-
-
Dong Aisheng authored
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:
Dong Aisheng <b29396@freescale.com> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
- 26 Sep, 2013 37 commits
-
-
Dong Aisheng authored
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:
-
Dong Aisheng authored
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:
-
Dong Aisheng authored
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:
-
Dong Aisheng authored
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:
-
Dong Aisheng authored
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:
-
Dong Aisheng authored
It helps for platform code to use it send tuning commands. Signed-off-by:
-
Dong Aisheng authored
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:
-
Axel Lin authored
This avoid duplicated implementation. Signed-off-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
Axel Lin authored
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:
-
Sachin Kamat authored
'dw_mci_socfpga_probe' is used only in this file. Make it static. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Acked-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Sachin Kamat authored
'dw_mci_socfpga_match' is always compiled in. Hence of_match_ptr is not necessary. Signed-off-by:
-
Sachin Kamat authored
devm_request_and_ioremap() is deprecated. Use devm_ioremap_resource() instead. Signed-off-by:
-
Jackey Shen authored
Clean up the duplicate macros: mmc_sd_card_uhs -> mmc_card_uhs mmc_sd_card_set_uhs -> mmc_card_set_uhs Signed-off-by:
Jackey Shen <jackey.shen@amd.com> Signed-off-by:
-
Rodolfo Giometti authored
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:
Rodolfo Giometti <giometti@enneenne.com> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Ludovic Desroches authored
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:
Alexander Morozov <etesial@gmail.com> Acked-by:
-
Seungwon Jeon authored
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:
Seungwon Jeon <tgih.jun@samsung.com> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Seungwon Jeon authored
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:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Acked-by:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
'supports-highspeed' is not one of the quirks but is a capability. So, it's removed from quirks. Signed-off-by:
-
Seungwon Jeon authored
As host controller can support eMMC's HS200 mode at 1.8V or 1.2V, these capability will be added. Signed-off-by:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Seungwon Jeon authored
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:
-
Yuvaraj Kumar C D authored
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:
Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> Signed-off-by:
-
Yuvaraj Kumar C D authored
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:
-
Yuvaraj Kumar C D authored
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:
-
Yuvaraj Kumar C D authored
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:
-
Doug Anderson authored
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:
Tomasz Figa <t.figa@samsung.com> Signed-off-by:
-
Doug Anderson authored
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:
-
Doug Anderson authored
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:
-
