Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 7月, 2016 1 次提交
  3. 05 3月, 2016 2 次提交
    • L
      regmap: irq: add devm apis for regmap_{add,del}_irq_chip · 045b9848
      由 Laxman Dewangan 提交于 
      Add device managed APIs for regmap_add_irq_chip() and
regmap_del_irq_chip() so that it can be managed by
device framework for freeing it.

This helps on following:
1. Maintaining the sequence of resource allocation and deallocation
	regmap_add_irq_chip(&d);
	devm_requested_threaded_irq(virq)

	On free path:
		regmap_del_irq_chip(d);
		and then removing the irq registration.

	On this case, regmap irq is deleted before the irq is free.
	This force to use normal irq registration.

	By using devm apis, the sequence can be maintain properly:
		devm_regmap_add_irq_chip(&d);
		devm_requested_threaded_irq(virq);

	and resource deallocation will be done in reverse order
	by device framework.

2. No need to delete the regmap_irq_chip in error path or remove
   callback and hence there is less code on this path.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      045b9848
    • K
      regmap: replace regmap_write_bits() · b821957a
      由 Kuninori Morimoto 提交于 
      commit 23b92e4cf5fd ("regmap: remove regmap_write_bits()")
removed regmap_write_bits(), but MFD driver was using it.
So, commit e30fccd6771d ("regmap: Keep regmap_write_bits()")
turns out it, but it is using original style.
This patch uses regmap_update_bits_base() for regmap_write_bits()
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      b821957a
  5. 26 2月, 2016 2 次提交
  7. 20 2月, 2016 11 次提交
  9. 16 2月, 2016 1 次提交
    • L
      regmap: irq: add devm apis for regmap_{add,del}_irq_chip · 800c3a0e
      由 Laxman Dewangan 提交于 
      Add device managed APIs for regmap_add_irq_chip() and
regmap_del_irq_chip() so that it can be managed by
device framework for freeing it.

This helps on following:
1. Maintaining the sequence of resource allocation and deallocation
	regmap_add_irq_chip(&d);
	devm_requested_threaded_irq(virq)

	On free path:
		regmap_del_irq_chip(d);
		and then removing the irq registration.

	On this case, regmap irq is deleted before the irq is free.
	This force to use normal irq registration.

	By using devm apis, the sequence can be maintain properly:
		devm_regmap_add_irq_chip(&d);
		devm_requested_threaded_irq(virq);

	and resource deallocation will be done in reverse order
	by device framework.

2. No need to delete the regmap_irq_chip in error path or remove
   callback and hence there is less code on this path.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      800c3a0e
  11. 23 1月, 2016 1 次提交
  13. 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
  15. 02 12月, 2015 1 次提交
  17. 06 10月, 2015 2 次提交
  19. 05 10月, 2015 1 次提交
  21. 25 9月, 2015 1 次提交
  23. 17 9月, 2015 2 次提交
  25. 30 8月, 2015 2 次提交
  27. 22 8月, 2015 1 次提交
  29. 12 8月, 2015 1 次提交
  31. 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
  33. 17 7月, 2015 2 次提交
  35. 10 7月, 2015 2 次提交
  37. 22 5月, 2015 2 次提交
  39. 27 1月, 2015 1 次提交
  41. 19 11月, 2014 1 次提交
  43. 26 7月, 2014 1 次提交