| Age | Commit message (Collapse) | Author |
|---|
|
|
|
[ Upstream commit c077dc5e0620508a29497dac63a2822324ece52a ]
First, it should be noted that the CQE timeout (60 seconds) is substantial
so a CQE request that times out is really stuck, and the race between
timeout and completion is extremely unlikely. Nevertheless this patch
fixes an issue with it.
Commit ad73d6feadbd7b ("mmc: complete requests from ->timeout")
preserved the existing functionality, to complete the request.
However that had only been necessary because the block layer
timeout handler had been marking the request to prevent it from being
completed normally. That restriction was removed at the same time, the
result being that a request that has gone will have been completed anyway.
That is, the completion was unnecessary.
At the time, the unnecessary completion was harmless because the block
layer would ignore it, although that changed in kernel v5.0.
Note for stable, this patch will not apply cleanly without patch "mmc:
core: Fix recursive locking issue in CQE recovery path"
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: ad73d6feadbd7b ("mmc: complete requests from ->timeout")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200508062227.23144-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 39a22f73744d5baee30b5f134ae2e30b668b66ed ]
Consider the following stack trace
-001|raw_spin_lock_irqsave
-002|mmc_blk_cqe_complete_rq
-003|__blk_mq_complete_request(inline)
-003|blk_mq_complete_request(rq)
-004|mmc_cqe_timed_out(inline)
-004|mmc_mq_timed_out
mmc_mq_timed_out acquires the queue_lock for the first
time. The mmc_blk_cqe_complete_rq function also tries to acquire
the same queue lock resulting in recursive locking where the task
is spinning for the same lock which it has already acquired leading
to watchdog bark.
Fix this issue with the lock only for the required critical section.
Cc: <stable@vger.kernel.org>
Fixes: 1e8e55b67030 ("mmc: block: Add CQE support")
Suggested-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1588868135-31783-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e6bfb1bf00852b55f4c771f47ae67004c04d3c87 ]
In the request completion path with CQE, request type is being checked
after the request is getting completed. This is resulting in returning
the wrong request type and leading to the IO hang issue.
ASYNC request type is getting returned for DCMD type requests.
Because of this mismatch, mq->cqe_busy flag is never getting cleared
and the driver is not invoking blk_mq_hw_run_queue. So requests are not
getting dispatched to the LLD from the block layer.
All these eventually leading to IO hang issues.
So, get the request type before completing the request.
Cc: <stable@vger.kernel.org>
Fixes: 1e8e55b67030 ("mmc: block: Add CQE support")
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1588775643-18037-2-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b56ff195c317ad28c05d354aeecbb9995b8e08c1 ]
Need to clear some bits in a vendor-defined register after reboot from
Windows 10.
Fixes: e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support")
Reported-by: Grzegorz Kowal <custos.mentis@gmail.com>
Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Grzegorz Kowal <custos.mentis@gmail.com>
Link: https://lore.kernel.org/r/20200504063957.6638-1-benchuanggli@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7c277dd2b0ff6a16f1732a66c2c52a29f067163e ]
If devm_request_threaded_irq() fails, the allocated struct mmc_host needs
to be freed via calling mmc_free_host(), so let's do that.
Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200426202355.43055-1-christophe.jaillet@wanadoo.fr
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 282ede76e47048eebc8ce5324b412890f0ec0a69 ]
The kernel prints a message similar to
"[ 28.881959] do_IRQ: 5.36 No irq handler for vector"
when GL975x resumes from suspend. Implement a resume callback to fix this.
Fixes: 31e43f31890c ("mmc: sdhci-pci-gli: Enable MSI interrupt for GL975x")
Co-developed-by: Renius Chen <renius.chen@genesyslogic.com.tw>
Signed-off-by: Renius Chen <renius.chen@genesyslogic.com.tw>
Tested-by: Dave Flogeras <dflogeras2@gmail.com>
Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw>
Tested-by: Vineeth Pillai <vineethrp@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200427103048.20785-1-benchuanggli@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
[Samuel Zou: Make sdhci_pci_gli_resume() static]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 45a3fe3bf93b7cfeddc28ef7386555e05dc57f06 ]
The AMD eMMC 5.0 controller does not support 64 bit DMA.
Fixes: 34597a3f60b1 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400")
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Link: https://marc.info/?l=linux-mmc&m=158879884514552&w=2
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200508165344.1.Id5bb8b1ae7ea576f26f9d91c761df7ccffbf58c5@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
|
|
commit ddca1092c4324c89cf692b5efe655aa251864b51 upstream.
The recent commit 0d84c3e6a5b2 ("mmc: core: Convert to
mmc_poll_for_busy() for erase/trim/discard") makes use of the
->card_busy() op for SD cards. This uncovered that the ->card_busy() op
in the Meson SDIO driver was never working right:
while polling the busy status with ->card_busy()
meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC
register values 0x1f001f10 or 0x1f003f10. This translates to "three out
of four DAT lines are HIGH" and "all four DAT lines are HIGH", which
is interpreted as "the card is busy".
It turns out that no situation can be observed where all four DAT lines
are LOW, meaning the card is not busy anymore. Upon further research the
3.10 vendor driver for this controller does not implement the
->card_busy() op.
Remove the ->card_busy() op from the meson-mx-sdio driver since it is
not working. At the time of writing this patch it is not clear what's
needed to make the ->card_busy() implementation work with this specific
controller hardware. For all use-cases which have previously worked the
MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have
a ->card_busy() op anymore.
Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb upstream.
The Meson SDIO controller uses the DAT0 lane for hardware busy
detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes
the following error observed with Linux 5.7 (pre-rc-1):
mmc1: Card stuck being busy! __mmc_poll_for_busy
blk_update_request: I/O error, dev mmcblk1, sector 17111080 op
0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0
Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200416183513.993763-2-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9d8cb58691f85cef687512262acb2c7109ee4868 upstream.
MSM sd host controller is capable of HW busy detection of device busy
signaling over DAT0 line. And it requires the R1B response for commands
that have this response associated with them.
So set the below two host capabilities for qcom SDHC.
- MMC_CAP_WAIT_WHILE_BUSY
- MMC_CAP_NEED_RSP_BUSY
Recent development of the mmc core in regards to this, revealed this as
being a potential bug, hence the stable tag.
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream.
BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
even though the eMMC may not support it, on the assumption that the kernel
will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.
This is done to avoid changing the value for different boards.
Putting aside the merits of this approach, it is clear the eMMC's mask
of supported driver strengths is more reliable than the value provided
by BIOS. Add validation accordingly.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream.
For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable
When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.
Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.
This patch fixes this particular problem on Turris MOX.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: stable@vger.kernel.org # v4.16+
Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b1ac62a7ac386d76968af5f374a4a7a82a35fe31 upstream.
Open-coding a timeout loop invariably leads to errors with handling
the timeout properly in one corner case or another. In the case of
cqhci we might report "CQE stuck on" even if it wasn't stuck on.
You'd just need this sequence of events to happen in cqhci_off():
1. Call ktime_get().
2. Something happens to interrupt the CPU for > 100 us (context switch
or interrupt).
3. Check time and; set "timed_out" to true since > 100 us.
4. Read CQHCI_CTL.
5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break.
6. Since "timed_out" is true, falsely print the error message.
Rather than fixing the polling loop, use readx_poll_timeout() like
many people do. This has been time tested to handle the corner cases.
Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d030c6af8e0@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
v5.4/standard/preempt-rt/cn96xx
|
|
[ Upstream commit 7d76ed77cfbd39468ae58d419f537d35ca892d83 ]
Refactor sdhci_set_timeout() such that platform drivers can do some
functionality in a set_timeout() callback and then call
__sdhci_set_timeout() to complete the operation.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-7-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7907ebe741a7f14ed12889ebe770438a4ff47613 ]
Export sdhci_set_timeout_irq() so that it is accessible from platform drivers.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200116105154.7685-6-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 2aa3d826adb578b26629a79b775a552cfe3fedf7 upstream.
This patch is to fix operating in esdhc_reset() for different
controller versions, and to add bus-width restoring after data
reset for eSDHC (verdor version <= 2.2).
Also add annotation for understanding.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200108040713.38888-1-yangbo.lu@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
commit 2e2f7dd69ae3760cfbcef1fb93becbbc6b65f8ba from
git@git.assembla.com:cavium/WindRiver.linux.git
The logic was inverted. This also increases the maximum speed for
CNF95XX and LOKI and adds another reset after calibration to match
U-Boot.
Change-Id: If51d04b89e9842490ad0263e73bb0504f6c0b5be
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/23940
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
|
|
commit 5e26844e1f4841619be8b02e5d1e7c47d8583784 from
git@git.assembla.com:cavium/WindRiver.linux.git
Change-Id: I980bfde7db3fec13ae73d33964215bbf377e7a37
Signed-off-by: Chandrakala Chavva <Chandrakala.Chavva@cavium.com>
Reviewed-on: https://sj1git1.cavium.com/24021
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Reviewed-by: Aaron Williams <awilliams@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/24031
Reviewed-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Reviewed-on: https://sj1git1.cavium.com/24083
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
|
|
commit 1b161f6c43bb06efc51b9714bd1afee3e1a73b4a from
git@git.assembla.com:cavium/WindRiver.linux.git
Instead of hard-coding the code to look for various SoCs and versions
it is better to use flags. This makes it much easier to put all of
the flag initialization in one place, in the probe function, as well
as make it easier to add noew SoCs witouth having to make
modifications all over the place. This patch also moves the
hardware maximum speed based on chip revision, etc. to
the probe function as well.
This patch also cleans up the timing support for HS200 and HS400 and
fixes a rounding error when calculating the tap value.
This patch also allows the device tree to override the default delays
for HS200 and HS400 modes.
This also adds support for the CNF95XXMM and LOKI SoCs.
Change-Id: Ia3457d56dd4cb38a3fb33bdb08d4e5d611f5c314
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/23690
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
|
|
commit e7d87815295b55b5a3d602e78ec6ed62bbf0f230 from
git@git.assembla.com:cavium/WindRiver.linux.git
Need to enable and disable emmc clock when updating timing
parameters in T96 C0.
Change-Id: I8d34918b961d9b466eb2b7465a6fb2610dd6acdc
Signed-off-by: Chandrakala Chavva <Chandrakala.Chavva@cavium.com>
Reviewed-on: https://sj1git1.cavium.com/21284
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/23280
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
|
|
commit b957ca320574e2ae0eb1da67d7f77979d01f1477 from
git@git.assembla.com:cavium/WindRiver.linux.git
Tuning the data input is required for reliable HS400 operation on the
Octeon TX2 SoCs. Often the sweet spot for HS200 mode does not work
in HS400 mode and the eMMC spec provides no method of performing
tuning.
Instead of using the eMMC's tuning functionality this relies instead
on a block specified in the device tree to contain a specific pattern
designed for worst-case signalling. If the block does not contain the
correct data it will be overwritten with the tuning pattern. The device
tree must make sure that the chosen block does not interfere with any
partitioning or filesystems. Generally block 1 is used which is fine
as long as EFI partitioning is not used.
The tuning code repeatedly reads this block with every tap value then
chooses the midpoint of the longest successful run like how tuning is
performed in HS200 mode for data in.
This tuning method is ignored if the appropriate device tree entry is
missing, instead falling back on the HS200 tuning.
Change-Id: Ic3ddc17fbf023e6a5b2a951e2303daad28d95267
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/23281
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
|
|
[ Upstream commit d2f8bfa4bff5028bc40ed56b4497c32e05b0178f ]
It has turned out that the sdhci-tegra controller requires the R1B response,
for commands that has this response associated with them. So, converting
from an R1B to an R1 response for a CMD6 for example, leads to problems
with the HW busy detection support.
Fix this by informing the mmc core about the requirement, via setting the
host cap, MMC_CAP_NEED_RSP_BUSY.
Reported-by: Bitan Biswas <bbiswas@nvidia.com>
Reported-by: Peter Geis <pgwipeout@gmail.com>
Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Tested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Tested-By: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 055e04830d4544c57f2a5192a26c9e25915c29c0 ]
It has turned out that the sdhci-omap controller requires the R1B response,
for commands that has this response associated with them. So, converting
from an R1B to an R1 response for a CMD6 for example, leads to problems
with the HW busy detection support.
Fix this by informing the mmc core about the requirement, via setting the
host cap, MMC_CAP_NEED_RSP_BUSY.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Anders Roxell <anders.roxell@linaro.org>
Reported-by: Faiz Abbas <faiz_abbas@ti.com>
Cc: <stable@vger.kernel.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Tested-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 18d200460cd73636d4f20674085c39e32b4e0097 ]
The busy timeout for the CMD5 to put the eMMC into sleep state, is specific
to the card. Potentially the timeout may exceed the host->max_busy_timeout.
If that becomes the case, mmc_sleep() converts from using an R1B response
to an R1 response, as to prevent the host from doing HW busy detection.
However, it has turned out that some hosts requires an R1B response no
matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note
that, if the R1B gets enforced, the host becomes fully responsible of
managing the needed busy timeout, in one way or the other.
Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200311092036.16084-1-ulf.hansson@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 43cc64e5221cc6741252b64bc4531dd1eefb733d ]
The busy timeout that is computed for each erase/trim/discard operation,
can become quite long and may thus exceed the host->max_busy_timeout. If
that becomes the case, mmc_do_erase() converts from using an R1B response
to an R1 response, as to prevent the host from doing HW busy detection.
However, it has turned out that some hosts requires an R1B response no
matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note
that, if the R1B gets enforced, the host becomes fully responsible of
managing the needed busy timeout, in one way or the other.
Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Tested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Tested-by: Faiz Abbas <faiz_abbas@ti.com>
Tested-By: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1292e3efb149ee21d8d33d725eeed4e6b1ade963 ]
It has turned out that some host controllers can't use R1B for CMD6 and
other commands that have R1B associated with them. Therefore invent a new
host cap, MMC_CAP_NEED_RSP_BUSY to let them specify this.
In __mmc_switch(), let's check the flag and use it to prevent R1B responses
from being converted into R1. Note that, this also means that the host are
on its own, when it comes to manage the busy timeout.
Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Tested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Tested-by: Faiz Abbas <faiz_abbas@ti.com>
Tested-By: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
|
|
commit 18b587b45c13bb6a07ed0edac15f06892593d07a upstream.
The SDHCI_PRESET_FOR_* registers are not set for the UniPhier platform
integration. (They are all read as zeros).
Set the SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk flag. Otherwise, the
High Speed DDR mode on the eMMC controller (MMC_TIMING_MMC_DDR52)
would not work.
I split the platform data to give no impact to other platforms,
although the UniPhier platform is currently only the upstream user
of this IP.
The SDHCI_QUIRK2_PRESET_VALUE_BROKEN flag is set if the compatible
string matches to "socionext,uniphier-sd4hc".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200312104257.21017-1-yamada.masahiro@socionext.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 53dd0a7cd65edc83b0c243d1c08377c8b876b2ee upstream.
SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least
SAMA5D27 doesn't). Fix this by forcing card-detect in the module
if module-controlled CD is not used.
Fixed commit addresses the problem only for non-removable cards. This
amends it to also cover gpio-cd case.
Cc: stable@vger.kernel.org
Fixes: 7a1e3f143176 ("mmc: sdhci-of-at91: force card detect value for non removable devices")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4686392c32361c97e8434adf9cc77ad7991bfa81 upstream.
The TX/RX register should not be treated the same way to allow for better
support of tuning. Fix this by using a default initial value for TX.
Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com
[Ulf: Updated changelog]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
commit 31e43f31890ca6e909b27dcb539252b46aa465da upstream.
Enable MSI interrupt for GL9750/GL9755. Some platforms
do not support PCI INTx and devices can not work without
interrupt. Like messages below:
[ 4.487132] sdhci-pci 0000:01:00.0: SDHCI controller found [17a0:9755] (rev 0)
[ 4.487198] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.PBR2._PRT.APS2], AE_NOT_FOUND (20190816/psargs-330)
[ 4.487397] ACPI Error: Aborting method \_SB.PCI0.PBR2._PRT due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
[ 4.487707] pcieport 0000:00:01.3: can't derive routing for PCI INT A
[ 4.487709] sdhci-pci 0000:01:00.0: PCI INT A: no GSI
Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw>
Tested-by: Raul E Rangel <rrangel@chromium.org>
Fixes: e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200219092900.9151-1-benchuanggli@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 272fff001dc3cbf7e4b78c94c950d27b3e9f1206 from
git@git.assembla.com:cavium/WindRiver.linux.git
Speed is limited to 150MHz for C0 in ddr modes.
Change-Id: I03206fb354be207c4eef8095cc736e99dfb89ae2
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/20292
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/23279
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
|
|
|
|
The IRQF_NO_THREAD is added by a Marvell SDK patch 238e623e1024 ("mmc:
cavium: fix swiotlb buffer is full") in order to get back some of the
performance loss. But in some cases (such as rt kernel), we do need the
capability to thread irq handler. Otherwise we would get warnings because
the normal spin lock is used in the irq handler. So drop this constraint.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
In commit 6f30754ec148 ("mmc: cavium: forbid unaligned DMA"), the codes
are added to check the unaligned dma request. But at that time,
we still don't do the dma map for the scatterlist yet. So it is
meaningless to check the dma address. So drop of it.
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit 837c49d6448c672754cf5cc15eec4b58e9e31167 from
git@git.assembla.com:cavium/WindRiver.linux.git
There's no need to re-run the calibration,
it's for characterizing chip, not tracking variation
due to voltage/temperature drift, which execute_tuning
handles quite well with finer granularity
Also adds/clarifies debug logs
Change-Id: I46d5d4c30d126bfc6ba00c49cfd81fb143948f20
Signed-off-by: Peter Swain <pswain@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/14550
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Reviewed-on: https://sj1git1.cavium.com/16106
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit 21b9256b54cb02e0dc068f19e7c2ef0f7054f673 from
git@git.assembla.com:cavium/WindRiver.linux.git
Uses the calibrated tap-delay reading to determine data_out
& cmd_out parameters. To do the calibration, certain HW sequence
has been employed for the reliable operation of calibration.
A scale factor is added to simplify testing, starts at 100%
and can be tweaked via modparam. A switch is added to force
the constant timing params, for comparison with old code.
Forced clock is used for cnf95. Also a redundant read has
been removed.
Change-Id: I38b488afadee8f66f3cdde824464b24badaf8234
Signed-off-by: Peter Swain <pswain@marvell.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/14926
Reviewed-by: Peter Swain <pswain@cavium.com>
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit 9e1b3d36e427dc975717245155a8de72f6bb8916 from
git@git.assembla.com:cavium/WindRiver.linux.git
An earlier patch dropped/reacquired bus lock around
hs400 tuning calls. This is unnecessary and deadlock
prone, and was a relic of a hunt for an earlier issue,
since resolved.
With this change, all 3 mmc-slots can be concurrently
active even as some undergo hs200-retuning, without
deadlock.
Change-Id: I42089ea265cf61d088debc3dade2efbffb7f9c46
Signed-off-by: Peter Swain <pswain@marvell.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/14925
Reviewed-by: Peter Swain <pswain@cavium.com>
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit d7c6388926a6f04938649b1e11dad4a31f5b4ab0 from
git@git.assembla.com:cavium/WindRiver.linux.git
Octeon/OcteonTX MMC supports up to 3 mmc slots, but any
level-shifting to accommodate different signal voltages is
done by external hardware, under control of an optional
vqmmc regulator object, typically controlled by gpio.
See Documentation/devicetree/bindings/mmc/cavium-mmc.txt
for a detailed explanation of device-tree control of MMC
signals via GPIO at reset and slot-switching time.
If any mmc-slots have a vqmmc-supply property,
take it as a warning that we must switch carefully between
slots (unless they have the same vqmmc object), tri-stating
MMC signals to avoid any transient states as level-shifters
are enabled/disabled, by zeroing MIO_EMM_CFG[bus_id].
During this vqmmc-switching, care must be taken to never
completely zero MIO_EMM_CFG, as this resets the host controller,
so the "phantom" slot3 is enabled during the switch.
There's no need to list vqmmc property if all the mmc-slots
on a board run at same signal voltage, and have same width.
In this case the old behavior, enabling all probed slots in
MIO_EMM_CFG, allows faster slot-switching.
Change-Id: I6061d88513920043a3dcef58684d8dcd85ba3cc3
Signed-off-by: Peter Swain <pswain@cavium.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/14924
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit 6727f8cd954c4e320e541bf500b7afaa54dd3a0c from
git@git.assembla.com:cavium/WindRiver.linux.git
Code motion to allow the upcoming vqmmc-switching commit
to fit nicely. No change to actual operation, except to
correct several IS_ERR() to IS_ERR_OR_NULL() which
would have segfaulted in the NULL case.
The do_switch() & cvm_mmc_switch_to() functions were
becoming unwieldly, and about to become more so, when
vqmmc-switching is introduced.
- mode_switch() does the low level EMM_MMC_SWITCH change
- pre_switch() prepares for a slot switch, notes if it's
needed
- post_switch() performs final actions, if a slot switch
was needed
Some code has moved from cvm_mmc_switch_to() to do_switch()
and now happens on every invocation, including probe-time,
but will have no effect on post-probe runtime
Change-Id: If21c93ea11f18bcffe79796cc7ff29e45bdf3e96
Signed-off-by: Peter Swain <pswain@cavium.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/14923
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit 88110c97db90266fdf5b1563bd5c6bde04cda7b6 from
git@git.assembla.com:cavium/WindRiver.linux.git
Cn95xx needs command and data out values to be fixed at 10
based on the HW recommendation.
Change-Id: Ib1a343a1fcce8645db4bc51ea5d534c2d899c181
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/10211
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/10655
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit f71a73040c9c582b4e3d87ee543a80a71c64919b from
git@git.assembla.com:cavium/WindRiver.linux.git
cmd_out/data_out taps are fixed, depending on ios.timing
cmd_in/data_in taps are probed, as before
modparam tune=N adjusts tuning to (last_good_tap - N)
Default value of 2 is recommended,
old behavior can be restored with tune=0
Use CMD21 tuning where applicable
Move some _host properties to _slot, because they're actually
related to the current slot. This avoids mis-associating IRQ
events with the wrong conversation.
Optionally walk clock rate down by 12.5% on each tuning failure
Paranoid timing on DMA teardown: watch _DEBUG and DMA_INT[DONE]
to avoid attributing the final teardown event to wrong request
Change-Id: I46499cd96ed5ae41e57b41525eb7f86f986001de
Signed-off-by: Peter Swain <pswain@marvell.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/8552
Reviewed-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit eaf02b26770cf9180a5b1fbd9f141df3b75fe2b4 from
git@git.assembla.com:cavium/WindRiver.linux.git
Rounding of the mmc clock divisor was incorrect,
allowing overclocking. We still keep clk_lo/_hi identical,
using (n, n+1) for intermediate frequencies is unproven.
Now explicitly check for overclocking.
Adjusting system clock, from which mmc clock is derived,
may allow higher frequencies when the next-smaller
divisor would take mmc clock past device maximum
Change-Id: I464fe91afa94a202e9db2682f52f29dfe1fa9aa5
Signed-off-by: Peter Swain <pswain@cavium.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/8551
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit 43cd07f68ff2ed82ccb6328262c4c44bf5adbbd5 from
git@git.assembla.com:cavium/WindRiver.linux.git
When using iommu.passthrough=1, the maximum dma size is
limited by swiotlb size. OcteonTX platforms do not need
swiotlb, but iommu-passthru (a useful development option)
forces it. So adapt the size cap from Yoshihiro Shimoda's
commit e90e8da72ad6 ("mmc: tmio: fix swiotlb buffer is full").
Passthru reduces peak i/o rate on large requests, but could
improve random filesystem performance slightly on some loads
(hdparm -t down ~5%, mke2fs up ~15%)
To get back some of that performance loss, the irqs are
specified as non-threaded, as the persistent state is all
contained in host->current_req, so no thread context needed.
Signed-off-by: Peter Swain <pswain@marvell.com>
Change-Id: I256729f8ff0ef194e6c57dda000c7341cac446f4
Reviewed-on: https://sj1git1.cavium.com/3944
Reviewed-by: Chandrakala Chavva <Chandrakala.Chavva@cavium.com>
Reviewed-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/8550
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
|
commit 01d87e93c8b7184082a23a8de6438d7711a64d2b from
git@git.assembla.com:cavium/WindRiver.linux.git
Previous code relied on particular state left by u-boot,
or a previous _probe attempt aborted with EPROBE_DEFER,
else it would program a clock-divisor of zero and hang MMC.
Do not cache emm_switch setting if it has clock divisor zero.
Do not use frequency params before they have been extracted
from devtree.
Do enforce lower frequency bound (400KHz) from mmc/core.
Change-Id: I2d19084d1ab57d0f98e2ce1ffcd6fb918228f53c
Signed-off-by: Peter Swain <pswain@marvell.com>
Signed-off-by: Sujeet Baranwal <sbaranwal@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/8549
Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Signed-off-by: Xiaotao Yin <xiaotao.yin@windriver.com>
|
Bruce Ashfield
Adrian Hunter
Sarthak Garg
Veerabhadrarao Badiganti
Ben Chuang
Christophe JAILLET
Raul E Rangel
Martin Blumenstingl
Marek Behún
Douglas Anderson
Faiz Abbas
Yangbo Lu
Aaron Williams
Chandrakala Chavva
Ulf Hansson
Masahiro Yamada
Michał Mirosław
Ricky Wu
Sujeet Baranwal
Kevin Hao
Kevin Hao
Peter Swain
Peter Swain