01 Nov, 2016

1 commit


15 Sep, 2016

1 commit

  • STiH415/6 SoC support is being removed from the kernel.
    This patch updates the ST pinctrl driver and removes
    references to these obsolete platforms. As some structures
    referenced by STiH407 based configuration were shared with
    STiH416 we update these names to match the remaining
    supported platform.

    Signed-off-by: Peter Griffin
    Cc:
    Cc:
    Signed-off-by: Linus Walleij

    Peter Griffin
     

11 Aug, 2016

1 commit

  • This patch allows to use the second parameter of gpio
    specifier, which is used to specify whether the gpio is
    active high or low.

    Simply remove specific of_xlate callback() and of_gpio_n_cells
    and use default one set by of_gpiochip_add() which allows
    to use second parameter gpio specifier.

    Signed-off-by: Maxime Coquelin
    Signed-off-by: Patrice Chotard
    Signed-off-by: Linus Walleij

    Patrice Chotard
     

15 Jun, 2016

1 commit

  • When building with 'make W=1', we get harmless warnings about
    five drivers in drivers/pinctrl, which all contain a copy of
    the same line:

    drivers/pinctrl/freescale/pinctrl-imx1-core.c:160:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration]

    This replaces the somewhat nonstandard 'static const inline'
    with 'static inline const', which has the same meaning but
    does not cause this warning.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Linus Walleij

    Arnd Bergmann
     

21 Apr, 2016

1 commit


27 Jan, 2016

1 commit


05 Jan, 2016

1 commit

  • This makes the driver use the data pointer added to the gpio_chip
    to store a pointer to the state container instead of relying on
    container_of().

    Cc: Srinivas Kandagatla
    Cc: Patrice Chotard
    Acked-by: Maxime Coquelin
    Signed-off-by: Linus Walleij

    Linus Walleij
     

19 Nov, 2015

1 commit

  • The name .dev in a struct is normally reserved for a struct device
    that is let us say a superclass to the thing described by the struct.
    struct gpio_chip stands out by confusingly using a struct device *dev
    to point to the parent device (such as a platform_device) that
    represents the hardware. As we want to give gpio_chip:s real devices,
    this is not working. We need to rename this member to parent.

    This was done by two coccinelle scripts, I guess it is possible to
    combine them into one, but I don't know such stuff. They look like
    this:

    @@
    struct gpio_chip *var;
    @@
    -var->dev
    +var->parent

    and:

    @@
    struct gpio_chip var;
    @@
    -var.dev
    +var.parent

    and:

    @@
    struct bgpio_chip *var;
    @@
    -var->gc.dev
    +var->gc.parent

    Plus a few instances of bgpio that I couldn't figure out how
    to teach Coccinelle to rewrite.

    This patch hits all over the place, but I *strongly* prefer this
    solution to any piecemal approaches that just exercise patch
    mechanics all over the place. It mainly hits drivers/gpio and
    drivers/pinctrl which is my own backyard anyway.

    Cc: Haavard Skinnemoen
    Cc: Rafał Miłecki
    Cc: Richard Purdie
    Cc: Mauro Carvalho Chehab
    Cc: Alek Du
    Cc: Jaroslav Kysela
    Cc: Takashi Iwai
    Acked-by: Dmitry Torokhov
    Acked-by: Greg Kroah-Hartman
    Acked-by: Lee Jones
    Acked-by: Jiri Kosina
    Acked-by: Hans-Christian Egtvedt
    Acked-by: Jacek Anaszewski
    Signed-off-by: Linus Walleij

    Linus Walleij
     

17 Oct, 2015

1 commit

  • Replace all trivial request/free callbacks that do nothing but call into
    pinctrl code with the generic versions.

    Signed-off-by: Jonas Gorski
    Acked-by: Bjorn Andersson
    Acked-by: Heiko Stuebner
    Acked-by: Eric Anholt
    Acked-by: Mika Westerberg
    Acked-by: Andrew Bresticker
    Acked-by: Baruch Siach
    Acked-by: Matthias Brugger
    Acked-by: Lee Jones
    Acked-by: Laxman Dewangan
    Acked-by: Maxime Ripard
    Signed-off-by: Linus Walleij

    Jonas Gorski
     

16 Sep, 2015

