1. 08 4月, 2013 3 次提交
  2. 02 4月, 2013 1 次提交
  3. 09 2月, 2013 3 次提交
  4. 02 2月, 2013 2 次提交
  5. 07 1月, 2013 1 次提交
  6. 03 1月, 2013 1 次提交
    • L
      cpufreq / governor: Fix problem with cpufreq_ondemand or cpufreq_conservative · 1e15f295
      Larry Finger 提交于
      Since commit 2aacdfff entitled "cpufreq: Move common part from governors
      to separate file", whenever the drivers that depend on this new file
      (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new
      module named cpufreq_governor is created because the Makefile includes
      cpufreq_governor.o twice. As drivers/cpufreq/cpufreq_governor.c contains no
      MODULE directives, the resulting module has no license specified, which
      results in logging of a "module license 'unspecified' taints kernel". In
      addition, a number of globals are exported GPL only, and are therefore
      not available. This fix establishes a new boolean configuration variable
      that forces cpufreq_governor.o to be linked into the kernel whenever
      either cpufreq_ondemand or cpufreq_conservative is selected.
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1e15f295
  7. 27 11月, 2012 1 次提交
  8. 15 11月, 2012 1 次提交
  9. 10 9月, 2012 2 次提交
  10. 15 3月, 2012 2 次提交
  11. 01 3月, 2012 1 次提交
    • H
      [CPUFREQ] Add S3C2416/S3C2450 cpufreq driver · 34ee5507
      Heiko Stübner 提交于
      The S3C2416/S3C2450 SoCs support two sources for the armclk.
      
      The first source is the so called armdiv which divides the msysclk down
      to provide necessary cpu rates. In this mode the core voltage must be
      always at 1.3V. The frequency from the armdiv is not allowed to be
      lower than the hclk frequency.
      
      In the second mode the armclk can be sourced directly from the hclk in
      the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv
      isn't used at all. Also in this mode the core voltage may be lowered.
      Existing hardware and tests with it suggest 1.0V as sufficient.
      
      When changing the clock source to the armdiv from the hclk, the SoC
      shows stability issues if the new frequency is higher than the current
      hclk frequency. Hence the driver always forces the armdiv to the hclk
      frequency before the source change and lets the cpufreq issue another
      set_target call for higher frequencies.
      
      To mark the hclk frequency as lower as the corresponding armdiv
      frequency it is set 1MHz below the real frequency. This lets the cpufreq
      framework change between 133MHz based on hclk and 133MHz based on armdiv
      at will.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NAndrey Gusakov <dron0gus@gmail.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      34ee5507
  12. 22 2月, 2012 1 次提交
  13. 09 1月, 2012 1 次提交
  14. 09 11月, 2011 1 次提交
  15. 19 7月, 2011 1 次提交
  16. 14 7月, 2011 4 次提交
  17. 25 5月, 2011 1 次提交
  18. 20 5月, 2011 1 次提交
  19. 01 6月, 2005 1 次提交
    • D
      [CPUFREQ] Conservative cpufreq governer · b9170836
      Dave Jones 提交于
      A new cpufreq module, based on the ondemand one with my additional patches
      just posted.  This one is more suitable for battery environments where its
      probably more appealing to have the cpu freq gracefully increase and decrease
      rather than flip between the min and max freq's.
      
      N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency
      between min and max freq transition, due to the step-by-step requirements
      (200MHz IIRC)"; so AMD64 users would probably benefit from this too.
      Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: NDave Jones <davej@redhat.com>
      b9170836
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4