linux-toradex.git/drivers/cpufreq/Kconfig.x86, branch v3.12-rc2

cpufreq: X86_AMD_FREQ_SENSITIVITY: select CPU_FREQ_TABLE

2013-06-18T08:23:11+00:00

This CPUFreq driver uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.

Acked-by: Jacob Shin 
Acked-by: Arnd Bergmann 
Signed-off-by: Viresh Kumar

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

cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor

2013-04-10T11:19:26+00:00

Future AMD processors, starting with Family 16h, can provide software
with feedback on how the workload may respond to frequency change --
memory-bound workloads will not benefit from higher frequency, where
as compute-bound workloads will. This patch enables this "frequency
sensitivity feedback" to aid the ondemand governor to make better
frequency change decisions by hooking into the powersave bias.

Signed-off-by: Jacob Shin 
Acked-by: Thomas Renninger 
Acked-by: Borislav Petkov 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

Merge tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2013-02-21T20:05:51+00:00

Pull driver core patches from Greg Kroah-Hartman:
 "Here is the big driver core merge for 3.9-rc1

  There are two major series here, both of which touch lots of drivers
  all over the kernel, and will cause you some merge conflicts:

   - add a new function called devm_ioremap_resource() to properly be
     able to check return values.

   - remove CONFIG_EXPERIMENTAL

  Other than those patches, there's not much here, some minor fixes and
  updates"

Fix up trivial conflicts

* tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits)
  base: memory: fix soft/hard_offline_page permissions
  drivercore: Fix ordering between deferred_probe and exiting initcalls
  backlight: fix class_find_device() arguments
  TTY: mark tty_get_device call with the proper const values
  driver-core: constify data for class_find_device()
  firmware: Ignore abort check when no user-helper is used
  firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER
  firmware: Make user-mode helper optional
  firmware: Refactoring for splitting user-mode helper code
  Driver core: treat unregistered bus_types as having no devices
  watchdog: Convert to devm_ioremap_resource()
  thermal: Convert to devm_ioremap_resource()
  spi: Convert to devm_ioremap_resource()
  power: Convert to devm_ioremap_resource()
  mtd: Convert to devm_ioremap_resource()
  mmc: Convert to devm_ioremap_resource()
  mfd: Convert to devm_ioremap_resource()
  media: Convert to devm_ioremap_resource()
  iommu: Convert to devm_ioremap_resource()
  drm: Convert to devm_ioremap_resource()
  ...

cpufreq / intel_pstate: Change to disallow module build

2013-02-15T21:54:59+00:00

Load order is important in order for intel_pstate to take over as the
default scaling driver from acpi-cpufreq.

If both are built-in, acpi-cpufreq uses late_initcall() and
intel_pstate uses device_initcall() so it will be able to register as
the scaling before acpi-cpufreq for the processors supported by
intel_pstate.

If acpi-cpufreq is built as a module then intel_pstate still gets
first option to become the scaling driver.

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

cpufreq/x86: Add P-state driver for sandy bridge.

2013-02-09T11:56:04+00:00

Add a P-state driver for the Intel Sandy bridge processor. In cpufreq
terminology this driver implements a  scaling driver with an internal
governor.

When built into the the kernel this driver will be the preferred
scaling driver for Sandy bridge processors.

In addition to the interfaces provided by the cpufreq subsystem for
controlling scaling drivers. The user may control the behavior of the
driver via three sysfs files located in
"/sys/devices/system/cpu/intel_pstate".

  max_perf_pct: limits the maximum P state that will be requested by
  the driver stated as a percentage of the avail performance.

  min_perf_pct: limits the minimum P state that will be  requested by
  the driver stated as a percentage of the avail performance.

  no_turbo: limits the driver to selecting P states below the turbo
  frequency range.

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

Merge 3.8-rc5 into driver-core-next

2013-01-26T05:06:30+00:00

This resolves a gpio driver merge issue pointed out in linux-next.

Signed-off-by: Greg Kroah-Hartman

powernow-k8: Add a kconfig dependency on acpi-cpufreq

2013-01-18T12:43:44+00:00

Andreas reports in https://bugzilla.kernel.org/show_bug.cgi?id=51741
that with his Gentoo config, acpi-cpufreq wasn't enabled and
powernow-k8 couldn't handoff properly to acpi-cpufreq leading to
running without P-state support (i.e., cores are constantly in P0).

To alleaviate that, we need to make powernow-k8 depend on acpi-cpufreq
so that acpi-cpufreq is always present.

References: https://bugzilla.kernel.org/show_bug.cgi?id=51741
Reported-by: Andreas 
Signed-off-by: Borislav Petkov 
Cc: 3.7+ 
Signed-off-by: Rafael J. Wysocki

drivers/cpufreq: remove depends on CONFIG_EXPERIMENTAL

2013-01-11T19:38:05+00:00

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Acked-by: Rafael J. Wysocki

acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob

2012-09-09T20:05:20+00:00

The powernow-k8 driver supported a sysfs knob called "cpb", which was
instantiated per CPU, but actually acted globally for the whole
system. To keep some compatibility with this feature, we re-introduce
this behavior here, but:
a) only enable it on AMD CPUs and
b) protect it with a Kconfig switch

I'd like to consider this feature obsolete. Lets keep it around for
some kernel versions and then phase it out.

Signed-off-by: Andre Przywara 
Signed-off-by: Rafael J. Wysocki