1. 07 3月, 2014 1 次提交
  2. 06 3月, 2014 5 次提交
  3. 29 1月, 2014 6 次提交
  4. 30 12月, 2013 1 次提交
  5. 04 12月, 2013 1 次提交
    • K
      cpuidle: Check for dev before deregistering it. · 813e8e3d
      Konrad Rzeszutek Wilk 提交于
      If not, we could end up in the unfortunate situation where
      we dereference a NULL pointer b/c we have cpuidle disabled.
      
      This is the case when booting under Xen (which uses the
      ACPI P/C states but disables the CPU idle driver) - and can
      be easily reproduced when booting with cpuidle.off=1.
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff8156db4a>] cpuidle_unregister_device+0x2a/0x90
      .. snip..
      Call Trace:
       [<ffffffff813b15b4>] acpi_processor_power_exit+0x3c/0x5c
       [<ffffffff813af0a9>] acpi_processor_stop+0x61/0xb6
       [<ffffffff814215bf>] __device_release_driver+0fffff81421653>] device_release_driver+0x23/0x30
       [<ffffffff81420ed8>] bus_remove_device+0x108/0x180
       [<ffffffff8141d9d9>] device_del+0x129/0x1c0
       [<ffffffff813cb4b0>] ? unregister_xenbus_watch+0x1f0/0x1f0
       [<ffffffff8141da8e>] device_unregister+0x1e/0x60
       [<ffffffff814243e9>] unregister_cpu+0x39/0x60
       [<ffffffff81019e03>] arch_unregister_cpu+0x23/0x30
       [<ffffffff813c3c51>] handle_vcpu_hotplug_event+0xc1/0xe0
       [<ffffffff813cb4f5>] xenwatch_thread+0x45/0x120
       [<ffffffff810af010>] ? abort_exclusive_wait+0xb0/0xb0
       [<ffffffff8108ec42>] kthread+0xd2/0xf0
       [<ffffffff8108eb70>] ? kthread_create_on_node+0x180/0x180
       [<ffffffff816ce17c>] ret_from_fork+0x7c/0xb0
       [<ffffffff8108eb70>] ? kthread_create_on_node+0x180/0x180
      
      This problem also appears in 3.12 and could be a candidate for backport.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      813e8e3d
  6. 30 10月, 2013 12 次提交
  7. 17 10月, 2013 1 次提交
  8. 07 10月, 2013 4 次提交
  9. 02 10月, 2013 3 次提交
  10. 31 8月, 2013 1 次提交
  11. 30 8月, 2013 3 次提交
  12. 29 8月, 2013 1 次提交
    • L
      cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver · 14d2c34c
      Lorenzo Pieralisi 提交于
      The big.LITTLE architecture is composed of two clusters of cpus. One cluster
      contains less powerful but more energy efficient processors and the other
      cluster groups the powerful but energy-intensive cpus.
      
      The TC2 testchip implements two clusters of CPUs (A7 and A15 clusters in
      a big.LITTLE configuration) connected through a CCI interconnect that manages
      coherency of their respective L2 caches and intercluster distributed
      virtual memory messages (DVM).
      
      TC2 testchip integrates a power controller that manages cores resets, wake-up
      IRQs and cluster low-power states. Power states are managed at cluster
      level, which means that voltage is removed from a cluster iff all cores
      in a cluster are in a wfi state. Single cores can enter a reset state
      which is identical to wfi in terms of power consumption but simplifies the
      way cluster states are entered.
      
      This patch provides a multiple driver CPU idle implementation for TC2
      which paves the way for a generic big.LITTLE idle driver for all
      upcoming big.LITTLE based systems on chip.
      
      The driver relies on the MCPM infrastructure to coordinate and manage
      core power states; in particular MCPM allows to suspend specific cores
      and hides the CPUs coordination required to shut-down clusters of CPUs.
      
      Power down sequences for the respective clusters are implemented in the
      MCPM TC2 backend, with all code needed to clean caches and exit coherency.
      
      The multiple driver CPU idle infrastructure allows to define different
      C-states for big and little cores, determined at boot by checking the
      part id of the possible CPUs and initializing the respective logical
      masks in the big and little drivers.
      
      Current big.little systems are composed of A7 and A15 clusters, as
      implemented in TC2, but in the future that may change and the driver
      will have evolve to retrieve what is a 'big' cpu and what is a 'little'
      cpu in order to build the correct topology.
      
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Amit Kucheria <amit.kucheria@linaro.org>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      14d2c34c
  13. 23 8月, 2013 1 次提交
    • T
      cpuidle: Change struct menu_device field types · 51f245b8
      Tuukka Tikkanen 提交于
      Field predicted_us value can never exceed expected_us value, but it has
      a potentially larger type. As there is no need for additional 32 bits of
      zeroes on 32 bit plaforms, change the type of predicted_us to match the
      type of expected_us.
      
      Field correction_factor is used to store a value that cannot exceed the
      product of RESOLUTION and DECAY (default 1024*8 = 8192). The constants
      cannot in practice be incremented to such values, that they'd overflow
      unsigned int even on 32 bit systems, so the type is changed to avoid
      unnecessary 64 bit arithmetic on 32 bit systems.
      
      One multiplication of (now) 32 bit values needs an added cast to avoid
      truncation of the result and has been added.
      
      In order to avoid another multiplication from 32 bit domain to 64 bit
      domain, the new correction_factor calculation has been changed from
      new = old * (DECAY-1) / DECAY
      to
      new = old - old / DECAY,
      which with infinite precision would yeild exactly the same result, but
      now changes the direction of rounding. The impact is not significant as
      the maximum accumulated difference cannot exceed the value of DECAY,
      which is relatively small compared to product of RESOLUTION and DECAY
      (8 / 8192).
      Signed-off-by: NTuukka Tikkanen <tuukka.tikkanen@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      51f245b8