1 commit

  • Most interrupt flow handlers do not use the irq argument. Those few
    which use it can retrieve the irq number from the irq descriptor.

    Remove the argument.

    Search and replace was done with coccinelle and some extra helper
    scripts around it. Thanks to Julia for her help!

    Signed-off-by: Thomas Gleixner
    Cc: Julia Lawall
    Cc: Jiang Liu

    Thomas Gleixner
     

18 Jul, 2015

1 commit


02 Jul, 2015

1 commit

  • Pull irq fixes from Thomas Gleixner:
    "This contains:

    - a series of fixes for interrupt drivers to prevent a potential race
    when installing a chained interrupt handler

    - a fix for cpumask pointer misuse

    - a fix for using the wrong interrupt number from struct irq_data

    - removal of unused code and outdated comments

    - a few new helper functions which allow us to cleanup the interrupt
    handling code further in 4.3

    I decided against doing the cleanup at the end of this merge window
    and rather do the preparatory steps for 4.3, so we can run the final
    ABI change at the end of the 4.3 merge window with less risk"

    * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (26 commits)
    ARM/LPC32xx: Use irq not hwirq for __irq_set_handler_locked()
    genirq: Implement irq_set_handler_locked()/irq_set_chip_handler_name_locked()
    genirq: Introduce helper irq_desc_get_irq()
    genirq: Remove irq_node()
    genirq: Clean up outdated comments related to include/linux/irqdesc.h
    mn10300: Fix incorrect use of irq_data->affinity
    MIPS/ralink: Fix race in installing chained IRQ handler
    MIPS/pci: Fix race in installing chained IRQ handler
    MIPS/ath25: Fix race in installing chained IRQ handler
    MIPS/ath25: Fix race in installing chained IRQ handler
    m68k/psc: Fix race in installing chained IRQ handler
    avr32/at32ap: Fix race in installing chained IRQ handler
    sh/intc: Fix race in installing chained IRQ handler
    sh/intc: Fix potential race in installing chained IRQ handler
    pinctrl/sun4i: Fix race in installing chained IRQ handler
    pinctrl/samsung: Fix race in installing chained IRQ handler
    pinctrl/samsung: Fix race in installing chained IRQ handler
    pinctrl/exynos: Fix race in installing chained IRQ handler
    pinctrl/st: Fix race in installing chained IRQ handler
    pinctrl/adi2: Fix race in installing chained IRQ handler
    ...

    Linus Torvalds
     

25 Jun, 2015

1 commit

  • Fix a race where a pending interrupt could be received and the handler
    called before the handler's data has been setup, by converting to
    irq_set_chained_handler_and_data().

    Search and conversion was done with coccinelle:

    @@
    expression E1, E2, E3;
    @@
    (
    -if (irq_set_chained_handler(E1, E3) != 0)
    - BUG();
    |
    -irq_set_chained_handler(E1, E3);
    )
    -irq_set_handler_data(E1, E2);
    +irq_set_chained_handler_and_data(E1, E3, E2);

    @@
    expression E1, E2, E3;
    @@
    (
    -if (irq_set_chained_handler(E1, E3) != 0)
    - BUG();
    ...
    |
    -irq_set_chained_handler(E1, E3);
    ...
    )
    -irq_set_handler_data(E1, E2);
    +irq_set_chained_handler_and_data(E1, E3, E2);

    Reported-by: Russell King
    Signed-off-by: Thomas Gleixner
    Cc: Julia Lawall
    Cc: Srinivas Kandagatla
    Cc: Maxime Coquelin
    Cc: Patrice Chotard
    Cc: Linus Walleij
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: kernel@stlinux.com
    Cc: linux-gpio@vger.kernel.org

    Thomas Gleixner
     

10 Jun, 2015

1 commit

  • 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

  • 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
     

25 Mar, 2015

5 commits

  • Great for easily determining which mode a pin is operating in.
    This patch was particularly helpful when debugging a recent GPIO/
    Pinctrl disparity issue.

    Before:
    $ cat /sys/kernel/debug/pinctrl//pinconf-pins
    pin 33 (PIO4[1]):[OE:0,PU:0,OD:0]
    [retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]

    After [GPIO]:
    $ cat /sys/kernel/debug/pinctrl//pinconf-pins
    pin 33 (PIO4[1]):[OE:0,PU:0,OD:0] GPIO
    [retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]

    After [Alt]:
    $ cat /sys/kernel/debug/pinctrl//pinconf-pins
    pin 33 (PIO4[1]):[OE:0,PU:0,OD:0] Alt Fn 2
    [retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]

    Acked-by: Maxime Coquelin
    Signed-off-by: Lee Jones
    Signed-off-by: Linus Walleij

    Lee Jones
     
  • Until now ST's pinconf_dbg_show() call-back has displayed the PIO
    alternate function direction, which is only relevant if a pin is
    operating in an alternate function mode i.e not GPIO mode. If a
    pin is in GPIO mode its direction is both set and status is
    obtained by a completely different/unrelated bunch of registers.

    This change ensures that the correct pin direction is shown, even
    if a pin is operating in GPIO mode.

    Reported-by: Olivier Clergeaud
    Acked-by: Maxime Coquelin
    Signed-off-by: Lee Jones
    Signed-off-by: Linus Walleij

    Lee Jones
     
  • ST's hardware differentiates between GPIO mode and Pinctrl alternate
    functions. When a pin is in GPIO mode, there are dedicated registers
    to set and obtain direction status. However, If a pin's alternate
    function is in use then the direction is set and status is derived
    from a bunch of syscon registers. The issue is; until now there was
    a lack of parity between the two.

    For example:

    Catting the two following information sources could result in
    conflicting information (output has been snipped for simplicity):

    $ cat /sys/kernel/debug/gpio
    GPIOs 32-39, platform/961f080.pin-controller-sbc, PIO4:
    gpio-33 (? ) out hi

    $ cat /sys/kernel/debug/pinctrl//pinconf-pins
    pin 33 (PIO4[1]):[OE:0,PU:0,OD:0]
    [retime:0,invclk:0,clknotdat:0,de:0,rt-clk:0,rt-delay:0]

    In this example GPIO-33 is a GPIO controlled LED, which is set for
    output, as you'd expect. However, when the same information is
    drafted from Pinctrl, it clearly states that OE (Output Enable) is
    not set i.e. the pin is set for input. This is because OE normally
    only represents alternate functions and has no bearing on how the
    pin operates when in Alt-0 (GPIO mode).

    This patch changes the current semantics and provides a parity link
    between the two subsystems. The get_direction() call-back firstly
    determines which function a pin is operating in, then uses the
    appropriate helpers for that mode.

    Reported-by: Olivier Clergeaud
    Acked-by: Maxime Coquelin
    Signed-off-by: Lee Jones
    Signed-off-by: Linus Walleij

    Lee Jones
     
  • st_get_pio_control() will be used by subsequent calls which are
    to be located above its original position. This is required to
    prevent the need for an unnecessary forward-declaration/prototype.

    Acked-by: Maxime Coquelin
    Signed-off-by: Lee Jones
    Signed-off-by: Linus Walleij

    Lee Jones
     
  • This call fetches the numerical function value a specified pin is
    currently operating in. Function zero is more often than not the
    GPIO function. Greater than zero values represent an alternative
    function. You'd need to either look those up in the Device Tree
    sources or the Programmer's Manual.

    Acked-by: Maxime Coquelin
    Signed-off-by: Lee Jones
    Signed-off-by: Linus Walleij

    Lee Jones
     

07 Jan, 2015

2 commits

  • Currently disable_irq() doesn't work for pinctrl-st driver, due to
    missing irq_disable hook in the driver.
    disable_irq() is required only for level-triggered interrupts, which
    is not the case normally.

    Signed-off-by: Pankaj Dev
    Signed-off-by: Patrice Chotard
    Signed-off-by: Linus Walleij

    Patrice CHOTARD
     
  • Using the sysfs inteface to inspect the pins configuration
    the system can walk around a path which acquires the same
    mutex twice.

    On STiH407 platform, for example :
    cat /sys/kernel/debug/pinctrl/920f080.pin-controller-front0/pinconf-pins
    hangs the kernel and never returns.

    With this patch the mutex is temporary freed.

    Signed-off-by: Francesco Virlinzi
    Signed-off-by: Patrice Chotard
    Signed-off-by: Linus Walleij

    Francesco VIRLINZI
     

