This reverts commit 3500ed90.

The reverted patch caused a significant performance regression when
booting with the root file system on eMMC.

Before the patch:

[    1.625623] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.

After the patch:

[    1.935851] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.

That was an addition of 310 ms which is a 19% performance degradation.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.

VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not support reading read-only switch. assuming write-enable.
1f00             256 mtdblock0  (driver?)
1f01             256 mtdblock1  (driver?)
1f02            2560 mtdblock2 mmc0: new SDHC card at address b368
 (driver?)
1f03           29696 mtdblock3  (driver?)
1f04           16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
 (driver?)
 mmcblk0: p1
b300         3910656 mmcblk0  driver: mmcblk
  b301         3906560 mmcblk0p1 00000000-01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Signed-off-by: NSergey Yanovich <ynvich@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Function _mmc_detect_card_removed will be called to know whether
the card is still present when host->bus_ops->detect is called.
In current code, the return value of this function generally only
depend on the result of sending cmd13 to card, which may not safe
for card with detection support like slot gpio detection.
Because the communication status between host and card may out of
sync with the detect status if remove the card slowly or hands shake
during the process. The direct reason is the async between card
detect switch and card/slot pad contaction in hardware, which is
defined by spec.

The spec define card insert/remove sequence as below (both standard size
SD card and MicroSD card have the same sequence):
"Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final,
Appendix C: Card Detection Switch" (Take normally open type as example)
a)SD card insertion sequence:
  The card detection switch should be turned on after all SD card
  contact pads are connected to the host connector contact pads.
b)SD removal sequence:
  The card detection switch should be turned off when the SD card
  is just going to be removed and before any SD card contact pad is
  disconnected from the host connector contact pad.

Below is the sequence when this issue occur (Take slot gpio detection
as example and remove the card slowly during the process):
1. gpio level changed and card detect interrupt triggered.
2. mmc_rescan was launched.
3. the card pads were still contacted with the slot pads because of slow
   removal. So _mmc_detect_card_removed and mmc_rescan think card was
   still present (cmd13 succeed).
4. card pads were discontacted from the card slot pads.
So the card was actually removed finally but the card removal event
has been missed by system.
The interval length between step 1 and step 4 depends on the
card removal speed. If it's longer than the detect work schedule
delay which is 200ms, this issue will likely happen.

This patch add the card detect status check in function
_mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd
provided. If get_cd detect no card present then schedule another detect
work 200ms later.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Tested-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_regulator_set_ocr() depends on the ability of regulator to change the
voltage value. When regulator cannot change its voltage output, some code
is skipped to avoid reporting false errors on some boards, which use MMC
hosts with fixed regulators (e.g. Samsung Goni and UniversalC210 boards).

This patch replaces a hacky workaround based on regulator_count_voltages()
value with the correct call to recently introduced
regulator_can_change_voltage() function in regulators core.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes incorrect indentation.  (Just code cleanup)
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch is derived from:
"mmc: fix async request mechanism for sequential read scenarios".

According as async transfer, a request is handled with twice mmc_start_req.
When the card is removed, the request is actually not issued in the first
mmc_start_req [__mmc_start_data_req]. And then mmc_wait_for_data_req_done
will come in the next mmc_start_req. But there is no event for completions.
wake_up_interruptible is needed in __mmc_start_data_req for the case of
removed card.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

When switching SD and SDIO cards from 3.3V to 1.8V signal levels, the
clock should be gated for 5 ms during the step. After enabling the
clock, the host should wait for at least 1 ms before checking for
failure. Failure by the card to switch is indicated by dat[0:3] being
pulled low. The host should check for this condition and power-cycle
the card if failure is indicated.

Add a retry mechanism for the SDIO case.

If the voltage switch fails repeatedly, give up and continue the
initialization using the original voltage.

This patch places a couple of requirements on the host driver:

 1) mmc_set_ios with ios.clock = 0 must gate the clock
 2) mmc_power_off must actually cut the power to the card
 3) The card_busy host_ops member must be implemented

