1. 30 May, 2018 1 commit
  2. 29 May, 2018 2 commits
    • Linus Walleij's avatar
      regulator: gpio: Get enable GPIO using GPIO descriptor · 37bed97f
      Linus Walleij authored
      We augment the GPIO regulator to get the *enable* regulator
      GPIO line (not the other lines) using a descriptor rather than
      a global number.
      
      We then pass this into the regulator core which has been
      prepared to hande enable descriptors in a separate patch.
      
      Switch over the two boardfiles using this facility and clean
      up so we only pass descriptors around.
      
      Cc: Philipp Zabel <philipp.zabel@gmail.com> # HX4700/Magician maintainer
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      37bed97f
    • Linus Walleij's avatar
      regulator: fixed: Convert to use GPIO descriptor only · 6059577c
      Linus Walleij authored
      As we augmented the regulator core to accept a GPIO descriptor instead
      of a GPIO number, we can augment the fixed GPIO regulator to look up
      and pass that descriptor directly from device tree or board GPIO
      descriptor look up tables.
      
      Some boards just auto-enumerate their fixed regulator platform devices
      and I have assumed they get names like "fixed-regulator.0" but it's
      pretty hard to guess this. I need some testing from board maintainers to
      be sure. Other boards are straight forward, using just plain
      "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
      device ID.
      
      The OMAP didn't have proper label names on its GPIO chips so I have fixed
      this with a separate patch to the GPIO tree, see
      commit 088413bc
      "gpio: omap: Give unique labels to each GPIO bank/chip"
      
      It seems the da9055 and da9211 has never got around to actually passing
      any enable gpio into its platform data (not the in-tree code anyway) so we
      can just decide to simply pass a descriptor instead.
      
      The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
      "*_dummy_supply_device" while it is a very real device backed by a GPIO
      line. There is nothing dummy about it at all, so I renamed it with the
      infix *_regulator_* as part of this patch set.
      
      For the patch hunk hitting arch/blackfin I would say I do not expect
      testing, review or ACKs anymore so if it works, it works.
      
      The hunk hitting the x86 BCM43xx driver is especially tricky as the number
      comes out of SFI which is a mystery to me. I definately need someone to
      look at this. (Hi Andy.)
      
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff
      Cc: Alexander Shiyan <shc_work@mail.ru> # i.MX boards user
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com> # MMP2 maintainer
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP1 maintainer
      Cc: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> # EM-X270 maintainer
      Cc: Robert Jarzmik <robert.jarzmik@free.fr> # EZX maintainer
      Cc: Philipp Zabel <philipp.zabel@gmail.com> # Magician maintainer
      Cc: Daniel Mack <zonque@gmail.com> # Raumfeld maintainer
      Cc: Marc Zyngier <marc.zyngier@arm.com> # Zeus maintainer
      Cc: Geert Uytterhoeven <geert+renesas@glider.be> # SuperH pinctrl/GPIO maintainer
      Cc: Russell King <rmk+kernel@armlinux.org.uk> # SA1100
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      6059577c
  3. 26 May, 2018 1 commit
    • Mark Brown's avatar
      regulator: s2mps11: Fix boot on Odroid XU3 · 37fa23db
      Mark Brown authored
      The change to descriptors in 0369e02b "regulator: s2mps11: Pass
      descriptor instead of GPIO number" has broken the boot on Odroid XU3
      according to kernelci so let's revert that for now.  We get a NULL
      pointer defererence in:
      
      [    2.467929] [] (validate_desc) from [] (gpiod_set_value_cansleep+0x14/0x30)
      [    2.476591] [] (gpiod_set_value_cansleep) from [] (_regulator_do_enable+0x2f8/0x370)
      [    2.486032] [] (_regulator_do_enable) from [] (regulator_register+0xc54/0x1280)
      [    2.495045] [] (regulator_register) from [] (devm_regulator_register+0x40/0x7c)
      [    2.504057] [] (devm_regulator_register) from [] (s2mps11_pmic_probe+0x1c0/0x444)
      [    2.513243] [] (s2mps11_pmic_probe) from [] (platform_drv_probe+0x6c/0xa4)
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      37fa23db
  4. 24 May, 2018 14 commits
  5. 17 May, 2018 15 commits
    • Anson Huang's avatar
      regulator: pfuze100: add .is_enable() for pfuze100_swb_regulator_ops · 0b01fd3d
      Anson Huang authored
      If is_enabled() is not defined, regulator core will assume
      this regulator is already enabled, then it can NOT be really
      enabled after disabled.
      
      Based on Li Jun's patch from the NXP kernel tree.
      Signed-off-by: default avatarAnson Huang <Anson.Huang@nxp.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      0b01fd3d
    • Anson Huang's avatar
      regulator: pfuze100: add enable/disable for switch · 5fe156f1
      Anson Huang authored
      Add enable/disable support for switch regulator on pfuze100.
      
      Based on Robin Gong's patch from the NXP kernel tree.
      Signed-off-by: default avatarAnson Huang <Anson.Huang@nxp.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      5fe156f1
    • Linus Walleij's avatar
      regulator: wm8994: Pass descriptor instead of GPIO number · 3c6b38d4
      Linus Walleij authored
      Instead of passing a global GPIO number for the enable GPIO, pass
      a descriptor looked up from the device tree node or the board file
      decriptor table for the regulator.
      
      There is a single board file passing the GPIOs for LDO1 and LDO2
      through platform data, so augment this to pass descriptors
      associated with the i2c device as well.
      
      The special GPIO enable DT property for the enable GPIO is
      nonstandard but this was accomodated in
      commit 6a537d48
      "gpio: of: Support regulator nonstandard GPIO properties".
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      3c6b38d4
    • Maciej Purski's avatar
      regulator: core: Change voltage setting path · 456e7cdf
      Maciej Purski authored
      On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
      different devices on the board are supplied by different regulators
      with non-fixed voltages. If one of these devices temporarily requires
      higher voltage, there might occur a situation that the spread between
      two devices' voltages is so high, that there is a risk of changing
      'high' and 'low' states on the interconnection between devices powered
      by those regulators.
      
      Uncoupled regulators should be a special case of coupled regulators, so
      they should share a common voltage setting path. When enabling,
      disabling or setting voltage of a coupled regulator, all coupled
      regulators should be locked. Regulator's supplies should be locked, when
      setting voltage of a single regulator. Enabling a coupled regulator or
      setting its voltage should not be possible if some of its coupled
      regulators, has not been registered.
      
      Add function for locking coupled regulators and supplies. Extract
      a new function regulator_set_voltage_rdev() from
      regulator_set_voltage_unlocked(), which is called when setting
      voltage of a single regulator.
      Signed-off-by: default avatarMaciej Purski <m.purski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      456e7cdf
    • Maciej Purski's avatar
      regulator: core: Add voltage balancing mechanism · 69686176
      Maciej Purski authored
      On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
      different devices on the board are supplied by different regulators
      with non-fixed voltages. If one of these devices temporarily requires
      higher voltage, there might occur a situation that the spread between
      two devices' voltages is so high, that there is a risk of changing
      'high' and 'low' states on the interconnection between devices powered
      by those regulators.
      
      Introduce new function regulator_balance_voltage(), which
      keeps max_spread constraint fulfilled between a group of coupled
      regulators. It should be called if a regulator changes its
      voltage or after disabling or enabling. Disabled regulators should
      follow changes of the enabled ones, but their consumers' demands
      shouldn't be taken into account while calculating voltage of other
      coupled regulators.
      
      Find voltages, which are closest to suiting all the consumers' demands,
      while fulfilling max_spread constraint, keeping the following rules:
      - if one regulator is about to rise its voltage, rise others
        voltages in order to keep the max_spread
      - if a regulator, which has caused rising other regulators, is
        lowered, lower other regulators if possible
      - if one regulator is about to lower its voltage, but it hasn't caused
        rising other regulators, don't change its voltage if it breaks the
        max_spread
      
      Change regulators' voltages step by step, keeping max_spread constraint
      fulfilled all the time. Function regulator_get_optimal_voltage()
      should find the best possible change for the regulator, which doesn't
      break max_spread constraint. In function regulator_balance_voltage()
      optimize number of steps by finding highest voltage difference on
      each iteration.
      
      If a regulator, which is about to change its voltage, is not coupled,
      method regulator_get_optimal_voltage() should simply return the lowest
      voltage fulfilling consumers' demands.
      
      Coupling should be checked only if the system is in PM_SUSPEND_ON state.
      Signed-off-by: default avatarMaciej Purski <m.purski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      69686176
    • Maciej Purski's avatar
      regulator: core: Resolve coupled regulators · d3d64537
      Maciej Purski authored
      On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
      different devices on the board are supplied by different regulators
      with non-fixed voltages. If one of these devices temporarily requires
      higher voltage, there might occur a situation that the spread between
      two devices' voltages is so high, that there is a risk of changing
      'high' and 'low' states on the interconnection between devices powered
      by those regulators.
      
      Fill coupling descriptor with data obtained from DTS using previously
      defined of_functions. Fail to register a regulator, if some data
      inconsistency occurs. If some coupled regulators are not yet registered,
      don't fail to register, but try to resolve them in late init call.
      Signed-off-by: default avatarMaciej Purski <m.purski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d3d64537
    • Maciej Purski's avatar
      regulator: core: Parse coupled regulators properties · a085a31a
      Maciej Purski authored
      On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
      different devices on the board are supplied by different regulators
      with non-fixed voltages. If one of these devices temporarily requires
      higher voltage, there might occur a situation that the spread between
      devices' voltages is so high, that there is a risk of changing
      'high' and 'low' states on the interconnection between devices powered
      by those regulators.
      
      Add new structure "coupling_desc" to regulator_dev, which contains
      pointers to all coupled regulators including the owner of the structure,
      number of coupled regulators and counter of currently resolved
      regulators.
      
      Add of_functions to parse all data needed in regulator coupling.
      Provide method to check DTS data consistency. Check if each coupled
      regulator's max_spread is equal and if their lists of regulators match.
      Signed-off-by: default avatarMaciej Purski <m.purski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      a085a31a
    • Maciej Purski's avatar
      regulator: bindings: Add properties for coupled regulators · f98618b3
      Maciej Purski authored
      Some regulators require keeping their voltage spread below defined
      max_spread.
      
      Add properties to provide information on regulators' coupling.
      Signed-off-by: default avatarMaciej Purski <m.purski@samsung.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      f98618b3
    • Maciej Purski's avatar
      regulator: core: Make locks re-entrant · 66cf9a7e
      Maciej Purski authored
      Setting voltage, enabling/disabling regulators requires operations on
      all regulators related with the regulator being changed. Therefore,
      all of them should be locked for the whole operation. With the current
      locking implementation, adding additional dependency (regulators
      coupling) causes deadlocks in some cases.
      
      Introduce a possibility to attempt to lock a mutex multiple times
      by the same task without waiting on a mutex. This should handle all
      reasonable coupling-supplying combinations, especially when two coupled
      regulators share common supplies. The only situation that should be
      forbidden is simultaneous coupling and supplying between a pair of
      regulators.
      
      The idea is based on clk core.
      Signed-off-by: default avatarMaciej Purski <m.purski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      66cf9a7e
    • Linus Walleij's avatar
      regulator: s2mps11: Pass descriptor instead of GPIO number · 0369e02b
      Linus Walleij authored
      Instead of passing a global GPIO number for the enable GPIO, pass
      a descriptor looked up with the standard devm_gpiod_get_optional()
      call.
      
      This regulator supports passing platform data, but enable/sleep
      regulators are looked up from the device tree exclusively, so
      we can need not touch other files.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Tested-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      0369e02b
    • Linus Walleij's avatar
      regulator: max77686: Pass descriptor instead of GPIO number · c89c00e2
      Linus Walleij authored
      Instead of passing a global GPIO number, pass a descriptor looked
      up from the device tree configuration node.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Tested-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c89c00e2
    • Linus Walleij's avatar
      regulator: arizona-ldo1: Look up a descriptor and pass to the core · e1739e86
      Linus Walleij authored
      Instead of passing a global GPIO number, pass a descriptor looked
      up with the standard devm_gpiod_get_optional() call.
      
      We have augmented the GPIO core to look up the regulator special
      GPIO "wlf,ldoena" in commit 6a537d48
      "gpio: of: Support regulator nonstandard GPIO properties".
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      e1739e86
    • David Collins's avatar
      regulator: of: add support for allowed modes configuration · 54557ad9
      David Collins authored
      Add support for configuring the machine constraints
      valid_modes_mask element based on a list of allowed modes
      specified via a device tree property.
      Signed-off-by: default avatarDavid Collins <collinsd@codeaurora.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      54557ad9
    • David Collins's avatar
      regulator: of: add property for allowed modes specification · d73e2842
      David Collins authored
      Add a common device tree property for regulator nodes to support
      the specification of allowed operating modes.
      Signed-off-by: default avatarDavid Collins <collinsd@codeaurora.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d73e2842
    • Douglas Anderson's avatar
      regulator: core: Allow for regulators that can't be read at bootup · 84b3a7c9
      Douglas Anderson authored
      Regulators attached via RPMh on Qualcomm sdm845 apparently are
      write-only.  Specifically you can send a request for a certain voltage
      but you can't read back to see what voltage you've requested.  What
      this means is that at bootup we have absolutely no idea what voltage
      we could be at.
      
      As discussed in the patches to try to support the RPMh regulators [1],
      the fact that regulators are write-only means that its driver's
      get_voltage_sel() should return an error code if it's called before
      any calls to set_voltage_sel().  This causes problems in
      machine_constraints_voltage() when trying to apply the constraints.
      
      A proposed fix was to come up with an error code that could be
      returned by get_voltage_sel() which would cause the regulator
      framework to simply try setting the voltage with the current
      constraints.
      
      In this patch I propose the error code -ENOTRECOVERABLE.  In errno.h
      this error is described as "State not recoverable".  Though the error
      code was originally intended "for robust mutexes", the description of
      the error code seems to apply here because we can't read the state of
      the regulator.  Also note that the only existing user of this error
      code in the regulator framework is tps65090-regulator.c which returns
      this error code from the enable() call (not get_voltage() or
      get_voltage_sel()), so there should be no existing regulators that
      might accidentally get the new behavior.  (Side note is that tps65090
      seems to interpret this error code to mean an error that you can't
      recover from rather than some data that can't be recovered).
      
      [1] https://patchwork.kernel.org/patch/10340897/Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      84b3a7c9
  6. 09 May, 2018 2 commits
  7. 05 May, 2018 2 commits
    • Changbin Du's avatar
      regulator: add dummy function of_find_regulator_by_node · 08813e0e
      Changbin Du authored
      If device tree is not enabled, of_find_regulator_by_node() should have
      a dummy function since the function call is still there.
      
      This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced.
      If this option is enabled, GCC will not auto-inline functions that are
      not explicitly marked as inline.
      
      In this case (no CONFIG_OF), the copmiler will report error in function
      regulator_dev_lookup().
      
      W/O NO_AUTO_INLINE, function of_get_regulator() is auto-inlined and then
      the call to of_find_regulator_by_node() is optimized out since
      of_get_regulator() always return NULL.
      
      W/ NO_AUTO_INLINE, the return value of of_get_regulator() is a variable
      so the call to of_find_regulator_by_node() cannot be optimized out. So
      we need a stub of_find_regulator_by_node().
      
      static struct regulator_dev *regulator_dev_lookup(struct device *dev,
      						  const char *supply)
      {
      	struct regulator_dev *r = NULL;
      	struct device_node *node;
      	struct regulator_map *map;
      	const char *devname = NULL;
      
      	regulator_supply_alias(&dev, &supply);
      
      	/* first do a dt based lookup */
      	if (dev && dev->of_node) {
      		node = of_get_regulator(dev, supply);
      		if (node) {
      			r = of_find_regulator_by_node(node);
      			if (r)
      				return r;
      	...
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      08813e0e
    • Fabio Estevam's avatar
      regulator: pfuze100: Make the node name generic · 60891ceb
      Fabio Estevam authored
      According to Devicetree Specification v0.2 document:
      
      "The name of a node should be somewhat generic, reflecting the function
      of the device and not its precise programming model."
      
      Do as suggested in the binding example.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      60891ceb
  8. 01 May, 2018 1 commit
  9. 23 Apr, 2018 2 commits
    • Geert Uytterhoeven's avatar
      regulator: bd9571mwv: Add support for backup mode · 6eb0bfae
      Geert Uytterhoeven authored
      The BD9571MWV PMIC supports backup mode, which keeps one or more DDR
      rails powered while the main SoC is powered down.
      
      Which DDR rails are to be kept powered is board-specific, and controlled
      using the optional "rohm,ddr-backup-power" DT property.  In the absence
      of this property, backup mode is not available.
      
      Backup mode can be enabled or disabled by the user using the standard
      "wakeup" virtual file in sysfs, e.g. to enable:
      
          echo enabled > /sys/devices/platform/soc/e60b0000.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup
      
      When the PMIC is configured for backup mode, the role of the accessory
      power switch changes from a power switch to a wake-up switch.
      Two types of switches (or signals) can be used:
        A. With a momentary power switch (or pulse signal), the PMIC is
           configured for backup mode in the PMIC driver's suspend callback,
           during system suspend.
           Backup mode is enabled by default, as there is no further impact
           during normal system operation.
      
        B. With a toggle power switch (or level signal), the following steps
           must be followed exactly:
             1. Configure PMIC for backup mode,
             2. Switch accessory power switch off, to prepare for system
                suspend, which is a manual step not controlled by software,
             3. Suspend system.
           This mode is not yet supported by the driver.
      
      As the switch type is board-specific, and cannot be determined
      automatically, it is obtained from the presence of one of the
      "rohm,rstbmode-*" properties in DT.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      6eb0bfae
    • Geert Uytterhoeven's avatar
      mfd: bd9571mwv: Allow DDR Backup Power register access · 7b569bcb
      Geert Uytterhoeven authored
      Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which
      is amongst others used to configure DDR Backup Power.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      7b569bcb