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>
n /= range->step_uV + 1; is equivalent to n /= (range->step_uV + 1);
which is wrong. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/qcom_spmi-regulator.c:751:3-50: code aligned
with following code on line 753
drivers/regulator/qcom_spmi-regulator.c:584:3-41: code aligned
with following code on line 587
These lines where missing braces causing the break to always
be executed even when it shouldn't be. Fix it.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Simplify a trivial if-return sequence and combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
CC: Mark Brown <broonie@kernel.org>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add an SPMI regulator driver for Qualcomm's PM8841, PM8941, and
PM8916 PMICs. This driver is based largely on code from
codeaurora.org[1].
[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/regulator/qpnp-regulator.c?h=msm-3.10
Cc: David Collins <collinsd@codeaurora.org>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators can limit their input current (typically annotated
as ilim). Add an op (set_input_current_limit) and a DT property +
constraint to support this.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators support a "soft start" feature where the voltage
ramps up slowly when the regulator is enabled. Add an op
(set_soft_start) and a DT property + constraint to support this.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators need to be configured to pull down a resistor
when the regulator is disabled. Add an op (set_pull_down) and a
DT property + constraint to support this.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators have a fixed load that isn't captured by
consumers that the kernel knows about. Add a constraint to
support this.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix trivial typo.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to avoid potential overflows in print_constraints we
better replace sprintf() with scnprintf().
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The buffer for condtraints debug isn't big enough to hold the output
in all cases. So fix this issue by increasing the buffer.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
We weren't taking into account the already used buffer when telling
sprintf() where to print to.
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Maxim MAX77621 device is high-efficiency, three-phase,
DC-DC step-down switching regulator delivers peak
output currents up to 16A. This device is extension of
MAX8973 and compatible with the register definition.
The MAX77621 has the SHUTDOWN pin which is EN pin on the
MAX8973. On MAX77621, the SHUTDOWN pin (active low) reset
device register to its POR/OTP value. The voltage output
is enabled when SHUTDONW pin is HIGH and EN bit on VOUT
register is HIGH.
For MAX8973, VOUT is enabled when EN bit or EN pin is high.
Add support of the MAX77621 device on max8973 regulator driver
with following changes:
- Make sure SHUTDOWN pin is set HIGH through GPIO calls if
GPIO from AP connected to SHUTDOWN pin provided.
- Enable/disable the rail through register access only.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Regulator core framework support the configuration of ramp
delay reading from platform specific regulator data via the
regulator callback ops.
Instead of reading regulator init data on driver and setting
ramp delay, use the callback to achieve this.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Regulator Device keeps a full copy of it's own, which can be easily accessed.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't consider a failure to add the sysfs node as a problem,
so use sysfs_create_link_nowarn() so that we don't print a
backtrace when duplicated files exist. Also, downgrade the printk
message to a debug statement so that we're quiet here. This
allows multiple drivers to request a CPU's regulator so that
CPUfreq and AVSish drivers can coexist.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Using the driver for the internal regulator to also enable/disable
the codec internal clock frequency controller is an unexpected
side-effect for a regulator, and also means that the core clocks
won't be changed as expected if an external regulator is used to
power the codec.
The DVFS is now handled by the codec driver so can be removed from
the LDO1 driver.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code does not set regulators->irq_ldo_lim and regulators->irq_uvov,
so it actually calls free_irq(0, regulators) twice in remove() but does not
free the irq actually used.
Convert to use devm_request_threaded_irq instead and then we don't need to
take care the clean up irq so remove irq_ldo_lim and irq_uvov from
struct da9063_regulators. Note, regulators->irq_uvov is not used at all in
current code.
There is a slightly change in this patch, it will return error in probe()
if devm_request_threaded_irq fails. If the irq is optional, it should be
fine to allow platform_get_irq_byname fails. But current code does not
allow platform_get_irq_byname fails. So I think the reason to allow
request irq failure is just because the irq leak.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown