[v5,0/7] Add tuning algorithm for delay chain

This patch series introduces a new tuning algorithm for
mmc. The new algorithm should be used when delay chain is
enabled. The ITAPDLY is selected from the largest passing
window and the buffer is not viewed as a circular buffer.
The new tuning algorithm is implemented as per the paper
published here [0] and has been tested on the following
platforms: AM62x SK, AM62A SK, AM62p SK, AM64x SK, and AM64x
EVM.

The series also includes a few fixes in the sdhci_am654
driver on OTAPDLYEN/ITAPDLYEN and ITAPDELSEL.

Changelog:
v4->v5:
- Add dll_enable = false
v3->v4:
- Add acked-by
- Remove extra newline
v2->v3:
- Remove fixes tags when not needed
- Fix return for tuning algorithm
- Fix ITAPDLY_LAST_INDEX
- Use reverse fir tree order for variable declarations
- Save all ITAPDLYENA changes in itap_del_ena[]
- Remove unnecessary parenthesis
- Remove unnecessary variables
- Save itapdlyena for HS400 timing
v1->v2:
- Remove unnecessary indentations and if/else in
 sdhci_am654_calculate_itap
- Optimize sdhci_am654_calculate_itap()
- Call sdhci_am654_write_itapdly() in sdhci_am654_set_clock()
 instead of sdhci_am654_setup_dll()
- Change otap_del_sel[], itap_del_sel[], and itap_del_ena[]
 to type u32
- Revert unnecessary reformating in sdhci_am654_set_clock()
 and sdhci_j721e_4bit_set_clock()

Judith Mendez (7):
  mmc: sdhci_am654: Add tuning algorithm for delay chain
  mmc: sdhci_am654: Write ITAPDLY for DDR52 timing
  mmc: sdhci_am654: Add OTAP/ITAP delay enable
  mmc: sdhci_am654: Fix itapdly/otapdly array type
  mmc: sdhci_am654: Update comments in sdhci_am654_set_clock
  mmc: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock
  mmc: sdhci_am654: Fix ITAPDLY for HS400 timing

 drivers/mmc/host/sdhci_am654.c | 176 ++++++++++++++++++++++++++-------
 1 file changed, 138 insertions(+), 38 deletions(-)


base-commit: faf3b8014c357d71c7a9414302e217a1dd1679af

On Wed, 20 Mar 2024 at 23:38, Judith Mendez <jm@ti.com> wrote:
>
> This patch series introduces a new tuning algorithm for
> mmc. The new algorithm should be used when delay chain is
> enabled. The ITAPDLY is selected from the largest passing
> window and the buffer is not viewed as a circular buffer.
> The new tuning algorithm is implemented as per the paper
> published here [0] and has been tested on the following
> platforms: AM62x SK, AM62A SK, AM62p SK, AM64x SK, and AM64x
> EVM.
>
> The series also includes a few fixes in the sdhci_am654
> driver on OTAPDLYEN/ITAPDLYEN and ITAPDELSEL.
>
> Changelog:
> v4->v5:
> - Add dll_enable = false
> v3->v4:
> - Add acked-by
> - Remove extra newline
> v2->v3:
> - Remove fixes tags when not needed
> - Fix return for tuning algorithm
> - Fix ITAPDLY_LAST_INDEX
> - Use reverse fir tree order for variable declarations
> - Save all ITAPDLYENA changes in itap_del_ena[]
> - Remove unnecessary parenthesis
> - Remove unnecessary variables
> - Save itapdlyena for HS400 timing
> v1->v2:
> - Remove unnecessary indentations and if/else in
>  sdhci_am654_calculate_itap
> - Optimize sdhci_am654_calculate_itap()
> - Call sdhci_am654_write_itapdly() in sdhci_am654_set_clock()
>  instead of sdhci_am654_setup_dll()
> - Change otap_del_sel[], itap_del_sel[], and itap_del_ena[]
>  to type u32
> - Revert unnecessary reformating in sdhci_am654_set_clock()
>  and sdhci_j721e_4bit_set_clock()
>
> Judith Mendez (7):
>   mmc: sdhci_am654: Add tuning algorithm for delay chain
>   mmc: sdhci_am654: Write ITAPDLY for DDR52 timing
>   mmc: sdhci_am654: Add OTAP/ITAP delay enable
>   mmc: sdhci_am654: Fix itapdly/otapdly array type
>   mmc: sdhci_am654: Update comments in sdhci_am654_set_clock
>   mmc: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock
>   mmc: sdhci_am654: Fix ITAPDLY for HS400 timing
>
>  drivers/mmc/host/sdhci_am654.c | 176 ++++++++++++++++++++++++++-------
>  1 file changed, 138 insertions(+), 38 deletions(-)
>

It's a bit unclear to me whether this series is actually fixing a
regression or whether it should be considered as improvements for the
tuning logic. For now, I decided that it looks like the latter (please
tell me if you don't agree). That said, the series is applied for
*next*, but I also took the liberty of re-ordering the patches, so
those without a fixes tag comes last.

Thanks and kind regards
Uffe