Add helper functions that allow regulator consumers to obtain low-level
details about the regulator hardware, like the voltage selector register
address and such. These details can be useful when configuring hardware
or firmware that want to do low-level access to regulators, with no
involvement from the kernel.
The use-case for Tegra is a voltage-controlled oscillator clocksource
which has control logic to change the supply voltage via I2C to achieve
a desired output clock rate.
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This is the driver for the Dialog DA9211 Multi-phase 12A DC-DC Buck
Converter 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@linaro.org>
CONFIG_REGULATOR_AB8500_DEBUG is always not defined.
ab8500_regulator_debug_init() is not called at all now,
ab8500_regulator_debug_exit() simply return 0, thus remove them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
When CONFIG_REGULATOR is not set, we cannot call
regulator_can_change_voltage() from a device driver, which results
in a build error like
video/fbdev/omap2/dss/hdmi5.c: In function 'hdmi_init_regulator':
video/fbdev/omap2/dss/hdmi5.c:149:2: error: implicit declaration of function 'regulator_can_change_voltage' [-Werror=implicit-function-declaration]
even for drivers that don't require the regulator API normally.
Such a use was recently added in the omap2+ hdmi driver.
This avoids the problem by adding a static inline function
stub in the API header, as we have for most of the other
regulator functions as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
We already have dummy implementation for most of the regulators APIs for
!CONFIG_REGULATOR case and were missing it for regulator_set_voltage_time().
Found this issue while compiling cpufreq-cpu0 driver without regulators support
in kernel.
drivers/cpufreq/cpufreq-cpu0.c: In function ‘cpu0_cpufreq_probe’:
drivers/cpufreq/cpufreq-cpu0.c:186:3: error: implicit declaration of function ‘regulator_set_voltage_time’ [-Werror=implicit-function-declaration]
Fix this by adding dummy definition for regulator_set_voltage_time().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Drivers that call regulator_get_optional are tolerant to the absence of
that regulator. By modifying the value returned from the stub function
to match that seen when a regulator isn't present, callers can wrap the
regulator logic with an IS_ERR based conditional even if they happen to
call regulator_is_supported_voltage. This improves efficiency as well
as eliminates the possibility for a very subtle bug.
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
This patch extends the regulator helpers to account for device that use
multiple bits for control when using regmap enable/disable/bypass ops.
The actual regulator helpers wrongly assume that the regulator control
is always performed using single bits, using in the regulator_desc
struct only two parameters *_reg and *_mask defining register and mask
for control.
This patch extends this struct and introduces the helpers to take into
account devices where control is performed using multiple bits and
specific multi-bit values are used for enabling/disabling/bypassing the
regulator.
Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
support pfuze200 chip which remove SW1C and SW4 based on pfuze100.
Signed-off-by: Robin Gong <b38343@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
These patches add the ability to create an alternative device on which
a lookup for a certain supply should be conducted.
A common use-case for this would be devices that are logically
represented as a collection of drivers within Linux but are are
presented as a single device from device tree. It this case it is
necessary for each sub device to locate their supply data on the main
device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
