[PATCH v3] mmc: sdhci-of-dwcmshc: add PD workaround on RK3576
Nicolas Frattaroli
nicolas.frattaroli at collabora.com
Tue May 13 07:27:02 PDT 2025
On Tuesday, 29 April 2025 12:06:16 Central European Summer Time Ulf Hansson wrote:
> On Wed, 23 Apr 2025 at 09:54, Nicolas Frattaroli
> <nicolas.frattaroli at collabora.com> wrote:
> >
> > RK3576's power domains have a peculiar design where the PD_NVM power
> > domain, of which the sdhci controller is a part, seemingly does not have
> > idempotent runtime disable/enable. The end effect is that if PD_NVM gets
> > turned off by the generic power domain logic because all the devices
> > depending on it are suspended, then the next time the sdhci device is
> > unsuspended, it'll hang the SoC as soon as it tries accessing the CQHCI
> > registers.
> >
> > RK3576's UFS support needed a new dev_pm_genpd_rpm_always_on function
> > added to the generic power domains API to handle what appears to be a
> > similar hardware design.
> >
> > Use this new function to ask for the same treatment in the sdhci
> > controller by giving rk3576 its own platform data with its own postinit
> > function. The benefit of doing this instead of marking the power domains
> > always on in the power domain core is that we only do this if we know
> > the platform we're running on actually uses the sdhci controller. For
> > others, keeping PD_NVM always on would be a waste, as they won't run
> > into this specific issue. The only other IP in PD_NVM that could be
> > affected is FSPI0. If it gets a mainline driver, it will probably want
> > to do the same thing.
> >
> > Acked-by: Adrian Hunter <adrian.hunter at intel.com>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli at collabora.com>
>
> Applied for next, thanks!
>
> Kind regards
> Uffe
>
Hi Uffe,
I was wondering whether we can get this into 6.15 as a fix as well, as 6.15
should already have the genpd API additions this requires AFAIU.
Fixes tag could be something like:
Fixes: cfee1b507758 ("pmdomain: rockchip: Add support for RK3576 SoC")
but may need some more flavorings to keep the stable robot overlords from
trying to apply it to 6.14 and earlier and then starting the robot uprising
in your inbox when they notice the API is missing.
I originally left out the Fixes tag on the rewrite of this using the new
API because I wanted to avoid those awkward backport scenarios for a fairly
freshly supported SoC, but it'd be great to have this in 6.15 because that
will be with us for a full release cycle to come.
Kind regards,
Nicolas Frattaroli
More information about the Linux-rockchip
mailing list