if these requirements are not fulfilled, the 1.8V signal voltage switch
will still be attempted but may not be successful.
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NWei WANG <wei_wang@realsil.com.cn>
Signed-off-by: NChris Ball <cjb@laptop.org>

Allow callers to access the start_signal_voltage_switch host_ops
member without going through any cmd11 logic. This is mostly a
preparation for the following signal voltage switch patch.

Also, reset ios.signal_voltage to its original value if
start_signal_voltage_switch fails.
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NWei WANG <wei_wang@realsil.com.cn>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add mmc_power_cycle which can be used to power cycle for instance
SD-cards.
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NWei WANG <wei_wang@realsil.com.cn>
Signed-off-by: NChris Ball <cjb@laptop.org>

Cache control is an eMMC feature and in therefore should be
part of MMC's bus resume operations, performed in mmc_suspend,
rather than in the generic mmc_suspend_host().
Signed-off-by: NMaya Erez <merez@codeaurora.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.
Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.
Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Provide support for automatically sending Set Block Count
(CMD23) messages. Used at least for RPMB support.
Signed-off-by: NAlex Macro <alex.macro@stericsson.com>
Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are infinite loops in the mmc code that can be caused by bad
hardware.  The code will loop forever if the device never comes back
from program mode, R1_STATE_PRG, and it is not ready for data,
R1_READY_FOR_DATA.

A long timeout is added to prevent the code from looping forever.
The timeout will occur if the device never comes back from program
state or the device never becomes ready for data.

It's not clear whether the timeout will do more than log a pr_err()
and then start a fresh hang all over again.  We may need to extend
this patch later to perform some kind of reset of the device (is
that possible?) or rejection of new I/O to the device.
Signed-off-by: NTrey Ramsay <tramsay@linux.vnet.ibm.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes up the broken suspend sequence for eMMC with sleep
support. Additionally it reworks the eMMC4.5 Power Off Notification
feature so it fits together with the existing sleep feature.

The CMD0 based re-initialization of the eMMC at resume is re-introduced
to maintain compatiblity for devices using sleep.

A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off
Notification feature. We might be able to remove this cap later on,
if we think that Power Off Notification always is preferred over
sleep, even if the host is not able to cut the eMMC VCCQ power.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSaugata Das <saugata.das@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Before this patch, we were using MMC_CAP2_BROKEN_VOLTAGE as a way to
avoid calling regulator_set_voltage() on a fixed regulator, but that's
just duplicating information that already exists -- we should test
whether the regulator is fixed directly, instead of via a capability.

This patch implements that test.  We can't reclaim the capability bit
just yet, since there are still boards in arch/arm/ that reference it;
those references can be removed now.
Reported-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Enable eMMC background operations (BKOPS) feature.

If URGENT_BKOPS is set after a response, note that BKOPS are required.
Immediately run BKOPS if required.  Read/write operations should be
requested during BKOPS(LEVEL-1), then issue HPI to interrupt the
ongoing BKOPS and service the foreground operation.
(This patch only controls the LEVEL2/3.)

When repeating the writing 1GB data, at a certain time, performance is
decreased.  At that time, card triggers the Level-3 or Level-2.  After
running bkops, performance is recovered.

Future considerations:
 * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
 * Interrupt ongoing BKOPS before powering off the card.
 * How do we get BKOPS_STATUS value (periodically send ext_csd command)?
 * If using periodic bkops, also consider runtime_pm control.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: NMaya Erez <merez@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

If MMC_CAP_NONREMOVABLE is set, only issue a detect job on init.
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

HPI can be issued only in programming state to bring the card to
transfer state. If the card is already in transfer state, doing
a HPI is redundant.
Fix this by adding transfer state to the list of exceptions to
doing HPI and return without error.
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in
mmc_power_up so that we do not need to touch signal voltage setting in
mmc/sd/sdio init functions and rescan function.

