Re: [PATCH v4 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 22, 2024 at 06:00:58PM +0100, Johan Hovold wrote:
> On Thu, Jan 25, 2024 at 01:05:08PM -0800, Bjorn Andersson wrote:
> > The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> > event that the GPU crashes, so that it can be restarted again. But in
> > the event that the power-domain is supplied through a dedicated
> > regulator (in contrast to being a subdomin of another power-domain),
> > something needs to turn that regulator on, both to make sure things are
> > powered and to match the operation in gdsc_disable().
> > 
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
> > Signed-off-by: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx>
> > ---
> >  drivers/clk/qcom/gdsc.c | 12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> > index 5358e28122ab..e7a4068b9f39 100644
> > --- a/drivers/clk/qcom/gdsc.c
> > +++ b/drivers/clk/qcom/gdsc.c
> > @@ -557,7 +557,15 @@ void gdsc_unregister(struct gdsc_desc *desc)
> >   */
> >  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
> >  {
> > -	/* Do nothing but give genpd the impression that we were successful */
> > -	return 0;
> > +	struct gdsc *sc = domain_to_gdsc(domain);
> > +	int ret = 0;
> > +
> > +	/* Enable the parent supply, when controlled through the regulator framework. */
> > +	if (sc->rsupply)
> > +		ret = regulator_enable(sc->rsupply);
> > +
> > +	/* Do nothing with the GDSC itself */
> > +
> > +	return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
> 
> This patch (and series) is now in mainline as commit 9187ebb954ab ("clk:
> qcom: gdsc: Enable supply reglator in GPU GX handler") and appears to be
> involved in triggering the below lockdep splat on boot of the Lenovo
> ThinkPad X13s.
> 
> Adding Ulf and the MSM DRM devs as well in case I blamed the wrong
> change here.

I've now verified that applying this series on top of 6.8 also triggers
the lockdep splat even if it is possible that it only exposed an
existing issue.

This is still a regression and also prevents using lockdep on these
platforms, which can lead to further locking issues being introduced
until this is fixed:

#regzbot ^introduced: 9187ebb954ab

Johan




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux