1. 25 2月, 2009 6 次提交
  2. 06 2月, 2009 1 次提交
  3. 06 1月, 2009 2 次提交
  4. 06 12月, 2008 2 次提交
    • M
      [CPUFREQ] Fix on resume, now preserves user policy min/max. · 187d9f4e
      Mike Chan 提交于
      Previously driver resume would always set the current policy min/max with
      the cpuinfo min/max, defined by user_policy.min/max. Resulting in a reset
      of policy settings when policy.min/max != cpuinfo.min/max when coming out
      of suspend. Now user_policy is saved as the policy instead of cpuinfo to
      preserve what the user actually set.
      Signed-off-by: NMike Chan <mike@android.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      187d9f4e
    • M
      [CPUFREQ] Disable sysfs ui for p4-clockmod. · e088e4c9
      Matthew Garrett 提交于
      p4-clockmod has a long history of abuse.   It pretends to be a CPU
      frequency scaling driver, even though it doesn't actually change
      the CPU frequency, but instead just modulates the frequency with
      wait-states.
      The biggest misconception is that when running at the lower 'frequency'
      p4-clockmod is saving power.  This isn't the case, as workloads running
      slower take longer to complete, preventing the CPU from entering deep C states.
      
      However p4-clockmod does have a purpose.  It can prevent overheating.
      Having it hooked up to the cpufreq interfaces is the wrong way to achieve
      cooling however. It should instead be hooked up to ACPI.
      
      This diff introduces a means for a cpufreq driver to register with the
      cpufreq core, but not present a sysfs interface.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e088e4c9
  5. 10 10月, 2008 10 次提交
  6. 09 8月, 2008 1 次提交
  7. 31 7月, 2008 1 次提交
  8. 20 7月, 2008 1 次提交
  9. 10 6月, 2008 1 次提交
  10. 07 6月, 2008 1 次提交
  11. 30 5月, 2008 1 次提交
    • L
      [CPUFREQ] fix double unlock of cpu_policy_rwsem in drivers/cpufreq/cpufreq.c · dca02613
      Lothar Waßmann 提交于
      In drivers/cpufreq/cpufreq.c the function cpufreq_add_dev() takes the
      error exit 'err_out_unregister' from different places once with the
      'cpu_policy_rwsem' lock held, once with the lock released:
      |		if (ret)
      |			goto err_out_unregister;
      |	}
      |
      |	policy->governor = NULL; /* to assure that the starting sequence is
      |				  * run in cpufreq_set_policy */
      |
      |	/* set default policy */
      |	ret = __cpufreq_set_policy(policy, &new_policy);
      |	policy->user_policy.policy = policy->policy;
      |	policy->user_policy.governor = policy->governor;
      |
      |	unlock_policy_rwsem_write(cpu);
      |
      |	if (ret) {
      |		dprintk("setting policy failed\n");
      |		goto err_out_unregister;
      |	}
      
      This leads to the following error message in case of a failing
      __cpufreq_set_policy() call:
      =====================================
      [ BUG: bad unlock balance detected! ]
      -------------------------------------
      swapper/1 is trying to release lock (&per_cpu(cpu_policy_rwsem, cpu)) at:
      [<c01b4564>] unlock_policy_rwsem_write+0x30/0x40
      but there are no more locks to release!
      
      other info that might help us debug this:
      1 lock held by swapper/1:
       #0:  (sysdev_drivers_lock){--..}, at: [<c018fd18>] sysdev_driver_register+0x74/0x130
      
      stack backtrace:
      [<c002f588>] (dump_stack+0x0/0x14) from [<c00692fc>] (print_unlock_inbalance_bug+0xc8/0x104)
      [<c0069234>] (print_unlock_inbalance_bug+0x0/0x104) from [<c006b7ac>] (lock_release_non_nested+0xc4/0x19c)
       r6:00000028 r5:c3c1ab80 r4:c01b4564
      [<c006b6e8>] (lock_release_non_nested+0x0/0x19c) from [<c006b9e0>] (lock_release+0x15c/0x18c)
       r8:60000013 r7:00000001 r6:c01b4564 r5:c0541bb4 r4:c3c1ab80
      [<c006b884>] (lock_release+0x0/0x18c) from [<c0061ba0>] (up_write+0x24/0x30)
       r8:c0541b80 r7:00000000 r6:ffffffea r5:c3c34828 r4:c0541b8c
      [<c0061b7c>] (up_write+0x0/0x30) from [<c01b4564>] (unlock_policy_rwsem_write+0x30/0x40)
       r4:c3c34884
      [<c01b4534>] (unlock_policy_rwsem_write+0x0/0x40) from [<c01b4c40>] (cpufreq_add_dev+0x324/0x398)
      [<c01b491c>] (cpufreq_add_dev+0x0/0x398) from [<c018fd64>] (sysdev_driver_register+0xc0/0x130)
      [<c018fca4>] (sysdev_driver_register+0x0/0x130) from [<c01b3574>] (cpufreq_register_driver+0xbc/0x174)
      Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      dca02613
  12. 24 5月, 2008 1 次提交
  13. 23 5月, 2008 1 次提交
  14. 20 5月, 2008 1 次提交
  15. 29 4月, 2008 9 次提交
  16. 06 3月, 2008 1 次提交
    • S
      [CPUFREQ] fix section mismatch warnings · f6ebef30
      Sam Ravnborg 提交于
      Fix the following warnings:
      WARNING: vmlinux.o(.text+0xfe6711): Section mismatch in reference from the function cpufreq_unregister_driver() to the variable .cpuinit.data:cpufreq_cpu_notifier
      WARNING: vmlinux.o(.text+0xfe68af): Section mismatch in reference from the function cpufreq_register_driver() to the variable .cpuinit.data:cpufreq_cpu_notifier
      WARNING: vmlinux.o(.exit.text+0xc4fa): Section mismatch in reference from the function cpufreq_stats_exit() to the variable .cpuinit.data:cpufreq_stat_cpu_notifier
      
      The warnings were casued by references to unregister_hotcpu_notifier()
      from normal functions or exit functions.
      This is flagged by modpost as a potential error because
      it does not know that for the non HOTPLUG_CPU
      scenario the unregister_hotcpu_notifier() is a nop.
      Silence the warning by replacing the __initdata
      annotation with a __refdata annotation.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDave Jones <davej@codemonkey.org.uk>
      f6ebef30