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>
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>
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>
