1. 04 7月, 2012 2 次提交
    • 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
  2. 27 6月, 2012 1 次提交
  3. 26 6月, 2012 2 次提交
  4. 18 6月, 2012 4 次提交
  5. 04 6月, 2012 1 次提交
  6. 03 6月, 2012 4 次提交
  7. 14 5月, 2012 3 次提交
  8. 12 5月, 2012 2 次提交
  9. 10 5月, 2012 1 次提交
  10. 07 5月, 2012 1 次提交
  11. 20 4月, 2012 1 次提交
    • M
      regulator: core: Optimise enable/disable path for always on regulators · 6492bc1b
      Mark Brown 提交于
      If a regulator is always on for any reason then cache that when the
      consumer is created and use it to optimise away the need to take locks
      or recurse up the supply tree when consumers do enable or disable calls.
      The scheduling of asynchronous work for bulk enables is also skipped.
      
      We don't actually check if the device physically supports control on the
      basis that constraints allowing status changes on physically always on
      regulators are nonsensical anyway.
      
      This is a very common pattern in hardware - it's normal to have some
      power supplies that have either no software control or are critical to
      system function - so many systems should be able to benefit.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      6492bc1b
  12. 17 4月, 2012 4 次提交
  13. 16 4月, 2012 2 次提交
  14. 11 4月, 2012 1 次提交
  15. 09 4月, 2012 1 次提交
    • M
      regulator: core: Use a struct to pass in regulator runtime configuration · c172708d
      Mark Brown 提交于
      Rather than adding new arguments to regulator_register() every time we
      want to add a new bit of dynamic information at runtime change the function
      to take these via a struct. By doing this we avoid needing to do further
      changes like the recent addition of device tree support which required each
      regulator driver to be updated to take an additional parameter.
      
      The regulator_desc which should (mostly) be static data is still passed
      separately as most drivers are able to configure this statically at build
      time.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      c172708d
  16. 05 4月, 2012 1 次提交
  17. 04 4月, 2012 1 次提交
  18. 03 4月, 2012 3 次提交
  19. 30 3月, 2012 1 次提交
  20. 17 3月, 2012 1 次提交
  21. 13 3月, 2012 1 次提交
  22. 24 2月, 2012 1 次提交
  23. 21 2月, 2012 1 次提交