Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 8月, 2012 1 次提交
  3. 10 8月, 2012 1 次提交
  5. 08 8月, 2012 2 次提交
  7. 04 8月, 2012 1 次提交
  9. 20 7月, 2012 1 次提交
  11. 13 7月, 2012 2 次提交
  13. 07 7月, 2012 1 次提交
  15. 05 7月, 2012 1 次提交
  17. 04 7月, 2012 6 次提交
    • M
      regulator: core: Add core support for GPIO controlled enable lines · 65f73508
      由 Mark Brown 提交于 
      It is very common for regulators to support having their enable signal
controlled by a GPIO. Since there are a bunch of fiddly things to get
right like handling the operations when the enable signal is tied to
a rail and it's just replicated code add support for this to the core.

Drivers should set ena_gpio in their config if they have a GPIO control,
using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for
the initial state) and ena_gpio_invert if the GPIO is active low. The
core will then override any enable and disable operations the driver has
and instead control the specified GPIO.

This will in the future also allow us to further extend the core by
identifying when several enable signals have been tied together and
handling this properly.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      65f73508
    • M
      regulator: core: Factor out enable and disable operations some more · 5c5659d0
      由 Mark Brown 提交于 
      Create new _regulator_do_enable() and _regulator_do_disable() operations
which deal with the mechanics of performing the enable and disable, partly
to cut down on the levels of indentation and partly to support some future
work.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      5c5659d0
    • M
      regulator: core: Allow fixed enable_time to be set in the regulator_desc · 79511ed3
      由 Mark Brown 提交于 
      Many regulators have a fixed specification for their enable time. Allow
this to be set in the regulator_desc as a number to save them having to
implement an explicit operation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      79511ed3
    • M
      regulator: core: Check that the selector from map_voltage() is valid · e113d792
      由 Mark Brown 提交于 
      Lots of regulator drivers have checks in their map_voltage() functions
to verify that the result of the mapping is in the range originally
specified. Factor these out in the core and provide a bit of extra
defensiveness for other drivers by doing the check in the core.

Since we're now doing a list_voltage() earlier move the current mapping
back to a voltage out into the set_voltage() call to save redoing it.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      e113d792
    • M
      regulator: core: Support fixed voltages in regulator_is_supported_voltage() · c5f3939b
      由 Mark Brown 提交于 
      Currently regulator_is_supported_voltage() works by enumerating the set
of voltages which can be set by the regulator but the checks we're doing
to impose constraints mean that if we can't vary the voltage we'll not
report any voltages as supported even though the regulator is actually
set at that voltage.

We could fix the voltage listing but this would mean that list_voltage()
could end up going to the hardware to get the current voltage which isn't
expected (it's supposed to be very cheap) so instead special case things
when we can't change the voltage and compare the requested range against
the current voltage.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      c5f3939b
    • S
      regulator: Fix recursive mutex lockdep warning · d92d95b6
      由 Stephen Boyd 提交于 
      A recursive lockdep warning occurs if you call
regulator_set_optimum_mode() on a regulator with a supply because
there is no nesting annotation for the rdev->mutex. To avoid this
warning, get the supply's load before locking the regulator's
mutex to avoid grabbing the same class of lock twice.

=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #3257 Tainted: G        W
---------------------------------------------
swapper/0/1 is trying to acquire lock:
 (&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38

but task is already holding lock:
 (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&rdev->mutex);
  lock(&rdev->mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by swapper/0/1:
 #0:  (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c
 #1:  (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c
 #2:  (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224

stack backtrace:
[<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080)
[<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10)
[<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8)
[<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4)
[<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38)
[<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224)
...
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d92d95b6
  19. 27 6月, 2012 1 次提交
  21. 26 6月, 2012 2 次提交
  23. 23 6月, 2012 2 次提交
  25. 18 6月, 2012 7 次提交
  27. 11 6月, 2012 2 次提交
  29. 08 6月, 2012 2 次提交
  31. 04 6月, 2012 1 次提交
  33. 03 6月, 2012 4 次提交
  35. 14 5月, 2012 3 次提交