If per tick is set to 10ms, it will cause nxsig_usleep(1000) in the
sdio driver to sleep for 19ms, which is much longer than the
expected 1ms, resulting in very low write performance. Add option to
reduce CPU hogging by using sched_yield(), though it may also affect
write performance when the CPU is busy.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
In mmcsd_cardidentify(), the clock is not enabled before issuing
CMD0, and the clock has been disabled in mmcsd_removed(). It makes
no sense to enable the clock after issuing CMD0, because when CMD0
is issued, it will exit with error due to the clock is not enabled.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Prompts for capacity, speed mode and bus width after eMMC
initialization is completed.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
According to the eMMC specification, in Backwards Compatibility
with legacy MMC card mode, the frequency of the SD clock must be
0-26 MHZ; in high speed SDR mode, it must be 0-52MHZ. So we should
switch to high speed SDR mode if the clock frequency is higher than
26MHZ.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
CMD6 can use these macros to set any writable EXT_CSD field, not
just the bus width, so optimize these macro definitions to make
them general.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
All eMMC devices support 4-bit bus width, so we should mark the
device as supporting 4-bit bus width after detecting that the
device type is eMMC.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Fix a bug which causes that 1-bit mode is always selected.
This happens even if the driver sets SDIO_CAPS_4BIT capability
in case of the card and the host support 1- and 4-bit wide bus.
Signed-off-by: Jani Paalijarvi <jani.paalijarvi@unikie.com>
Commit 50a8ec6 broke many mmc devices. Only if the flag
priv->caps & SDIO_CAPS_4BIT_ONLY was set, it migth work.
Without the flag, the mmc clock is never set (mmcsd_widebus()
call is terminated early stopping the clock). This flag
is probably not very generic because most mmc hw support
1, 4 and 8 bit modes.
JEDEC specifies a bus width selection procedure, but it's
not implemented in this mmcsd_sdio.c driver. Thus, it's
not known whether the hw supports 1, 4 anf 8 bit modes or
a combination of them.
However, with priv->caps & SDIO_CAPS_4BIT_ONLY the driver
suddenly assigns priv->buswidth = MMCSD_SCR_BUSWIDTH_4BIT
making it the only way to have the driver working.
Fix this by relaxing the above mentioned restrictions.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
Some hardware needs to config this delay to write one data block, because
the hardware needs more time to wear leveling and bad block manage.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
- Fix DMA addressing issues within litex_sendsetup/litex_recvsetup
- Extend with handling specific to eMMC commands during init & use.
- Cleanup of 4-bit BUS handling for SD and eMMC
- For eMMC, Send CMD0 during init as per JEDEC v4.41 for pre-idle
MMC_CMD1 command is used to check whether card is MMC type (checked if
CONFIG_MMCSD_MMCSUPPORT is enabled). This commit inserts nxsig_usleep
wait if this check fails. This is to ensure the communication recovers
from invalid response as this may take some time on some platforms (
samv7 for example). Following command for SDHC check may fail if sleep
is not used.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
mmcsd_removed will be called if the card is in invalid state.
This can happen if the card is bad, or vibrations causes a power
loss.
mmcsd_removed resets:
priv->capacity = 0; /* Capacity=0 sometimes means no media */
priv->blocksize = 0;
priv->probed = false;
priv->mediachanged = false;
priv->wrbusy = false;
priv->type = MMCSD_CARDTYPE_UNKNOWN;
priv->rca = 0;
priv->selblocklen = 0;
priv->widebus = false;
If blocksize is set to 0 will cause the log2 to result
in an infinate loop in some drivers.
IS_EMPTY will check for priv->type = MMCSD_CARDTYPE_UNKNOWN
and return ENODEV.
since rwbuffer isn't fully initiailized in mmcsd_slotinitialize.
BTW, if the cache is important for performance, it is better to
implement a general block cache and put in a common location.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
This change makes it so that the timeout is set as part of the SDIO_WAITENABLE call instead of the SDIO_EVENTWAIT call. By doing so, you eliminate all opportunity for a race condition.
stm32h7:sdmmc Check if busy ended early
mmcsd:Remove CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
stm32h7:sdmmc remove CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
stm32f7:sdmmc remove CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
stm32f7:sdmmc WRITE COMPLETE prevent false triggers
stm32h7:sdmmc WRITE COMPLETE prevent false triggers
While testing PR #2989 on the H7 I noticed that the cards
were staying in 1-bit mode. The root cause was that the
scr read path was using DMA without an invlidate.
This was caused by CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT,
but the sdmmc driver, did not use the delayed invalidate
nor would it work on 8 bytes.
The driver fully supported dcache mgt on runt buffers, but
the #ifdef CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT blocked it.
Reviewing the PR that added CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
it may have been valid at the time. But after the dcache operations
we fixed. It is not necessary and offers no benefit.
This change reflects that the geometry isn't related to the largest
allocatable unit on the platform.
Calls to read and write block devices are also affected and have
been updated.
