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>