[PATCH 0/8] mmc: sdhci-cadence: Improvements and fixes for Cadence SDHCI driver

[PATCH 0/8] mmc: sdhci-cadence: Improvements and fixes for Cadence SDHCI driver

[Tanmay Kathpalia]

This patch series introduces improvements and fixes to the Cadence SDHCI
driver, correct timing mode handling, device tree integration, SD/eMMC
tuning, and compliance with SDHCI specification updates.

Summary of changes:

- Add reset control support
  Ensures proper controller reset during probe for reliable initialization.

- Respect max-frequency from device tree
  Uses the max-frequency property for configuration instead of default
  hardware values.

- Correct timing mode and PHY/control configuration
  Refactors timing mode selection for SD and eMMC cards, implements new
  mode mapping, and updates PHY/control settings for UHS and legacy modes.

- Add SDHCI_SPEC_400, _410, _420 defines
  Introduces new specification macros for SDHCI v4.0+ compatibility.

- Use hardware version field for controller detection
  Switches from compatible string checks to hardware version detection for
  controller capabilities.

- Enable software tuning for SD and eMMC
  Extends tuning logic to support both SD and eMMC devices, improving
  reliability.

- Fix device tree property naming conventions
  Updates DT property names for compliance and corrects minor typos.

- Add DLL master control and improve tuning reliability
  Adds support for PHY DLL master control and enhances tuning robustness.

Please review the series and provide your feedback.

Regards,
Tanmay Kathpalia
tanmay.kathpalia@altera.com

Tanmay Kathpalia (8):
  mmc: sdhci-cadence: Add reset control support
  mmc: sdhci-cadence: Use max-frequency property from device tree
  mmc: sdhci-cadence: Set controller and PHY speed modes for SD and eMMC
    cards
  mmc: sdhci: Add SDHCI_SPEC_400, _410, and _420 version defines
  mmc: sdhci-cadence: Use hardware version field for Cadence SDHCI
    controller
  mmc: sdhci-cadence: Enable software tuning for both SD and eMMC
    interfaces
  mmc: sdhci-cadence6: socfpga: Fix DT property naming convention
  mmc: sdhci-cadence6: Add DLL master control and improve tuning
    reliability

 drivers/mmc/sdhci-cadence.c  | 100 ++++++++++++++++++++++++-----------
 drivers/mmc/sdhci-cadence6.c |  82 +++++++++++++++++++++-------
 include/sdhci.h              |   3 ++
 3 files changed, 137 insertions(+), 48 deletions(-)

-- 
2.19.0

[PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Tanmay Kathpalia]

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>
---
 drivers/mmc/sdhci-cadence.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index 7d169efa476..d9fda902076 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -15,6 +15,7 @@
 #include <linux/sizes.h>
 #include <linux/libfdt.h>
 #include <mmc.h>
+#include <reset.h>
 #include <sdhci.h>
 #include "sdhci-cadence.h"
 
@@ -214,6 +215,7 @@ static int sdhci_cdns_probe(struct udevice *dev)
 	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
 	struct sdhci_cdns_plat *plat = dev_get_plat(dev);
 	struct sdhci_host *host = dev_get_priv(dev);
+	struct reset_ctl_bulk reset_bulk;
 	fdt_addr_t base;
 	int ret;
 
@@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct udevice *dev)
 	if (!plat->hrs_addr)
 		return -ENOMEM;
 
+	ret = reset_get_bulk(dev, &reset_bulk);
+	if (ret)
+		dev_warn(dev, "Can't get reset: %d\n", ret);
+	else
+		reset_deassert_bulk(&reset_bulk);
+
 	host->name = dev->name;
 	host->ioaddr = plat->hrs_addr + SDHCI_CDNS_SRS_BASE;
 	host->ops = &sdhci_cdns_ops;
-- 
2.43.7

Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Peng Fan]

On Mon, Nov 10, 2025 at 09:37:30AM -0800, Tanmay Kathpalia wrote:
>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>
>---
> drivers/mmc/sdhci-cadence.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
....
> 
>@@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct udevice *dev)
> 	if (!plat->hrs_addr)
> 		return -ENOMEM;
> 
>+	ret = reset_get_bulk(dev, &reset_bulk);

Should this be optional? Some in tree platforms may not have
the reset supported.

Regards
Peng

Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Tanmay Kathpalia]

Thanks for your comment, Peng.

On 11/18/2025 10:39 AM, Peng Fan wrote:
> On Mon, Nov 10, 2025 at 09:37:30AM -0800, Tanmay Kathpalia wrote:
>> 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>
>> ---
>> drivers/mmc/sdhci-cadence.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
> ....
>>
>> @@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct udevice *dev)
>> 	if (!plat->hrs_addr)
>> 		return -ENOMEM;
>>
>> +	ret = reset_get_bulk(dev, &reset_bulk);
> 
> Should this be optional? Some in tree platforms may not have
> the reset supported.
> 

Yes, you're right-some in-tree platforms may not have reset support. In 
those cases, the code will print a warning message ("Can't get reset") 
and continue the probe process.
If you prefer, I can remove the warning and let the function fail 
silently instead, or is there any other way you would suggest to make 
this optional?

> Regards
> Peng

Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Peng Fan]

On Thu, Nov 20, 2025 at 08:29:11PM +0530, Tanmay Kathpalia wrote:
>Thanks for your comment, Peng.
>
>On 11/18/2025 10:39 AM, Peng Fan wrote:
>> On Mon, Nov 10, 2025 at 09:37:30AM -0800, Tanmay Kathpalia wrote:
>> > 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>
>> > ---
>> > drivers/mmc/sdhci-cadence.c | 8 ++++++++
>> > 1 file changed, 8 insertions(+)
>> > 
>> ....
>> > 
>> > @@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct udevice *dev)
>> > 	if (!plat->hrs_addr)
>> > 		return -ENOMEM;
>> > 
>> > +	ret = reset_get_bulk(dev, &reset_bulk);
>> 
>> Should this be optional? Some in tree platforms may not have
>> the reset supported.
>> 
>
>Yes, you're right-some in-tree platforms may not have reset support. In those
>cases, the code will print a warning message ("Can't get reset") and continue
>the probe process.
>If you prefer, I can remove the warning and let the function fail silently
>instead, or is there any other way you would suggest to make this optional?

devm_reset_bulk_get_optional() may help.

Regards
Peng

>
>> Regards
>> Peng
>
>

Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Tanmay Kathpalia]

Thanks for the suggestion, Peng.

