1. 08 Jul, 2016 2 commits
  2. 01 Jul, 2016 1 commit
  3. 22 Jun, 2016 2 commits
    • Jacob Pan's avatar
      idle_intel: Add Denverton · 0080d65b
      Jacob Pan authored
      Denverton is an Intel Atom based micro server which shares the same
      Goldmont architecture as Broxton. The available C-states on
      Denverton is a subset of Broxton with only C1, C1e, and C6.
      Signed-off-by: default avatarJacob Pan <jacob.jun.pan@linux.intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0080d65b
    • Paul Gortmaker's avatar
      drivers/idle: make intel_idle.c driver more explicitly non-modular · 02c4fae9
      Paul Gortmaker authored
      The Kconfig for this driver is currently declared with:
      
      config INTEL_IDLE
              bool "Cpuidle Driver for Intel Processors"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      This was done in commit 6ce9cd86
      ("intel_idle: disable module support") since "...the module capability
      is cauing more trouble than it is worth."
      
      This was done over 5y ago, and Daniel adds that:
      
          ...the modular support has been removed from almost all the cpuidle
          drivers and the cpuidle framework is no longer assuming driver could
          be unloaded.
      
          Removing the modular dead code in the driver makes sense as this
          what have been done in the others drivers.
      
      So lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      Since module_init translates to device_initcall in the non-modular
      case, the init ordering remains unchanged with this commit.  At a
      later date we might want to consider whether subsys_init or another
      init category seems more appropriate than device_init.
      
      We replace module.h with moduleparam.h since the file does declare
      some module parameters, and leaving them as such is currently the
      easiest way to remain compatible with existing boot arg use cases.
      
      Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
      
      Also note that we can't remove intel_idle_cpuidle_devices_uninit() as
      that is still used for unwind purposes if the init fails.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      02c4fae9
  4. 08 Jun, 2016 1 commit
    • Dave Hansen's avatar
      x86/intel_idle: Use Intel family macros for intel_idle · db73c5a8
      Dave Hansen authored
      Use the new INTEL_FAM6_* macros for intel_idle.c.  Also fix up
      some of the macros to be consistent with how some of the
      intel_idle code refers to the model.
      
      There's on oddity here: model 0x1F is uniquely referred to here
      and nowhere else that I could find.  0x1E/0x1F are just spelled
      out as "Intel Core i7 and i5 Processors" in the SDM or as "Intel
      processors based on the Nehalem, Westmere microarchitectures" in
      the RDPMC section.  Comments between tables 19-19 and 19-20 in
      the SDM seem to point to 0x1F being some kind of Westmere, so
      let's call it "WESTMERE2".
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: jacob.jun.pan@intel.com
      Cc: linux-pm@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160603001932.EE978EB9@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      db73c5a8
  5. 08 Apr, 2016 1 commit
  6. 07 Apr, 2016 12 commits
  7. 23 Mar, 2016 2 commits
  8. 10 Sep, 2015 1 commit
  9. 15 Aug, 2015 1 commit
    • Len Brown's avatar
      intel_idle: Skylake Client Support · 493f133f
      Len Brown authored
      Skylake Client CPU idle Power states (C-states)
      are similar to the previous generation, Broadwell.
      However, Skylake does get its own table with updated
      worst-case latency and average energy-break-even residency values.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      493f133f
  10. 26 Jul, 2015 1 commit
    • Len Brown's avatar
      intel_idle: allow idle states to be freeze-mode specific · 7dd0e0af
      Len Brown authored
      intel_idle uses a NULL "enter" field in a cpuidle state
      to recognize the invalid entry terminating a variable-length array.
      
      Linux-4.0 added support for the system-wide "freeze" state
      in cpuidle drivers via the new "enter_freeze" field.
      
      The natural way to expose a deep idle state for freeze,
      but not for run-time idle is to supply "enter_freeze" without "enter";
      so we update the driver to accept such states.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7dd0e0af
  11. 10 Apr, 2015 1 commit
  12. 03 Apr, 2015 2 commits
  13. 31 Mar, 2015 2 commits
    • Len Brown's avatar
      intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs · cab07a56
      Len Brown authored
      Support C-states for the Airmont core in the Cherrytrail and Braswell SOCs.
      The states are similar to those of Silvermont in Baytrail,
      except both flavors of C6 states are faster.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Cc: Kumar P Mahesh <mahesh.kumar.p@intel.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      cab07a56
    • Len Brown's avatar
      intel_idle: Update support for Silvermont Core in Baytrail SOC · d7ef7671
      Len Brown authored
      On some Silvermont-Core/Baytrail-SOC systems,
      C1E latency is higher than original specifications.
      Although C1E is still enumerated in CPUID.MWAIT.EDX,
      we delete the state from intel_idle to avoid latency impact.
      
      Under some conditions, the latency of the C6N-BYT and C6S-BYT states
      may exceed the specified values of 40 and 140 usec, respectively.
      Increase those values to 300 and 500 usec; to assure
      that the hardware does not violate constraints that may be set
      by the Linux PM_QOS sub-system.
      
      Also increase the C7-BYT target residency to 4.0 ms from 1.5 ms.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Cc: Kumar P Mahesh <mahesh.kumar.p@intel.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      d7ef7671
  14. 15 Feb, 2015 1 commit
  15. 10 Feb, 2015 1 commit
  16. 12 Nov, 2014 1 commit
    • Daniel Lezcano's avatar
      cpuidle: Invert CPUIDLE_FLAG_TIME_VALID logic · b82b6cca
      Daniel Lezcano authored
      The only place where the time is invalid is when the ACPI_CSTATE_FFH entry
      method is not set. Otherwise for all the drivers, the time can be correctly
      measured.
      
      Instead of duplicating the CPUIDLE_FLAG_TIME_VALID flag in all the drivers
      for all the states, just invert the logic by replacing it by the flag
      CPUIDLE_FLAG_TIME_INVALID, hence we can set this flag only for the acpi idle
      driver, remove the former flag from all the drivers and invert the logic with
      this flag in the different governor.
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b82b6cca
  17. 15 Aug, 2014 2 commits
  18. 21 Apr, 2014 1 commit
  19. 04 Apr, 2014 1 commit
    • Len Brown's avatar
      intel_idle: fine-tune IVT residency targets · 0138d8f0
      Len Brown authored
      Ivy Town processors have slightly different properties
      than Ivy Bridge processors, particuarly as socket count grows.
      Here we add dedicated tables covering 1-2 socket,
      3-4 socket, and > 4 socket IVT configurations.
      
      This reduces the frequency of deep transitions on those systems,
      which can impact throughput.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      0138d8f0
  20. 20 Mar, 2014 1 commit
    • Srivatsa S. Bhat's avatar
      intel-idle: Fix CPU hotplug callback registration · 07494d54
      Srivatsa S. Bhat authored
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the intel-idle code by using this latter form of callback registration.
      
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      07494d54
  21. 27 Feb, 2014 1 commit
  22. 19 Feb, 2014 2 commits
    • Len Brown's avatar
      intel_idle: support Bay Trail · 718987d6
      Len Brown authored
      Bay Trail (BYT) is a family of Silvermont-core Atom Processor SOCs,
      including the Intel Atom Processor Z36xxx and Z37xxx Series.
      
      Although it shares the Silvermont core with Avoton,
      BYT is optimized for mobile, and thus it supports
      different power saving CPU idle states.
      
      Note that not all versions of Bay Trail HW support all
      of the states listed in the driver.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Tested-by: default avatarAubrey Li <aubrey.li@linux.intel.com>
      718987d6
    • Len Brown's avatar
      intel_idle: allow sparse sub-state numbering, for Bay Trail · 24bfa950
      Len Brown authored
      Like acpi_idle, intel_idle compared sub-state numbers
      to the number of supported sub-states -- discarding
      sub-states numbers that were numbered >= the number of states.
      
      But some Bay Trail SOCs use sparse sub-state numbers,
      so we can't make such a comparison if we are going
      to access those states.
      
      So now we simply check that _some_ sub-states are
      supported for the given state, and assume that the
      sub-state number in our driver is valid.
      
      In practice, the driver is correct, and even if it were not,
      the hardware clips invalid sub-state requests to valid ones.
      
      No entries in the driver require this change,
      but Bay Trail will need it.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      24bfa950