Add a PRE_DISABLE notification so that consumers can use a
notifier to run any steps required to prepare for the
regulator being switched off. Since the regulator disable
can fail an abort notification is also added.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The user hasn't got a regulator and shouldn't be mislead into thinking
they have one; really we should probably remove this stub entirely (and
may well before the next merge window).
Signed-off-by: Mark Brown <broonie@kernel.org>
sh:sh2007_defconfig fails to build with the following error:
In file included from include/linux/regulator/machine.h:18:0,
from arch/sh/boards/board-sh2007.c:10:
include/linux/regulator/consumer.h: In function 'regulator_get_optional':
include/linux/regulator/consumer.h:271:2:
error: implicit declaration of function 'ERR_PTR'
include/linux/err.h: At top level:
include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'
include/linux/regulator/consumer.h:271:9:
note: previous implicit declaration of 'ERR_PTR' was here
Since consumer.h uses ERR_PTR, it should include err.h.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
In some cases we need to know when a regulator is about to be changed.
Add a way for clients to be notified. Note that for set_voltage() we
don't necessarily know what voltage we'll end up with, so we tell the
client what the range will be so they can prepare.
Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie+linaro@kernel.org>
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>
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>
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>
While the majority of supplies on devices are mandatory and can't be
physically omitted for electrical reasons some devices do have optional
supplies and need to know if they are missing, MMC being the most common
of these.
Currently the core accurately reports all errors when regulators are
requested since it does not know if the supply is one that must be provided
even if by a regulator software does not know about or if it is one that
may genuinely be disconnected. In order to allow this behaviour to be
changed and stub regulators to be provided in the former case add a new
regulator request function regulator_get_optional() which provides a hint
to the core that the regulator may genuinely not be connected.
Currently the implementation is identical to the current behaviour, future
patches will add support in the core for returning stub regulators in the
case where normal regulator_get() fails and the board has requested it.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Chris Ball <cjb@laptop.org>
The expected semantic for something expressed as a tolerance is that it
should deliver the specified value with some deviation allowed but this
is not what set_voltage_tol() currently does. Instead it just passes
the maximum possible range to set_voltage() which will typically result
in a voltage aimed at lower than the target voltage.
Instead first try to set a voltage between the target voltage and the
upper limit, then fall back on the full range. This will be much more
robust against physical variation in systems and makes the API behave
more like users would expect.
Signed-off-by: Mark Brown <broonie@linaro.org>
Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators. This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Andrew Chew <achew@nvidia.com>
Cc: Matthew Longnecker <mlongnecker@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
It's generally important that devices have power when they expect it so
drivers really ought to be checking for errors on the power up paths.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Mark Brown
Richard Fitzgerald
Guenter Roeck
Heiko Stübner
Mark Brown
Tuomas Tynkkynen
Arnd Bergmann
Viresh Kumar
Lee Jones
Tim Kryger
Charles Keepax
Matthias Kaehlcke
Paul Walmsley
Mark Brown