On 11/26/2025 7:47 AM, Peng Fan wrote:
> On Thu, Nov 20, 2025 at 08:29:11PM +0530, Tanmay Kathpalia wrote:
>> Thanks for your comment, Peng.
>>
>> On 11/18/2025 10:39 AM, Peng Fan wrote:
>>> On Mon, Nov 10, 2025 at 09:37:30AM -0800, Tanmay Kathpalia wrote:
>>>> 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>
>>>> ---
>>>> drivers/mmc/sdhci-cadence.c | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>> ....
>>>>
>>>> @@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct udevice *dev)
>>>> 	if (!plat->hrs_addr)
>>>> 		return -ENOMEM;
>>>>
>>>> +	ret = reset_get_bulk(dev, &reset_bulk);
>>>
>>> Should this be optional? Some in tree platforms may not have
>>> the reset supported.
>>>
>>
>> Yes, you're right-some in-tree platforms may not have reset support. In those
>> cases, the code will print a warning message ("Can't get reset") and continue
>> the probe process.
>> If you prefer, I can remove the warning and let the function fail silently
>> instead, or is there any other way you would suggest to make this optional?
> 
> devm_reset_bulk_get_optional() may help.
> 
> Regards
> Peng
> 

I looked into devm_reset_bulk_get_optional(), and I see that it 
dynamically allocates the struct reset_ctl_bulk and adds it to the 
device resources list if CONFIG_DEVRES is enabled. However, if 
CONFIG_DEVRES is not enabled, we need to manually free the memory using 
reset_release_bulk() in the driver's remove function. This means we 
would need to store a pointer to struct reset_ctl_bulk in the driver's 
private data, which would require additional changes to the 
sdhci-cadence driver (since it currently uses the generic struct 
sdhci_host with .priv_auto = sizeof(struct sdhci_host)).

Let me know if you’re okay with this approach, as it would require other 
changes in the driver, or if you have any further recommendations.
Alternatively, I can simplify the implementation as shown below:

ret = reset_get_bulk(dev, &reset_bulk);
if (!ret)
	reset_deassert_bulk(&reset_bulk);

Please let me know your preference.

Regards,
Tanmay

>>
>>> Regards
>>> Peng
>>
>>

RE: [PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Peng Fan]

