The host should be responsible to suspend|resume the host and not the
card. This patch changes this behaviour, by moving the responsiblity
to the mmc bus instead which already holds the card device.
The exported functions mmc_suspend|resume_host are now to be considered
as depcrecated. Once all host drivers moves away from using them, we
can remove them. As of now, a successful error code is always returned.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
By moving code from the mmc_suspend|resume_host down into each
.suspend|resume bus_ops callback, we get a more flexible solution.
Some nice side effects are that we get a better understanding of each
bus_ops suspend|resume sequence and the common code don't have to take
care of specific corner cases, especially for the SDIO case.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch moves the validation for all the suspend prerequisites to be
done at SUSPEND_PREPARE notification. Previously in the SDIO case parts
of the validation was done from mmc_suspend_host.
This patch invents a new pre_suspend bus_ops callback and implements it
for SDIO. Returning an error code from it, will mean at SUSPEND_PREPARE
notification, the card will be removed before proceeding with the
suspend sequence.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
For every bus_ops type the .remove callback always exist, thus there
are no need to check the existence of it, before we decide to call it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The mmc_card_sleep|awake APIs are not being used since the support is
already properly encapsulated within the suspend sequence. Sleep|awake
command is also specific for eMMC.
We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
move the code into the mmc specific core instead. This also includes
the mmc ops function, mmc_sleepawake. All releated functions have then
become static and we have got far less code to maintain.
Additionally this patch also simplifies the code from mmc_sleepawake,
since it is only used to put the card to sleep and not awake.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inactivity occurs for a certain time. Right now the
selected timeout value is set to 3 s. Obviously this value will likely
need to be configurable somehow since it needs to be trimmed depending
on the power save algorithm.
For SD-combo cards, we are still leaving the enablement of runtime PM
to the SDIO init sequence since it depends on the capabilities of the
SDIO func driver.
Moreover, when the blk device is being suspended, we make sure the device
will be runtime resumed. The reason for doing this is that we want the
host suspend sequence to be unaware of any runtime power save operations
done for the card in this phase. Thus it can just handle the suspend as
the card is fully powered from a runtime perspective.
Finally, this patch prepares to make it possible to move BKOPS handling
into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
accomplished.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
SDIO is the only protocol that uses runtime pm for the card device
right now. To provide the option for sd and mmc to use runtime pm as
well the bus_ops callback are extended with two new functions. One for
runtime_suspend and one for runtime_resume.
This patch will also implement the callbacks for SDIO to make sure
existing functionality is maintained. It also prepares to move
away from using the mmc_power_restore_host API, since it is not
needed when using runtime PM.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Move mmc suspend specific operations to be executed from the .suspend
callback in the mmc bus_ops. This simplifies the mmc_suspend_host
function which is supposed to handle nothing but common suspend tasks.
Since eMMC can be considered non-removable there are no need to check
for ongoing bkops at PM_SUSPEND_PREPARE notification so remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The sanitize support is added as a user-app ioctl call, and
was removed from the block-device request, since its purpose is
to be invoked not via File-System but by a user.
This feature deletes the unmap memory region of the eMMC card,
by writing to a specific register in the EXT_CSD.
unmap region is the memory region that was previously deleted
(by erase, trim or discard operation).
In order to avoid timeout when sanitizing large-scale cards,
the timeout for sanitize operation is 240 seconds.
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Previously the MMC_CAP2_DETECT_ON_ERR was invented for detecting
slow card removal. In was never a realy good solution and a proper
fix has been merged using gpio debouncing instead. We remove this
cap in this patch.
Although when using polling card detect mode, the code invented for
MMC_CAP2_DETECT_ON_ERR is re-used to complete card removal in an
earlier phase. There are no need waiting for the polling timeout to
elapse in this case.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Core:
- Introduce MMC_CAP2_NO_PRESCAN_POWERUP to allow skipping mmc_power_up()
at boot/initialization time if it's already happened, for performance
(faster boot time) reasons.
- Fix a bit width test failure that resulted in old eMMC cards being put
into 1-bit mode when 4-bit mode was available.
- Expose fwrev/hwrev for MMCv4 parts.
- Improve card removal logic in the case where the card's removed slowly;
we were missing card removal events if the card retained contact with
the slot pads for long enough to reply to a CMD13 while being removed.
Drivers:
- davinci_mmc: Support using PIO instead of DMA.
- dw_mmc: Add support for Exynos4412.
- mxcmmc: DT support, use slot-gpio API.
- mxs-mmc: Add broken-cd/cd-inverted/non-removable DT property support.
- sdhci-sirf: New sdhci-pltfm driver for CSR SiRF SoCs:
SiRFprimaII: unicore ARM Cortex-A9
SiRFatlas6: unicore ARM Cortex-A9
SiRFmarco: dual core ARM Cortex-A9 SMP
- sdhci-tegra: Add support for Tegra114 platforms, use mmc_of_parse().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJRfr+qAAoJEHNBYZ7TNxYMG90QALW6ArdTxkfNKNybCx/s3ttm
hyP2BB9eXF/FbZ9bGHGuv9NXV/4YZ4yr4c3yV4paOMW3s0z/+IhqajLfCgPFPCGK
MOk5GAStN/+znBjLy+5V/17EJuVpE+WVwUqDg3RafB8NGQtaClymwPg6R+SMWwL9
uiRcCVgmgzlk9l+4Z1p9wHUeQlhZQ/Okzj4CjkOpWfgsUpo0PcWQRosd+CHHirWz
iWnhFBM1cP4Nj59ashYSedu797s29pKGd31JcuWWQE228iykGfcCJWzMr9YMiU6x
LwESeuTST8b9HblI7WYnFvpVvD9qTuBkkKMIKMNb4E34xBf8+H2zUh1hK7iEnDXt
W0F1xy3WsxpJ1yF0BY9SqqnNeLpJBOenHlTZfGlf5r+kHWYUUQvvqw/ZdmWStRgv
mSoqXSmz/oM3rn1KjMritJ9oyr0EH8kHDMAsoiCF0EuGipmenFTdJJiwbh0JZJxK
bjqPUROtSK8TdPvTw1BPRX5YtJLzsG4HdsI3C8W05BTbCL9iIE1NaWP27nikPVfq
glt9EilzgR252Wc649OrB7JAHBZjlVFIndNzjziGdxNzH6m1AK05qxTL5hBvba99
plccrsVMDGWLSmsGVwz7Eo+TLflRCdtrE+7O4NrlydZzp2t24HZrMc9rN8GDWQQE
dP91YUdpDYrTsUBKiKGQ
=Pr7P
-----END PGP SIGNATURE-----
Merge tag 'mmc-updates-for-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
Pull MMC update from Chris Ball:
"MMC highlights for 3.10:
Core:
- Introduce MMC_CAP2_NO_PRESCAN_POWERUP to allow skipping
mmc_power_up() at boot/initialization time if it's already
happened, for performance (faster boot time) reasons.
- Fix a bit width test failure that resulted in old eMMC cards being
put into 1-bit mode when 4-bit mode was available.
- Expose fwrev/hwrev for MMCv4 parts.
- Improve card removal logic in the case where the card's removed
slowly; we were missing card removal events if the card retained
contact with the slot pads for long enough to reply to a CMD13
while being removed.
Drivers:
- davinci_mmc: Support using PIO instead of DMA.
- dw_mmc: Add support for Exynos4412.
- mxcmmc: DT support, use slot-gpio API.
- mxs-mmc: Add broken-cd/cd-inverted/non-removable DT property
support.
- sdhci-sirf: New sdhci-pltfm driver for CSR SiRF SoCs:
SiRFprimaII: unicore ARM Cortex-A9
SiRFatlas6: unicore ARM Cortex-A9
SiRFmarco: dual core ARM Cortex-A9 SMP
- sdhci-tegra: Add support for Tegra114 platforms, use
mmc_of_parse()"
* tag 'mmc-updates-for-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (66 commits)
mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
mmc: core: fix init controller performance regression, updated patch
mmc: mxcmmc: enable DMA support on mpc512x
mmc: mxcmmc: constify mxcmci_devtype
mmc: mxcmmc: use slot-gpio API for write-protect detection
mmc: mxcmmc: add mpc512x SDHC support
mmc: mxcmmc: fix race conditions for host->req and host->data access
mmc: mxcmmc: DT support
mmc: dw_mmc: let device core setup the default pin configuration
mmc: mxs-mmc: add broken-cd property
mmc: mxs-mmc: add non-removable property
mmc: mxs-mmc: add cd-inverted property
mmc: core: call pm_runtime_put_noidle in pm_runtime_get_sync failed case
mmc: mxcmmc: Fix bug when card is present during boot
mmc: core: fix performance regression initializing MMC host controllers
Revert "mmc: core: wait while adding MMC host to ensure root mounts successfully"
mmc: atmel-mci: pio hang on block errors
mmc: core: Fix bit width test failing on old eMMC cards
mmc: dw_mmc: Use pr_info instead of printk
mmc: dw_mmc: Check return value of regulator_enable
...
Use preferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Chris Ball <cjb@laptop.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add MMC_CAP2_NO_PRESCAN_POWERUP to sdhci-pci.c also, use mmc_power_off()
for MMC_CAP2_NO_PRESCAN_POWERUP.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
[cjb: previously applied v1 of this patch instead of v4]
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit fa5501890d introduced a performance
regression by adding mmc_power_up() to mmc_start_host(). mmc_power_up()
is not necessary to host controller initialization, it is part of card
initialization and is performed anyway asynchronously.
This patch allows a driver to leave the power up in asynchronous code
(as it was before).
On my current target platform this reduces driver initialization from:
[ 1.313220] initcall sdhci_acpi_driver_init+0x0/0x12 returned 0 after 102008 usecs
to this:
[ 1.217209] initcall sdhci_acpi_driver_init+0x0/0x12 returned 0 after 8331 usecs
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
This reverts commit 3500ed90b2.
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: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris 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: Sergey Yanovich <ynvich@gmail.com>
Signed-off-by: Chris 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: Kevin Liu <kliu5@marvell.com>
Tested-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Philip Rakity <prakity@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris 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: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chris 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: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Chris 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: Johan Rudholm <johan.rudholm@stericsson.com>
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris 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: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add mmc_power_cycle which can be used to power cycle for instance
SD-cards.
Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris 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: Maya Erez <merez@codeaurora.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris 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: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Provide support for automatically sending Set Block Count
(CMD23) messages. Used at least for RPMB support.
Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: Chris 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: Trey Ramsay <tramsay@linux.vnet.ibm.com>
Signed-off-by: Chris 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: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saugata Das <saugata.das@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris 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: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Chris 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: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
If MMC_CAP_NONREMOVABLE is set, only issue a detect job on init.
Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris 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: Venkatraman S <svenkatr@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Chris 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: Aaron Lu <aaron.lu@amd.com>
Tested-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris 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: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris 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: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris 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: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris 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: Alex Lemberg <Alex.Lemberg@sandisk.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris 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: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Chris 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: Ulf Hansson <ulf.hansson@stericsson.com>
Tested-by: Daniel Drake <dsd@laptop.org>
[stable@: please apply to 3.2-stable and 3.3-stable]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Chris 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: Adrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris 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: Adrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris 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: Paul Walmsley <paul@pwsan.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Chris 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: Ulf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: Per Forlin <per.forlin@stericsson.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Most parts of the enable / disable API are no longer used and
can be removed.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Venkatraman S <svenkatr@ti.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris 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: Ulf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris 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: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Chris 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: Ulf Hansson <ulf.hansson@stericsson.com>
Acked-by: Philip Rakity <prakity@marvell.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Chris 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: Girish K S <girish.shivananjappa@linaro.org>
Tested-by: Girish K S <girish.shivananjappa@linaro.org>
Reviewed-by: Saugata Das <saugata.das@linaro.org>
Signed-off-by: Chris 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: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris 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: Sujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
