1. 22 4月, 2014 1 次提交
  2. 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
  3. 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
  4. 28 2月, 2014 1 次提交
  5. 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
  6. 11 1月, 2014 2 次提交
  7. 10 1月, 2014 1 次提交
  8. 09 1月, 2014 1 次提交
    • J
      Revert "intel_idle: mark states tables with __initdata tag" · ba0dc81e
      Jiang Liu 提交于
      This reverts commit 9d046ccb.
      
      Commit 9d046ccb marks all state tables with __initdata, but
      the state table may be accessed when doing CPU online, which then
      causing system crash as below:
      
      [  204.188841] BUG: unable to handle kernel paging request at ffffffff8227cce8
      [  204.196844] IP: [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
      [  204.203996] PGD 1e11067 PUD 1e12063 PMD 455859063 PTE 800000000227c062
      [  204.211638] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [  204.216975] Modules linked in: x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd gpio_ich microcode joydev sb_edac edac_core ipmi_si lpc_ich ipmi_msghandler lp tpm_tis parport wmi mac_hid acpi_pad hid_generic ixgbe isci usbhid dca hid libsas ptp ahci libahci scsi_transport_sas megaraid_sas pps_core mdio
      [  204.262815] CPU: 11 PID: 1489 Comm: bash Not tainted 3.13.0-rc7+ #48
      [  204.269993] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0047.L09.1312061514 12/06/2013
      [  204.281646] task: ffff8804303a24a0 ti: ffff880440fac000 task.ti: ffff880440fac000
      [  204.290311] RIP: 0010:[<ffffffff814aa1c0>]  [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
      [  204.300184] RSP: 0018:ffff880440fadd28  EFLAGS: 00010286
      [  204.306192] RAX: ffffffff8227cca0 RBX: ffffe8fff1a03400 RCX: 0000000000000007
      [  204.314244] RDX: ffff88045f400000 RSI: 0000000000000009 RDI: 0000000000001120
      [  204.322296] RBP: ffff880440fadd38 R08: 0000000000000000 R09: 0000000000000001
      [  204.330411] R10: 0000000000000001 R11: 0000000000000000 R12: 000000000000001e
      [  204.338482] R13: 00000000ffffffdb R14: 0000000000000001 R15: 0000000000000000
      [  204.346743] FS:  00007f64f7b0c740(0000) GS:ffff88045ce00000(0000) knlGS:0000000000000000
      [  204.355919] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  204.362449] CR2: ffffffff8227cce8 CR3: 0000000444ab0000 CR4: 00000000001407e0
      [  204.370520] Stack:
      [  204.372853]  000000000000001e ffffffff81f10240 ffff880440fadd50 ffffffff814aa307
      [  204.381519]  ffffffff81ea80e0 ffff880440fadda0 ffffffff8185a230 0000000000000000
      [  204.390196]  000000000000001e 0000000000000002 0000000000000002 0000000000000000
      [  204.398856] Call Trace:
      [  204.401683]  [<ffffffff814aa307>] cpu_hotplug_notify+0x57/0x70
      [  204.408638]  [<ffffffff8185a230>] notifier_call_chain+0x100/0x150
      [  204.415553]  [<ffffffff810a7dae>] __raw_notifier_call_chain+0xe/0x10
      [  204.422772]  [<ffffffff81072163>] cpu_notify+0x23/0x50
      [  204.428616]  [<ffffffff810723b2>] _cpu_up+0x132/0x1a0
      [  204.434361]  [<ffffffff8107249d>] cpu_up+0x7d/0xa0
      [  204.439819]  [<ffffffff81836c9c>] cpu_subsys_online+0x3c/0x90
      [  204.446345]  [<ffffffff81554625>] device_online+0x45/0xa0
      [  204.452471]  [<ffffffff815546ce>] online_store+0x4e/0x80
      [  204.458511]  [<ffffffff815519a8>] dev_attr_store+0x18/0x30
      [  204.464744]  [<ffffffff812a68f1>] sysfs_write_file+0x151/0x1c0
      [  204.471681]  [<ffffffff81217ef1>] vfs_write+0xe1/0x160
      [  204.477524]  [<ffffffff8121889c>] SyS_write+0x4c/0x90
      [  204.483270]  [<ffffffff8185f2ed>] system_call_fastpath+0x1a/0x1f
      [  204.490081] Code: 41 54 41 89 fc 8b 3d 48 25 85 01 53 48 8b 1d 30 25 85 01 48 03 1c c5 40 90 fb 81 48 8b 05 19 25 85 01 c7 43 0c 01 00 00 00 66 90 <48> 83 78 48 00 74 4f 41 83 c0 01 41 39 f0 7e 10 48 c7 c7 38 79
      [  204.515723] RIP  [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
      [  204.522996]  RSP <ffff880440fadd28>
      [  204.526976] CR2: ffffffff8227cce8
      [  204.530766] ---[ end trace 336f56cc3d1cfc8c ]---
      
      Fixes: 9d046ccb (intel_idle: mark states tables with __initdata tag)
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ba0dc81e
  9. 20 12月, 2013 2 次提交
  10. 28 11月, 2013 1 次提交
  11. 13 11月, 2013 1 次提交
  12. 30 10月, 2013 1 次提交
  13. 25 9月, 2013 1 次提交
  14. 24 9月, 2013 3 次提交
  15. 23 4月, 2013 1 次提交
  16. 22 4月, 2013 1 次提交
  17. 18 4月, 2013 1 次提交
  18. 15 3月, 2013 1 次提交
  19. 14 2月, 2013 1 次提交
    • L
      intel_idle: export both C1 and C1E · 32e95180
      Len Brown 提交于
      Here we disable HW promotion of C1 to C1E
      and export both C1 and C1E and distinct C-states.
      
      This allows a cpuidle governor to choose a lower latency
      C-state than C1E when necessary to satisfy performance
      and QOS constraints -- and still save power versus polling.
      This also corrects the erroneous latency previously reported
      for C1E -- it is 10usec, not 1usec.
      
      Note that if you use "intel_idle.max_cstate=N",
      then you must increment N by 1 to get the same behavior
      after this change.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      32e95180
  20. 09 2月, 2013 3 次提交
    • L
      intel_idle: remove assumption of one C-state per MWAIT flag · e022e7eb
      Len Brown 提交于
      Remove the assumption that cstate_tables are
      indexed by MWAIT flag values.  Each entry
      identifies itself via its own flags value.
      This change is needed to support multiple states
      that share the same MWAIT flags.
      
      Note that this can have an effect on what state is described
      by 'N' on cmdline intel_idle.max_cstate=N on some systems.
      
      intel_idle.max_cstate=0 still disables the driver
      intel_idle.max_cstate=1 still results in just C1(E)
      However, "place holders" in the sparse C-state name-space
      (eg. Atom) have been removed.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e022e7eb
    • L
      intel_idle: remove use and definition of MWAIT_MAX_NUM_CSTATES · 137ecc77
      Len Brown 提交于
      Cosmetic only.
      
      Replace use of MWAIT_MAX_NUM_CSTATES with CPUIDLE_STATE_MAX.
      They are both 8, so this patch has no functional change.
      
      The reason to change is that intel_idle will soon be able
      to export more than the 8 "major" states supported by MWAIT.
      When we hit that limit, it is important to know
      where the limit comes from.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      137ecc77
    • L
      intel_idle: support Haswell · 85a4d2d4
      Len Brown 提交于
      This patch enables intel_idle to run on the
      next-generation Intel(R) Microarchitecture code named "Haswell".
      Signed-off-by: NLen Brown <len.brown@intel.com>
      85a4d2d4
  21. 02 2月, 2013 1 次提交
    • L
      intel_idle: stop using driver_data for static flags · b1beab48
      Len Brown 提交于
      The commit, 4202735e
      (cpuidle: Split cpuidle_state structure and move per-cpu statistics fields)
      observed that the MWAIT flags for Cn on every processor to date were the
      same, and created get_driver_data() to supply them.
      
      Unfortunately, that assumption is false, going forward.
      So here we restore the MWAIT flags to the cpuidle_state table.
      However, instead restoring the old "driver_data" field,
      we put the flags into the existing "flags" field,
      where they probalby should have lived all along.
      
      This patch does not change any operation.
      
      This patch removes 1 of the 3 users of cpuidle_state_usage.driver_data.
      Perhaps some day we'll get rid of the other 2.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b1beab48
  22. 18 1月, 2013 1 次提交
    • K
      intel_idle: Don't register CPU notifier if we are not running. · 6f8c2e79
      Konrad Rzeszutek Wilk 提交于
      The 'intel_idle_probe' probes the CPU and sets the CPU notifier.
      But if later on during the module initialization we fail (say
      in cpuidle_register_driver), we stop loading, but we neglect
      to unregister the CPU notifier.  This means that during CPU
      hotplug events the system will fail:
      
      calling  intel_idle_init+0x0/0x326 @ 1
      intel_idle: MWAIT substates: 0x1120
      intel_idle: v0.4 model 0x2A
      intel_idle: lapic_timer_reliable_states 0xffffffff
      intel_idle: intel_idle yielding to none
      initcall intel_idle_init+0x0/0x326 returned -19 after 14 usecs
      
      ... some time later, offlining and onlining a CPU:
      
      cpu 3 spinlock event irq 62
      BUG: unable to ] __cpuidle_register_device+0x1c/0x120
      PGD 99b8b067 PUD 99b95067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in: xen_evtchn nouveau mxm_wmi wmi radeon ttm i915 fbcon tileblit font atl1c bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf
      CPU 0
      Pid: 2302, comm: udevd Not tainted 3.8.0-rc3upstream-00249-g09ad159 #1 MSI MS-7680/H61M-P23 (MS-7680)
      RIP: e030:[<ffffffff814d956c>]  [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120
      RSP: e02b:ffff88009dacfcb8  EFLAGS: 00010286
      RAX: 0000000000000000 RBX: ffff880105380000 RCX: 000000000000001c
      RDX: 0000000000000000 RSI: 0000000000000055 RDI: ffff880105380000
      RBP: ffff88009dacfce8 R08: ffffffff81a4f048 R09: 0000000000000008
      R10: 0000000000000008 R11: 0000000000000000 R12: ffff880105380000
      R13: 00000000ffffffdd R14: 0000000000000000 R15: ffffffff81a523d0
      FS:  00007f37bd83b7a0(0000) GS:ffff880105200000(0000) knlGS:0000000000000000
      CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000008 CR3: 00000000a09ea000 CR4: 0000000000042660
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process udevd (pid: 2302, threadinfo ffff88009dace000, task ffff88009afb47f0)
      Stack:
       ffffffff8107f2d0 ffffffff810c2fb7 ffff88009dacfce8 00000000ffffffea
       ffff880105380000 00000000ffffffdd ffff88009dacfd08 ffffffff814d9882
       0000000000000003 ffff880105380000 ffff88009dacfd28 ffffffff81340afd
      Call Trace:
       [<ffffffff8107f2d0>] ? collect_cpu_info_local+0x30/0x30
       [<ffffffff810c2fb7>] ? __might_sleep+0xe7/0x100
       [<ffffffff814d9882>] cpuidle_register_device+0x32/0x70
       [<ffffffff81340afd>] intel_idle_cpu_init+0xad/0x110
       [<ffffffff81340bc8>] cpu_hotplug_notify+0x68/0x80
       [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70
       [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10
       [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30
       [<ffffffff81652cf7>] _cpu_up+0x103/0x14b
       [<ffffffff81652e18>] cpu_up+0xd9/0xec
       [<ffffffff8164a254>] store_online+0x94/0xd0
       [<ffffffff814122fb>] dev_attr_store+0x1b/0x20
       [<ffffffff81216404>] sysfs_write_file+0xf4/0x170
       [<ffffffff811a1024>] vfs_write+0xb4/0x130
       [<ffffffff811a17ea>] sys_write+0x5a/0xa0
       [<ffffffff816643a9>] system_call_fastpath+0x16/0x1b
      Code: 03 18 00 c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d e8 4c 89 65 f0 48 89 fb 4c 89 6d f8 e8 84 08 00 00 <48> 8b 78 08 49 89 c4 e8 f8 7f c1 ff 89 c2 b8 ea ff ff ff 84 d2
      RIP  [<ffffffff814d956c>] __cpuidle_register_device+0x1c/0x120
       RSP <ffff88009dacfcb8>
      
      This patch fixes that by moving the CPU notifier registration
      as the last item to be done by the module.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: 3.6+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6f8c2e79
  23. 03 1月, 2013 1 次提交
  24. 27 11月, 2012 1 次提交
    • J
      cpuidle: Measure idle state durations with monotonic clock · a474a515
      Julius Werner 提交于
      Many cpuidle drivers measure their time spent in an idle state by
      reading the wallclock time before and after idling and calculating the
      difference. This leads to erroneous results when the wallclock time gets
      updated by another processor in the meantime, adding that clock
      adjustment to the idle state's time counter.
      
      If the clock adjustment was negative, the result is even worse due to an
      erroneous cast from int to unsigned long long of the last_residency
      variable. The negative 32 bit integer will zero-extend and result in a
      forward time jump of roughly four billion milliseconds or 1.3 hours on
      the idle state residency counter.
      
      This patch changes all affected cpuidle drivers to either use the
      monotonic clock for their measurements or make use of the generic time
      measurement wrapper in cpuidle.c, which was already working correctly.
      Some superfluous CLIs/STIs in the ACPI code are removed (interrupts
      should always already be disabled before entering the idle function, and
      not get reenabled until the generic wrapper has performed its second
      measurement). It also removes the erroneous cast, making sure that
      negative residency values are applied correctly even though they should
      not appear anymore.
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Tested-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a474a515
  25. 27 9月, 2012 1 次提交
  26. 18 8月, 2012 1 次提交
  27. 06 7月, 2012 1 次提交
  28. 06 6月, 2012 1 次提交
  29. 22 3月, 2012 1 次提交
  30. 16 2月, 2012 1 次提交
  31. 14 2月, 2012 1 次提交
  32. 27 1月, 2012 1 次提交
  33. 20 1月, 2012 1 次提交