linux/drivers/regulator, branch v4.0

Merge remote-tracking branches 'regulator/fix/doc' and 'regulator/fix/palmas' into regulator-linus

2015-03-23T18:43:42Z

regulator: palmas: Correct TPS659038 register definition for REGEN2

2015-03-17T12:19:14Z

The register offset for REGEN2_CTRL in different for TPS659038 chip as when compared with other Palmas family PMICs. In the case of TPS659038 the wrong offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same. Signed-off-by: Keerthy Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

Merge remote-tracking branches 'regulator/fix/gpio-enable' and 'regulator/fix/tps65910' into regulator-linus

2015-03-16T11:43:24Z

regulator: tps65910: Add missing #include

2015-03-16T11:41:16Z

drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’: drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’ drivers/regulator/tps65910-regulator.c:1018: warning: assignment makes pointer from integer without a cast drivers/regulator/tps65910-regulator.c:1034: error: implicit declaration of function ‘of_node_put’ drivers/regulator/tps65910-regulator.c:1056: error: implicit declaration of function ‘of_property_read_u32’ Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown

regulator: core: Fix enable GPIO reference counting

2015-03-08T19:43:52Z

Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list") Signed-off-by: Doug Anderson Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

regulator: Only enable disabled regulators on resume

2015-03-08T19:40:16Z

The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by: Javier Martinez Canillas Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

Merge remote-tracking branches 'regulator/fix/da9210' and 'regulator/fix/rk808' into regulator-linus

2015-03-06T21:10:30Z

regulator: Fix regression due to NULL constraints check

2015-03-04T12:31:01Z

The commit [39f802d6b6d9: 'regulator: Build sysfs entries with static attribute groups'] converted the sysfs entry creation to static attribute groups, but this resulted in a regression due to the NULL check of rdev->constraints. At the point where the device is registered, rdev->constraints isn't set, so the attributes depending on it are missing. We may fix it by shuffling the code order in regulator_register(), but a quicker fix is to just remove this NULL check. rdev->constraints is in anyway always set to non-NULL in set_machine_constraints(), thus the check there is basically superfluous. Fixes: 39f802d6b6d9 ('regulator: Build sysfs entries with static attribute groups') Signed-off-by: Takashi Iwai Reportded-by: Steve Twiss Tested-by: Steve Twiss Signed-off-by: Mark Brown

regulator: rk808: Set the enable time for LDOs

2015-02-21T14:32:43Z

The LDOs are documented in the rk808 datasheet to have a soft start time of 400us. Add that to the driver. If this time takes longer on a certain board the device tree should be able to override with "regulator-enable-ramp-delay". This fixes some dw_mmc probing problems (together with other patches posted to the mmc maiing lists) on rk3288. Signed-off-by: Doug Anderson Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

Merge tag 'mfd-for-linus-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd

2015-02-18T17:05:48Z

Pull MFD updates from Lee Jones: "Changes to existing drivers: - fixr platform device collision; da9052, wm8994-core - regmap configuration amendments; tps65218 - fix runtime PM deadlock; rtsx_usb - remove unused/superfluous code; db8500-prcmu, omap-usb-host - enable watchdog timer; lpc_sch - add start/stop RX URBs helpers; dln2 - remove platform device (DT only); max77686, max77802 - support suspend and resume; dln2 - add Device Tree support; da9063 - extra error checking; intel_soc_pmic - const'ify all the things; 88pm860x, hi6421-pmic, intel_soc_pmic, max77686, lm3533, retu, pcf50633, davinci_voicecodec, smsc-ece1099, tps65218, mc13xxx, tps65217, twl-core, twl6040 New drivers/supported devices: - new driver for Richtek RT5033 - new driver for DA9150 Charger and FuelGauge - new driver for Qualcomm Resource Power Manager (RPM) - add support for the ir-clk into sun6i-prcm - add support for FuelGauge into axp20x" * tag 'mfd-for-linus-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (32 commits) mfd: intel_soc_pmic: Add missing error check for devm_kzalloc mfd: rtsx_usb: Defer autosuspend while card exists mfd: devicetree: Add bindings for DA9063 mfd: da9063: Add device tree support regulator: qcom-rpm: Add missing state flag in call to RPM mfd: qcom-rpm: Driver for the Qualcomm RPM mfd: devicetree: bindings: Add Qualcomm RPM DT binding mfd: max77686/802: Remove support for board files mfd: omap-usb-host: Remove some unused functions mfd: twl6040: Constify struct regmap_config and reg_default array mfd: twl-core: Constify struct regmap_config and reg_default array mfd: tps65217: Constify struct regmap_config mfd: mc13xxx: i2c/spi: Constify struct regmap_config mfd: tps65218: Constify struct regmap_config mfd: smsc-ece1099: Constify struct regmap_config mfd: davinci_voicecodec: Constify struct regmap_config mfd: pcf50633: Constify struct regmap_config mfd: retu: Constify struct regmap_config mfd: lm3533: Constify struct regmap_config mfd: max77686: Constify struct regmap_config ...