The ARASAN MMC controller on Keystone 3 class of devices need the SDCD
line to be connected for proper functioning.
In cases where this can't be connected, add a quirk to force the
controller into test mode and set the TESTCD bit. Use the flag
"ti,fails-without-test-cd", to implement this above quirk when required.
Additionally, this quirk also avoids waiting for the controller debounce
time.
This commit is similar to linux kernel commit c7666240ec76
("drivers: mmc: sdhci_am654: Add the quirk to set TESTCD bit").
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Christian Marangi <ansuelsmth@gmail.com> says:
This is an initial series that have all the initial trivial
fixes required for usage of OF_UPSTREAM for the mediatek SoC
This also contains the pcie-gen3 driver and the required tphy
support driver to make it work.
Subsequent series will follow with conversion of the mtk-clk
to permit usage of OF_UPSTREAM and upstream clk ID.
MT7981, MT7986 and MT7988 migration to upstream clock ID
is complete and working on MT7623.
Series CI tested with PR: https://github.com/u-boot/u-boot/pull/590
Add support for upstream linux clock and map U-Boot property to the one
use in upstream linux where supported.
Also add handling for the use_internal_cd that on upstream is hardcoded
enabled on mt7620.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add missing newline character and also add the return code of
regulator_set_value() to the output.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
common:
- spl: Introduce SoC specific init function
xilinx:
- Enable FF-A and NVMEM
- Rename spl_board_init() to spl_soc_init()
zynqmp:
- DT alignments
- Enable reset from SPL
- Enable USB3 for KD240
- Align multiboot register on Kria for proper reboot
- Allow multiboot environment write even in saved environment
- Move zynqmp commands from board/ to arch/
- Clean up xilinx_zynqmp.h
versal:
- Do not prioritize boot device if driver is not enabled
versal-net:
- Setup location for redundant variables in SPI
versal2:
- Add support for new SOC
mmc:
- Fix tap delay for SD on Versal NET
spi:
- Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part
gpio:
- Cover MODEPIN firmware dependency
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCZnBfewAKCRDKSWXLKUoM
Ib/7AJ0cn3q7lMpxbSbRj33oftI8Vy8+owCeN35Nl8TN9l/DHbfusER4uVfnOVw=
=YMIB
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2024.10-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
AMD/Xilinx changes for v2024.10-rc1
common:
- spl: Introduce SoC specific init function
xilinx:
- Enable FF-A and NVMEM
- Rename spl_board_init() to spl_soc_init()
zynqmp:
- DT alignments
- Enable reset from SPL
- Enable USB3 for KD240
- Align multiboot register on Kria for proper reboot
- Allow multiboot environment write even in saved environment
- Move zynqmp commands from board/ to arch/
- Clean up xilinx_zynqmp.h
versal:
- Do not prioritize boot device if driver is not enabled
versal-net:
- Setup location for redundant variables in SPI
versal2:
- Add support for new SOC
mmc:
- Fix tap delay for SD on Versal NET
spi:
- Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part
gpio:
- Cover MODEPIN firmware dependency
I can't see any way how tap delays are setup on Versal NET platform because
xlnx,versal-8.9a compatible string is also used there but driver is not
letting to setup tap delays. Not sure if versal_iclk_phases[] is also valid
for Versal NET but the patch is made to investigate it.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e535cfc1a59b5146a5c9a3ab389dc770de80440c.1713427490.git.michal.simek@amd.com
At this point in the DM migration, all platforms enable DM. BLK requires
DM. Make BLK "def_bool y" in the cases it had been "default y" to make
this clearer. Now remove the symbol requirement from other places as it
is redundant here.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Remove <common.h> from this driver directory and when needed
add missing include files directly.
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The constraints on the MMC_SUPPORTS_TUNING symbol can easily be
expressed in Kconfig (with the addition of SPL_MMC_SUPPORTS_TUNING).
Furthermore, in order to remove <common.h> from the MMC subsystem, the
way this symbol is used today needs to be changed in order to continue
functioning.
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, only the receive delay is configured while the transmit delay
is not set, which may result in errors when writing to the file. This issue
can be resolved by setting PHY_TX_SRC_INVERT to SDHCI_PHY_TX_RX_DLY.
Signed-off-by: Kongyang Liu <seashell11234455@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Judith Mendez <jm@ti.com> says:
The following patch series includes a MMC tuning algorithm
fix according to the following published paper [0].
This seris also includes fixes for OTAP/ITAP delay values
in j721e_4bit_sdhci_set_ios_post and for HS400 mode.
For DDR52 mode, also set ENDLL=1 and call am654_sdhci_setup_dll()
instead of am654_sdhci_setup_delay_chain() according to
device datasheet[1].
[0] https://www.ti.com/lit/an/spract9/spract9.pdf
[1] https://www.ti.com/lit/ds/symlink/am62p.pdf
At HS400 mode the ITAPDLY value is that from High Speed mode
which is incorrect and may cause boot failures.
The ITAPDLY for HS400 speed mode should be the same as ITAPDLY
as HS200 timing after tuning is executed. Add the functionality
to save ITAPDLY from HS200 tuning and save as HS400 ITAPDLY.
Fixes: c964447ea3d6 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith Mendez <jm@ti.com>
According to the device datasheet [0], ENDLL=1 for
DDR52 mode, so call am654_sdhci_setup_dll() and write
itapdly after since we do not carry out tuning.
[0] https://www.ti.com/lit/ds/symlink/am62p.pdf
Fixes: c964447ea3d6 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Set itap_del_ena if ITAPDLY is found in DT or if the tuning
algorithm was executed and found the optimal ITAPDLY. Add the
functionality to save ITAPDLYENA that can be referenced later
by storing the bit in array itap_del_ena[].
Signed-off-by: Judith Mendez <jm@ti.com>
U-Boot is failing to boot class U1 UHS SD cards due to incorrect
OTAP and ITAP delay select values. Update OTAP and ITAP delay select
values from DT.
Fixes: c7d106b4eb3 ("mmc: am654_sdhci: Update output tap delay writes")
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Currently the sdhci_am654 driver only supports one tuning
algorithm which should be used only when DLL is enabled. The
ITAPDLY is selected from the largest passing window and the
buffer is viewed as a circular buffer.
The new tuning algorithm should be used when the delay chain
is enabled; the ITAPDLY is selected from the largest passing
window and the buffer is not viewed as a circular buffer.
This implementation is based off of the following paper: [1].
Also add support for multiple failing windows.
[1] https://www.ti.com/lit/an/spract9/spract9.pdf
Fixes: a759abf569d4 ("mmc: am654_sdhci: Add support for software tuning")
Signed-off-by: Judith Mendez <jm@ti.com>
The commit 2cc6cde647e2 ("mmc: rockchip_sdhci: Limit number of blocks
read in a single command") introduced a limit of number of blocks to
read to fix a Data End Bit Error on RK3568 and RK3588. This had a side
affect of significant slowing down reading FIT from eMMC.
After the commit 6de9d7b2f13c ("rockchip: rk35xx: Enable eMMC HS200 mode
by default") the limit of number of blocks to read workaround is no
longer necessary and at HS200+ a Data End Bit Error is no longer
happening using PIO mode.
Change this limitation to allow reading more than 4 blocks with a single
CMD18 command in PIO mode at HS200+ speed, keep using the 4 blocks
limitation when loadig FIT from eMMC at lower speed than HS200.
Fixes: 2cc6cde647e2 ("mmc: rockchip_sdhci: Limit number of blocks read in a single command")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Currently fetching files bigger that cause a data transfer greater than
U16_MAX fails.
The reason is that the specification defines the datalength register
as a 16 bit wide register, but in u-boot it is used as if it is an
32 bit register. Therefore values greater than U16_MAX cause an
infinite loop inside u-boot. U-boot expects to get more data from
interface/hardware then it will ever get and therefore inifintely waits
for more data that will never come.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
According to the SD Host Controller Simplified Specification v4.20,
the multiplier value M is one more than the Clock Multiplier field.
Copied code from Linux project. drivers/mmc/host/sdhci.c line 4405
Signed-off-by: cmachida <curtis.machida@intel.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
The linux commit f722e650d965 ("mmc: core: add support for disabling
HS400 mode via DT") added support for a no-mmc-hs400 prop.
Add support for the no-mmc-hs400 prop to disable HS400 host caps.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
eMMC nodes in linux device tree files typically only contain a mmc-hs400
prop to signal support for both HS400 and HS200. However, U-Boot require
an explicit mmc-hs200 prop to signal support for the HS200 mode.
Fix this by follow linux and imply HS200 cap when HS400 cap is signaled
using a mmc-hs400 prop.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@theobrma-systems.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Some arm64 platforms may include SDIO host controllers that
only support 32-bit ADMA. While the Linux kernel detects which
size is supported and adjusts the descriptor size used dynamically,
the previous u-boot implementation statically selected between the
two depending on whether DMA_ADDR_T_64BIT was defined. Because the
static selection is already in place and effective for most platforms,
this patch logically separates "64 bit addresses are used for DMA on
this platform" and "64 bit addresses are used by the SDIO host
controller for ADMA" in order to support the small number of platforms
where these statements are not equivalent.
Using 32 bits is opt-in and existing 64 bit platforms should be
unaffected by this change.
Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Co-developed-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Greg Malysa <greg.malysa@timesys.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept &desc so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
The above is a port of Linux kernel commit 54552e4948cbf
In addition, allow drivers to allocate their own ADMA descriptor
tables if additional space is required.
Finally, fix the assignment of adma_addr to fix compiler warning
on 64-bit platforms that still use 32-bit DMA addressing.
Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Co-developed-by: Greg Malysa <greg.malysa@timesys.com>
Signed-off-by: Greg Malysa <greg.malysa@timesys.com>
Signed-off-by: Ian Roberts <ian.roberts@timesys.com>
The addresses were mistakenly swapped. Put them right.
Reported-by: Sumit Garg <sumit.garg@linaro.org>
Fixes: a737d8962cae ("mmc: msm_sdhci: correct vendor_spec_cap0 register for v5")
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
We currently default to the lowest rate but this actually doesn't work
on most platforms. Default to the HS400 speed instead which is most
common on Qualcomm platforms.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
using fdtdec_* functions is incompatible with OF_LIVE and generally
offers a less friendly interface. Update to use dev_read_* functions
instead.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The V4 and V5 controllers have quite varied register layouts. Inherit
the register offsets and naming from the Linux driver. More version
specific offsets can be inherited from Linux as needed.
Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
When building with AARCH64 defconfig, we got warnings, fix them.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The value defaults to 0 and is ignored by dw_mmc code, so the other
users are not affected.
Setting this explicitly fixes some weird reading error found on Hi3798MV200.
Fixes: 8a5dc8140e62 ("mmc: hi6220_dw_mmc: add compatible for HC2910 support")
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This can avoid hardcoding a clock rate in driver. Also can enable the
clocks and deassert the resets if the pre-bootloader does not do this
for us.
Currently only enabled for Hi3798MV200.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Place the SDR104/HS200/HS400 checks into the mmc_deinit() and always
call it. This simplifies the code and removes ifdeffery. No functional
change is expected.
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Do not access SCC when sending commands during tuning operation as that
will disrupt the tuning operation. The tuning operation is adjusting the
SCC settings itself in execute_tuning callback.
When renesas_sdhi_execute_tuning() is called by the MMC core code, a loop
which consists of renesas_sdhi_prepare_tuning(), mmc_send_tuning() and
renesas_sdhi_compare_scc_data() iterates over each SCC tuning tap.
The renesas_sdhi_prepare_tuning() configures the SCC tuning tap number into
hardware, mmc_send_tuning() triggers transfer of tuning block which depends
on the bus mode for which the bus is currently being tuned, this information
is supplied by the MMC core code, and finally renesas_sdhi_compare_scc_data()
tests the received tuning block for validity.
Because renesas_sdhi_prepare_tuning() configures the SCC tuning tap into
the hardware to fit the tuning operation, mmc_send_tuning() which triggers
command transfer using renesas_sdhi_send_cmd() must not manipulate with
the SCC in any way. Currently renesas_sdhi_send_cmd() does unconditionally
call renesas_sdhi_check_scc_error(), which may adjust the SCC tuning tap
position by writing RENESAS_SDHI_SCC_TAPSET, which would overwrite the
required tuning configuration set by renesas_sdhi_prepare_tuning() and
disrupt the tuning operation.
Fix this by skipping the renesas_sdhi_check_scc_error() call in case the
MMC subsystem is in tuning state. This way, the SCC settings are left
unmodified by command transfer during tuning operation.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Set generic mmc->tuning flag when performing tuning to indicate
this condition to drivers. Drivers may use this to bypass various
checks during tuning.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This hs400_tuning is a flag, make it bool. No functional change.
This will be useful in the following patch, which adds another
more generic flag, where the compiler can better use the space
now reserved for the u8 to store more flags in it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The current code uses the state of tuning block received by SCC to
determine whether or not to send transmission stop command. This is
not correct. Use the state of tuning block transfer to determine
whether or not to send transmission stop command instead, because
the transmission stop command has to be sent in case the tuning
block transfer failed.
This requires two changes, separate variable to store and check the
state of tuning block received by SCC, and another separate variable
to store and check return value from transmission stop command.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
In case a CRC error occurs during DMA transfer, the transfer completion
flag is not set in TMIO_SD_DMA_INFO1 and the transfer would eventually
time out. The timeout could be very long in case the transfer consists
of a large amount of blocks, the base timeout is 10 seconds and every
block adds 100 us more.
In case a CRC error does occur, a completion flag is set in a different
register, TMIO_SD_INFO1. Use this other completion flag to detect DMA
transfer ended and stop waiting for TMIO_SD_DMA_INFO1 completion flag.
This reduces the lengthy timeout in case of an error. The unconditional
check of TMIO_SD_DMA_INFO2 register for DMA related errors must not be
skipped in any case to actually recognize the DMA error and report it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The PL180/MMCI driver is implied to use CONFIG_DM and the ARM
defconfigs such as configs/vexpress_ca9x4_defconfig will get it
as well.
With a simple oneline to default to not being the v2 variant,
the original ARM MMCI variant works fine with the driver as well.
The IP version actually needs to be read out from a register on
the ARM versions, but we will simply assume we are running on the
original hardware if arm,primecell-periphid is not explicitly
specified in the device tree.
Drop the !CONFIG_DM code and depend on DM_MMC.
Tested on the Versatile Express CA9x4 board.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With MMC_PWRSEQ enabled the following link issue may happen when
building SPL and SPL_PWRSEQ is not enabled.
aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function `meson_mmc_probe':
drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
pwrseq support in SPL.
Also add depends on DM_GPIO to fix following link issue:
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function `mmc_pwrseq_set_power':
drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference to `dm_gpio_set_value'
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Ferass El Hafidi <vitali64pmemail@protonmail.com>
If the CSD register contains a reserved value (4 - 7) in bits 0:2 of the
TRAN_SPEED field, a buffer overrun occurs. Resize the mapping table.
According to the original report
https://lore.kernel.org/u-boot/20180826231332.2491-11-erosca@de.adit-jv.com/
reserved values have been observed resulting in a buffer overrun.
Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Fixes: 272cc70b211e ("Add MMC Framework")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
