1. 26 2月, 2016 2 次提交
  2. 20 2月, 2016 11 次提交
  3. 06 1月, 2016 1 次提交
    • L
      regmap: irq: add support for configuration of trigger type · 7a78479f
      Laxman Dewangan 提交于
      Some of devices supports the trigger level for interrupt
      like rising/falling edge specially for GPIOs. The interrupt
      support of such devices may have uses the generic regmap irq
      framework for implementation.
      
      Add support to configure the trigger type device interrupt
      register via regmap-irq framework. The regmap-irq framework
      configures the trigger register only if the details of trigger
      type registers are provided.
      
      [Fixed use of terery operator for legibility -- broonie]
      Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      7a78479f
  4. 02 12月, 2015 1 次提交
  5. 06 10月, 2015 2 次提交
  6. 05 10月, 2015 1 次提交
  7. 25 9月, 2015 1 次提交
  8. 17 9月, 2015 2 次提交
  9. 30 8月, 2015 2 次提交
  10. 22 8月, 2015 1 次提交
  11. 12 8月, 2015 1 次提交
  12. 07 8月, 2015 1 次提交
    • N
      regmap: Use different lockdep class for each regmap init call · 3cfe7a74
      Nicolas Boichat 提交于
      Lockdep validator complains about recursive locking and deadlock
      when two different regmap instances are called in a nested order.
      That happens anytime a regmap read/write call needs to access
      another regmap.
      
      This is because, for performance reason, lockdep groups all locks
      initialized by the same mutex_init() in the same lock class.
      Therefore all regmap mutexes are in the same lock class, leading
      to lockdep "nested locking" warnings if a regmap accesses another
      regmap.
      
      In general, it is impossible to establish in advance the hierarchy
      of regmaps, so we make sure that each regmap init call initializes
      its own static lock_class_key. This is done by wrapping all
      regmap_init calls into macros.
      
      This also allows us to give meaningful names to the lock_class_key.
      For example, in rt5677 case, we have in /proc/lockdep_chains:
      irq_context: 0
      [ffffffc0018d2198] &dev->mutex
      [ffffffc0018d2198] &dev->mutex
      [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock
      [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock
      [ffffffc001b95448] &(&base->lock)->rlock
      
      The above would have resulted in a lockdep recursive warning
      previously. This is not the case anymore as the lockdep validator
      now clearly identifies the 2 regmaps as separate.
      Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      3cfe7a74
  13. 17 7月, 2015 2 次提交
  14. 10 7月, 2015 2 次提交
  15. 22 5月, 2015 2 次提交
  16. 27 1月, 2015 1 次提交
  17. 19 11月, 2014 1 次提交
  18. 26 7月, 2014 2 次提交
  19. 18 4月, 2014 1 次提交
  20. 11 3月, 2014 1 次提交
  21. 06 3月, 2014 1 次提交
    • N
      regmap: add regmap_parse_val api · 13ff50c8
      Nenghua Cao 提交于
          In some cases, we need regmap's format parse_val function
      to do be/le translation according to the bus configuration.
      For example, snd_soc_bytes_put() uses regmap to write/read values,
      and use cpu_to_be() directly to covert MASK into big endian. This
      is a defect, and should use regmap's format function to do it according
      to bus configuration.
      Signed-off-by: NNenghua Cao <nhcao@marvell.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      13ff50c8
  22. 26 2月, 2014 1 次提交