This patch renames the board directory from board/freescale to
board/nxp because NXP now provides Board Support Packages (BSPs) and
tools for the former Freescale i.MX and other i.MX products.
All relevant references have been updated accordingly. This change does
not affect functionality.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
In sd_get_capabilities an ACMD is sent (SD_CMD_APP_SEND_SCR),
which requires sending APP_CMD (MMC_CMD_APP_CMD) before.
Currently, the ACMD is retried on error, however APP_CMD isn't.
In this case, when the ACMD fails and it is tried again,
the retry attempts will not be handled as ACMD, which is wrong.
The fix performs the retry attempts on the sequence of
APP_CMD and the ACMD together.
Signed-off-by: Yanir Levin <yanir.levin@tandemg.com>
Reviewed-by: Eran Moshe <emoshe@gsitechnology.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Use dev_read_u32_default() instead of dev_read_u32() to read the
"max-frequency" property from device tree. This preserves the driver-set
cfg->f_max value when the optional "max-frequency" property is not
present, ensuring the controller's default frequency is used as fallback
rather than being overwritten.
Suggested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When 'max-clk' is not specified, the SDHCI core retrieves the base clock
from the SDHCI_CAPABILITIES register (bits [15:8]). However, this field
is unreliable on MSM SDHCI controllers, as noted by the Linux driver
using the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN flag. In addition, the field
is only 8 bits wide and cannot represent base clocks above 255 MHz.
On platforms like Agatti/QCM2290, the firmware sets the SDHCI clock to
384 MHz, but the capabilities register reports 200 MHz. As a result,
the core calculates a divider of 4, producing a 96 MHz SDCLK instead of
the intended ~52 MHz. This overclocking can cause sporadic CRC errors
with certain eMMC.
To fix this, use the actual clock rate reported by the SDHCI core clock
instead of relying on the capabilities register for divider calculation.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://patch.msgid.link/20251210155454.1561611-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
This reverts commit aebb523a23.
The change to use dev_read_u32_default() with a default value of 0
causes regression for host controller drivers that hardcode f_max
before calling mmc_of_parse().
When the "max-frequency" property is not specified in the device tree,
dev_read_u32_default() returns 0, which overwrites the previously
configured f_max value set by the driver. This effectively resets
the maximum frequency to 0, breaking MMC functionality for those
controllers.
Revert to the original dev_read_u32() behavior which only updates
cfg->f_max when the "max-frequency" property is explicitly present
in the device tree, preserving driver-configured values otherwise.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Currently CRC16 is not selected when CRC checking is enabled and
if it wasn't enabled in the config otherwise the build will fail
because of references to crc16_ccitt() that doesn't exist.
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc/sd specification requires a 1 ms delay (stable supply voltage)
after vdd was enabled and before issuing first command.
For most sdcard/soc combinations, the missing delay seems to be not a
problem because the processing time between enabling vdd and the first
command is often hundreds of microseconds or more. However, in our
specific case, some sdcards were not detected by u-boot:
* soc: NXP i.MX 93
* sdcards: SanDisk Ultra, 64GB micro SDXC 1,
MediaRange, 8GB, SDHC
* measured time between vdd and first command: approx. 784us
* symptom: both sdcards did not respond at all to first commands,
u-boot mmc subsystem ran into timeout and stops to
initialize the cards
Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
Upgrade the SDHCI Cadence controller from SD4HC to SD6HC for Agilex5
platform to support the newer controller version with enhanced features.
Key changes:
- Remove combophy0 node and associated references as SD6HC doesn't require
separate PHY configuration node
- Upgrade MMC controller compatible from "cdns,sd4hc" to "cdns,sd6hc"
- Add Agilex5-specific compatible string "altr,agilex5-sd6hc" for
platform-specific optimizations
Hardware configuration updates:
- Add voltage regulator support:
* sd_emmc_power: Fixed 3.3V regulator for card power supply
* sd_io_1v8_reg: GPIO-controlled regulator for 1.8V/3.3V I/O switching
- Configure proper reset control with named resets including combophy
reset
- Add GPIO control via portb pin 3 for voltage switching
SD card operation:
- Configure for SD card specific operation (no-mmc, cap-sd-highspeed)
- Set maximum frequency to 200MHz
- Configure timing parameters for SD modes:
* Default Speed (DS) and UHS-I SDR12 mode timing:
* High Speed and UHS-I SDR25 mode timing:
- Add PHY timing delays for optimal signal integrity
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
- Add support for configuring the PHY DLL master control register for all
SD/eMMC timing modes (DS, HS, SDR, DDR, HS200, HS400) by extending the
PHY configuration arrays and writing the value during PHY adjustment.
- Fix tuning reliability by toggling the DLL reset before and after
updating the PHY_DLL_SLAVE_CTRL_REG_ADDR register.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
1. Replace underscores with hyphens in device tree property names to
follow the standard DT naming convention. This affects all
"lpbk_ctrl" properties which are now correctly named "lpbk-ctrl".
Changes:
- cdns,phy-gate-lpbk_ctrl-delay-* → cdns,phy-gate-lpbk-ctrl-delay-*
- cdns,ctrl-hrs10-lpbk_ctrl-delay-* → cdns,ctrl-hrs10-lpbk-ctrl-delay-*
2. Fix typo: semmc → emmc in eMMC SDR PHY property name
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Remove interface type restrictions in sdhci_cdns_execute_tuning() to
enable software tuning for both SD and eMMC devices. The previous
assumption that SD timing should be handled by SDHCI core is incorrect
based on the actual function assignment logic.
The execute_tuning function is assigned based on MMC_SUPPORTS_TUNING
config, which is enabled by both MMC_UHS_SUPPORT and MMC_HS200_SUPPORT.
Changes:
Remove IS_MMC() check that restricted tuning to eMMC only
Remove opcode validation limited to MMC_CMD_SEND_TUNING_BLOCK_HS200
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Replace device tree compatible string checks with hardware version field
detection to determine SDHCI controller capabilities. This approach is
more robust and aligns with standard SDHCI specification practices.
Controllers with SDHCI version 4.2 and above will automatically use the
enhanced PHY adjustment, and tuning v6-specific procedures.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Replace the legacy clock frequency-based timing mode selection with
proper MMC timing mode constants.
Changes to sdhci-cadence.c:
- Add sdhci_cdns_get_hrs06_mode() helper function for mode selection
- Replace clock frequency logic with mmc->selected_mode switch statement
- Use proper MMC timing constants (MMC_HS, UHS_SDR104, etc.)
- Add SD card specific handling with standard SDHCI control register setup
Changes to sdhci-cadence6.c:
- Add SD high speed PHY and control configuration arrays
- Update sdhci_cdns6_phy_adj() to use timing modes instead of HRS06 modes
- Support both SD and eMMC timing modes with appropriate PHY settings
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When f_max parameter is 0 in sdhci_setup_cfg(), the function defaults
to using the maximum frequency from host controller capabilities register
instead of the max-frequency property parsed from device tree.
The max-frequency property from device tree is parsed by mmc_of_parse()
and stored in plat->cfg.f_max, but sdhci_setup_cfg() was being called
with f_max=0, causing it to ignore the device tree value and use the
host capabilities register value instead.
Fix this by passing plat->cfg.f_max to sdhci_setup_cfg() to ensure
the device tree specified maximum frequency is respected over the
hardware default.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When the max-frequency property is not specified in the device tree,
the function now explicitly defaults to 0 instead of leaving cfg->f_max
uninitialized. This allows sdhci_setup_cfg() to properly detect the
absence of a device tree specified frequency and fall back to using
the host controller's maximum base clock frequency from the capabilities
register.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add reset control functionality to the SDHCI Cadence driver to properly
handle hardware reset sequences during probe. This ensures the controller
is in a known state before initialization.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Andrew Goodbody <andrew.goodbody@linaro.org> says:
The function clk_get_rate() returns a ulong with 0 meaning an invalid
clock rate and also negative error codes being returned for other
errors. But being an unsigned return value this cannot simply be tested
for with a < 0 test. Instead use the IS_ERR_VALUE() macro to check for
negative errors appearing as very large positive values. Fix those
places that test for <= 0. Also fix some places checking the return of
clk_register() that incorrectly used ERR_PTR().
Link: https://lore.kernel.org/r/20251021-clk_funcs-v1-0-acf51a40eea7@linaro.org
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
clk_get_rate() returns a ulong and that return value is assigned to a
member of a struct that is an unsigned int. So testing this value to <=
0 will only detect a return of 0. Also the code in the if block assumes
ret holds the return value when it does not. So update the test to one
that will work as intended and update the if block to actually refer to
the return value.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Restore legacy implementation of retrieving clkmgr base address from
mach-socfpga/misc.c driver for our legacy devices.
Excluding Agilex7/7M from this implementation as these devices' clock
driver is already following clock driver model and is supporting
enable/disable APIs.
The legacy devices' clock driver will have to be refactored to support
driver model which enables us to support enable/disable APIs for these
devices.
Fixes: ab27182cac ("mmc: socfpga_dw_mmc: Enable/disable SDMMC clock via API")
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Add support for R-Car Gen5 SoCs into the driver.
The default quirk is identical to previous generation.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Tweak commit message
Add DWMCI_QUIRK_DISABLE_FMP flag to Exynos850 driver data to make the
driver disable FMP in case of Exynos850 chip. That makes eMMC on
Exynos850 functional when U-Boot is executed during USB boot.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Up until now "samsung,exynos7-dw-mshc-smu" compatible was used for
Exynos850 SoC, as it's present in its device tree. But Exynos850 device
tree also supports "samsung,exynos850-dw-mshc-smu" compatible string.
Add it in compatible ID list in the driver so that it can be matched
against this string for Exynos850 device tree.
No functional change, as the driver data is just a copy of
"samsung,exynos7-dw-mshc-smu" data for now.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add DWMCI_QUIRK_DISABLE_FMP which disables Flash Memory Protector (FMP)
during driver's init. It's usually done by early bootloaders, but in
some cases (like USB boot) the FMP may be left unconfigured. The issue
was observed on Exynos850 SoC (the E850-96 board). Enabling this quirk
makes eMMC functional even in such cases.
No functional change, as this feature is only added here but not enabled
for any chips yet.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Exynos DW MMC glue layer driver have seen a lot of changes recently.
Stabilize the coding style.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Do not over-expose the private dw_mmc API. The glue layer drivers at
this point shouldn't be aware and shouldn't use the generic
dwmci_send_cmd() and dwmci_set_ios() functions. Making those functions
public causes a "leaky abstraction" issue. It clutters the public
interface of generic dw_mmc driver and possibly leads to improper usage
of those functions, so it's a bad design.
If struct dm_dwmci_ops has to be extended, do so by copying it first
(like it's done for example in snps_dw_mmc driver). That also makes sure
the future changes to struct dm_dwmci_ops in dw_mmc driver will be
automatically reflected in all extended copies, and avoid code
duplication.
This effectively reverts commit ef3b16bb8e73 ("mmc: dw_mmc: export
dwmci_send_cmd() and dwmci_set_ios()").
No functional change.
Fixes: ef3b16bb8e73 ("mmc: dw_mmc: export dwmci_send_cmd() and dwmci_set_ios()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Instead of extending dm_dwmci_ops by copy-pasting the structure code
first, copy the actual structure data with memcpy() and then set the
.execute_tuning field. Now if struct dm_dwmci_ops gets modified in
future, these changes will be automatically reflected in struct
exynos_dwmmc_ops, which prevents possible issues in future. It also
avoids code duplication.
No functional change, but it can prevent possible isssues in future.
Fixes: eda4bd29929c ("mmc: exynos_dw_mmc: add support for MMC HS200 and HS400 modes")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
eMMC erase and write support on RK3528 is somewhat unreliable, sometime
e.g. mmc erase and write commands will fail with an error.
Use the delay line lock value for half card clock cycle, DLL_LOCK_VALUE,
to set a manual xx_TAP_VALUE to fix the unreliable eMMC support.
This is only enabled for RK3528, remaining SoCs still use the automatic
tap value, (DLL_LOCK_VALUE * 2) % 256, same value we configure manually
for RK3528.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Guard execute_tuning with MMC_SUPPORTS_TUNING, otherwise there will be
build failure:
drivers/mmc/exynos_dw_mmc.c:484:10: error: 'struct dm_mmc_ops' has no member
named 'execute_tuning'
.execute_tuning = exynos_dwmmc_execute_tuning,
^~~~~~~~~~~~~~
Cc: Kaustabh Chakraborty <kauschluss@disroot.org>
Acked-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Some boards have SD card connectors where the power rail cannot be switched
off by the driver. However there are various circumstances when a card
might be re-initialized, such as after system resume, warm re-boot, or
error handling. However, a UHS card will continue to use 1.8V signaling
unless it is power cycled.
If the card has not been power cycled, it may still be using 1.8V
signaling. According to the SD spec., the Bus Speed Mode (function group 1)
bits 2 to 4 are zero if the card is initialized at 3.3V signal level. Thus
they can be used to determine if the card has already switched to 1.8V
signaling. Detect that situation and try to initialize a UHS-I (1.8V)
transfer mode.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Exynos7870 is documented in upstream dt-schema. Add it in the U-Boot
driver.
Note that here it seems that Exynos7 DW MMC is perfectly compatible with
Exynos7870 DW MMC. It's not always true, especially in SDIO cards where
data from a 64-bit FIFO is read in two 32-bit halves [1]. Since SDIO
isn't used or implemented here, it's oblivious. But upstream's schema
considers that quirk, so that compatible is followed.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7cbe799ac10f [1]
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
SD UHS mode is already supported by the Exynos DW-MMC driver in mainline
Linux. Using that as reference, add support in the U-Boot driver.
The maximum frequency was capped to 200000000, increase it to 208000000,
which is the required frequency for UHS_SDR104, which has the highest
frequency of all UHS modes. Moreover, add UHS_CAPS to host capailities.
These changes allow both host and card to recognize support for all UHS
modes.
SDR104, SDR50, and DDR50 have their own CLKSEL timing values, which
requires the CIU div value to be set in bits 18:16. Move the function
exynos_dwmci_clksel() below exynos_dwmmc_get_ciu_div() so that the
latter is accessible from the former, and add cases for said timing
modes.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
MMC HS200 and HS400 modes are already supported by the Exynos DW-MMC
driver in mainline Linux. Using that as reference, add support in the
U-Boot driver.
The maximum frequency was capped to 50000000, increase it to 200000000,
which is the required frequency for HS200/HS400. Moreover, add
MMC_MODE_HS200 and MMC_MODE_HS400 to host capailities. These changes
allow both host and card to recognize support for HS200/HS400.
This change also includes a new ops function, namely execute_tuning.
Implementing it would mean that we can no longer rely on the default ops
provided by dw_mmc.c, thus a new ops instance is created with proper
fields. The execute_tuning function is modeled after the one available
in the Linux driver.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Disrupting the regulator voltage during ios configuration messes with
the MMC initialization sequence. Move the VQMMC regulator enable/disable
functions to the MMC power cycle function, similar to how its done for
the VMMC regulator.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In certain cases, the VQMMC regulator may not support certain voltages.
For instance, a VQMMC regulator which supports only up to 2.7V will not
accept 3.3V as an argument. This is unaccounted for, and thus the driver
incorrectly assumes that the voltage is set successfully.
Fetch the return value in a variable and return if it's non-zero.
(-ENOSYS is exempted as it implies that the voltage adjustment
functionality as a whole isn't supported).
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
During a voltage switch command (CMD11, opcode: SD_CMD_SWITCH_UHS18V),
certain hosts tend to stop responding to subsequent commands. This is
addressed by introducing an additional command flag,
DWMCI_CMD_VOLT_SWITCH.
The associated interrupt bit is defined as DWMCI_INTMSK_VOLTSW. This is
set high when a voltage switch is issued, this needs to be waited for
and set to low. Implement the same in the timeout loop. Do note that
since DWMCI_INTMSK_VOLTSW shares the same bit as DWMCI_INTMSK_HTO (bit
10), the interrupt bit needs to be polled for only if the volt switch
command is issued.
DWMCI_CMD_VOLT_SWITCH also needs to be set for subsequent clken commands
after the volt switch. To ensure this, add a boolean member in the host
private struct (herein named volt_switching), which informs if the last
command issued was for volt switching or not.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The current implementation polls for the DWMCI_CMD register, for the
DWMCI_CMD_START bit to turn off, which indicates that the command has
been completed. The problem with this approach is that it doesn't
address the DWMCI_INTMSK_CDONE bit in the interrupt register,
DWMCI_RINTSTS. As a result, subsequent commands result in timeout errors.
Re-implement the waiting logic by polling for said interrupt status bit
and setting it low if raised.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In dwmci_setup_bus(), if the requested frequency is equal to the current
frequency, the function is returned, assuming no changes are required in
associated registers.
On certain SD cards, skipping in such situations may result in a timeout
errors during MMC initialization. Due to the lack of documentation, the
cause is unknown, but removing said check seems to fix the issue.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
These commands are required by struct dm_mmc_ops. Any platform specific
driver may use some or all of the functions in their own ops. Make them
accessible by moving the prototype to the dwmmc.h header.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
This driver got successfully tested with an upstream device tree
and an Exynos5250. The board in question is samsung-manta
(Google Nexus 10) which we are getting ready for upstream.
For the u-boot port was just this additional compatible string needed.
Signed-off-by: Lukas Timmermann <uboot@timmermann.space>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In owl_mmc_prepare_data there is a NULL check for the pointer data but
it happens after data has already been dereferenced. Refactor the code
so that the NULL check happens before any code dereferences data.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