> Subject: Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control
> support
> 
> Thanks for the suggestion, Peng.
> 
> On 11/26/2025 7:47 AM, Peng Fan wrote:
> > On Thu, Nov 20, 2025 at 08:29:11PM +0530, Tanmay Kathpalia
> wrote:
> >> Thanks for your comment, Peng.
> >>
> >> On 11/18/2025 10:39 AM, Peng Fan wrote:
> >>> On Mon, Nov 10, 2025 at 09:37:30AM -0800, Tanmay Kathpalia
> wrote:
> >>>> 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>
> >>>> ---
> >>>> drivers/mmc/sdhci-cadence.c | 8 ++++++++
> >>>> 1 file changed, 8 insertions(+)
> >>>>
> >>> ....
> >>>>
> >>>> @@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct
> udevice *dev)
> >>>> 	if (!plat->hrs_addr)
> >>>> 		return -ENOMEM;
> >>>>
> >>>> +	ret = reset_get_bulk(dev, &reset_bulk);
> >>>
> >>> Should this be optional? Some in tree platforms may not have the
> >>> reset supported.
> >>>
> >>
> >> Yes, you're right-some in-tree platforms may not have reset support.
> >> In those cases, the code will print a warning message ("Can't get
> >> reset") and continue the probe process.
> >> If you prefer, I can remove the warning and let the function fail
> >> silently instead, or is there any other way you would suggest to
> make this optional?
> >
> > devm_reset_bulk_get_optional() may help.
> >
> > Regards
> > Peng
> >
> 
> I looked into devm_reset_bulk_get_optional(), and I see that it
> dynamically allocates the struct reset_ctl_bulk and adds it to the
> device resources list if CONFIG_DEVRES is enabled. However, if
> CONFIG_DEVRES is not enabled, we need to manually free the memory
> using
> reset_release_bulk() in the driver's remove function. This means we
> would need to store a pointer to struct reset_ctl_bulk in the driver's
> private data, which would require additional changes to the sdhci-
> cadence driver (since it currently uses the generic struct sdhci_host
> with .priv_auto = sizeof(struct sdhci_host)).
> 
> Let me know if you’re okay with this approach, as it would require
> other changes in the driver, or if you have any further
> recommendations.
> Alternatively, I can simplify the implementation as shown below:
> 
> ret = reset_get_bulk(dev, &reset_bulk);
> if (!ret)
> 	reset_deassert_bulk(&reset_bulk);

For better, an optional API is preferred, since non-devres API
is not there, I am fine with your above changes.

Regards
Peng.

> 
> Please let me know your preference.
> 
> Regards,
> Tanmay
> 
> >>
> >>> Regards
> >>> Peng
> >>
> >>

Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control support

[Tanmay Kathpalia]

On 11/27/2025 3:18 PM, Peng Fan wrote:
>> Subject: Re: [PATCH 1/8] mmc: sdhci-cadence: Add reset control
>> support
>>
>> Thanks for the suggestion, Peng.
>>
>> On 11/26/2025 7:47 AM, Peng Fan wrote:
>>> On Thu, Nov 20, 2025 at 08:29:11PM +0530, Tanmay Kathpalia
>> wrote:
>>>> Thanks for your comment, Peng.
>>>>
>>>> On 11/18/2025 10:39 AM, Peng Fan wrote:
>>>>> On Mon, Nov 10, 2025 at 09:37:30AM -0800, Tanmay Kathpalia
>> wrote:
>>>>>> 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>
>>>>>> ---
>>>>>> drivers/mmc/sdhci-cadence.c | 8 ++++++++
>>>>>> 1 file changed, 8 insertions(+)
>>>>>>
>>>>> ....
>>>>>>
>>>>>> @@ -225,6 +227,12 @@ static int sdhci_cdns_probe(struct
>> udevice *dev)
>>>>>> 	if (!plat->hrs_addr)
>>>>>> 		return -ENOMEM;
>>>>>>
>>>>>> +	ret = reset_get_bulk(dev, &reset_bulk);
>>>>>
>>>>> Should this be optional? Some in tree platforms may not have the
>>>>> reset supported.
>>>>>
>>>>
>>>> Yes, you're right-some in-tree platforms may not have reset support.
>>>> In those cases, the code will print a warning message ("Can't get
>>>> reset") and continue the probe process.
>>>> If you prefer, I can remove the warning and let the function fail
>>>> silently instead, or is there any other way you would suggest to
>> make this optional?
>>>
>>> devm_reset_bulk_get_optional() may help.
>>>
>>> Regards
>>> Peng
>>>
>>
>> I looked into devm_reset_bulk_get_optional(), and I see that it
>> dynamically allocates the struct reset_ctl_bulk and adds it to the
>> device resources list if CONFIG_DEVRES is enabled. However, if
>> CONFIG_DEVRES is not enabled, we need to manually free the memory
>> using
>> reset_release_bulk() in the driver's remove function. This means we
>> would need to store a pointer to struct reset_ctl_bulk in the driver's
>> private data, which would require additional changes to the sdhci-
>> cadence driver (since it currently uses the generic struct sdhci_host
>> with .priv_auto = sizeof(struct sdhci_host)).
>>
>> Let me know if you’re okay with this approach, as it would require
>> other changes in the driver, or if you have any further
>> recommendations.
>> Alternatively, I can simplify the implementation as shown below:
>>
>> ret = reset_get_bulk(dev, &reset_bulk);
>> if (!ret)
>> 	reset_deassert_bulk(&reset_bulk);
> 
> For better, an optional API is preferred, since non-devres API
> is not there, I am fine with your above changes.
> 
> Regards
> Peng.
> 

I will make the changes and push the V2 series.

Regards,
Tanmay

>>
>> Please let me know your preference.
>>
>> Regards,
>> Tanmay
>>
>>>>
>>>>> Regards
>>>>> Peng
>>>>
>>>>
> 

[PATCH 2/8] mmc: sdhci-cadence: Use max-frequency property from device tree

[Tanmay Kathpalia]

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>
---
 drivers/mmc/sdhci-cadence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index d9fda902076..f31437e5eeb 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -255,7 +255,7 @@ static int sdhci_cdns_probe(struct udevice *dev)
 
 	host->mmc = &plat->mmc;
 	host->mmc->dev = dev;
-	ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
+	ret = sdhci_setup_cfg(&plat->cfg, host, plat->cfg.f_max, 0);
 	if (ret)
 		return ret;
 
-- 
2.43.7

Re: [PATCH 2/8] mmc: sdhci-cadence: Use max-frequency property from device tree

[Peng Fan]

On Mon, Nov 10, 2025 at 09:37:31AM -0800, Tanmay Kathpalia wrote:
>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>
>---
> drivers/mmc/sdhci-cadence.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
>index d9fda902076..f31437e5eeb 100644
>--- a/drivers/mmc/sdhci-cadence.c
>+++ b/drivers/mmc/sdhci-cadence.c
>@@ -255,7 +255,7 @@ static int sdhci_cdns_probe(struct udevice *dev)
> 
> 	host->mmc = &plat->mmc;
> 	host->mmc->dev = dev;
>-	ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
>+	ret = sdhci_setup_cfg(&plat->cfg, host, plat->cfg.f_max, 0);

plat is allocated by setting plat_auto in U_BOOT_DRIVER, but it is not
zeroed. So f_max maybe a random value if max frequency is not set in
device tree. You need clear it before mmc_of_parse or
change to use dev_read_u32_default for parsing max frequency in mmc_of_parse.

Regards
Peng

> 	if (ret)
> 		return ret;
> 
>-- 
>2.43.7
>
>

Re: [PATCH 2/8] mmc: sdhci-cadence: Use max-frequency property from device tree

[Tanmay Kathpalia]

Thanks for your feedback, Peng.

On 11/18/2025 11:43 AM, Peng Fan wrote:
> On Mon, Nov 10, 2025 at 09:37:31AM -0800, Tanmay Kathpalia wrote:
>> 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>
>> ---
>> drivers/mmc/sdhci-cadence.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
>> index d9fda902076..f31437e5eeb 100644
>> --- a/drivers/mmc/sdhci-cadence.c
>> +++ b/drivers/mmc/sdhci-cadence.c
>> @@ -255,7 +255,7 @@ static int sdhci_cdns_probe(struct udevice *dev)
>>
>> 	host->mmc = &plat->mmc;
>> 	host->mmc->dev = dev;
>> -	ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
>> +	ret = sdhci_setup_cfg(&plat->cfg, host, plat->cfg.f_max, 0);
> 
> plat is allocated by setting plat_auto in U_BOOT_DRIVER, but it is not
> zeroed. So f_max maybe a random value if max frequency is not set in
> device tree. You need clear it before mmc_of_parse or
> change to use dev_read_u32_default for parsing max frequency in mmc_of_parse.

I agree with your suggestion to use dev_read_u32_default in 
mmc_of_parse() for parsing the max-frequency property. This will ensure 
that plat->cfg.f_max is correctly set from the device tree, and if 
max-frequency is not specified, it will default to 0.
Since this change affects mmc-uclass.c in the MMC subsystem, I plan to 
submit a separate patch for that update to keep the changes organized.

> 
> Regards
> Peng
> 
>> 	if (ret)
>> 		return ret;
>>
>> -- 
>> 2.43.7
>>
>>

[PATCH 3/8] mmc: sdhci-cadence: Set controller and PHY speed modes for SD and eMMC cards

[Tanmay Kathpalia]

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>
---
 drivers/mmc/sdhci-cadence.c  | 72 +++++++++++++++++++++++++++---------
 drivers/mmc/sdhci-cadence6.c | 39 ++++++++++++++++---
 2 files changed, 87 insertions(+), 24 deletions(-)

diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index f31437e5eeb..a151ce10ddc 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -2,6 +2,7 @@
 /*
  * Copyright (C) 2016 Socionext Inc.
  *   Author: Masahiro Yamada <yamada.masahiro@socionext.com>
+ * Copyright (C) 2025 Altera Corporation <www.altera.com>
  */
 
 #include <dm.h>
@@ -84,39 +85,74 @@ static int sdhci_cdns_phy_init(struct sdhci_cdns_plat *plat,
 	return 0;
 }
 
+static unsigned int sdhci_cdns_get_hrs06_mode(struct mmc *mmc)
+{
+	unsigned int mode;
+
+	if (IS_SD(mmc)) {
+		mode = SDHCI_CDNS_HRS06_MODE_SD;
+	} else {
+		switch (mmc->selected_mode) {
+		case MMC_LEGACY:
+			mode = SDHCI_CDNS_HRS06_MODE_SD; /* use this for Legacy */
+			break;
+
+		case MMC_HS:
+		case MMC_HS_52:
+			mode = SDHCI_CDNS_HRS06_MODE_MMC_SDR;
+			break;
+
+		case UHS_DDR50:
+		case MMC_DDR_52:
+			mode = SDHCI_CDNS_HRS06_MODE_MMC_DDR;
+			break;
+
+		case UHS_SDR104:
+		case MMC_HS_200:
+			mode = SDHCI_CDNS_HRS06_MODE_MMC_HS200;
+			break;
+
+		case MMC_HS_400:
+		case MMC_HS_400_ES:
+			mode = SDHCI_CDNS_HRS06_MODE_MMC_HS400;
+			break;
+
+		default:
+			mode = SDHCI_CDNS_HRS06_MODE_SD;
+			break;
+		}
+	}
+	return mode;
+}
+
 static void sdhci_cdns_set_control_reg(struct sdhci_host *host)
 {
 	struct mmc *mmc = host->mmc;
 	struct sdhci_cdns_plat *plat = dev_get_plat(mmc->dev);
-	unsigned int clock = mmc->clock;
 	u32 mode, tmp;
 
 	/*
-	 * REVISIT:
-	 * The mode should be decided by MMC_TIMING_* like Linux, but
-	 * U-Boot does not support timing.  Use the clock frequency instead.
+	 * Select HRS06 mode based on card type and selected timing mode.
+	 * For SD cards, always use SD mode (000b) as per Cadence user guide,
+	 * section 12.7 (HRS06), Part Number: IP6061.
+	 * For eMMC, use selected_mode to pick the appropriate mode.
 	 */
-	if (clock <= 26000000) {
-		mode = SDHCI_CDNS_HRS06_MODE_SD; /* use this for Legacy */
-	} else if (clock <= 52000000) {
-		if (mmc->ddr_mode)
-			mode = SDHCI_CDNS_HRS06_MODE_MMC_DDR;
-		else
-			mode = SDHCI_CDNS_HRS06_MODE_MMC_SDR;
-	} else {
-		if (mmc->ddr_mode)
-			mode = SDHCI_CDNS_HRS06_MODE_MMC_HS400;
-		else
-			mode = SDHCI_CDNS_HRS06_MODE_MMC_HS200;
-	}
+	mode = sdhci_cdns_get_hrs06_mode(mmc);
 
 	tmp = readl(plat->hrs_addr + SDHCI_CDNS_HRS06);
 	tmp &= ~SDHCI_CDNS_HRS06_MODE;
 	tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_MODE, mode);
 	writel(tmp, plat->hrs_addr + SDHCI_CDNS_HRS06);
 
+	/*
+	 * For SD cards, program standard SDHCI Host Control2 UHS/voltage
+	 * registers for UHS-I support.
+	 */
+	if (IS_SD(mmc))
+		sdhci_set_control_reg(host);
+
 	if (device_is_compatible(mmc->dev, "cdns,sd6hc"))
-		sdhci_cdns6_phy_adj(mmc->dev, plat, mode);
+		sdhci_cdns6_phy_adj(mmc->dev, plat, mmc->selected_mode);
 }
 
 static const struct sdhci_ops sdhci_cdns_ops = {
diff --git a/drivers/mmc/sdhci-cadence6.c b/drivers/mmc/sdhci-cadence6.c
index ead96dc0c91..d4e2cb1c83e 100644
--- a/drivers/mmc/sdhci-cadence6.c
+++ b/drivers/mmc/sdhci-cadence6.c
@@ -2,6 +2,7 @@
 /*
  * Copyright (C) 2023 Starfive.
  *   Author: Kuan Lim Lee <kuanlim.lee@starfivetech.com>
+ * Copyright (C) 2025 Altera Corporation <www.altera.com>
  */
 
 #include <dm.h>
@@ -77,6 +78,13 @@ static struct sdhci_cdns6_phy_cfg sd_ds_phy_cfgs[] = {
 	{ "cdns,phy-dq-timing-delay-sd-ds", 0x00000001, },
 };
 
+static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
+	{ "cdns,phy-dqs-timing-delay-sd-hs", 0x00380004, },
+	{ "cdns,phy-gate-lpbk_ctrl-delay-sd-hs", 0x01A00040, },
+	{ "cdns,phy-dll-slave-ctrl-sd-hs", 0x00000000, },
+	{ "cdns,phy-dq-timing-delay-sd-hs", 0x00000001, },
+};
+
 static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
 	{ "cdns,phy-dqs-timing-delay-semmc-sdr", 0x00380004, },
 	{ "cdns,phy-gate-lpbk_ctrl-delay-emmc-sdr", 0x01A00040, },
@@ -112,6 +120,13 @@ static struct sdhci_cdns6_ctrl_cfg sd_ds_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs07-timing-delay-sd-ds", 0x00080000, },
 };
 