For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will lose its power and when powered on again, we
will set signal voltage to 3.3v in mmc_power_up before its resume function
gets called, which will re-init the card.

And for sdio cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will either lose its power or not depending on if it
wants to wakeup the host. If power is not maintained, it is the same case as
mmc/sd cards. If power is maintained, mmc_power_up will not be called and
the card's signal voltage will remain at the last setting.
Signed-off-by: NAaron Lu <aaron.lu@amd.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Currently mmc host drivers have to decide whether to enable card
detection before calling mmc_add_host() -- in which case a card
insertion event can arrive before the host has been completely
initialised -- or after mmc_add_host(), in which case the initial
card detection can be problematic.

This patch adds an explicit indication of when card detection should
not be carried out. With it in place enabling card detection before
calling mmc_add_host() should be safe. Similarly, disabling it again
after calling mmc_remove_host() will avoid any races.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add a function to get regulators, supplying card's Vdd and Vccq on a
specific host. If a Vdd supplying regulator is found, the function checks,
whether a valid OCR mask can be obtained from it. The Vccq regulator is
optional. A failure to get it is not fatal.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviwed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The regulator API functions we're wrapping are exported as GPL, so our
wrappers for the same functions should be too.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_execute_hpi should send the HPI command only once, and only
if the card is in PRG state.

According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which
is defined to begin at the end of sending the command itself.

Specify the default timeout for the actual sending of HPI
command, and then use OUT_OF_INTERRUPT_TIME to wait for
the transition out of PRG state.
Reported-by: NAlex Lemberg <Alex.Lemberg@sandisk.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Reviewed-by: NSubhash Jadavani <subhashj@codeaurora.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For eMMC cards that has been initialized from a bootloader,
the VCC voltage supply must not be cut in an uncontrolled
manner, without first sending SLEEP or POWEROFF_NOTIFY.

The regulator_init_complete late initcall, may cut the VCC
regulator if it's reference counter is zero. To be able to
prevent the regulator from being cut, mmc_start_host, which
should execute at device init and thus before late init,
calls mmc_power_up. Then the host driver is able to increase
the reference to the regulator.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Since SDIO drivers may want to do some SDIO operations in their suspend
callback functions, we must not keep the host claimed when calling them.

Daniel Drake reported that libertas_sdio encountered a deadlock in its
suspend function.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Tested-by: NDaniel Drake <dsd@laptop.org>
[stable@: please apply to 3.2-stable and 3.3-stable]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

eMMC v4.5 sanitize operation erases all copies of unmapped
data.  However trim or erase operations must be used first
to unmap the required sectors.  That was not being done.

Fixes apply to linux 3.2 on.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

eMMC v4.5 discard operation is significantly different from the
existing trim operation because it is not guaranteed to work with
the new sanitize operation.  Consequently mmc_can_trim() is
separated from mmc_can_discard().

Also the new discard operation does not result in the sectors being
set to all-zeros, so discard_zeroes_data must not be set.

In addition, the new discard has the same timeout as trim, but from
v4.5 trim is defined to use the hc timeout.  The timeout calculation
is adjusted accordingly.

Fixes apply to linux 3.2 on.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Several people have noticed that crappy SD cards take much longer to
complete multiple block writes than the 300ms that Linux specifies.
Try to work around this by using a three second write timeout instead.

This is a generalized version of a patch from Chase Maupin
<Chase.Maupin@ti.com>, whose patch description said:

* With certain SD cards timeouts like the following have been seen
  due to an improper calculation of the dto value:
    mmcblk0: error -110 transferring data, sector 4126233, nr 8,
    card status 0xc00
* By removing the dto calculation and setting the timeout value
  to the maximum specified by the SD card specification part A2
  section 2.2.15 these timeouts can be avoided.
* This change has been used by beagleboard users as well as the
  Texas Instruments SDK without a negative impact.
* There are multiple discussion threads about this but the most
  relevant ones are:
    * http://talk.maemo.org/showthread.php?p=1000707#post1000707
    * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
