| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit e03826d5045e81a66a4fad7be9a8ecdaeb7911cf ]
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 <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 29d62ec5f87fbeec8413e2215ddad12e7f972e4c ]
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 <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 0548bf4f5ad6fc3bd93c4940fa48078b34609682 ]
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 <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 28249b0c2fa361cdac450a6f40242ed45408a24f ]
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 <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit 83b0302d347a49f951e904184afe57ac3723476e upstream.
The regulator framework maintains a list of consumer regulators
for a regulator device and protects it from concurrent access using
the regulator device's mutex lock.
In the case of regulator_put() the consumer is removed and regulator
device's parameters are updated without holding the regulator device's
mutex. This would lead to a race condition between the regulator_put()
and any function which traverses the consumer list or modifies regulator
device's parameters.
Fix this race condition by holding the regulator device's mutex in case
of regulator_put.
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1222d8fe578cd28a6c7f5e4e6c6b664c56abfdc0 upstream.
Invalid buck4 configuration for linear mapping of voltage in S2MPS14
regulators caused boot failure on Gear 2 (dw_mmc-exynos):
[ 3.569137] EXT4-fs (mmcblk0p15): mounted filesystem with ordered data mode. Opts: (null)
[ 3.571716] VFS: Mounted root (ext4 filesystem) readonly on device 179:15.
[ 3.629842] mmcblk0: error -110 sending status command, retrying
[ 3.630244] mmcblk0: error -110 sending status command, retrying
[ 3.636292] mmcblk0: error -110 sending status command, aborting
Buck4 voltage regulator has different minimal voltage value than other
bucks. Commit merging multiple regulator description macros caused to
use linear_min_sel from buck[1235] regulators as value for buck4. This
lead to lower voltage of buck4 than required.
Output of the buck4 is used internally as power source for
LDO{3,4,7,11,19,20,21,23}. On Gear 2 board LDO11 is used as MMC
regulator (V_EMMC_1.8V).
Fixes: 5a867cf28893 ("regulator: s2mps11: Optimize the regulator description macro")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fe08be3ec8672ed92b3ed1b85810df9fa0f98931 upstream.
The code reads the default voltage selector from its register. If the
bootloader disables the regulator, the default voltage selector will be
0 which results in faulty behaviour of this regulator driver.
This patch sets a default voltage selector for vddpu if it is not set in
the register.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
'regulator/fix/max77686', 'regulator/fix/max77693', 'regulator/fix/max77802', 'regulator/fix/max8860' and 'regulator/fix/s2mpa01' into regulator-linus
|
|
|
|
The struct of_regulator_match rmatch[] is declared as a non-static local
variable so the structure members are not auto-initialized.
Initialize the array at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The struct of_regulator_match rmatch[] is declared as a non-static local
variable so the structure members are not auto-initialized.
Initialize the array at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The struct of_regulator_match is declared as a non-static local variable
so the structure members are not auto-initialized.
Initialize the struct at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The struct of_regulator_match is declared as a non-static local variable
so the structure members are not auto-initialized.
Initialize the struct at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The struct of_regulator_match rmatch[] is declared as a non-static local
variable so the structure members are not auto-initialized.
Initialize the array at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Driver allocated on stack struct regulator_config but didn't initialize
it fully. Few fields (driver_data, ena_gpio) were left untouched. This
lead to using random ena_gpio values as GPIOs for max77693 regulators.
On occasion these values could match real GPIO numbers leading to
interfering with other drivers and to unsuccessful enable/disable of
regulator.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Description of regulators should generally be optional so if there is no
DT node for the regulators container then we shouldn't print an error
message. Lower the severity of the message to debug level (it might help
someone work out what went wrong) and while we're at it say what we were
looking for.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
|
|
Pull power supply and reset updates from Sebastian Reichel:
- Initial support for the following chips
* max77836 (charger)
* max14577 (charger)
* bq27742 (battery gauge)
* ltc2952 (poweroff)
* stih416 (restart)
* syscon-reboot (restart)
* gpio-restart (restart)
- cleanup of power supply core
- misc fixes in power supply and reset drivers
* tag 'for-v3.18' of git://git.infradead.org/battery-2.6: (48 commits)
power: ab8500_fg: Fix build warning
Documentation: charger: max14577: Update the date of introducing ABI
power: reset: corrections for simple syscon reboot driver
Documentation: power: reset: Add documentation for generic SYSCON reboot driver
power: reset: Add generic SYSCON register mapped reset
bq27x00_battery: Fix flag reading for bq27742
power: reset: use restart_notifier mechanism for msm-poweroff
power: Add simple gpio-restart driver
power: reset: st: Provide DT bindings for ST's Power Reset driver
power: reset: Add restart functionality for STiH41x platforms
power: charger-manager: Fix NULL pointer exception with missing cm-fuel-gauge
power: max14577: Fix circular config SYSFS dependency
power: gpio-charger: do not use gpio value directly
power: max8925: Use of_get_child_by_name
power: max8925: Fix NULL ptr dereference on memory allocation failure
bq27x00_battery: Add support to bq27742
Documentation: charger: max14577: Document exported sysfs entry
devicetree: mfd: max14577: Add device tree bindings document
power: max17040: Add ID for MAX77836 Fuel Gauge block
charger: max14577: Configure battery-dependent settings from DTS and sysfs
...
Conflicts:
drivers/power/reset/Kconfig
drivers/power/reset/Makefile
|
|
The min_uv in DCDC1 & DCDC2 should be 712.5mv
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviwed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
'regulator/topic/tps65910' and 'regulator/topic/voltage-ev' into regulator-next
|
|
'regulator/topic/rn5t618' and 'regulator/topic/samsung' into regulator-next
|
|
'regulator/topic/max77802' and 'regulator/topic/of' into regulator-next
|
|
'regulator/topic/enable', 'regulator/topic/fan53555', 'regulator/topic/hi6421' and 'regulator/topic/isl9305' into regulator-next
|
|
'regulator/topic/axp20x', 'regulator/topic/bcm590xx' and 'regulator/topic/da9211' into regulator-next
|
|
'regulator/fix/ltc3589' and 'regulator/fix/tps65023' into regulator-linus
|
|
This is a patch for fixing a bug about mask bit operation.
Signed-off-by: James Ban <james.ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Conflicts:
drivers/regulator/Kconfig
drivers/regulator/Makefile
|
|
Conflicts:
drivers/regulator/Kconfig
|
|
rename st-pwm to pwm-regulator. And support getting voltage & duty table from
device tree, other platforms can also use this driver without any modify.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Current code does not take the macro parameter, fix it.
This is not a problem at this moment because the only user actually passes
vreg to FORCE_MODE_IS_2_BITS().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Doing so generates a warning as the first field is a pointer but we use
0 to initialize it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
VCCR is used as a trigger to start voltage transitions, so
we need to mark it volatile in order to make sure it gets
written to hardware every time we set a new voltage.
Fixes regulator voltage being stuck at the first voltage
set after driver load.
[lst: reworded commit message]
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
This patch prepares for changing the max14577 charger driver to allow
configuring battery-dependent settings from DTS.
The patch moves from regulator driver to MFD core driver and exports:
- function for calculating register value for charger's current;
- table of limits for chargers (MAX14577, MAX77836).
Previously they were used only by the max14577 regulator driver. In next
patch the charger driver will use them as well. Exporting them will
reduce unnecessary code duplication.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Driver for regulators exposed by the Resource Power Manager (RPM) found
in Qualcomm 8660, 8960 and 8064 based devices.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The current device used for the regulator configuration is the child device
created by the MFD driver. This means that it doesn't have any of_node pointing
to it, and whenever we register the regulators, it will not look into the
regulator supply in the DT, hence requiring to provide regulator aliases in the
MFD driver.
We can easily fix that by using the parent device in our configuration, which
has a DT node associated to it, and will allow a DT lookup. Eventually, we will
be able to remove the aliases in the MFD driver.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Set di->regulator before dereference it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The vendor-id gathered from the dt match-data was cast to int but assigned
to an unsigned long, producing warnings on at least sparc, like
drivers/regulator/fan53555.c: In function 'fan53555_regulator_probe':
>> drivers/regulator/fan53555.c:373:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
di->vendor = (int) match->data;
Fix this by using an appropriate cast.
Reported-by: kbuild test robot
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Silergy SYR82x regulators share the exact same functionality and register layout
as the Fairchild FAN53555 regulators. Therefore extend the driver to add
support for them.
Both types use the same vendor id in their ID1 register, so it's not possible
to distinguish them automatically.
Similarly, the types also do not match. Type 8 used by the SYR827 and SYR828
start at 712.5mV and increment in 12.5mv steps, while the FAN53555 type 8
starts at 600mV and increments in 10mV steps.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add the ability to parse regulator-data from the devicetree.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On rk808 buck1 and buck2 have programmable ramp delays. Let's add a
function to allow a client of rk808 to set them.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The regulator constraints already provide a field for the ramp_delay, so
there is no need to set this manually. Therefore implement the set_ramp_delay
callback and convert the pdata value to the constraint value if necessary.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The regulator can be supplied by a parent regulator through its vin pin,
so add the supply_name for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
1. Pass &pdev->dev rather than &client->dev to of_regulator_match, the *dev
argument is used for devres to ensure devm_of_regulator_put_matches() will
be called when unload the module.
2. of_get_child_by_name() returns a node pointer with refcount incremented.
Thus add missing of_node_put(reg_np).
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Also remove non-informative comment.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix ERROR: "devm_regmap_init_i2c" [drivers/regulator/isl9305.ko] undefined!
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This removes some code and replaces it with data.
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-isl9305
|
|
Remove a bunch of code in favour of data.
Signed-off-by: Mark Brown <broonie@linaro.org>
|
