[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPDyKFpohUibXp_ReVquAxYHY7vZ28P1XmOCTU5GPQdLKYEaNg@mail.gmail.com>
Date: Wed, 14 May 2025 17:12:44 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Shawn Lin <shawn.lin@...k-chips.com>, Heiko Stuebner <heiko@...ech.de>,
Elaine Zhang <zhangqing@...k-chips.com>, Finley Xiao <finley.xiao@...k-chips.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Sebastian Reichel <sebastian.reichel@...labora.com>,
Detlev Casanova <detlev.casanova@...labora.com>, kernel@...labora.com,
linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mmc@...r.kernel.org
Subject: Re: [PATCH v3] mmc: sdhci-of-dwcmshc: add PD workaround on RK3576
On Tue, 13 May 2025 at 16:27, Nicolas Frattaroli
<nicolas.frattaroli@...labora.com> wrote:
>
> 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@...labora.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@...el.com>
> > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.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.
Sure, it makes perfect sense!
>
> 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.
I added the fixes tag and a stable tag to point out that it should be
applied only for v6.15+.
>
> Kind regards,
> Nicolas Frattaroli
>
>
>
Kind regards
Uffe
Powered by blists - more mailing lists