15 Dec, 2014

1 commit

  • Pull driver core update from Greg KH:
    "Here's the set of driver core patches for 3.19-rc1.

    They are dominated by the removal of the .owner field in platform
    drivers. They touch a lot of files, but they are "simple" changes,
    just removing a line in a structure.

    Other than that, a few minor driver core and debugfs changes. There
    are some ath9k patches coming in through this tree that have been
    acked by the wireless maintainers as they relied on the debugfs
    changes.

    Everything has been in linux-next for a while"

    * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
    Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
    fs: debugfs: add forward declaration for struct device type
    firmware class: Deletion of an unnecessary check before the function call "vunmap"
    firmware loader: fix hung task warning dump
    devcoredump: provide a one-way disable function
    device: Add dev__once variants
    ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
    ath: use seq_file api for ath9k debugfs files
    debugfs: add helper function to create device related seq_file
    drivers/base: cacheinfo: remove noisy error boot message
    Revert "core: platform: add warning if driver has no owner"
    drivers: base: support cpu cache information interface to userspace via sysfs
    drivers: base: add cpu_device_create to support per-cpu devices
    topology: replace custom attribute macros with standard DEVICE_ATTR*
    cpumask: factor out show_cpumap into separate helper function
    driver core: Fix unbalanced device reference in drivers_probe
    driver core: fix race with userland in device_add()
    sysfs/kernfs: make read requests on pre-alloc files use the buffer.
    sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
    fs: sysfs: return EGBIG on write if offset is larger than file size
    ...

    Linus Torvalds
     

21 Oct, 2014

1 commit

  • This change fixes below sparse error,
    drivers/pinctrl/pinctrl-st.c:1515:31: error: incompatible types for operation (>)
    drivers/pinctrl/pinctrl-st.c:1515:31: left side has type void [noderef] *irqmux_base
    drivers/pinctrl/pinctrl-st.c:1515:31: right side has type int

    Cc: Maxime Coquelin
    Cc: Patrice Chotard
    CC: Linus Walleij
    Cc: Srinivas Kandagatla
    Signed-off-by: Pramod Gurav
    Signed-off-by: Linus Walleij

    Pramod Gurav
     

20 Oct, 2014

1 commit


23 Sep, 2014

1 commit


04 Sep, 2014

1 commit

  • 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
     

08 Aug, 2014

1 commit

  • Pull pinctrl updates from Linus Walleij:
    "This is the bulk pin control changes for the v3.17 merge development
    cycle:

    - get rid of the .disable() callback from the driver callback vtable.

    This callback was abused and counterintuitive since a pin or group
    of pins can be said to always be in some setting, and never really
    disabled. We now only enable a certain muxing, and move between
    some certain muxings, we never "disable" a mux setting

    - some janitorial moving the MSM, Samsung and Nomadik and drivers to
    their own subdirectories for a clearer view in the subsystem. This
    will continue

    - kill off the use of the return value from gpiochip_remove(), this
    will be done in parallel in the GPIO subsystem and hopefully not
    trigger too many unchecked return value warnings before we get rid
    of this altogether

    - a huge set of changes and improvements to the Allwinner sunxi
    drivers especially for their latest A23 and A31 SoCs, and some
    ground work for the new sun8i platform family

    - a large set of Rockchip driver improvements adding support for the
    RK3288 SoC

    - advances in migration of older Freescale platforms to pin control,
    especially i.MX1

    - Samsung and Exynos improvements

    - support for the Qualcomm MSM8960 SoC

    - use the gpiolib irqchip helpers for the ST SPEAr and Intel Baytrail
    drivers

    - a bunch of nice janitorial work done with cppcheck"

    * tag 'pinctrl-v3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (61 commits)
    pinctrl: baytrail: Convert to use gpiolib irqchip
    pinctrl: sunxi: number gpio ranges starting from 0
    pinctrl: sunxi: use gpiolib API to mark a GPIO used as an IRQ
    pinctrl: rockchip: add drive-strength control for rk3288
    pinctrl: rockchip: add separate type for rk3288
    pinctrl: rockchip: set is_generic in pinconf_ops
    pinctrl: msm: drop negativity check on unsigned value
    pinctrl: remove all usage of gpio_remove ret val in driver/pinctl
    pinctrl: qcom: Make muxing of gpio function explicit
    pinctrl: nomadik: move all Nomadik drivers to subdir
    pinctrl: samsung: Group all drivers in a sub-dir
    sh-pfc: sh73a0: Introduce the use of devm_regulator_register
    sh-pfc: Add renesas,pfc-r8a7791 to binding documentation
    pinctrl: msm: move all qualcomm drivers to subdir
    pinctrl: msm: Add msm8960 definitions
    pinctrl: samsung: Allow pin value to be initialized using pinfunc
    pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
    pinctrl: exynos: Consolidate irq_chips of GPIO and WKUP EINTs
    pinctrl: samsung: Handle GPIO request and free using pinctrl helpers
    pinctrl: samsung: Decouple direction setting from pinctrl
    ...

    Linus Torvalds
     

