1. 25 9月, 2015 1 次提交
  2. 30 8月, 2015 2 次提交
  3. 22 8月, 2015 1 次提交
  4. 12 8月, 2015 1 次提交
  5. 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
  6. 17 7月, 2015 2 次提交
  7. 10 7月, 2015 2 次提交
  8. 22 5月, 2015 2 次提交
  9. 27 1月, 2015 1 次提交
  10. 19 11月, 2014 1 次提交
  11. 26 7月, 2014 2 次提交
  12. 18 4月, 2014 1 次提交
  13. 11 3月, 2014 1 次提交
  14. 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
  15. 26 2月, 2014 2 次提交
  16. 16 2月, 2014 2 次提交
  17. 09 1月, 2014 1 次提交
  18. 17 12月, 2013 1 次提交
  19. 29 10月, 2013 1 次提交
  20. 14 10月, 2013 1 次提交
  21. 09 10月, 2013 1 次提交
  22. 21 9月, 2013 1 次提交
  23. 17 9月, 2013 2 次提交
  24. 15 8月, 2013 1 次提交
  25. 07 8月, 2013 1 次提交
  26. 24 7月, 2013 3 次提交
  27. 12 6月, 2013 1 次提交
    • S
      regmap: Add regmap_field APIs · 67252287
      Srinivas Kandagatla 提交于
      It is common to access regmap registers at bit level, using
      regmap_update_bits or regmap_read functions, however the end user has to
      take care of a mask or shifting. This becomes overhead when such use
      cases are high. Having a common function to do this is much convenient
      and less error prone.
      
      The idea of regmap_field is simple, regmap_field gives a logical
      structure to bits of the regmap register, and the driver can use this
      logical entity without the knowledge of the bit positions and masks all
      over the code. This way code looks much neat and it need not handle the
      masks, shifts every time it access the those entities.
      
      With this new regmap_field_read/write apis the end user can setup a
      regmap field using regmap_field_init and use the return regmap_field to
      read write the register field without worrying about the masks or
      shifts.
      
      Also this apis will be useful for drivers which are based on regmaps,
      like some clocks or pinctrls which can work on the regmap_fields
      directly without having to worry about bit positions.
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      67252287
  28. 12 5月, 2013 2 次提交
  29. 27 3月, 2013 1 次提交