sdhci-msm can support auto cmd12.
So enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-3-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When use one SDIO wifi which enable the runtime PM feature on i.MX6SX,
we meet system hang. This hang happened during the usdhc runtime resume,
in sdhci_init(), when call the sdhci_set_default_irqs. One interrupt
(SDHCI_INT_CARD_INT) triggered just after the host->ier update and before
the write of register SDHCI_SIGNAL_ENABLE. So in sdhci_irq, it will skip
the call of sdio_signal_irq() because current host->ier do not set the
SDHCI_INT_CARD_INT. So this SDIO wifi interrupt always keep triggered,
let the system stuck in irq handle, can't response any other thread.
This patch add spin lock for the sdhci_set_default_irqs to fix this issue.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1586941255-9237-1-git-send-email-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Implement the request_atomic() API for nonremovable cards, that means
we can submit next request in the irq hard handler context to reduce
latency.
Moreover factor out the AUTO CMD23 checking into a separate function
to reduce duplicate code.
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/60142fe6c6c1dbba2696e775564ae2166786f0bc.1586744073.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Implement the request_atomic() ops for the sdhci driver to process
one request in the atomic context if the card is nonremovable.
Moreover, we should return BUSY flag if controller has not released
the inhibit bits to allow HSQ trying to send request again in non-atomic
context.
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/9ed34afa9fb42e0c234065cac5401d7826942b55.1586744073.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SD host controller can process one request in the atomic context if
the card is nonremovable, which means we can submit next request in the
irq hard handler when using the MMC host software queue to reduce the
latency. Thus this patch adds a new API request_atomic() for the host
controller, as well as adding support for host software queue to submit
a request by the new request_atomic() API.
Moreover there is an unusual case that the card is busy when trying to
send a command, and we can not polling the card status in interrupt
context by using request_atomic() to dispatch requests. Thus we should
queue a work to try again in the non-atomic context in case the host
releases the busy signal later.
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/a344e27e506cb2329073cbd5cf65e15cc3cbeba9.1586744073.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Spending time under spinlock increases IRQ latencies and also
response times because preemption is disabled.
sdhci_send_command() waits up to 10 ms under spinlock for inhibit bits
to clear. In general inhibit bits will not be set, but there may be
corner cases, especially in the face of errors, where waiting helps.
There might also be dysfunctional hardware that needs the waiting. So
retain the legacy behaviour but do not wait for inhibit bits while under
spinlock. Instead adjust the logic to enable waiting while not under
spinlock. That is mostly straight forward, but in the interrupt handler
it requires deferring an "inhibited" command to the IRQ thread where
sleeping is allowed.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-6-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In preparation for further changes, tidy sdhci_request() a bit.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-5-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci_finish_data() is defined before it is referenced, so forward
declaration is not necessary.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-4-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci_send_command() has not been used outside of sdhci.c for many
years. Stop exporting it.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-3-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add 2 helper functions to make the use of the auto-CMD23 flag more
readable.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200412090349.1607-2-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use the well defined HIGH_SPEED_BUS_SPEED macro in mmc_sd_switch_hs()
to make code more readable.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200410145643.630b0731@xhacker.debian
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Instead of reimplementing the logic in mmc_regulator_set_vqmmc(), use the
mmc code function directly.
This also allows us to fix a related issue on STM32MP1, when a voltage
switch of 1.8V is done for the eMMC, but the current level is already set
to 1.8V. More precisely, in this scenario the call to the
->post_sig_volt_switch() hangs, indefinitely waiting for the voltage switch
to complete. Fix this problem by checking if mmc_regulator_set_vqmmc()
returned 1 and then skip invoking the callback.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20200416163649.336967-3-marex@denx.de
[Ulf: Updated the commit message]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adjust mmc_regulator_set_vqmmc() to return 1 if the voltage switch was
skipped because the regulator voltage was already correct. This allows
drivers to detect such condition and possibly skip various voltage
switching extras.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20200416163649.336967-2-marex@denx.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Patch all drivers which use mmc_regulator_set_vqmmc() and prepare them for
the fact that mmc_regulator_set_vqmmc() can return a value > 0, which would
happen if the signal voltage switch did NOT happen, because the voltage was
already set correctly.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20200416163649.336967-1-marex@denx.de
[Ulf: Re-worked/simplified the code a bit]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Clang warns:
drivers/mmc/host/sdhci-of-arasan.c:784:9: warning: variable 'ret' is
uninitialized when used here [-Wuninitialized]
return ret;
^~~
drivers/mmc/host/sdhci-of-arasan.c:738:9: note: initialize the variable
'ret' to silence this warning
int ret;
^
= 0
drivers/mmc/host/sdhci-of-arasan.c:860:9: warning: variable 'ret' is
uninitialized when used here [-Wuninitialized]
return ret;
^~~
drivers/mmc/host/sdhci-of-arasan.c:810:9: note: initialize the variable
'ret' to silence this warning
int ret;
^
= 0
2 warnings generated.
This looks like a copy paste error. Neither function has handling that
needs ret so just remove it and return 0 directly.
Link: https://github.com/ClangBuiltLinux/linux/issues/996
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20200416182402.16858-1-natechancellor@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
No need to call platform_get_resource twice when we still have the
pointer from before. Also, use '%pa' for a resource_size_t pointer.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/20200408142252.21958-1-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
When tuning HS400, if all TAPS are good, we can utilize the SMPCMP
register to select the optimal TAP. For that, we populate a second
bitmap with SMPCMP results and query it in case the regular bitmap is
full (= all good).
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20200408094638.10375-4-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The comment and the define about how TAPs are selected were confusing to
me because the good TAP was only valid if it was bigger than a *_MAX_*
value. Rename the define and adapt the comment to what really happens.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20200408094638.10375-3-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To select the best TAP, we need to find the longest stream of set bits
in a bit field. There is now a helper function for bitmaps which
iterates over all region of set bits. Using it makes the code much more
concise and easier to understand. Double so, because we need to handle
two bitmaps in the near future. Remove a superfluous comment while here.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20200408094638.10375-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use FIELD_GET and FIELD_PREP to get access to the register fields. Delete
the shift macros and use GENMASK() for the touched macros.
Note that, this has the side-effect of changing the constants to 64-bit on
64-bit platforms.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200408072105.422-2-yamada.masahiro@socionext.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the SDHCI specification, the Capabilities Register (Offset 0x40h)
is the 64-bit width register, but in Linux, it is represented as two
registers, SDHCI_CAPABILITIES and SDHCI_CAPABILITIES_1 so that drivers
can use 32-bit register accessors.
The upper 32-bit field is associated with SDHCI_CAPABILITIES_1.
Move the definition of SDHCI_CAPABILITIES_1 to the correct place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200408072105.422-1-yamada.masahiro@socionext.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SDHCI clock operations are platform specific. So it better to define
them separately for particular platform. This will prevent multiple
if..else conditions and will make it easy for user to add their own
clock operations handlers.
Signed-off-by: Manish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-6-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Existing driver code has the platform specific structures scattered
throughout the driver code. Rearrange the platform specific data
structures for more modularity and readability. This will help in adding
new static functions with more ease.
Signed-off-by: Manish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-5-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is 'struct sdhci_arasan_data' but also
'struct sdhci_arasan_of_data sdhci_arasan_data'. Rename the latter to
avoid confusion with the name of the struct.
Reported-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Manish Narani <manish.narani@xilinx.com>
Link: https://lore.kernel.org/r/1586195015-128992-4-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support to set tap delays for Xilinx Versal SD controller. The tap
delay registers have moved to SD controller space in Versal. Make the
changes accordingly.
Signed-off-by: Manish Narani <manish.narani@xilinx.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1586195015-128992-3-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The in-parameter struct mmc_data *data is never NULL, because the caller
always provides a valid pointer. Hence drop the corresponding redundant
code.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200407143903.22477-1-ulf.hansson@linaro.org
The in-parameter "wait" is always set to 0 by the caller, hence just drop
it and its corresponding code.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Manuel Lauss <manuel.lauss@gmail.com>
Link: https://lore.kernel.org/r/20200406114337.8802-1-ulf.hansson@linaro.org
The MMC_CAP_ERASE and MMC_CAP_CMD23 flags are already being set in the
common sdhci_setup_host(). This makes it redundant to set them for
sdhci-sprd, so let's drop them.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200406113724.8504-1-ulf.hansson@linaro.org
Instead of explicitly checking for SDIO specific requests and then
returning an error code, let's set MMC_CAP2_NO_SDIO to tell the mmc core to
prevent them altogether.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200401145531.23247-1-ulf.hansson@linaro.org
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 ad73d6fead ("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: ad73d6fead ("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>
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: 1e8e55b670 ("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>
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: 1e8e55b670 ("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>
Need to clear some bits in a vendor-defined register after reboot from
Windows 10.
Fixes: e51df6ce66 ("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>
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: 31e43f3189 ("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>
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: 51ced59cc0 ("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>
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: 8d876bf472 ("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>
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>
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: a4080225f5 ("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>
The recent commit 0d84c3e6a5 ("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: ed80a13bb4 ("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>
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: ed80a13bb4 ("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>
Fix the following sparse warning:
drivers/mmc/core/mmc_ops.c:881:5: warning: symbol 'mmc_interrupt_hpi'
was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Fixes: 55c2b8b9a3 ("mmc: core: Re-work the code for eMMC sanitize")
Link: https://lore.kernel.org/r/20200403034727.11879-1-yanaijie@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
- Add support for host software queue for (e)MMC/SD
- Throttle polling rate for CMD6
- Update CMD13 busy condition check for CMD6 commands
- Improve busy detect polling for erase/trim/discard/HPI
- Fixup support for HW busy detection for HPI commands
- Re-work and improve support for eMMC sanitize commands
MMC host:
- mmci: Add support for sdmmc variant revision 2.0
- mmci_sdmmc: Improve support for busyend detection
- mmci_sdmmc: Fixup support for signal voltage switch
- mmci_sdmmc: Add support for tuning with delay block
- mtk-sd: Fix another SDIO irq issue
- sdhci: Disable native card detect when GPIO based type exist
- sdhci: Add option to defer request completion
- sdhci_am654: Add support to set a tap value per speed mode
- sdhci-esdhc-imx: Add support for i.MX8MM based variant
- sdhci-esdhc-imx: Fixup support for standard tuning on i.MX8 usdhc
- sdhci-esdhc-imx: Optimize for strobe/clock dll settings
- sdhci-esdhc-imx: Fixup support for system and runtime suspend/resume
- sdhci-iproc: Update regulator/bus-voltage management for bcm2711
- sdhci-msm: Prevent clock gating with PWRSAVE_DLL on broken variants
- sdhci-msm: Fix management of CQE during SDHCI reset
- sdhci-of-arasan: Add support for auto tuning on ZynqMP based platforms
- sdhci-omap: Add support for system suspend/resume
- sdhci-sprd: Add support for HW busy detection
- sdhci-sprd: Enable support host software queue
- sdhci-tegra: Add support for HW busy detection
- tmio/renesas_sdhi: Enforce retune after runtime suspend
- renesas_sdhi: Use manual tap correction for HS400 on some variants
- renesas_sdhi: Add support for manual correction of tap values for tunings
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAl6CGT8XHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjClFWg/+LzX09vHBOfAu7hT/RokcTaBT
uQnSAfmhkBI+CZerVulPjDX9lFpG2Jb/fu44Ae9EqOAOESAgsTJpxywRRO2f+aNL
ie9mc0WOkmz1wuAbqYPJImES0CIL2WNpivovLgquRWyltbneh+ImkCbqoWmDYff7
uIuIC4EPhrWYJczdKr5RCw6HVbsNEAgAr6oJEbmzC63HciCPx5Zo99FN5WHoyRnf
3c3Ehc4wkVy5iu/wlXqmRdvuayDHhAAmVq6FP5J3IfuoeES3EYeKHc2Ej+pwhYi9
IFCrO8RDKEu3/o5hLp60ShhF7N/LGWYsl+5KfrwOQ6YPyMLYawR6L0iTYSqkQijy
3admTGD4OGFuN/8DvQb0yUwhSpRm/Dj+jBZTP3uk9FJHteFlLNHnzREk7weo8i/R
2WNDSbbV3+TudfC0uC4ipsHtDoidyds+TvR/ebO53pH2Dcr/z6h7i+1tKczA2rK4
x9mqXhOsskNZC26/UBb9K2oElRON4XDv+VZdQI5ddDuabIYIswXMWLYD1TGYoX5z
1PXSrrj/Jl/Sz65ZpabKJOexa24s2uThvpOnrGCy2aDc/tbDpcvVhKwL6NX9iRK0
yYKpwy9yWCGMryVfLI+ahJpvJfQDY4ufKpLC2429LVvgFvNZDG233ZcZhdlhoLNG
nWh9qHTGTPWo/213yx0=
=gILc
-----END PGP SIGNATURE-----
Merge tag 'mmc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC updates from Ulf Hansson:
"MMC core:
- Add support for host software queue for (e)MMC/SD
- Throttle polling rate for CMD6
- Update CMD13 busy condition check for CMD6 commands
- Improve busy detect polling for erase/trim/discard/HPI
- Fixup support for HW busy detection for HPI commands
- Re-work and improve support for eMMC sanitize commands
MMC host:
- mmci:
* Add support for sdmmc variant revision 2.0
- mmci_sdmmc:
* Improve support for busyend detection
* Fixup support for signal voltage switch
* Add support for tuning with delay block
- mtk-sd:
* Fix another SDIO irq issue
- sdhci:
* Disable native card detect when GPIO based type exist
- sdhci:
* Add option to defer request completion
- sdhci_am654:
* Add support to set a tap value per speed mode
- sdhci-esdhc-imx:
* Add support for i.MX8MM based variant
* Fixup support for standard tuning on i.MX8 usdhc
* Optimize for strobe/clock dll settings
* Fixup support for system and runtime suspend/resume
- sdhci-iproc:
* Update regulator/bus-voltage management for bcm2711
- sdhci-msm:
* Prevent clock gating with PWRSAVE_DLL on broken variants
* Fix management of CQE during SDHCI reset
- sdhci-of-arasan:
* Add support for auto tuning on ZynqMP based platforms
- sdhci-omap:
* Add support for system suspend/resume
- sdhci-sprd:
* Add support for HW busy detection
* Enable support host software queue
- sdhci-tegra:
* Add support for HW busy detection
- tmio/renesas_sdhi:
* Enforce retune after runtime suspend
- renesas_sdhi:
* Use manual tap correction for HS400 on some variants
* Add support for manual correction of tap values for tunings"
* tag 'mmc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (86 commits)
mmc: cavium-octeon: remove nonsense variable coercion
mmc: mediatek: fix SDIO irq issue
mmc: mmci_sdmmc: Fix clear busyd0end irq flag
dt-bindings: mmc: Fix node name in an example
mmc: core: Re-work the code for eMMC sanitize
mmc: sdhci: use FIELD_GET for preset value bit masks
mmc: sdhci-of-at91: Display clock changes for debug purpose only
mmc: sdhci: iproc: Add custom set_power() callback for bcm2711
mmc: sdhci: am654: Use sdhci_set_power_and_voltage()
mmc: sdhci: at91: Use sdhci_set_power_and_voltage()
mmc: sdhci: milbeaut: Use sdhci_set_power_and_voltage()
mmc: sdhci: arasan: Use sdhci_set_power_and_voltage()
mmc: sdhci: Introduce sdhci_set_power_and_bus_voltage()
mmc: vub300: Use scnprintf() for avoiding potential buffer overflow
dt-bindings: mmc: synopsys-dw-mshc: fix clock-freq-min-max in example
sdhci: tegra: Enable MMC_CAP_WAIT_WHILE_BUSY host capability
sdhci: tegra: Implement Tegra specific set_timeout callback
mmc: sdhci-omap: Add Support for Suspend/Resume
mmc: renesas_sdhi: simplify execute_tuning
mmc: renesas_sdhi: Use BITS_PER_LONG helper
...
Pull perf updates from Ingo Molnar:
"The main changes in this cycle were:
Kernel side changes:
- A couple of x86/cpu cleanups and changes were grandfathered in due
to patch dependencies. These clean up the set of CPU model/family
matching macros with a consistent namespace and C99 initializer
style.
- A bunch of updates to various low level PMU drivers:
* AMD Family 19h L3 uncore PMU
* Intel Tiger Lake uncore support
* misc fixes to LBR TOS sampling
- optprobe fixes
- perf/cgroup: optimize cgroup event sched-in processing
- misc cleanups and fixes
Tooling side changes are to:
- perf {annotate,expr,record,report,stat,test}
- perl scripting
- libapi, libperf and libtraceevent
- vendor events on Intel and S390, ARM cs-etm
- Intel PT updates
- Documentation changes and updates to core facilities
- misc cleanups, fixes and other enhancements"
* 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (89 commits)
cpufreq/intel_pstate: Fix wrong macro conversion
x86/cpu: Cleanup the now unused CPU match macros
hwrng: via_rng: Convert to new X86 CPU match macros
crypto: Convert to new CPU match macros
ASoC: Intel: Convert to new X86 CPU match macros
powercap/intel_rapl: Convert to new X86 CPU match macros
PCI: intel-mid: Convert to new X86 CPU match macros
mmc: sdhci-acpi: Convert to new X86 CPU match macros
intel_idle: Convert to new X86 CPU match macros
extcon: axp288: Convert to new X86 CPU match macros
thermal: Convert to new X86 CPU match macros
hwmon: Convert to new X86 CPU match macros
platform/x86: Convert to new CPU match macros
EDAC: Convert to new X86 CPU match macros
cpufreq: Convert to new X86 CPU match macros
ACPI: Convert to new X86 CPU match macros
x86/platform: Convert to new CPU match macros
x86/kernel: Convert to new CPU match macros
x86/kvm: Convert to new CPU match macros
x86/perf/events: Convert to new CPU match macros
...
In this function, the variable 'base' is already 'void __iomem *base',
and the return function 'devm_platform_ioremap_resource()' also returns
this type, so the mandatory definition here is redundant.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20200327043639.6564-1-tangbin@cmss.chinamobile.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDIO irq is not triggered by low level, but by falling edge in our
previous IC. This mechanism only have one chance to catch the SDIO irq
if a SDIO irq comes within the multiple block transmission. This SDIO
irq may be easily lost, because falling edge appears only once within 2
clock after data transmission is completed.
SDIO irq recheck mechanism will make sure all irqs can be
processed correctly.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Link: https://lore.kernel.org/r/1585299097-6897-2-git-send-email-yong.mao@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
