Eric Lee / smarc-fsl-linux-kernel

10 Jun, 2015

1 commit

  • 323de9efd   pinctrl: make pinctrl_register() return proper error code ... Browse Code »

    Currently, pinctrl_register() just returns NULL on error, so the
    callers can not know the exact reason of the failure.

    Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some
    -ENOMEM on error of pinctrl_register(), although the error code
    might be different from the real cause of the error.

    This commit reworks pinctrl_register() to return the appropriate
    error code and modifies all of the pinctrl drivers to use IS_ERR()
    for the error checking and PTR_ERR() for getting the error code.

    Signed-off-by: Masahiro Yamada
    Acked-by: Patrice Chotard
    Acked-by: Thierry Reding
    Acked-by: Heiko Stuebner
    Tested-by: Mika Westerberg
    Acked-by: Mika Westerberg
    Acked-by: Lee Jones
    Acked-by: Sören Brinkmann
    Acked-by: Laurent Pinchart
    Acked-by: Ray Jui
    Acked-by: Antoine Tenart
    Acked-by: Hongzhou Yang
    Acked-by: Wei Chen
    Signed-off-by: Linus Walleij

    Masahiro Yamada
     

27 Mar, 2015

1 commit

  • baa9946e3   pinctrl: constify of_device_id array ... Browse Code »

    of_device_id is always used as const.
    (See driver.of_match_table and open firmware functions)

    Signed-off-by: Fabian Frederick
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD
    Acked-by: Patrice Chotard
    Acked-by: Maxime Coquelin
    Acked-by: Hongzhou Yang
    Acked-by: Lee Jones
    Signed-off-by: Linus Walleij

    Fabian Frederick
     

20 Oct, 2014

1 commit

04 Sep, 2014

1 commit

  • 03e9f0cac   pinctrl: clean up after enable refactoring ... Browse Code »

    commit 2243a87d90b42eb38bc281957df3e57c712b5e56
    "pinctrl: avoid duplicated calling enable_pinmux_setting for a pin"
    removed the .disable callback from the struct pinmux_ops,
    making the .enable() callback the only remaining callback.

    However .enable() is a bad name as it seems to imply that a
    muxing can also be disabled. Rename the callback to .set_mux()
    and also take this opportunity to clean out any remaining
    mentions of .disable() from the documentation.

    Acked-by: Stephen Warren
    Acked-by: Bjorn Andersson
    Acked-by: Fan Wu
    Signed-off-by: Linus Walleij

    Linus Walleij
     

22 Jul, 2014

1 commit

11 Jul, 2014

1 commit

  • 2243a87d9   pinctrl: avoid duplicated calling enable_pinmux_setting for a pin ... Browse Code »

    What the patch does:
    1. Call pinmux_disable_setting ahead of pinmux_enable_setting
    each time pinctrl_select_state is called
    2. Remove the HW disable operation in pinmux_disable_setting function.
    3. Remove the disable ops in struct pinmux_ops
    4. Remove all the disable ops users in current code base.

    Notes:
    1. Great thanks for the suggestion from Linus, Tony Lindgren and
    Stephen Warren and Everyone that shared comments on this patch.
    2. The patch also includes comment fixes from Stephen Warren.

    The reason why we do this:
    1. To avoid duplicated calling of the enable_setting operation
    without disabling operation inbetween which will let the pin
    descriptor desc->mux_usecount increase monotonously.
    2. The HW pin disable operation is not useful for any of the
    existing platforms.
    And this can be used to avoid the HW glitch after using the
    item #1 modification.

    In the following case, the issue can be reproduced:
    1. There is a driver that need to switch pin state dynamically,
    e.g. between "sleep" and "default" state
    2. The pin setting configuration in a DTS node may be like this:

    component a {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = ;
    pinctrl-1 = ;
    }

    The "c_grp_setting" config node is totally identical, maybe like
    following one:

    c_grp_setting: c_grp_setting {
    pinctrl-single,pins = ;
    }

    3. When switching the pin state in the following official pinctrl
    sequence:
    pin = pinctrl_get();
    state = pinctrl_lookup_state(wanted_state);
    pinctrl_select_state(state);
    pinctrl_put();

    Test Result:
    1. The switch is completed as expected, that is: the device's
    pin configuration is changed according to the description in the
    "wanted_state" group setting
    2. The "desc->mux_usecount" of the corresponding pins in "c_group"
    is increased without being decreased, because the "desc" is for
    each physical pin while the setting is for each setting node
    in the DTS.
    Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead
    of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount
    will keep increasing without any chance to be decreased.

    According to the comments in the original code, only the setting,
    in old state but not in new state, will be "disabled" (calling
    pinmux_disable_setting), which is correct logic but not intact. We
    still need consider case that the setting is in both old state
    and new state. We can do this in the following two ways:

    1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin
    setting" repeatedly
    2. "Disable"(calling pinmux_disable_setting) the "same pin setting",
    actually two setting instances, ahead of enabling them.

    Analysis:
    1. The solution #2 is better because it can avoid too much
    iteration.
    2. If we disable all of the settings in the old state and one of
    the setting(s) exist in the new state, the pins mux function
    change may happen when some SoC vendors defined the
    "pinctrl-single,function-off"
    in their DTS file.
    old_setting => disabled_setting => new_setting.
    3. In the pinmux framework, when a pin state is switched, the
    setting in the old state should be marked as "disabled".

    Conclusion:
    1. To Remove the HW disabling operation to above the glitch mentioned
    above.
    2. Handle the issue mentioned above by disabling all of the settings
    in old state and then enable the all of the settings in new state.

    Signed-off-by: Fan Wu
    Acked-by: Stephen Warren
    Acked-by: Patrice Chotard
    Acked-by: Heiko Stuebner
    Acked-by: Maxime Coquelin
    Signed-off-by: Linus Walleij

    Fan Wu
     

