Hardware reset is not implemented in SD card. To circumvent this,
a power-cycle is issued to the card & it is reinitialized.
This would help recovering from 'card stuck in programming state'
situations.
mmc_can_reset: Added check for SD card.
CRs-fixed: 375869
Change-Id: I8bd7dc071f3569898371d5becca06ec2fe937d4a
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
When the fault injection framework introduces an error to the data
block, the current code queries the SD card to find the number of
blocks actually programmed. This value would be as requested by the
generic block layer. So the entire request would be completed.
Say, request 0 is pulled from queue and submitted. When this is being
processed, request 1 is pulled from queue and prepared. Request 0
though is successful, fault-injection framework injects an error
and modifies the bytes_xferred variable to a random value less than
requested transfer. Request 1 is not processed and during the handling
of error, the SD card is queried for the actual bytes programmed. This
would be the correct value. Thus blk_end_request would complete
this request and the control would return to fetch request 2. In this
process, request 1 is not processed at all and the application waits
indefinitely for request 1 to be processed. No further requests are
issued to the queue.
This patch identifies, if the fault injection-framework has inserted an
error to this request and doesn't query the card and uses
bytes_xferred to complete the request.
Change-Id: I496802e244745bc7550402027a594d967cf7b756
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
In mmc_wait_for_req_done() function, change the call wait_for_completion()
to wait_for_compltion_io(). This change makes the kernel account for
wait time as I/O wait and through another configuration, this io wait
is treated as busy which makes the acpu clock to scale up.
Change-Id: Iebdc7b1b22871bf845f10a55e2272816c72d9964
Signed-off-by: Murali Palnati <palnatim@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
If sleep command has error it doesn't mean host cannot suspend,
but a deeper low power state transition for the card has failed.
Report an warning in error case and ignore propagating the error
so that suspend is not aborted.
If there is such sleep error during mmc_suspend(), mmc_resume()
takes care of complete intialization of the card.
CRs-Fixed: 370446
Change-Id: I47f31fd35c463544d2ea2bce56f9e5b5295e7e4d
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
This reverts the if/else part of
4466903481. We don't know why it
was done though and this should probably be dropped after testing.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Current implementation decides the card type exclusively. Even though
eMMC device can support both HS200 and DDR mode, card type will be
set only for HS200. If the host doesn't support HS200 but has DDR
capability, then DDR mode can't be selected.
Change-Id: Ifb5bb7fb0b7f4472734e10ec39d47e3f12e32cf8
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
This bug was introduced in the 'MMC-4.5 Power OFF Notify Rework' fix.
Prior to the aforementioned patch, during resume mmc_init_card was being
invoked. The aforesaid patch invokes mmc_card_awake, prior to which
mmc_power_up has already set the clock frequency to 400Khz. Since the card
init is not done again, this frequency stays as is and results in data
time-out errors.
Two new functions
* mmc_save_ios
* mmc_restore_ios
were added.
The mmc_save_ios is invoked during mmc_suspend process and it saves the
current ios values, while mmc_restore_ios is invoked during mmc_resume process
and restores the previous ios values before sending the awake command. This
ensures that the clock, timing, bus-width etc are set properly before any
request is sent to the driver.
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
This is a rework of the existing POWER OFF NOTIFY patch. The current problem
with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF
power_mode from mmc_set_ios in different host controller drivers.
This new patch works around this problem by adding a new host CAP,
MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a
POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that host
controller drivers will set this CAP, if they switch off both Vcc and Vccq
from MMC_POWER_OFF condition within mmc_set_ios. However, note that there
is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off.
This patch also sends POWER OFF NOTIFY from power management routines (e.g.
mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host), which
does reinitialization of the eMMC on the return path of the power management
routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE,
mmc_start_host).
This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent from
the suspend sequence. If it is sent from shutdown sequence then it is set to
POWER_OFF_LONG.
Earlier implementation of PowerOff Notify as a core function is replaced as
a device's bus operation.
Signed-off-by: Saugata Das <saugata.das@linaro.org>
Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
changes in v5:
modified the the handling of return value in mmc_poweroff_notify.
changes in v4:
As suggested in review,
- Moved mmc_can_poweroff_notify to core.c
- Moved mmc_claim_host, mmc_release_host outside mmc_poweroff_notify
- Added check for wrong initialization for poweroff_notify_type
- mmc_poweroff_notify is modified to take as 2nd parameter
changes in v3:
This version addresses the review comments given by Subhash and Ulf
changes in v2:
This version addresses the changes suggested by Ulf
[smuckle@codeaurora.org: resolve minor merge conflicts]
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
If PM_SLEEP is not enabled, mmc.c will give warnning since mmc_bus_suspend/
mmc_bus_resume functions are defined but not used. This patch can fix this
warnning.
Reported-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@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>
[sboyd: Keep non-upstreamed bits for sdio.c]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The write packing statistics are used for the packed commands unit tests
in order to determine test success or failure
Change-Id: I1b330033e59a775c64fb915038d58615aff0dbdd
Signed-off-by: Maya Erez <merez@codeaurora.org>
Define max timeout, when BKOPS started for urgent BKOPS level (2,3).
Otherwise it will be default host controller timeout
Change-Id: I53c17ea3c575cbde0c2198e3071f21e98bcebe13
Signed-off-by: Maya Erez <merez@codeaurora.org>
This patch supports packed write command of eMMC4.5 device.
Several writes can be grouped in packed command and all data
of the individual commands can be sent in a single transfer
on the bus.
Change-Id: I391c3e5f73b785a8b7d25eb8256051020cfb0631
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Maya Erez <merez@codeaurora.org>
This change fixes the following issues in eMMC v4.5 BKOPS (back
ground operations)
1. For HPI (high priority interrupt) sent using CMD12,
configure R1B response flag, as defined by spec
2. Mark BKOPS shadow flag (doing_bkops) only for non-urgent BKOPS levels,
otherwise is not needed this because BKOPS already completed
synchronously (with R1B)
3. Send HPI before sleep (CMD5), when BKOPS is in progress
Change-Id: I575fe0946d04c91f1de71804409c60c7acb6d46a
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Enable eMMC background operations (BKOPS) feature.
If URGENT_BKOPS is set after a response, note that BKOPS
are required. After all I/O requests are finished, run
BKOPS if required. Should read/write operations be requested
during BKOPS, first issue HPI to interrupt the ongoing BKOPS
and then service the request.
If BKOPS-STATUS is upper than LEVEL2, need to check until clear
the BKOPS-STATUS vaule.
If you want to enable this feature, set MMC_CAP2_BKOPS.
And if you want to set the BKOPS_EN bit in ext_csd register,
use the MMC_CAP2_INIT_BKOPS.
Future considerations
* Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
* Interrupt ongoing BKOPS before powering off the card.
* How get BKOPS_STATUS value.(periodically send ext_csd command?)
Change-Id: Ia679c661a282072a7e54d10fc59d8ec1cbecae96
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>
This patch adds packed command feature of eMMC4.5.
The maximum number for packing read(or write) is offered
and exception event relevant to packed command which is
used for error handling is enabled. If host wants to use
this feature, MMC_CAP2_PACKED_CMD should be set.
Change-Id: I8013970fc9d54da7d92b0aca2bb0746189b9825b
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Maya Erez <merez@codeaurora.org>
mmcq performance numbers are not captured since asynchronous
MMC request support got added in MMC block driver. So printing
out these numbers (which are all zeros) just adds confusion.
This patch removes the printing of mmcq performance numbers
statistics.
CRs-Fixed: 364206
Change-Id: I7213b11c8e9e055894c9902af7e975de3be1c519
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Commit 06e8935feb ("optimized SDIO IRQ handling for single irq")
introduced some spurious calls to SDIO function interrupt handlers,
such as when the SDIO IRQ thread is started, or the safety check
performed upon a system resume. Let's add a flag to perform the
optimization only when a real interrupt is signaled by the host
driver and we know there is no point confirming it.
Change-Id: Ibfd6b35589b15fabea7b1c18dfa2197a78866b61
Reported-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
MMC_CLKGATE feature can be enabled for Atheros AR6003 cards as
the host supports asynchronous acitivity notification when the
clocks are off.
Change-Id: Ieff00382894a0841496776dc6a6b1db53e204d6d
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Some INAND MCP devices advertise incorrect data timeout values.
This leads to data timeout errors on the platform. So, add a quirk
for such devices to facilitate proper functionality.
CRs-Fixed: 355347
Change-Id: If4fdd2724dc407450da8529222efca7ee94f50df
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Currently performance numbers are captured for each SDCC
transfers unconditionally which may add the overhead and
could reduce the SDCC read/write throughput numbers.
This change adds additional control for enabling/disabling the
capturing of performance numbers at runtime. We already have sysfs
entry named "perf" for msm sdcc devices. Currently setting this
entry to 0 clears the performance statistics. But now we are
changing the definition of this entry as mentioned below:
Disable performance capturing and clear the performance statistics:
"echo 0 > /sys/devices/platform/msm_sdcc.<n>/perf"
Enable performance capturing:
"echo 1 > /sys/devices/platform/msm_sdcc.<n>/perf"
CRs-fixed: 345170
Change-Id: I3ab9288fd87cc8a8ada6c0c3d066cac4f68d79b7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
MMC_CLKGATE feature can be enabled for Volans cards as
the host supports asynchronous acitivity notification
when the clocks are off.
Change-Id: Ic6cfa7fb2e713dcf1d2c6b2ae9df9cf0394f8c4a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc_set_ios() is used by host drivers during suspend/resume
routines in indirect way i.e., by calling host->ops->set_ios().
But now with MMC_CLKGATE enabled, mmc_set_ios() also updates
host->clk_gated flag. So export this API so that host controller
drivers can use it.
Change-Id: Ib0c177635bb8d87ba68c98e08b8d940c73f2b80c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc_resume_host() is called during resume (runtime or system) which calls
1. mmc_power_up
2. mmc_select_voltage
3. host->bus_ops->resume() (mmc_sd_resume())
mmc_sd_resume() ultimately calls mmc_sd_init_card() to initialize the
SD card. But let's say if mmc_sd_init_card() fails during the
execute_tuning(). At this point, host controller timing is changed
to SDR104/SDR50 mode and host clock will also be > 100 MHz.
If there is an error returned by mmc_sd_init_card() and
if CONFIG_MMC_PARANOID_SD_INIT defined, it retries by calling
mmc_sd_init_card() without making sure that host controller timing
and clock be initialized again. This may cause the further
mmc_sd_init_card() also to fail.
To fix this, mmc_sd_resume() should call mmc_power_up()
and mmc_select_voltage() before retrying.
Change-Id: I8de39ea547fa0d5eca478719a4cf9255b6652503
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SDCC runtime suspend can race with mmc_rescan causing deadlock.
The call flow would be this:
1) When runtime suspend is triggered:
msmsdcc_runtime_suspend()
-> mmc_suspend_host()
-> mmc_flush_scheduled_work()
2) mmc_flush_schedule_work() waits for mmc_rescan() work
to be completed if it is already in runqueue.
3) When mmc_rescan() is scheduled to run:
mmc_claim_host()
-> msmsdcc_enable()
->pm_runtime_get_sync()
4) pm_runtime_get_sync() waits for runtime_suspend to complete,
and hence cause two threads to wait upon each other.
Fix this deadlock by aborting runtime suspend when mmc_rescan
is scheduled.
CRs-Fixed: 326610
Change-Id: I4ca88651f80f5a1bfccb6e0c07e3ea83fadcdc57
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
msleep of any delay less than 20ms (or 2 jiffies) would
give an unpredictable delay (most of the times as ~20ms).
Use usleep_range in mmc_delay() for delays less than two jiffies.
Change-Id: I7cf22532af2b4048afccf07a5aeba89d808799f0
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Qualcomm SDCC controller supports minimum SD clock frequency
which is required for card initialization. This information is
exported through platform data for each SDCC controller. There is
no need of retrying higher frequencies than the minimum supported
by controller for Qualcomm chipsets which inturn add delay in
detection process if there is no card during suspend/resume cycles.
Hence, skip multiple frequency retries.
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
When SD/MMC card is removed without unmounting and
then reinserted again while gendisk is freed. Partition
invalidation and deletion may take more than 10secs during
which SDCC controller can suspend due to runtime pm functionality.
Once the block layer activity is done it claims host to detach card
from MMC bus which triggers SDCC resume. As the host->card is
NULL already there is a BUG_ON hit in mmc_sd_resume(). Fix this
by claiming host even before we free host->card.
CRs-Fixed: 284262
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 5eed6a9778440ef512f597b43368337a7ef9438b)
Change-Id: I6b58aab1865a93a025fd9912200ab0beea21be92
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
Some eMMC cards require a delay of around 1ms after sending
the CMD6 command, before accepting further commands.
Change-Id: I0984c6d76db60fe596f67becccde524669a6cac1
Signed-off-by: Aparna Mallavarapu <aparnam@codeaurora.org>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
[sthumma@codeaurora.org: Porting missing changes from .32 to .35]
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
MMC core reads SEC_COUNT information from EXT_CSD register and assumes
that the card supports sector access mode. Some eMMC cards (<=2GB) do not
support this mode even though they have SEC_COUNT value defined, causing
failure while populating extended partitions. Sector/Byte access mode
information is stored in OCR register. Hence, read OCR bit 30 and then
confirm it with SEC_COUNT value to know whether the card supports sector
access mode or byte access mode.
Change-Id: Ifdfff35309e8667cd2c2ac2761b9a708d5b785d3
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
Depending on the host and card's capability SDIO cards can
operate at 8-bit buswidth.
Change-Id: I2ed1c5ecaff521db693db47928b0958ed0289645
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Qualcomm-SDIO client on MDM contains NULL tuple for all SDIO functions 1 to 7
and doesn't contain any valid data. This patch is a temporary software
workaround (not to read CIS if it is NULL tuple) until the hardware bug is
resolved. The device ID 0x23F0 is for the SDIO client core on MDM8220. The
device ID 0x23F1 is used for msm8660_charm.
Change-Id: I82f44d313b3d499462977a0a9bbc0759f489ae95
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Murali Palnati <palnatim@codeaurora.org>
Signed-off-by: Raj Kushwaha <rajk@codeaurora.org>
[sboyd: Squash in two other device id patches]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
There is a possible race with mmc_claim_host() in mmc_sd_suspend()/
mmc_suspend() and mmc_claim_host() in mmc_blk_issue_rq() when runtime
pm is enabled. Fix this by blocking processing of requests until the
previous runtime suspend is processed and then resume as part of
msmsdcc_enable(). Previous fix has card detection failure as a side effect
during resume.
Change-Id: I9cb31269638d9db4e630eb22b973a5335af1bda4
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
[sboyd: Dropped msm driver change]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The current code doesn't set any timeout value for bus test commands
CMD19 and CMD14. This fails bus test because the controller returns
DATATIMEOUT error for these commands. Fix the bus test timeout value
to 1ms for all cards.
Change-Id: I12446e094302f51853cc0c56a5c13b4a6a46d8cb
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Profiling code is added to measure read, write times for
the MMC requests at various MMC layers. Profiling is done
at the MMC queue and at the driver level. This information
can be viewed through a sysfs entry called perf.
Change-Id: I7c65bfe25a1f7774e3a9abf1f9539e690b3718ec
Signed-off-by: Aparna Mallavarapu <aparnam@qualcomm.com>
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>
Include the linux/mmc/cd-gpio.h header to pickup the prototypes
for the two exported symbols.
This quiets the sparse warnings:
warning: symbol 'mmc_cd_gpio_request' was not declared. Should it be static?
warning: symbol 'mmc_cd_gpio_free' was not declared. Should it be static?
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
MMC bus is using legacy suspend/resume method, which is not compatible if
runtime pm callbacks are used. In this scenario, MMC bus suspend/resume
callbacks cannot be called when system entering S3. So change to use the
new defined dev_pm_ops for system sleeping mode.
Tested on AM335x Platform. Solves major issue/crash reported at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65425.html
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Tested-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@stericsson.com>
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>
There is no need to take a wakelock for delayed lazy disable
work, it will be cancelled in the suspend handler and force
disabled. Only take the wakelock when the detect work is
queued, and make sure to drop the wakelock if the work is
cancelled.
Change-Id: I1e507a5f98848954ea21d45e23b6192c3132a349
Signed-off-by: Colin Cross <ccross@android.com>
