On Thu, 20 Mar 2025 at 05:14, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > Hi, > > * Ulf Hansson <ulf.hansson@xxxxxxxxxx> [250312 11:56]: > > On Fri, 7 Mar 2025 at 05:28, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > Based on the symptoms, it sounds like there might be a missing flush of > > > a posted write in the PM runtime suspend/resume path. This could cause > > > something in the sequence happen in the wrong order for some of the > > > related surrounding resources like power, clocks or interrupts. > > > > SDIO is entirely different in this regard compared to eMMC/SD. So if > > there are no reports of issues I suggest we keep the SDIO part. > > Hmm just wondering if you have any guesses what causes the eMMC/SD related > PM to break? > > Regards, > > Tony Well, I have recently been looking a bit closer at the runtime PM support of the eMMC/SD card. We seem to have some kind of related problems [1], but I am not really sure yet. That said, I believe I may have found some *potential* issues and I am working on a few patches for it (for the mmc core), I will keep you and the people in $subject posted. Although, it's not quite clear to me, why these problems have turned up at this point and not a lot earlier. I have a feeling there is something that I am missing. Also note that, if the problems are sdhci/sdhci-omap specific, it becomes a bit more difficult for me to help out. Luckily, it seems like David shared a pretty simple script with us, which should reproduce the problem in just a few minutes. There are also debugfs and the runtime PM-sysfs interface one can use to play with the behaviour of MMC_CAP_AGGRESSIVE_PM. Kind regards Uffe [1] https://bugzilla.kernel.org/show_bug.cgi?id=218821 https://lore.kernel.org/all/CAPDyKFq4-fL3oHeT9phThWQJqzicKeA447WBJUbtcKPhdZ2d1A@xxxxxxxxxxxxxx/T/
