This fix alters the minimum and maximum BUCK voltage limits for DA9052 and
DA9053. It does so for the following cases:
DA9052
- BUCK3 (MEM)
min: 0.925V -> 0.950V
max: 2.500V -> 2.525V
DA9053
- BUCK3 (MEM)
min: 0.925V -> 0.950V
max: 2.500V -> 2.525V
- BUCK4 (PERI)
min: 0.925V -> 0.950V
max: 2.500V -> 2.525V
The voltage range remains the same, but the limits are shifted by +0.025V.
This change is provided on DA9052:MEM, DA9053:MEM and DA9053:PERI
and is a voltage difference of 0.025V, compared to those measured before
this fix is applied. The patch has the effect of decreasing *all* measured
voltages on those BUCKs when compared against the previously measured
values for the same software voltage request.
For example, with this fix applied for DA9052:MEM, DA9053:MEM and
DA9053:PERI, the following is true.
Because the previous software defined slot 0 as being 0.925V, if a request
for 0.950V was previously sent, the slot 1 voltage would have been used.
This would have corresponded to an actual measured voltage of 0.975V. But,
with this patch fix, and with slot 0 properly aligned to 0.950V, if a
voltage of 0.950V is requested by software, a measured value of 0.950V will
be provided.
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Signed-off-by: Chen Zhong <chen.zhong@mediatek.com>
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Addition of device tree support for DA9210.
Two files are modified, the driver source file and the binding document.
Updates for the regulator source file include an .of_match_table entry and
node match checking in the probe() function for a compatible da9210 string.
Minor binding documentation changes have been made to the title and the
example.
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This node pointer is returned by of_get_child_by_name() with
refcount incremented in this function. of_node_put() is missing
when exitting this function while invalid device type. Fix it
by move of_get_child_by_name() code after device type check.
Found by Coccinelle.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is only one instance of ab8500_regulator_platform_data, and it's
safe to assume we won't ever merge another one, so it's rather pointless
to pass it through multiple levels of platform data pointers.
This moves the structure and everything referenced by it into the
driver that uses it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pm8x41_hfsmps ranges overlap. The first range is from 375000
to 1562500:
375000 + (95 * 12500) == 1562500
and the second range starts at 1550000. Interestingly, the second
range ends at the correct value when it's set to be the
appropriate start value, 1575000:
1575000 + ((158 - 96) * 25000) == 3125000
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes some of the LDOs and BUCKs voltage range as per
user manual of s2mps15 (REV0.4).
Fixes: 51af206758 ("regulator: s2mps11: Add support for S2MPS15 regulators")
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.
Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current
voltage value.
If possible, retrieve the current voltage selector from the PWM state,
else return -EINVAL.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Use the atomic API wherever appropriate and get rid of pwm_apply_args()
call (the reference period and polarity are now explicitly set when
calling pwm_apply_state()).
We also make use of the pwm_set_relative_duty_cycle() helper to ease
relative to absolute duty_cycle conversion.
Note that changes introduced by commit fd786fb027 ("regulator: pwm:
Try to avoid voltage error in duty cycle calculation") are no longer
needed because pwm_set_relative_duty_cycle() takes care of all rounding
approximation for us.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM attached to a PWM regulator device might have been previously
configured by the bootloader.
Make sure the bootloader and linux config are in sync, and adjust the PWM
config if that's not the case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly. It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS. Let's
adjust it. Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).
Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS. 1000 is way too much. We'll try to be dynamic
and use 10%.
NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
That could be done in a future patch when someone has a user of that
featre.
Though this patch is shows as "fixing" a bug, there are no actual known
users of continuous mode PWM regulator w/ ramp delay in mainline and so
this likely won't have any effect on anyone unless they are working
out-of-tree with private patches. For anyone in this state, it is
highly encouraged to also pick Boris Brezillon's WIP patches to get
yourself a reliable and glitch-free regulator.
Fixes: 4773be185a ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SD4 regulator is not registered with regulator core
framework in probe as there is no support in MAX77620 PMIC,
removing SD4 entry from MAX77620 regulator information list
and checking for valid regulator information data before
configuring FPS source and FPS power up/down period to avoid
NULL pointer exception if regulator not registered with core.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch for adding description for da9212/da9214.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend the driver to support Ricoh RN5T567. Support the additional
DCDC and slightly different voltage range of LDORTC1.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
TPS65218 has a pre-defined power-up / power-down sequence which in
a typical application does not need to be changed. However, it is possible
to define custom sequences under I2C control. The power-up sequence is
defined by strobes and delay times. Each output rail is assigned to a
strobe to determine the order in which the rails are enabled.
Every regulator has sequence registers and every regulator has a default
strobe value and gets disabled when a particular power down sequence
occurs.
To keep a regulator on during suspend we write value 0 to strobe so
that the regulator is out of all sequencers and is not impacted by any
power down sequence. Hence saving the default strobe value during probe
so that when we want to regulator to be enabled during suspend we write 0
to strobe and when we want it to get disabled during suspend we write
the default saved strobe value.
This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The TPS65217 has a pre-defined power-up / power-down sequence which in
a typical application does not need to be changed. However, it is possible
to define custom sequences under I2C control. The power-up sequence is
defined by strobes and delay times. Each output rail is assigned to a
strobe to determine the order in which the rails are enabled.
Every regulator of tps65217 PMIC has sequence registers and every
regulator has a default strobe value and gets disabled when a particular
power down sequence occurs.
To keep a regulator on during suspend we write value 0 to strobe so
that the regulator is out of all sequencers and is not impacted by any
power down sequence. Hence saving the default strobe value during probe
so that when we want to regulator to be enabled during suspend we write 0
to strobe and when we want it to get disabled during suspend we write
the default saved strobe value.
This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
[Enhanced commit log and added dynamic allocation for strobes]
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The voltage switches support mode switching, so add support for
these ops to those types of regulators.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: e92a404741 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mvs1 and mvs2 switches are actually called 5vs1 and 5vs2 on
some datasheets. Let's rename them to match the datasheets and
also match the RPM based regulator driver which calls these by
their 5vs names (see qcom_smd-regulator.c). There aren't any
users of these regulators so far, so there aren't any concerns of
DT ABI breakage here. While we're here making updates to the
switches, also mandate usage of the OCP irq for these switches
too.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: e92a404741 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The S4 supply is sometimes called the boost regulator because it
outputs 5V. Typically it's connected to the 5vs1 and 5vs2
switches for use in USB OTG and HDMI applications. Add support
for this regulator which was mistakenly left out from the initial
submission of this driver.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: e92a404741 ("regulator: Add QCOM SPMI regulator driver")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add an optional enable GPIO to the pwm-regulator driver.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
No need to pass _nlr to LP873X_REGULATOR(), use ARRAY_SIZE to calculate it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bypass support was added in commit d38018f201 ("regulator: anatop: Add
bypass support to digital LDOs"). A check for valid voltage selectors was
added in commit da0607c8df ("regulator: anatop: Fail on invalid voltage
selector") but it also discards all regulators that are in bypass mode. Add
check for the bypass setting. Errors below were seen on a Variscite mx6
board.
anatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector.
anatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22
anatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector.
anatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22
Fixes: da0607c8df ("regulator: anatop: Fail on invalid voltage selector")
Signed-off-by: Mika Båtsman <mbatsman@mvista.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use regulator_list_voltage_linear_range in rpm_smps_ldo_ops_fixed is
wrong because it is used for fixed regulator without any linear range.
The rpm_smps_ldo_ops_fixed is used for pm8941_lnldo which has fixed_uV
set and n_voltages = 1. In this case, regulator_list_voltage() can return
rdev->desc->fixed_uV without .list_voltage implementation.
Fixes: 3bfbb4d1a4 ("regulator: qcom_smd: add list_voltage callback")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support to list_voltage callback, so that consumers
like mmc core, can get information of supported voltage range.
Without this patch there is no way for mmc core to know this voltage range.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is little obvious use case for a regualtor driver to know if it is
possible to vary voltages at all by itself. If a consumer needs to
limit what voltages it tries to set based on the system configuration
then it will need to enumerate the possible voltages, and without that
even if it is possible to change voltages that doesn't mean that
constraints or other consumers will allow whatever change the driver is
trying to do at a given time. It doesn't even indicate if _set_voltage()
calls will work as noop _set_voltage() calls return success.
There were no users of this API that weren't abusing it and now they're
all gone so remove the API.
Signed-off-by: Mark Brown <broonie@kernel.org>
The TWL6030_FIXED_LDO() macro passes the TWL_FIXED_LDO()
macro an 0x0 instead of a NULL. Changing this to a NULL
fixes the following warnings:
drivers/regulator/twl-regulator.c:1068:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1069:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1070:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1071:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1072:1: warning: Using plain integer as NULL pointer
drivers/regulator/twl-regulator.c:1073:1: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
After "regulator: qcom_smd: add list_voltage callback" patch adding
pm8941 lnldo regulators would bug on list_voltages as it is a fixed
regulator without any linear range.
This patch fixes that issue by adding dedicated ops for pm8941 lnldo
without list_voltages callback.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org # v4.6
This patch adds support to list_voltage callback, so that consumers
like mmc core, can get information of supported voltage range.
Without this patch there is no way for mmc core to know this voltage range.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org # v4.6
Adjust the MODULE_DESCRIPTION() text to also include the PFUZE3000
as a supported device.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The CONFIG_REGULATOR_PFUZE100 option also supports PFUZE3000, so
mention that in the Kconfig text.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should better not use a global 'struct pfuze_regulator' variable,
as this could cause problems if multiple regulator chips are used.
Place it inside the private struct instead.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The axp20x pmics have 2 power inputs, one called ACIN which is intended
for to be supplied via a powerbarrel on the board and one called VBUS
which is intended to be supplied via an otg connector.
In the VBUS case the pmic needs to know if the board is supplying power
to the otg connector, because then it should not take any power from
its VBUS pin. The axp209 pmic has a N_VBUSEN input pin via which the
board can signal to the pmic whether the board is supplying power to the
otg connector or not.
On the axp221/axp223 this pin can alternatively be used as an output
which controls an external regulator which (optionally) supplies
power to the otg connector from the board. When the pin is used as
output it is called DRIVEVBUS in the datasheet.
This commit adds support for the DRIVEVBUS pin as an extra pmic
controlled regulator. Since this is optional a new x-powers,drivebus dt
property is added. When this is present the misc-control register is
written to change the N_VBUSEN input pin to DRIVEVBUS output pin mode and
the extra drivebus regulator is registered with the regulator subsystem.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the PWM regulator driver implements the ->enable/disable() hooks
we can remove the pwm_enable() call from pwm_regulator_set_voltage().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to retrieve fixed voltage configure information through
ACPI interface. This is needed for Intel Bay Trail devices, where a
GPIO is used to control the USB vbus.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
though a few LDOs were removed, and a new switch output added. Like the
AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
to DCDC1 and DCDC5, respectively.
Add support for this new variant. Also remove the "axp22x_" prefix from
DC1SW/DC5LDO supply handling code, as the AXP809 uses it as well.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the datasheet:
SLEW Register(Address = 07h)
b7 b6 b5 b4 b3 b2 b1 b0
48mV/us 42mV/us 36mV/us 30mV/us 24mV/us 18mV/us 12mV/us 6mV/us
Current code does not set correct slew rate in some cases:
e.g. Assume ramp_delay is 10000, current code sets slew register to 6mV/us.
Fix the logic to set slew register.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code can set ramp delay to a wrong setting that the return value
from .set_voltage_time_sel is not enough for proper delay.
Fix the logic in .set_ramp_delay and also remove unused ret_val variable.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
BUCKs of mt6397 have auto mode and pwm mode.
User can use regulator interfaces to control modes
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The GPIO interface of_get_named_gpio() has implemented the proper
error returns even EPROBE_DEFER and hence caller need not to
implement any workaround for translating the returned error.
Remove the workaround implemented to handle the return of
of_get_named_gpio().
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A common simplified DT parsing code for regulators was introduced in
commit a0c7b164ad ("regulator: of: Provide simplified DT parsing
method")
While at it also added RK8XX_DESC and RK8XX_DESC_SWITCH macros for the
regulator_desc struct initialization. This just makes the driver more compact.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulators set consists of 2 BUCKs and 2 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components. The ramp delay is configurable
for both BUCKs.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Just dereference match->of_node once instead of using match->of_node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Stop the palmas regulator driver from imagining that the allocations
will always succeed. Since regulator dt nodes are optional in nature and
can be described in downstream drivers via platform data, continue to
maintain code flow as prior when of node is not found.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Converting dt to platform data logic involves picking up information
that is unique per regulator, however we can improve readability of
the code by allocating and referencing pdata->reg_init[idx] once in
the loop.
While at it, use sizeof(*pointer) when allocating pointer. This allows
for structure name changes with minimal code change.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Converting dt to platform data logic involves picking up information
that is unique per regulator, however we can improve readability of
the code by dereferencing ddata->palmas_matches[idx] once in the loop.
While at it fix reuse of generic palmas_matches common variable
while reporting error for a specific regulator (which may be from
65917/palmas list).
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The PWM framework has clarified the concept of reference PWM config (the
platform dependent config retrieved from the DT or the PWM lookup table)
and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has just
been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The enable time for buck regulators was not configured but actually is
essential: consumers, like usb3503, doing hard reset (regulator off/on)
should wait for the regulator to settle.
Configure the enable time according to datasheet.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The maximum supported voltage for ldo_io# is 3.3V, but on cold
boot the selector comes up at 0x1f, which maps to 3.8V.
This causes _regulator_get_voltage() to fail with -EINVAL which
causes regulator registration to fail when constrains are used:
[ 1.467788] vcc-touchscreen: failed to get the current voltage(-22)
[ 1.474209] axp20x-regulator axp20x-regulator: Failed to register ldo_io1
[ 1.483363] axp20x-regulator: probe of axp20x-regulator failed with error -22
This commits makes the axp20x regulator driver accept the 0x1f register
value, fixing this.
The datasheet does not guarantee reliable operation above 3.3V, so on
boards where this regulator is used the regulator-max-microvolt setting
must be 3.3V or less.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
LDO_REG3 descriptor is using linear_ranges.
Add and use proper ops for LDO_REG3.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The call to set_machine_constraints() in regulator_register(), will
attempt to get the voltage for the regulator. If a regulator is in
bypass will fail to get the voltage (ie. it's bypass voltage) and
hence register the regulator, because the supply for the regulator has
not been resolved yet.
To fix this, add a call to regulator_resolve_supply() before we call
set_machine_constraints(). If the call to regulator_resolve_supply()
fails, rather than returning an error at this point, allow the
registration of the regulator to continue because for some regulators
resolving the supply at this point may not be necessary and it will be
resolved later as more regulators are added. Furthermore, if the supply
is still not resolved for a bypassed regulator, this will be detected
when we attempt to get the voltage for the regulator and an error will
be propagated at this point.
If a bypassed regulator does not have a supply when we attempt to get
the voltage, rather than returing -EINVAL, return -EPROBE_DEFER instead
to allow the registration of the regulator to be deferred and tried
again later.
Please note that regulator_resolve_supply() will call
regulator_dev_lookup() which may acquire the regulator_list_mutex. To
avoid any deadlocks we cannot hold the regulator_list_mutex when calling
regulator_resolve_supply(). Therefore, rather than holding the lock
around a large portion of the registration code, just hold the lock when
aquiring any GPIOs and setting up supplies because these sections may
add entries to the regulator_map_list and regulator_ena_gpio_list,
respectively.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The minium voltage of 1800mV is a copy and paste error from the axp20x
regulator info. The correct minimum voltage for the ldo_io regulators
on the axp22x is 700mV.
Fixes: 1b82b4e4f9 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When commit b554e14506 ("regulator: tps65917/palmas: Add bypass
ops for LDOs with bypass capability") introduced bypass capability
to palmas regulator, it went with the assumption that regulator
regmap helpers just check val against the bypass_mask.
Unfortunately, this ignored the explicit "on" and "off" values when
the register value is masked with bypass_mask in commit ca5d1b3524
("regulator: helpers: Modify helpers enabling multi-bit control").
With the recent commit dd1a571dae ("regulator: helpers: Ensure
bypass register field matches ON value"), this issue gets highlighted
and fails tps65917/palmas based platforms which need regulators/ldos
that have bypass capability.
Introduce the bypass_on value appropriately for tps65917/palmas
regulator.
Fixes: b554e14506 ("regulator: tps65917/palmas: Add bypass ops for LDOs with bypass capability")
Cc: Keerthy <j-keerthy@ti.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current linear voltage range for the LDO4 regulator found in the APX20X
PMICs assumes that the voltage is linear between 2.5 and 3.1V.
However, the PMIC can output up to 3.3V on that regulator by skipping the
2.6V and 2.9V steps.
Fix the ranges to read and set the proper voltages.
Fixes: 13d57e6435 ("regulator: axp20x: Use linear voltage ranges for AXP20X LDO4")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
After removing all uses of the range operations in a recent patch,
we get a warning about the symbol not being referenced anywhere:
drivers/regulator/rk808-regulator.c:306:29: 'rk808_reg_ops_ranges' defined but not used
This removes the now-unused structure along with the
rk808_set_suspend_voltage_range function that is only referenced from
rk808_reg_ops_ranges.
Fixes: afcd666d9d ("regulator: rk808: remove linear range definitions with a single range")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
To make the code more compat and centralized, this patch add a
unified function - regulator_ops_is_valid. So we can add
some extra checking code easily later.
Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver was using only linear ranges. Now we remove linear range
definitions with a single range. So we have to add an ops struct for
ranges and adjust all other ops functions accordingly.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Maxim advertised the ramp rate of the rail with some recommended
design specification like output capacitance of rail should be
2.2uF. This make sure that current change in the rail is within
maximum current limit and hence meet the advertised ramp rate.
If there is variation in design which causes the rail current to
change more that maximum current limit then device applies the
current limit. In this case, ramp rate is different than advertised
ramp rate.
Add device specific settings for ramp rate which need to be configure
on device register when measure ramp rate on platform is deviated from
advertised ramp rate. In this case, all delay time calculation for
voltage change is done with measured ramp rate and device ramp rate
is used for configuring the device register.
If measured ramp rate in the platform is same as advertised ramp rate
then regulator-ramp-delay is used for the device register configuration
and ramp time calculation for voltage change.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When checking bypass state for a regulator, we check to see if any bits
in the bypass mask are set. For most cases this is fine because there is
typically, only a single bit used to determine if the regulator is in
bypass. However, for some regulators, such as LDO6 on AS3722, the bypass
state is indicate by a value rather than a single bit. Therefore, when
checking the bypass state, check that the bypass field matches the ON
value.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The public functions to acquire a regulator, such as regulator_get(),
internally look-up the regulator from the list of regulators that have
been registered with the regulator device class. The registration of
a new regulator with the regulator device class happens before the
regulator has been completely setup. Therefore, it is possible that
the regulator could be acquired before it has been setup successfully.
To avoid this move the device registration of the regulator to the end
of the regulator setup and update the error exit path accordingly.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
During the resolution of a regulator's supply, we may attempt to enable
the supply if the regulator itself is already enabled. If enabling the
supply fails, then we will call _regulator_put() for the supply.
However, the pointer to the supply has not been cleared for the
regulator and this will cause a crash if we then unregister the
regulator and attempt to call regulator_put() a second time for the
supply. Fix this by clearing the supply pointer if enabling the supply
after fails when resolving the supply for a regulator.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The function regulator_register_resolve_supply() is called from the
context of class_for_each_dev() (during the regulator registration) to
resolve any supplies added. regulator_register_resolve_supply() will
return an error if a regulator's supply cannot be resolved and this will
terminate the loop in class_for_each_dev(). This means that we will not
attempt to resolve any other supplies after one has failed. Hence, this
may delay the resolution of other regulator supplies until the failing
one itself can be resolved.
Rather than terminating the loop early, don't return an error code and
keep attempting to resolve any other supplies for regulators that have
been registered.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There are debugfs entries for voltage and current, but not for
the constraint flags. It's useful for debugging to be able to
see what these flags are so this patch adds a new debugfs file.
We can't use debugfs_create_bool for this because the flags are
bitfields, so as this needs a special read callback they have been
collected into a single file that lists all the flags.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The tps6524x driver uses spi_dev_get() to take a copy of the SPI device
it uses but has no obvious reason to do so and never calls spi_dev_put()
to release the reference. Fix this to just a straight copy.
Signed-off-by: Mark Brown <broonie@kernel.org>
IC type options 00, 13 and 23 are sharing the same DIE_ID 0.
Let's differentiate between these revisions.
FAN53555UC13X has the ID 0 and REV 0xf, starts at 800mV and
increments in 10mV steps.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
FAN53555BUC18X has the DIE_ID 8, starts at 600mV and
increments in 10mV steps.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
suspend_prepare can be called during regulator init time also, where
the mutex is not locked yet. This causes a false lockdep warning.
To avoid the problem, remove the lockdep assertion from the function
causing the issue. An alternative would be to lock the mutex during
init, but this would cause other problems (some APIs used during init
will attempt to lock the mutex also, causing deadlock.)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is the driver for the Powerventure PV88080 BUCKs regulator.
It communicates via an I2C bus to the device.
Signed-off-by: James Ban <James.Ban..opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Driver did not provide default value for ramp delay for LDOs which lead
to warning in dmesg, e.g. on Odroid XU4:
[ 1.486076] vdd_ldo9: ramp_delay not set
[ 1.506875] vddq_mmc2: ramp_delay not set
[ 1.523766] vdd_ldo15: ramp_delay not set
[ 1.544702] vdd_sd: ramp_delay not set
The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO. It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).
However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.
Without the ramp delay value the consumers do not wait for voltage
settle after changing it. Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
I had a thinko in spmi_regulator_select_voltage_same_range() when
converting it to return selectors via the function's return value
instead of by modifying a pointer argument. I only tested
multi-range regulators so this passed through testing. Fix it by
returning the selector here.
Fixes: 1b5b196892 ("regulator: qcom_spmi: Only use selector based regulator ops")
Reported-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is harmless but my static checker complains that "tmp" is
uninitialized if lp3972_i2c_read() fails. I have moved the line of code
below the error handling to silence the warning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is harmless but if lp3971_i2c_read() fails then "tmp" can be
uninitialized. Silence the warning by moving the error handling up a
line.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver MAX8973 supports the driver for Maxim PMIC MAX77621.
MAX77621 supports the junction temp warning at 120 degC and
140 degC which is configurable. It generates alert signal when
junction temperature crosses these threshold.
MAX77621 does not support the continuous temp monitoring of
junction temperature. It just report whether junction temperature
crossed the threshold or not.
Add support to
- Configure junction temp warning threshold via DT property
to generate alert when it crosses the threshold.
- Add support to interrupt the host from this device when alert
occurred.
- read the junction temp via thermal framework.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When we acquire a shareable enable GPIO on probe we do so with the
regulator_list_mutex held. However when we release the GPIOs we do this
immediately after dropping the mutex meaning that the list could become
corrupted. Move the release into the locked region to avoid this.
Signed-off-by: Mark Brown <broonie@kernel.org>
device_register() is calling ->get_voltage() as part of it's sysfs attribute
initialization process, and this functions might need to know the regulator
constraints to return a valid value.
This is at least true for the pwm regulator driver (when operating in
continuous mode) which needs to know the minimum and maximum voltage values
to calculate the current voltage:
min_uV + (((max_uV - min_uV) * dutycycle) / 100);
Move device_register() after set_machine_constraints() to make sure those
constraints are correctly initialized when ->get_voltage() is called.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When a regulator is in bypass mode it is functioning as a switch
returning the voltage set in the regulator will not give the voltage
being output by the regulator as it's just passing through its supply.
This means that when we are getting the voltage from a regulator we
should check to see if it is in bypass mode and if it is we should
report the voltage from the supply rather than that which is set on the
regulator.
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
[treding@nvidia.com: return early for bypass mode]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A const pointer to regulator ops is stored in regulator descriptors. The
operations never need to be modified, so define them as const as a hint
to the compiler that they can go into .rodata.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
LD06 on the AS3722 power management IC supports a bypass mode. Bypass
is enabled for the LDO by writing the value 0x3F to the voltage select
field in the control register for the LDO. Note that this is the same
register and field that is used to select the voltage as well for the
LDO.
Add support for bypass on LDO6 by specifying the various bypass
parameters for regulator and adding new function pointer tables for the
LDO. Note that the bypass OFF value is the same as the ON value simply
because there is no actual OFF value and bypass will be disabled when
a new voltage is written to the VSEL field.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver's init and exit function don't do anything besides registering
and unregistering the platform driver, so the module_platform_driver()
macro could just be used instead of having separate functions.
Currently the macro is not being used because the driver is initialized at
subsys init call level but this isn't necessary since consumer devices are
defined in the DT as dependencies so there's no need for init calls order.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver's init and exit function don't do anything besides registering
and unregistering the platform driver, so the module_platform_driver()
macro could just be used instead of having separate functions.
Currently the macro is not being used because the driver is initialized at
subsys init call level but this isn't necessary since consumer devices are
defined in the DT as dependencies so there's no need for init calls order.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit <2330b05c095bdeaaf1261c54cd2d4b9127496996> ("regulator: twl: Make
sure we have access to powerbus before trying to write to it")
has implemented the needed logic to correctly access powerbus through i2c,
however it brought a typo when powerbus configuration is restored, which
results in writing to a wrong register. Fix that by providing the correct
register value.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In continuous mode of the PWM regulators, the requested voltage
PWM duty cycle is calculated in terms of 100% scale where entire
range denotes 100%. The calculation for PWM pulse ON time(duty_pulse)
is done as:
duty_cycle = ((requested - minimum) * 100) / voltage_range.
then duty pulse is calculated as
duty_pulse = (pwm_period/100) * duty_cycle
This leads to the calculation error if we have the requested voltage
where accurate pulse time is possible.
For example: Consider following case
voltage range is 800000uV to 1350000uV.
pwm-period = 1550ns (1ns time is 1mV).
Requested 900000uV.
duty_cycle = ((900000uV - 800000uV) * 100)/ 1550000
= 6.45 but we will get 6.
duty_pulse = (1550/100) * 6 = 90 pulse time.
90 pulse time is equivalent to 90mV and this gives us pulse time equivalent
to 890000uV instead of 900000uV.
Proposing the solution in which if requested voltage makes the accurate
duty pulse then there will not be any error. On this case, if
(req_uV - min_uV) * pwm_period is perfect dividable by voltage_range
then get the duty pulse time directly.
duty_pulse = ((900000uV - 800000uV) * 1550)/1550000)
= 100
and this is equivalent to 100mV and so final voltage is
(800000 + 100000) = 900000uV which is same as requested,
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Correct smasung.com into samsung.com.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
of_map_mode is needed so to be possible to set initial regulators mode from
the board DTS. Otherwise, for DT boot, regulators are left in their default
state after reset/reboot. Document device specific modes as well.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mixing raw voltage and selector based regulator ops is
inconsistent. This driver already supports some selector based
ops via the list_voltage and set_voltage_time_sel ops but it uses
raw voltage ops for get_voltage and set_voltage. This causes
problems for regulator_set_voltage() and automatic insertion of
slewing delays because set_voltage_time_sel() is only used if the
regulator ops are all selector based. Put another way, delays
aren't happening at all right now when we should be waiting for
voltages to settle. Let's move to pure selector based regulator
ops so that the delays are inserted properly.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Only the FT SMPS type regulators have slewing supported in the
driver, but all types of SMPS regulators need the same support.
The only difference is that some SMPS regulators don't have a
step size and the step delay is typically 20, not 8. Luckily, the
step size reads as 0 for the non-FT types, so we can always read
that, but we need to detect which type of regulator we're using
to figure out what step delay to use. Make these minor
adjustments to the slew rate calculations and add support for the
delay function to the appropriate regulator ops.
Reported-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 5e3ca2b349 ("regulator: Try to resolve regulators supplies on
registration") added a call to regulator_resolve_supply() within
regulator_register() where the regulator_list_mutex is held. This causes
a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC
is registered because regulator_register_resolve_supply() calls
regulator_dev_lookup() which may try to acquire the regulator_list_mutex
again.
Fix this by releasing the mutex before calling
regulator_register_resolve_supply() and update the error exit path to
ensure the mutex is released on an error.
[Made commit message more legible -- broonie]
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Flagging voltage changes as possible for exactly specified voltages
appears to be triggering bugs in the SDHCI code (it should be able to
handle the case where only one voltage it wants is in the range it is
allowed to set) so make sure we only set the flag in cases where there's
genuine variability.
Signed-off-by: Mark Brown <broonie@kernel.org>
This aids in debugging problems triggered by the regulator core applying
its constraints, we could potentially crash immediately after updating
the voltage if the constraints are buggy.
Signed-off-by: Mark Brown <broonie@kernel.org>
This can be used to expose the act8600 registers via debugfs.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This makes the code easier to read and it avoids a dynamic memory
allocation.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Most Maxim PMIC regulator drivers are for sub-devices of Multi-Function
Devices with drivers under drivers/mfd. But for many of these, the same
object file name was used for both the MFD and the regulator drivers.
Having 2 different drivers with the same name causes a lot of confusion
to Kbuild, specially if these are built as module since only one module
will be installed and also exported symbols will be undefined due being
overwritten by the other module during modpost.
For example, it fixes the following issue when both drivers are module:
$ make M=drivers/regulator/
...
CC [M] drivers/regulator//max14577.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "maxim_charger_calc_reg_current" [drivers/regulator//max14577.ko] undefined!
WARNING: "maxim_charger_currents" [drivers/regulator//max14577.ko] undefined!
Reported-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 6261b06de5 ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.
Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.
This patch tries to resolve the parent supply for the already registered
regulators each time that a new regulator is registered. So the regulators
that have child regulators marked as always on will be enabled regardless
if a driver gets the child regulator or not.
That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.
Since regulator_resolve_supply() checks for rdev->supply, most of the times
it will be a no-op. Errors aren't checked to keep the possible out of order
dependencies which was the motivation for the mentioned commit.
Also, the supply being available will be enforced on regulator get anyways
in case the resolve fails on regulators registration.
Fixes: 6261b06de5 ("regulator: Defer lookup of supply to regulator_get")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org> # 4.1+
On some designs, a handful of the regulators can't be read via
SPMI transactions because they're "secure" and not intended to be
touched by non-secure processors. This driver unconditionally
attempts to read the id registers of all the regulators though,
leading to probe failing and no regulators being registered.
Let's ignore any errors from failing to read the registers and
keep adding other regulators so that this driver can probe on
such devices.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Document the regulators available on pm8994 and add support for
this PMIC to the SPMI PMIC regulator driver.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When machine constraints are applied, regulator framework first sets
initial mode (if any) and then enables the regulator if needed. The current
code in twl4030reg_set_mode always checks if the regulator is enabled
before applying the mode. That results in -EACCES error returned for
"always-on" regulators which have "initial-mode" set in the board DTS. Fix
that by removing the unneeded check.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the TRM, we need to enable i2c access to powerbus before
writing to it. Also, a new write to powerbus should not be attempted if
there is a pending transfer. The current code does not implement that
functionality and while there are no known problems caused by that, it is
better to follow what TRM says.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
instead of 0x1f) thus reading entire register as buck9's voltage. This
effectively caused regulator core to interpret values as higher voltages
than they were and then to set real voltage much lower than intended.
The buck9 provides power to other regulators, including LDO13
and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
voltage caused SD card detection errors on Odroid XU3/XU4:
mmc1: card never left busy state
mmc1: error -110 whilst initialising SD card
During driver probe the regulator core was checking whether initial
voltage matches the constraints. With incorrect vsel_mask of 0xff and
default value of 0x50, the core interpreted this as 5 V which is outside
of constraints (3-3.775 V). Then the regulator core was adjusting the
voltage to match the constraints. With incorrect vsel_mask this new
voltage mapped to a vere low voltage in the driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Currently we only attempt to set the voltage during constraints
application if an exact voltage is specified. Extend this so that if
the currently set voltage for the regulator is outside the bounds set in
constraints we will move the voltage to the nearest constraint, raising
to the minimum or lowering to the maximum as needed. This ensures that
drivers can probe without the hardware being driven out of spec.
Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Apparently due to a wrongly resolved merge conflict between two
branches, which contained the same commit, the commit contents
partially was added two times in a row.
This change reverts the latter wrong inclusion of commit 909f7ee0b5
("regulator: core: Add support for active-discharge configuration").
The first applied commit 670666b9e0 ("regulator: core: Add support
for active-discharge configuration") is not touched.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow the core to always use the voltage constraints to set the voltage
on startup. A forthcoming change in that code will ensure that we bring
out of constraints voltages into spec with this setting.
Signed-off-by: Mark Brown <broonie@kernel.org>
The check would dereference pdata, which can be NULL in the non-DT
use case.
Nothing will break if pdata->num_regulators is larger than the number
of regulators that the driver defines: pdata->num_regulators is only
read in act8865_get_init_data() to iterate through pdata->regulators.
The error handler might have some value as a sanity check on the
platform data, but the platform data could be broken in many other
ways that are not checked for (unknown IDs, duplicate IDs), so I see
no reason to perform only this specific check.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The local variable "dev" already contains a pointer to the device,
so there is no need to take the address of "client->dev" again.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_resolve_supply() function checks if a supply has been
associated with a regulator to avoid enabling it if that is not the
case.
But the supply was already looked up with regulator_resolve_supply()
and set with set_supply() before the check and both return on error.
So the fact that this statement has been reached means that neither
of them failed and a supply must be associated with the regulator.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
- Freescale Touch Screen ADC
- X-Powers AXP PMIC with RSB
- TI TPS65086 Power Management IC (PMIC)
- New Device Support
- Supply device PCI IDs for Intel Broxton
- Fix-ups
- Move to clkdev_create() API; intel_quark_i2c_gpio
- Complete re-write of TI's TPS65912 Power Management IC (PMIC)
- Remove unnecessary function argument; axp20x
- Separate out bus related code; axp20x
- Coding Style changes; axp20x
- Allow more drivers to be compiled as modules
- Work around false positive 'used uninitialised' warning; db8500-prcmu
- Bug Fixes
- Remove do_div(); fsl-imx25-gcq
- Fix driver init when built-in; tps65010
- Fix clock-unregister leak; intel-lpss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW6+LJAAoJEFGvii+H/Hdh8kQP/2AKYzPZiw9fhLufsDPvXO5m
BVdLYVyA11oQjQk7/Bh+5Rjz8mR5Tfv4uAJUReC3FOIfC/oJNBfBxYJLDV/P8S0/
KaCEaZrpNmecKrsy+TjmFYtcRa51THAdjlWEUKRks/ZBjwP4YsNnh5reWe+wB7bS
NFbCNhpXFvYXaDGH8MRhKqdChzZkxi+lgOBcFCKvUYO5/o6g/ZRUD/0TXUItJDwh
F8ps5jImHC1imHeRIKWPNrrZqcYasKmObIhvOKMDcwNQPnjrAWq5QuFH4LFhGQ7d
7NMQrBpaGvZyUNBVtL7ZF1xCJ68wAg/ZvZUkKVkax9ubLbSgf6VXYLQEbq+lyFn7
H9A79xPAGN2nC9HsGnCqW0c0qgTOz0DIkbpuaxAGlzBt0zooc19i3cuUd7LX0NG8
ttLaIP1hX6rgvXSFnF0Ihe3iN5A90LTT3ldbn3A8awyS42vEAbUVL9ivRL21BUbB
ilSTO2W05a9HlIVe43o2euytaGvDYX7RbL/g3WcJLF1pA01RCIDQAI5usMpgF3bf
fJ7cszll0OVTTb5UzbfrNsxAn4oNtbwMIspMMFe17pbmxqh+4oomM3CkuTrMVQfB
pA7Uv0jh/mLCV6P52ZEsNiecn0/l0rID8d/DCHjunr2xBWIOrglzZ7n+vLTJMNJ6
72GVBkYRMLbRm+eph1Tp
=gTBA
-----END PGP SIGNATURE-----
Merge tag 'mfd-for-linus-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Drivers:
- Freescale Touch Screen ADC
- X-Powers AXP PMIC with RSB
- TI TPS65086 Power Management IC (PMIC)
New Device Support:
- Supply device PCI IDs for Intel Broxton
Fix-ups:
- Move to clkdev_create() API; intel_quark_i2c_gpio
- Complete re-write of TI's TPS65912 Power Management IC (PMIC)
- Remove unnecessary function argument; axp20x
- Separate out bus related code; axp20x
- Coding Style changes; axp20x
- Allow more drivers to be compiled as modules
- Work around false positive 'used uninitialised' warning; db8500-prcmu
Bug Fixes:
- Remove do_div(); fsl-imx25-gcq
- Fix driver init when built-in; tps65010
- Fix clock-unregister leak; intel-lpss"
* tag 'mfd-for-linus-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (53 commits)
mfd: intel-lpss: Pass I2C configuration via properties on BXT
mfd: imx6sx: Add PCIe register definitions for iomuxc gpr
mfd: ipaq-micro: Use __maybe_unused to hide pm functions
mfd: max77686: Add max77802 to I2C device ID table
mfd: max77686: Export OF module alias information
mfd: max77686: Allow driver to be built as a module
mfd: stmpe: Add the proper PWM resources
mfd: tps65090: Set regmap config reg counts properly
mfd: syscon: Return ENOTSUPP instead of ENOSYS when disabled
mfd: as3711: Set regmap config reg counts properly
mfd: rc5t583: Set regmap config reg counts properly
gpio: tps65086: Add GPO driver for the TPS65086 PMIC
mfd: mt6397: Add platform device ID table
mfd: da9063: Fix missing volatile registers in the core regmap_range volatile lists
mfd: mt6397: Add MT6323 support to MT6397 driver
mfd: mt6397: Add support for different Slave types
mfd: mt6397: int_con and int_status may vary in location
dt-bindings: mfd: Add bindings for the MediaTek MT6323 PMIC
mfd: da9062: Fix missing volatile registers in the core regmap_range volatile lists
mfd: Add documentation for ACT8945A DT bindings
...
Core changes:
- The gpio_chip is now a *real device*. Until now the gpio chips
were just piggybacking the parent device or (gasp) floating in
space outside of the device model. We now finally make GPIO chips
devices. The gpio_chip will create a gpio_device which contains
a struct device, and this gpio_device struct is kept private.
Anything that needs to be kept private from the rest of the kernel
will gradually be moved over to the gpio_device.
- As a result of making the gpio_device a real device, we have added
resource management, so devm_gpiochip_add_data() will cut down on
overhead and reduce code lines. A huge slew of patches convert
almost all drivers in the subsystem to use this.
- Building on making the GPIO a real device, we add the first step
of a new userspace ABI: the GPIO character device. We take small
steps here, so we first add a pure *information* ABI and the tool
"lsgpio" that will list all GPIO devices on the system and all
lines on these devices. We can now discover GPIOs properly from
userspace. We still have not come up with a way to actually *use*
GPIOs from userspace.
- To encourage people to use the character device for the future,
we have it always-enabled when using GPIO. The old sysfs ABI is
still opt-in (and can be used in parallel), but is marked as
deprecated. We will keep it around for the foreseeable future,
but it will not be extended to cover ever more use cases.
Cleanup:
- Bjorn Helgaas removed a whole slew of per-architecture <asm/gpio.h>
includes. This dates back to when GPIO was an opt-in feature and
no shared library even existed: just a header file with proper
prototypes was provided and all semantics were up to the arch to
implement. These patches make the GPIO chip even more a proper
device and cleans out leftovers of the old in-kernel API here
and there. Still some cruft is left but it's very little now.
- There is still some clamping of return values for .get() going
on, but we now return sane values in the vast majority of drivers
and the errorpath is sanitized. Some patches for powerpc, blackfin
and unicore still drop in.
- We continue to switch the ARM, MIPS, blackfin, m68k local GPIO
implementations to use gpiochip_add_data() and cut down on code
lines.
- MPC8xxx is converted to use the generic GPIO helpers.
- ATH79 is converted to use the generic GPIO helpers.
New drivers:
- WinSystems WS16C48
- Acces 104-DIO-48E
- F81866 (a F7188x variant)
- Qoric (a MPC8xxx variant)
- TS-4800
- SPI serializers (pisosr): simple 74xx shift registers connected
to SPI to obtain a dirt-cheap output-only GPIO expander.
- Texas Instruments TPIC2810
- Texas Instruments TPS65218
- Texas Instruments TPS65912
- X-Gene (ARM64) standby GPIO controller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW6m24AAoJEEEQszewGV1zUasP/RpTrjRcNI5QFHjudd2oioDx
R/IljC06Q072ZqVy/MR7QxwhoU8jUnCgKgv4rgMa1OcfHblxC2R1+YBKOUSij831
E+SYmYDYmoMhN7j5Aslr66MXg1rLdFSdCZWemuyNruAK8bx6cTE1AWS8AELQzzTn
Re/CPpCDbujLy0ZK2wJHgr9ZkdcBGICtDRCrOR3Kyjpwk/DSZcruK1PDN+VQMI3k
bJlwgtGenOHINgCq/16edpwj/hzmoJXhTOZXJHI5XVR6czTwb3SvCYACvCkauI/a
/N7b3quG88b5y0OPQPVxp5+VVl9GyVcv5oGzIfTNat/g5QinShZIT4kVV9r0xu6/
TQHh1HlXleh+QI3yX0oRv9ztHreMf+vdpw1dhIwLqHqfJ7AWdOGk7BbKjwCrsOoq
t/qUVFnyvooLpyr53Z5JY8+LqyynHF68G+jUQyHLgTZ0GCE+z+1jqNl1T501n3kv
3CSlNYxSN/YUBN3cnroAIU/ZWcV4YRdxmOtEWP+7xgcdzTE6s/JHb2fuEfVHzWPf
mHWtJGy8U0IR4VSSEln5RtjhRr0PAjTHeTOGAmivUnaIGDziTowyUVF+X5hwC77E
DGTuLVx/Kniv173DK7xNAsUZNAETBa3fQZTgu+RfOpMiM1FZc7tI1rd7K7PjbyCc
d2M0gcq+d11ITJTxC7OM
=9AJ4
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for kernel v4.6. There is quite a
lot of interesting stuff going on.
The patches to other subsystems and arch-wide are ACKed as far as
possible, though I consider things like per-arch <asm/gpio.h> as
essentially a part of the GPIO subsystem so it should not be needed.
Core changes:
- The gpio_chip is now a *real device*. Until now the gpio chips
were just piggybacking the parent device or (gasp) floating in
space outside of the device model.
We now finally make GPIO chips devices. The gpio_chip will create
a gpio_device which contains a struct device, and this gpio_device
struct is kept private. Anything that needs to be kept private
from the rest of the kernel will gradually be moved over to the
gpio_device.
- As a result of making the gpio_device a real device, we have added
resource management, so devm_gpiochip_add_data() will cut down on
overhead and reduce code lines. A huge slew of patches convert
almost all drivers in the subsystem to use this.
- Building on making the GPIO a real device, we add the first step of
a new userspace ABI: the GPIO character device. We take small
steps here, so we first add a pure *information* ABI and the tool
"lsgpio" that will list all GPIO devices on the system and all
lines on these devices.
We can now discover GPIOs properly from userspace. We still have
not come up with a way to actually *use* GPIOs from userspace.
- To encourage people to use the character device for the future, we
have it always-enabled when using GPIO. The old sysfs ABI is still
opt-in (and can be used in parallel), but is marked as deprecated.
We will keep it around for the foreseeable future, but it will not
be extended to cover ever more use cases.
Cleanup:
- Bjorn Helgaas removed a whole slew of per-architecture <asm/gpio.h>
includes.
This dates back to when GPIO was an opt-in feature and no shared
library even existed: just a header file with proper prototypes was
provided and all semantics were up to the arch to implement. These
patches make the GPIO chip even more a proper device and cleans out
leftovers of the old in-kernel API here and there.
Still some cruft is left but it's very little now.
- There is still some clamping of return values for .get() going on,
but we now return sane values in the vast majority of drivers and
the errorpath is sanitized. Some patches for powerpc, blackfin and
unicore still drop in.
- We continue to switch the ARM, MIPS, blackfin, m68k local GPIO
implementations to use gpiochip_add_data() and cut down on code
lines.
- MPC8xxx is converted to use the generic GPIO helpers.
- ATH79 is converted to use the generic GPIO helpers.
New drivers:
- WinSystems WS16C48
- Acces 104-DIO-48E
- F81866 (a F7188x variant)
- Qoric (a MPC8xxx variant)
- TS-4800
- SPI serializers (pisosr): simple 74xx shift registers connected to
SPI to obtain a dirt-cheap output-only GPIO expander.
- Texas Instruments TPIC2810
- Texas Instruments TPS65218
- Texas Instruments TPS65912
- X-Gene (ARM64) standby GPIO controller"
* tag 'gpio-v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (194 commits)
Revert "Share upstreaming patches"
gpio: mcp23s08: Fix clearing of interrupt.
gpiolib: Fix comment referring to gpio_*() in gpiod_*()
gpio: pca953x: Fix pca953x_gpio_set_multiple() on 64-bit
gpio: xgene: Fix kconfig for standby GIPO contoller
gpio: Add generic serializer DT binding
gpio: uapi: use 0xB4 as ioctl() major
gpio: tps65912: fix bad merge
Revert "gpio: lp3943: Drop pin_used and lp3943_gpio_request/lp3943_gpio_free"
gpio: omap: drop dev field from gpio_bank structure
gpio: mpc8xxx: Slightly update the code for better readability
gpio: mpc8xxx: Remove *read_reg and *write_reg from struct mpc8xxx_gpio_chip
gpio: mpc8xxx: Fixup setting gpio direction output
gpio: mcp23s08: Add support for mcp23s18
dt-bindings: gpio: altera: Fix altr,interrupt-type property
gpio: add driver for MEN 16Z127 GPIO controller
gpio: lp3943: Drop pin_used and lp3943_gpio_request/lp3943_gpio_free
gpio: timberdale: Switch to devm_ioremap_resource()
gpio: ts4800: Add IMX51 dependency
gpiolib: rewrite gpiodev_add_to_list
...
At boot time the regulator driver can be initialized before the
gpio, in which case the call to of_get_named_gpio will return
EPROBE_DEFER. This value is silently passed to regulator_register
which will return success, although the gpio is not registered
(regulator_ena_gpio_request not called) as the value passed is
detected as invalid. The gpio_regulator_probe will therefore
succeed win no gpio requested.
Signed-off-by: Mihai Mihalache <mihai.d.mihalache@intel.com>
Reviewed-by: Hans Holmberg <hans.holmberg@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Prints the error number along with error message when any
error occurs. This help on getting the reason of failure
quickly from log without any code instrument.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of platforms like Nvidia's Tegra210 Jetson-TX1 platform has
multiple PMW based regulators. Add support to have multiple instances
of the driver by not changing any global data of pwm regulator and
if required, making instance specific copy and then making changes.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
With following equation for calculating
voltage_to_duty_cycle_percentage
100 - (((req_uV * 100) - (min_uV * 100)) / diff);
we get 0% for max_uV and 100% for min_uV.
Correcting this to
((req_uV * 100) - (min_uV * 100)) / diff;
to get proper duty cycle.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
OF interface provides to read the u32 value via standard interface
of_property_read_u32(). Use this API to read "regulator-min-microvolts"
and "regulator-max-microvolt".
This will make consistent with other property value reads.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch to fix incorrect clear of event register.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch to fix incorrect clear of event register.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator ops callback for configuration of active-discharge
and provide necessarily information via regulator descriptor.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper function to set the state of active-discharge of
regulator using regmap. The HW regulator driver can directly
use this by providing the necessary information in the regulator
descriptor.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The documentation lists both 1.8V and 3.3V for this regulator output,
but 3.3V is mentioned more often and also matches what JZ4770 and
JZ4780 expect as an input.
Note that the voltage of REG9 is not programmable, so this commit only
changes the voltage reported in sysfs and debugfs, not the actual
output voltage of the hardware.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to preserve its value between calls. I guess this
was a copy-paste slip-up.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
These fields are never used and not required at all, remove them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This problem was introduced by:
commit daad134d66 ("regulator: core: Request GPIO before creating
sysfs entries")
The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.
This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:
[ 1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[ 1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[ 1.130894] pgd = c0004000
[ 1.133598] [00000044] *pgd=00000000
[ 1.137205] Internal error: Oops: 5 [#1] SMP ARM
and here's backtrace from KDB:
Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0: 00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.
Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.
Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't print out an error with the driver sees EPROBE_DEFER when
attempting to get the gpio. These errors are usually transient; the
probe will be retried later.
Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the s2mps11_info.rdev_num because it is not used outside of
probe.
Suggested-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
i2c_master_send() returns the number of bytes written on success.
So current code returns 2 if ad5398_write_reg() success.
This return value is propagated to .set_current_limit, .enable and .disable
callbacks of regulator_ops. This can be a problem, for example, if the
users test if the return value of regulator_set_current_limit() is 0.
Fix it by making ad5398_write_reg() return 0 on success.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
MAXIM Semiconductor's PMIC, MAX77620 and MAX20024 have the
multiple DCDC and LDOs. This supplies the power to different
components of the system.
Also these rails has configuration for ramp time, flexible
power sequence, slew rate etc.
Add regulator driver to access these rails via regulator APIs.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mallikarjun Kasoju <mkasoju@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Following BUILD_BUG_ON using a variable fails for some of the compilers
and optimization levels (reported for gcc 4.9):
var = ARRAY_SIZE(s2mps15_regulators);
BUILD_BUG_ON(S2MPS_REGULATOR_MAX < var);
Fix this by using ARRAY_SIZE directly.
Additionally add missing BUILD_BUG_ON check for S2MPS15 device (the
check ensures that internal arrays are big enough to hold data for all
of regulators on all devices).
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The s5m8767_pmic_probe() function calls s5m8767_get_register() to
read data without checking the return code, which produces a compile-time
warning when that data is accessed:
drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This changes the s5m8767_get_register() function to return a -EINVAL
not just for an invalid register number but also for an invalid
regulator number, as both would result in returning uninitialized
data. The s5m8767_pmic_probe() function is then changed accordingly
to fail on a read error, as all the other callers of s5m8767_get_register()
already do.
In practice this probably cannot happen, as we don't call
s5m8767_get_register() with invalid arguments, but the gcc
warning seems valid in principle, in terms writing safe
error checking.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 9c4c60554a ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
Signed-off-by: Mark Brown <broonie@kernel.org>
The vexpress regulator implementation is currently just called vexpress.
This is a problem because it clashes with another module with the same
name in hardware monitors.
This patch renames the vexpress regulator implementation to
vexpress-regulator so that there will be no clash in the module namespace.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Reported-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Originally the helper macros used uppercase regulator names, which
are primarily used to expand to the regulator ID enum, as the default
names. This is aestheticly unpleasent.
Since the of_match bits are the same, just lowercase, use that as the
default names instead.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the regulator driver for hi655x PMIC.
Signed-off-by: Chen Feng <puck.chen@hisilicon.com>
Signed-off-by: Fei Wang <w.f@huawei.com>
Signed-off-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Reviewed-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
It's perfectly valid to use the LTC3589 without an interrupt pin
connected to it. Currently, the driver probing fails when client->irq
is 0 (which means "no interrupt"). Don't register the interrupt
handler in that case but successfully finish the device probing instead.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The max77686 and max77802 regulator drivers are for sub-devices of a MFD
driver for some PMIC blocks. But the same object file name (max77686.o)
was used for both the common MFD driver and the max77686 regulator one.
This confuses kbuild if both drivers are built as module causing the MFD
driver to not be copied when installing the modules.
Also, max77{686,802} are a quite generic name for MFD subdevices drivers
so it is better to rename them to max77{686,802}-regulator like it's the
case for most regulator drivers.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch adds support for TPS65912 PMIC regulators.
The regulators set consists of 4 DCDCs and 10 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The old tps65912 driver is being replaced, delete old driver.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some devices don't hook the DVS pin to a GPIO but to ground or VCC.
In those cases, it is not a problem to have no DVS GPIO provided, as the current
code will already switch to software-only DVS selection:
When the DVS GPIO is invalid, lp872x_init_dvs jumps to the set_default_dvs_mode
label, which instructs the chip not to use the DVS pin at all and do it all in
software instead (by clearing the LP8720_EXT_DVS_M bit in the
LP872X_GENERAL_CFG register).
That is reflected later in the code, when setting the bucks (the DVS pin only
applies to the bucks) by checking for the LP8720_EXT_DVS_M bit on the
LP872X_GENERAL_CFG register (in lp872x_select_buck_vout_addr) to decide whether
to use software or hardware DVS selection.
Thus, there is no need to print a warning when the DVS GPIO is invalid.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds new regulator driver to support ACT8945A MFD
chip's regulators.
The ACT8945A has three step-down DC/DC converters and four
low-dropout regulators.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
AXP20X datasheet lists the possible voltage settings for LDO4, so
it was implemented using a voltage table. Upon closer examination,
the valid voltages can be mapped into 3 linear ranges.
Move AXP20X LDO4 to use linear ranges. The supporting code can be
reused with later AXP8xx PMICs, which have a number of regulators
that have 2 linear ranges.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch-type regulators, such as DC1SW on AXP22X, are a secondary output
from DCDC1. They are just an on/off switch, and the driver should not
try to read its voltage directly from the DCDC1 control registers.
Instead, the core will pass down the voltage from the regulator supply
chain.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Documentation/devicetree/bindings/regulator/mt6397-regulator.txt doc
mentions that a compatible "mediatek,mt6397-regulator" is required for
the MT6397 device node but the driver doesn't provide a OF match table so
the platform bus .match fallbacks to match using the driver name instead.
This also means that module auto-loading is broken for this driver since
the MFD driver that register the device, has a .of_compatible set so the
platform .uevent callback reports a OF modalias that's not in the module.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform bus_type .match callback attempts to match the platform device
name with an entry on the .id_table if provided and fallbacks to match with
the driver's name if a table is not provided.
Using a platform device ID to match is more explicit, allows the driver to
support more than one device and also the MODULE_DEVICE_TABLE macro can be
used to export the module aliases information instead of the MODULE_ALIAS.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we now free the constraints in regulator_dev_release we will still
call free on the constraints pointer even if we went down an error
path in regulator_register, because it is only allocated after the
device_register. As such we no longer need to free rdev->constraints
on the error paths, so this patch removes said frees.
Fixes: 29f5f4860a ("regulator: core: Move more deallocation into class unregister")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Aside from a fix for a spurious warning (which caused more problems than
it fixed in the fixing really) this is all driver updates, including new
drivers for Dialog PV88060/90 and TI LM363x and TPS65086 devices. The
qcom_smd driver has had PM8916 and PMA8084 support added.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWlUWiAAoJECTWi3JdVIfQtywH/0joibyUbL34arXcPNCUUhlo
UnhTgT1kfOoS01ODt9gU49X4/8SRL9HdjcrIV8yTz4Ldb8by8Rd3ZrkO//9zs7BF
5PIqIzEw6FT/Ovsj8Tc35irccMSrwtTIGRrA8zrM/WtWQWcIUWFxMw+j/lewIvvH
jHZNTTLL5XemObSTfvzhbS6PZ8RcvRVXLNJjZYYO5xAEHNg3i5Hxao5p3QKzVJ8m
P5n4jSiTY/pVePcs9dzzQTGjlzkE11KX7DBxnmXOSPZsArSaRIC53DCmqu/JoG+o
3JJBkmRx7IJb0651hclFaUl8Wl56FSst+zigeAj82b301xpVR30iG3xiwYK/AT8=
=NQ6n
-----END PGP SIGNATURE-----
Merge tag 'regulator-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"Aside from a fix for a spurious warning (which caused more problems
than it fixed in the fixing really) this is all driver updates,
including new drivers for Dialog PV88060/90 and TI LM363x and TPS65086
devices. The qcom_smd driver has had PM8916 and PMA8084 support
added"
* tag 'regulator-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (36 commits)
regulator: core: remove some dead code
regulator: core: use dev_to_rdev
regulator: lp872x: Get rid of duplicate reference to DVS GPIO
regulator: lp872x: Add missing of_match in regulators descriptions
regulator: axp20x: Fix GPIO LDO enable value for AXP22x
regulator: lp8788: constify regulator_ops structures
regulator: wm8*: constify regulator_ops structures
regulator: da9*: constify regulator_ops structures
regulator: mt6311: Use REGCACHE_RBTREE
regulator: tps65917/palmas: Add bypass ops for LDOs with bypass capability
regulator: qcom-smd: Add support for PMA8084
regulator: qcom-smd: Add PM8916 support
soc: qcom: documentation: Update SMD/RPM Docs
regulator: pv88090: logical vs bitwise AND typo
regulator: pv88090: Fix irq leak
regulator: pv88090: new regulator driver
regulator: wm831x-ldo: Use platform_register/unregister_drivers()
regulator: wm831x-dcdc: Use platform_register/unregister_drivers()
regulator: lp8788-ldo: Use platform_register/unregister_drivers()
regulator: core: Fix nested locking of supplies
...
Setting the set_suspend_enable/disable callback to support
enable and disable the dcdc when system is suspend.
Signed-off-by: zhangqing <zhangqing@rock-chips.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Originally queue_delayed_work() used to negative error codes or 0 and 1
on success depending if the work was queued or not. It caused a lot of
bugs where people treated all non-zero returns as failures so we changed
it to return bool instead in d4283e9378 ('workqueue: make queueing
functions return bool'). Now it never returns failure.
Checking for negative values causes a static checker warning since it is
impossible based on the bool type.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The lp872x structure holds a reference to the DVS GPIO, but it is never actually
used anywhere, since a first reference exists from the lp872x_dvs structure.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to select the regulators via of_find_regulator_by_node (and thus use
them in devicetree), defining of_match for each regulator is required.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
The enable/disable values for GPIO LDOs are reversed. It seems no one
noticed as AXP22x support was introduced recently, and no one was using
the GPIO LDOs, either because no designs actually use them or board
support hasn't caught up.
Fixes: 1b82b4e4f9 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The regulator_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
This regulator is on a slow i2c bus. Register accesses are very simple,
they all either enable/disable a regulator channel, or select a new
voltage level. Thus, reading registers from the device will always
return what was last written.
Therefore we can save a lot of time when reading registers by using a
regmap_cache. Since the register map is relatively large, but we only
ever access a few of them, we use an RBTREE cache.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
set/get_bypass ops were missing for ldo1/ldo2 on tps65917 and
ldo9 on palmas/tps659038 which support bypass mode.
Adding the bypass ops helps consumers configure these ldos in
bypass mode or remove bypass mode if need be.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reported-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support and documentation for the PMA8084 regulators
found on APQ8084 platforms.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support and documentation for the PM8916 regulators
found on MSM8916 platforms.
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
These were supposed to be bitwise AND instead of logical. Also kernel
style is for the operator to be on the first line and I removed some
extra parenthesis.
Fixes: c90456e36d ('regulator: pv88090: new regulator driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use devm_request_threaded_irq to ensure the irq is freed when unload the
module.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is the driver for the Powerventure PV88090 BUCKs and LDOs regulator.
It communicates via an I2C bus to the device.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit fa731ac7ea ("regulator: core: avoid unused variable warning")
introduced a subtle change in how supplies are locked. Where previously
code was always locking the regulator of the current iteration, the new
implementation only locks the regulator if it has a supply. For any
given power tree that means that the root will never get locked.
On the other hand the regulator_unlock_supply() will still release all
the locks, which in turn causes the lock debugging code to warn about a
mutex being unlocked which wasn't locked.
Cc: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Fixes: Fixes: fa731ac7ea ("regulator: core: avoid unused variable warning")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The latest workaround for the lockdep interface's not using the second
argument of mutex_lock_nested() changed the loop missed locking the last
regulator due to a thinko with the loop termination condition exiting
one regulator too soon.
Reported-by: Tyler Baker <tyler.baker@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make changes to allow this driver to work with the updated TPS65086 core
driver and bindings.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There were some missing "ret = " assignments here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As noticed by Geert Uytterhoeven, my patch to avoid a harmless build warning
in regulator_lock_supply() was total crap and introduced a real bug:
> [ BUG: bad unlock balance detected! ]
> kworker/u4:0/6 is trying to release lock (&rdev->mutex) at:
> [<c0247b84>] regulator_set_voltage+0x38/0x50
we still lock the regulator supplies, but not the actual regulators,
so we are missing a lock, and the unlock is unbalanced.
This rectifies it by first locking the regulator device itself before
using the same loop as before to lock its supplies.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 716fec9d1965 ("[SUBMITTED] regulator: core: avoid unused variable warning")
Signed-off-by: Mark Brown <broonie@kernel.org>
LM363X regulator driver supports LM3631 and LM3632.
LM3631 has 5 regulators. LM3632 provides 3 regulators.
One boost output and LDOs are used for the display module.
Boost voltage is configurable but always on.
Supported operations for LDOs are enabled/disabled and voltage change.
Two LDOs of LM3632 can be controlled by external pins.
Those are configured through the DT properties.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for TPS65218 LS3 current regulator, which is capable of 4
current input limit modes: 100, 200, 500, and 1000 uA.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use devm_request_threaded_irq to ensure the irq is freed when unload the
module.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently S2MPSXX multifunction device is named as *-pmic,
and these MFDs also supports regulator as a one of its MFD cell which
has the same name, because current name is confusing and we want to
sort it out.
We did discussed different approaches about how the MFD and it
cells need to be named here [1].
Based in the discussion this patch rename MFD regulator name as
*-regulator instead of current *-pmic.
This patch also changes the corresponding entries in the regulator driver
to keep git-bisect happy.
[1]-> https://lkml.org/lkml/2015/10/28/417
Suggested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is the driver for the Powerventure PV88060 BUCKs and LDOs regulator.
It communicates via an I2C bus to the device.
Signed-off-by: James Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The second argument of the mutex_lock_nested() helper is only
evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we
get this build warning for the new regulator_lock_supply
function:
drivers/regulator/core.c: In function 'regulator_lock_supply':
drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable]
To avoid the warning, this restructures the code to make it
both simpler and to move the 'i++' outside of the mutex_lock_nested
call, where it is now always used and the variable is not
flagged as unused.
We had some discussion about changing mutex_lock_nested to an
inline function, which would make the code do the right thing here,
but in the end decided against it, in order to guarantee that
mutex_lock_nested() does not introduced overhead without
CONFIG_DEBUG_LOCK_ALLOC.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 9f01cd4a91 ("regulator: core: introduce function to lock regulators and its supplies")
Link: http://permalink.gmane.org/gmane.linux.kernel/2068900
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7e50711993 ("mfd: tps6105x: Use i2c regmap to access
registers"), we can use regmap helper functions instead of open coded.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Tested-by: Denis Grigoryev <grigoryev@fastwel.ru>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fix the below build error:
drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c'
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Add support for TPS65086 PMIC regulators.
The regulators set consists of 3 Step-down Controllers, 3 Step-down
Converters, 3 LDOs, 3 Load Switches, and a Sink and Source LDO. The
output voltages are configurable and are meant to supply power to a
SoC and/or other components.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Quite a lot of activity in SPI this cycle, almost all of it in drivers
with a few minor improvements and tweaks in the core.
- Updates to pxa2xx to support Intel Broxton and multiple chip selects.
- Support for big endian in the bcm63xx driver.
- Multiple slave support for the mt8173
- New driver for the auxiliary SPI controller in bcm2835 SoCs.
- Support for Layerscale SoCs in the Freescale DSPI driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWOehzAAoJECTWi3JdVIfQTPYH+wYMDG8gAIw2s0AJ4DvVe4qZ
sOAm1UgUJZxssrEA6BNqbfM0dfRo+oQJKmRd0Dc5n7LEMsYHdI/5yKHk8PCS6ZzD
iQyQCzbd0thDAqwuPaMP62cyPDHwyJX22VGTsgVnj6AZqAQ+9+g4SPKhFnm1Mlm4
hmDi6fdSrsqo8k8gkpVN8RFOfVsjAV1dLtAauQRWDHrqMxXURSrKG76eqAqUa5bn
BLPXBoj5PA0DMLPO2j+ADZwWN723LrI2mSSlc+ThjEX/OIt2OhAoiOTV5RPqaafy
TIsCkh68q/gYAsL5HtvvmgZByl41FLYiO0Z+rXmWUyMMbnvhZTLws9S2BNpBLuk=
=DgXG
-----END PGP SIGNATURE-----
Merge tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"Quite a lot of activity in SPI this cycle, almost all of it in drivers
with a few minor improvements and tweaks in the core.
- Updates to pxa2xx to support Intel Broxton and multiple chip selects.
- Support for big endian in the bcm63xx driver.
- Multiple slave support for the mt8173
- New driver for the auxiliary SPI controller in bcm2835 SoCs.
- Support for Layerscale SoCs in the Freescale DSPI driver"
* tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits)
spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI
spi: pxa2xx: Add support for Intel Broxton
spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals
spi: pxa2xx: Add output control for multiple Intel LPSS chip selects
spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific
spi: Add DSPI support for layerscape family
spi: ti-qspi: improve ->remove() callback
spi/spi-xilinx: Fix race condition on last word read
spi: Drop owner assignment from spi_drivers
spi: Add THIS_MODULE to spi_driver in SPI core
spi: Setup the master controller driver before setting the chipselect
spi: dw: replace magic constant by DW_SPI_DR
spi: mediatek: mt8173 spi multiple devices support
spi: mediatek: handle controller_data in mtk_spi_setup
spi: mediatek: remove mtk_spi_config
spi: mediatek: Update document devicetree bindings to support multiple devices
spi: fix kernel-doc warnings about missing return desc in spi.c
spi: fix kernel-doc warnings about missing return desc in spi.h
spi: pxa2xx: Align a few defines
spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select
...
Since we need to read voltages of parents as part of setting supply
voltages we need to be able to do get_voltage() internally without
taking locks so reorganize the locking to take locks on the full tree on
entry rather than as we recurse when called externally.
Reported-by: John Stultz <john.stultz@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver depends on MFD_STW481X but there isn't a build dependency so
it's a good idea to allow the driver to always be built when the
COMPILE_TEST option is enabled.
That way, the driver can be built with a config generated by make
allyesconfig and check if a patch would break the build.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The set_load() op deals with uA while the SMD packets used mA, so
convert as we're building the packet.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Until now changing the voltage of a regulator only ever effected the
regulator itself, but never its supplies. It's a common pattern though
to put LDO regulators behind switching regulators. The switching
regulators efficiently drop the input voltage but have a high ripple on
their output. The output is then cleaned up by the LDOs. For higher
energy efficiency the voltage drop at the LDOs should be minimized. For
this scenario we need to propagate the voltage change to the supply
regulators. Another scenario where voltage propagation is desired is
a regulator which only consists of a switch and thus cannot regulate
voltages itself. In this case we can pass setting voltages to the
supply.
This patch adds support for voltage propagation. We do voltage
propagation when the current regulator has a minimum dropout voltage
specified or if the current regulator lacks a get_voltage operation
(indicating it's a switch and not a regulator).
Changing the supply voltage must be done carefully. When we are
increasing the current regulators output we must first increase the
supply voltage and then the regulator itself. When we are decreasing the
current regulators voltage we must decrease the supply voltage after
changing the current regulators voltage.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
_regulator_call_set_voltage has code to translate a minimum/maximum
voltage pair into a selector. This code is useful for others aswell,
so create a regulator_map_voltage function.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The anatop regulators are SoC internal LDO regulators usually supplied
by an external PMIC. This patch adds support for specifying the supply
from the device tree using the vin-supply property.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The LDO1 driver is using the arizona_of_get_named_gpio helper function
which will return 0 if an error was encountered whilst parsing the GPIO,
as under the pdata scheme 0 was not being treated as a valid GPIO.
However, since the regulator framework was expanded to allow the use of
GPIO 0 this causes us to attempt to register GPIO 0 when we encountered
an error parsing the device tree.
This patch uses of_get_named_gpio directly and sets the
ena_gpio_initialized flag based on the return value.
Fixes: 1de3821ace ("regulator: Set ena_gpio_initialized in regulator drivers")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Provide an additional case entry for DA9053_BC in the find_regulator_info()
function in order to support BC type silicon for the DA9053 device.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The DC1SW and DC5LDO regulators in the AXP22X are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property.
Since they are internally connected, the relationship should not be
represented in the device tree, but handled internally by the driver.
This patch has the driver remember the regulator names for the parent
DCDC1/DCDC5, and use them as supply names for DC1SW/DC5LDO.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch modifies tps6105x and associated function driver to use regmap
instead of operating directly on i2c.
Signed-off-by: Denis Grigoryev <grigoryev@fastwel.ru>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
For the step-down DC/DC regulators, the output voltage is
selectable by setting VSEL pin that when VSEL is low, output
voltage is programmed by VSET1[] bits, and when VSEL is high,
output voltage is programmed by VSET2[] bits.
The DT property "active-semi,vsel-high" is used to specify
the VSEL pin at high on the board.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Each regulator_dev is locked with its own mutex. This is fine as long
as only one regulator_dev is locked, but makes lockdep unhappy when we
have to walk up the supply chain like it can happen in
regulator_get_voltage:
regulator_get_voltage ->
mutex_lock(®ulator->rdev->mutex) ->
_regulator_get_voltage(regulator->rdev) ->
regulator_get_voltage(rdev->supply) ->
mutex_lock(®ulator->rdev->mutex);
This causes lockdep to issue a possible deadlock warning.
There are at least two ways to work around this:
- We can always lock the whole supply chain using the functions
introduced with this patch.
- We could store the current voltage in struct regulator_rdev so
that we do not have to walk up the supply chain for the
_regulator_get_voltage case.
Anyway, regulator_lock_supply/regulator_unlock_supply will be needed
once we allow regulator_set_voltage to optimize the supply voltages.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
When resolving regulator-regulator supplies we ignore probe deferral
returns from regulator_dev_lookup() (such as are generated for DT when
we can see a supply is registered) and just fall back to the dummy
regulator if there are full constraints (as is the case for DT). This
means that probe deferral is broken for DT systems, fix that by paying
attention to -EPROBE_DEFER return codes like we do -ENODEV.
A further patch will simplify this further, this is a minimal fix for
the specific issue.
Fixes: 9f7e25edb1 (regulator: core: Handle full constraints systems when resolving supplies)
Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonnie@kernel.org>
Cc: stable@vger.kernel.org
The enable bit indexes for DCDC4 and DCDC5 regulators are off by 1.
We haven't run into any problems with this since either the regulators
aren't defined in the DT and aren't used, or all the DCDC regulators
have the "always-on" property set, as they are almost always used
for system critical loads.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Implement the ->enable(), ->disable() and ->is_enabled methods and remove
the PWM call in ->set_voltage_sel().
This is particularly important for critical regulators tagged as always-on,
because not claiming the PWM (and its dependencies) might lead to
unpredictable behavior (like a system hang because the PWM clk is only
claimed when the PWM device is enabled).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we are already registering a device with regulator_class for each
regulator device, regulator_list is redundant and can be replaced with
calls to class_find_device() and class_for_each_device().
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add device tree based initialization support for tps65023 regulators.
Therefore add macros for regulator definition setting of_match and
regulators_node members. Add initialization of regulator_desc data
using these macros. Remove old regulator_desc initialization.
Add device tree binding document for tps65023 regulators.
Signed-off-by: Thomas Elste <thomas.elste@imms.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The ret pointer passed to regulator_dev_lookup is only filled with a
valid error code if regulator_dev_lookup returned NULL. Currently
regulator_resolve_supply checks this ret value before it checks if a
regulator was returned, this can result in valid regulator lookups being
ignored.
Fixes: 6261b06de5 ("regulator: Defer lookup of supply to regulator_get")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Introduce "regulator-allow-set-load" property to make it possible to
flag in the board configuration that a regulator is allowed to have the
load requirements changed.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The same error print exists 4 times in the regulator core
<rdev>: operation not allowed
Unfortunately, seeing this in the dmesg is not very informative.
Add what type of operation is not allowed to the message so that
these errors are unique, hopefully pointing developers in the
right direction
<rdev>: drms operation not allowed
<rdev>: voltage operation not allowed
<rdev>: current operation not allowed
<rdev>: mode operation not allowed
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add missing zero to value. This will be needed when range checking
is implemented.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It's clearly a typo error that just creates a null statement so remove it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It's clearly a typo error that just creates a null statement so remove it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This has been a busy release for regmap. By far the biggest set of
changes here are those from Markus Pargmann which implement support for
block transfers in smbus devices. This required quite a bit of
refactoring but leaves us better able to handle odd restrictions that
controllers may have and with better performance on smbus.
Other new features include:
- Fix interactions with lockdep for nested regmaps (eg, when a device
using regmap is connected to a bus where the bus controller has a
separate regmap). Lockdep's default class identification is too
crude to work without help.
- Support for must write bitfield operations, useful for operations
which require writing a bit to trigger them from Kuniori Morimoto.
- Support for delaying during register patch application from Nariman
Poushin.
- Support for overriding cache state via the debugfs implementation
from Richard Fitzgerald.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJV6cZyAAoJECTWi3JdVIfQM3sH/RSygzRIOoOuvro0U3qd4+nM
qLzpuZNtuAP7xNc5yJZiixz1S6PqUNl+pK/u58s6x10GWDGsWZY6E0Lg94lYmfhA
26jqWSzrMHp42x+ZN7btLExzPTVnvRerrjtj4mqz6t4yun9SzqVymaZTUZ1hqPHB
qxSNHs3rHPiqiEWpQKJXb+5dazYYJCbOUrlivxJCk60+ns1N88cA71aY+5/zq5uy
36e0iYe3s+lv0lptedarFCf9p7o1E6EQzhvEMfyquGXtvq8fl7Qdeo7riRFQ8Iiy
sygCb3AYuZIiqnOC7+90xkr2Oq0iwdJUD91A9sl/SRiwgItG9jW03bWNHYIhQyk=
=CbGt
-----END PGP SIGNATURE-----
Merge tag 'regmap-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap updates from Mark Brown:
"This has been a busy release for regmap.
By far the biggest set of changes here are those from Markus Pargmann
which implement support for block transfers in smbus devices. This
required quite a bit of refactoring but leaves us better able to
handle odd restrictions that controllers may have and with better
performance on smbus.
Other new features include:
- Fix interactions with lockdep for nested regmaps (eg, when a device
using regmap is connected to a bus where the bus controller has a
separate regmap). Lockdep's default class identification is too
crude to work without help.
- Support for must write bitfield operations, useful for operations
which require writing a bit to trigger them from Kuniori Morimoto.
- Support for delaying during register patch application from Nariman
Poushin.
- Support for overriding cache state via the debugfs implementation
from Richard Fitzgerald"
* tag 'regmap-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: (25 commits)
regmap: fix a NULL pointer dereference in __regmap_init
regmap: Support bulk reads for devices without raw formatting
regmap-i2c: Add smbus i2c block support
regmap: Add raw_write/read checks for max_raw_write/read sizes
regmap: regmap max_raw_read/write getter functions
regmap: Introduce max_raw_read/write for regmap_bulk_read/write
regmap: Add missing comments about struct regmap_bus
regmap: No multi_write support if bus->write does not exist
regmap: Split use_single_rw internally into use_single_read/write
regmap: Fix regmap_bulk_write for bus writes
regmap: regmap_raw_read return error on !bus->read
regulator: core: Print at debug level on debugfs creation failure
regmap: Fix regmap_can_raw_write check
regmap: fix typos in regmap.c
regmap: Fix integertypes for register address and value
regmap: Move documentation to regmap.h
regmap: Use different lockdep class for each regmap init call
thermal: sti: Add parentheses around bridge->ops->regmap_init call
mfd: vexpress: Add parentheses around bridge->ops->regmap_init call
regmap: debugfs: Fix misuse of IS_ENABLED
...
Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.
Also update the dt binding documentation for the new compatible
strings.
Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The smd rpm structures are always in little endian, but this
driver is not capable of being used on big endian CPUs. Annotate
the little endian data members and update the code to do the
proper byte swapping.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
We were checking rdev->supply for NULL after dereferencing it. Lets
check for rdev->supply along with _regulator_is_enabled() and call
regulator_enable() only if rdev->supply is not NULL.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/mt6311-regulator.c:169:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has a I2C device id table that is used to create the modaliases
and already contains a "ltc3589" device id. So the modalias is unnecessary.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has a I2C device id table that is used to create the modaliases
and also "ad5398-regulator" is not a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has a I2C device id table that is used to create the modaliases
and also "pfuze100-regulator" is not a supported I2C id, so is never used.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When calling regulator_set_load, regulator_check_drms prints and returns
an error if the regulator device's flag REGULATOR_CHANGE_DRMS isn't set.
drms_uA_update, however, bails out without reporting an error.
Replace the error print with a debug level print so that we don't get
such prints when the underlying regulator doesn't support DRMS.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
If memory allocation gets failed on parsing the DT, then it returns error
'-ENOMEM' explicitly. Then, the driver exists from the _probe().
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, lp872x driver parses the DT and copies values into the
'cl->dev.platform_data' if 'of_node' exists.
This may have architectural issue. Platform data is configurable through
the DT or I2C board info inside the platform area.
However, lp872x driver changes this configuration when it is loaded.
The lp872x driver should get data from the platform side and use the private
data, 'lp872x->pdata' instead of changing the original platform data.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The I2C core always reports the MODALIAS uevent as "i2c:<modalias>"
regardless of the mechanism that was used to register the device
(i.e: OF or board code) and the table that is used later to match
the driver with the device (i.e: I2C id table or OF match table).
So drivers needs to export the I2C id table and this be built into
the module or udev won't have the necessary information to autoload
the needed driver module when the device is added.
But this means that OF-only drivers needs to have both OF and I2C id
tables that have to be kept in sync and also the dev node compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same I2C device name for example.
To avoid the above, the I2C core behavior may be changed in the future
to not require an SPI device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table even when
is unused now to prevent breaking module loading when the core changes.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
MAX77693 based regulators are used by USB gadget subsystem, which
doesn't support deferred probe, so the driver should be registered
before USB gadget drivers get probed.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Just setting fixed_uV is not enough, the regulator core will also check
n_voltages setting. The fixed_uV only works when n_voltages is 1.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Driver for regulators exposed by the Resource Power Manager (RPM) found
in devices based on Qualcomm 8974 and newer platforms.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: Andy Gross <agross@codeaurora.org>
Tested-by: Tim Bird <tim.bird@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Failure to create a debugfs node is not an error, but we print a
warning upon failure to create the node. Downgrade this to a
debug printk so that we're quiet here. This allows multiple
drivers to request a CPU's regulator so that CPUfreq and AVSish
drivers can coexist.
The downside of this approach is that whoever gets to debugfs first
the others who come later to not have any debugfs attributes associated
with them.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_disable of pbias always writes '0' to the enable_reg.
However actual disable value of pbias regulator is not always '0'.
Fix it by populating the disable_val in pbias_reg_info for the
various platforms and assign it to the disable_val of
pbias regulator descriptor. This will be used by
regulator_disable_regmap while disabling pbias regulator.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
The regulator_list has exactly the same contents as the list that the
driver core maintains of regulator_class members so is redundant. As a
first step in converting over to use the class device list convert our
iteration in late_initcall() to use the class device iterator.
Signed-off-by: Mark Brown <broonie@kernel.org>
We really ought to be using the class dvice lifetime management features
more than we are rather than open coding them so take a step towards that
by moving some of the simplest deallocations to the dev_release() function.
Signed-off-by: Mark Brown <broonie@kernel.org>
When we release a regulator we need to remove references to it from the
rdev which means locking the rdev. Currently we also free resources
associated with the regulator inside the rdev lock but there is no need
to do this, we can reduce the region the lock is held by restricting it
to just actions that affect the rdev.
Signed-off-by: Mark Brown <broonie@kernel.org>
When removing a regulator we hold regulator_list_mutex in order to
ensure the regualtor doesn't become removed again. However we only need
to protect the list until we remove the regulator from the list so move
the unlock earlier to reduce the locked region.
Signed-off-by: Mark Brown <broonie@kernel.org>
This allows the module to be autoloaded.
Together with 07949bf9c6 ("cpufreq: dt: allow driver to boot
automatically") this is sufficient to allow a modular kernel (such
as Debian's) to enable cpufreq on a Cubietruck.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make mt6311_buck_ops, mt6311_ldo_ops and mt6311_regulators const and remove
unneeded error variable in mt6311_i2c_probe().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The maximum voltage of buck should be 1.39375V.
1.39375V = 0.6V + 0.00625V * 127, 127 is the max_sel of linear range.
Reported-by: Axel Lin <axel.lin@ingics.com>
signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use regmap helpers for get_voltage_sel and set_voltage_sel ops
if the DVS GPIO is not set.
The DVS GPIO allows on the fly selection of the VSEL register
from two choices. However, if it is not set, the VSEL register
will stay fixed and we can use the regmap ops. This allows use
of the *hardware_vsel* regulator APIs.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for over current protection (OCP), pin control
selection, soft start strength, and auto-mode.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators can automatically shut down when they detect an
over current event. Add an op (set_over_current_protection) and a
DT property + constraint to support this capability.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator support for mt6311.
It has 2 regulaotrs - Buck and LDO, provide the related buck/ldo voltage
data to the driver, and creates the regulator_desc table. Supported
operations for Buck are enabled/disabled and voltage change, only
enabled/disabled for LDO.
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
of_regulator_match.driver_data is (void *). tps6586x uses it to store an
anonymous enum value (those TPS6586X_ID_ values).
Later, it tries to extract the ID by casting directly to an int, which is a
no-no ([-Wpointer-to-int-cast]):
drivers/regulator/tps6586x-regulator.c: In function 'tps6586x_parse_regulator_dt':
drivers/regulator/tps6586x-regulator.c:430:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
id = (int)tps6586x_matches[i].driver_data;
^
Instead of casting to int, uintptr_t is better suited for receiving and
comparing integers extracted from void *. This is especially true on
64-bit systems where sizeof(void *) != sizeof(int).
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The gpiod functions include variants for managed gpiod resources. Use it
to simplify the remove function.
As the driver handles a device node without a specification of dvs gpios
just fine, additionally use the variant of gpiod_get exactly for this
use case. This makes error checking more strict.
As a third benefit this patch makes the driver use the flags parameter
of gpiod_get* which will not be optional any more after 4.2 and so
prevents a build failure when the respective gpiod commit is merged.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This fixes a build problem on mips found by the kbuild test robot:
drivers/regulator/rk808-regulator.c: In function 'rk808_buck1_2_get_voltage_sel_regmap':
drivers/regulator/rk808-regulator.c:97:2: error: implicit declaration of function 'gpiod_get_value' [-Werror=implicit-function-declaration]
if (IS_ERR(gpio) || gpiod_get_value(gpio) == 0)
^
Fixes: bad47ad2ee ("regulator: rk808: fixed the overshoot when adjust voltage")
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a overshoot in DCDC1/DCDC2, we have 2 method to workaround:
1st is use dvs pin to switch the voltage between value in BUCKn_ON_VSEL
and BUCKn_DVS_VSEL. If DVS pin is inactive, the voltage of DCDC1/DCDC2
are controlled by BUCKn_ON_VSEL, when we pull dvs1/dvs2 pin to active,
they would be controlled by BUCKn_DVS_VSEL. In this case, the ramp rate
is same as the value programmed in BUCKn_RATE, and the fastest rate is
10mv/us.
2nd method is gradual adjustment, adjust the voltage to a target value
step by step via i2c, each step is set to 100 mA. If you write the
voltage directly using an i2c write the rk808 will always ramp as fast
as it possibly can, about 100mv/us.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The max77693 regulator driver supports Maxim 77843 device so remove the
max77843 driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The charger and safeout parts of MAX77843 are almost the same as MAX77693.
From regulator point of view the only differences are the constraints
and register values related to these constraints. Now the max77693
regulator driver can be used for MAX77843 device.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to the same definition of state container as in MAX77693 drivers.
This will allow usage of one regulator driver in both devices: MAX77693
and MAX77843.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This prepares for merging some of the drivers between max77693 and
max77843 so the child MFD driver can be attached to any parent MFD main
driver.
Move the state container to common header file. Additionally add
consistent 'i2c' prefixes to its members (of 'struct i2c_client' type).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for different configurations of charger's registers so the
same driver could be used on other devices (e.g. MAX77843).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_resolve_supply() function calls set_supply() which in turn
calls create_regulator() to allocate a supply regulator.
If an error occurs after set_supply() succeeded, the allocated regulator
has to be freed before propagating the error code.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When a regulator is unregistered with regulator_unregister(), a call to
regulator_put() is made for its input supply if there is one. This does
a module_put() to decrement the refcount of the module that owns the
supply but there isn't a corresponding try_module_get() in set_supply()
to make the calls balanced.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch is add regulator_nodes/of_match in the regulator
descriptor for using information from DT instead of specific codes.
With this patch, driver gets simplified,
- No need to maintain "struct of_regulator_match" table
and call of_regulator_match() fn.
- No need for pm800_regulator_dt_init() fn, as it was only
used for of_regulator_match().
- probe() fn got simplified around regulator_config and regulator_desc
initialization.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch replaces standard regulator_register with
devm_regulator_register() fn, as using devm_regulator_register() fn
simplifies the driver return/exit path.
As part of this update, patch also cleanups up all unnecessary changes
which is result of this patch -
- Remove _remove() fn, as devm_ variant takes care of it.
- Remove pm800_regulators.regulators[] field, as it was only
needed during cleanup, so we no longer need this.
This also saved some amount of memory.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch makes code more clean from readability point of view,
make all assignments of LDO, BUCk and regulator_ops structure
at the same indentation.
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When resolving device supplies if we fail to look up the regulator we
substitute in the dummy supply instead if the system has fully specified
constraints. When resolving supplies for regulators we do not have the
equivalent code and instead just directly use the regulator_dev_lookup()
result causing spurious failures.
This does not affect DT systems since we are able to detect missing
mappings directly as part of regulator_dev_lookup() and so have appropriate
handling in the DT specific code.
Reported-by: Christian Hartmann <cornogle@googlemail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a patch for supporting da9215 buck converter.
Signed-off-by: James Ban <james.ban.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add optional interrupt support to the da9210 regulator driver, to handle
over-current, under- and over-voltage, and over-temperature events.
Only the interrupt sources for which we handle events are unmasked, to
avoid interrupts we cannot handle.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/pwm-regulator.c:
In function ‘pwm_regulator_init_table’:
drivers/regulator/pwm-regulator.c:171:14:
warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/pwm-regulator.c:
In function 'pwm_regulator_init_table':
drivers/regulator/pwm-regulator.c:172:14:
warning: 'length' is used uninitialized in this function [-Wuninitialized]
if ((length < sizeof(*duty_cycle_table)) ||
^
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/pwm-regulator.c:
In function 'pwm_regulator_init_continuous':
drivers/regulator/pwm-regulator.c:202:22:
warning: unused variable 'np' [-Wunused-variable]
struct device_node *np = pdev->dev.of_node;
^
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
As per datasheet,
Except LDO2, all other LDO's use bit [3:0] for VOUT select.
Current code uses wrong mask value of 0x1f, So this patch
fixes it to use 0xf.
Signed-off-by: Yi Zhang <yizhang@marvell.com>
[vaibhav.hiremath@linaro.org: Updated changelog with more detailed description]
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove over-bracketing, use framework API to fetch PWM period and
be more forthcoming that pwm_voltage_to_duty_cycle() actually returns
duty cycle as a percentage, rather than a register value.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
In "[3d7ef30] regulator: pwm-regulator: Simplify voltage to duty-cycle
call" we stopped using max_duty_cycle, so we can retire it from device
data and DT.
There is no need to deprecate this property, as it hasn't hit Mainline
yet.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Perhaps this is just personal preference, but ...
This patch introduces a new local variable to receive and test regulator
initialisation data. It simplifies and cleans up the code making it
that little bit easier to read and maintain. The local value is assigned
to the structure attribute when all the others are. This is the way we
usually do things.
Prevents this kind of nonsense:
this->is->just.silly = fetch_silly_value(&pointer);
if (!this->is->just.silly) {
printk("Silly value failed: %d\n", this->is->just.silly);
return this->is->just.silly;
}
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
If we reverse some of the logic and change the formula used,
we can simplify the function greatly.
It is intentional that this function is supplied and then re-worked
within the same patch-set. The submission in the previous patch is
the tried and tested (i.e. in real releases) method written by ST.
This patch contains a simplification provided later. It looks and
performs better, but doesn't have the same time-under-test that the
original method does. The idea is that we keep some history in
order to provide an easy way back i.e. revert.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current version of PWM regulator only supports a static table
approach, where pre-calculated values are supplied by the vendor and
obtained via DT. The continuous-voltage method takes min_uV and
max_uV, and divides the difference between them up into a number of
slices. The number of slices depend on how large the duty cycle
register is. This information is provided by a DT property.
As the name alludes, this provides values for a continuous voltage
range between min_uV and max_uV, which has obvious benefits over
either limited voltage possibilities, or the requirement to provide
a large voltage-table.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support to configure Enhanced Transient Response Enable (ETR)
and Sensitivity Selection based on maximum current i.e. expected
load on that rail.
Maxim recommended as:
- Enable ETR with high sensitivity (75mV/us) for 0 to 9A expected loads,
- Enable ETR with low sensitivity (150mV/us) for 9A to 12A expected loads.
- Disable ETR for expected load > 12A.
These recommendation will be configured for MAX77621 when maximum load
is provided through regulator constraint for maximum current from platform.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The MAX8973/MAX77621 feature an Enhanced Transient Response(ETR)
circuit that is enabled through software. The enhanced transient
response reduces the voltage droop during large load steps by
temporarily allowing all three phases to fire in unison, slewing
total inductor current faster than would normally be possible if
all three phases continued to operate 120deg out of phase. The
enhanced transient response detector features two selectable
sensitivity settings, which select the output voltage slew rate
during load transients that triggers the ETR circuit. The sensitivity
of the ETR detector is set by the CKADV[1:0] bits in the CONTROL2
register.
Add support to configure the ETR through platform data from DT.
Update the DT binding document accordingly.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The control flag for the bias control is MAX8973_CONTROL_BIAS_ENABLE
rather than MAX8973_BIAS_ENABLE which is macro for the bits in
register.
Fix this typo.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Take this out of the main .probe() routine in order to facilitate the
introduction of different ways to obtain 'duty cycle' information.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
ltc3589_reg_defaults[] is not modified after initialized, so make it const.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add lockdep_assert_held_once() to functions explicitly mentioning that
rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't
pollute the dmesg to much.
The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain
regulators calling regulator_notifier_call_chain() without rdev->mutex
held.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVkO2uAAoJEOvOhAQsB9HWOT0P/jvFrpj2iuWqdMcvBuMdlx6K
/9qiMsOStbxmbmjj3RsbFCkeHJMUBCI0ZVrIosdEyeZWx33fHkZJisvN1i1PMA63
qppcZtkGxSmCOi6+e9k+qZNBvKBWy2oCXyLx7zaUKkWuR7wGe9488+9dqd9x+/gu
i/HTvf8Omrukwko2a0omWUSmUimhveb/hQ7Vxc/M9lbxFeO3jMabV5ZzgfnoTTrh
Rd2zo4kGbhj8nxonCUHgamnk6hoTE3KYhBPvqohzTDSTALmZVxhCwaQzQWzq+kdl
oSLa+tik508/csh98tN9dlMkJReHlDNdJIbfazQ1vHI00T5PsQELexFT02iKBhS7
5mdHSPp5P1TgGB6Fk3lN+hVO6Ja0S/vmJUi72M2y5DPd55lnvOaCVuqzWIJTYOoN
tqllBH4WIz27hsJWiMLgkJQaDxfBFYx104tOq56s5SeOthBluSE2xoNDrzZGyvRh
NeVza4ccgxIj0p2xfgeErx89r4GSCNk/LakpcMJReaT7ri23mTCDZJNLMcVW7BYm
2MW6M3LF748eN3P2YyNnU+TeQNpIho4whuwfOV+uR4tpdd5MtMaObWimwxBN7URM
LeW3gIwsZFHxYU9NLeZoQZVi6gDmaVe7ma82AbHXaV/mQVYsSP9M6gCO+FASCTGt
Rz6Nyl4/Ns8rdXUoOud8
=qotW
-----END PGP SIGNATURE-----
Merge tag 'module-implicit-v4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
Pull implicit module.h fixes from Paul Gortmaker:
"Fix up implicit <module.h> users that will break later.
The files changed here are simply modular source files that are
implicitly relying on <module.h> being present. We fix them up now,
so that we can decouple some of the module related init code from the
core init code in the future.
The addition of the module.h include to several files here is also a
no-op from a code generation point of view, else there would already
be compile issues with these files today.
There may be lots more implicit includes of <module.h> in tree, but
these are the ones that extensive build test coverage has shown that
must be fixed in order to avoid build breakage fallout for the pending
module.h <---> init.h code relocation we desire to complete"
* tag 'module-implicit-v4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
frv: add module.h to mb93090-mb00/flash.c to avoid compile fail
drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
drivers/staging: include <module.h> for modular android tegra_ion code
crypto/asymmetric_keys: pkcs7_key_type needs module.h
sh: mach-highlander/psw.c is tristate and should use module.h
drivers/regulator: include <module.h> for modular max77802 code
drivers/pcmcia: include <module.h> for modular xxs1500_ss code
drivers/hsi: include <module.h> for modular omap_ssi code
drivers/gpu: include <module.h> for modular rockchip code
drivers/gpio: include <module.h> for modular crystalcove code
drivers/clk: include <module.h> for clk-max77xxx modular code
It was a busy development cycle at this time, as you can see a wide
range of changes in diffstat. There are no big changes but many
refactoring and improvements. Here we go some highlights:
* ALSA core:
- Procfs codes were cleaned up to use seq_file
- Procfs can be opt out via Kconfig (only for EXPERT)
- Two types of jack API were unified finally; now both kctl and input
jack devs are handled via a single function call.
* HD-audio
- Continued code restructuring for the future ASoC driver; now HDA
controller driver is split to a core helper module.
- Preliminary codes for Skylake audio support in HDA core.
- Proper i915 gfx power well management for SKL & co
- Enabled runtime PM as default for Intel HDMI/DP codecs
- Newer Tegra chip supports
- More quirks for Dell headsets, Alienware (with CA0132), etc.
- A couple of DRM ELD helper API functions
* ASoC
- Support for loading ASoC topology maps from firmware, intended to be
used to allow self-describing DSP firmware images to be built which
can map controls added by the DSP to userspace without the kernel
needing to know about individual DSP firmwares
- Lots of refactoring to avoid direct access to snd_soc_codec where
it's not needed supporting future refactoring
- Big refactoring, cleanup and enhancement for the Wolfson ADSP driver
- Cleanup series for TI TAS2552 and R-CAR drivers
- Fixes and improvements on RT56xx codecs
- Support for TI TAS571x power amplifiers
- Support for Qualcomm APQ8016 and ZTE ZX296702 SoCs
- Support for x86 systems with RT5650 and Qualcomm Storm
- Support for Mediatek AFE (Audio Front End) unit
- Other various small fixes to ASoC codec drivers
* Firewire
- Enhanced to allow non-blocking streams to use timestamp
synchronization
- Improve support for DM1500 and BeBoBv3
* Misc
- Cleanup of old pci API functions over all PCI sound drivers
- Fix long-standing regression of the old powermac i2c setup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVitjmAAoJEGwxgFQ9KSmksW8P/2ngNzNpo/bmmGh6xjB7GWU9
RDAkqhKd6yvcClQojGS9n4a9CJ8nk5tdqTr9rMp58N7DRv6GYCPdq0A+lLOih+yC
UPcTkTMBKm6UtvJjEcaasMxhvs5xno345oo5KrBdvlfv1rXe83dTtzEsybWYkaVD
dJbbr5QFaiyj5cTp9nanK5kyTyDDXCdP+vjBGv5u9+GbVxQ6Eenyts89uSqEZs1F
ltoBrl4VotXyqHKneJ0ttUKEimcVIgu8rCXH0sTtCg0SZVJFi+UXzI/VkkS+expL
x9bNN6bw5UT9LA8+qybFRETx+8qchFsffzeUEle4wkIpVKXt/VqjP3GIvp6umlF5
RhU5Wumf2KuIVjgVsYxd7bUkmHr4ywpqS3vSWMWU90FApJay7exatzLPyUVN0AxH
pdAizc8NWFk1kVtWq8jr9agEdxDt2l+E9UXij+ViGyouMZL1oSvOo9NgovfwvfC6
qKUisUkq53p1uPOW/U5gvF7bee2enEXMI9YUY1Z8MHx7nloq+25Nqma8P0gYthB8
6Qk+t1oqC2p7ZMSkyVHH9nySQmoLITZHZmsHqqpLW+jFtanhuckDI75AvmrScs+r
3+2YZXxPI0caZZ1qxMCd7Clmh7ZcSeRe73HXSXmF0xrLffISM3Yg3ZN10cbWQRj2
D6TiHCspLpn+pcYLcWJ2
=D78E
-----END PGP SIGNATURE-----
Merge tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"It was a busy development cycle at this time, as you can see a wide
range of changes in diffstat. There are no big changes but many
refactoring and improvements. Here we go some highlights:
ALSA core:
- Procfs codes were cleaned up to use seq_file
- Procfs can be opt out via Kconfig (only for EXPERT)
- Two types of jack API were unified finally; now both kctl and input
jack devs are handled via a single function call.
HD-audio:
- Continued code restructuring for the future ASoC driver; now HDA
controller driver is split to a core helper module.
- Preliminary codes for Skylake audio support in HDA core.
- Proper i915 gfx power well management for SKL & co
- Enabled runtime PM as default for Intel HDMI/DP codecs
- Newer Tegra chip supports
- More quirks for Dell headsets, Alienware (with CA0132), etc.
- A couple of DRM ELD helper API functions
ASoC:
- Support for loading ASoC topology maps from firmware, intended to
be used to allow self-describing DSP firmware images to be built
which can map controls added by the DSP to userspace without the
kernel needing to know about individual DSP firmwares
- Lots of refactoring to avoid direct access to snd_soc_codec where
it's not needed supporting future refactoring
- Big refactoring, cleanup and enhancement for the Wolfson ADSP
driver
- Cleanup series for TI TAS2552 and R-CAR drivers
- Fixes and improvements on RT56xx codecs
- Support for TI TAS571x power amplifiers
- Support for Qualcomm APQ8016 and ZTE ZX296702 SoCs
- Support for x86 systems with RT5650 and Qualcomm Storm
- Support for Mediatek AFE (Audio Front End) unit
- Other various small fixes to ASoC codec drivers
Firewire:
- Enhanced to allow non-blocking streams to use timestamp
synchronization
- Improve support for DM1500 and BeBoBv3
Misc:
- Cleanup of old pci API functions over all PCI sound drivers
- Fix long-standing regression of the old powermac i2c setup"
* tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (533 commits)
ALSA: pcm: Fix pcm_class sysfs output
ALSA: hda-beep: Update authors dead email address
ASoC: wm_adsp: Move DSP Rate controls into the codec
ASoC: wm8995: Fix setting sysclk for WM8995_SYSCLK_MCLK2 case
ALSA: hda: provide default bus io ops extended hdac
ALSA: hda: add hda link cleanup routine
ALSA: hda: add hdac_ext stream creation and cleanup routines
ASoC: rsrc-card: remove unused ret
ALSA: HDAC: move SND_HDA_PREALLOC_SIZE to core
ASoC: mediatek: Add machine driver for rt5650 rt5676 codec
ASoC: mediatek: Add machine driver for MAX98090 codec
ASoC: mediatek: Add AFE platform driver
ASoC: rsnd: remove io from rsnd_mod
ASoC: rsnd: move rsnd_mod_is_working() to rsnd_io_is_working()
ASoC: rsnd: don't use rsnd_mod_to_io() on snd_kcontrol
ASoC: rsnd: don't use rsnd_mod_to_io() on rsnd_src_xxx()
ASoC: rsnd: don't use rsnd_mod_to_io() on rsnd_ssi_xxx()
ASoC: rsnd: don't use rsnd_mod_to_io() on rsnd_dma_xxx()
ASoC: rsnd: don't use rsnd_mod_to_io() on rsnd_get_adinr()
ASoC: rsnd: add common interrupt handler for SSI/SRC/DMA
...
Status of enabling suspend mode for regulator was stored in bitmap-like
long integer.
However since adding support for S2MPU02 the number of regulators
exceeded 32 so on devices with more than 32 regulators (S2MPU02 and
S2MPS13) overflow happens when shifting the bit. This could lead to
enabling suspend mode for completely different regulator than intended
or to switching different regulator to other mode (e.g. from always
enabled to controlled by PWRHOLD pin). Both cases could result in larger
energy usage and issues when suspending to RAM.
Fixes: 00e2573d2c ("regulator: s2mps11: Add support S2MPU02 regulator device")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Steve Twiss