linux.git/drivers/cpufreq, branch v3.10-rc4

Merge tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2013-05-26T03:32:00+00:00

Pull power management and ACPI fixes from Rafael Wysocki:

 - Additional CPU ID for the intel_pstate driver from Dirk Brandewie.

 - More cpufreq fixes related to ARM big.LITTLE support and locking from
   Viresh Kumar.

 - VIA C7 cpufreq build fix from Rafał Bilski.

 - ACPI power management fix making it possible to use device power
   states regardless of the CONFIG_PM setting from Rafael J Wysocki.

 - New ACPI video blacklist item from Bastian Triller.

* tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist
  cpufreq: arm_big_little_dt: Instantiate as platform_driver
  cpufreq: arm_big_little_dt: Register driver only if DT has valid data
  cpufreq / e_powersaver: Fix linker error when ACPI processor is a module
  cpufreq / intel_pstate: Add additional supported CPU ID
  cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT
  ACPI / PM: Allow device power states to be used for CONFIG_PM unset

cpufreq: arm_big_little_dt: Instantiate as platform_driver

2013-05-22T10:43:33+00:00

As multiplatform build is being adopted by more and more ARM platforms, initcall
function should be used very carefully. For example, when both arm_big_little_dt
and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to
register even if we had platform device for cpufreq-cpu0 registered.

To eliminate this undesired the effect, the patch changes arm_big_little_dt
driver to have it instantiated as a platform_driver. Then it will only run on
platforms that create the platform_device "arm-bL-cpufreq-dt".

Reported-and-tested-by: Rob Herring 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: arm_big_little_dt: Register driver only if DT has valid data

2013-05-22T10:42:34+00:00

If arm_big_little_dt driver is enabled, then it will always try to register with
big LITTLE cpufreq core driver. In case DT doesn't have relevant data for cpu
nodes, i.e. operating points aren't present, then we should exit early and
shouldn't register with big LITTLE cpufreq core driver. Otherwise we will fail
continuously from the driver->init() routine.

This patch fixes this issue.

Reported-and-tested-by: Jon Medhurst 
Reviewed-by: Jon Medhurst 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq / e_powersaver: Fix linker error when ACPI processor is a module

2013-05-22T10:41:25+00:00

on i386:
CONFIG_ACPI_PROCESSOR=m
CONFIG_X86_E_POWERSAVER=y

drivers/built-in.o: In function `eps_cpu_init.part.8':
e_powersaver.c:(.text.unlikely+0x2243): undefined reference to `acpi_processor_register_performance'
e_powersaver.c:(.text.unlikely+0x22a2): undefined reference to `acpi_processor_unregister_performance'
e_powersaver.c:(.text.unlikely+0x246b): undefined reference to `acpi_processor_get_bios_limit'

X86_E_POWERSAVER should also depend on ACPI_PROCESSOR.

Signed-off-by: Rafal Bilski 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

MIPS: Idle: Consolidate all declarations in .

2013-05-21T23:34:27+00:00

Signed-off-by: Ralf Baechle

MIPS: Idle: Re-enable irqs at the end of r3081, au1k and loongson2 cpu_wait.

2013-05-21T23:34:26+00:00

Without this, the

    WARN_ON_ONCE(irqs_disabled());

in the idle loop will be triggered.

Signed-off-by: Ralf Baechle

cpufreq / intel_pstate: Add additional supported CPU ID

2013-05-21T22:28:44+00:00

Add CPU ID for Ivybrigde processor.

Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki

cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT

2013-05-21T22:23:54+00:00