* Original proposal for this fix was done by Sukumar Ghoral of
  Texas Instruments
* Tested using a Texas Instruments AM335x EVM
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Make sure mmc_start_req cancels the prepared job, if the request
was prevented to be started due to the card has been removed.

This bug was introduced in commit:
mmc: allow upper layers to know immediately if card has been removed
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NPer Forlin <per.forlin@stericsson.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Most parts of the enable / disable API are no longer used and
can be removed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

To prevent I/O as soon as possible at card removal, a new detect work is
re-scheduled without a delay to let a rescan remove the card device as
soon as possible.

Additionally, MMC_CAP2_DETECT_ON_ERR can now be used to handle "slowly"
removed cards that a scheduled detect work did not detect as removed.
To prevent further I/O requests for these lingering removed cards,
check if card has been removed and then schedule a detect work to
properly remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch is added just debug message.  Almost features need to use the
CMD23.  But we didn't see the debug message for sbc.  If sbc's message
can see, should be help for debugging.  (We can check whether use the
cmd23 or not.)
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Even if cards supports 1.8V I/O voltage those should anyway be
initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
Some eMMC and embedded SDIO devices are able to be initialized
at 1.8V as well, but it is better to be safe.

Do note that initialization in this context means that the card
has been completely powered off, otherwise the card will remain
at the last I/O voltage level that were negotitiated.

Due to the above being taken care of the suspend/resume issues
for UHS-I SD-cards has been fixed.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Acked-by: NPhilip Rakity <prakity@marvell.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NSubhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Modified the mmc_poweroff to resume before sending the poweroff
notification command. In sleep mode only AWAKE and RESET commands are
allowed, so before sending the poweroff notification command resume from
sleep mode and then send the notification command.

PowerOff Notify is tested on a Synopsis Designware Host Controller
(eMMC 4.5). The suspend to RAM and resume works fine.
Signed-off-by: NGirish K S <girish.shivananjappa@linaro.org>
Tested-by: NGirish K S <girish.shivananjappa@linaro.org>
Reviewed-by: NSaugata Das <saugata.das@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

There is an understood mismatch between the voltage the host controller is
set to and the voltage supplied to the card by a fixed voltage regulator.
Teaching the driver to accept the mismatch is overly complicated.  Instead
just accept the regulator's voltage.

This patch adds MMC_CAP2_BROKEN_VOLTAGE.

If the voltage didn't satisfy between min_uV and max_uV, try to change
the voltage in core.c.  When changing the voltage, maybe use
regulator_set_voltage().

In regulator_set_voltage(), check the below condition.

	/* sanity check */
	if (!rdev->desc->ops->set_voltage &&
	    !rdev->desc->ops->set_voltage_sel) {
		ret = -EINVAL;
		goto out;
	}

If some board should use the fixed-regulator, always return -EINVAL.
Then, eMMC didn't initialize always.

So if use a fixed-regulator, we need to add the MMC_CAP2_BROKEN_VOLTAGE.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Ensure clocks are always enabled before any interaction with the
host controller driver. This makes sure that there is no race
between host execution and the core layer turning off clocks
in different context with clock gating framework.
Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NPer Forlin <per.forlin@stericsson.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Performing MMC block IO with simultaneous STR can lead to a deadlock: the
mmc_pm_notify() function claims the host and then calls bus .remove()
method, which lands in mmc_blk_remove(), which calls mmc_blk_remove_req()
then it goes to -> mmc_cleanup_queue() -> kthread_stop(), which waits for
the mmc-block thread to stop. If the mmc-block thread at that time is
processing block requests, it will also try to claim the host in
mmc_blk_issue_rq() and block there. This patch fixes the problem by
calling .remove() before claiming the host.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NArindam Nath <arindam.nath@amd.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Turning the cache off implies flushing cache which doesn't define
maximum timeout unlike cache-on. This patch will apply the generic
CMD6 timeout only for cache-on. Additionally the kernel message is
added for checking failure case of cache-on.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>