1. 23 6月, 2016 2 次提交
    • J
      idle_intel: Add Denverton · 0080d65b
      Jacob Pan 提交于
      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: NJacob Pan <jacob.jun.pan@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0080d65b
    • P
      drivers/idle: make intel_idle.c driver more explicitly non-modular · 02c4fae9
      Paul Gortmaker 提交于
      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: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      02c4fae9
  2. 08 6月, 2016 1 次提交
    • D
      x86/intel_idle: Use Intel family macros for intel_idle · db73c5a8
      Dave Hansen 提交于
      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: NDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: NRafael 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: NIngo Molnar <mingo@kernel.org>
      db73c5a8
  3. 09 4月, 2016 1 次提交
  4. 08 4月, 2016 12 次提交
  5. 24 3月, 2016 2 次提交
  6. 11 9月, 2015 1 次提交
  7. 16 8月, 2015 1 次提交
  8. 27 7月, 2015 1 次提交
    • L
      intel_idle: allow idle states to be freeze-mode specific · 7dd0e0af
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      7dd0e0af
  9. 11 4月, 2015 1 次提交
  10. 03 4月, 2015 2 次提交
  11. 01 4月, 2015 2 次提交
    • L
      intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs · cab07a56
      Len Brown 提交于
      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: NLen 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
    • L
      intel_idle: Update support for Silvermont Core in Baytrail SOC · d7ef7671
      Len Brown 提交于
      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: NLen 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
  12. 16 2月, 2015 1 次提交
  13. 11 2月, 2015 1 次提交
  14. 13 11月, 2014 1 次提交
    • D
      cpuidle: Invert CPUIDLE_FLAG_TIME_VALID logic · b82b6cca
      Daniel Lezcano 提交于
      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: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b82b6cca
  15. 16 8月, 2014 2 次提交
  16. 22 4月, 2014 1 次提交
  17. 05 4月, 2014 1 次提交
    • L
      intel_idle: fine-tune IVT residency targets · 0138d8f0
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      0138d8f0
  18. 20 3月, 2014 1 次提交
    • S
      intel-idle: Fix CPU hotplug callback registration · 07494d54
      Srivatsa S. Bhat 提交于
      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: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      07494d54
  19. 28 2月, 2014 1 次提交
  20. 20 2月, 2014 2 次提交
    • L
      intel_idle: support Bay Trail · 718987d6
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      Tested-by: NAubrey Li <aubrey.li@linux.intel.com>
      718987d6
    • L
      intel_idle: allow sparse sub-state numbering, for Bay Trail · 24bfa950
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      24bfa950
  21. 11 1月, 2014 2 次提交
  22. 10 1月, 2014 1 次提交