16 Jul, 2014

1 commit

  • st_gpio_irqmux_handler() reads the status register to find out
    which banks inside the controller have pending IRQs.
    For each banks having pending IRQs, it calls the corresponding handler.

    Problem is that current code restricts the number of possible banks inside the
    controller to ST_GPIO_PINS_PER_BANK. This define represents the number of pins
    inside a bank, so it shouldn't be used here.

    On STiH407, PIO_FRONT0 controller has 10 banks, so IRQs pending in the two
    last banks (PIO18 & PIO19) aren't handled.

    This patch replace ST_GPIO_PINS_PER_BANK by the number of banks inside the
    controller.

    Cc: Linus Walleij
    Cc: #v3.15+
    Acked-by: Srinivas Kandagatla
    Signed-off-by: Maxime Coquelin
    Signed-off-by: Linus Walleij

    Maxime COQUELIN
     

11 Jul, 2014

4 commits

  • Remove variable that are never used

    This was found using a static code analysis program called cppcheck.

    Signed-off-by: Rickard Strandqvist
    Acked-by: Patrice Chotard
    Signed-off-by: Linus Walleij

    Rickard Strandqvist
     
  • Remove checking if a unsigned is less than zero

    This was found using a static code analysis program called cppcheck.

    Signed-off-by: Rickard Strandqvist
    Acked-by: Srinivas Kandagatla
    Acked-by: Maxime Coquelin
    Signed-off-by: Linus Walleij

    Rickard Strandqvist
     
  • no .irq_set_wake API is available for pinctrl-st driver.
    Add the IRQCHIP_SKIP_SET_WAKE flag to inform irq handler
    not to call this API.

    Signed-off-by: David Paris
    Signed-off-by: Linus Walleij

    David PARIS
     
  • 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
     

22 Apr, 2014

4 commits

  • This patch completes the one that used ARRAY_SIZE for STiH407 and STiH416
    for setting ninput_delays and noutput_delays fields.

    Signed-off-by: Maxime Coquelin
    Signed-off-by: Linus Walleij

    Maxime COQUELIN
     
  • This patch adds const qualifier where applicable.

    Reported-by: Joe Perches
    Signed-off-by: Maxime Coquelin
    Signed-off-by: Linus Walleij

    Maxime COQUELIN
     
  • This lets the gpiolib core handle the irqchip set-up and
    chained IRQ on the primary (behind the mux) IRQ chip in
    the st pinctrl driver.

    Default irq type is set to level low at irqchip add time.

    The v1 was sent by Linus
    (https://lkml.org/lkml/2014/4/4/287).

    Two changes were necessary to make it to work properly
    on STiH416:
    1 - dev reference was not passed to the gpio_chip
    struct, causing a panic.
    2 - gpiochip_irqchip_add passed IRQ_TYPE_NONE as
    default type, which caused lot of warnings at
    init time. I choose IRQ_TYPE_LEVEL_LOW as default.

    Cc: Srinivas Kandagatla
    Cc: Giuseppe Cavallaro
    Signed-off-by: Linus Walleij
    Signed-off-by: Maxime COQUELIN

    Linus Walleij
     
  • In the mass-conversion to the new irqchip callbacks, this
    in-transit IRQ support was missed. Fix it.

    Cc: Srinivas Kandagatla
    Cc: Maxime COQUELIN
    Cc: Giuseppe Cavallaro
    Signed-off-by: Linus Walleij

    Linus Walleij
     

12 Mar, 2014

3 commits