[ Upstream commit 987aa5f8059613bf85cbb6f64ffbd34f5cb7a9d1 ]
with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream.
During a re-initialization of the eMMC card, we may fail to re-enable HPI.
In these cases, that isn't properly reflected in the card->ext_csd.hpi_en
bit, as it keeps being set. This may cause following attempts to use HPI,
even if's not enabled. Let's fix this!
Fixes: eb0d8f135b ("mmc: core: support HPI send command")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that CMDQ device and driver are stable, Change unnecessary
pr_err logs to pr_debug.
Also use %pK instead of %p while printing addresses to avoid leaking
of kernel addresses.
Change-Id: I95683ffe0410daef86dd9a376f5769d8f40ae990
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Use %pK instead of %p in debug logs so that kernel addresses don't get
leaked when debug logs are dynamically enabled.
Change-Id: I3c0df8a8db6643ab547d8599dd03b54030f76ece
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
(cherry picked from commit b277da0a8a594308e17881f4926879bd5fca2a2d)
Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
QUEUE_FLAG_NONROT.
Historically, all block devices have automatically made entropy
contributions. But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
- On SSD disks, the completion times aren't as random as they
are for rotational drives. So it's questionable whether they
should contribute to the random pool in the first place.
- Calling add_disk_randomness() has a lot of overhead.
There are more reliable sources for randomness than non-rotational block
devices. From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.
Change-Id: Iaace159bea0e9245e6825cccd4f6a1152a166ce1
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 upstream.
According to the code the intention is to append 8 SCK cycles
instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this
will never happened because it's an AC command not an ADTC command.
So fix this by moving the statement into the right function.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: e4243f13d1 (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
commit 16652a936e96f5dae53c3fbd38a570497baadaa8 upstream.
We never set "ret" to RESULT_OK.
Fixes: 9f9c4180f8 ("mmc: mmc_test: add test for non-blocking transfers")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
commit 0ed50abb2d8fc81570b53af25621dad560cd49b3 upstream.
CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1.
Older versions of the specification allowed to terminate
multi-block transfers only with CMD12.
The patch fixes the following problem:
mmc0: new MMC card at address 0001
mmcblk0: mmc0:0001 SDMB-16 15.3 MiB
mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900
...
blk_update_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on dev mmcblk0, logical block 0, async page read
mmcblk0: unable to read partition table
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
commit f91346e8b5f46aaf12f1df26e87140584ffd1b3f upstream.
An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.
In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.
Fixes: e4243f13d1 (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 upstream.
The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:
[ 563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[ 563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1
Convert header data to LE.
Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
Fixes: ce39f9d17c ("mmc: support packed write command for eMMC4.5 devices")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
This change sets err_state in sdhci_dumpregs func indicating
driver errors captured, which can be read out from debugfs.
CRs-Fixed: 1056483
Change-Id: If6323f4e2cf9c835139ea92753ae8407709b8a70
Signed-off-by: Liangliang Lu <luliang@codeaurora.org>
This change adds support to allow user space query if low level eMMC
driver has encountered any error or not, this state can be read/cleared
via debugfs.
CRs-Fixed: 1056483
Change-Id: Idc4ea375e9f308446dec04d443d062fe502658bd
Signed-off-by: Liangliang Lu <luliang@codeaurora.org>
In mmc_wr_pack_stats_read(), userspace buffer is directly accessed
which is violating PAN (Privilege Access Never).
So to prevent this, data which needs to be copied to user buffer is
gathered into a local buffer and at the end, this local buffer
contents are copied back to buffer supplied from user space using
copy_to_user().
Change-Id: Id772613fe54c47d64906c18d3d0249eee2f6ac26
Signed-off-by: Siba Prasad <sibap@codeaurora.org>
When system is heavily loaded, in some cases interrupt servicing
is getting effected and cmdq halt interrupt handler is getting invoked
after 1 sec delay. Since wait time of HAC interrupt in cmdq driver
is 1 sec, the delayed interrupt is being treated as unexpected
interrupt.
For fixing this case, increasing the timeout to 10 seconds.
Change-Id: I55879095aa2b81a10f40963aee02b2068a3305b4
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Enable the legacy interrupts immediately after halt interrupt is
handled, from cmdq_irq() itself.
When cmdq halt is initiated, as per existing logic driver waits either
for halt interrupt to fire or for certain period of time. In case if
cmdq is halted but halt interrupt got delayed than wait-timeout period,
driver disables cmdq interrupts since cmdq is in halt state.
The delayed halt interrupt gets fired only when cmdq is unhalted next
time and cmdq interrupts are enabled. And this delayed interrupt is
treated as an unexpected interrupt.
By enabling legacy interrupts (i.e., disabling cmdq interrupts) from
cmdq_irq(), we can ensure that we don't disable cmdq interrupts until
halt interrupt get fired. So we can avoid above mentioned scenario.
Change-Id: Ic052d41fac789b6390a5d80dfaee91767bdb783f
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
In eMMC driver CQ mode, the sdhc driver votes for pm qos and unvotes in
hardware irq when there are no more requests. But in a particular corner
scenario, the qos unvoting is not done by hardware irq handler after
last request and this can cause power regression. So the unvoting was
been shifted to software irq context of eMMC driver where there is
enough information to accurately know when there are no active requests to
the eMMC driver.
There is a very rare corner case when the active req counter is
checked by completion context and before it schedules the work to
unvote, the issuing context can set active req counter and do
qos voting. In this case the performance suffers but this is a
very rare corner case as the completion context is in softirq.
Also it is not good to add locking to prevent this corner case as
issuing and completion contexts should not have locking in between them.
Change-Id: I9fb714d3a5e4eb35a0bedd69691e3f1f84fc4cd8
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
According to specs, some commands require a delay after
issuing the command. idata->ic struct is received from
user in mmc_blk_ioctl_cmd(). So idata->ic.postsleep_min_us,
idata->ic.postsleep_max_us are user controlled. If the min
and max values are set such as max < min, then operation in
the function do_usleep_range will overflow. For avoiding this,
put a condition for checking max < min. If the condition is
true, then print the error message with respective values and
return error.
Change-Id: Iaf966d19275741a666d2dae1f0c32b72ab0642eb
Signed-off-by: Siba Prasad <sibap@codeaurora.org>
According to specs, some commands require a delay after
issuing the command. idata->ic struct is received from
user in mmc_blk_ioctl_cmd(). So idata->ic.postsleep_min_us,
idata->ic.postsleep_max_us are user controlled. If the min
and max values are set such as max < min, then operation in
the function do_usleep_range will overflow. For avoiding this,
put a condition for checking max < min. If the condition is
true, then print the error message with respective values and
return error.
Change-Id: I76828b58aa46fc4e195da4ae0babb02a7abf6bbe
Signed-off-by: Siba Prasad <sibap@codeaurora.org>
In CQ mode, the legacy commands will be sent after CQ is put in
halt state. But when deferred resume is enabled, the resume
happens in mmc_wait_for_req(), which will enable CQ again
overiding the caller's state. This causes legacy commands to fail.
Fix this by moving the deferred resume from all the places to
mmc_rpm_hold() which is always the first step done in both
CQ/legacy commands and thus avoids the above issue scneario.
Fix: fbb7cbf8ea (mmc: core: Add deferred resume for command queue mode)
Change-Id: I97fb9d654968b294dc1fb6986b8b9431e22233c0
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
This reverts commit e423578d2857a7bb83857f8d7bae4e9ba11f1af7.
As a part of above commit, mmcqd thread's priority was
modified to sched_fifo making it a RT task. This resulted
in starving other tasks like watchdog and starting hiting
watchdog bite error. This is expected if there are too
many requests to SD card and since it is fast enough to
serve the requests, it may starve other tasks.
Hence reverting the change to avoid such issues.
Change-Id: I620b674a990b9e2e76027a7419e1275679fa4eb0
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Sometimes after failing RPMB access due to card in bad voltgae state,
If issue USER parition access request,it fails as card is already in
bad state. Fix this by adding error handling to mmc_blk_part_switch()
and by resetting the block whenever partition switch fails.
Change-Id: I98c6793e25a11d209553236c266cca908242095f
Signed-off-by: Pavan Anamula <pavana@codeaurora.org>
MMC_PM_WAKE_SDIO_IRQ flag is used by platform driver(sdhci-msm
here) to determine if SDIO wakeup IRQ needs to be enabled
or not. If this flag is not removed in every mmc_resume_host,
then while suspend, platform driver will configure the sdio
wakeup IRQ even though wlan is disabled from UI.
This flag can be enabled by wlan driver before entring into suspend.
In this case since Wlan is not enable and thus not entering WoW mode,
pull up present on this SDIO GPIO line will pull the line high (which
otherwise is pulled low by wlan firmware in WoW mode and triggers
interrupt by pulling it high in WoW mode) which eventually will
trigger a false SDIO wakeup interrupt thus breaking the suspend
everytime.
Hence disable the flag everytime in mmc_resume_host and let
wlan driver enables it (-by sdio_set_host_pm_flags)
before entering into suspend if needed
for sdio wakeup part.
Change-Id: Iecf9eef4d91a741116bc8b8bb59c49ae7f2891fd
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Specifies if SDIO host and card requires complete
power_restore (mmc_sdio_power_restore) while resuming.
This is in cases where card cannot go through complete
pwr_cycle in suspend/resume like in case of
QCA9377 & QCA6574.
Change-Id: I41976752aff28d1e86746d16298c9de5bf071519
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Power supply to card QCA9377 & QCA6574 is used for wlan and
bluetooth as well.
Now if SDIO card is switched to 1.8V signaling voltage, it will not
switch back to 3.3V without a power cycle. CMD0 will not make SD (SDIO)
card enter 3.3V signalling voltage. Since the power supply
for mentioned card is also used to power bluetooth along with
wlan, so card cannot be power cycled for wlan alone from such mmc
host
This patch adds a capability for such host which cannot power cycle
the card. Thus during resume of sdio (mmc_sdio_resume), it checks
if host has MMC_CAP2_BROKEN_PWR_CYCLE capability set. In case if this
capability is set we do mmc_sdio_power_restore.
This patch also fixes the resume path that if there is an oldcard
present and it's an UHS card then CMD11 may give no response. In that
case we need to switch only host signal voltage to 1.8V as card is
already in 1.8V.
Without this patch software assumes that card is switched to 3.3V on
power cycle and tries voltage switch sequence which fails
(because host driver will not control this power supply and thus
card will never enter into 3.3V supply). Thus UHS mode is not entered.
Change-Id: I1fae116fd3c5b3854761ac09da1ffec7f6ddfec9
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Move Qos calls before Data desc/DCMD desc writes, so that
a wmb() is issued just after Data/DCMD desc write and
before ringing the doorbell.
This will ensure that the Data/DCMD desc write is visible
to SDCC DMA.
Change-Id: Iace5ae2e4b3db41c3118352a27e6cb37fd12589e
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
There are issues with ADMA when used with ICE enabled for tuning
commands. As a workaround, use PIO mode for these commands by
enabling quirk SDHCI_QUIRK2_USE_PIO_FOR_EMMC_TUNING .
Change-Id: I8dbec823938525af90fb990db1bb4b325ee23cba
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some controllers have an issue using ADMA for tuning commands.
Add a quirk - SDHCI_QUIRK2_USE_PIO_FOR_EMMC_TUNING to use PIO
mode for tuning commands on those host controllers.
Change-Id: Id9625167d7e235fb3a20a6193889c1654b5c0cd8
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some controllers need SW to compare the data received
from the card for a tuning command. Enable this quirk -
SDHCI_QUIRK2_NON_STANDARD_TUNING for sdhci msm host
controller.
Change-Id: Id6f6230520db1ad018c883cb639fe66b4b86c70c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some controllers need SW to compare the data received
from the card for a tuning command. Add a quirk for
such non standard controllers so that they can read
the data from the controller using ADMA/PIO and do the
tuning sequence from SW to determine the appropriate phase.
Change-Id: I15edfdf0442e3ac678c70df29482b3304cf1215a
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Some of the transfer parameters like DMA mode will be changed
only when CQ is in HALT state to send some legacy commands like
tuning etc.
Also, fix a typo with set_transfer_params() host op.
Change-Id: I3a9856e0d60ce6a9cc1727cd8ccd10ef33bb707c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Data CRC errors are observed for the data commands that are
sent immediately after tuning in HS200 mode with CQ enabled but
in HALT state. This is because tuning commands change the block
size to 128 bytes from default 512 bytes.
Change-Id: I9657b16954b54c491fa19f9d82d9141edf45e0ef
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
During the suspend of class device (mmc_host), it is
legal for the suspend to fail. For e.g in case of SDIO
the wlan may refuse to suspend at that point of time.
In such a scenario the device should not be marked as
suspended. Its state should be restored to resumed.
Otherwise, the device never enters suspend again.
write mem to /sys/power/state -> suspend is triggered
[0: ksdioirqd/mmc2:25044] HIFsuspendwow TODO
wma_suspend_fw: wow suspend successful
system_server: 1226] vfsspi_regulator_onoff: off
kworker/u16:2:23854] mmc2: mmc_host_suspend: start
wma_check_scan_in_progress: scan in progress on interface
hifDeviceSuspend: Scan in progress. Aborting suspend
kworker/u16:2:23854] wlan suspend failed error=-1
Wlan refuses to suspend above
mmc2: mmc_host_suspend: failed: ret: -1 .
mmc2: mmc_host_suspend: end -->
dpm_run_callback(): mmc_host_suspend+0x0/0x2d8 returns -1
PM: Device mmc2 failed to suspend async: error -1
PM: Some devices failed to suspend
Since wlan refuses to suspend, SDIO doesn't suspend too.
But the class device is still marked to be suspended
[state: 2] incorrectly.
It should be marked as resumed, since suspend had failed.
After this, the device never suspends:
!@suspend_thread_func: write mem to /sys/power/state
PM: suspend entry 2016-03-29 10:52:42.456889406 UTC
mmc2: sdio_irq_thread: 130: acquired wlock: state: 2 ->
incorrectly marked as suspended.
mmc2: sdio_irq_thread: 130: acquired wlock: state: 2
PM: Syncing filesystems ... done.
active wakeup source: mmc2:0001->wakeup event by mmc2
CRs-fixed: 997876
Change-Id: Ib08a72b2ab21c4d4a76bac8e65d06c13ccbd1482
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
This is needed to set the dma mode for CQ transfers. The dma mode
may be changed by the commands sent in legacy mode (like tuning
which uses FIFO mode).
Change-Id: Idaa2cb0c7712846f6827272caefc112b127ef818
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Move Qos calls before Data desc/DCMD desc writes, so that
a wmb() is issued just after Data/DCMD desc write and
before ringing the doorbell.
This will ensure that the Data/DCMD desc write is visible
to SDCC DMA.
Change-Id: Iace5ae2e4b3db41c3118352a27e6cb37fd12589e
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>