[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240611052820.tp3xoto5fbd7figr@vireshk-i7>
Date: Tue, 11 Jun 2024 10:58:20 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Primoz Fiser <primoz.fiser@...ik.com>
Cc: Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, upstream@...ts.phytec.de
Subject: Re: [PATCH 2/2] OPP: ti: Use devm_pm_opp_set_config_regulators
On 10-06-24, 13:39, Primoz Fiser wrote:
> I didn't because of:
>
> config ARM_TI_CPUFREQ
>
> bool "Texas Instruments CPUFreq support"
>
>
> is a built-in driver.
This driver has confused me so many times.. The driver looks like a module,
since it declares all module properties but is builtin only :(
> Anyway, I guess one could trigger this also with:
>
> $ cd /sys/devices/platform/ocp/4a003b20.opp-supply/driver
> $ echo 4a003b20.opp-supply > unbind
> $ echo 4a003b20.opp-supply > bind
> -sh: echo: write error: Device or resource busy
>
> so the error comes from drivers/opp/core.c block:
>
> /* This should be called before OPPs are initialized */
> if (WARN_ON(!list_empty(&opp_table->opp_list))) {
> ret = -EBUSY;
> goto err;
> }
This is a different issue, which is unrelated to what we are discussing here. It
happens as the driver has registered the cpufreq device from init() callback
instead of probe() and remove() doesn't undo that.
> > The only way to get this solved is probably by introducing a remove()
> > method, which clears the OPP config and stores the token returned by
> > dev_pm_opp_set_config_regulators().
I will apply the V1 patch itself now. That is probably the best we can do for
now.
--
viresh
Powered by blists - more mailing lists