1. 17 9月, 2015 1 次提交
  2. 25 7月, 2015 1 次提交
  3. 12 6月, 2015 4 次提交
  4. 01 5月, 2015 1 次提交
  5. 27 11月, 2014 1 次提交
    • J
      regulator: Document binding for initial and suspend modes · 218094c9
      Javier Martinez Canillas 提交于
      Some regulators can run on different operating modes (opmodes). This
      allows systems to choose the most efficient opmode for each regulator.
      
      This patch builds on top of (291d761c regulator: Document binding for
      regulator suspend state for PM state) adding a regulator-initial-mode
      DT property to configure at startup the operating mode for regulators
      that support changing its mode during normal operation and a property
      regulator-mode to be used in the regulator-state-[mem/disk] nodes for
      regulators that supports changing its operating mode when the system
      enters in a suspend state.
      
      The set of possible modes that a regulator can operate depends on the
      hardware capabilities so a list of generic operating modes can't be
      provided. Instead, each hardware binding should define the list of
      valid operating modes for the regulators found on that device.
      Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      218094c9
  6. 03 11月, 2014 1 次提交
  7. 20 10月, 2014 1 次提交
  8. 05 5月, 2014 1 次提交
  9. 19 9月, 2013 1 次提交
  10. 15 7月, 2013 1 次提交
  11. 20 6月, 2013 1 次提交
  12. 25 9月, 2012 1 次提交
    • S
      regulator: deprecate regulator-compatible DT property · 13511def
      Stephen Warren 提交于
      When the bindings for the TPS6586x regulator were being proposed, I
      asserted that DT node naming rules for bus child nodes should also be
      applied to nodes inside the TPS6586x regulator node itself. In other
      words, that each node providing regulator init data should be named
      after the type of object it represented ("regulator") and hence that
      some other property was required to indicate which regulator the node
      described ("regulator-compatible"). In turn this led to multiple nodes
      having the same name, thus requiring node names to use a unit address
      to make them unique, thus requiring reg properties within the nodes and
      
      However, subsequent discussion indicates that the rules I was asserting
      only applies to standardized bus nodes, and within a device's own node,
      the binding can basically do anything sane that it wants.
      
      Hence, this change deprecates the register-compatible property, and
      instead uses node names to replace this functionality. This greatly
      simplifies the device tree content, making them smaller and more legible.
      
      The code is changed such that old device trees continue to work.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      13511def
  13. 05 7月, 2012 1 次提交
  14. 18 6月, 2012 2 次提交
    • A
      regulator: core: Change the unit of ramp_delay from mV/uS to uV/uS · ea38d13f
      Axel Lin 提交于
      This change makes it possible to set ramp_delay with 0.xxx mV/uS without
      truncation issue.
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      ea38d13f
    • Y
      regulator: Add ramp_delay configuration to constraints · 6f0b2c69
      Yadwinder Singh Brar 提交于
      For some hardwares ramp_delay for BUCKs is a configurable parameter which can
      be configured through DT or board file.This patch adds ramp_delay to regulator
      constraints and allow user to configure it for regulators which supports this
      feature, through DT or board file. It will provide two ways of setting the
      ramp_delay for a regulator:
      	First, by setting it as constraints in board file(for configurable
      regulators) and set_machine_constraints() will take care of setting it on
      hardware by calling(the provided) .set_ramp_delay() operation(callback).
      	Second, by setting it as data in regulator_desc(as fixed/default
      ramp_delay rate) for a regulator in driver.
      
      regulator_set_voltage_time_sel() will give preference to
      constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly
      users should also take care accordingly while refering ramp_delay rate(in case
      of implementing their private .set_voltage_time_sel() callbacks for different
      regulators).
      
      [Rewrote subject for 80 columns -- broonie]
      Signed-off-by: NYadwinder Singh Brar <yadi.brar@samsung.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      6f0b2c69
  15. 29 11月, 2011 1 次提交
  16. 24 11月, 2011 1 次提交
    • R
      regulator: helper routine to extract regulator_init_data · 8f446e6f
      Rajendra Nayak 提交于
      The helper routine is meant to be used by the regulator drivers
      to extract the regulator_init_data structure from the data
      that is passed from device tree.
      'consumer_supplies' which is part of regulator_init_data is not extracted
      as the regulator consumer mappings are passed through DT differently,
      implemented in subsequent patches.
      Similarly the regulator<-->parent/supply mapping is handled in
      subsequent patches.
      
      Also add documentation for regulator bindings to be used to pass
      regulator_init_data struct information from device tree.
      
      Some of the regulator properties which are linux and board specific,
      are left out since its not clear if they can
      be in someway embedded into the kernel or passed in from DT.
      They will be revisited later.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      8f446e6f