rename st-pwm to pwm-regulator. And support getting voltage & duty table from
device tree, other platforms can also use this driver without any modify.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code does not take the macro parameter, fix it.
This is not a problem at this moment because the only user actually passes
vreg to FORCE_MODE_IS_2_BITS().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Doing so generates a warning as the first field is a pointer but we use
0 to initialize it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
VCCR is used as a trigger to start voltage transitions, so
we need to mark it volatile in order to make sure it gets
written to hardware every time we set a new voltage.
Fixes regulator voltage being stuck at the first voltage
set after driver load.
[lst: reworded commit message]
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
This patch prepares for changing the max14577 charger driver to allow
configuring battery-dependent settings from DTS.
The patch moves from regulator driver to MFD core driver and exports:
- function for calculating register value for charger's current;
- table of limits for chargers (MAX14577, MAX77836).
Previously they were used only by the max14577 regulator driver. In next
patch the charger driver will use them as well. Exporting them will
reduce unnecessary code duplication.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Driver for regulators exposed by the Resource Power Manager (RPM) found
in Qualcomm 8660, 8960 and 8064 based devices.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current device used for the regulator configuration is the child device
created by the MFD driver. This means that it doesn't have any of_node pointing
to it, and whenever we register the regulators, it will not look into the
regulator supply in the DT, hence requiring to provide regulator aliases in the
MFD driver.
We can easily fix that by using the parent device in our configuration, which
has a DT node associated to it, and will allow a DT lookup. Eventually, we will
be able to remove the aliases in the MFD driver.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The vendor-id gathered from the dt match-data was cast to int but assigned
to an unsigned long, producing warnings on at least sparc, like
drivers/regulator/fan53555.c: In function 'fan53555_regulator_probe':
>> drivers/regulator/fan53555.c:373:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
di->vendor = (int) match->data;
Fix this by using an appropriate cast.
Reported-by: kbuild test robot
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Silergy SYR82x regulators share the exact same functionality and register layout
as the Fairchild FAN53555 regulators. Therefore extend the driver to add
support for them.
Both types use the same vendor id in their ID1 register, so it's not possible
to distinguish them automatically.
Similarly, the types also do not match. Type 8 used by the SYR827 and SYR828
start at 712.5mV and increment in 12.5mv steps, while the FAN53555 type 8
starts at 600mV and increments in 10mV steps.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the ability to parse regulator-data from the devicetree.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
On rk808 buck1 and buck2 have programmable ramp delays. Let's add a
function to allow a client of rk808 to set them.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator constraints already provide a field for the ramp_delay, so
there is no need to set this manually. Therefore implement the set_ramp_delay
callback and convert the pdata value to the constraint value if necessary.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator can be supplied by a parent regulator through its vin pin,
so add the supply_name for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
