1. 22 1月, 2013 1 次提交
  2. 18 1月, 2013 1 次提交
  3. 03 1月, 2013 3 次提交
  4. 27 11月, 2012 2 次提交
    • F
      cpufreq: ondemand: update sampling rate only on right CPUs · 3e33ee9e
      Fabio Baltieri 提交于
      Fix cpufreq_gov_ondemand to skip CPU where another governor is used.
      
      The bug present itself as NULL pointer access on the mutex_lock() call,
      an can be reproduced on an SMP machine by setting the default governor
      to anything other than ondemand, setting a single CPU's governor to
      ondemand, then changing the sample rate by writing on:
      
      > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
      
      Backtrace:
      
      Nov 26 17:36:54 balto kernel: [  839.585241] BUG: unable to handle kernel NULL pointer dereference at           (null)
      Nov 26 17:36:54 balto kernel: [  839.585311] IP: [<ffffffff8174e082>] __mutex_lock_slowpath+0xb2/0x170
      [snip]
      Nov 26 17:36:54 balto kernel: [  839.587005] Call Trace:
      Nov 26 17:36:54 balto kernel: [  839.587030]  [<ffffffff8174da82>] mutex_lock+0x22/0x40
      Nov 26 17:36:54 balto kernel: [  839.587067]  [<ffffffff81610b8f>] store_sampling_rate+0xbf/0x150
      Nov 26 17:36:54 balto kernel: [  839.587110]  [<ffffffff81031e9c>] ?  __do_page_fault+0x1cc/0x4c0
      Nov 26 17:36:54 balto kernel: [  839.587153]  [<ffffffff813309bf>] kobj_attr_store+0xf/0x20
      Nov 26 17:36:54 balto kernel: [  839.587192]  [<ffffffff811bb62d>] sysfs_write_file+0xcd/0x140
      Nov 26 17:36:54 balto kernel: [  839.587234]  [<ffffffff8114c12c>] vfs_write+0xac/0x180
      Nov 26 17:36:54 balto kernel: [  839.587271]  [<ffffffff8114c472>] sys_write+0x52/0xa0
      Nov 26 17:36:54 balto kernel: [  839.587306]  [<ffffffff810321ce>] ?  do_page_fault+0xe/0x10
      Nov 26 17:36:54 balto kernel: [  839.587345]  [<ffffffff81751202>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NFabio Baltieri <fabio.baltieri@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3e33ee9e
    • D
      cpufreq: SPEAr: Add CPUFreq driver · 42099322
      Deepak Sikri 提交于
      SPEAr is an ARM based family of SoCs. This patch adds in support of cpufreq
      driver for SPEAr SoCs. It is supported via DT only and so bindings are present
      in binding document.
      Signed-off-by: NDeepak Sikri <deepak.sikri@st.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      42099322
  5. 24 11月, 2012 2 次提交
  6. 22 11月, 2012 2 次提交
  7. 21 11月, 2012 3 次提交
  8. 15 11月, 2012 12 次提交
  9. 10 11月, 2012 3 次提交
  10. 01 11月, 2012 1 次提交
  11. 23 10月, 2012 2 次提交
    • T
      Fix memory leak in cpufreq stats. · e3773677
      Tu, Xiaobing 提交于
      When system enters sleep, non-boot CPUs will be disabled.
      Cpufreq stats sysfs is created when the CPU is up, but it is not
      freed when the CPU is going down. This will cause memory leak.
      Signed-off-by: Nxiaobing tu <xiaobing.tu@intel.com>
      Signed-off-by: Nguifang tang <guifang.tang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e3773677
    • A
      cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code · e4df1cbc
      Andreas Herrmann 提交于
      Commit 6889125b
      (cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU)
      causes powernow-k8 to trigger a preempt warning, e.g.:
      
        BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776
        caller is powernowk8_target+0x20/0x49
        Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9
        Call Trace:
         [<ffffffff8125b447>] debug_smp_processor_id+0xc7/0xe0
         [<ffffffff814877e7>] powernowk8_target+0x20/0x49
         [<ffffffff81482b02>] __cpufreq_driver_target+0x82/0x8a
         [<ffffffff81484fc6>] cpufreq_governor_performance+0x4e/0x54
         [<ffffffff81482c50>] __cpufreq_governor+0x8c/0xc9
         [<ffffffff81482e6f>] __cpufreq_set_policy+0x1a9/0x21e
         [<ffffffff814839af>] store_scaling_governor+0x16f/0x19b
         [<ffffffff81484f16>] ? cpufreq_update_policy+0x124/0x124
         [<ffffffff8162b4a5>] ? _raw_spin_unlock_irqrestore+0x2c/0x49
         [<ffffffff81483640>] store+0x60/0x88
         [<ffffffff811708c0>] sysfs_write_file+0xf4/0x130
         [<ffffffff8111243b>] vfs_write+0xb5/0x151
         [<ffffffff811126e0>] sys_write+0x4a/0x71
         [<ffffffff816319a9>] system_call_fastpath+0x16/0x1b
      
      Fix this by by always using work_on_cpu().
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e4df1cbc
  12. 09 10月, 2012 4 次提交
  13. 20 9月, 2012 2 次提交
    • A
      cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_name · 1bae9958
      Axel Lin 提交于
      omap_device_get_by_hwmod_name() returns ERR_PTR on error.
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      1bae9958
    • T
      cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU · 6889125b
      Tejun Heo 提交于
      powernowk8_target() runs off a per-cpu work item and if the
      cpufreq_policy->cpu is different from the current one, it migrates the
      kworker to the target CPU by manipulating current->cpus_allowed.  The
      function migrates the kworker back to the original CPU but this is
      still broken.  Workqueue concurrency management requires the kworkers
      to stay on the same CPU and powernowk8_target() ends up triggerring
      BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
      fidvid_mutex and sleeps.
      
      It is unclear why this bug is being reported now.  Duncan says it
      appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
      3.5.  Bisection seemed to point to 63d95a91 "workqueue: use @pool
      instead of @gcwq or @cpu where applicable" which is an non-functional
      change.  Given that the reproduce case sometimes took upto days to
      trigger, it's easy to be misled while bisecting.  Maybe something made
      contention on fidvid_mutex more likely?  I don't know.
      
      This patch fixes the bug by using work_on_cpu() instead if @pol->cpu
      isn't the same as the current one.  The code assumes that
      cpufreq_policy->cpu is kept online by the caller, which Rafael tells
      me is the case.
      
      stable: ed48ece2 ("workqueue: reimplement work_on_cpu() using
              system_wq") should be applied before this; otherwise, the
              behavior could be horrible.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NDuncan <1i5t5.duncan@cox.net>
      Tested-by: NDuncan <1i5t5.duncan@cox.net>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
      6889125b
  14. 15 9月, 2012 2 次提交