01 Sep, 2013

4 commits


30 Aug, 2013

1 commit


19 Aug, 2013

1 commit


09 Aug, 2013

1 commit


07 Aug, 2013

2 commits


31 Jul, 2013

1 commit

  • While the majority of supplies on devices are mandatory and can't be
    physically omitted for electrical reasons some devices do have optional
    supplies and need to know if they are missing, MMC being the most common
    of these.

    Currently the core accurately reports all errors when regulators are
    requested since it does not know if the supply is one that must be provided
    even if by a regulator software does not know about or if it is one that
    may genuinely be disconnected. In order to allow this behaviour to be
    changed and stub regulators to be provided in the former case add a new
    regulator request function regulator_get_optional() which provides a hint
    to the core that the regulator may genuinely not be connected.

    Currently the implementation is identical to the current behaviour, future
    patches will add support in the core for returning stub regulators in the
    case where normal regulator_get() fails and the board has requested it.

    Signed-off-by: Mark Brown
    Acked-by: Chris Ball

    Mark Brown
     

25 Jul, 2013

1 commit


18 Jul, 2013

3 commits


15 Jul, 2013

4 commits

  • In function _regulator_do_set_voltage(), old_selector gets intialised only
    if (_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel &&
    rdev->desc->ops->get_voltage_sel)) is true.

    Before calling set_voltage_time_sel() we checks if (old_selector >= 0) and it
    will true if it got intialised properly. so we don't need to check again
    _regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel before
    calling set_voltage_time_sel().

    Signed-off-by: Yadwinder Singh Brar
    Signed-off-by: Mark Brown

    Yadwinder Singh Brar
     
  • Some hardwares support disabling ramp delay, so adding ramp_disable flag to
    constraints. It will be used to figure out whether ramp_delay in constraints
    is explicitly set to zero or its unintialized (zero by default).
    And we don't need to call set_voltage_time_sel() for regulators for whom ramp
    delay is disabled in constraints.

    Signed-off-by: Yadwinder Singh Brar
    Signed-off-by: Mark Brown

    Yadwinder Singh Brar
     
  • Many regulators have several linear ranges of selector with different
    step sizes, for example offering better resolution at lower voltages.
    Provide regulator_{map,list}_voltage_linear_range() allowing these
    regulators to use generic code. To do so a table of regulator_linear_range
    structs needs to be pointed to from the descriptor.

    This was inspired by similar code included in a driver submission from
    Chao Xie and Yi Zhang at Marvell.

    Signed-off-by: Mark Brown

    Mark Brown
     
  • Signed-off-by: Mark Brown

    Mark Brown
     

01 Jul, 2013

1 commit


07 Jun, 2013

1 commit

  • Add regulator_get_linear_step(), which returns the voltage step size
    between VSEL values for linear regulators. This is intended for use
    by regulator consumers which build their own voltage-to-VSEL tables.

    Signed-off-by: Paul Walmsley
    Reviewed-by: Andrew Chew
    Cc: Matthew Longnecker
    Signed-off-by: Mark Brown

    Paul Walmsley
     

30 May, 2013

1 commit


21 May, 2013

1 commit


02 May, 2013

1 commit


28 Apr, 2013

3 commits


18 Apr, 2013

1 commit

  • A lot of regulator hardware has ascendant voltage list.
    This patch adds regulator_map_voltage_ascend() and export it.

    Drivers that have ascendant voltage list can use this as their map_voltage()
    operation, this is more efficient than default regulator_map_voltage_iterate()
    function.

    Signed-off-by: Axel Lin
    Signed-off-by: Mark Brown

    Axel Lin
     

17 Apr, 2013

1 commit

  • commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
    (regulator: core: Don't defer probe if there's no DT binding for a supply)

    Attempted to differentiate between regulator_get() with an actual
    DT binding for the supply and when there is none to avoid unnecessary
    deferal.
    However, ret value supplied by regulator_dev_lookup() is being
    ignored by regulator_get(). So, exit with the appropriate return value.

    Signed-off-by: Nishanth Menon
    Signed-off-by: Mark Brown

    Nishanth Menon
     

