1. 22 3月, 2014 1 次提交
  2. 19 3月, 2014 1 次提交
  3. 18 3月, 2014 1 次提交
  4. 12 3月, 2014 1 次提交
  5. 06 3月, 2014 1 次提交
  6. 05 3月, 2014 1 次提交
  7. 19 2月, 2014 1 次提交
  8. 15 2月, 2014 1 次提交
  9. 21 1月, 2014 1 次提交
  10. 24 12月, 2013 2 次提交
  11. 19 12月, 2013 1 次提交
  12. 21 9月, 2013 1 次提交
  13. 17 9月, 2013 2 次提交
    • L
      regulator: add STw481x VMMC driver · 3615a34e
      Linus Walleij 提交于
      The ST Microelectronics STw481x PMIC used for the Nomadik
      has one single software-controlled regulator for VMMC.
      This driver registers directly to the compatible string
      as there is just one regulator.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      3615a34e
    • 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
  14. 30 8月, 2013 3 次提交
  15. 07 8月, 2013 1 次提交
  16. 29 7月, 2013 1 次提交
    • A
      regulator: pfuze100: REGULATOR_PFUZE100 needs to select REGMAP_I2C · 94421b05
      Axel Lin 提交于
      This fixes below build errors:
      
        CC [M]  drivers/regulator/pfuze100-regulator.o
      drivers/regulator/pfuze100-regulator.c:342:21: error: variable 'pfuze_regmap_config' has initializer but incomplete type
      drivers/regulator/pfuze100-regulator.c:343:2: error: unknown field 'reg_bits' specified in initializer
      drivers/regulator/pfuze100-regulator.c:343:2: warning: excess elements in struct initializer [enabled by default]
      drivers/regulator/pfuze100-regulator.c:343:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default]
      drivers/regulator/pfuze100-regulator.c:344:2: error: unknown field 'val_bits' specified in initializer
      drivers/regulator/pfuze100-regulator.c:344:2: warning: excess elements in struct initializer [enabled by default]
      drivers/regulator/pfuze100-regulator.c:344:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default]
      drivers/regulator/pfuze100-regulator.c:345:2: error: unknown field 'max_register' specified in initializer
      drivers/regulator/pfuze100-regulator.c:345:2: warning: excess elements in struct initializer [enabled by default]
      drivers/regulator/pfuze100-regulator.c:345:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default]
      drivers/regulator/pfuze100-regulator.c:346:2: error: unknown field 'cache_type' specified in initializer
      drivers/regulator/pfuze100-regulator.c:346:2: warning: excess elements in struct initializer [enabled by default]
      drivers/regulator/pfuze100-regulator.c:346:2: warning: (near initialization for 'pfuze_regmap_config') [enabled by default]
      drivers/regulator/pfuze100-regulator.c: In function 'pfuze100_regulator_probe':
      drivers/regulator/pfuze100-regulator.c:370:2: error: implicit declaration of function 'devm_regmap_init_i2c' [-Werror=implicit-function-declaration]
      drivers/regulator/pfuze100-regulator.c:370:21: warning: assignment makes pointer from integer without a cast [enabled by default]
      cc1: some warnings being treated as errors
      make[2]: *** [drivers/regulator/pfuze100-regulator.o] Error 1
      make[1]: *** [drivers/regulator] Error 2
      make: *** [drivers] Error 2
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      94421b05
  17. 25 7月, 2013 1 次提交
  18. 20 7月, 2013 2 次提交
  19. 18 7月, 2013 1 次提交
  20. 25 6月, 2013 1 次提交
  21. 12 5月, 2013 1 次提交
    • A
      regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver · 40b1936e
      Andrii.Tseglytskyi 提交于
      Adaptive Body Biasing (ABB) modulates transistor bias voltages
      dynamically in order to optimize switching speed versus leakage.
      
      Texas Instruments' SmartReflex 2 technology provides support for this
      power management technique with Forward Body Biasing (FBB) and Reverse
      Body Biasing (RBB). These modulate the body voltage of transistor
      cells or blocks dynamically to gain performance and reduce leakage.
      TI's SmartReflex white paper[1] has further information for usage in
      conjunction with other power management techniques.
      
      The application of FBB/RBB technique is determined for each unique
      device in some process nodes, whereas, they are mandated on other
      process nodes.
      
      In a nutshell, ABB technique is implemented on TI SoC as an on-chip
      LDO which has ABB module controlling the bias voltage. However, the
      voltage is unique per device. These vary per SoC family and the manner
      in which these techniques are used may vary depending on the Operating
      Performance Point (OPP) voltage targeted. For example:
      OMAP3630/OMAP4430: certain OPPs mandate usage of FBB independent of
      	devices.
      OMAP4460/OMAP4470: certain OPPs mandate usage of FBB, while others may
      	optionally use FBB or optimization with RBB.
      OMAP5: ALL OPPs may optionally use ABB, and ABB biasing voltage is
      	influenced by vset fused in s/w and requiring s/w override of
      	default values.
      
      Further, two generations of ABB module are used in various TI SoCs.
      They have remained mostly register field compatible, however the
      register offset had switched between versions.
      
      We introduce ABB LDO support in the form of a regulator which is
      controlled by voltages denoting the desired Operating Performance
      Point which is targeted. However, since ABB transition is part of OPP
      change sequence, the sequencing required to ensure sane operation
      w.r.t OPP change is left to the controlling driver (example: cpufreq
      SoC driver) using standard regulator operations.
      
      The driver supports all ABB modes and ability to override ABB LDO vset
      control efuse based ABB mode detection etc.
      
      Current implementation is heavily influenced by the original patch
      series [2][3] from Mike Turquette. However, the current implementation
      supports only device tree based information.
      
      [1] http://www.ti.com/pdfs/wtbu/smartreflex_whitepaper.pdf
      [2] http://marc.info/?l=linux-omap&m=134931341818379&w=2
      [3] http://marc.info/?l=linux-arm-kernel&m=134931402406853&w=2
      
      [nm@ti.com: co-developer]
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NAndrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      40b1936e
  22. 16 4月, 2013 1 次提交
  23. 13 1月, 2013 1 次提交
  24. 25 12月, 2012 1 次提交
  25. 23 11月, 2012 1 次提交
  26. 19 11月, 2012 1 次提交
  27. 15 11月, 2012 1 次提交
  28. 13 11月, 2012 1 次提交
  29. 01 11月, 2012 1 次提交
  30. 15 10月, 2012 2 次提交
  31. 17 9月, 2012 1 次提交
  32. 10 9月, 2012 1 次提交
  33. 29 8月, 2012 1 次提交
    • G
      regulator: add MAX8907 driver · ffee1909
      Gyungoh Yoo 提交于
      The MAX8907 is an I2C-based power-management IC containing voltage
      regulators, a reset controller, a real-time clock, and a touch-screen
      controller.
      
      The original driver was written by:
      * Gyungoh Yoo <jack.yoo@maxim-ic.com>
      
      Various fixes and enhancements by:
      * Jin Park <jinyoungp@nvidia.com>
      * Tom Cherry <tcherry@nvidia.com>
      * Prashant Gaikwad <pgaikwad@nvidia.com>
      * Dan Willemsen <dwillemsen@nvidia.com>
      * Laxman Dewangan <ldewangan@nvidia.com>
      
      During upstreaming, I (swarren):
      * Converted to regmap.
      * Allowed probing from device tree.
      * Reworked the regulator driver to be represented as a single device that
        provides multiple regulators, rather than as a device per regulator.
      * Replaced many regulator ops with standard functions.
      * Added ability to specify supplies for each regulator.
      * Removed the WLED regulator. If/when we expose this in the driver, it
        should be a backlight object not a regulator object.
      * Renamed from max8907c->max8907, since the driver covers at least the
        C and B revisions.
      * General cleanup.
      Signed-off-by: NGyungoh Yoo <jack.yoo@maxim-ic.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      ffee1909
  34. 04 8月, 2012 1 次提交