With the rwsem lock around
__cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT), we
get circular dependency when we call sysfs_remove_group().

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.9.0-rc7+ #15 Not tainted
 -------------------------------------------------------
 cat/2387 is trying to acquire lock:
  (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}, at: [] lock_policy_rwsem_read+0x25/0x34

 but task is already holding lock:
  (s_active#41){++++.+}, at: [] sysfs_read_file+0x4f/0xcc

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

-> #1 (s_active#41){++++.+}:
        [] lock_acquire+0x61/0xbc
        [] sysfs_addrm_finish+0xc1/0x128
        [] sysfs_hash_and_remove+0x35/0x64
        [] remove_files.isra.0+0x1b/0x24
        [] sysfs_remove_group+0x2d/0xa8
        [] cpufreq_governor_interactive+0x13b/0x35c
        [] __cpufreq_governor+0x2b/0x8c
        [] __cpufreq_set_policy+0xa9/0xf8
        [] store_scaling_governor+0x61/0x100
        [] store+0x39/0x60
        [] sysfs_write_file+0xed/0x114
        [] vfs_write+0x65/0xd8
        [] sys_write+0x2f/0x50
        [] ret_fast_syscall+0x1/0x52

-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}:
        [] __lock_acquire+0xef3/0x13dc
        [] lock_acquire+0x61/0xbc
        [] down_read+0x25/0x30
        [] lock_policy_rwsem_read+0x25/0x34
        [] show+0x21/0x58
        [] sysfs_read_file+0x67/0xcc
        [] vfs_read+0x63/0xd8
        [] sys_read+0x2f/0x50
        [] ret_fast_syscall+0x1/0x52

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(s_active#41);
                                lock(&per_cpu(cpu_policy_rwsem, cpu));
                                lock(s_active#41);
   lock(&per_cpu(cpu_policy_rwsem, cpu));

  *** DEADLOCK ***

 2 locks held by cat/2387:
  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_read_file+0x25/0xcc
  #1:  (s_active#41){++++.+}, at: [] sysfs_read_file+0x4f/0xcc

 stack backtrace:
 [] (unwind_backtrace+0x1/0x9c) from [] (print_circular_bug+0x19d/0x1e8)
 [] (print_circular_bug+0x19d/0x1e8) from [] (__lock_acquire+0xef3/0x13dc)
 [] (__lock_acquire+0xef3/0x13dc) from [] (lock_acquire+0x61/0xbc)
 [] (lock_acquire+0x61/0xbc) from [] (down_read+0x25/0x30)
 [] (down_read+0x25/0x30) from [] (lock_policy_rwsem_read+0x25/0x34)
 [] (lock_policy_rwsem_read+0x25/0x34) from [] (show+0x21/0x58)
 [] (show+0x21/0x58) from [] (sysfs_read_file+0x67/0xcc)
 [] (sysfs_read_file+0x67/0xcc) from [] (vfs_read+0x63/0xd8)
 [] (vfs_read+0x63/0xd8) from [] (sys_read+0x2f/0x50)
 [] (sys_read+0x2f/0x50) from [] (ret_fast_syscall+0x1/0x52)

This lock isn't required while calling __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT). Remove it.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Preserve sysfs files across suspend/resume

2013-05-15T19:47:17+00:00

The file permissions of cpufreq per-cpu sysfs files are not preserved
across suspend/resume because we internally go through the CPU
Hotplug path which reinitializes the file permissions on CPU online.

But the user is not supposed to know that we are using CPU hotplug
internally within suspend/resume (IOW, the kernel should not silently
wreck the user-set file permissions across a suspend cycle).
Therefore, we need to preserve the file permissions as they are
across suspend/resume.

The simplest way to achieve that is to just not touch the sysfs files
at all - ie., just ignore the CPU hotplug notifications in the
suspend/resume path (_FROZEN) in the cpufreq hotplug callback.

Reported-by: Robert Jarzmik 
Reported-by: Durgadoss R 
Signed-off-by: Srivatsa S. Bhat 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: use vzalloc() instead of vmalloc()/memset(0)

2013-05-13T23:39:28+00:00

Use vzalloc() instead of vmalloc() and memset(0).

Signed-off-by: Wei Yongjun 
Acked-by: Viresh Kumar 
Acked-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki