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
    ...

    Linus Torvalds
     

04 Nov, 2015

8 commits


28 Oct, 2015

1 commit


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

    Luis de Bethencourt
     

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

    Bjorn Andersson
     
  • 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

    Sascha Hauer
     

20 Oct, 2015

1 commit


17 Oct, 2015

2 commits


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

    Charles Keepax
     
  • 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

    Steve Twiss
     

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

    Chen-Yu Tsai
     
  • 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

    Grigoryev Denis
     

03 Oct, 2015

2 commits


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

    Sascha Hauer
     
  • 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

    Sascha Hauer
     
  • 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

    Mark Brown
     

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

    Chen-Yu Tsai
     

22 Sep, 2015

5 commits


19 Sep, 2015

3 commits


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

    Charles Keepax
     

17 Sep, 2015

3 commits


15 Sep, 2015

1 commit