1. 31 10月, 2015 2 次提交
  2. 12 8月, 2015 1 次提交
  3. 11 8月, 2015 2 次提交
    • R
    • C
      mfd: arizona: Fix race between runtime suspend and IRQs · 16f6a0df
      Charles Keepax 提交于
      The function arizona_irq_thread (the threaded handler for the arizona
      IRQs) calls pm_runtime_get_sync at the start to ensure that the chip is
      active as we handle the IRQ. If the chip is part way through a runtime
      suspend when an IRQ arrives the PM core will wait for the suspend to
      complete, before resuming. However, since commit 4f0216409f7c
      ("mfd: arizona: Add better support for system suspend") the runtime
      suspend function may call disable_irq, if the chip is going to fully
      power off, which will try to wait for any outstanding IRQs to complete.
      This results in deadlock as the IRQ thread is waiting for the PM
      operation to complete and the PM thread is waiting for the IRQ to
      complete.
      
      To avoid this situation we use disable_irq_nosync, which allows the
      suspending thread to finish the suspend without waiting for the IRQ to
      complete. This is safe because if an IRQ is being processed it can only
      be blocked at the pm_runtime_get_sync at the start of the handler
      otherwise it wouldn't be possible to suspend.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      16f6a0df
  4. 24 7月, 2015 2 次提交
    • C
      mfd: arizona: Fix initialisation of the PM runtime · 72e43164
      Charles Keepax 提交于
      The PM runtime core by default assumes a chip is suspended when runtime
      PM is enabled. Currently the arizona driver enables runtime PM when the
      chip is fully active and then disables the DCVDD regulator at the end of
      arizona_dev_init. This however has several problems, firstly the if we
      reach the end of arizona_dev_init, we did not properly follow all the
      proceedures for shutting down the chip, and most notably we never marked
      the chip as cache only so any writes occurring between then and the next
      PM runtime resume will be lost. Secondly, if we are already resumed when
      we reach the end of dev_init, then at best we get unbalanced regulator
      enable/disables at work we lose DCVDD whilst we need it.
      
      Additionally, since the commit 4f0216409f7c ("mfd: arizona: Add better
      support for system suspend"), the PM runtime operations may
      disable/enable the IRQ, so the IRQs must now be enabled before we call
      any PM operations.
      
      This patch adds a call to pm_runtime_set_active to inform the PM core
      that the device is starting up active and moves the PM enabling to
      around the IRQ initialisation to avoid any PM callbacks happening until
      the IRQs are initialised.
      
      Cc: stable@vger.kernel.org # v3.5+
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      72e43164
    • C
      mfd: arizona: Fix race between runtime suspend and IRQs · 11150929
      Charles Keepax 提交于
      The function arizona_irq_thread (the threaded handler for the arizona
      IRQs) calls pm_runtime_get_sync at the start to ensure that the chip is
      active as we handle the IRQ. If the chip is part way through a runtime
      suspend when an IRQ arrives the PM core will wait for the suspend to
      complete, before resuming. However, since commit 4f0216409f7c
      ("mfd: arizona: Add better support for system suspend") the runtime
      suspend function may call disable_irq, if the chip is going to fully
      power off, which will try to wait for any outstanding IRQs to complete.
      This results in deadlock as the IRQ thread is waiting for the PM
      operation to complete and the PM thread is waiting for the IRQ to
      complete.
      
      To avoid this situation we use disable_irq_nosync, which allows the
      suspending thread to finish the suspend without waiting for the IRQ to
      complete. This is safe because if an IRQ is being processed it can only
      be blocked at the pm_runtime_get_sync at the start of the handler
      otherwise it wouldn't be possible to suspend.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      11150929
  5. 17 7月, 2015 1 次提交
  6. 22 6月, 2015 11 次提交
  7. 12 3月, 2015 1 次提交
  8. 26 2月, 2015 1 次提交
  9. 05 12月, 2014 1 次提交
  10. 26 9月, 2014 4 次提交
  11. 28 7月, 2014 3 次提交
  12. 09 7月, 2014 6 次提交
  13. 03 6月, 2014 1 次提交
  14. 19 4月, 2014 2 次提交
  15. 26 2月, 2014 1 次提交
    • C
      mfd: arizona: Use new regmap features for manual register patch · 1c18d2ca
      Charles Keepax 提交于
      On the wm5102 the register patches are applied manually, rather than by
      the regmap core. This application is wrapped in calls to
      regcache_cache_bypass. However, this is dangerous as other threads may
      be accessing the hardware at the same time as the pm_runtime operations
      and if they do so during the period whilst cache_bypass is enabled those
      writes will miss the cache when they shouldn't.
      
      Apply the register patch using the new regmap_multi_reg_write_bypassed
      function to avoid this problem. Also remove the call to
      regcache_cache_bypass from the hardware patch application as it is
      unneeded there and creates a similar window for writes to miss the
      cache.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      1c18d2ca
  16. 06 1月, 2014 1 次提交