1. 31 Dec, 2016 2 commits
  2. 27 Dec, 2016 1 commit
  3. 21 Dec, 2016 3 commits
  4. 12 Dec, 2016 1 commit
  5. 08 Dec, 2016 3 commits
    • Srinivas Pandruvada's avatar
      Documentation: intel_pstate: Document HWP energy/performance hints · bf006e14
      Srinivas Pandruvada authored
      Updated documentation for the support of energy performance hint in
      the HWP mode.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Subject & changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bf006e14
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Support for energy performance hints with HWP · 984edbdc
      Srinivas Pandruvada authored
      It is possible to provide hints to the HWP algorithms in the processor
      to be more performance centric to more energy centric. These hints are
      provided by using HWP energy performance preference (EPP) or energy
      performance bias (EPB) settings.
      
      The scope of these settings is per logical processor, which means that
      each of the logical processors in the package can be programmed with a
      different value.
      
      This change provides cpufreq sysfs interface to provide hint. For each
      policy, two additional attributes will be available to check and provide
      hint. These attributes will only be present when the intel_pstate driver
      is using HWP mode.
      
      These attributes are:
       - energy_performance_available_preferences
       - energy_performance_preference
      
      To get list of supported hints:
      $ cat energy_performance_available_preferences
      default performance balance_performance balance_power power
      
      The current preference can be read or changed via cpufreq sysfs
      attribute "energy_performance_preference". Reading from this attribute
      will display current effective setting changed via any method. User can
      write any of the valid preference string to this attribute. User can
      always restore to power-on default by writing "default".
      
      Implementation
      Since these hints can be provided by direct MSR write or using some tools
      like x86_energy_perf_policy, the driver internally doesn't maintain any
      state. The user operation will result in direct read/write of MSR: 0x774
      (HWP_REQUEST_MSR). Also driver use read modify write to update other
      fields in this MSR.
      
      Summary of changes:
       - struct cpudata field epp_saved is renamed to epp_powersave, as this
         stores the value to restore once policy is switched from performance
         to powersave to restore original powersave EPP value.
       - A new struct cpudata field epp_saved is used to store the raw MSR
         EPP/EPB value when a CPU goes offline or on suspend and restore on
         online/resume. This ensures that EPP value is restored to correct
         value irrespective of the means used to set.
       - EPP/EPB value ranges are fixed for each preference, which can be
         set for the cpufreq sysfs, so user request is mapped to/from this
         range.
       - New attributes are only added when HWP is present.
       - Since EPP value of 0 is valid the fields are initialized to
         -EINVAL when not valid. The field epp_default is read only once
         after powerup to avoid reading on subsequent CPU online operation
       - New suspend callback to store epp on suspend operation
       - Don't invalidate old epp_saved field on resume and online as now
         we can restore last epp value on suspend and this field can still
         have old EPP value sampled during switch to performance from
         powersave.
       - While here optimized setting of cpu_data->epp_powersave = epp in
         intel_pstate_hwp_set() as this was done in both true and false
         paths.
       - epp/epb set function returns error to caller on failure to pass
         on to user space for display.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      984edbdc
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Add locking around HWP requests · b59fe540
      Srinivas Pandruvada authored
      To avoid race conditions from multiple threads, increase the scope
      of intel_pstate_limits_lock to include HWP requests also.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Subject ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b59fe540
  6. 01 Dec, 2016 3 commits
  7. 30 Nov, 2016 1 commit
  8. 28 Nov, 2016 4 commits
  9. 24 Nov, 2016 1 commit
  10. 22 Nov, 2016 2 commits
  11. 21 Nov, 2016 4 commits
    • Rafael J. Wysocki's avatar
      cpufreq: Make cpufreq_update_policy() void · 30248fef
      Rafael J. Wysocki authored
      The return value of cpufreq_update_policy() is never used, so make
      it void.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      30248fef
    • Rafael J. Wysocki's avatar
      ACPI / processor: Make acpi_processor_ppc_has_changed() void · bca5f557
      Rafael J. Wysocki authored
      The return value of acpi_processor_ppc_has_changed() is never used,
      so make it void.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      bca5f557
    • Rafael J. Wysocki's avatar
      cpufreq: Avoid using inactive policies · 182e36af
      Rafael J. Wysocki authored
      There are two places in the cpufreq core in which low-level driver
      callbacks may be invoked for an inactive cpufreq policy, which isn't
      guaranteed to work in general.  Both are due to possible races with
      CPU offline.
      
      First, in cpufreq_get(), the policy may become inactive after
      the check against policy->cpus in cpufreq_cpu_get() and before
      policy->rwsem is acquired, in which case using it going forward may
      not be correct.
      
      Second, an analogous situation is possible in cpufreq_update_policy().
      
      Avoid using inactive policies by adding policy_is_inactive() checks
      to the code in the above places.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      182e36af
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Generic governors support · 001c76f0
      Rafael J. Wysocki authored
      There may be reasons to use generic cpufreq governors (eg. schedutil)
      on Intel platforms instead of the intel_pstate driver's internal
      governor.  However, that currently can only be done by disabling
      intel_pstate altogether and using the acpi-cpufreq driver instead
      of it, which is subject to limitations.
      
      First of all, acpi-cpufreq only works on systems where the _PSS
      object is present in the ACPI tables for all logical CPUs.  Second,
      on those systems acpi-cpufreq will only use frequencies listed by
      _PSS which may be suboptimal.  In particular, by convention, the
      whole turbo range is represented in _PSS as a single P-state and
      the frequency assigned to it is greater by 1 MHz than the greatest
      non-turbo frequency listed by _PSS.  That may confuse governors to
      use turbo frequencies less frequently which may lead to suboptimal
      performance.
      
      For this reason, make it possible to use the intel_pstate driver
      with generic cpufreq governors as a "normal" cpufreq driver.  That
      mode is enforced by adding intel_pstate=passive to the kernel
      command line and cannot be disabled at run time.  In that mode,
      intel_pstate provides a cpufreq driver interface including
      the ->target() and ->fast_switch() callbacks and is listed in
      scaling_driver as "intel_cpufreq".
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarDoug Smythies <dsmythies@telus.net>
      001c76f0
  12. 17 Nov, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Request P-states control from SMM if needed · d0ea59e1
      Rafael J. Wysocki authored
      Currently, intel_pstate is unable to control P-states on my
      IvyBridge-based Acer Aspire S5, because they are controlled by SMM
      on that machine by default and it is necessary to request OS control
      of P-states from it via the SMI Command register exposed in the ACPI
      FADT.  intel_pstate doesn't do that now, but acpi-cpufreq and other
      cpufreq drivers for x86 platforms do.
      
      Address this problem by making intel_pstate use the ACPI-defined
      mechanism as well.  However, intel_pstate is not modular and it
      doesn't need the module refcount tricks played by
      acpi_processor_notify_smm(), so export the core of this function
      to it as acpi_processor_pstate_control() and make it call that.
      [The changes in processor_perflib.c related to this should not
      make any functional difference for the acpi_processor_notify_smm()
      users].
      
      To be safe, only call acpi_processor_notify_smm() from intel_pstate
      if ACPI _PPC support is enabled in it.
      Suggested-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      d0ea59e1
  13. 16 Nov, 2016 8 commits
    • Geert Uytterhoeven's avatar
      cpufreq: dt: Add support for r8a7743 and r8a7745 · f0da898b
      Geert Uytterhoeven authored
      Add the compatible strings for supporting the generic cpufreq driver on
      the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f0da898b
    • Denis Kirjanov's avatar
      cpufreq: powernv: Disable preemption while checking CPU throttling state · 8a10c06a
      Denis Kirjanov authored
      With preemption turned on we can read incorrect throttling state
      while being switched to CPU on a different chip.
      
       BUG: using smp_processor_id() in preemptible [00000000] code: cat/7343
       caller is .powernv_cpufreq_throttle_check+0x2c/0x710
       CPU: 13 PID: 7343 Comm: cat Not tainted 4.8.0-rc5-dirty #1
       Call Trace:
       [c0000007d25b75b0] [c000000000971378] .dump_stack+0xe4/0x150 (unreliable)
       [c0000007d25b7640] [c0000000005162e4] .check_preemption_disabled+0x134/0x150
       [c0000007d25b76e0] [c0000000007b63ac] .powernv_cpufreq_throttle_check+0x2c/0x710
       [c0000007d25b7790] [c0000000007b6d18] .powernv_cpufreq_target_index+0x288/0x360
       [c0000007d25b7870] [c0000000007acee4] .__cpufreq_driver_target+0x394/0x8c0
       [c0000007d25b7920] [c0000000007b22ac] .cpufreq_set+0x7c/0xd0
       [c0000007d25b79b0] [c0000000007adf50] .store_scaling_setspeed+0x80/0xc0
       [c0000007d25b7a40] [c0000000007ae270] .store+0xa0/0x100
       [c0000007d25b7ae0] [c0000000003566e8] .sysfs_kf_write+0x88/0xb0
       [c0000007d25b7b70] [c0000000003553b8] .kernfs_fop_write+0x178/0x260
       [c0000007d25b7c10] [c0000000002ac3cc] .__vfs_write+0x3c/0x1c0
       [c0000007d25b7cf0] [c0000000002ad584] .vfs_write+0xc4/0x230
       [c0000007d25b7d90] [c0000000002aeef8] .SyS_write+0x58/0x100
       [c0000007d25b7e30] [c00000000000bfec] system_call+0x38/0xfc
      
      Fixes: 09a972d1 (cpufreq: powernv: Report cpu frequency throttling)
      Reviewed-by: default avatarGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a10c06a
    • Viresh Kumar's avatar
      cpufreq: schedutil: irq-work and mutex are only used in slow path · 21ef5729
      Viresh Kumar authored
      Execute the irq-work specific initialization/exit code only when the
      fast path isn't available.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      21ef5729
    • Viresh Kumar's avatar
      cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task · 02a7b1ee
      Viresh Kumar authored
      If slow path frequency changes are conducted in a SCHED_OTHER context
      then they may be delayed for some amount of time, including
      indefinitely, when real time or deadline activity is taking place.
      
      Move the slow path to a real time kernel thread. In the future the
      thread should be made SCHED_DEADLINE. The RT priority is arbitrarily set
      to 50 for now.
      
      Hackbench results on ARM Exynos, dual core A15 platform for 10
      iterations:
      
      $ hackbench -s 100 -l 100 -g 10 -f 20
      
      Before			After
      ---------------------------------
      1.808			1.603
      1.847			1.251
      2.229			1.590
      1.952			1.600
      1.947			1.257
      1.925			1.627
      2.694			1.620
      1.258			1.621
      1.919			1.632
      1.250			1.240
      
      Average:
      
      1.8829			1.5041
      
      Based on initial work by Steve Muckle.
      Signed-off-by: default avatarSteve Muckle <smuckle.linux@gmail.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      02a7b1ee
    • Viresh Kumar's avatar
      cpufreq: schedutil: enable fast switch earlier · 4a71ce43
      Viresh Kumar authored
      The fast_switch_enabled flag will be used by both sugov_policy_alloc()
      and sugov_policy_free() with a later patch.
      
      Prepare for that by moving the calls to enable and disable it to the
      beginning of sugov_init() and end of sugov_exit().
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4a71ce43
    • Viresh Kumar's avatar
      cpufreq: schedutil: Avoid indented labels · 8e2ddb03
      Viresh Kumar authored
      Switch to the more common practice of writing labels.
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8e2ddb03
    • Stratos Karafotis's avatar
      cpufreq: conservative: Fix comment explaining frequency updates · 42d951c8
      Stratos Karafotis authored
      The original comment about the frequency increase to maximum is wrong.
      
      Both increase and decrease happen at steps.
      Signed-off-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      42d951c8
    • Stratos Karafotis's avatar
      cpufreq: conservative: Decrease frequency faster for deferred updates · 00bfe058
      Stratos Karafotis authored
      Conservative governor changes the CPU frequency in steps.
      That means that if a CPU runs at max frequency, it will need several
      sampling periods to return to min frequency when the workload
      is finished.
      
      If the update function that calculates the load and target frequency
      is deferred, the governor might need even more time to decrease the
      frequency.
      
      This may have impact to power consumption and after all conservative
      should decrease the frequency if there is no workload at every sampling
      rate.
      
      To resolve the above issue calculate the number of sampling periods
      that the update is deferred. Considering that for each sampling period
      conservative should drop the frequency by a freq_step because the
      CPU was idle apply the proper subtraction to requested frequency.
      
      Below, the kernel trace with and without this patch. First an
      intensive workload is applied on a specific CPU. Then the workload
      is removed and the CPU goes to idle.
      
      WITHOUT
      
           <idle>-0     [007] dN..   620.329153: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   620.350857: cpu_frequency: state=1700000 cpu_id=7
      kworker/7:2-556   [007] ....   620.370856: cpu_frequency: state=1900000 cpu_id=7
      kworker/7:2-556   [007] ....   620.390854: cpu_frequency: state=2100000 cpu_id=7
      kworker/7:2-556   [007] ....   620.411853: cpu_frequency: state=2200000 cpu_id=7
      kworker/7:2-556   [007] ....   620.432854: cpu_frequency: state=2400000 cpu_id=7
      kworker/7:2-556   [007] ....   620.453854: cpu_frequency: state=2600000 cpu_id=7
      kworker/7:2-556   [007] ....   620.494856: cpu_frequency: state=2900000 cpu_id=7
      kworker/7:2-556   [007] ....   620.515856: cpu_frequency: state=3100000 cpu_id=7
      kworker/7:2-556   [007] ....   620.536858: cpu_frequency: state=3300000 cpu_id=7
      kworker/7:2-556   [007] ....   620.557857: cpu_frequency: state=3401000 cpu_id=7
           <idle>-0     [007] d...   669.591363: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   669.591939: cpu_idle: state=4294967295 cpu_id=7
           <idle>-0     [007] d...   669.591980: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] dN..   669.591989: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   670.201224: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   670.221975: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   670.222016: cpu_frequency: state=3300000 cpu_id=7
           <idle>-0     [007] d...   670.222026: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   670.234964: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   670.801251: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.236046: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.236073: cpu_frequency: state=3100000 cpu_id=7
           <idle>-0     [007] d...   671.236112: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.393437: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   671.401277: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.404083: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.404111: cpu_frequency: state=2900000 cpu_id=7
           <idle>-0     [007] d...   671.404125: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.404974: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   671.501180: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.995414: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.995459: cpu_frequency: state=2800000 cpu_id=7
           <idle>-0     [007] d...   671.995469: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.996287: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.001305: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.078374: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.078410: cpu_frequency: state=2600000 cpu_id=7
           <idle>-0     [007] d...   672.078419: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.158020: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.158040: cpu_frequency: state=2400000 cpu_id=7
           <idle>-0     [007] d...   672.158044: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.160038: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.234557: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.237121: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.237174: cpu_frequency: state=2100000 cpu_id=7
           <idle>-0     [007] d...   672.237186: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.237778: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.267902: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.269860: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.269906: cpu_frequency: state=1900000 cpu_id=7
           <idle>-0     [007] d...   672.269914: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.271902: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.751342: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.823056: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.823095: cpu_frequency: state=1600000 cpu_id=7
      
      WITH
      
           <idle>-0     [007] dN..  4380.928009: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4380.949767: cpu_frequency: state=2000000 cpu_id=7
      kworker/7:2-399   [007] ....  4380.969765: cpu_frequency: state=2200000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.009766: cpu_frequency: state=2500000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.029767: cpu_frequency: state=2600000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.049769: cpu_frequency: state=2800000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.069769: cpu_frequency: state=3000000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.089771: cpu_frequency: state=3100000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.109772: cpu_frequency: state=3400000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.129773: cpu_frequency: state=3401000 cpu_id=7
           <idle>-0     [007] d...  4428.226159: cpu_idle: state=1 cpu_id=7
           <idle>-0     [007] d...  4428.226176: cpu_idle: state=4294967295 cpu_id=7
           <idle>-0     [007] d...  4428.226181: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.227177: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4428.551640: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.649239: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4428.649268: cpu_frequency: state=2800000 cpu_id=7
           <idle>-0     [007] d...  4428.649278: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.689856: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4428.799542: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.801683: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4428.801748: cpu_frequency: state=1700000 cpu_id=7
           <idle>-0     [007] d...  4428.801761: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.806545: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4429.051880: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4429.086240: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4429.086293: cpu_frequency: state=1600000 cpu_id=7
      
      Without the patch the CPU dropped to min frequency after 3.2s
      With the patch applied the CPU dropped to min frequency after 0.86s
      Signed-off-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      00bfe058
  14. 14 Nov, 2016 3 commits
  15. 13 Nov, 2016 3 commits
    • Linus Torvalds's avatar
      Linux 4.9-rc5 · a25f0944
      Linus Torvalds authored
      a25f0944
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · e234832a
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "ARM fixes.  There are a couple pending x86 patches but they'll have to
        wait for next week"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs
        KVM: arm/arm64: vgic: Prevent access to invalid SPIs
        arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
      e234832a
    • Linus Torvalds's avatar
      Merge branch 'media-fixes' (patches from Mauro) · e861d890
      Linus Torvalds authored
      Merge media fixes from Mauro Carvalho Chehab:
       "This contains two patches fixing problems with my patch series meant
        to make USB drivers to work again after the DMA on stack changes.
      
        The last patch on this series is actually not related to DMA on stack.
        It solves a longstanding bug affecting module unload, causing
        module_put() to be called twice. It was reported by the user who
        reported and tested the issues with the gp8psk driver with the DMA
        fixup patches. As we're late at -rc cycle, maybe you prefer to not
        apply it right now. If this is the case, I'll add to the pile of
        patches for 4.10.
      
        Exceptionally this time, I'm sending the patches via e-mail, because
        I'm on another trip, and won't be able to use the usual procedure
        until Monday. Also, it is only three patches, and you followed already
        the discussions about the first one"
      
      * emailed patches from Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
        gp8psk: Fix DVB frontend attach
        gp8psk: fix gp8psk_usb_in_op() logic
        dvb-usb: move data_mutex to struct dvb_usb_device
      e861d890