| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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 fa5501890d8974301042e0202d342a6cbe8609f4 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 3500ed90b26a9935b943b5e2e4cd3226600d6b58.
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 fixes incorrect indentation. (Just code cleanup)
Signed-off-by: Jaehoon Chung <jh80.chung@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>
|
|
Autogenerated GPG tag for Rusty D1ADB8F1: 15EE 8D6C AB0E 7F0C F999 BFCB D920 0E6C D1AD B8F1
* tag 'for-linus' of git://github.com/rustyrussell/linux:
module_param: check that bool parameters really are bool.
intelfbdrv.c: bailearly is an int module_param
paride/pcd: fix bool verbose module parameter.
module_param: make bool parameters really bool (drivers & misc)
module_param: make bool parameters really bool (arch)
module_param: make bool parameters really bool (core code)
kernel/async: remove redundant declaration.
printk: fix unnecessary module_param_name.
lirc_parallel: fix module parameter description.
module_param: avoid bool abuse, add bint for special cases.
module_param: check type correctness for module_param_array
modpost: use linker section to generate table.
modpost: use a table rather than a giant if/else statement.
modules: sysfs - export: taint, coresize, initsize
kernel/params: replace DEBUGP with pr_debug
module: replace DEBUGP with pr_debug
module: struct module_ref should contains long fields
module: Fix performance regression on modules with large symbol tables
module: Add comments describing how the "strmap" logic works
Fix up conflicts in scripts/mod/file2alias.c due to the new linker-
generated table approach to adding __mod_*_device_table entries. The
ARM sa11x0 mcp bus needed to be converted to that too.
|
|
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: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Rusty 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: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris 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: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
Host may now use MMC_CAP2_NO_SLEEP_CMD to disable the use
of eMMC sleep/awake command.
This option can be used when your platform has a buggy
kernel crash dump software, which is supposed to store
the dump on the eMMC, but is not able to wake up the eMMC
from sleep state.
In particular, failures have been seen with u-boot; even if
it is fixed there, platforms will be slow to update their
bootloader binaries.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: Hanumath Prasad <hanumath.prasad@stericsson.com>
Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Acked-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
Ulf Hansson
Maya Erez
Linus Torvalds
Akinobu Mita
Adrian Hunter
Sergey Yanovich
Kevin Liu
Marek Szyprowski
Jaehoon Chung
Seungwon Jeon
Johan Rudholm
Konstantin Dorfman
Loic Pallardy
Trey Ramsay
Chris Ball
Venkatraman S
Aaron Lu
Guennadi Liakhovetski
Ulf Hansson
Paul Walmsley
Girish K S
Sujit Reddy Thumma
Rusty Russell