| Message ID | 20240320223837.959900-1-jm@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add tuning algorithm for delay chain | expand |
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