1. 21 9月, 2013 1 次提交
  2. 17 9月, 2013 2 次提交
    • M
      regulator: core: Remove unused regulator_use_dummy_regulator() · 4f0ac6da
      Mark Brown 提交于
      No boards have used this functionality and the new default of providing
      dummy regulators by default provides a better solution to the problem it
      was trying to solve.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      4f0ac6da
    • M
      regulator: core: Provide a dummy regulator with full constraints · 4ddfebd3
      Mark Brown 提交于
      When a system has said that it has fully specified constraints for its
      regulators it is still possible that some supplies may be missing,
      especially if regulator support has been added to a driver after the
      board was integrated. We can handle such situations more gracefully by
      providing a dummy regulator.
      
      Unless the caller has specifically indicated that the system design may
      not include a given regulator by using regulator_get_optional() or that
      it needs its interactions to have an effect using regulator_get_exclusive()
      provide a dummy regulator if we can't locate a real one.
      
      The kconfig option REGULATOR_DUMMY that provided similar behaviour for all
      regulators has been removed, systems that need it should flag that they
      have full constraints instead.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      4ddfebd3
  3. 30 8月, 2013 1 次提交
  4. 19 8月, 2013 1 次提交
  5. 09 8月, 2013 1 次提交
  6. 07 8月, 2013 1 次提交
  7. 31 7月, 2013 1 次提交
    • M
      regulator: core: Provide hints to the core about optional supplies · de1dd9fd
      Mark Brown 提交于
      While the majority of supplies on devices are mandatory and can't be
      physically omitted for electrical reasons some devices do have optional
      supplies and need to know if they are missing, MMC being the most common
      of these.
      
      Currently the core accurately reports all errors when regulators are
      requested since it does not know if the supply is one that must be provided
      even if by a regulator software does not know about or if it is one that
      may genuinely be disconnected. In order to allow this behaviour to be
      changed and stub regulators to be provided in the former case add a new
      regulator request function regulator_get_optional() which provides a hint
      to the core that the regulator may genuinely not be connected.
      
      Currently the implementation is identical to the current behaviour, future
      patches will add support in the core for returning stub regulators in the
      case where normal regulator_get() fails and the board has requested it.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Acked-by: NChris Ball <cjb@laptop.org>
      de1dd9fd
  8. 25 7月, 2013 1 次提交
  9. 18 7月, 2013 3 次提交
  10. 15 7月, 2013 4 次提交
  11. 07 6月, 2013 1 次提交
  12. 21 5月, 2013 1 次提交
  13. 02 5月, 2013 1 次提交
  14. 18 4月, 2013 1 次提交
  15. 17 4月, 2013 1 次提交
  16. 05 4月, 2013 1 次提交
  17. 25 3月, 2013 1 次提交
  18. 05 3月, 2013 1 次提交
  19. 04 3月, 2013 3 次提交
    • K
      regulator: core: use regulator_ena_pin member · 7b74d149
      Kim, Milo 提交于
       The regulator_dev has regulator_enable_gpio structure.
       'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.
      
        regulator_dev   --->   regulator_enable_gpio
        .ena_gpio              .gpio
        .ena_gpio_invert       .ena_gpio_invert
      
        Pointer, 'ena_pin' is used for checking valid enable GPIO pin.
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Reviewed-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      7b74d149
    • K
      regulator: core: manage enable GPIO list · 967cfb18
      Kim, Milo 提交于
       To support shared enable GPIO pin, replace GPIO code with new static functions
      
       Reference count: 'enable_count'
         Balance the reference count of each GPIO and actual pin control.
         The count is incremented with enabling GPIO.
         On the other hand, it is decremented on disabling GPIO.
         Actual GPIO pin is enabled at the initial use.(enable_count = 0)
         The pin is disabled if it is not used(shared) any more. (enable_count <=1)
         Regardless of the enable count, update GPIO state of the regulator.
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Reviewed-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      967cfb18
    • K
      regulator: core: support shared enable GPIO concept · f19b00da
      Kim, Milo 提交于
       A Regulator can be enabled by external GPIO pin.
       This is configurable in the regulator_config.
       At this moment, the GPIO can be owned by only one regulator device.
       In some devices, multiple regulators are enabled by shared one GPIO pin.
       This patch extends this limitation, enabling shared enable GPIO of regulators.
      
       New list for enable GPIO: 'regulator_ena_gpio_list'
         This manages enable GPIO list.
      
       New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
         The enable count is used for balancing GPIO control count.
         This count is incremented when GPIO is enabled.
         On the other hand, it's decremented when GPIO is disabled.
      
       Reference count: 'request_count'
         The reference count, 'request_count' is incremented/decremented on
         requesting/freeing the GPIO. This count makes sure only free the GPIO
         when it has no users.
      
       How it works
         If the GPIO is already used, skip requesting new GPIO usage.
         The GPIO is new one, request GPIO function and add it to the list of
         enable GPIO.
         This list is used for balancing enable GPIO count and pin control.
      
       Updating a GPIO and invert code moved
         'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
          new function, regulator_ena_gpio_request().
          Use regulator_enable_pin structure rather than regulator_dev.
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Reviewed-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      f19b00da
  20. 01 3月, 2013 2 次提交
  21. 15 2月, 2013 1 次提交
    • R
      regulator: Fix memory garbage dev_err printout. · 9c7b4e8a
      Russ Dill 提交于
      commit dd8004af: 'regulator: core: Log when a device causes a voltage
      constraint fail', tried to print out some information about the
      check consumer min/max uV fixup, however, it uses a garbage pointer
      left over from list_for_each_entry leading to boot messages in the
      form:
      
      '[    2.079890] <RANDOM ASCII>: Restricting voltage, 3735899821-4294967295uV'
      
      Because it references regulator->dev, it could potentially read memory from
      anywhere causing a panic.
      
      This patch instead uses rdev and the updated min/max uV values.
      Signed-off-by: NRuss Dill <Russ.Dill@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      9c7b4e8a
  22. 08 2月, 2013 1 次提交
  23. 05 2月, 2013 1 次提交
  24. 03 1月, 2013 1 次提交
  25. 25 12月, 2012 2 次提交
  26. 15 12月, 2012 1 次提交
  27. 11 12月, 2012 1 次提交
  28. 06 12月, 2012 1 次提交
  29. 29 11月, 2012 2 次提交