Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 4月, 2020 1 次提交
  3. 27 3月, 2020 2 次提交
    • R
      cpufreq: intel_pstate: Select schedutil as the default governor · a00ec387
      由 Rafael J. Wysocki 提交于 
      Modify cpufreq Kconfig to select schedutil as the default governor
if the intel_pstate driver has been selected and SMP support is
enabled (because schedutil depends on SMP).

Also select schedutil as well as the performance governor from the
intel_pstate Kconfig section to ensure the equivalence of the passive
and active mode governor configuration options.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a00ec387
    • R
      cpufreq: intel_pstate: Simplify intel_pstate_cpu_init() · 5ac54113
      由 Rafael J. Wysocki 提交于 
      The initial policy value set by intel_pstate_cpu_init() depends on
whether or not CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is set, but
that is not necessary, because the core will set the policy to
"performance" in cpufreq_init_policy() if the default governor is
"performance" anyway.

Accordingly, change intel_pstate_cpu_init() to always set policy
to CPUFREQ_POLICY_POWERSAVE initially to provide a valid fallback
value to cpufreq_init_policy() in case the default cpufreq governor
is neither "powersave" nor "performance".
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5ac54113
  5. 25 3月, 2020 4 次提交
  7. 20 3月, 2020 1 次提交
  9. 17 3月, 2020 1 次提交
  11. 14 3月, 2020 2 次提交
  13. 13 3月, 2020 2 次提交
  15. 12 3月, 2020 1 次提交
  17. 11 3月, 2020 1 次提交
  19. 07 3月, 2020 1 次提交
  21. 06 3月, 2020 1 次提交
  23. 03 3月, 2020 2 次提交
  25. 27 2月, 2020 1 次提交
  27. 17 2月, 2020 1 次提交
  29. 12 2月, 2020 2 次提交
  31. 03 2月, 2020 1 次提交
  33. 29 1月, 2020 1 次提交
  35. 27 1月, 2020 1 次提交
    • R
      cpufreq: Avoid creating excessively large stack frames · 1e4f63ae
      由 Rafael J. Wysocki 提交于 
      In the process of modifying a cpufreq policy, the cpufreq core makes
a copy of it including all of the internals which is stored on the
CPU stack.  Because struct cpufreq_policy is relatively large, this
may cause the size of the stack frame to exceed the 2 KB limit and
so the GCC complains when -Wframe-larger-than= is used.

In fact, it is not necessary to copy the entire policy structure
in order to modify it, however.

First, because cpufreq_set_policy() obtains the min and max policy
limits from frequency QoS now, it is not necessary to pass the limits
to it from the callers.  The only things that need to be passed to it
from there are the new governor pointer or (if there is a built-in
governor in the driver) the "policy" value representing the governor
choice.  They both can be passed as individual arguments, though, so
make cpufreq_set_policy() take them this way and rework its callers
accordingly.  This avoids making copies of cpufreq policies in the
callers of cpufreq_set_policy().

Second, cpufreq_set_policy() still needs to pass the new policy
data to the ->verify() callback of the cpufreq driver whose task
is to sanitize the min and max policy limits.  It still does not
need to make a full copy of struct cpufreq_policy for this purpose,
but it needs to pass a few items from it to the driver in case they
are needed (different drivers have different needs in that respect
and all of them have to be covered).  For this reason, introduce
struct cpufreq_policy_data to hold copies of the members of
struct cpufreq_policy used by the existing ->verify() driver
callbacks and pass a pointer to a temporary structure of that
type to ->verify() (instead of passing a pointer to full struct
cpufreq_policy to it).

While at it, notice that intel_pstate and longrun don't really need
to verify the "policy" value in struct cpufreq_policy, so drop those
check from them to avoid copying "policy" into struct
cpufreq_policy_data (which allows it to be slightly smaller).

Also while at it fix up white space in a couple of places and make
cpufreq_set_policy() static (as it can be so).

Fixes: 3000ce3c ("cpufreq: Use per-policy frequency QoS")
Link: https://lore.kernel.org/linux-pm/CAMuHMdX6-jb1W8uC2_237m8ctCpsnGp=JCxqt8pCWVqNXHmkVg@mail.gmail.comReported-by: Nkbuild test robot <lkp@intel.com>
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      1e4f63ae
  37. 23 1月, 2020 1 次提交
  39. 20 1月, 2020 1 次提交
    • C
      cpufreq: brcmstb-avs: fix imbalance of cpufreq policy refcount · a48ac1c9
      由 chenqiwu 提交于 
      brcm_avs_cpufreq_get() calls cpufreq_cpu_get() to get the cpufreq
policy, meanwhile, it also increments the kobject reference count
to mark it busy. However, a corresponding call of cpufreq_cpu_put()
is ignored to decrement the kobject reference count back, which may
lead to a potential stuck risk that the cpuhp thread deadly waits
for dropping of kobject refcount when cpufreq policy free.

With this patch, the cpuhp thread can be easily exercised by
attempting to force an unbind of the CPUfreq driver.
Signed-off-by: Nchenqiwu <chenqiwu@xiaomi.com>
[ Viresh: Dropped !policy check ]
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      a48ac1c9
  41. 13 1月, 2020 1 次提交
  43. 07 1月, 2020 5 次提交
  45. 06 1月, 2020 1 次提交
  47. 30 12月, 2019 2 次提交
  49. 24 12月, 2019 1 次提交
    • S
      cpufreq: scmi: Match scmi device by both name and protocol id · 12b76626
      由 Sudeep Holla 提交于 
      The scmi bus now has support to match the driver with devices not only
based on their protocol id but also based on their device name if one is
available. This was added to cater the need to support multiple devices
and drivers for the same protocol.

Let us add the name "cpufreq" to scmi_device_id table in the driver so
that in matches only with device with the same name and protocol id
SCMI_PROTOCOL_PERF. This will help to add "devfreq" device/driver.

Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      12b76626
  51. 16 12月, 2019 1 次提交
  53. 09 12月, 2019 1 次提交