05 Apr, 2013

1 commit

  • Regulator drivers may specify regulator_desc->supply_name which
    regulator_register() will use to find the supply node for a regulator.
    If no supply was specified in the device tree or the supply has yet
    to be registered regulator_register() will fail, deferring the probe
    of the regulator. In the case where no supply node was specified in the
    device tree, there is no supply and it is pointless to try and find one
    later, so go ahead and add the regulator without the supply.

    Signed-off-by: Andrew Bresticker
    Signed-off-by: Mark Brown

    Andrew Bresticker
     

25 Mar, 2013

1 commit


05 Mar, 2013

2 commits


04 Mar, 2013

3 commits

  • The regulator_dev has regulator_enable_gpio structure.
    'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.

    regulator_dev ---> regulator_enable_gpio
    .ena_gpio .gpio
    .ena_gpio_invert .ena_gpio_invert

    Pointer, 'ena_pin' is used for checking valid enable GPIO pin.

    Signed-off-by: Milo(Woogyom) Kim
    Reviewed-by: Axel Lin
    Signed-off-by: Mark Brown

    Kim, Milo
     
  • To support shared enable GPIO pin, replace GPIO code with new static functions

    Reference count: 'enable_count'
    Balance the reference count of each GPIO and actual pin control.
    The count is incremented with enabling GPIO.
    On the other hand, it is decremented on disabling GPIO.
    Actual GPIO pin is enabled at the initial use.(enable_count = 0)
    The pin is disabled if it is not used(shared) any more. (enable_count
    Reviewed-by: Axel Lin
    Signed-off-by: Mark Brown

    Kim, Milo
     
  • A Regulator can be enabled by external GPIO pin.
    This is configurable in the regulator_config.
    At this moment, the GPIO can be owned by only one regulator device.
    In some devices, multiple regulators are enabled by shared one GPIO pin.
    This patch extends this limitation, enabling shared enable GPIO of regulators.

    New list for enable GPIO: 'regulator_ena_gpio_list'
    This manages enable GPIO list.

    New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
    The enable count is used for balancing GPIO control count.
    This count is incremented when GPIO is enabled.
    On the other hand, it's decremented when GPIO is disabled.

    Reference count: 'request_count'
    The reference count, 'request_count' is incremented/decremented on
    requesting/freeing the GPIO. This count makes sure only free the GPIO
    when it has no users.

    How it works
    If the GPIO is already used, skip requesting new GPIO usage.
    The GPIO is new one, request GPIO function and add it to the list of
    enable GPIO.
    This list is used for balancing enable GPIO count and pin control.

    Updating a GPIO and invert code moved
    'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
    new function, regulator_ena_gpio_request().
    Use regulator_enable_pin structure rather than regulator_dev.

    Signed-off-by: Milo(Woogyom) Kim
    Reviewed-by: Axel Lin
    Signed-off-by: Mark Brown

    Kim, Milo
     

01 Mar, 2013

2 commits

  • Unwinding code disables all successfully enabled regulators.
    Error is logged for every failed regulator.

    Signed-off-by: Andrzej Hajda
    Signed-off-by: Kyungmin Park
    Signed-off-by: Mark Brown

    Andrzej Hajda
     
  • commit f59c8f9f (regulator: core: Support bypass mode)
    has a short documentation error around the regulator_allow_bypass
    parameter 'enable' which is documented as 'allow'.

    This generates kernel-doc warning as follows:
    ./scripts/kernel-doc drivers/regulator/core.c >/dev/null
    Warning(drivers/regulator/core.c:2841): No description found for parameter 'enable'
    Warning(drivers/regulator/core.c:2841): Excess function parameter 'allow' description in 'regulator_allow_bypass'

    Cc: Liam Girdwood
    Cc: Mark Brown
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Nishanth Menon
    Signed-off-by: Mark Brown

    Nishanth Menon
     

19 Feb, 2013

3 commits