DDR50 tuning is optinally defined in sd 3.0 spec. And i.MX
uSDHC internally already uses a fixed optimized timing for
DDR50, normally does not require tuning for DDR50 mode.
This patch specify a new execute_tuning function for i.MX
uSDHC, do not impact i.MX eSDHC.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The bit ESDHC_STD_TUNING_EN may be configed by bootloader code if it
choose to use standard tuning method. So on linux side, if choose to
use manual tuning method, need to clear the bit ESDHC_STD_TUNING_EN,
remove the impact of bootloader code.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Variant specific driver data doesn't change at run-time, so mark it as
const to reflect that.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fixes the following sparse warning:
drivers/mmc/host/sdhci_am654.c:161:18: warning:
symbol 'sdhci_am654_ops' was not declared. Should it be static?
Fixes: aff88ff23512 ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit bb36489032 ("mmc: meson-gx: Free irq in release() callback")
changed the _probe code to use request_threaded_irq() instead of
devm_request_threaded_irq().
Unfortunately this removes a fallback for the interrupt name:
devm_request_threaded_irq() uses the device name as fallback if the
given IRQ name is NULL. request_threaded_irq() has no such fallback,
thus /proc/interrupts shows "(null)" instead.
Explicitly pass the dev_name() so we get the IRQ name shown in
/proc/interrupts again.
While here, also fix the indentation of the request_threaded_irq()
parameter list.
Fixes: bb36489032 ("mmc: meson-gx: Free irq in release() callback")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The kblockd workqueue is created with the WQ_MEM_RECLAIM flag set.
This generates a rescuer thread for that queue that will trigger when
the CPU is under heavy load and collect the uncompleted work.
In the case of mmc, this creates the possibility of a deadlock when
there are multiple partitions on the device as other blk-mq work is
also run on the same queue. For example:
- worker 0 claims the mmc host to work on partition 1
- worker 1 attempts to claim the host for partition 2 but has to wait
for worker 0 to finish
- worker 0 schedules complete_work to release the host
- rescuer thread is triggered after time-out and collects the dangling
work
- rescuer thread attempts to complete the work in order starting with
claim host
- the task to release host is now blocked by a task to claim it and
will never be called
The above results in multiple hung tasks that lead to failures to
mount partitions.
Handling complete_work on a separate workqueue avoids this by keeping
the work completion tasks separate from the other blk-mq work. This
allows the host to be released without getting blocked by other tasks
attempting to claim the host.
Signed-off-by: Zachary Hays <zhays@lexmark.com>
Fixes: 81196976ed ("mmc: block: Add blk-mq support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The MMC device tree bindings include properties used to signal various
signalling speed modes. Until now the sunxi driver was accepting them
without any further filtering, while the sunxi device trees were not
actually using them.
Since some of the H5 boards can not run at higher speed modes stably,
we are resorting to declaring the higher speed modes per-board.
Regardless, having boards declare modes and blindly following them,
even without proper support in the driver, is generally a bad thing.
Filter out all unsupported modes from the capabilities mask after
the device tree properties have been parsed.
Cc: <stable@vger.kernel.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some H5 boards seem to not have proper trace lengths for eMMC to be able
to use the default setting for the delay chains under HS-DDR mode. These
include the Bananapi M2+ H5 and NanoPi NEO Core2. However the Libre
Computer ALL-H3-CC-H5 works just fine.
For the H5 (at least for now), default to not enabling HS-DDR modes in
the driver, and expect the device tree to signal HS-DDR capability on
boards that work.
Reported-by: Chris Blake <chrisrblake93@gmail.com>
Fixes: 07bafc1e35 ("mmc: sunxi: Use new timing mode for A64 eMMC controller")
Cc: <stable@vger.kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
to set cmd internal delay, need set PAD_TUNE register but not PAD_CMD_TUNE
register.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Fixes: 1ede5cb88a ("mmc: mediatek: Use data tune for CMD line tune")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The BCM2835 MMC host driver requests a DMA channel on probe but neglects
to release the channel in the probe error path. The channel may
therefore be leaked, in particular if devm_clk_get() causes probe
deferral. Fix it.
Fixes: 660fc733bd ("mmc: bcm2835: Add new driver for the sdhost controller.")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.12+
Cc: Frank Pavlic <f.pavlic@kunbus.de>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SPDX license identifier and the boiler plate text are
contradicting. Only the SPDX license identifier is needed. The
other one is removed.
Fixes: 86958dcc5a ("mmc: dw_mmc-bluefield: Add driver extension")
Cc: stable@vger.kernel.org
Reviewed-by: David Woods <dwoods@mellanox.com>
Signed-off-by: Liming Sun <lsun@mellanox.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
- Get rid of some WARN_ON() from the ACPI code
- Staticize a symbol
- Fix MMC polarity detection
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcPEajAAoJEEEQszewGV1zUEEP/jW6tRnSQlH2TXsn+9ljH3Q4
y8LicXEK1QTeP8TlJ9ZUQr8Vgy24hzekUy65euDyyGnXCocTS+UCWY7hznU+O1BX
Q67WrrtgOaqrkxNTYP6HBzUdJ7yza5rw4kWf8qwKQtP/giyMx+XXjzv849YHfqkv
E903+cLhNBtRafq756qV+6RJg7C7vhGhMabGny/PTkjtrD6NmkIl/A3qVGFLo/Zu
Kfwn7gpIMiXJyN2GFC8S5seESwuaZKQ2gFfdYZD2k5yTM+YvWockZjhzMMkE5OE3
RmffBw2RNWvqAZvv3PxH42AQSqKtBCaJOu2f8fGdKY/IG/Z5g4i9jAIFgh+C0P1P
l3ySji03POdvKR7dZmsqLAyMsVEppV101l6bVhkqDf99GBSlr9mPW42w2jlYdWAu
eVM6Wtkn6ssuOp3Da47Burk7dVoSo+eqRwzZkLB2TgY2oLhXyk+798e71XFnEv5G
TlY3D4n7/ozfbrN2cZX3pbXowc3RoMt9JuUnQAulO/Zjd1yoNy2lkb10mM+iIm2z
X1mNP9H5TlBLgS9QIL2Ng7DOJXO3av2UjfPENJ4yvufzjEtrGf2N9SXx7QYDDlFh
5DZV/ZFT6iKkzhi/9sWYFCQf83+57tzea/KMzPT2Xt+n8Xbb5Ub2bM17tgdOu5m/
QShDJGrEeGvxqJsGRWsc
=kS/C
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"The patch hitting the MMC/SD subsystem is fixing up my own mess when
moving semantics from MMC/SD over to gpiolib. Ulf is on vacation but I
managed to reach him on chat and obtain his ACK.
The other two are early-rc fixes that are not super serious but pretty
annoying so I'd like to get rid of them.
Summary:
- Get rid of some WARN_ON() from the ACPI code
- Staticize a symbol
- Fix MMC polarity detection"
* tag 'gpio-v5.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
mmc: core: don't override the CD GPIO level when "cd-inverted" is set
gpio: pca953x: Make symbol 'pca953x_i2c_regmap' static
gpiolib-acpi: Remove unnecessary WARN_ON from acpi_gpiochip_free_interrupts
We need to handle mmc_of_parse() errors during probe.
This finally fixes the wifi regression on Raspberry Pi 3 series.
In error case the wifi chip was permanently in reset because of
the power sequence depending on the deferred probe of the GPIO expander.
Fixes: b580c52d58 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Because the irq was requested through device managed resources API
(devm_request_threaded_irq()) it was freed after meson_mmc_remove()
completion, thus after mmc_free_host() has reclaimed meson_host memory.
As this irq is IRQF_SHARED, while using CONFIG_DEBUG_SHIRQ, its handler
get called by free_irq(). So meson_mmc_irq() was called after the
meson_host memory reclamation and was using invalid memory.
We ended up with the following scenario:
device_release_driver()
meson_mmc_remove()
mmc_free_host() /* Freeing host memory */
...
devres_release_all()
devm_irq_release()
__free_irq()
meson_mmc_irq() /* Uses freed memory */
To avoid this, the irq is released in meson_mmc_remove() and in
mseon_mmc_probe() error path before mmc_free_host() gets called.
Reported-by: Elie Roudninski <xademax@gmail.com>
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit 961de0a856 ("mmc: sdhci-omap: Workaround errata regarding
SDR104/HS200 tuning failures (i929)") added a select on TI_SOC_THERMAL
for the driver to get temperature for tuning.
However, this causes the following warning on keystone_defconfig because
keystone does not support TI_SOC_THERMAL:
"WARNING: unmet direct dependencies detected for TI_SOC_THERMAL"
Fix this by changing the select to imply.
Fixes: 961de0a856 ("mmc: sdhci-omap: Workaround errata regarding
SDR104/HS200 tuning failures (i929)")
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Tested-by: Borislav Petkov <bp@suse.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
After 'commit 5d32a66541 ("PCI/ACPI: Allow ACPI to be built without
CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
satisfied implicitly through dependencies on CONFIG_ACPI have to be
specified directly. This driver relies on IOSF_MBI and IOSF_MBI depends
on PCI. For this reason, add a direct dependency to CONFIG_PCI here.
Fixes: 5d32a66541 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Since commit 89a5e15bcb ("gpio/mmc/of: Respect polarity in the device
tree") gpiolib-of parses the "cd-gpios" property and flips the polarity
if "cd-inverted" is also set. This results in the "cd-inverted" property
being evaluated twice, which effectively makes it a no-op:
- first in drivers/gpio/gpiolib-of.c (of_xlate_and_get_gpiod_flags) when
setting up the CD GPIO
- then again in drivers/mmc/core/slot-gpio.c (mmc_gpio_get_cd) when
reading the CD GPIO value at runtime
On boards which are using device-tree with the "cd-inverted" property
being set any inserted card are not detected anymore. This is due to the
MMC core treating the CD GPIO with the wrong polarity.
Disable "override_cd_active_level" for the card detection GPIO which is
parsed using mmc_of_parse. This fixes SD card detection on the boards
which are currently using the "cd-inverted" device-tree property (tested
on Meson8b Odroid-C1 and Meson8b EC-100).
This does not remove the CD GPIO inversion logic from the MMC core
because there's at least one driver (sdhci-pci-core for Intel BayTrail
based boards) which still passes "override_cd_active_level = true" to
mmc_gpiod_request_cd(). Due to lack of hardware for testing this is left
untouched.
In the future the GPIO inversion logic for both, card and read-only
detection can be removed once no driver is using it anymore.
Fixes: 89a5e15bcb ("gpio/mmc/of: Respect polarity in the device tree")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Loys Ollivier <loys.ollivier@gmail.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.
This change was generated with the following Coccinelle SmPL patch:
@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@
-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
[hch: re-ran the script on the latest tree]
Signed-off-by: Christoph Hellwig <hch@lst.de>
- Cleanup BKOPS support
- Introduce MMC_CAP_SYNC_RUNTIME_PM
- slot-gpio: Delete legacy slot GPIO handling
MMC host:
- alcor: Add new mmc host driver for Alcor Micro PCI based cardreader
- bcm2835: Several improvements to better recover from errors
- jz4740: Rework and fixup pre|post_req support
- mediatek: Add support for SDIO IRQs
- meson-gx: Improve clock phase management
- meson-gx: Stop descriptor on errors
- mmci: Complete the sbc error path by sending a stop command
- renesas_sdhi/tmio: Fixup reset/resume operations
- renesas_sdhi: Add support for r8a774c0 and R7S9210
- renesas_sdhi: Whitelist R8A77990 SDHI
- renesas_sdhi: Fixup eMMC HS400 compatibility issues for H3 and M3-W
- rtsx_usb_sdmmc: Re-work card detection/removal support
- rtsx_usb_sdmmc: Re-work runtime PM support
- sdhci: Fix timeout loops for some variant drivers
- sdhci: Improve support for error handling due to failing commands
- sdhci-acpi/pci: Disable LED control for Intel BYT-based controllers
- sdhci_am654: Add new SDHCI variant driver to support TI's AM654 SOCs
- sdhci-of-esdhc: Add support for eMMC HS400 mode
- sdhci-omap: Fixup reset support
- sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures
- sdhci-msm: Fixup sporadic write transfers issues for SDR104/HS200
- sdhci-msm: Fixup dynamical clock gating issues
- various: Complete converting all hosts into using slot GPIO descriptors
Other:
- Move GPIO mmc platform data for mips/sh/arm to GPIO descriptors
- Add new Alcor Micro cardreader PCI driver
- Support runtime power management for memstick rtsx_usb_ms driver
- Use USB remote wakeups for card detection for rtsx_usb misc driver
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAlwk3CcXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCn3ug/+Kra3JxvVcD9I6NZV5CEBWRdw
nlNN/hexyzpf+zJ6Gb/YS1PSNVQl3a/gND+7mQRHQxJobhkSzaJ3vkZqRMo2HN8p
D1Gh1j2qBfX2uKj87Svy8nygIulbDbeiBYWrNV070JQaOki9osWTv2JRGl2zufc8
zonoW1Aou9K6AkrFoFKiaiIZFG9+h5imGSdZTTZ17iOMvs/3DzhjV8UgIvye0Tzm
Pic/4m6C7YeU7cj+aWyJFRgVuR3AG041d1likIuufxKwwhMSPf16L/xK1q8P8CCQ
ErScSODqo0hGPmRLNQ7lBN+3A3NLBWOw2Ph5OabfNIPWz1kr6s2ixN9pxkPT7usE
YMnVQ0YA0fJ13SbtdZ/mjr2A2zMkHN+4PNQC6DRDiDt4WWdNC/1aedOk0CKxRPME
ppw8MnbSl3lranNoz+opU10spSXZ2m5sGI3t7gD032PJfM3dOcJgLNTpcES5NdTR
jxqD/RYrtlg4IwZoLZgNt6BPIHBIo+D7JobqcLbELC3MKSSrO9nTKGHF2HxF6Nes
YvCzKrUAsuxKSVAuNSq/f0ZP0Uk2Nic6iN7Kt2tmkpiMZ2CmynXNtyk/Ff1b1FF/
urqOSjKYvq2bvyej5fVMGg6cieEsPZr3CiHYNWq3vwpDK87HsraO3op/qj3ud0Y0
nAPkQbeHfKKhwPGtSQU=
=mB5P
-----END PGP SIGNATURE-----
Merge tag 'mmc-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC updates from Ulf Hansson:
"This time, this pull request contains changes crossing subsystems and
archs/platforms, which is mainly because of a bigger modernization of
moving from legacy GPIO to GPIO descriptors for MMC (by Linus
Walleij).
Additionally, once again, I am funneling changes to
drivers/misc/cardreader/* and drivers/memstick/* through my MMC tree,
mostly due to that we lack a maintainer for these.
Summary:
MMC core:
- Cleanup BKOPS support
- Introduce MMC_CAP_SYNC_RUNTIME_PM
- slot-gpio: Delete legacy slot GPIO handling
MMC host:
- alcor: Add new mmc host driver for Alcor Micro PCI based cardreader
- bcm2835: Several improvements to better recover from errors
- jz4740: Rework and fixup pre|post_req support
- mediatek: Add support for SDIO IRQs
- meson-gx: Improve clock phase management
- meson-gx: Stop descriptor on errors
- mmci: Complete the sbc error path by sending a stop command
- renesas_sdhi/tmio: Fixup reset/resume operations
- renesas_sdhi: Add support for r8a774c0 and R7S9210
- renesas_sdhi: Whitelist R8A77990 SDHI
- renesas_sdhi: Fixup eMMC HS400 compatibility issues for H3 and M3-W
- rtsx_usb_sdmmc: Re-work card detection/removal support
- rtsx_usb_sdmmc: Re-work runtime PM support
- sdhci: Fix timeout loops for some variant drivers
- sdhci: Improve support for error handling due to failing commands
- sdhci-acpi/pci: Disable LED control for Intel BYT-based controllers
- sdhci_am654: Add new SDHCI variant driver to support TI's AM654 SOCs
- sdhci-of-esdhc: Add support for eMMC HS400 mode
- sdhci-omap: Fixup reset support
- sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures
- sdhci-msm: Fixup sporadic write transfers issues for SDR104/HS200
- sdhci-msm: Fixup dynamical clock gating issues
- various: Complete converting all hosts into using slot GPIO descriptors
Other:
- Move GPIO mmc platform data for mips/sh/arm to GPIO descriptors
- Add new Alcor Micro cardreader PCI driver
- Support runtime power management for memstick rtsx_usb_ms driver
- Use USB remote wakeups for card detection for rtsx_usb misc driver"
* tag 'mmc-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (99 commits)
mmc: mediatek: Add MMC_CAP_SDIO_IRQ support
mmc: renesas_sdhi_internal_dmac: Whitelist r8a774c0
dt-bindings: mmc: renesas_sdhi: Add r8a774c0 support
mmc: core: Cleanup BKOPS support
mmc: core: Drop redundant check in mmc_send_hpi_cmd()
mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
dt-bindings: sdhci-omap: Add note for cpu_thermal
mmc: sdhci-acpi: Disable LED control for Intel BYT-based controllers
mmc: sdhci-pci: Disable LED control for Intel BYT-based controllers
mmc: sdhci: Add quirk to disable LED control
mmc: mmci: add variant property to set command stop bit
misc: alcor_pci: fix spelling mistake "invailid" -> "invalid"
mmc: meson-gx: add signal resampling
mmc: meson-gx: align default phase on soc vendor tree
mmc: meson-gx: remove useless lock
mmc: meson-gx: make sure the descriptor is stopped on errors
mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver
dt-bindings: mmc: sdhci-of-arasan: Add deprecated message for AM65
dt-bindings: mmc: sdhci-am654: Document bindings for the host controllers on TI's AM654 SOCs
mmc: sdhci-msm: avoid unused function warning
...
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAlwb7R8QHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjiID/97oDjMhNT7rwpuMbHw855h62j1hEN/m+N3
FI0uxivYoYZLD+eJRnMcBwHlKjrCX8iJQAcv9ffI3ThtFW7dnZT3atUacaZVR/Dt
IrxdymdBP3qsmuaId5NYBug7rJ+AiqFJKjEvCcSPu5X397J4I3SEbzhfvYLJ/aZX
16o0HJlVVIrcbmq1IP4HwiIIOaKXvPaw04L4z4fpeynRSWG7EAi8NLSnhlR4Rxbb
BTiMkCTsjRCFdyO6da4fvNQKWmPGPa3bJkYy3qR99cvJCeIbQjRyCloQlWNJRRgi
3eJpCHVxqFmN0/+DNTJVQEEr4H8o0AVucrLVct1Jc4pessenkpoUniP8vELqwlng
Z2VHLkhTfCEmvFlk82grrYdNvGATRsrbswt/PlP4T7rBfr1IpDk8kXDWF59EL2dy
ly35Sk3wJGHBl8qa+vEPXOAnaWdqJXuVGpwB4ifOIatOls8mOxwfZjiRc7x05/fC
1O4rR2IfLwRqwoYHs0AJ+h6ohOSn1mkGezl2Tch1VSFcJUOHmuYvraTaUi6hblpA
SslaAoEhO39hRBL0HsvsMeqVWM9uzqvFkLDCfNPdiA81H1258CIbo4vF8z6czCIS
eeXnTJxVhPVbZgb3a1a93SPwM6KIDZFoIijyd+NqjpU94thlnhYD0QEcKJIKH7os
2p4aHs6ktw==
=TRdW
-----END PGP SIGNATURE-----
Merge tag 'for-4.21/block-20181221' of git://git.kernel.dk/linux-block
Pull block updates from Jens Axboe:
"This is the main pull request for block/storage for 4.21.
Larger than usual, it was a busy round with lots of goodies queued up.
Most notable is the removal of the old IO stack, which has been a long
time coming. No new features for a while, everything coming in this
week has all been fixes for things that were previously merged.
This contains:
- Use atomic counters instead of semaphores for mtip32xx (Arnd)
- Cleanup of the mtip32xx request setup (Christoph)
- Fix for circular locking dependency in loop (Jan, Tetsuo)
- bcache (Coly, Guoju, Shenghui)
* Optimizations for writeback caching
* Various fixes and improvements
- nvme (Chaitanya, Christoph, Sagi, Jay, me, Keith)
* host and target support for NVMe over TCP
* Error log page support
* Support for separate read/write/poll queues
* Much improved polling
* discard OOM fallback
* Tracepoint improvements
- lightnvm (Hans, Hua, Igor, Matias, Javier)
* Igor added packed metadata to pblk. Now drives without metadata
per LBA can be used as well.
* Fix from Geert on uninitialized value on chunk metadata reads.
* Fixes from Hans and Javier to pblk recovery and write path.
* Fix from Hua Su to fix a race condition in the pblk recovery
code.
* Scan optimization added to pblk recovery from Zhoujie.
* Small geometry cleanup from me.
- Conversion of the last few drivers that used the legacy path to
blk-mq (me)
- Removal of legacy IO path in SCSI (me, Christoph)
- Removal of legacy IO stack and schedulers (me)
- Support for much better polling, now without interrupts at all.
blk-mq adds support for multiple queue maps, which enables us to
have a map per type. This in turn enables nvme to have separate
completion queues for polling, which can then be interrupt-less.
Also means we're ready for async polled IO, which is hopefully
coming in the next release.
- Killing of (now) unused block exports (Christoph)
- Unification of the blk-rq-qos and blk-wbt wait handling (Josef)
- Support for zoned testing with null_blk (Masato)
- sx8 conversion to per-host tag sets (Christoph)
- IO priority improvements (Damien)
- mq-deadline zoned fix (Damien)
- Ref count blkcg series (Dennis)
- Lots of blk-mq improvements and speedups (me)
- sbitmap scalability improvements (me)
- Make core inflight IO accounting per-cpu (Mikulas)
- Export timeout setting in sysfs (Weiping)
- Cleanup the direct issue path (Jianchao)
- Export blk-wbt internals in block debugfs for easier debugging
(Ming)
- Lots of other fixes and improvements"
* tag 'for-4.21/block-20181221' of git://git.kernel.dk/linux-block: (364 commits)
kyber: use sbitmap add_wait_queue/list_del wait helpers
sbitmap: add helpers for add/del wait queue handling
block: save irq state in blkg_lookup_create()
dm: don't reuse bio for flushes
nvme-pci: trace SQ status on completions
nvme-rdma: implement polling queue map
nvme-fabrics: allow user to pass in nr_poll_queues
nvme-fabrics: allow nvmf_connect_io_queue to poll
nvme-core: optionally poll sync commands
block: make request_to_qc_t public
nvme-tcp: fix spelling mistake "attepmpt" -> "attempt"
nvme-tcp: fix endianess annotations
nvmet-tcp: fix endianess annotations
nvme-pci: refactor nvme_poll_irqdisable to make sparse happy
nvme-pci: only set nr_maps to 2 if poll queues are supported
nvmet: use a macro for default error location
nvmet: fix comparison of a u16 with -1
blk-mq: enable IO poll if .nr_queues of type poll > 0
blk-mq: change blk_mq_queue_busy() to blk_mq_queue_inflight()
blk-mq: skip zero-queue maps in blk_mq_map_swqueue
...
We need r8a774c0 to be whitelisted for SDHI to work on the RZ/G2E,
but we don't care about the revision of the SoC, so just whitelist
the generic part number.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It's been ~6 years ago since we introduced the BKOPS support for eMMC
cards. The current code is a bit messy and primarily that's because it
prepares to support running BKOPS in an asynchronous mode. However, that
mode has never been fully implemented/enabled. Instead BKOPS is always
executed in synchronously, when the card has reported an urgent BKOPS
level.
For these reasons, let's make the code more readable by dropping the unused
parts. Let's also rename mmc_start_bkops() to mmc_run_bkops(), as to make
it more descriptive.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is no point checking if HPI is supported in mmc_send_hpi_cmd() as
mmc_interrupt_hpi(), which is the only caller, already checks if HPI has
been enabled. Therefore, let's drop the check and the corresponding error
path.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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>
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>
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>
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>
Some of the SDMMC pads auto calibration values parsed from
devicetree are assigned incorrectly. This patch fixes it.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Fixes: 51b77c8ea7 ("mmc: tegra: Program pad autocal offsets from dt")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
V4_MODE is Bit-15 of SDHCI_HOST_CONTROL2 register.
Need to perform word access to this register.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Fixes: b3f80b434f ("mmc: sdhci: Add sd host v4 mode")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
(SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
unexpected tuning pattern errors. A small failure band may be present
in the tuning range which may be missed by the current algorithm.
Furthermore, the failure bands vary with temperature leading to
different optimum tuning values for different temperatures.
As suggested in the related Application Report (SPRACA9B - October 2017
- Revised July 2018 [2]), tuning should be done in two stages.
In stage 1, assign the optimum ratio in the maximum pass window for the
current temperature. In stage 2, if the chosen value is close to the
small failure band, move away from it in the appropriate direction.
References:
[1] http://www.ti.com/lit/pdf/sprz426
[2] http://www.ti.com/lit/pdf/SPRACA9
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Intel BYT-based controllers do not have a LED signal line. Nevertheless
sdhci_led_control() takes more than twice as long as sdhci_send_command(),
even though it does nothing. Use the new SDHCI_QUIRK_NO_LED quirk to
disable LED control for Intel BYT-based controllers.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Intel BYT-based controllers do not have a LED signal line. Nevertheless
sdhci_led_control() takes more than twice as long as sdhci_send_command(),
even though it does nothing. Use the new SDHCI_QUIRK_NO_LED quirk to
disable LED control for Intel BYT-based controllers.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Host controllers may not have a LED signal line, whereas the register
updates to control the non-existent LED can be relatively time consuming.
Add a quirk to disable LED control.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On cmd12 (STOP_TRANSMISSION), STM32 sdmmc variant needs to set
cmdstop bit in command register. The CPSM ("Command Path State Machine")
treats the command as a Stop Transmission command and signals
abort to the DPSM ("Data Path State Machine").
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
With some eMMC devices, there is still issues with the new phase
settings. Enabling signal resampling seems to solve the problem
for these.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Align the default Core and Tx phase with the SoC vendor tree.
Even if the Tx phase is different from what the documentation
recommends, it seems to provide better results.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The spinlock is only used within the irq handler so it does not
seem very useful.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On errors, if we don't stop the descriptor chain, it may continue to
run and raise IRQ after we have called mmc_request_done(). This is bad
because we won't be able to get cmd anymore and properly deal with the
IRQ.
This patch makes sure the descriptor chain is stopped before
calling mmc_request_done()
Fixes: 79ed05e329 ("mmc: meson-gx: add support for descriptor chain mode")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The host controllers on TI's AM654 SOCs are not compatible with
the phy and consumer model of the sdhci-of-arasan driver. It turns out
that for optimal operation at higher speeds, a special tuning procedure
needs to be implemented which involves configuration of platform
specific phy registers.
Therefore, branch out to a new sdhci_am654 driver and add the phy
register space with all phy configurations to it. Populate AM654
specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever
applicable.
Only add support for upto High Speed for SD card and upto DDR52 speed
mode for eMMC. Higher speeds will be added in subsequent patches.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The newly added sdhci_msm_restore_sdr_dll_config() function is only called
if CONFIG_PM is enabled:
drivers/mmc/host/sdhci-msm.c:1050:12: error:
'sdhci_msm_restore_sdr_dll_config' defined but not used
[-Werror=unused-function]
Better remove the incorrect #ifdef altogether and just use __maybe_unused,
which is harder to get wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Always check the wait condition before returning timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Always check the wait condition before returning timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/mmc/host/alcor.c: In function 'alcor_data_set_dma':
drivers/mmc/host/alcor.c:124:12: warning:
variable 'len' set but not used [-Wunused-but-set-variable]
drivers/mmc/host/alcor.c:648:15: warning:
variable 'clock_out' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is a spelling mistake in a pr_warn message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The rtsx USB parent device, has logic to detect when a card is inserted
into the card slot. Although, the logic can't detect when a card is
removed. This makes things a bit tricky, which is why the current method is
simply to turn on MMC_CAP_NEEDS_POLL during probe.
Using MMC_CAP_NEEDS_POLL means lots of energy being wasted, as the mmc host
becomes runtime resumed frequently by the mmc core, while it polls for new
cards being inserted.
To address this problem, let's start relying on that the rtsx USB driver
runtime resumes its child device, which is the rtsx_usb_sdmmc device, when
it detects that a new card being inserted.
This means dropping MMC_CAP_NEEDS_POLL from being set during probe. Instead
let's implement a ->runtime_resume() callback to schedule a detect work and
to set MMC_CAP_NEEDS_POLL. In this way, polling is enabled as long as there
is card inserted, thus we can rely on the mmc core to detect also when the
card becomes removed.
Furthermore, to avoid polling forever after a card has been removed, let's
implement a ->runtime_suspend() callback and make it clear
MMC_CAP_NEEDS_POLL.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
