Skip to content
  1. Oct 24, 2014
    • Rafael J. Wysocki's avatar
      Merge branches 'pm-cpuidle' and 'pm-cpufreq' · a91e99e2
      Rafael J. Wysocki authored
      * pm-cpuidle:
        cpuidle: powernv: Populate cpuidle state details by querying the device-tree
      
      * pm-cpufreq:
        intel_pstate: Correct BYT VID values.
        intel_pstate: Fix BYT frequency reporting
        intel_pstate: Don't lose sysfs settings during cpu offline
        cpufreq: intel_pstate: Reflect current no_turbo state correctly
        cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers
        cpufreq: intel_pstate: Fix setting max_perf_pct in performance policy
        cpufreq: cpufreq-dt: adjust message related to regulators
        cpufreq: cpufreq-dt: extend with platform_data
        cpufreq: allow driver-specific data
      a91e99e2
    • Rafael J. Wysocki's avatar
      Merge branches 'acpi-pm' and 'pm-genirq' · 49fe0353
      Rafael J. Wysocki authored
      * acpi-pm:
        ACPI: invoke acpi_device_wakeup() with correct parameters
      
      * pm-genirq:
        PCI / PM: handle failure to enable wakeup on PCIe PME
      49fe0353
    • Rafael J. Wysocki's avatar
      Merge branch 'freezer' · 96ed7532
      Rafael J. Wysocki authored
      * freezer:
        PM / freezer: Clean up code after recent fixes
        PM: convert do_each_thread to for_each_process_thread
        OOM, PM: OOM killed task shouldn't escape PM suspend
        freezer: remove obsolete comments in __thaw_task()
        freezer: Do not freeze tasks killed by OOM killer
      96ed7532
    • Rafael J. Wysocki's avatar
      Merge branch 'pm-qos' · 37c72cac
      Rafael J. Wysocki authored
      * pm-qos:
        PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class
      37c72cac
    • Rafael J. Wysocki's avatar
      Merge branches 'acpi-ec' and 'acpi-platform' · 286180d8
      Rafael J. Wysocki authored
      * acpi-ec:
        ACPI / EC: Cleanup coding style.
        ACPI / EC: Refine event/query debugging messages.
        ACPI / EC: Add detailed command/query debugging information.
        ACPI / EC: Enhance the logs to apply to QR_EC transactions.
        ACPI / EC: Add CPU ID to debugging messages.
      
      * acpi-platform:
        ACPI / platform: provide default DMA mask
      286180d8
    • Dirk Brandewie's avatar
      intel_pstate: Correct BYT VID values. · d022a65e
      Dirk Brandewie authored
      
      
      Using a VID value that is not high enough for the requested P state can
      cause machine checks. Add a ceiling function to ensure calulated VIDs
      with fractional values are set to the next highest integer VID value.
      
      The algorythm for calculating the non-trubo VID from the BIOS writers
      guide is:
       vid_ratio = (vid_max - vid_min) / (max_pstate - min_pstate)
       vid = ceiling(vid_min + (req_pstate - min_pstate) * vid_ratio)
      
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d022a65e
    • Dirk Brandewie's avatar
      intel_pstate: Fix BYT frequency reporting · b27580b0
      Dirk Brandewie authored
      
      
      BYT has a different conversion from P state to frequency than the core
      processors.  This causes the min/max and current frequency to be
      misreported on some BYT SKUs. Tested on BYT N2820, Ivybridge and
      Haswell processors.
      
      Link: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6663
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b27580b0
    • Dirk Brandewie's avatar
      intel_pstate: Don't lose sysfs settings during cpu offline · c0348717
      Dirk Brandewie authored
      
      
      The user may have custom settings don't destroy them during suspend.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=80651
      Reported-by: default avatarTobias Jakobi <liquid.acid@gmx.net>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c0348717
    • Gabriele Mazzotta's avatar
      cpufreq: intel_pstate: Reflect current no_turbo state correctly · 4521e1a0
      Gabriele Mazzotta authored
      
      
      Some BIOSes modify the state of MSR_IA32_MISC_ENABLE_TURBO_DISABLE
      based on the current power source for the system battery AC vs
      battery. Reflect the correct current state and ability to modify the
      no_turbo sysfs file based on current state of
      MSR_IA32_MISC_ENABLE_TURBO_DISABLE.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=83151
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4521e1a0
    • Dirk Brandewie's avatar
      cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers · c034b02e
      Dirk Brandewie authored
      
      
      Currently the core does not expose scaling_cur_freq for set_policy()
      drivers this breaks some userspace monitoring tools.
      Change the core to expose this file for all drivers and if the
      set_policy() driver supports the get() callback use it to retrieve the
      current frequency.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=73741
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c034b02e
    • Pali Rohár's avatar
      cpufreq: intel_pstate: Fix setting max_perf_pct in performance policy · 36b4bed5
      Pali Rohár authored
      
      
      Code which changes policy to powersave changes also max_policy_pct based on
      max_freq. Code which change max_perf_pct has upper limit base on value
      max_policy_pct. When policy is changing from powersave back to performance
      then max_policy_pct is not changed. Which means that changing max_perf_pct is
      not possible to high values if max_freq was too low in powersave policy.
      
      Test case:
      
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      800000
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      3300000
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      performance
      $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
      100
      
      $ echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      $ echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      $ echo 20 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
      
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      powersave
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      800000
      $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
      20
      
      $ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      $ echo 3300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      $ echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
      
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      performance
      $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      3300000
      $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
      24
      
      And now intel_pstate driver allows to set maximal value for max_perf_pct based
      on max_policy_pct which is 24 for previous powersave max_freq 800000.
      
      This patch will set default value for max_policy_pct when setting policy to
      performance so it will allow to set also max value for max_perf_pct.
      
      Signed-off-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Cc: All applicable <stable@vger.kernel.org>
      Acked-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      36b4bed5
    • Lucas Stach's avatar
      PCI / PM: handle failure to enable wakeup on PCIe PME · 5dfd7f9f
      Lucas Stach authored
      If the irqchip handling the PCIe PME interrupt is not able
      to enable interrupt wakeup we should properly reflect this
      in the PME suspend status.
      
      This fixes a kernel warning on resume, where it would try
      to disable the irq wakeup that failed to be activated while
      suspending, for example:
      
      WARNING: CPU: 0 PID: 609 at kernel/irq/manage.c:536 irq_set_irq_wake+0xc0/0xf8()
      Unbalanced IRQ 384 wake disable
      
      Fixes: 76cde7e4
      
       (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle)
      Reported-and-tested-by: default avatarRichard Zhu <richard.zhu@freescale.com>
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5dfd7f9f
    • Zhang Rui's avatar
      ACPI: invoke acpi_device_wakeup() with correct parameters · 67598a1d
      Zhang Rui authored
      Fix a bug that invokes acpi_device_wakeup() with wrong parameters.
      
      Fixes: f35cec25
      
       (ACPI / PM: Always enable wakeup GPEs when enabling device wakeup)
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      67598a1d
  2. Oct 23, 2014
  3. Oct 22, 2014
    • Michal Hocko's avatar
      PM: convert do_each_thread to for_each_process_thread · a28e785a
      Michal Hocko authored
      as per 0c740d0a
      
       (introduce for_each_thread() to replace the buggy
      while_each_thread()) get rid of do_each_thread { } while_each_thread()
      construct and replace it by a more error prone for_each_thread.
      
      This patch doesn't introduce any user visible change.
      
      Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a28e785a
    • Michal Hocko's avatar
      OOM, PM: OOM killed task shouldn't escape PM suspend · 5695be14
      Michal Hocko authored
      PM freezer relies on having all tasks frozen by the time devices are
      getting frozen so that no task will touch them while they are getting
      frozen. But OOM killer is allowed to kill an already frozen task in
      order to handle OOM situtation. In order to protect from late wake ups
      OOM killer is disabled after all tasks are frozen. This, however, still
      keeps a window open when a killed task didn't manage to die by the time
      freeze_processes finishes.
      
      Reduce the race window by checking all tasks after OOM killer has been
      disabled. This is still not race free completely unfortunately because
      oom_killer_disable cannot stop an already ongoing OOM killer so a task
      might still wake up from the fridge and get killed without
      freeze_processes noticing. Full synchronization of OOM and freezer is,
      however, too heavy weight for this highly unlikely case.
      
      Introduce and check oom_kills counter which gets incremented early when
      the allocator enters __alloc_pages_may_oom path and only check all the
      tasks if the counter changes during the freezing attempt. The counter
      is updated so early to reduce the race window since allocator checked
      oom_killer_disabled which is set by PM-freezing code. A false positive
      will push the PM-freezer into a slow path but that is not a big deal.
      
      Changes since v1
      - push the re-check loop out of freeze_processes into
        check_frozen_processes and invert the condition to make the code more
        readable as per Rafael
      
      Fixes: f660daac
      
       (oom: thaw threads if oom killed thread is frozen before deferring)
      Cc: 3.2+ <stable@vger.kernel.org> # 3.2+
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5695be14
    • Cong Wang's avatar
      freezer: remove obsolete comments in __thaw_task() · c05eb32f
      Cong Wang authored
      __thaw_task() no longer clears frozen flag since commit a3201227
      
      
      (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE).
      
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c05eb32f
    • Cong Wang's avatar
      freezer: Do not freeze tasks killed by OOM killer · 51fae6da
      Cong Wang authored
      Since f660daac (oom: thaw threads if oom killed thread is frozen
      before deferring) OOM killer relies on being able to thaw a frozen task
      to handle OOM situation but a3201227 (freezer: make freezing() test
      freeze conditions in effect instead of TIF_FREEZE) has reorganized the
      code and stopped clearing freeze flag in __thaw_task. This means that
      the target task only wakes up and goes into the fridge again because the
      freezing condition hasn't changed for it. This reintroduces the bug
      fixed by f660daac.
      
      Fix the issue by checking for TIF_MEMDIE thread flag in
      freezing_slow_path and exclude the task from freezing completely. If a
      task was already frozen it would get woken by __thaw_task from OOM killer
      and get out of freezer after rechecking freezing().
      
      Changes since v1
      - put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator
        as per Oleg
      - return __thaw_task into oom_scan_process_thread because
        oom_kill_process will not wake task in the fridge because it is
        sleeping uninterruptible
      
      [mhocko@suse.cz: rewrote the changelog]
      Fixes: a3201227
      
       (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE)
      Cc: 3.3+ <stable@vger.kernel.org> # 3.3+
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      51fae6da
    • Heikki Krogerus's avatar
      ACPI / platform: provide default DMA mask · 8a2f38dd
      Heikki Krogerus authored
      
      
      Most devices are configured for 32-bit DMA addresses.
      Setting the mask to 32-bit here removes the need for the
      drivers to do it separately.
      
      Signed-off-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a2f38dd
  4. Oct 21, 2014
  5. Oct 20, 2014