[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220905043543.huxq7mmpclto2h7k@vireshk-i7>
Date: Mon, 5 Sep 2022 10:05:43 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Clément Péron <peron.clem@...il.com>
Cc: k.konieczny@...sung.com,
Marek Szyprowski <m.szyprowski@...sung.com>,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
Viresh Kumar <vireshk@...nel.org>,
"open list:ALLWINNER CPUFREQ DRIVER" <linux-pm@...r.kernel.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Rafael Wysocki <rjw@...ysocki.net>,
Mark Brown <broonie@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] opp: core: add regulators enable and disable
On 03-09-22, 22:35, Clément Péron wrote:
> Today, I compiled my kernel without any program requiring GPU
> computing at boot. This makes the dev_pm_opp_set_rate() to never be
> called and so the regulator is not enabled before the regulator
> framework switches off all the regulators that haven't been enabled.
>
> Unfortunately switching off the GPU regulator makes my board hang..
Why does the board hang? I mean the kernel should boot fine with the
GPU disabled, isn't it ? Or is the regulator shared with some other
critical resource, or something else.
> I'm not sure what is the best approach to fix this.
>
> Is it required that the dev_pm_opp_set_rate() must be called one time
> at the GPU driver init?
Right now, Yes. And it looks like the right approach as well.
> Panfost already calls devfreq_recommended_opp() and dev_pm_opp_put()
> but that doesn't trigger dev_pm_opp_set_rate().
Can you also point to your code ? Which file are you working on ?
--
viresh
Powered by blists - more mailing lists