On 07.09.26 20:44, Andrei Lalaev wrote:
> Hi Yao,
>
> On 07.09.26 20:08, Yao Zi wrote:
>> On Mon, Sep 07, 2026 at 04:54:35PM +0200, Andrei Lalaev wrote:
>>> Some samples of the Milk-V Duo and Duo 256M have issues with SD card
>>> communication. As a result, the SD card is not detected, or the correct
>>> mode is not selected.
>>>
>>> Configure SDHCI PHY in the same way as in downstream, to ensure
>>> that the PHY is initialized properly.
>>>
>>> Fixes: eb36f28ff721 ("mmc: cv1800b: Add sdhci driver support for cv1800b
>>> SoC")
>>> Signed-off-by: Andrei Lalaev <[email protected]>
>>> Link:
>>> https://lore.kernel.org/u-boot/[email protected]/
>>> ---
>>> drivers/mmc/cv1800b_sdhci.c | 25 +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c
>>> index b756649f90f3..5c129682daba 100644
>>> --- a/drivers/mmc/cv1800b_sdhci.c
>>> +++ b/drivers/mmc/cv1800b_sdhci.c
>>> @@ -8,11 +8,17 @@
>>> #include <sdhci.h>
>>> #include <linux/delay.h>
>>>
>>> +#define CV18XX_SDHCI_MSHC_CTRL 0x200
>>> +#define CV18XX_SDHCI_PHY_CONFIG 0x24c
>>> #define SDHCI_PHY_TX_RX_DLY 0x240
>>> #define MMC_MAX_CLOCK 375000000
>>> #define TUNE_MAX_PHCODE 128
>>>
>>> #define PHY_TX_SRC_INVERT BIT(8)
>>> +#define PHY_RX_SRC_INVERT BIT(24)
>>> +
>>> +#define CV18XX_LATANCY_1T BIT(1)
>>> +#define CV18XX_PHY_TX_BPS BIT(0)
>>>
>>> struct cv1800b_sdhci_plat {
>>> struct mmc_config cfg;
>>> @@ -64,10 +70,29 @@ static int cv1800b_execute_tuning(struct mmc *mmc, u8
>>> opcode)
>>> }
>>> #endif
>>>
>>> +static int cv1800b_deferred_probe(struct sdhci_host *host)
>>> +{
>>> + u32 val;
>>> +
>>> + val = sdhci_readl(host, CV18XX_SDHCI_MSHC_CTRL);
>>> + val |= CV18XX_LATANCY_1T;
>>> + sdhci_writel(host, val, CV18XX_SDHCI_MSHC_CTRL);
>>> +
>>> + val = sdhci_readl(host, CV18XX_SDHCI_PHY_CONFIG);
>>> + val |= CV18XX_PHY_TX_BPS;
>>> + sdhci_writel(host, val, CV18XX_SDHCI_PHY_CONFIG);
>>> +
>>> + val = PHY_TX_SRC_INVERT | PHY_RX_SRC_INVERT;
>>> + sdhci_writel(host, val, SDHCI_PHY_TX_RX_DLY);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> const struct sdhci_ops cv1800b_sdhci_sd_ops = {
>>> #if CONFIG_IS_ENABLED(MMC_SUPPORTS_TUNING)
>>> .platform_execute_tuning = cv1800b_execute_tuning,
>>> #endif
>>> + .deferred_probe = cv1800b_deferred_probe,
>>
>> Is there a reason to create a new function, instead of including the
>> logic somewhere already existing, for example, cv1800b_sdhci_reset()?
>> It seems to fit in cv1800b_sdhci_reset(), too, if it's for
>> initialization of the PHY.
>
>
> No, there is no particular reason. I simply didn't think about
> cv1800b_sdhci_reset (:
>
> Thank you for the hint! I'll check it and will probably move it to reset.
>
>
I've rechecked, and unfortunately, moving it to cv1800b_sdhci_reset() is not
an option because reset is called only from cv1800b_execute_tuning() and
not accessible to SDHCI core (unlike in Linux MMC subsystem).
So I think I'll just drop deferred_probe() (wasn't actually required)
and call the function directly from probe().
--
Best regards,
Andrei Lalaev