+static struct sdhci_cdns6_ctrl_cfg sd_hs_ctrl_cfgs[] = {
+	{ "cdns,ctrl-hrs09-timing-delay-sd-hs", 0x0001800C, },
+	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-sd-hs", 0x00030000, },
+	{ "cdns,ctrl-hrs16-slave-ctrl-sd-hs", 0x00000000, },
+	{ "cdns,ctrl-hrs07-timing-delay-sd-hs", 0x00080000, },
+};
+
 static struct sdhci_cdns6_ctrl_cfg emmc_sdr_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-emmc-sdr", 0x0001800C, },
 	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-emmc-sdr", 0x00030000, },
@@ -186,27 +201,39 @@ int sdhci_cdns6_phy_adj(struct udevice *dev, struct sdhci_cdns_plat *plat, u32 m
 	int i, ret;
 
 	switch (mode) {
-	case SDHCI_CDNS_HRS06_MODE_SD:
+	case UHS_SDR12:
+	case MMC_LEGACY:
 		sdhci_cdns6_phy_cfgs = sd_ds_phy_cfgs;
 		sdhci_cdns6_ctrl_cfgs = sd_ds_ctrl_cfgs;
 		break;
 
-	case SDHCI_CDNS_HRS06_MODE_MMC_SDR:
+	case SD_HS:
+	case UHS_SDR25:
+	case MMC_HS:
+		sdhci_cdns6_phy_cfgs = sd_hs_phy_cfgs;
+		sdhci_cdns6_ctrl_cfgs = sd_hs_ctrl_cfgs;
+		break;
+
+	case UHS_SDR50:
+	case MMC_HS_52:
 		sdhci_cdns6_phy_cfgs = emmc_sdr_phy_cfgs;
 		sdhci_cdns6_ctrl_cfgs = emmc_sdr_ctrl_cfgs;
 		break;
 
-	case SDHCI_CDNS_HRS06_MODE_MMC_DDR:
+	case UHS_DDR50:
+	case MMC_DDR_52:
 		sdhci_cdns6_phy_cfgs = emmc_ddr_phy_cfgs;
 		sdhci_cdns6_ctrl_cfgs = emmc_ddr_ctrl_cfgs;
 		break;
 
-	case SDHCI_CDNS_HRS06_MODE_MMC_HS200:
+	case UHS_SDR104:
+	case MMC_HS_200:
 		sdhci_cdns6_phy_cfgs = emmc_hs200_phy_cfgs;
 		sdhci_cdns6_ctrl_cfgs = emmc_hs200_ctrl_cfgs;
 		break;
 
-	case SDHCI_CDNS_HRS06_MODE_MMC_HS400:
+	case MMC_HS_400:
+	case MMC_HS_400_ES:
 		sdhci_cdns6_phy_cfgs = emmc_hs400_phy_cfgs;
 		sdhci_cdns6_ctrl_cfgs = emmc_hs400_ctrl_cfgs;
 		break;
@@ -263,7 +290,7 @@ int sdhci_cdns6_phy_adj(struct udevice *dev, struct sdhci_cdns_plat *plat, u32 m
 
 int sdhci_cdns6_phy_init(struct udevice *dev, struct sdhci_cdns_plat *plat)
 {
-	return sdhci_cdns6_phy_adj(dev, plat, SDHCI_CDNS_HRS06_MODE_SD);
+	return sdhci_cdns6_phy_adj(dev, plat, MMC_LEGACY);
 }
 
 int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
-- 
2.43.7

[PATCH 4/8] mmc: sdhci: Add SDHCI_SPEC_400, _410, and _420 version defines

[Tanmay Kathpalia]

Add SDHCI_SPEC_400, SDHCI_SPEC_410, and SDHCI_SPEC_420 macros to sdhci.h
to support newer SDHCI specification versions. These defines are required
for compatibility with controllers implementing SDHCI 4.0 and above.

Reference:
https://lore.kernel.org/all/1535617305-16952-2-git-send-email-zhang.chunyan@linaro.org/

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Reviewed-by: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
---
 include/sdhci.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/sdhci.h b/include/sdhci.h
index d9c0597a0c1..fb847821d58 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -223,6 +223,9 @@
 #define   SDHCI_SPEC_100	0
 #define   SDHCI_SPEC_200	1
 #define   SDHCI_SPEC_300	2
+#define   SDHCI_SPEC_400	3
+#define   SDHCI_SPEC_410	4
+#define   SDHCI_SPEC_420	5
 
 #define SDHCI_GET_VERSION(x) (x->version & SDHCI_SPEC_VER_MASK)
 
-- 
2.43.7

[PATCH 5/8] mmc: sdhci-cadence: Use hardware version field for Cadence SDHCI controller

[Tanmay Kathpalia]

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>
---
 drivers/mmc/sdhci-cadence.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index a151ce10ddc..4a54196e06d 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -151,7 +151,7 @@ static void sdhci_cdns_set_control_reg(struct sdhci_host *host)
 	if (IS_SD(mmc))
 		sdhci_set_control_reg(host);
 
-	if (device_is_compatible(mmc->dev, "cdns,sd6hc"))
+	if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_420)
 		sdhci_cdns6_phy_adj(mmc->dev, plat, mmc->selected_mode);
 }
 
@@ -162,11 +162,13 @@ static const struct sdhci_ops sdhci_cdns_ops = {
 static int sdhci_cdns_set_tune_val(struct sdhci_cdns_plat *plat,
 				   unsigned int val)
 {
+	struct mmc *mmc = &plat->mmc;
+	struct sdhci_host *host = dev_get_priv(mmc->dev);
 	void __iomem *reg = plat->hrs_addr + SDHCI_CDNS_HRS06;
 	u32 tmp;
 	int i, ret;
 
-	if (device_is_compatible(plat->mmc.dev, "cdns,sd6hc"))
+	if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_420)
 		return sdhci_cdns6_set_tune_val(plat, val);
 
 	if (WARN_ON(!FIELD_FIT(SDHCI_CDNS_HRS06_TUNE, val)))
-- 
2.43.7

[PATCH 6/8] mmc: sdhci-cadence: Enable software tuning for both SD and eMMC interfaces

[Tanmay Kathpalia]

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>
---
 drivers/mmc/sdhci-cadence.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index 4a54196e06d..de3d42053f0 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -207,16 +207,10 @@ static int __maybe_unused sdhci_cdns_execute_tuning(struct udevice *dev,
 	int i;
 
 	/*
-	 * This handler only implements the eMMC tuning that is specific to
-	 * this controller.  The tuning for SD timing should be handled by the
-	 * SDHCI core.
+	 * This function performs the tuning process for both SD and eMMC
+	 * interfaces. It sweeps through all available tuning points,
+	 * sending tuning commands at each step.
 	 */
-	if (!IS_MMC(mmc))
-		return -ENOTSUPP;
-
-	if (WARN_ON(opcode != MMC_CMD_SEND_TUNING_BLOCK_HS200))
-		return -EINVAL;
-
 	for (i = 0; i < SDHCI_CDNS_MAX_TUNING_LOOP; i++) {
 		if (sdhci_cdns_set_tune_val(plat, i) ||
 		    mmc_send_tuning(mmc, opcode)) { /* bad */
-- 
2.43.7

[PATCH 7/8] mmc: sdhci-cadence6: socfpga: Fix DT property naming convention

[Tanmay Kathpalia]

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>
---
 drivers/mmc/sdhci-cadence6.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/sdhci-cadence6.c b/drivers/mmc/sdhci-cadence6.c
index d4e2cb1c83e..d9467293807 100644
--- a/drivers/mmc/sdhci-cadence6.c
+++ b/drivers/mmc/sdhci-cadence6.c
@@ -73,84 +73,84 @@ struct sdhci_cdns6_ctrl_cfg {
 
 static struct sdhci_cdns6_phy_cfg sd_ds_phy_cfgs[] = {
 	{ "cdns,phy-dqs-timing-delay-sd-ds", 0x00380004, },
-	{ "cdns,phy-gate-lpbk_ctrl-delay-sd-ds", 0x01A00040, },
+	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-ds", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-sd-ds", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-sd-ds", 0x00000001, },
 };
 
 static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
 	{ "cdns,phy-dqs-timing-delay-sd-hs", 0x00380004, },
-	{ "cdns,phy-gate-lpbk_ctrl-delay-sd-hs", 0x01A00040, },
+	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-hs", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-sd-hs", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-sd-hs", 0x00000001, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
-	{ "cdns,phy-dqs-timing-delay-semmc-sdr", 0x00380004, },
-	{ "cdns,phy-gate-lpbk_ctrl-delay-emmc-sdr", 0x01A00040, },
+	{ "cdns,phy-dqs-timing-delay-emmc-sdr", 0x00380004, },
+	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-sdr", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-sdr", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-emmc-sdr", 0x00000001, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
 	{ "cdns,phy-dqs-timing-delay-emmc-ddr", 0x00380004, },
-	{ "cdns,phy-gate-lpbk_ctrl-delay-emmc-ddr", 0x01A00040, },
+	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-ddr", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-ddr", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-emmc-ddr", 0x10000001, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
 	{ "cdns,phy-dqs-timing-delay-emmc-hs200", 0x00380004, },
-	{ "cdns,phy-gate-lpbk_ctrl-delay-emmc-hs200", 0x01A00040, },
+	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs200", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-hs200", 0x00DADA00, },
 	{ "cdns,phy-dq-timing-delay-emmc-hs200", 0x00000001, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
 	{ "cdns,phy-dqs-timing-delay-emmc-hs400", 0x00280004, },
-	{ "cdns,phy-gate-lpbk_ctrl-delay-emmc-hs400", 0x01A00040, },
+	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs400", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-hs400", 0x00DAD800, },
 	{ "cdns,phy-dq-timing-delay-emmc-hs400", 0x00000001, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg sd_ds_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-sd-ds", 0x0001800C, },
-	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-sd-ds", 0x00020000, },
+	{ "cdns,ctrl-hrs10-lpbk-ctrl-delay-sd-ds", 0x00020000, },
 	{ "cdns,ctrl-hrs16-slave-ctrl-sd-ds", 0x00000000, },
 	{ "cdns,ctrl-hrs07-timing-delay-sd-ds", 0x00080000, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg sd_hs_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-sd-hs", 0x0001800C, },
-	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-sd-hs", 0x00030000, },
+	{ "cdns,ctrl-hrs10-lpbk-ctrl-delay-sd-hs", 0x00030000, },
 	{ "cdns,ctrl-hrs16-slave-ctrl-sd-hs", 0x00000000, },
 	{ "cdns,ctrl-hrs07-timing-delay-sd-hs", 0x00080000, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg emmc_sdr_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-emmc-sdr", 0x0001800C, },
-	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-emmc-sdr", 0x00030000, },
+	{ "cdns,ctrl-hrs10-lpbk-ctrl-delay-emmc-sdr", 0x00030000, },
 	{ "cdns,ctrl-hrs16-slave-ctrl-emmc-sdr", 0x00000000, },
 	{ "cdns,ctrl-hrs07-timing-delay-emmc-sdr", 0x00080000, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg emmc_ddr_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-emmc-ddr", 0x0001800C, },
-	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-emmc-ddr", 0x00020000, },
+	{ "cdns,ctrl-hrs10-lpbk-ctrl-delay-emmc-ddr", 0x00020000, },
 	{ "cdns,ctrl-hrs16-slave-ctrl-emmc-ddr", 0x11000001, },
 	{ "cdns,ctrl-hrs07-timing-delay-emmc-ddr", 0x00090001, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg emmc_hs200_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-emmc-hs200", 0x00018000, },
-	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-emmc-hs200", 0x00080000, },
+	{ "cdns,ctrl-hrs10-lpbk-ctrl-delay-emmc-hs200", 0x00080000, },
 	{ "cdns,ctrl-hrs16-slave-ctrl-emmc-hs200", 0x00000000, },
 	{ "cdns,ctrl-hrs07-timing-delay-emmc-hs200", 0x00090000, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg emmc_hs400_ctrl_cfgs[] = {
 	{ "cdns,ctrl-hrs09-timing-delay-emmc-hs400", 0x00018000, },
-	{ "cdns,ctrl-hrs10-lpbk_ctrl-delay-emmc-hs400", 0x00080000, },
+	{ "cdns,ctrl-hrs10-lpbk-ctrl-delay-emmc-hs400", 0x00080000, },
 	{ "cdns,ctrl-hrs16-slave-ctrl-emmc-hs400", 0x11000000, },
 	{ "cdns,ctrl-hrs07-timing-delay-emmc-hs400", 0x00080000, },
 };
-- 
2.43.7

Re: [PATCH 7/8] mmc: sdhci-cadence6: socfpga: Fix DT property naming convention

[Peng Fan]

On Mon, Nov 10, 2025 at 09:37:36AM -0800, Tanmay Kathpalia wrote:
>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".

Are these properties in Linux Upstream tree?

I not see users in arch/arm/dts and dts/upstream for the properties.

Regards
Peng

Re: [PATCH 7/8] mmc: sdhci-cadence6: socfpga: Fix DT property naming convention

[Tanmay Kathpalia]

On 11/18/2025 11:52 AM, Peng Fan wrote:
> On Mon, Nov 10, 2025 at 09:37:36AM -0800, Tanmay Kathpalia wrote:
>> 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".
> 
> Are these properties in Linux Upstream tree?
> 

No, the Linux upstream tree does not have the Cadence version 6 host 
controller driver, so these properties are not present in Linux.

> I not see users in arch/arm/dts and dts/upstream for the properties.
> 

Currently, there are no users for the Cadence version 6 host controller 
IP. However, we have enabled it in our local repository for our 
platform. Once these changes are merged, I plan to submit the enablement 
patches.

> Regards
> Peng

[PATCH 8/8] mmc: sdhci-cadence6: Add DLL master control and improve tuning reliability

[Tanmay Kathpalia]

- 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>
---
 drivers/mmc/sdhci-cadence6.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci-cadence6.c b/drivers/mmc/sdhci-cadence6.c
index d9467293807..91a245aa490 100644
--- a/drivers/mmc/sdhci-cadence6.c
+++ b/drivers/mmc/sdhci-cadence6.c
@@ -58,7 +58,7 @@
 #define PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY	GENMASK(31, 24)
 #define PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY		GENMASK(7, 0)
 
-#define SDHCI_CDNS6_PHY_CFG_NUM		4
+#define SDHCI_CDNS6_PHY_CFG_NUM		5
 #define SDHCI_CDNS6_CTRL_CFG_NUM	4
 
 struct sdhci_cdns6_phy_cfg {
@@ -76,6 +76,7 @@ static struct sdhci_cdns6_phy_cfg sd_ds_phy_cfgs[] = {
 	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-ds", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-sd-ds", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-sd-ds", 0x00000001, },
+	{ "cdns,phy-dll-master-ctrl-sd-ds", 0x00800004, },
 };
 
 static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
@@ -83,6 +84,7 @@ static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
 	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-hs", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-sd-hs", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-sd-hs", 0x00000001, },
+	{ "cdns,phy-dll-master-ctrl-sd-hs", 0x00800004, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
@@ -90,6 +92,7 @@ static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-sdr", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-sdr", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-emmc-sdr", 0x00000001, },
+	{ "cdns,phy-dll-master-ctrl-emmc-sdr", 0x00800004, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
@@ -97,6 +100,7 @@ static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-ddr", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-ddr", 0x00000000, },
 	{ "cdns,phy-dq-timing-delay-emmc-ddr", 0x10000001, },
+	{ "cdns,phy-dll-master-ctrl-emmc-ddr", 0x00800004, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
@@ -104,6 +108,7 @@ static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs200", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-hs200", 0x00DADA00, },
 	{ "cdns,phy-dq-timing-delay-emmc-hs200", 0x00000001, },
+	{ "cdns,phy-dll-master-ctrl-emmc-hs200", 0x00000004, },
 };
 
 static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
@@ -111,6 +116,7 @@ static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs400", 0x01A00040, },
 	{ "cdns,phy-dll-slave-ctrl-emmc-hs400", 0x00DAD800, },
 	{ "cdns,phy-dq-timing-delay-emmc-hs400", 0x00000001, },
+	{ "cdns,phy-dll-master-ctrl-emmc-hs400", 0x00000004, },
 };
 
 static struct sdhci_cdns6_ctrl_cfg sd_ds_ctrl_cfgs[] = {
@@ -252,6 +258,7 @@ int sdhci_cdns6_phy_adj(struct udevice *dev, struct sdhci_cdns_plat *plat, u32 m
 
 	sdhci_cdns6_write_phy_reg(plat, PHY_DQS_TIMING_REG_ADDR, sdhci_cdns6_phy_cfgs[0].val);
 	sdhci_cdns6_write_phy_reg(plat, PHY_GATE_LPBK_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[1].val);
+	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_MASTER_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[4].val);
 	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[2].val);
 
 	/* Switch Off the DLL Reset */
@@ -296,6 +303,7 @@ int sdhci_cdns6_phy_init(struct udevice *dev, struct sdhci_cdns_plat *plat)
 int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
 {
 	u32 tmp, tuneval;
+	int ret;
 
 	tuneval = (val * 256) / SDHCI_CDNS_MAX_TUNING_LOOP;
 
@@ -304,7 +312,18 @@ int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
 		 PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY);
 	tmp |= FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY, tuneval) |
 		FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY, tuneval);
+
+	/* Switch On the DLL Reset */
+	sdhci_cdns6_reset_phy_dll(plat, true);
+
 	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, tmp);
 
+	/* Switch Off the DLL Reset */
+	ret = sdhci_cdns6_reset_phy_dll(plat, false);
+	if (ret) {
+		printf("sdhci_cdns6_reset_phy is not completed\n");
+		return ret;
+	}
+
 	return 0;
 }
-- 
2.43.7

Re: [PATCH 8/8] mmc: sdhci-cadence6: Add DLL master control and improve tuning reliability

[Peng Fan]

On Mon, Nov 10, 2025 at 09:37:37AM -0800, Tanmay Kathpalia wrote:
>- 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>
>---
> drivers/mmc/sdhci-cadence6.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mmc/sdhci-cadence6.c b/drivers/mmc/sdhci-cadence6.c
>index d9467293807..91a245aa490 100644
>--- a/drivers/mmc/sdhci-cadence6.c
>+++ b/drivers/mmc/sdhci-cadence6.c
>@@ -58,7 +58,7 @@
> #define PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY	GENMASK(31, 24)
> #define PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY		GENMASK(7, 0)
> 
>-#define SDHCI_CDNS6_PHY_CFG_NUM		4
>+#define SDHCI_CDNS6_PHY_CFG_NUM		5
> #define SDHCI_CDNS6_CTRL_CFG_NUM	4
> 
> struct sdhci_cdns6_phy_cfg {
>@@ -76,6 +76,7 @@ static struct sdhci_cdns6_phy_cfg sd_ds_phy_cfgs[] = {
> 	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-ds", 0x01A00040, },
> 	{ "cdns,phy-dll-slave-ctrl-sd-ds", 0x00000000, },
> 	{ "cdns,phy-dq-timing-delay-sd-ds", 0x00000001, },
>+	{ "cdns,phy-dll-master-ctrl-sd-ds", 0x00800004, },
> };
> 
> static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
>@@ -83,6 +84,7 @@ static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
> 	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-hs", 0x01A00040, },
> 	{ "cdns,phy-dll-slave-ctrl-sd-hs", 0x00000000, },
> 	{ "cdns,phy-dq-timing-delay-sd-hs", 0x00000001, },
>+	{ "cdns,phy-dll-master-ctrl-sd-hs", 0x00800004, },
> };
> 
> static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
>@@ -90,6 +92,7 @@ static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-sdr", 0x01A00040, },
> 	{ "cdns,phy-dll-slave-ctrl-emmc-sdr", 0x00000000, },
> 	{ "cdns,phy-dq-timing-delay-emmc-sdr", 0x00000001, },
>+	{ "cdns,phy-dll-master-ctrl-emmc-sdr", 0x00800004, },
> };
> 
> static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
>@@ -97,6 +100,7 @@ static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-ddr", 0x01A00040, },
> 	{ "cdns,phy-dll-slave-ctrl-emmc-ddr", 0x00000000, },
> 	{ "cdns,phy-dq-timing-delay-emmc-ddr", 0x10000001, },
>+	{ "cdns,phy-dll-master-ctrl-emmc-ddr", 0x00800004, },
> };
> 
> static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
>@@ -104,6 +108,7 @@ static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs200", 0x01A00040, },
> 	{ "cdns,phy-dll-slave-ctrl-emmc-hs200", 0x00DADA00, },
> 	{ "cdns,phy-dq-timing-delay-emmc-hs200", 0x00000001, },
>+	{ "cdns,phy-dll-master-ctrl-emmc-hs200", 0x00000004, },
> };
> 
> static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
>@@ -111,6 +116,7 @@ static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs400", 0x01A00040, },
> 	{ "cdns,phy-dll-slave-ctrl-emmc-hs400", 0x00DAD800, },
> 	{ "cdns,phy-dq-timing-delay-emmc-hs400", 0x00000001, },
>+	{ "cdns,phy-dll-master-ctrl-emmc-hs400", 0x00000004, },
> };
> 
> static struct sdhci_cdns6_ctrl_cfg sd_ds_ctrl_cfgs[] = {
>@@ -252,6 +258,7 @@ int sdhci_cdns6_phy_adj(struct udevice *dev, struct sdhci_cdns_plat *plat, u32 m
> 
> 	sdhci_cdns6_write_phy_reg(plat, PHY_DQS_TIMING_REG_ADDR, sdhci_cdns6_phy_cfgs[0].val);
> 	sdhci_cdns6_write_phy_reg(plat, PHY_GATE_LPBK_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[1].val);
>+	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_MASTER_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[4].val);
> 	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[2].val);
> 
> 	/* Switch Off the DLL Reset */
>@@ -296,6 +303,7 @@ int sdhci_cdns6_phy_init(struct udevice *dev, struct sdhci_cdns_plat *plat)
> int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
> {
> 	u32 tmp, tuneval;
>+	int ret;
> 
> 	tuneval = (val * 256) / SDHCI_CDNS_MAX_TUNING_LOOP;
> 
>@@ -304,7 +312,18 @@ int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
> 		 PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY);
> 	tmp |= FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY, tuneval) |
> 		FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY, tuneval);
>+
>+	/* Switch On the DLL Reset */
>+	sdhci_cdns6_reset_phy_dll(plat, true);

There is no err return check, but

>+
> 	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, tmp);
> 
>+	/* Switch Off the DLL Reset */
>+	ret = sdhci_cdns6_reset_phy_dll(plat, false);