23 May, 2014

1 commit

  • 7ea456436   pinctrl: vt8500: Ensure value reg is updated when setting direction ... Browse Code »

    Current code only touches the direction register when setting direction
    to output, which breaks logic like

    echo high > /sys/class/gpio/gpio0/direction

    which is expected to also set the value. This patch also adds a call
    to update the value register when setting direction to output.

    Signed-off-by: Alexey Charkov
    Acked-by: Tony Prisk
    Signed-off-by: Linus Walleij

    Alexey Charkov
     

03 Feb, 2014

1 commit

  • f17248ed8   pinctrl: vt8500: Change devicetree data parsing ... Browse Code »

    Due to an assumption in the VT8500 pinctrl driver, the value passed
    from devicetree for 'wm,pull' was not explicitly translated before
    being passed to pinconf.

    Since v3.10, changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN)
    no longer map 1-to-1 with the expected values in devicetree.

    This patch adds a small translation between the devicetree values (0..2)
    and the enum pin_config_param equivalent values.

    Cc: # v3.10+
    Signed-off-by: Tony Prisk
    Signed-off-by: Linus Walleij

    Tony Prisk
     

04 Dec, 2013

1 commit

  • 9fb1f39eb   gpio/pinctrl: make gpio_chip members typed boolean ... Browse Code »

    This switches the two members of struct gpio_chip that were
    defined as unsigned foo:1 to bool, because that is indeed what
    they are. Switch all users in the gpio and pinctrl subsystems
    to assign these values with true/false instead of 0/1. The
    users outside these subsystems will survive since true/false
    is 1/0, atleast we set some kind of more strict typing example.

    Signed-off-by: Linus Walleij

    Linus Walleij
     

28 Aug, 2013

1 commit

  • 03b054e96   pinctrl: Pass all configs to driver on pin_config_set() ... Browse Code »

    When setting pin configuration in the pinctrl framework, pin_config_set() or
    pin_config_group_set() is called in a loop to set one configuration at a time
    for the specified pin or group.

    This patch 1) removes the loop and 2) changes the API to pass the whole pin
    config array to the driver. It is now up to the driver to loop through the
    configs. This allows the driver to potentially combine configs and reduce the
    number of writes to pin config registers.

    All c files changed have been build-tested to verify the change compiles and
    that the corresponding .o is successfully generated.

    Signed-off-by: Sherman Yin
    Reviewed-by: Christian Daudt
    Reviewed-by: Matt Porter
    Tested-by: Stephen Warren
    Acked-by: Laurent Pinchart
    Signed-off-by: Linus Walleij

    Sherman Yin
     

27 Jun, 2013

1 commit

16 Jun, 2013

1 commit

27 May, 2013

1 commit

14 May, 2013

1 commit

19 Apr, 2013

1 commit

04 Apr, 2013

1 commit

  • 170c6152a   pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500 ... Browse Code »

    This patch adds support for the GPIO/pinmux controller found on the VIA
    VT8500 and Wondermedia WM8xxx-series SoCs.

    Each pin within the controller is capable of operating as a GPIO or as
    an alternate function. The pins are numbered according to their control
    bank/bit so that if new pins are added, the existing numbering is maintained.

    All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
    WM8850.

    Signed-off-by: Tony Prisk
    Reviewed-by: Stephen Warren
    Acked-by: Linus Walleij

    Tony Prisk