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>
When 'unevaluatedProperties' support is enabled, the following warnings
are generated in the mmc bindings:
Documentation/devicetree/bindings/mmc/mtk-sd.example.dt.yaml: mmc@11230000: Unevaluated properties are not allowed ('reg', 'interrupts' were unexpected)
Documentation/devicetree/bindings/mmc/sdhci-am654.example.dt.yaml: mmc@4f80000: Unevaluated properties are not allowed ('sdhci-caps-mask' was unexpected)
Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.example.dt.yaml: mmc@5a400000: Unevaluated properties are not allowed ('dma-names', 'dmas' were unexpected)
Documentation/devicetree/bindings/mmc/arm,pl18x.example.dt.yaml: mmc@80126000: Unevaluated properties are not allowed ('dmas', 'dma-names' were unexpected)
Documentation/devicetree/bindings/mmc/arasan,sdhci.example.dt.yaml: mmc@80420000: Unevaluated properties are not allowed ('resets' was unexpected)
Documentation/devicetree/bindings/mmc/arm,pl18x.example.dt.yaml: mmc@52007000: Unevaluated properties are not allowed ('interrupt-names' was unexpected)
Documentation/devicetree/bindings/clock/imx8qxp-lpcg.example.dt.yaml: mmc@5b010000: Unevaluated properties are not allowed ('power-domains' was unexpected)
Add the missing properties as necessary. For pl18x, drop interrupt-names
as there isn't any use of it when there are 2 interrupts.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Chaotian Jing <chaotian.jing@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wenbin Mei <wenbin.mei@mediatek.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-mmc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20211206174201.2297265-1-robh@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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>
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 5.16-rc5. They include:
- gadget driver fixes for reported issues
- xhci fixes for reported problems.
- config endpoint parsing fixes for where we got bitfields wrong
Most of these have been in linux-next, the remaining few were not, but
got lots of local testing in my systems and in some cloud testing
infrastructures"
* tag 'usb-5.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: core: config: using bit mask instead of individual bits
usb: core: config: fix validation of wMaxPacketValue entries
USB: gadget: zero allocate endpoint 0 buffers
USB: gadget: detect too-big endpoint 0 requests
xhci: avoid race between disable slot command and host runtime suspend
xhci: Remove CONFIG_USB_DEFAULT_PERSIST to prevent xHCI from runtime suspending
Revert "usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default"
Pull char/misc driver fixes from Greg KH:
"Here are a bunch of small char/misc and other driver subsystem fixes.
Included in here are:
- iio driver fixes for reported problems
- phy driver fixes for a number of reported problems
- mhi resume bugfix for broken hardware
- nvmem driver fix
- rtsx driver fix for irq issues
- fastrpc packet parsing fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (33 commits)
bus: mhi: core: Add support for forced PM resume
iio: trigger: stm32-timer: fix MODULE_ALIAS
misc: rtsx: Avoid mangling IRQ during runtime PM
nvmem: eeprom: at25: fix FRAM byte_len
misc: fastrpc: fix improper packet size calculation
MAINTAINERS: add maintainer for Qualcomm FastRPC driver
bus: mhi: pci_generic: Fix device recovery failed issue
iio: adc: stm32: fix null pointer on defer_probe error
phy: HiSilicon: Fix copy and paste bug in error handling
dt-bindings: phy: zynqmp-psgtr: fix USB phy name
phy: ti: omap-usb2: Fix the kernel-doc style
phy: qualcomm: ipq806x-usb: Fix kernel-doc style
iio: at91-sama5d2: Fix incorrect sign extension
iio: adc: axp20x_adc: fix charging current reporting on AXP22x
iio: gyro: adxrs290: fix data signedness
phy: ti: tusb1210: Fix the kernel-doc warn
phy: qualcomm: usb-hsic: Fix the kernel-doc warn
phy: qualcomm: qmp: Add missing struct documentation
phy: mvebu-cp110-utmi: Fix kernel-doc warns
iio: ad7768-1: Call iio_trigger_notify_done() on error
...
Pull timer fixes from Thomas Gleixner:
"Two fixes for clock chip drivers:
- A regression fix for the Designware APB timer. A recent change to
the error checking code transformed the error condition wrongly so
it turned into a fail if good condition.
- Fix a clang build fail of the ARM architected timer driver"
* tag 'timers-urgent-2021-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource/drivers/arm_arch_timer: Force inlining of erratum_set_next_event_generic()
clocksource/drivers/dw_apb_timer_of: Fix probe failure
Pull irq fixes from Thomas Gleixner:
"A set of interrupt chip driver fixes:
- Fix the multi vector MSI allocation on Armada 370XP
- Do interrupt acknowledgement correctly in the aspeed-scu driver
- Make the IPR register offset correct in the NVIC driver
- Make redistribution table flushing correct by issueing a SYNC
command to ensure that the invalidation command has been executed
- Plug a device tree node reference leak in the bcm7210-l2 driver
- Trivial fixes in the MIPS GIC and the Apple AIC drivers"
* tag 'irq-urgent-2021-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/irq-bcm7120-l2: Add put_device() after of_find_device_by_node()
irqchip/irq-gic-v3-its.c: Force synchronisation when issuing INVALL
irqchip/apple-aic: Mark aic_init_smp() as __init
irqchip: nvic: Fix offset for Interrupt Priority Offsets
irqchip/mips-gic: Use bitfield helpers
irqchip/aspeed-scu: Replace update_bits with write_bits.
irqchip/armada-370-xp: Fix support for Multi-MSI interrupts
irqchip/armada-370-xp: Fix return value of armada_370_xp_msi_alloc()
