In commit 3c1a884436 ("mmc: mediatek: add support of source_cg clock")
an independent cg was introduced to avoid a hardware hang issue during
clock mode switches (subsequent commits will set that clock as optional).
When this clock is not present in device-tree, any operation is being
done on src_clk's parent (calling clk_get_parent()): to simplify this
and avoid checking for src_clk_cg presence everytime, just assign the
parent clock to src_clk_cg and remove the now useless checks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20211216125748.179602-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Since the MMC/SD controller in Ingenic SoCs work in half-duplex, it is
possible to use one single DMA channel for both TX and RX operations,
instead of using separate channels.
As some older Ingenic SoCs offer only a handful of DMA channels,
supporting bi-directional channels allow more hardware to use the
channels that would otherwise be used for the MMC/SD operation.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20211220190840.108061-3-paul@crapouillou.net
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When running the ARTPEC-8 DWMMC IP version, and a data error interrupt
comes during a data read transfer, there is no guarantee for the data
transfer over interrupt (DTO) to come within the specified data timeout.
This case is handled by the dto_timer handler which will complete the
request with the comment:
/*
* If DTO interrupt does NOT come in sending data state,
* we should notify the driver to terminate current transfer
* and report a data timeout to the core.
*/
But since the ARTPEC-8 DWMMC IP version, supports an extended TMOUT
register which allows longer timeouts than the non ARTPEC-8 version
does, waiting for the dto_timer to complete the request in error cases
may cause the request to take significantly longer time than necessary.
This is specifically true for the failing steps during tuning of a
device.
Fix this by completing the request when the error interrupt comes. Since
this fix is specific for the ARTPEC-8, a quirk is added.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20211220113026.21129-5-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Current dw_mci driver supports a TMOUT register which consists of a 24
bit field (TMOUT[31:8]) for the DATA_TIMEOUT. The maximum value of this
field is 0xFFFFFF, which with a 200MHz clock will give a full DRTO of:
0xFFFFFF / 200000000 => ~84 ms
However, the ARTPEC-8 SoC DWMMC IP version has a TMOUT register with an
extended DATA_TIMEOUT field, which supports longer timers for the DRTO.
In this version the DATA_TIMEOUT field is split into two, which with the
same 200MHz clock as above will allow a maximum timeout of:
((TMOUT[10:8] -1) * 0xFFFFFF + TMOUT[31:11] * 8) / 200000000 => ~587 ms
Add driver callbacks for implementation specific data timeout, and
implement callback functions for the ARTPEC-8 SoC.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211220113026.21129-4-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes: ed80a13bb4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoC")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20211217202717.10041-3-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes: e4bf1b0970 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20211217202717.10041-2-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Sparse spits out this following warning:
drivers/mmc/core/queue.c:311:21: warning: incorrect type in assignment (different base types)
drivers/mmc/core/queue.c:311:21: expected int ret
drivers/mmc/core/queue.c:311:21: got restricted blk_status_t [usertype]
drivers/mmc/core/queue.c:314:21: warning: incorrect type in assignment (different base types)
drivers/mmc/core/queue.c:314:21: expected int ret
drivers/mmc/core/queue.c:314:21: got restricted blk_status_t [usertype]
drivers/mmc/core/queue.c:336:16: warning: incorrect type in return expression (different base types)
drivers/mmc/core/queue.c:336:16: expected restricted blk_status_t
drivers/mmc/core/queue.c:336:16: got int [assigned] ret
ret is only used for blk_status_t types, so make it that type.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20211215011336.194089-1-joel@jms.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
During test campaign, and especially after several unbind/bind sequences,
it has been seen that the SD-card on SDMMC1 thread could freeze.
The freeze always appear on a CMD23 following a CMD19.
Checking SDMMC internal registers shows that the tuning command (CMD19)
has failed.
The freeze is then due to the delay block involved in the tuning sequence.
To correct this, clear the delay block register DLYB_CR register after
the tuning commands.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Fixes: 1103f807a3 ("mmc: mmci_sdmmc: Add execute tuning with delay block")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211215141727.4901-4-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The vendor driver implements special handling for multi-block
SD_IO_RW_EXTENDED (and SD_IO_RW_DIRECT) commands which have data
attached to them. It sets the MANUAL_STOP bit in the MESON_SDHC_MISC
register for these commands. In all other cases this bit is cleared.
Here we omit SD_IO_RW_DIRECT since that command never has any data
attached to it.
This fixes SDIO wifi using the brcmfmac driver which reported the
following error without this change on a Netxeon S82 board using a
Meson8 (S802) SoC:
brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip
BCM43362/1
brcmf_sdiod_ramrw: membytes transfer failed
brcmf_sdio_download_code_file: error -110 on writing 219557 membytes
at 0x00000000
brcmf_sdio_download_firmware: dongle image file download failed
And with this change:
brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip
BCM43362/1
brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may
have limited channels available
brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00
version 5.90.195.89.6 FWID 01-b30a427d
Fixes: e4bf1b0970 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211219153442.463863-2-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use DEFINE_SIMPLE_DEV_PM_OPS() instead of the SIMPLE_DEV_PM_OPS()
macro, along with using pm_sleep_ptr() as this driver doesn't handle
runtime PM.
This makes it possible to remove the #ifdef CONFIG_PM guard around
the suspend/resume functions.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Use DEFINE_SIMPLE_DEV_PM_OPS() instead of the SIMPLE_DEV_PM_OPS()
macro. This makes it possible to remove the __maybe_unused flags
on the callback functions.
- Since we only have callbacks for suspend/resume, we can conditionally
compile the dev_pm_ops structure for when CONFIG_PM_SLEEP is enabled;
so use the pm_sleep_ptr() macro instead of pm_ptr().
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The SDHCI on Tegra belongs to the core power domain and we're going to
enable GENPD support for the core domain. Now SDHCI must be resumed using
runtime PM API in order to initialize the SDHCI power state. The SDHCI
clock rate must be changed using OPP API that will reconfigure the power
domain performance state in accordance to the rate. Add runtime PM and OPP
support to the SDHCI driver.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Move the common MMC_CAP_CMD23 capability to common_caps so that only the
special case of MMC_CAP_1_8V_DDR and MMC_CAP_8_BIT_DATA are set via
caps/num_caps. Both of those can, and should, be set via device tree
properties instead, so we can now say that exynos_dwmmc_caps is only
used for backwards compatibility.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Link: https://lore.kernel.org/r/20211124184603.3897245-5-john@metanate.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The TMOUT register is always set with a full value for every transfer,
which (with a 200MHz clock) will give a full DRTO of ~84 milliseconds.
This is normally good enough to complete the request, but setting a full
value makes it impossible to test shorter timeouts, when for example
testing data read times on different SD cards.
Add a function to set any value smaller than the maximum of 0xFFFFFF.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Link: https://lore.kernel.org/r/20211119155337.14341-1-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In mmc_send_op_cond(), loops are continuously performed at the same
interval of 10 ms. However the behaviour is not good for some eMMC
which can be out from a busy state earlier than 10 ms if normal.
Rather than fixing about the interval time in mmc_send_op_cond(),
let's instead convert into using the common __mmc_poll_for_busy().
The reason for adjusting the interval time is that it is important
to reduce the eMMC initialization time, especially in devices that
use eMMC as rootfs.
Test log(eMMC:KLM8G1GETF-B041):
before: 12 ms (0.311016 - 0.298729)
[ 0.295823] mmc0: starting CMD0 arg 00000000 flags 000000c0
[ 0.298729] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start
[ 0.311016] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish
[ 0.311336] mmc0: starting CMD2 arg 00000000 flags 00000007
after: 2 ms (0.301270 - 0.298762)
[ 0.295862] mmc0: starting CMD0 arg 00000000 flags 000000c0
[ 0.298762] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start
[ 0.299067] mmc0: starting CMD1 arg 40000080 flags 000000e1
[ 0.299441] mmc0: starting CMD1 arg 40000080 flags 000000e1
[ 0.299879] mmc0: starting CMD1 arg 40000080 flags 000000e1
[ 0.300446] mmc0: starting CMD1 arg 40000080 flags 000000e1
[ 0.301270] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish
[ 0.301572] mmc0: starting CMD2 arg 00000000 flags 00000007
Signed-off-by: Huijin Park <huijin.park@samsung.com>
Link: https://lore.kernel.org/r/20211104063231.2115-3-huijin.park@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If we get a data error during a block transfer command, a stop command
(CMD12) is normally initiated. But this does not work for the general
command (CMD56), but instead the action is ignored and an uninitialized
command struct is used for the stop action, with unexpected result.
Fix this by adding a check for GEN_CMD when preparing stop transmission.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20211103182716.28419-1-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The TiWi WL1251 WiFi chip needs special setup of the sdio
interface before it can be probed.
So far, this is done in omap_hsmmc_init_card() in omap_hsmmc.c
which makes it useable only if connected to omap devices
which use the omap_hsmmc. The OpenPandora is the most promient
example.
There are plans to switch to a newer sdhci-omap driver and
retire omap_hsmmc. Hence this quirk must be reworked or moved
somewhere else. Ideally to some location that is not dependent
on the specific SoC mmc host driver.
This is achieved by the new mmc_fixup_device() option introduced
by ("mmc: allow to match the device tree to apply quirks") to match
through device tree compatible string.
This quirk will be called early right after where host->ops->init_card()
and thus omap_hsmmc_init_card() was previously called.
Note that we do not need to transplant
card->ocr = 0x80;
because we rely on ("mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD_SDIO").
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/774565df7f02124c003aaf8b879706352548f832.1636564631.git.hns@goldelico.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The mmc core takes a specific path to support initializing of a
non-standard SDIO card. This is triggered by looking for the card-quirk,
MMC_QUIRK_NONSTD_SDIO.
In mmc_sdio_init_card() this gets rather messy, as it causes the code to
bail out earlier, compared to the usual path. This leads to that the OCR
doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has
been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by
assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops.
To make the behaviour consistent, let's instead rely on the core to save
the OCR in card->ocr during initialization.
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/e7936cff7fc24d187ef2680d3b4edb0ade58f293.1636564631.git.hns@goldelico.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This (initially empty) table allows to match quirks early based
on .compatible of the child node of some mmc/sdio interface.
This allows to add quirks based on device tree instead of having
card specific code in the host ops.
A new macro SDIO_FIXUP_COMPATIBLE makes the definition readable.
And we call mmc_fixup_device(sdio_card_init_methods) just after
where host->ops->init_card() can be optionally called.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/b13fd8b3eebc3c23b6816b254a518c224cbdcfd4.1636564631.git.hns@goldelico.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
