Sets the retries in cmd struct to their Kconfig value. This fixes
an issue in imx_usdhc.c where retries would be used uninitialized. That
leads to a loop not being entered and subsequently no data being read
from the controller.
Tested on mimxrt1170_evk.
Signed-off-by: Jakob Genßler <jakob.genssler@gin.de>
In the code comments referring to section 3.6.1, changed the reference
from 'SD specification' to 'SD host controller specification'
for a clearer and more accurate context.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
After a review of the usage of csd[4] and cid[4],
it has been determined that zero-initialization can be omitted.
It can be expected from successful operations that data will be
appropriately written back from the underlying layer.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
The decision to omit zero-initialization is driven by a desire to enhance
Zephyr's compactness and efficiency.
This is achieved by omitting zero-initialization, thereby reducing the
instruction count and, as a byproduct, the code size.
After a thorough review of the usage of struct sdhc_command and sdhc_data,
it has been determined that zero-initialization can be omitted.
Only a portion of the fields need to be manually initialized.
(e.g. cmd.retries, data.block_addr)
For the uninitialized fields, it can be expected from successful
operations that data will be appropriately written back from
the underlying layer.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Introduced the config SD_CMD_RETRIES option as a build-time parameter.
This allows the assignment of a specific value to cmd.retries.
The default value has been set to 0 to preserve the previous setting.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
As described in issue:
https://github.com/zephyrproject-rtos/zephyr/issues/65027,
sdmmc_wait_ready can enter an infinite loop if the card is removed while
waiting for it to report an idle status. Fix this by always decrementing
the timeout in sdmmc_wait_ready, regardless of whether the SD card is
busy.
Fixes#65027
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Previously, if an SD I/O operation was attempted while another thread
held the mutex for the SD card, the I/O operation would simply fail. Add
a timeout to k_mutex_lock calls within the SD subsystem, so that
multithreaded access to the SD card instead blocks until the SD card is
available for I/O
Fixes#66211
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
The current implementation uses both, host and card capabilites to derive
the maximum bus width to be used. However, in cases where a MMC device is
not connected to the host via shdc using the full bus width of 8 lines,
device initialization fails. Introducing the `bus-width` property
circumvents this by reducing the host bus capabilites and forcing
communication with the MMC device using 1, 4 or 8 lines.
Signed-off-by: Mourad Kharrazi <mourad.kharrazi@ithinx.io>
Clean up sizes of some SD data fields, as the max value of these fields
is limited by the SD specification
Specifically, the limits are as follows:
num_io: 0-7, 3 bits (SDIO only)
relative_addr: 16 bits (SDMMC/MMC)
block_size: 12 bits (Max of 2KB, uint16_t used)
sd_version: 8 bits (currently at version 3)
card_speed: 8 bits (could potentially be reduced in size)
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Ensure card CSD and CID variables are initialized in sd_ops functions
for reading card CSD and CID data.
Fixes#59562
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
- Adds mmc.c
- Edits sd.c to init and probe MMC
- Adds mmc init to sd_init
- Some functions from sdmmc.c should be in sd_ops because
they can be used by both sdmmc and mmc.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
In sd subsystem, made one header for all the init functions
instead of having a bunch of header files with one function.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
split reusable portions of SDMMC protocol code into sd_ops.c, so other
SD protocols can use these functions directly without compiling in the
SDMMC subsystem.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add stub code for SDIO support, capable of verifying card responds to CMD5.
This commit also changes the architecture of the SDIO probe step to make
adding new protocol support more streamlined, and enable compiling out
support for undesired protocols.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Update sdmmc framework to use sdmmc_wait_ready when accessing card in
SPI mode. this will allow cards that do not return to ready to be polled
for busy status until the SD data timeout expires
Fixes#52931
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Enable 4 bit bus width for high speed cards, so that host and card
combinations that cannot use UHS mode will still benefit from the
speed increase of using 4 data lines.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
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>
Fix spelling in sdmmc_decode_csd to use count instead of cout. Shortening
the variable name here was needlessly confusing.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
introduce a small wait between probing and initialization OCR. This
delay fixes a failure to initialize seen on some SD cards
Fixes#47238
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add handling for DISK_IOCTL_CTRL_SYNC to SD subsystem. Note that
SD caching is not enabled by the SD stack, so the only required
operation to sync the disk is to wait for any active data programming
to complete.
Fixes#46689
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
SDMMC busy wait timeout was incorrectly waiting for
CONFIG_SD_DATA_TIMEOUT microseconds, but should be waiting for
CONFIG_SD_DATA_TIMEOUT milliseconds. Multiply wait value by 1000.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add SDMMC driver to subsystem. SDMMC driver will handle initialization,
as well as SDMMC I/O. SD mode support is currently supported, SPI mode
support is not.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
All SD cards require SD CMD0 (reset) and CMD8 (send IF cond) at boot.
Add this portion of the initialization flow to SD subsystem, as well as
query command to check if card is SDIO.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
