[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190918092925.5hrvbcdorm2qw2j4@vireshk-mac-ubuntu>
Date: Wed, 18 Sep 2019 14:59:25 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Amit Kucheria <amit.kucheria@...aro.org>,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
bjorn.andersson@...aro.org, edubezval@...il.com, agross@...nel.org,
tdas@...eaurora.org, swboyd@...omium.org, ilina@...eaurora.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Zhang Rui <rui.zhang@...el.com>, linux-pm@...r.kernel.org
Subject: Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier
On 18-09-19, 10:17, Sudeep Holla wrote:
> Ah no, I am not referring to building as module. As you mention, that may
> work just fine. I was referring to timing dependency during boot. The idea
> is minimize the number of such initcall dependency. They should all work
> fine even as modules and should have least dependency on initcall sequence.
Yeah, so things work fine for them right now but that can be improved by
changing the sequence of boot here. And that's what Amit is trying to do here.
Even if android builds this as a module later, things will continue to work but
that may not be the best performance/boot-time wise.
When I had a discussion about this with Amit earlier, I asked him to send
patches even if he doesn't have any performance numbers for it as this is a
platform driver and I find it okay for them to decide the boot sequence that
they think is the best :)
--
viresh
Powered by blists - more mailing lists