1. 21 Jan, 2014 1 commit
  2. 20 Sep, 2013 1 commit
  3. 16 Sep, 2013 2 commits
    • Linus Walleij's avatar
      regulator: add STw481x VMMC driver · 3615a34e
      Linus Walleij authored
      
      
      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: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      3615a34e
    • Mark Brown's avatar
      regulator: core: Provide a dummy regulator with full constraints · 4ddfebd3
      Mark Brown authored
      
      
      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: default avatarMark Brown <broonie@linaro.org>
      4ddfebd3
  4. 30 Aug, 2013 1 commit
  5. 29 Aug, 2013 2 commits
  6. 06 Aug, 2013 1 commit
  7. 29 Jul, 2013 1 commit
    • Axel Lin's avatar
      regulator: pfuze100: REGULATOR_PFUZE100 needs to select REGMAP_I2C · 94421b05
      Axel Lin authored
      
      
      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: default avatarAxel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      94421b05
  8. 25 Jul, 2013 1 commit
  9. 19 Jul, 2013 2 commits
  10. 18 Jul, 2013 1 commit
  11. 25 Jun, 2013 1 commit
  12. 12 May, 2013 1 commit
    • Andrii.Tseglytskyi's avatar
      regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver · 40b1936e
      Andrii.Tseglytskyi authored
      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: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarAndrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      40b1936e
  13. 16 Apr, 2013 1 commit
  14. 13 Jan, 2013 1 commit
  15. 24 Dec, 2012 1 commit
  16. 23 Nov, 2012 1 commit
  17. 19 Nov, 2012 1 commit
  18. 15 Nov, 2012 1 commit
  19. 13 Nov, 2012 1 commit
  20. 01 Nov, 2012 1 commit
  21. 15 Oct, 2012 2 commits
  22. 17 Sep, 2012 1 commit
  23. 10 Sep, 2012 1 commit
  24. 28 Aug, 2012 1 commit
    • Gyungoh Yoo's avatar
      regulator: add MAX8907 driver · ffee1909
      Gyungoh Yoo authored
      
      
      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: default avatarGyungoh Yoo <jack.yoo@maxim-ic.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      ffee1909
  25. 04 Aug, 2012 1 commit
  26. 03 Aug, 2012 1 commit
  27. 20 Jul, 2012 1 commit
  28. 16 Jul, 2012 1 commit
  29. 11 Jul, 2012 1 commit
  30. 21 Jun, 2012 1 commit
  31. 20 Jun, 2012 2 commits
  32. 19 Jun, 2012 1 commit
  33. 03 Jun, 2012 1 commit
  34. 19 May, 2012 1 commit
  35. 04 Apr, 2012 1 commit