* Romain Naour <romain.naour@xxxxxxxx> [240201 09:04]:
> Le 31/01/2024 à 11:30, Tony Lindgren a écrit :
> > * Romain Naour <romain.naour@xxxxxxxx> [240130 11:20]:
> >> Le 29/01/2024 à 18:42, Romain Naour a écrit :
> >>> Le 29/01/2024 à 12:17, Tony Lindgren a écrit :
> >>>> So I'm still guessing your issue is with emmc not getting reinitialized
> >>>> properly as there's no mmc-pwrseq-emmc configured. Can you give it a
> >>>> try? See am5729-beagleboneai.dts for an example.
> >>
> >> I can't add such mmc-pwrseq-emmc on the custom board, there is no gpio available
> >> to reset the emmc device.
> >>
> >> To resume:
> >> - the emmc doesn't work with mmc-hs200-1_8v mode with PM runtime enabled
> >> - the emmc works with mmc-hs200-1_8v mode without PM runtime (patch series reverted)
> >> - the emmc works with mmc-ddr-1_8v mode with PM runtime enabled
> >>
> >> AFAIU the hs200 mode requires some pin iodelay tuning (SDHCI_OMAP_REQUIRE_IODELAY)
> >> is sdhci_omap_runtime_{suspend,resume} needs to take care of that?
On PM runtime resume, sdhci_omap_runtime_resume() gets called and calls
sdhci_runtime_resume_host(), and calls mmc->ops->set_ios().
Then sdhci_omap_set_ios() calls sdhci_omap_set_timing() to set the iodelay.
Maybe add some printk to sdhci_omap_set_timing() to verify the right modes
get set on PM runtime resume?
> >> The mmc2 clock seems idle when mmc-hs200-1_8v and PM runtime are used.
> >>
> >> omapconf dump prcm l3init
> >>
> >> (mmc2 clock idle)
> >> | CM_L3INIT_MMC2_CLKCTRL | 0x4A009330 | 0x01070000 |
> >>
> >> (mmc2 clock running)
> >> | CM_L3INIT_MMC2_CLKCTRL | 0x4A009330 | 0x01040002 |
> >>
> >> Thoughts?
For the clocks above, that is as expected. The clocks get idled when the
MMC controller is idle.
> > OK so if the emmc reset gpio is not available, seems we should do something
> > like the following patch to not set MMC_CAP_POWER_OFF_CARD unless the
> > cap-power-off-card devicetree property is set.
> >
> > Care to give it a try and see if it helps?
>
> Same problem without MMC_CAP_POWER_OFF_CARD flag (even by removing
> MMC_CAP_AGGRESSIVE_PM too).
>
> I did some test with mmc capabilities mask but no progress so far.
OK. So this issue seems to be related to the PM runtime resume not
restoring something properly as you suggested earlier.
Regards,
Tony
