1. 16 Jul, 2019 1 commit
  2. 19 Jun, 2019 1 commit
  3. 21 Dec, 2016 1 commit
  4. 29 Apr, 2014 1 commit
  5. 07 Apr, 2014 1 commit
    • Viresh Kumar's avatar
      cpufreq: create another field .flags in cpufreq_frequency_table · 7f4b0461
      Viresh Kumar authored
      Currently cpufreq frequency table has two fields: frequency and driver_data.
      driver_data is only for drivers' internal use and cpufreq core shouldn't use
      it at all. But with the introduction of BOOST frequencies, this assumption
      was broken and we started using it as a flag instead.
      There are two problems due to this:
      - It is against the description of this field, as driver's data is used by
        the core now.
      - if drivers fill it with -3 for any frequency, then those frequencies are
        never considered by cpufreq core as it is exactly same as value of
        CPUFREQ_BOOST_FREQ, i.e. ~2.
      The best way to get this fixed is by creating another field flags which
      will be used for such flags. This patch does that. Along with that various
      drivers need modifications due to the change of struct cpufreq_frequency_table.
      Reviewed-by: default avatarGautham R Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  6. 17 Jan, 2014 1 commit
  7. 06 Jan, 2014 1 commit
    • Viresh Kumar's avatar
      cpufreq: Mark ARM drivers with CPUFREQ_NEED_INITIAL_FREQ_CHECK flag · ae6b4271
      Viresh Kumar authored
      Sometimes boot loaders set CPU frequency to a value outside of frequency table
      present with cpufreq core. In such cases CPU might be unstable if it has to run
      on that frequency for long duration of time and so its better to set it to a
      frequency which is specified in frequency table.
      On some systems we can't really say what frequency we're running at the moment
      and so for these we shouldn't check if we are running at a frequency present in
      frequency table. And so we really can't force this for all the cpufreq drivers.
      Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that
      will be marked by platforms which want to go for this check at boot time.
      Initially this is done for all ARM platforms but others may follow if required.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  8. 30 Oct, 2013 1 commit
  9. 25 Oct, 2013 1 commit
    • Viresh Kumar's avatar
      cpufreq: Implement light weight ->target_index() routine · 9c0ebcf7
      Viresh Kumar authored
      Currently, the prototype of cpufreq_drivers target routines is:
      int target(struct cpufreq_policy *policy, unsigned int target_freq,
      		unsigned int relation);
      And most of the drivers call cpufreq_frequency_table_target() to get a valid
      index of their frequency table which is closest to the target_freq. And they
      don't use target_freq and relation after that.
      So, it makes sense to just do this work in cpufreq core before calling
      cpufreq_frequency_table_target() and simply pass index instead. But this can be
      done only with drivers which expose their frequency table with cpufreq core. For
      others we need to stick with the old prototype of target() until those drivers
      are converted to expose frequency tables.
      This patch implements the new light weight prototype for target_index() routine.
      It looks like this:
      int target_index(struct cpufreq_policy *policy, unsigned int index);
      CPUFreq core will call cpufreq_frequency_table_target() before calling this
      routine and pass index to it. Because CPUFreq core now requires to call routines
      present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.
      This also marks target() interface as deprecated. So, that new drivers avoid
      using it. And Documentation is updated accordingly.
      It also converts existing .target() to newly defined light weight
      .target_index() routine for many driver.
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarRussell King <linux@arm.linux.org.uk>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Tested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@rjwysocki.net>
  10. 16 Oct, 2013 1 commit
  11. 15 Oct, 2013 3 commits
  12. 30 Sep, 2013 2 commits
  13. 10 Aug, 2013 1 commit
  14. 24 Jun, 2013 1 commit
  15. 04 Jun, 2013 1 commit
  16. 02 Apr, 2013 1 commit
  17. 01 Mar, 2012 1 commit
  18. 09 Dec, 2011 1 commit
  19. 31 Oct, 2011 1 commit
  20. 13 Jul, 2011 5 commits
  21. 15 Mar, 2011 1 commit
  22. 20 Feb, 2010 1 commit
  23. 01 Dec, 2009 3 commits
  24. 16 Jun, 2009 1 commit
    • Mark Brown's avatar
      [ARM] S3C64XX: Initial support for DVFS · b3748ddd
      Mark Brown authored
      This patch provides initial support for CPU frequency scaling on the
      Samsung S3C ARM processors. Currently only S3C6410 processors are
      supported, though addition of another data table with supported clock
      rates should be sufficient to enable support for further CPUs.
      Use the regulator framework to provide optional support for DVFS in
      the S3C cpufreq driver. When a software controllable regulator is
      configured the driver will use it to lower the supply voltage when
      running at a lower frequency, giving improved power savings.
      When regulator support is disabled or no regulator can be obtained
      for VDDARM the driver will fall back to scaling only the frequency.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>