Some USDHC instances are permanently wired to a non-removable device,
such as an SDIO Wi-Fi module, with no card-detect GPIO or host
card-detect line available. Previously this relied on falling through
to the "no card detection method configured" warning path and assuming
the card was present. Add an explicit non-removable boolean property so
boards can declare this intent directly; when set, the driver reports
the card as always present and skips card detection.
Signed-off-by: Ryan Erickson <ryan.erickson@ezurio.com>
NXP's USDHC SDK driver knows how to do its own cache maintenance and
does so on platforms that set HAS_MCUX_CACHE[1]. Recently, a copy of
that cache maintenance logic was added on the Zephyr side because
certain cores, like the Cortex-M33 of the i.MX RT1180, use an external
cache controller and instead set HAS_MCUX_XCACHE.
However, the Zephyr-side cache logic is buggy: it clobbers the response
data in cases when the SDK can't use DMA (specifically, when the RX
buffer isn't 4-byte aligned[2]): in those cases, the SDK code writes to
the buffer, those writes go to cache, then Zephyr invalidates the cache
discarding the written data.
NXP's SDK abstracts over different cache drivers just like Zephyr does,
so it's fine to enable its cache control for platforms with any type of
cache. Do that instead of reimplementing cache maintenance in Zephyr.
This partially reverts commit 0b8babdcc3 ("drivers: sdhc: imx_usdhc:
add cache maintenance on DMA path"), leaving only the new default value
for CONFIG_SDHC_BUFFER_ALIGNMENT.
[1] 2d8b1b1133/modules/hal_nxp/mcux/CMakeLists.txt (L140-L142)
[2] cddb388583/mcux/mcux-sdk-ng/drivers/usdhc/fsl_usdhc.c (L1343-L1346)
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
In case of FSL_FEATURE_USDHC_HAS_NO_VS18 is definied,
kUSDHC_SupportV180Flag is not defined in fsl_usdhc.h, so it will has
compile issue, the fix is to make 1.8v support to be false in case of
FSL_FEATURE_USDHC_HAS_NO_VS18 is definied.
Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
These are both gated on CONFIG_NOCACHE_MEMORY and both place the symbol
in a non-cacheable section, so there's no reason to define our own
macro. The only difference is that __nocache uses a file-specific
section name, which helps with debugging but shouldn't affect
functionality.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
When CONFIG_IMX_USDHC_DMA_SUPPORT is enabled, the USDHC ADMA2
engine DMAs to/from the data buffer supplied by upper layers
(e.g. FAT FS, SD subsystem) which lives in regular cacheable
RAM. Without explicit cache maintenance, on writes the
controller may DMA-read stale RAM while CPU writes are still
in D-cache, and on reads the CPU may consume stale cache lines
after the controller has DMA-written fresh data.
Flush the data buffer before each transfer (correct for TX,
and prevents later dirty-line eviction over DMA-written data
on RX) and invalidate after RX completes. Both scatter-gather
and non-scatter-gather paths are handled.
Raise SDHC_BUFFER_ALIGNMENT to DCACHE_LINE_SIZE when D-cache is
enabled so that DMA buffers (both upper-layer pass-through and
the SD subsystem fallback card_buffer) are cache-line aligned.
Without this, sys_cache_data_invd_range may operate on partial
cache lines and silently discard dirty data of adjacent
allocations sharing the head/tail line.
Fixes#107862
Signed-off-by: Lucien Zhao <lucien.zhao@nxp.com>
rcar already had a function to map timing mode to a string. Move that
function into the shared header and use it from multiple drivers. Also
use a shared function to convert voltage to a string instead of open
coding it everywhere.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Add optional devicetree reset support to the i.MX USDHC
driver and deassert the reset line before controller
initialization.
Keep existing behavior unchanged when no reset is described.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Add support for the no-3-3-v and no-3-0-v devicetree properties in the
IMX USDHC driver. When both are set, the driver overrides the host
capability flags to disable 3.3V and 3.0V support, and sets the USDHC
VSELECT bit at init time to configure the data line sampling threshold
for 1.8V I/O without triggering the SD voltage switch protocol.
Update the reset function to respect the voltage configuration: when
both no-3-3-v and no-3-0-v are set, the reset path now restores 1.8V
signaling instead of unconditionally switching to 3.3V, ensuring correct
behavior after card re-initialization on fixed 1.8V I/O boards.
This is required for boards like the MIMXRT700-EVK where the USDHC1
I/O voltage domain (VDDIO_0) is fixed at 1.8V.
Signed-off-by: Lucien Zhao <lucien.zhao@nxp.com>
imx_usdhc.c does not use any symbols from fsl_cache.h, and
fsl_usdhc.h does not require it transitively.
Remove the unused include to avoid build failures on targets where
the cache HAL header is not available, such as MCXN947 CPU1 virtual
board builds.
Signed-off-by: Hake Huang <hake.huang@nxp.com>
There are currently two other sdhc drivers that support this interrupt:
Infineon and Ambiq. Both those vendor HALs automatically mask the
interrupt after invoking the callback[1][2], expecting the user to
unmask it asynchronously once they've cleared the card's interrupt
condition.
The NXP usdhc driver doesn't do this and so is inconsistent with the
other two. This has caused bugs with higher-level drivers, such as the
AIROC Wi-Fi driver (#101100). Fix the issue by masking the interrupt
ourselves.
[1] 470f874ce4/mtb-hal-cat1/source/cyhal_sdhc.c (L1251-L1260)
[2] 5efc022852/mcu/apollo510/hal/mcu/am_hal_sdhc.c (L2256)Fixes#101100
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
commit bf61a47887 ("drivers: sdhc: imx_usdhc: extend reset timeout
duration") extended the timeout from 100 iterations to 1000 iterations
for the USDHC_Reset() call in imx_usdhc_reset() but not in the other
places it's called. I have observed a "usdhc: Failed to reset command
line" error from imx_usdhc_error_recovery() on an i.MX RT1061, which
goes away if I extend the timeout. Do so there and also at other call
sites for good measure.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
DAT3-based card detection can return a false negative on the first read
due to transient signal states after enabling detection. Add a bounded
retry loop (limited by IMX_USDHC_DAT3_DETECT_RETRY) with a short delay
between attempts to improve robustness.
Signed-off-by: Maochen Wang <maochen.wang@nxp.com>
When USDHC_Reset fails, we should be more verbose about it failing. Add
the error prints here so that we can observe the failure in logs.
Signed-off-by: Bas van Loon <bas@arch-embedded.com>
The imx USDHC driver previously queried the peripheral's internal card
detect signal to check card presence if no card detect method was
configured. However, some boards do not route the card detect signal and
do not work correctly with the DAT3 detection method supported by this
peripheral. As a fallback, assume the card is present in the slot but
log a warning to the user.
Fixes#42227
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Some instances of the USDHC peripheral take longer to reset, and will
timeout with the previous delay of 100 cycles. Extend this delay to 1000
cycles to resolve this.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Remove function for waiting for clock gate, as this is not used anywhere
within the USDHC driver.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Some USDHC IP instances do not have the voltage control bit present, as
they can only operate at 3.3V. Move code to select 1.8V mode into a
separate helper, and guard the call to UDSHC_SelectVoltage() behind a
feature macro from MCUX SDK.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
DDR50/DDR52 modes should use PINCTRL_STATE_SLOW (50MHz), so the lack of a
break statement after enabling DDR mode is expected. Add an explicit
__fallthrough to resolve the issue flagged by coverity scan
Fixes#65324
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Explicitly set host_io fields, instead of using memset(). This way the
fields should have values that are defined in the enum types for each
field.
Fixes#63130
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
The iMX platform always uses pinctrl, there's no need to keep
extra macrology around pinctrl. Also updated driver's Kconfig to `select
PINCTRL`.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add SD response type masks, to allow drivers to mask out the
SPI or SD native mode response type based on the SD host controller
mode they use.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
with the legacy USDHC driver fully removed from the tree, the
nxp,imx-usdhc binding can now be used for the new SD host controller
driver.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Implement SDHC driver for NXP USDHC peripheral, supporting all api calls
available in the sdhc driver. This implementation leverages NXP's HAL,
and simply implements a shim layer over the HAL itself.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
