There is multiple voltage input pins on device which
takes the voltage input for different voltage regulator.
Support to configure the voltage input supplied by
different regulator for each regulators.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This commit adds device tree support for tps65217 pmic. And usage
details are added to device tree documentation. Driver is tested
by using kernel module with regulator set and get APIs.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Initialize config.of_node for regulator before registering.
This is needed for DT based regulator support.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently s2mps11->iodev, s2mps11->dev and config.dev point to NULL.
This patch fixes the settings for config.dev.
Current code does not need the *dev and *iodev of struct s2mps11_info,
so remove them.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The tps65910 mfd driver has been converted to regmap APIs.
This patch adds tps65910_reg_update_bits() in include/linux/mfd/tps65910.h.
Thus we can use tps65910_reg_read/tps65910_reg_write/tps65910_reg_update_bits
directly and remove tps65910_reg_[read|modify_bits|read_locked|write_locked]
functions. With this change, we can also remove the mutex in struct tps65910_reg.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Tested-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch add Samsung S2MPS11 regulator driver.
The S2MPS11 can support 10 Bucks and 38 LDOs and RTC.
Especially, S2MPS11 is designed for high performance
Samsung application processor.
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Recent change in the core driver to get the maximum voltage
is based on the (n_voltages -1) steps of voltage.
For the tps65910, the (n_voltages -1)th step voltage is
calculated based on the callback function list_voltage.
This function direct maps the datasheet and adjust the
first few steps for initial voltage as per datasheet,
and hence initialize the n_voltages based on datasheet.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Using the same ops for both [en|dis]able and set_suspend_[en|dis]able
callbacks is actively broken. This patch removes .set_suspend_disable and
.set_suspend_enable callback setting.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Using the same ops for both .disable and .set_suspend_disable callbacks is
actively broken. This patch removes .set_suspend_disable callback setting.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Now the MFD API is Device Tree aware we can use it for platform
registration again, even when booting with DT enabled. To aid in
Device Node pointer allocation we provide each cell with the
associative compatible string.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Now the MFD API is Device Tree aware we can use it for platform
registration again, even when booting with DT enabled. To aid in
Device Node pointer allocation we provide each cell with the
associative compatible string.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
There is multiple voltage input pins on device which
takes the voltage input for different voltage regulator.
Support to configure the voltage input supplied by
different regulator for each regulators.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Since DT doesn't provide an idiomatic mechanism for enabling full
constraints and since it's much more natural with DT to provide them
just assume that a DT enabled system has full constraints.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Add support for input supply in DT parsing of node.
The input supply will be provided by the property
"vin-supply" in the regulator node.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This patch device tree support for regulator driver. It uses the parent
(mfd's) DT node to parse the regulator data for max77686.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
With changes introduced by commit 222cc7b (regulator: core: Allow
multiple requests of a single supply mapping) on create_regulator,
regulator_put needs a corresponding update on sysfs entry removing.
Also regulator->dev still needs to get assigned in create_regulator,
otherwise, sysfs_remove_link call in regulator_put will get bypassed.
Reported-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is ok to request current limit with min_uA < chip->min_uA and
max_uA > chip->max_uA.
We need to set min_uA = chip->min_uA if (min_uA < chip->min_uA),
this ensures the equation to calcuate selator does not return negative number.
Also set max_uA = chip->max_uA if (max_uA > chip->max_uA), as suggested by
Sonic.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is essentially the code that was factored out into the core when the
feature was implemented.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is very common for regulators to support having their enable signal
controlled by a GPIO. Since there are a bunch of fiddly things to get
right like handling the operations when the enable signal is tied to
a rail and it's just replicated code add support for this to the core.
Drivers should set ena_gpio in their config if they have a GPIO control,
using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for
the initial state) and ena_gpio_invert if the GPIO is active low. The
core will then override any enable and disable operations the driver has
and instead control the specified GPIO.
This will in the future also allow us to further extend the core by
identifying when several enable signals have been tied together and
handling this properly.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Create new _regulator_do_enable() and _regulator_do_disable() operations
which deal with the mechanics of performing the enable and disable, partly
to cut down on the levels of indentation and partly to support some future
work.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Many regulators have a fixed specification for their enable time. Allow
this to be set in the regulator_desc as a number to save them having to
implement an explicit operation.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Lots of regulator drivers have checks in their map_voltage() functions
to verify that the result of the mapping is in the range originally
specified. Factor these out in the core and provide a bit of extra
defensiveness for other drivers by doing the check in the core.
Since we're now doing a list_voltage() earlier move the current mapping
back to a voltage out into the set_voltage() call to save redoing it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently regulator_is_supported_voltage() works by enumerating the set
of voltages which can be set by the regulator but the checks we're doing
to impose constraints mean that if we can't vary the voltage we'll not
report any voltages as supported even though the regulator is actually
set at that voltage.
We could fix the voltage listing but this would mean that list_voltage()
could end up going to the hardware to get the current voltage which isn't
expected (it's supposed to be very cheap) so instead special case things
when we can't change the voltage and compare the requested range against
the current voltage.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A recursive lockdep warning occurs if you call
regulator_set_optimum_mode() on a regulator with a supply because
there is no nesting annotation for the rdev->mutex. To avoid this
warning, get the supply's load before locking the regulator's
mutex to avoid grabbing the same class of lock twice.
=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #3257 Tainted: G W
---------------------------------------------
swapper/0/1 is trying to acquire lock:
(&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38
but task is already holding lock:
(&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&rdev->mutex);
lock(&rdev->mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by swapper/0/1:
#0: (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c
#1: (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c
#2: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224
stack backtrace:
[<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080)
[<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10)
[<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8)
[<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4)
[<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38)
[<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224)
...
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is ok to request voltage with min_uV < tps->info[rid]->min_uV and
max_uV > tps->info[rid]->max_uV.
The equation we used in uv_to_vsel() does not allow
min_uV < tps->info[rid]->min_uV, otherwise it returns negative selector.
So we need to set min_uV = tps->info[rid]->min_uV if
min_uV < tps->info[rid]->min_uV.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