there is err check here. Should these be aligned or the usage is intentional?

Regards
Peng

>+	if (ret) {
>+		printf("sdhci_cdns6_reset_phy is not completed\n");
>+		return ret;
>+	}
>+
> 	return 0;
> }
>-- 
>2.43.7
>
>

Re: [PATCH 8/8] mmc: sdhci-cadence6: Add DLL master control and improve tuning reliability

[Tanmay Kathpalia]

On 11/18/2025 11:54 AM, Peng Fan wrote:
> On Mon, Nov 10, 2025 at 09:37:37AM -0800, Tanmay Kathpalia wrote:
>> - 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>
>> ---
>> drivers/mmc/sdhci-cadence6.c | 21 ++++++++++++++++++++-
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/sdhci-cadence6.c b/drivers/mmc/sdhci-cadence6.c
>> index d9467293807..91a245aa490 100644
>> --- a/drivers/mmc/sdhci-cadence6.c
>> +++ b/drivers/mmc/sdhci-cadence6.c
>> @@ -58,7 +58,7 @@
>> #define PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY	GENMASK(31, 24)
>> #define PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY		GENMASK(7, 0)
>>
>> -#define SDHCI_CDNS6_PHY_CFG_NUM		4
>> +#define SDHCI_CDNS6_PHY_CFG_NUM		5
>> #define SDHCI_CDNS6_CTRL_CFG_NUM	4
>>
>> struct sdhci_cdns6_phy_cfg {
>> @@ -76,6 +76,7 @@ static struct sdhci_cdns6_phy_cfg sd_ds_phy_cfgs[] = {
>> 	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-ds", 0x01A00040, },
>> 	{ "cdns,phy-dll-slave-ctrl-sd-ds", 0x00000000, },
>> 	{ "cdns,phy-dq-timing-delay-sd-ds", 0x00000001, },
>> +	{ "cdns,phy-dll-master-ctrl-sd-ds", 0x00800004, },
>> };
>>
>> static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
>> @@ -83,6 +84,7 @@ static struct sdhci_cdns6_phy_cfg sd_hs_phy_cfgs[] = {
>> 	{ "cdns,phy-gate-lpbk-ctrl-delay-sd-hs", 0x01A00040, },
>> 	{ "cdns,phy-dll-slave-ctrl-sd-hs", 0x00000000, },
>> 	{ "cdns,phy-dq-timing-delay-sd-hs", 0x00000001, },
>> +	{ "cdns,phy-dll-master-ctrl-sd-hs", 0x00800004, },
>> };
>>
>> static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
>> @@ -90,6 +92,7 @@ static struct sdhci_cdns6_phy_cfg emmc_sdr_phy_cfgs[] = {
>> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-sdr", 0x01A00040, },
>> 	{ "cdns,phy-dll-slave-ctrl-emmc-sdr", 0x00000000, },
>> 	{ "cdns,phy-dq-timing-delay-emmc-sdr", 0x00000001, },
>> +	{ "cdns,phy-dll-master-ctrl-emmc-sdr", 0x00800004, },
>> };
>>
>> static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
>> @@ -97,6 +100,7 @@ static struct sdhci_cdns6_phy_cfg emmc_ddr_phy_cfgs[] = {
>> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-ddr", 0x01A00040, },
>> 	{ "cdns,phy-dll-slave-ctrl-emmc-ddr", 0x00000000, },
>> 	{ "cdns,phy-dq-timing-delay-emmc-ddr", 0x10000001, },
>> +	{ "cdns,phy-dll-master-ctrl-emmc-ddr", 0x00800004, },
>> };
>>
>> static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
>> @@ -104,6 +108,7 @@ static struct sdhci_cdns6_phy_cfg emmc_hs200_phy_cfgs[] = {
>> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs200", 0x01A00040, },
>> 	{ "cdns,phy-dll-slave-ctrl-emmc-hs200", 0x00DADA00, },
>> 	{ "cdns,phy-dq-timing-delay-emmc-hs200", 0x00000001, },
>> +	{ "cdns,phy-dll-master-ctrl-emmc-hs200", 0x00000004, },
>> };
>>
>> static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
>> @@ -111,6 +116,7 @@ static struct sdhci_cdns6_phy_cfg emmc_hs400_phy_cfgs[] = {
>> 	{ "cdns,phy-gate-lpbk-ctrl-delay-emmc-hs400", 0x01A00040, },
>> 	{ "cdns,phy-dll-slave-ctrl-emmc-hs400", 0x00DAD800, },
>> 	{ "cdns,phy-dq-timing-delay-emmc-hs400", 0x00000001, },
>> +	{ "cdns,phy-dll-master-ctrl-emmc-hs400", 0x00000004, },
>> };
>>
>> static struct sdhci_cdns6_ctrl_cfg sd_ds_ctrl_cfgs[] = {
>> @@ -252,6 +258,7 @@ int sdhci_cdns6_phy_adj(struct udevice *dev, struct sdhci_cdns_plat *plat, u32 m
>>
>> 	sdhci_cdns6_write_phy_reg(plat, PHY_DQS_TIMING_REG_ADDR, sdhci_cdns6_phy_cfgs[0].val);
>> 	sdhci_cdns6_write_phy_reg(plat, PHY_GATE_LPBK_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[1].val);
>> +	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_MASTER_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[4].val);
>> 	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, sdhci_cdns6_phy_cfgs[2].val);
>>
>> 	/* Switch Off the DLL Reset */
>> @@ -296,6 +303,7 @@ int sdhci_cdns6_phy_init(struct udevice *dev, struct sdhci_cdns_plat *plat)
>> int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
>> {
>> 	u32 tmp, tuneval;
>> +	int ret;
>>
>> 	tuneval = (val * 256) / SDHCI_CDNS_MAX_TUNING_LOOP;
>>
>> @@ -304,7 +312,18 @@ int sdhci_cdns6_set_tune_val(struct sdhci_cdns_plat *plat, unsigned int val)
>> 		 PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY);
>> 	tmp |= FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_CMD_DELAY, tuneval) |
>> 		FIELD_PREP(PHY_DLL_SLAVE_CTRL_REG_READ_DQS_DELAY, tuneval);
>> +
>> +	/* Switch On the DLL Reset */
>> +	sdhci_cdns6_reset_phy_dll(plat, true);
> 
> There is no err return check, but
> 
>> +
>> 	sdhci_cdns6_write_phy_reg(plat, PHY_DLL_SLAVE_CTRL_REG_ADDR, tmp);
>>
>> +	/* Switch Off the DLL Reset */
>> +	ret = sdhci_cdns6_reset_phy_dll(plat, false);
> 
> there is err check here. Should these be aligned or the usage is intentional?
> 

The difference is intentional.
sdhci_cdns6_reset_phy_dll always returns 0 when the second argument is 
true (i.e., when switching the DLL reset On).
When switching the DLL reset Off (false), the function waits for the PHY 
initialization completion bit to be set within the defined time period, 
so a return value check is necessary to catch any failure during this step.

> Regards
> Peng
> 
>> +	if (ret) {
>> +		printf("sdhci_cdns6_reset_phy is not completed\n");
>> +		return ret;
>> +	}
>> +
>> 	return 0;
>> }
>> -- 
>> 2.43.7
>>
>>