The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
by things like wrong dma settings in the system.
Till now the code dw_mci_init_slot() always assumed that dma is available
when CONFIG_MMC_DW_IDMAC was defined, ignoring the host->use_dma var
set during dma init.
So when now the dma init failed for whatever reason, the transfer sizes
would still be set for dma transfers, especially including the maximum
block-count calculated from host->ring_size and resulting in a
[ 4.991109] ------------[ cut here ]------------
[ 4.991111] kernel BUG at drivers/mmc/core/core.c:256!
[ 4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM
because host->ring_size is 0 in this case and the slot init code uses
the wrong code to calculate the values.
Fix this by selecting the correct calculations using the host->use_dma
variable instead of the CONFIG_MMC_DW_IDMAC config option.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
This patch fixes the following issues reported by checkpatch.pl:
- use -EINVAL instead of -ENOSYS, to fix warning message:
"ENOSYS means 'invalid syscall nr' and nothing else"
- split lines whose length is greater than 80 characters
- avoid quoted string split across lines
- use min_t instead of min, to fix warning message:
"min() should probably be min_t(int, cnt, host->part_buf_count)"
- fix missing a blank line after declarations
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
As per DW MobileStorage databook "each descriptor can transfer up to 4kB
of data in chained mode", moreover buffer size that is put in "des1" is
limited to 13 bits, i.e. for example on attempt to
IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written
will be 0.
On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in
SG-list of 8kB size and that leads to unpredictable behavior of the
SD/MMC controller.
In particular on write to FAT partition of SD-card the controller will
stuck in the middle of DMA transaction.
Solution to the problem is simple - we need to pass large (> 4kB) data
buffers to the controller via multiple descriptors. And that's what
that change does.
What's interesting I did try original driver on same platform but
configured with 4kB PAGE_SIZE and may confirm that data blocks passed
in SG-list to dw_mmc never exeed 4kB limit - that explains why nobody
ever faced a problem I did.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Seungwon Jeon <tgih.jun@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: arc-linux-dev@synopsys.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Remove module of dw_mmc driver will hung for eMMC devices if we follow the
steps which are listed below,
insmod dw_mmc.ko
insmod dw_mmc-pci.ko
rmmod dw_mmc-pci.ko
The root cause for this issue is, dw_mci_remove() will disable all the
interrupts by programming 0x0 to INTMASK register then it will call
dw_mci_cleanup_slot(). But dw_mci_cleanup_slot() is issuing CMD6 to
disable the eMMC boot partition and it is waiting for Command Complete
interrupt. Since INTMASK was already cleared by dw_mci_remove(), Command
Complete interrupt is not reaching the system. This leads to process hung.
Signed-off-by: Prabu Thangamuthu <prabu.t@synopsys.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use the new MMC_CAP2_NO_WRITE_PROTECT to let the core handle the case where
no write protect line is present instead of having custom driver code to
handle it.
dw_mci_of_get_slot_quirks() is slightly refactored to directly modify the
mmc_host capabilities instead of returning a quirk mask.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
switch_voltage is required on some platform since special register accessing
Signed-off-by: Jorge A. Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Dan Yuan <yuandan@hisilicon.com>
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When non-removable is used for emmc, MMC_CAP_NONREMOVABLE should
also be checked, otherwise detection fail since present=0
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Set 0 to des1 in 32bit case.
Otherwise the random value of des1 will be used in
dw_mci_translate_sglist: IDMAC_SET_BUFFER1_SIZE(desc, length)
Signed-off-by: Fei Wang <w.f@huawei.com>
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It is possible for the cmd11 interrupt to fire and delete the
cmd11_timer before the cmd11_timer was actually setup. Let's fix this
race by adding a few spinlocks. Note that the race wasn't seen in
practice without adding some printk statements, but it still seems
wise to fix.
Fixes: 5c935165da ("mmc: dw_mmc: Add a timeout for sending CMD11")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If we get an unexpected cmd11 timeout we shouldn't actually treat it
as a timeout (not that we really expect to get an unexpected cmd11
timeout, but still).
Fixes: 5c935165da ("mmc: dw_mmc: Add a timeout for sending CMD11")
Reported-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Although the cmd11 interrupt should come within 2ms, that's a very
short time. Let's increase the timeout to be really sure that we
don't get an accidnetal timeout. One case in particular this is
useful is if you've got a serial console and printk in just the right
places. Under that scenario I've seen delays of up to 130ms before
the interrupt fired.
CMD11 is only sent during card insertion, so this extra timeout
shouldn't be terrible.
Fixes: 5c935165da ("mmc: dw_mmc: Add a timeout for sending CMD11")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The dw_mmc driver changes to make the IO accesors endian agnostic did not
take into account the fifo accesses do not need to be swapped. To fix this
add a mmci_fifo_read/write wrapper to allow these to be passed through the
IO without being swapped.
Since these are now specific functions, it would be easier just to store
the pointer to the fifo registers in the host block instead of the offset
to them. So change the host->data_offset to host->fifo_reg (which also
means we catch all the places this is read or written).
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The dw_mmc driver does not take into account the processor may be in
big endian when writing the descriptors. Change the descriptors for
the 32bit IDMA to use __le32 and ensure they are suitably swapped
before writing.
Note, this has not been tested as the socfpga driver does not try to
use idma.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If dw_mci_init_slot() returns that we got a probe deferral then it may
leave slot->mmc as NULL. That will cause dw_mci_enable_cd() to crash
when it calls mmc_gpio_get_cd().
Fix this by moving the call of dw_mci_enable_cd() until we're sure
that we're good. Note that if we have more than one slot and one
defers (but the others don't) things won't work so well. ...but
that's not a new thing and everyone has already agreed that multislot
support ought to be removed from dw_mmc eventually anyway since it is
unused, untested, and you can see several bugs like this by inspecting
the code.
Fixes: bcafaf5470f0 ("mmc: dw_mmc: Only enable CD after setup and only if needed")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the Designware databook's description of the "Voltage Switch Normal
Scenario" it instructs us to set a timer and fail the voltage change
if we don't see the voltage change interrupt within 2ms. Let's
implement that. Without implementing this I have often been able to
reproduce a hang while trying to send CMD11 on an rk3288-based board
while constantly ejecting and inserting UHS cards.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It's unlikely that this is really needed on any single-slot systems
where we disable card detects until the end of probe, but it still
seems safer to check to make sure that a slot has been initted before
we try to dereference it to find the SDIO interrupt mask.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We really don't want to get a card detect interrupt during probe time
since it can confuse things. Let's disable the card detect interrupt
until we're in a really good place: the end of probe. Let's also
simply avoid enabling the card detect interrupt if it's not used.
It appears that (at least on rk3288) when vqmmc is turned on it can
cause a bogus "card detect" interrupt. That meant that we were
getting a predictable card detect interrupt while we were in
mmc_add_host(). On the version of the kernel I'm working with at
least (3.14), this is not a great time to get a card detect interrupt
since I think that we don't grab all the needed locks in
mmc_add_host() and children. I put stack dumps in dw_mci_setup_bus()
and found that I could see two distinct stack crawls that looked like:
Caller one:
* dw_mci_setup_bus
* dw_mci_set_ios
* mmc_power_up
* mmc_start_host
* mmc_add_host
Caller two:
* dw_mci_setup_bus
* dw_mci_set_ios
* mmc_set_chip_select
* mmc_go_idle
* mmc_rescan
* process_one_work
* worker_thread
* kthread
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We've seen problems on some WiFi modules where we seem to send a CMD53
(which requires the data lines) while the module is asserting busy.
We shouldn't do that.
The Designware Databook says that before issuing a new data transfer
command we should check for busy, so that's what we'll do.
We'll leverage the existing dw_mmc knowledge about whether it should
wait for the previous command to finish to know whether we should
check for busy before sending the command. This means we won't end up
incorrectly waiting for things like CMD52 (SDIO) or CMD13 (SD) which
don't use the data line.
Note that this also has the advantage of making sure that we don't
change the clock while the card is busy, too.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We should give dw_mmc a good reset after we apply power. On some
boards vqmmc may actually be connected to the IP block in the SoC so
it's good to reset after power comes in.
Without this we sometimes see failures enumerating cards on rk3288.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It appears that we can confuse things if we try to turn on the MMC
clock when the power is off. Adjust is so that we turn the clock on
(using dw_mci_setup_bus) after power is all the way on and we turn the
clock off before the power goes off.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The STOP command can terminate a data transfer between a memory card and
mmc controller.
As show in Synopsys DesignWare Cores Mobile Storage Host Databook:
Data timeout and Data end-bit error will terminate further data transfer
by mmc controller. So we should not send abort command to terminate a
data transfer again if we got DRTO and EBE interrupt.
After this patch, all mmc_test cases can pass on RK3288-Pink2 board.
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Implements HS400 mode support for exynos host driver.
This also include some updates as new mode is added.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
[Alim: addressed review comments]
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If we power up vqmmc in MMC_POWER_ON then we end up turning it on
before mmc_power_up() sets the signal voltage. That's not so great
since we might be powering it up at the wrong voltage.
Note that this is how Yuvaraj originally coded things up in
<https://patchwork.kernel.org/patch/4401231/> but he changed it on my
suggestion. Apparently I was wrong.
Reported-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Instead of having a local hack taking care of sending the tuning
command and as well to verify the response pattern, let's convert to
the common mmc_send_tuning() API.
This change affects the Exynos variant, since it's the only one which
support the dw_mmc's ->execute_tuning() callback.
It's seems like dw_mmc internal logic expects failed data transfers to
be ended using a stop command. Let the tuning requests also fall into
this category, since there are data transfer involved.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Even though 1MB is reserved for descriptor table in IDMAC,
the dw_mmc host driver is allowed to receive only maximum
128KB block length in one request. This is caused by setting
improper max_blk_count. It needs to be e adjusted so that
descriptor table is used fully. It is found that the performance
is improved with the increased the max_blk_count.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We're running into cases where our enabling of the SDIO interrupt in
dw_mmc doesn't actually take effect. Specifically, adding patch like
this:
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1076,6 +1076,9 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
mci_writel(host, INTMASK,
(int_mask | SDMMC_INT_SDIO(slot->id)));
+ int_mask = mci_readl(host, INTMASK);
+ if (!(int_mask & SDMMC_INT_SDIO(slot->id)))
+ dev_err(&mmc->class_dev, "failed to enable sdio irq\n");
} else {
...actually triggers the error message. That's because the
dw_mci_enable_sdio_irq() unsafely does a read-modify-write of the
INTMASK register.
We can't just use the standard host->lock since that lock is not irq
safe and mmc_signal_sdio_irq() (called from interrupt context) calls
dw_mci_enable_sdio_irq(). Add a new irq-safe lock to protect INTMASK.
An alternate solution to this is to punt mmc_signal_sdio_irq() to the
tasklet and then protect INTMASK modifications by the standard host
lock. This seemed like a bit more of a high-latency change.
Reported-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the patch (9623b5b mmc: dw_mmc: Disable low power mode if SDIO
interrupts are used) I added code that disabled the low power mode of
dw_mmc when SDIO interrupts are used. That code worked but always
felt a little hacky because we ended up disabling low power as a side
effect of the first enable_sdio_irq() call. That wouldn't be so bad
except that disabling low power involves a complicated process of
writing to the CMD/CMDARG registers and that extra process makes it
difficult to cleanly the read-modify-write race in
dw_mci_enable_sdio_irq() (see future patch in the series).
Change the code to take advantage of the init_card() callback of the
mmc core to do this right at bootup.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit f1d2736c81 (mmc: dw_mmc: control card read threshold) added
dw_mci_ctrl_rd_thld() with an unconditional write to the CDTHRCTL
register at offset 0x100. However before version 240a, the FIFO region
started at 0x100, so the write messes with the FIFO and completely
breaks the driver.
If the version id < 240A, return early from dw_mci_ctl_rd_thld() so as
not to hit this problem.
Fixes: f1d2736c81 (mmc: dw_mmc: control card read threshold)
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: <stable@vger.kernel.org> # v3.13+
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Synopsys DW_MMC IP core supports Internal DMA Controller with 64-bit address mode from IP version 2.70a onwards.
Updated the driver to support IDMAC 64-bit addressing mode.
Signed-off-by: Prabu Thangamuthu <prabu.t@synopsys.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The dw_mmc driver had a bunch of code that ran whenever a card was
ejected and inserted. However, this code was old and crufty and
should be removed. Some evidence that it's really not needed:
1. Is is supposed to be legal to use 'cd-gpio' on dw_mmc instead of
using the built-in card detect mechanism. The 'cd-gpio' code
doesn't run any of the crufty old code but yet still works.
2. While looking at this, I realized that my old change (369ac86 mmc:
dw_mmc: don't queue up a card detect at slot startup) actually
castrated the old code a little bit already and nobody noticed.
Specifically "last_detect_state" was left as 0 at bootup. That
means that on the first card removal none of the crufty code ran.
3. I can run "while true; do dd if=/dev/mmcblk1 of=/dev/null; done"
while ejecting and inserting an SD Card and the world doesn't
explode.
If some of the crufty old code is actually needed, we should justify
it and also put it in some place where it will be run even with
"cd-gpio".
Note that in my case I'm using the "cd-gpio" mechanism but for various
reasons the hardware triggers a dw_mmc "card detect" at bootup. That
was actually causing a real bug. The card detect workqueue was
running while the system was trying to enumerate the card. The
"present != slot->last_detect_state" triggered and we were doing all
kinds of crazy stuff and messing up enumeration. The new mechanism of
just asking the core to check the card is much safer and then the
bogus interrupt doesn't hurt.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: alim.akhtar <alim.akhtar@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In (28f92b5 mmc: core: Try other signal levels during power up) we can
see that there are times when it's valid to try several signal
voltages. Don't print an ugly error in the logs when that happens.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We've already got a reset of DMA after it's done. Add one before we
start DMA too. This fixes a data corruption on Rockchip SoCs which
will get bad data when doing a DMA transfer after doing a PIO transfer.
We tested this on an Exynos 5800 with HS200 and didn't notice any
difference in sequential read throughput.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The same tuning block exists in the dw_mmc h.c and sdhci-msm.c
files. Move these into mmc.c so that they can be shared across
drivers.
Reported-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
dw_mci_of_find_slot_node() is only used in dw_mci_of_get_slot_quirks()
if CONFIG_OF is defined, thus there is no need to have a !CONFIG_OF
version of it. Fixes the following compile warning with !CONFIG_OF:
CC [M] drivers/mmc/host/dw_mmc.o
drivers/mmc/host/dw_mmc.c:2223:28: warning: ‘dw_mci_of_find_slot_node’ defined but not used [-Wunused-function]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It's possible that mmc_of_parse() could return errors (possibly in
some future version it might return -EPROBE_DEFER even). Let's pass
those errors back.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For UHS cards we need the ability to switch voltages from 3.3V to
1.8V. Add support to the dw_mmc driver to handle this. Note that
dw_mmc needs a little bit of extra code since the interface needs a
special bit programmed to the CMD register while CMD11 is progressing.
This means adding a few extra states to the state machine to track.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If we happened to get a data error at just the wrong time the dw_mmc
driver could get into a state where it would never complete its
request. That would leave the caller just hanging there.
We fix this two ways and both of the two fixes on their own appear to
fix the problems we've seen:
1. Fix a race in the tasklet where the interrupt setting the data
error happens _just after_ we check for it, then we get a
EVENT_XFER_COMPLETE. We fix this by repeating a bit of code.
2. Fix it so that if we detect that we've got an error in the "data
busy" state and we're not going to do anything else we end the
request and unblock anyone waiting.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@gmail.com>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch changes the fifo reset code to follow the reset procedure
outlined in the documentation of Synopsys Mobile storage host databook.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
[sonnyrao: fix compile for !CONFIG_MMC_DW_IDMAC case]
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Data errors are completely expected during tuning. Printing them out
is confusing people looking at the kernel logs. They see things like:
[ 3.613296] dwmmc_exynos 12200000.dwmmc0: data error, status 0x00000088
...and they think something is wrong with their hardware.
Remove the printouts. We'll leave it up to a higher level to report
about errors.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Restore the card-present checking point.
(The following part was removed from commit bf626e5 ("mmc: dw_mmc:
use slot-gpio to handle cd pin")
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Since using the device-tree, didn't use the callback pointer.
So removed the unused callback pointer.
When the set_power callback is used, it should be added in future.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
