| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"Quite a lot of activity in SPI this cycle, almost all of it in drivers
with a few minor improvements and tweaks in the core.
- Updates to pxa2xx to support Intel Broxton and multiple chip selects.
- Support for big endian in the bcm63xx driver.
- Multiple slave support for the mt8173
- New driver for the auxiliary SPI controller in bcm2835 SoCs.
- Support for Layerscale SoCs in the Freescale DSPI driver"
* tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits)
spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI
spi: pxa2xx: Add support for Intel Broxton
spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals
spi: pxa2xx: Add output control for multiple Intel LPSS chip selects
spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific
spi: Add DSPI support for layerscape family
spi: ti-qspi: improve ->remove() callback
spi/spi-xilinx: Fix race condition on last word read
spi: Drop owner assignment from spi_drivers
spi: Add THIS_MODULE to spi_driver in SPI core
spi: Setup the master controller driver before setting the chipselect
spi: dw: replace magic constant by DW_SPI_DR
spi: mediatek: mt8173 spi multiple devices support
spi: mediatek: handle controller_data in mtk_spi_setup
spi: mediatek: remove mtk_spi_config
spi: mediatek: Update document devicetree bindings to support multiple devices
spi: fix kernel-doc warnings about missing return desc in spi.c
spi: fix kernel-doc warnings about missing return desc in spi.h
spi: pxa2xx: Align a few defines
spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select
...
|
|
'regulator/topic/tps6105x' and 'regulator/topic/tps65023' into regulator-next
|
|
'regulator/topic/max77802', 'regulator/topic/pwm', 'regulator/topic/qcom-smd' and 'regulator/topic/stw481x' into regulator-next
|
|
'regulator/topic/da9063' into regulator-next
|
|
'regulator/topic/anatop', 'regulator/topic/arizona', 'regulator/topic/axp20x' and 'regulator/topic/bcm590xx' into regulator-next
|
|
|
|
|
|
'spi/topic/omap-uwire', 'spi/topic/owner', 'spi/topic/pxa' and 'spi/topic/pxa2xx' into spi-next
|
|
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: 1de3821ace82 ("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: 9f7e25edb1575a6d2 (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
|
|
'regulator/fix/pbias', 'regulator/fix/tpx65218' and 'regulator/fix/vexpress' into regulator-linus
|
|
|
|
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: 6261b06de565 ("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>
|
|
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
...
|
|
'regmap/topic/force-update' into regmap-next
|
|
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>
|
|
|
|
'regulator/topic/qcom-spmi', 'regulator/topic/rk808', 'regulator/topic/stub' and 'regulator/topic/tol' into regulator-next
|
|
'regulator/topic/ocp', 'regulator/topic/owner', 'regulator/topic/pfuze100' and 'regulator/topic/pwm' into regulator-next
|
|
'regulator/topic/ltc3589', 'regulator/topic/max77693' and 'regulator/topic/max8973' into regulator-next
|
