1. 05 3月, 2016 1 次提交
  2. 26 2月, 2016 1 次提交
  3. 20 2月, 2016 12 次提交
  4. 02 2月, 2016 1 次提交
  5. 28 1月, 2016 1 次提交
    • M
      regmap: Add explict native endian flag to DT bindings · a06c488d
      Mark Brown 提交于
      Currently the binding document says that if no endianness is configured
      we use native endian but this is not in fact true for all binding types
      and we do have some devices that really want native endianness such as
      Broadcom MIPS SoCs where switching the endianness of the CPU also
      switches the endianness of external IPs.
      
      Provide an explicit option for this.
      Signed-off-by: NMark Brown <broonie@kernel.org>
      a06c488d
  6. 16 12月, 2015 1 次提交
  7. 13 12月, 2015 2 次提交
  8. 09 12月, 2015 2 次提交
  9. 06 10月, 2015 2 次提交
  10. 05 10月, 2015 1 次提交
  11. 15 9月, 2015 1 次提交
  12. 31 8月, 2015 2 次提交
  13. 30 8月, 2015 3 次提交
  14. 22 8月, 2015 3 次提交
  15. 21 8月, 2015 1 次提交
  16. 15 8月, 2015 1 次提交
  17. 12 8月, 2015 3 次提交
  18. 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
  19. 17 7月, 2015 1 次提交