LMH DCVS is no more registering cpufreq cooling device. cpufreq
has to register cpufreq cooling device for each policy by default.
Remove LMH DCVS node check before cpufreq cooling register in
cpufreq ready callback.
Change-Id: I4476aac3c5aecfd438b0671eb0a9ab8ad535eebb
Signed-off-by: Asha Magadi Venkateshamurthy <amagad@codeaurora.org>
When use common cpufreq table, fix missing register pm notifier and
cpufreq driver register.
Change-Id: I8432696c81c941c641d9ee1db6385e9e94c3a012
Signed-off-by: Maria Yu <aiquny@codeaurora.org>
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
Thermal cooling device has to be registered when the policy for a CPU is
ready. Cpufreq will get a callback when a cpufreq policy is ready and
register CPU cooling device as a part of this callback, so that the CPU
can be mitigated immediately if needed.
Ignore cpu cooling device registration when there is platform cooling
device available.
Change-Id: I7cfb8598aa8ead4091a617da3faddf86ff0fe6a8
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
[avilaj@codeaurora.org: Modify to support 4.19 API changes]
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
The topology driver keeps track of the current capacity of a CPU
and make it available via arch_scale_freq_capacity(). The PELT
load tracking in the scheduler and energy-aware task placement
are the clients of this API. Hence notify the new frequency to the
topology driver during frequency transition.
Change-Id: I6dae674ba3b9d4c745b3caff59b165215926d970
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
As remote cpufreq updates are supported on MSM platforms, set
dvfs_possible_from_any_cpu cpufreq driver flag.
Change-Id: I7d8a1a22a512fe87929a7a59724fec6a577bcb05
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
This driver implements resolved_freq and target methods.
Since target method does not know the resolved frequency
index, the frequency table look up is needed again. We
can optimize this by caching the resolved frequency
index in the resolved_freq method.
Change-Id: Ib303ef57c51ce50de52b759728bc8c162a90dc29
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
[avilaj@codeaurora.org: Fix some merge conflicts]
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
The resolve_freq method is needed for schedutil to avoid
calling into cpufreq for changing to the same frequency
again and again.
Change-Id: Ia03cc49e3b8bad68fa2fda5688c64233b4b2c48d
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
__cpufreq_driver_target() checks if policy->cur is same as target_freq
without holding any lock. This function is used by governor to
directly set CPU frequency. Governor calling this function can't hold
any CPUfreq framework locks due to deadlock possibility.
However, this results in a race condition where one thread could see
a stale policy->cur while another thread is changing CPU frequency.
Thread A: Governor calls __cpufreq_driver_target(), starts increasing
frequency but hasn't sent out CPUFREQ_POSTCHANGE notification yet.
Thread B: Some other driver (could be thermal mitigation) starts
limiting frequency using cpufreq_update_policy(). Every limits are
applied to policy->min/max and final policy->max happens to be same as
policy->cur. __cpufreq_driver_target() simply returns 0.
Thread A: Governor finish scaling and now policy->cur violates
policy->max and could last forever until next CPU frequency scaling
happens.
Shifting the responsibility of checking policy->cur and target_freq
to CPUfreq device driver would resolve the race as long as the device
driver holds a common mutex.
Change-Id: I6f943228e793a4a4300c58b3ae0143e09ed01d7d
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
We don't handle probe defer very well in this driver. If the
platform_driver_register() call doesn't immediately probe the
driver there, or if that driver probe defers for some reason,
then the cpufreq driver registration in msm_cpufreq_register()
will fail due to a missing frequency table. Let's move the
cpufreq driver registration (and platform suspend hook part) into
the platform driver probe path, so we handle probe defer properly
and avoid any issues with order of initializations.
Change-Id: I14b514d46239f52b535563d49fb5c19d06072c3a
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
This is a snapshot of qcom-cpufreq as of msm-3.10 commit
Commit acdce027751d (Merge "defconfig: arm64: Enable
ONESHOT_SYNC for msm8994").
Change-Id: Idb99a856330566ffad6309c48edabb220cee7917
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[junjiew@codeaurora.org: resolved conflicts in Kconfig.arm and Makefile. Dropped dependency on ARCH_MSM.]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
[dkeitel@codeaurora.org: skip frequencies that round to same rate]
Signed-off-by: David Keitel <dkeitel@codeaurora.org>
[gsantosh@codeaurora.org: adapt to opensource clock framework]
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
[pkondeti@codeaurora.org: Remove superfluous NULL]
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[avilaj@codeaurora.org: move documentation to separate patch]
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
