On 30-10-2026 19:27, Igor Opaniuk wrote:
SDHCI_QUIRK_WAIT_SEND_CMD makes sdhci_send_command() sleep for 1 ms
after every command.
Nit: "after every command" is slightly broad - with
SDHCI_QUIRK_BROKEN_R1B also set (as msm_sdhci does), busy-response
commands without data already return early in sdhci_send_command()
before reaching this udelay(), so they never paid it. Might be worth
rephrasing to "after most commands" or similar.
Not a blocker, a commit-message polish.
msm_sdhci has set it since the driver was added
for APQ8016, back when it only did PIO; the commit gives no reason for
it, and the Linux sdhci-msm driver has no such delay.
The delay is invisible for large reads but dominates small ones. A
multi-block read is CMD18 followed by CMD12, so every read pays 2 ms
on top of the transfer. With the eMMC in HS400 a 128 KiB read takes
about 0.4 ms, so USB mass storage, which reads in 128 KiB (FSG_BUFLEN)
chunks, spent most of its time in udelay(). On the Arduino UNO Q,
reading 1 GiB from "ums 0 mmc 0" on a USB 3 host
(dd if=/dev/sdX of=/dev/null bs=4M count=256):
host throughput time in eMMC reads (10.6k reads)
with the quirk 46 MB/s 26.8 s (~2.5 ms per read)
without 201 MB/s 4.5 s (~0.4 ms per read)
A single 128 MiB "mmc read" runs at 255.6 MiB/s either way.
Drop the quirk and keep SDHCI_QUIRK_BROKEN_R1B.
Tested on the Arduino UNO Q (QRB2210, qcom,sdhci-msm-v5, ADMA):
- on main (eMMC in DDR52): 128 MiB "mmc read" at 75 MiB/s as before,
the CRC32 of the first 128 MiB read in U-Boot matches the one Linux
computes from the same blocks, and Linux boots from the eMMC;
- with the "qcom: Enable HS200/HS400 eMMC modes" series and the
mass_storage SuperSpeed descriptor patch applied (eMMC in HS400):
the ums numbers above, same CRC32 check and Linux boot.
Not tested on v4 controllers or on the boards that use the driver in
PIO mode (qcom_dragonboard410c, qcom_dragonboard820c, hmibsc).
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Tanmay Kathpalia <[email protected]>
