1. 15 Feb, 2017 1 commit
  2. 03 Feb, 2017 2 commits
  3. 21 Nov, 2016 2 commits
  4. 20 Sep, 2016 1 commit
  5. 19 Sep, 2016 1 commit
  6. 13 Sep, 2016 1 commit
    • Viresh Kumar's avatar
      cpufreq: create link to policy only for registered CPUs · 26619804
      Viresh Kumar authored
      
      
      If a cpufreq driver is registered very early in the boot stage (e.g.
      registered from postcore_initcall()), then cpufreq core may generate
      kernel warnings for it.
      
      In this case, the CPUs are brought online, then the cpufreq driver is
      registered, and then the CPU topology devices are registered. However,
      by the time cpufreq_add_dev() gets called, the cpu device isn't stored
      in the per-cpu variable (cpu_sys_devices,) which is read by
      get_cpu_device().
      
      So the cpufreq core fails to get device for the CPU, for which
      cpufreq_add_dev() was called in the first place and we will hit a
      WARN_ON(!cpu_dev).
      
      Even if we reuse the 'dev' parameter passed to cpufreq_add_dev() to
      avoid that warning, there might be other CPUs online that share the
      policy with the cpu for which cpufreq_add_dev() is called. Eventually
      get_cpu_device() will return NULL for them as well, and we will hit the
      same WARN_ON() again.
      
      In order to fix these issues, change cpufreq core to create links to the
      policy for a cpu only when cpufreq_add_dev() is called for that CPU.
      
      Reuse the 'real_cpus' mask to track that as well.
      
      Note that cpufreq_remove_dev() already handles removal of the links for
      individual CPUs and cpufreq_add_dev() has aligned with that now.
      
      Reported-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      26619804
  7. 31 Aug, 2016 1 commit
  8. 22 Jul, 2016 1 commit
  9. 21 Jul, 2016 2 commits
    • Viresh Kumar's avatar
      cpufreq: Disallow ->resolve_freq() for drivers providing ->target_index() · abe8bd02
      Viresh Kumar authored
      The handlers provided by cpufreq core are sufficient for resolving the
      frequency for drivers providing ->target_index(), as the core already
      has the frequency table and so ->resolve_freq() isn't required for such
      platforms.
      
      This patch disallows drivers with ->target_index() callback to use the
      ->resolve_freq() callback.
      
      Also, it fixes a potential kernel crash for drivers providing ->target()
      but no ->resolve_freq().
      
      Fixes: e3c06236
      
       "cpufreq: add cpufreq_driver_resolve_freq()"
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      abe8bd02
    • Steve Muckle's avatar
      cpufreq: add cpufreq_driver_resolve_freq() · e3c06236
      Steve Muckle authored
      
      
      Cpufreq governors may need to know what a particular target frequency
      maps to in the driver without necessarily wanting to set the frequency.
      Support this operation via a new cpufreq API,
      cpufreq_driver_resolve_freq(). This API returns the lowest driver
      frequency equal or greater than the target frequency
      (CPUFREQ_RELATION_L), subject to any policy (min/max) or driver
      limitations. The mapping is also cached in the policy so that a
      subsequent fast_switch operation can avoid repeating the same lookup.
      
      The API will call a new cpufreq driver callback, resolve_freq(), if it
      has been registered by the driver. Otherwise the frequency is resolved
      via cpufreq_frequency_table_target(). Rather than require ->target()
      style drivers to provide a resolve_freq() callback it is left to the
      caller to ensure that the driver implements this callback if necessary
      to use cpufreq_driver_resolve_freq().
      
      Suggested-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSteve Muckle <smuckle@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e3c06236
  10. 04 Jul, 2016 1 commit
  11. 28 Jun, 2016 1 commit
  12. 08 Jun, 2016 4 commits
  13. 02 Jun, 2016 5 commits
    • Rafael J. Wysocki's avatar
      cpufreq: stats: Make the stats code non-modular · 1aefc75b
      Rafael J. Wysocki authored
      
      
      The modularity of cpufreq_stats is quite problematic.
      
      First off, the usage of policy notifiers for the initialization
      and cleanup in the cpufreq_stats module is inherently racy with
      respect to CPU offline/online and the initialization and cleanup
      of the cpufreq driver.
      
      Second, fast frequency switching (used by the schedutil governor)
      cannot be enabled if any transition notifiers are registered, so
      if the cpufreq_stats module (that registers a transition notifier
      for updating transition statistics) is loaded, the schedutil governor
      cannot use fast frequency switching.
      
      On the other hand, allowing cpufreq_stats to be built as a module
      doesn't really add much value.  Arguably, there's not much reason
      for that code to be modular at all.
      
      For the above reasons, make the cpufreq stats code non-modular,
      modify the core to invoke functions provided by that code directly
      and drop the notifiers from it.
      
      Make the stats sysfs attributes appear empty if fast frequency
      switching is enabled as the statistics will not be updated in that
      case anyway (and returning -EBUSY from those attributes breaks
      powertop).
      
      While at it, clean up Kconfig help for the CPU_FREQ_STAT and
      CPU_FREQ_STAT_DETAILS options.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      1aefc75b
    • Viresh Kumar's avatar
      cpufreq: Use clamp_val() in __cpufreq_driver_target() · 910c6e88
      Viresh Kumar authored
      
      
      Use clamp_val() instead of open coding it.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      910c6e88
    • Viresh Kumar's avatar
      cpufreq: Send START policy notification after sending CREATE · 388612ba
      Viresh Kumar authored
      
      
      The sequence got a bit wrong as we are sending CPUFREQ_START
      notifications even before we have sent CPUFREQ_CREATE_POLICY.
      
      Fix it.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      388612ba
    • Rafael J. Wysocki's avatar
      cpufreq: Drop the 'initialized' field from struct cpufreq_governor · 9a15fb2c
      Rafael J. Wysocki authored
      
      
      The 'initialized' field in struct cpufreq_governor is only used by
      the conservative governor (as a usage counter) and the way that
      happens is far from straightforward and arguably incorrect.
      
      Namely, the value of 'initialized' is checked by
      cpufreq_dbs_governor_init() and cpufreq_dbs_governor_exit() and
      the results of those checks are passed (as the second argument) to
      the ->init() and ->exit() callbacks in struct dbs_governor.  Those
      callbacks are only implemented by the ondemand and conservative
      governors and ondemand doesn't use their second argument at all.
      In turn, the conservative governor uses it to decide whether or not
      to either register or unregister a transition notifier.
      
      That whole mechanism is not only unnecessarily convoluted, but also
      racy, because the 'initialized' field of struct cpufreq_governor is
      updated in cpufreq_init_governor() and cpufreq_exit_governor() under
      policy->rwsem which doesn't help if one of these functions is run
      twice in parallel for different policies (which isn't impossible in
      principle), for example.
      
      Instead of it, add a proper usage counter to the conservative
      governor and update it from cs_init() and cs_exit() which is
      guaranteed to be non-racy, as those functions are only called
      under gov_dbs_data_mutex which is global.
      
      With that in place, drop the 'initialized' field from struct
      cpufreq_governor as it is not used any more.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      9a15fb2c
    • Rafael J. Wysocki's avatar
      cpufreq: governor: Get rid of governor events · e788892b
      Rafael J. Wysocki authored
      
      
      The design of the cpufreq governor API is not very straightforward,
      as struct cpufreq_governor provides only one callback to be invoked
      from different code paths for different purposes.  The purpose it is
      invoked for is determined by its second "event" argument, causing it
      to act as a "callback multiplexer" of sorts.
      
      Unfortunately, that leads to extra complexity in governors, some of
      which implement the ->governor() callback as a switch statement
      that simply checks the event argument and invokes a separate function
      to handle that specific event.
      
      That extra complexity can be eliminated by replacing the all-purpose
      ->governor() callback with a family of callbacks to carry out specific
      governor operations: initialization and exit, start and stop and policy
      limits updates.  That also turns out to reduce the code size too, so
      do it.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      e788892b
  14. 01 Jun, 2016 1 commit
  15. 30 May, 2016 3 commits
  16. 18 May, 2016 3 commits
  17. 02 May, 2016 1 commit
  18. 18 Apr, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set · c9d9c929
      Rafael J. Wysocki authored
      Since governor operations are generally skipped if cpufreq_suspended
      is set, cpufreq_start_governor() should do nothing in that case.
      
      That function is called in the cpufreq_online() path, and may also
      be called from cpufreq_offline() in some cases, which are invoked
      by the nonboot CPUs disabing/enabling code during system suspend
      to RAM and resume.  That happens when all devices have been
      suspended, so if the cpufreq driver relies on things like I2C to
      get the current frequency, it may not be ready to do that then.
      
      To prevent problems from happening for this reason, make
      cpufreq_update_current_freq(), which is the only function invoked
      by cpufreq_start_governor() that doesn't check cpufreq_suspended
      already, return 0 upfront if cpufreq_suspended is set.
      
      Fixes: 3bbf8fe3
      
       (cpufreq: Always update current frequency before startig governor)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      c9d9c929
  19. 08 Apr, 2016 3 commits
  20. 01 Apr, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: Support for fast frequency switching · b7898fda
      Rafael J. Wysocki authored
      
      
      Modify the ACPI cpufreq driver to provide a method for switching
      CPU frequencies from interrupt context and update the cpufreq core
      to support that method if available.
      
      Introduce a new cpufreq driver callback, ->fast_switch, to be
      invoked for frequency switching from interrupt context by (future)
      governors supporting that feature via (new) helper function
      cpufreq_driver_fast_switch().
      
      Add two new policy flags, fast_switch_possible, to be set by the
      cpufreq driver if fast frequency switching can be used for the
      given policy and fast_switch_enabled, to be set by the governor
      if it is going to use fast frequency switching for the given
      policy.  Also add a helper for setting the latter.
      
      Since fast frequency switching is inherently incompatible with
      cpufreq transition notifiers, make it possible to set the
      fast_switch_enabled only if there are no transition notifiers
      already registered and make the registration of new transition
      notifiers fail if fast_switch_enabled is set for at least one
      policy.
      
      Implement the ->fast_switch callback in the ACPI cpufreq driver
      and make it set fast_switch_possible during policy initialization
      as appropriate.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      b7898fda
  21. 22 Mar, 2016 3 commits
  22. 18 Mar, 2016 1 commit