mmc: sdhci-msm: configure regulators only if defined in dts

This patch adds support to configure regulators only if
it is defined in dts files. However, it doesn't return an
error otherwise.

Change-Id: Iac2284b2df3b3d8af623da0f17697694994b34b8
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: msm_sdcc: Fix compilation issues

Fix compilation issues when CONFIG_DEBUG_FS is not defined.

CRs-fixed: 555000
Change-Id: Ic7f30ae79450fa9125499352b80db3fa4c27104d
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci: fix incorrect command used in tuning

For SD hosts using retuning mode 1, when retuning timer expired, it will
need to do retuning in sdhci_request before processing the actual
request. But the retuning command is fixed: cmd19 for SD card and cmd21
for eMMC card, so we can't use the original request's command to do the
tuning.

And since the tuning command depends on the card type attached to the
host, we will need to know the card type to use the correct tuning
command.

Change-Id: Ibde71d8a8b4e0ff75456923c7c3d8579c04109b4
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Cc: stable <stable@vger.kernel.org> [3.3+]
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci: fix NULL dereference in sdhci_request() tuning

Commit 473b095a72a9 ("mmc: sdhci: fix incorrect command used in tuning")
introduced a NULL dereference at resume-time if an SD 3.0 host controller
raises the SDHCI_NEEDS_TUNING flag while no card is inserted.  Seen on an
OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.

Change-Id: I14a9e2a4566ed9f6d4186d6f63ed2e192485973d
Signed-off-by: Chris Ball <cjb@laptop.org>
Cc: stable <stable@vger.kernel.org> [3.3+]
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci: retune on cmd or data CRC error

Initiate a DLL (delay locked loop) retune for the next command,
if the current command fails with a CRC error.
This may help to choose a different phase (delay) if the same
has changed over the elapsed period of time.

CRs-Fixed: 587985
Change-Id: I21f6a5dadb096dd38d41fcf2251fa50b03c8bbb4
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: increase data-timeout value for Hynix cards

Add a quirk to increase the data-timeout value for Hynix eMMC
cards only. This value is fixed to a maximum of 4 seconds.

Change-Id: I4bca6cbc877b323b29a3f7f5923d0708c48adf2c
CRs-fixed: 587284
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci: do not use maximum timeout for all cards

Remove maximum timeout for all cards, since this causes
a long resume time for SD cards. Now only Hynix cards would
have this maximum timeout and this would be decided at the core
layer.

Change-Id: I758f9e5ecf407aba371928a86c313cf69e3cda63
CRs-fixed: 587284
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: do not reinsert prepeared FUA and FLUSH requests in stop flow

When mmc context has unblocked from waiting current request because of
urgent request notification coming from block layer, there is prepeared
request.  In the case, when the request is REQ_FUA or REQ_FLUSH, the
flow should not reinsert it back to i/o scheduler (since according to
block layer logic flush requests with data should never enter elevator).
Instead this request starts immediately.

Change-Id: Ia78b56c6135dd1a8d75a98fd5b771a5035e5c360
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: Hold host resume status while card rescan is in progress

In case if a removable card is hot-plugged when the card and host
are runtime suspended then the mmc_rescan() tries to detect the card
status and removes the bus_ops. During card removal the Linux device
model calls pm_runtime_remove() of the corresponding "card" device,
which not only marks the device as suspended but also notifies the
parent so that it can be suspended if there are no children that are
holding resume. In case if the runtime suspend work of host is scheduled
before bus_ops are marked NULL in mmc_rescan(), the runtime suspend
of host fails with -ENOMEDIUM error. This error makes runtime PM framework
to permanently mark the host device in error and further runtime PM
operations are disallowed even when the card is re-inserted.

CRs-Fixed: 593475
Change-Id: Ie5e09f05ef26098c561b0c64b3954962d9d4c039
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: block: stop bkops during shutdown

[   42.885198] SysRq : Emergency Remount R/O
[   43.003988] mmc0: mmc_bus_shutdown: invoked ###
[   43.033289] mmc0: mmc_bus_shutdown: done ###
[   43.118486] mmc0: sdhci_request: sending cmd8 after bus shutdown !!!
[   43.147955] [<c0659ca4>] (sdhci_request+0x4c/0x260) from
				[<c063ee24>] (mmc_start_request+0x27c/0x2b0)
[   43.157152] [<c063ee24>] (mmc_start_request+0x27c/0x2b0) from
				[<c063eec4>] (mmc_wait_for_req+0x6c/0x13c)
[   43.166618] [<c063eec4>] (mmc_wait_for_req+0x6c/0x13c) from
				[<c0645ed4>] (mmc_send_cxd_data+0xe0/0x114)
[   43.175991] [<c0645ed4>] (mmc_send_cxd_data+0xe0/0x114) from
				[<c0645f24>] (mmc_send_ext_csd+0x1c/0x20)
[   43.185277] [<c0645f24>] (mmc_send_ext_csd+0x1c/0x20) from
				[<c063df28>] (mmc_read_bkops_status+0x98/0xdc)
[   43.194823] [<c063df28>] (mmc_read_bkops_status+0x98/0xdc) from
				[<c06417ac>] (mmc_start_bkops+0x168/0x324)
[   43.204461] [<c06417ac>] (mmc_start_bkops+0x168/0x324) from
				[<c01a9584>] (process_one_work+0x200/0x400)
[   43.213835] [<c01a9584>] (process_one_work+0x200/0x400) from
				[<c01a9934>] (worker_thread+0x184/0x2a4)
