06 Nov, 2015
1 commit
-
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
...
04 Nov, 2015
8 commits
-
…5x' and 'regulator/topic/tps65023' into regulator-next
-
…', 'regulator/topic/pwm', 'regulator/topic/qcom-smd' and 'regulator/topic/stw481x' into regulator-next
-
…063' into regulator-next
-
…p', 'regulator/topic/arizona', 'regulator/topic/axp20x' and 'regulator/topic/bcm590xx' into regulator-next
-
…pi/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
Tested-by: John Stultz
Signed-off-by: Mark Brown
28 Oct, 2015
1 commit
-
An spi_driver does not need to set an owner, it will be populated by the
driver core.Signed-off-by: Andrew F. Davis
Acked-by: Jonathan Cameron
Signed-off-by: Mark Brown
23 Oct, 2015
1 commit
-
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
Signed-off-by: Mark Brown
22 Oct, 2015
2 commits
-
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
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown
20 Oct, 2015
1 commit
-
_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
Signed-off-by: Mark Brown
17 Oct, 2015
2 commits
-
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
Signed-off-by: Mark Brown -
The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.Signed-off-by: Sascha Hauer
Signed-off-by: Mark Brown
16 Oct, 2015
2 commits
-
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
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown
06 Oct, 2015
1 commit
05 Oct, 2015
2 commits
-
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
Signed-off-by: Mark Brown -
This patch modifies tps6105x and associated function driver to use regmap
instead of operating directly on i2c.Signed-off-by: Denis Grigoryev
Signed-off-by: Lee Jones
03 Oct, 2015
2 commits
-
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
Reviewed-by: Ludovic Desroches
Signed-off-by: Mark Brown -
Signed-off-by: Richard Fitzgerald
Acked-by: Mark Brown
Signed-off-by: Mark Brown
01 Oct, 2015
3 commits
-
The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.Signed-off-by: Sascha Hauer
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown -
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
Tested-by: Sascha Hauer
Signed-off-by: Mark Brown
Cc: stable@vger.kernel.org
30 Sep, 2015
1 commit
-
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
Signed-off-by: Mark Brown
Cc: stable@vger.kernel.org
22 Sep, 2015
5 commits
-
…gulator/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
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown
19 Sep, 2015
3 commits
-
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
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown -
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
Signed-off-by: Mark Brown
18 Sep, 2015
1 commit
-
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
Signed-off-by: Mark Brown
Cc: stable@vger.kernel.org
17 Sep, 2015
3 commits
-
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
Signed-off-by: Mark Brown -
The same error print exists 4 times in the regulator core
: 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: drms operation not allowed
: voltage operation not allowed
: current operation not allowed
: mode operation not allowedSigned-off-by: Stephen Boyd
Signed-off-by: Mark Brown -
Add missing zero to value. This will be needed when range checking
is implemented.Signed-off-by: Andrew F. Davis
Acked-by: Dan Murphy
Signed-off-by: Mark Brown
15 Sep, 2015
1 commit
-
It's clearly a typo error that just creates a null statement so remove it.
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Mark Brown