1. 27 2月, 2016 3 次提交
  2. 23 2月, 2016 1 次提交
    • V
      intel_pstate: Update frequencies of policy->cpus only from ->set_policy() · 41cfd64c
      Viresh Kumar 提交于
      The intel-pstate driver is using intel_pstate_hwp_set() from two
      separate paths, i.e. ->set_policy() callback and sysfs update path for
      the files present in /sys/devices/system/cpu/intel_pstate/ directory.
      
      While an update to the sysfs path applies to all the CPUs being managed
      by the driver (which essentially means all the online CPUs), the update
      via the ->set_policy() callback applies to a smaller group of CPUs
      managed by the policy for which ->set_policy() is called.
      
      And so, intel_pstate_hwp_set() should update frequencies of only the
      CPUs that are part of policy->cpus mask, while it is called from
      ->set_policy() callback.
      
      In order to do that, add a parameter (cpumask) to intel_pstate_hwp_set()
      and apply the frequency changes only to the concerned CPUs.
      
      For ->set_policy() path, we are only concerned about policy->cpus, and
      so policy->rwsem lock taken by the core prior to calling ->set_policy()
      is enough to take care of any races. The larger lock acquired by
      get_online_cpus() is required only for the updates to sysfs files.
      
      Add another routine, intel_pstate_hwp_set_online_cpus(), and call it
      from the sysfs update paths.
      
      This also fixes a lockdep reported recently, where policy->rwsem and
      get_online_cpus() could have been acquired in any order causing an ABBA
      deadlock. The sequence of events leading to that was:
      
      intel_pstate_init(...)
      	...cpufreq_online(...)
      		down_write(&policy->rwsem); // Locks policy->rwsem
      		...
      		cpufreq_init_policy(policy);
      			...intel_pstate_hwp_set();
      				get_online_cpus(); // Temporarily locks cpu_hotplug.lock
      		...
      		up_write(&policy->rwsem);
      
      pm_suspend(...)
      	...disable_nonboot_cpus()
      		_cpu_down()
      			cpu_hotplug_begin(); // Locks cpu_hotplug.lock
      			__cpu_notify(CPU_DOWN_PREPARE, ...);
      				...cpufreq_offline_prepare();
      					down_write(&policy->rwsem); // Locks policy->rwsem
      Reported-and-tested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      41cfd64c
  3. 22 2月, 2016 2 次提交
  4. 13 2月, 2016 1 次提交
  5. 11 2月, 2016 9 次提交
  6. 10 2月, 2016 7 次提交
  7. 05 2月, 2016 15 次提交
  8. 04 2月, 2016 2 次提交
    • M
      [media] vb2-core: call threadio->fnc() if !VB2_BUF_STATE_ERROR · 1f2c4501
      Mauro Carvalho Chehab 提交于
      changeset 70433a15 ("media: videobuf2: Refactor vb2_fileio_data
      and vb2_thread") broke videobuf2-dvb.
      
      The root cause is that, instead of calling threadio->fnc() for
      all types of events except for VB2_BUF_STATE_ERROR, it was calling
      it only for VB2_BUF_STATE_DONE.
      
      With that, the DVB thread were never called.
      
      Cc: stable@vger.kernel.org # Kernel >= 4.3
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      1f2c4501
    • H
      [media] vb2: fix nasty vb2_thread regression · fac710e4
      Hans Verkuil 提交于
      The vb2_thread implementation was made generic and was moved from
      videobuf2-v4l2.c to videobuf2-core.c in commit af3bac1a. Unfortunately
      that clearly was never tested since it broke read() causing NULL address
      references.
      
      The root cause was confused handling of vb2_buffer vs v4l2_buffer (the pb
      pointer in various core functions).
      
      The v4l2_buffer no longer exists after moving the code into the core and
      it is no longer needed. However, the vb2_thread code passed a pointer to
      a vb2_buffer to the core functions were a v4l2_buffer pointer was expected
      and vb2_thread expected that the vb2_buffer fields would be filled in
      correctly.
      
      This is obviously wrong since v4l2_buffer != vb2_buffer. Note that the
      pb pointer is a void pointer, so no type-checking took place.
      
      This patch fixes this problem:
      
      1) allow pb to be NULL for vb2_core_(d)qbuf. The vb2_thread code will use
         a NULL pointer here since they don't care about v4l2_buffer anyway.
      2) let vb2_core_dqbuf pass back the index of the received buffer. This is
         all vb2_thread needs: this index is the index into the q->bufs array
         and vb2_thread just gets the vb2_buffer from there.
      3) the fileio->b pointer (that originally contained a v4l2_buffer) is
         removed altogether since it is no longer needed.
      
      Tested with vivid and the cobalt driver.
      
      Cc: stable@vger.kernel.org # Kernel >= 4.3
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: NMatthias Schwarzott <zzam@gentoo.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      fac710e4