commit a89e7bcb18081c611eb6cf50edd440fa4983a71a upstream.
The Clock Data Recovery (CDR) circuit allows to automatically adjust
the RX sampling-point/phase for high frequency cards (SDR104, HS200...).
CDR is automatically enabled during DLL configuration.
However, according to the APQ8016 reference manual, this function
must be disabled during TX and tuning phase in order to prevent any
interferences during tuning challenges and unexpected phase alteration
during TX transfers.
This patch enables/disables CDR according to the current transfer mode.
This fixes sporadic write transfer issues observed with some SDR104 and
HS200 cards.
Inspired by sdhci-msm downstream patch:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/432516/
Reported-by: Leonid Segal <leonid.s@variscite.com>
Reported-by: Manabu Igusa <migusa@arrowjapan.com>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[georgi: backport to v4.14]
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make host->card as NULL when card is removed otherwise
we do see some kernel crashes in async contexts,
where host->card is referred (as dangling pointer).
Change-Id: Ifff6c7dffa674459add8b1e179f3ff7a8ddc7071
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Enhnaced RPMB support is added in eMMC v5.1 and later.
This change uses correct ext_csd rev (0x8 for v5.1) to
set enhanced rpmb support.
Change-Id: I5f99223ff55b1831793066c432d04ed60823881b
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
During GCC level clock gating of MCLK, the async FIFO
gets into some hang condition, such that for the next
transfer after MCLK ungating, first bit of CMD response
doesn't get written in to the FIFO. This cause the CPSM
to hang eventually leading to SW timeout.
To fix the issue, toggle the FIFO write clock after
MCLK ungated to get the FIFO pointers and flags to
valid states.
Change-Id: I29faefbcb814fcc36fb8afcf7ec2cb51c553b5e6
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
We observed some premature timeouts on a virtualization platform,
the log is like this:
case 1:
[159525.255629] mmc1: Internal clock never stabilised.
[159525.255818] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[159525.256049] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
...
[159525.257205] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa03
From the clock control register dump, we are pretty sure the clock was
stablized.
case 2:
[ 914.550127] mmc1: Reset 0x2 never completed.
[ 914.550321] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 914.550608] mmc1: sdhci: Sys addr: 0x00000010 | Version: 0x00001002
After checking the sdhci code, we found the timeout check actually
has a little window that the CPU can be scheduled out and when it
comes back, the original time set or check is not valid.
Change-Id: I291379e640d2896cfdebbe73133329a64c57d8c7
Fixes: 5a436cc0af ("mmc: sdhci: Optimize delay loops")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Alek Du <alek.du@intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Git-commit: b704441e38f645dcfba1348ca3cc1ba43d1a9f31
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
Skip dumping ADMA descriptor table memory for induced errors, Dump
it only for real ADMA errors. Otherwise, while inducing the errors
dumping memory is causing excessive logging and resulting in
watchdog bite.
Change-Id: I9a18a985986fe4832108cac7dcd15db162749295
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
commit 0b479790684192ab7024ce6a621f93f6d0a64d92 upstream.
While booting with rootfs on MMC, the following warning is encountered
on OMAP4430:
omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536]
This is because the DMA engine has a default maximum segment size of 64K
but HSMMC sets:
mmc->max_blk_size = 512; /* Block Length at max can be 1024 */
mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
mmc->max_seg_size = mmc->max_req_size;
which ends up telling the block layer that we support a maximum segment
size of 65535*512, which exceeds the advertised DMA engine capabilities.
Fix this by clamping the maximum segment size to the lower of the
maximum request size and of the DMA engine device used for either DMA
channel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793 upstream.
Some eMMCs from Micron have been reported to need ~800 ms timeout, while
enabling the CACHE ctrl after running sudden power failure tests. The
needed timeout is greater than what the card specifies as its generic CMD6
timeout, through the EXT_CSD register, hence the problem.
Normally we would introduce a card quirk to extend the timeout for these
specific Micron cards. However, due to the rather complicated debug process
needed to find out the error, let's simply use a minimum timeout of 1600ms,
the double of what has been reported, for all cards when enabling CACHE
ctrl.
Reported-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reported-by: Andreas Dannenberg <dannenberg@ti.com>
Reported-by: Faiz Abbas <faiz_abbas@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba9f39a785a9977e72233000711ef1eb48203551 upstream.
In commit 5320226a05 ("mmc: core: Disable HPI for certain Hynix eMMC
cards"), then intent was to prevent HPI from being used for some eMMC
cards, which didn't properly support it. However, that went too far, as
even BKOPS and CACHE ctrl became prevented. Let's restore those parts and
allow BKOPS and CACHE ctrl even if HPI isn't supported.
Fixes: 5320226a05 ("mmc: core: Disable HPI for certain Hynix eMMC cards")
Cc: Pratibhasagar V <pratibha@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>
commit b704441e38f645dcfba1348ca3cc1ba43d1a9f31 upstream.
We observed some premature timeouts on a virtualization platform, the log
is like this:
case 1:
[159525.255629] mmc1: Internal clock never stabilised.
[159525.255818] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[159525.256049] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
...
[159525.257205] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa03
From the clock control register dump, we are pretty sure the clock was
stablized.
case 2:
[ 914.550127] mmc1: Reset 0x2 never completed.
[ 914.550321] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 914.550608] mmc1: sdhci: Sys addr: 0x00000010 | Version: 0x00001002
After checking the sdhci code, we found the timeout check actually has a
little window that the CPU can be scheduled out and when it comes back,
the original time set or check is not valid.
Fixes: 5a436cc0af ("mmc: sdhci: Optimize delay loops")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Alek Du <alek.du@intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8cde625bfe8a714a856e1366bcbb259d7346095 upstream.
Since v2.6.22 or so there has been reports [1] about OMAP MMC being
broken on OMAP15XX based hardware (OMAP5910 and OMAP310). The breakage
seems to have been caused by commit 46a6730e3f ("mmc-omap: Fix
omap to use MMC_POWER_ON") that changed clock enabling to be done
on MMC_POWER_ON. This can happen multiple times in a row, and on 15XX
the hardware doesn't seem to like it and the MMC just stops responding.
Fix by memorizing the power mode and do the init only when necessary.
Before the patch (on Palm TE):
mmc0: new SD card at address b368
mmcblk0: mmc0:b368 SDC 977 MiB
mmci-omap mmci-omap.0: command timeout (CMD18)
mmci-omap mmci-omap.0: command timeout (CMD13)
mmci-omap mmci-omap.0: command timeout (CMD13)
mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
mmcblk0: error -110 requesting status
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD18)
mmci-omap mmci-omap.0: command timeout (CMD13)
mmci-omap mmci-omap.0: command timeout (CMD13)
mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
mmcblk0: error -110 requesting status
mmcblk0: recovery failed!
print_req_error: 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
After the patch:
mmc0: new SD card at address b368
mmcblk0: mmc0:b368 SDC 977 MiB
mmcblk0: p1
The patch is based on a fix and analysis done by Ladislav Michl.
Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770)
and OMAP2420 (Nokia N810).
[1] https://marc.info/?t=123175197000003&r=1&w=2
Fixes: 46a6730e3f ("mmc-omap: Fix omap to use MMC_POWER_ON")
Reported-by: Ladislav Michl <ladis@linux-mips.org>
Reported-by: Andrzej Zaborowski <balrogg@gmail.com>
Tested-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Resolve all warnings related to printk across drivers.
Change-Id: I5c6829943edd65c658b28c8275757a58ba28e942
Signed-off-by: vkakani <vkakani@codeaurora.org>
When exit from CX collapse event, the DLL registers lose their
contents because there is no SDCC registers retention support
during CX Collapse event. In case the SDCC is operating in
SDR104/HS200/HS400 modes, before resuming from CX Collapse event,
the DLL registers need to be saved and restored followed by
the SDCC's DLL initialization sequence in order for the DLL to be
fully functional again.
Change-Id: I9a870e783ce9b7271038fa5ce6e1d2f48a67d162
Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
When metadata encryption is enabled, below errors are observed
from pfk driver.
[ 44.754642] internal error, ref count should never be negative index 2
For discard commands, cq_host->ops->crypto_cfg_end() is being invoked
without its corresponding cq_host->ops->crypto_cfg() call. This is fine
until now, because ICE driver's msm_host->ice.vops->config_end() would
do nothing if req->bio is NULL. But with metadata encryption this may
not be NULL, thus resulting into refcnt mismatch for that key.
Change-Id: I1609eb8506d0d19944c536adbd9253da2a45c47c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
When metadata encryption is enabled, below errors are observed
from pfk driver.
[ 44.754642] internal error, ref count should never be negative index 2
For discard commands, cq_host->ops->crypto_cfg_end() is being invoked
without its corresponding cq_host->ops->crypto_cfg() call. This is fine
until now, because ICE driver's msm_host->ice.vops->config_end() would
do nothing if req->bio is NULL. But with metadata encryption this may
not be NULL, thus resulting into refcnt mismatch for that key.
Change-Id: I1609eb8506d0d19944c536adbd9253da2a45c47c
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
The variables which holds the register offset for HC_REG_DDR_CONFIG
register, its name got updated from DDR_CONFIG_2 DDR_CONFIG.
So would need to the updated in all other places as well where all
this register is being accessed.
And there was another register variable with same name DDR_CONFIG_2
which is unused and is masking the compilation errors of not updating
DDR_CONFIG register name across the file. Remove this unused register-
altogether.
Change-Id: I1f232091ea0998e486041dc3af7bab9633accbdf
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
commit cdcefe6bd9df754f528ffc339d3cc143cea4ddf6 upstream.
Problem:
The card detect IRQ does not work with modern BIOS (that want
to use _DSD to provide the card detect GPIO to the driver).
Details:
The mmc core provides the mmc_gpiod_request_cd() API to let host drivers
request the gpio descriptor for the "card detect" pin.
This pin is specified in the ACPI for the SDHC device:
* Either as a resource using _CRS. This is a method used by legacy BIOS.
(The driver needs to tell which resource index).
* Or as a named property ("cd-gpios"/"cd-gpio") in _DSD (which internally
points to an entry in _CRS). This way, the driver can lookup using a
string. This is what modern BIOS prefer to use.
This API finally results in a call to the following code:
struct gpio_desc *acpi_find_gpio(..., const char *con_id,...)
{
...
/* Lookup gpio (using "<con_id>-gpio") in the _DSD */
...
if (!acpi_can_fallback_to_crs(adev, con_id))
return ERR_PTR(-ENOENT);
...
/* Falling back to _CRS is allowed, Lookup gpio in the _CRS */
...
}
Note that this means that if the ACPI has _DSD properties, the kernel
will never use _CRS for the lookup (Because acpi_can_fallback_to_crs()
will always be false for any device hat has _DSD entries).
The SDHCI driver is thus currently broken on a modern BIOS, even if
BIOS provides both _CRS (for index based lookup) and _DSD entries (for
string based lookup). Ironically, none of these will be used for the
lookup currently because:
* Since the con_id is NULL, acpi_find_gpio() does not find a matching
entry in DSDT. (The _DSDT entry has the property name = "cd-gpios")
* Because ACPI contains DSDT entries, thus acpi_can_fallback_to_crs()
returns false (because device properties have been populated from
_DSD), thus the _CRS is never used for the lookup.
Fix:
Try "cd" for lookup in the _DSD before falling back to using NULL so
as to try looking up in the _CRS.
I've tested this patch successfully with both Legacy BIOS (that
provide only _CRS method) as well as modern BIOS (that provide both
_CRS and _DSD). Also the use of "cd" appears to be fairly consistent
across other users of this API (other MMC host controller drivers).
Link: https://lkml.org/lkml/2018/9/25/1113
Signed-off-by: Rajat Jain <rajatja@google.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: f10e4bf663 ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When inserting BAD sdcard in device and trying to read, device status
is continuously in programming state, leading to device hang and black
screen.
There is a 10 minute of waiting for device to come out of programming
state. But 10 minute is too long time to wait and it would increase the
CPU load significantly as we are continuously polling for the card
status.
To fix this issue reduces this timeout from 10 mins to 30 secs which is
quite reasonable for all good cards.
Change-Id: If1d3664a28cc246d8c80a7f0dc115ee7a0f7fd04
Signed-off-by: Ziqi Chen <ziqichen@codeaurora.org>
When system shutdown, kernel shall call shutdown function of mmc to stop
its request queue and clean it up, during which the request queue's kobject
shall be put once. In normal cases, if the SD card is removed, the
mmc_blk_remove routine releases all the resources and kobjects related to
the disk and request queue by decreasing their kref counts to 0. But if the
SD card is removed after its shutdown function is called, below kref count
underflow error shall be thrown out because the kref count was decreased
once during request queue cleanup by the shutdown function in advance. This
change fixes it by skipping request queue cleanup in the mmc blk routine if
the queue has been marked as dead.
[ 166.187211] refcount_t: underflow; use-after-free.
[ 166.187277] ------------[ cut here ]------------
[ 166.187321] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 166.187542] Workqueue: events_freezable mmc_rescan
[ 166.187558] task: ffffffe673b96680 task.stack: ffffff8008418000
[ 166.187579] pc : refcount_sub_and_test+0x64/0x78
[ 166.187593] lr : refcount_sub_and_test+0x64/0x78
[ 166.187605] sp : ffffff800841ba20 pstate : 60c00145
[ 166.188319] Call trace:
[ 166.188331] refcount_sub_and_test+0x64/0x78
[ 166.188343] refcount_dec_and_test+0x18/0x24
[ 166.188355] kobject_put+0x5c/0x74
[ 166.188374] blk_put_queue+0x1c/0x28
[ 166.188388] disk_release+0x70/0x90
[ 166.188402] device_release+0x38/0x90
[ 166.188429] kobject_cleanup+0xc4/0x1c0
[ 166.188441] kobject_put+0x68/0x74
[ 166.188455] put_disk+0x20/0x2c
[ 166.188467] mmc_blk_put+0x9c/0xdc
[ 166.188480] mmc_blk_remove_req+0x110/0x120
[ 166.188493] mmc_blk_remove+0x14c/0x22c
[ 166.188505] mmc_bus_remove+0x24/0x34
[ 166.188517] device_release_driver_internal+0x13c/0x1e0
[ 166.188528] device_release_driver+0x24/0x30
[ 166.188540] bus_remove_device+0xdc/0x120
[ 166.188552] device_del+0x1e0/0x284
[ 166.188564] mmc_remove_card+0x68/0x7c
[ 166.188577] mmc_sd_remove+0x24/0x48
[ 166.188588] mmc_sd_detect+0x120/0x1a4
[ 166.188600] mmc_rescan+0xf4/0x384
[ 166.188613] process_one_work+0x1c0/0x3d4
[ 166.188625] worker_thread+0x224/0x344
[ 166.188637] kthread+0x120/0x130
[ 166.188649] ret_from_fork+0x10/0x18
Change-Id: I5b79ed6daecd2f1517a985f68c0ce9389d38bcf5
Signed-off-by: Can Guo <cang@codeaurora.org>
On latest targets, gcc_sdc2_apps clock can support upto 208Mhz.
Update the driver for supporting 208Mhz.
Change-Id: I8c7bb6fffdb8404e0f9ce70883f43adafe864613
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
Discard request is no more overloaded with secure discard operation on
latest kernels. This change was introduced with commit "288dab8a3".
Earlier, it was issued as discard request.
We have a check for not to fetch a new DCMD request (flush/discard) if
mmc driver is already processing a DCMD request. But since here
secure-erase request which also a DCMD request getting issued as a
separate request (i.e., not as discard request), its getting issued and
mmc driver is trying to process another DCMD while a DCMD is already in
progress which can mess-up the command queue h/w & s/w state machines.
Adding explicit checks for secure-discard request besides discard
request in the cmdq request issueing path. This would ensure that
secure discard request won't get fetched while another DCMD is active.
Change-Id: Ie0e8fdd44fc6fb2e1bb3b7c595ef32b66128ac5f
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
The frequency comparison in clock scaling while setting the target
frequency was changed from current-frequency to target-frequency
against the requested frequency by the commit <3a6f149>
("mmc: core: Use new flag for suspending clk scaling").
When clock scaling is disabled and re-enabled, current-frequency
gets updated to max frequency but target-frequency remains at its
old value. Due to this clock is not scaling down and causing power
regressions.
To fix this issue, updating the target-frequency with the current-
frequency during clock scaling resume.
Change-Id: Ia033542724aac1f77f2dfbde0d9784e4c0657844
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
This is cmdq-error injection framework
to test cmdq error handling.
Change-Id: Ic44430b7097b3383bfcc51b752a7fec334f7838a
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
In case of Discard requests, currently the error handler was
not waking up the cmdq-thread which is waiting for completion
even of discard requests. This was happening when the error
requests is non-discard requests.
So this patch adds a way to wake up the issue thread waiting
on discard completion event
Change-Id: Ia663a2cf41004ce18a409b5a29f715e672c8a7ae
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
There can be case where controller may raise success for
rew queued requests while error for 1 of the requests.
In case of error we were handling the error but proceeding
and handling the requests which got completed by the controller.
As of now in cmdq-err handler mechanism, if any error occurs,
we re-queue all the requests back and request_queue.
So we need not call done for other requests which care completed
as this call lot of other contexts to run in parallel while error
handler is waiting to run.
Change-Id: I3e52253f0f0f893f8f668f6bb379af00eace5cf5
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
After err handler is run, the active_req should be 0,
so wakeup if anyone is waiting on queue_empty_wq.
Change-Id: I70e99dbda91cd493ec30041b98c031c5ad0ef240
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
This patch adds err_rwsem in mmc_cmdq_context_info,
which is used to synchronize between:
1. Error handler work <--> blk softirqs completion.
2. Error handler work <--> mmc_cmdq_thread issue ctx.
Error handler takes the writer lock and remaining
contextx which can run in parallel needs to rake read
semaphore.
To make sure that we release the read rwsem before
sleeping in case we expect error handler to run and
again check the state of the req. If the req is not
valid we return to the caller otherwise we proceed
to issue this req to controller.
Also note that error handler as of now is doing mmc_put_card
for all the requests pulled for which mmc_get_card is done.
So in case if the request was re-queued by cmdq-err handler,
then corresponding mmc_put_card is also already done.
So after we wake up and acquire the semaphore, we should
simply return to the caller.
TODO: Other IOCTL contxt checking
Change-Id: I63d27faa14c33af2f71a3416cd840f13764e47ae
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Change return type to int and req pointer which we need
in subsequent error handling patches.
Change-Id: Ibfbb9579ee955dbed95896246b65749f047978d3
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
There is no point in waiting infinitely for
wait_event_interruptible_timeout. Add a timeout logic in
wait_events in mmc_blk_cmdq_issue_rw_rq &
mmc_cmdq_halt_on_empty_queue.
Change-Id: I5cced42b8c0c6a20dc92394af0a0d5245ea9d729
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
[ Upstream commit e988867fd774d00aeaf5d3c332032bf5b97a4147 ]
Following up the device tree fixed in commits e78c637127ee ("ARM: dts:
rockchip: Fix DWMMC clocks") and ca9eee95a2de ("arm64: dts: rockchip:
Fix DWMMC clocks", 2018-02-15), avoid confusion by using the correct
property name in the debug output if clocks are not found.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Remove the workaround for SD card's SDR104 mode CRC error handling.
The SD card's SDR104 mode CRC errors issue was seen on some
SDCC controllers and the software reduced the SD card clock speed
as a workaround to avoid CRC errors. The latest SDCC controller
does not have this issue, so removing the workaround.
Change-Id: I3638500c83f7a6a2f9e4eae28a3179eea1d1fc89
Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
Move cmdq_dumpregs before we do any controller operation.
Otherwise in case of ADMA error we do not see SDHCI_INT_STATUS
register properly.
Change-Id: Ie9a38bc2e729a7f261cf05975210591ea2693dee
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
When SD card is removed from the slot, there could still be requests reside
in its queue's elevator. Usually, the driver shall call mmc_blk_remove to
clean up all the requests in its request queue, later VFS layer would call
mmc_blk_release to drain all the requests in the elevator to request queue
and clean up them once again. In some extreme scenarios, in which SD card
is repeatedly inserted and removed rapidly, mmc_blk_release may has no
chance to be called. If so, the requests reside in the elevator are left
not handled, thus user layer processes which are pending on the requests
may hang up.
This change fixes it by putting the request queue draining action into
mmc_blk_remove, so that the request queue and its elevator always got
cleaned up once the SD card is removed.
Change-Id: Id408fca2e038bf0bfecdbbc4002b7d0e2c8dc196
Signed-off-by: Can Guo <cang@codeaurora.org>
After SD card is removed, the driver would mark its queue DYING to try to
block further more requests from coming into the queue, then clean up its
queue's queuedata by setting it to NULL. However, there can still be new
requests come in right before the DYING mark is set after SD card is
removed. When one new request is allocated and initialized, the queuedata
would be accessed. If queuedata has been cleaned up already, NULL pointer
dereference would happen. This change fixes it by checking if queuedata is
NULL before accessing it, if yes, then bails out with error.
mmc0: card aaaa removed
Buffer I/O error on dev mmcblk0p1, logical block 1, lost async page write
Unable to handle kernel NULL pointer dereference at virtual address
00000000
Mem abort info:
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
user pgtable: 4k pages, 39-bit VAs, pgd = ffffffd7bbafa000
[0000000000000000] *pgd=0000000134331003, *pud=0000000134331003,
*pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
task: ffffffd77d193380 task.stack: ffffff8047e30000
pc : mmc_init_request+0x28/0x74
lr : alloc_request_size+0x4c/0x70
...
Process MediaScannerSer (pid: 4710, stack limit = 0xffffff8047e30000)
Call trace:
mmc_init_request+0x28/0x74
alloc_request_size+0x4c/0x70
mempool_alloc+0x104/0x184
get_request+0x324/0x75c
blk_queue_bio+0x154/0x398
generic_make_request+0xcc/0x228
submit_bio+0x13c/0x1d4
Change-Id: I1967392bd314fa49a723c08873c17bf229d33049
Signed-off-by: Can Guo <cang@codeaurora.org>
This change removes an identical code piece of allocating bounce buffer for
SDMA.
Change-Id: If8217645e81ee94e2cb2f569637cfce6b8f20186
Signed-off-by: Can Guo <cang@codeaurora.org>
commit 41591b38f5f8f78344954b68582b5f00e56ffe61 upstream.
On some SD cards over SPI, reading with the multiblock read command the last
sector will leave the card in a bad state.
Remove last sectors from the multiblock reading cmd.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
max_busy_timeout is used to decide whether R1B response should
be used or a R1 response should be used. This is also used to
decide what the discard size of mmc queue (registered with block
layer) can be set to. In order to keep both the features in place,
this change will allow for hosts to specify a larger discard size
while still specifying max_busy_timeout.
Change-Id: I4f92ecc8afe6614019da5f5e51c37ceca85af819
Signed-off-by: Ziqi Chen <ziqichen@codeaurora.org>
The mmc clock would get released when request processing is done.
In case of error, the request starter may retry the request.
In case of failed requests, clock is getting requested only once
but its getting released multiple times due to retries. This is
leading to unbalance in clock requests due to which clock gating
is misbehaving.
Update the condition so that clock won't get released in case of
request retries.
Change-Id: I1e0eba1afcfc012b9d840b777f768c7188c63c78
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Currently we disable clk scaling when card goes to suspend. This can
cause issue when we want to change the devfreq governor. Mmc devfreq
handler will ignore requests coming from devfreq framework,
causing unexpected behaviours.
Add a new flag for suspending clk scaling so that, any devfreq
request which comes while mmc is suspended will get queued and
then serviced as part of deferred scaling.
Change-Id: I640299724ece3390652abcec7eb3da3382f63f8a
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
Added a new debugfs entry to support for crashing
the system upon an error.
The default value of this debugfs entry is 'N'.
This need to set true('Y'), to crash upon an error.
Path to this debugfs entry to echo 'Y'/'N' is
/sys/kernel/debug/mmc0/crash_on_err for eMMC and
/sys/kernle/debug/mmc1/crash_on_err for SD card.
Change-Id: Ie7c79fb235b4882d73bb10193930418bd614ceaa
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
CRC errors are expected during tuning. MMC driver tries to fallback
to lower speed mode if it encounters consecutive CRC errors.
It should ignore CRC errors observed during tuning and shouldn't
try to fallback.
There is a check present for ignoring CRC errors for SD card
tuning commands. A new check has been added to ignore CRC errors
for eMMC tuning command as well.
Change-Id: Ic2bfa4f6a883fe30fdee85cf2e26779f3e906824
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
mmc_host is a virtual device and it doesn't have any pm ops and so during
pm registration of device, no_pm_callback gets set as true. The
mmc_host device is not runtime enabled as it is a virtual device and
mmc_host is the parent device of mmc_card. As the mmc_host is runtime
disabled, mmc_card can runtime suspend/resume without depending on
state of mmc_host during normal operations. During system suspend, the
direct_complete flag of mmc_host device gets set as it has no pm_ops.
When mmc_card successfully suspends, it clears the direct_complete flag
of its parent (mmc_host).
But in certain cases during dpm_suspend, an async error can occur after
suspend work for mmc_card is scheduled and before it gets executed. In
that case, mmc_card suspend work will not clear the direct_complete flag
of mmc_host. When mmc_host suspend comes after that of mmc_card,
it too will skip all actions.
But by this time, the mmc_host device has been added to device_suspended
list. So during resume, mmc_host resume will do dpm resume of mmc_host.
In dpm_resume, all devices which has direct_complete flag set will be
runtime_enabled. This is because, in dpm_suspend, any device with
direct_complete flag will be runtime_disabled. Thus, mmc_host which has
direct_complete flag set, will get runtime enabled during dpm_resume.
This is a problem in pm framework with direct_complete flag
(runtime enabling a device in resume when it was not runtime disabled
in suspend path).
Now that mmc_host device is runtime enabled, to runtime resume the
mmc_card, the pm framework will try to runtime resume the mmc_host
device as well and will fail. This prevents mmc_card from runtime
resuming after a runtime_suspend.
Fix this by adding a dummy suspend_prepare() fn for mmc_host. This
prevents the direct_complete flag of mmc_host device from getting set.
Change-Id: Ib739399027958d17e418e0240684b0b517a02941
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
[ Upstream commit 1b5190c2e74c47ebe4bcecf7a072358ad9f1feaa ]
For eMMC devices it is valid to only support 1.8V signaling. When
vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V
initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed
Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is
not available. This prevents the stack from even trying to use
3.3V signaling and avoids the above warning.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 127407e36f4fe3a1d5e8b9998b479956ce83a7dc ]
The stack assumes that SDHC controller which support SD3.0 (SDR104) do
support HS200. This is not the case for Tegra 3, which does support SD
3.0
but only supports eMMC spec 4.41.
Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not
support HS200.
Note that commit 156e14b126 ("mmc: sdhci: fix caps2 for HS200") added
the tie between SD3.0 (SDR104) and HS200. I don't think that this is
necessarly true. It is fully legitimate to support SD3.0 and not support
HS200. The quirk naming suggests something is broken in the controller,
but this is not the case: The controller simply does not support HS200.
Fixes: 7ad2ed1dfc ("mmc: tegra: enable UHS-I modes")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 5552d7ad596c3fea953f40fef74170ce0760c04d ]
SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses
when doing DMA. Make sure that the corresponding dma mask is correctly
configured.
Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings
for sdhci end up 48-bit wide. However, on these chips sdhci only use
40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device
generates transactions with clipped 40-bit addresses, thus smmu context
faults are triggered. Setting up the correct dma mask fixes this
situation.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Loic Poulain