[   43.223039] [<c01a9934>] (worker_thread+0x184/0x2a4) from
				[<c01ae010>] (kthread+0x80/0x90)
[   43.231286] [<c01ae010>] (kthread+0x80/0x90) from
				[<c0106c4c>] (kernel_thread_exit+0x0/0x8)
[   45.648206] wcnss crash shutdown 0
[   45.650599] Rebooting in 5 seconds..

In the above log, it is seen that the bkops thread runs after
mmc_bus_shutdown is completed and sends CMD8. Hence, cancel
bkops work during shutdown to prevent sending commands after
mmc bus is shutdown.

CRs-fixed: 593813
Change-Id: I3e8e9eb228bd03603d04561eb478d60664f50aaa
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci-msm: Fix clock gating while voltage switch is in progress

CLK_PWRSAVE bit in vendor specific register gates the output clock to
card automatically if there are no data/cmd operations.

According the SD3.0 voltage switch sequence the host should provide
clock to the card for atleast one millisecond before DAT[3:0] lines
are pulled high by the card. In this case if power save bit is enabled
it might auto-gate clocks even before the card completes voltage
switch sequence.

Fix this by disabling power save operation when the clocks are turned
off and enable only when clock rate is >400KHz i.e., end of initialization.

CRs-Fixed: 589992
Change-Id: If82d6d2e303b8d1189b76712e514f41fe6e2cf8b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: fix issue with HPI polling timeout

Out of CPU time for the MMC context included into measured timeout. System
under heavy load will easily exceed out_of_int_time (typically 20 ms),
because  the MMC context is not running and when it is back to running,
timeout already elapsed. In this case real card status checked again and
error reported for wrong card state only.

Change-Id: I0da3bd2e7d41e4933ad3b1333d7135705a1eafec
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci: fix issue with auto cmd err detection

As per specification, auto cmd error status register is valid only
when auto cmd error bit is set in Error interrupt status register.

CRs-fixed: 515513
Change-Id: Id1013e1705d8efdba0171dcad14f783607d38ef3
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: mxs-mmc: fix deadlock in SDIO IRQ case

Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler.

Backtrace:
[   79.660000] =============================================
[   79.660000] [ INFO: possible recursive locking detected ]
[   79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted
[   79.660000] ---------------------------------------------
[   79.660000] swapper/0 is trying to acquire lock:
[   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4
[   79.660000]
[   79.660000] but task is already holding lock:
[   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
[   79.660000]
[   79.660000] other info that might help us debug this:
[   79.660000]  Possible unsafe locking scenario:
[   79.660000]
[   79.660000]        CPU0
[   79.660000]        ----
[   79.660000]   lock(&(&host->lock)->rlock#2);
[   79.660000]   lock(&(&host->lock)->rlock#2);
[   79.660000]
[   79.660000]  *** DEADLOCK ***
[   79.660000]
[   79.660000]  May be due to missing lock nesting notation
[   79.660000]
[   79.660000] 1 lock held by swapper/0:
[   79.660000]  #0:  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
[   79.660000]
[   79.660000] stack backtrace:
[   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48)
[   79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8)
[   79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58)
[   79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
[   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
[   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
[   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
[   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
[   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
[   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
[   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
[   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
[   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
[   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
[   79.660000] BUG: spinlock lockup on CPU#0, swapper/0
[   79.660000]  lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
[   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144)
[   79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58)
[   79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
[   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
[   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
[   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
[   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
[   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
[   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
[   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
[   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
[   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
[   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)

Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci-esdhc: break out early if clock is 0

Since commit 30832ab56 ("mmc: sdhci: Always pass clock request value
zero to set_clock host op") was merged, esdhc_set_clock starts hitting
"if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated.  This
causes SDHCI card-detection function being broken.  Fix the regression
by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: omap_hsmmc: Pass on the suspend failure to the PM core

In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.

	ret = mmc_suspend_host(host->mmc);
	if (ret) {
		host->suspended = 0;
		if (host->pdata->resume) {
			ret = host->pdata->resume(dev, host->slot_id);

The return status from mmc_suspend_host() is overwritten by return
status from host->pdata->resume. So the original return status is lost.

In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.

To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Acked-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci-s3c: fix the wrong number of max bus clocks

We can use up to four bus-clocks; but on module remove, we didn't
disable the fourth bus clock.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sh-mmcif: avoid oops on spurious interrupts (second try)

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
interrupts without any active request. To prevent the Oops, that results
in such cases, don't dereference the mmc request pointer until we make
sure, that we are indeed processing such a request.

Reported-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci-esdhc-imx: fix host version read

commit ef4d0888bb7e1b963880f086575081c3d39cad2d upstream.

When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc
support) works around host version issue on imx6q, it gets the
register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc.
Thus, the controller version on these SoCs is wrongly identified
as v1 while it's actually v2.

Add the address fixup back and take a different approach to correct
imx6q host version, so that the host version read gets back to work
for all SoCs.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: at91/avr32/atmel-mci: fix DMA-channel leak on module unload

commit 91cf54feecf815bec0b6a8d6d9dbd0e219f2f2cc upstream.

Fix regression introduced by commit 796211b7953 ("mmc: atmel-mci: add
pdc support and runtime capabilities detection") which removed the need
for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the
compile guards around dma_release_channel() in remove(). Consequently,
DMA is always enabled (if supported), but the DMA-channel is not
released on module unload unless the DMA-config option is selected.

Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>