1. 24 Sep, 2018 2 commits
  2. 20 Sep, 2018 8 commits
  3. 17 Sep, 2018 15 commits
  4. 14 Sep, 2018 1 commit
  5. 13 Sep, 2018 6 commits
    • Janusz Krzysztofik's avatar
      gpiolib: Implement fast processing path in get/set array · b17566a6
      Janusz Krzysztofik authored
      Certain GPIO descriptor arrays returned by gpio_get_array() may contain
      information on direct mapping of array members to pins of a single GPIO
      chip in hardware order.  In such cases, bitmaps of values can be passed
      directly from/to the chip's .get/set_multiple() callbacks without
      wasting time on iterations.
      
      Add respective code to gpiod_get/set_array_bitmap_complex() functions.
      Pins not applicable for fast path are processed as before, skipping
      over the 'fast' ones.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b17566a6
    • Janusz Krzysztofik's avatar
      gpiolib: Pass array info to get/set array functions · 77588c14
      Janusz Krzysztofik authored
      In order to make use of array info obtained from gpiod_get_array() and
      speed up processing of arrays matching single GPIO chip layout, that
      information must be passed to get/set array functions.  Extend the
      functions' API with that additional parameter and update all users.
      Pass NULL if a user builds an array itself from single GPIOs.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Peter Korsgaard <peter.korsgaard@barco.com>
      Cc: Peter Rosin <peda@axentia.se>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Rojhalat Ibrahim <imr@rtschenk.de>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Kishon Vijay Abraham I <kishon@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Michael Hennerich <Michael.Hennerich@analog.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Yegor Yefremov <yegorslists@googlemail.com>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      77588c14
    • Janusz Krzysztofik's avatar
      gpiolib: Identify arrays matching GPIO hardware · bf9346f5
      Janusz Krzysztofik authored
      Certain GPIO array lookup results may map directly to GPIO pins of a
      single GPIO chip in hardware order.  If that condition is recognized
      and handled efficiently, significant performance gain of get/set array
      functions may be possible.
      
      While processing a request for an array of GPIO descriptors, identify
      those which represent corresponding pins of a single GPIO chip.  Skip
      over pins which require open source or open drain special processing.
      Moreover, identify pins which require inversion.  Pass a pointer to
      that information with the array to the caller so it can benefit from
      enhanced performance as soon as get/set array functions can accept and
      make efficient use of it.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      bf9346f5
    • Janusz Krzysztofik's avatar
      gpiolib: Pass bitmaps, not integer arrays, to get/set array · b9762beb
      Janusz Krzysztofik authored
      Most users of get/set array functions iterate consecutive bits of data,
      usually a single integer, while processing array of results obtained
      from, or building an array of values to be passed to those functions.
      Save time wasted on those iterations by changing the functions' API to
      accept bitmaps.
      
      All current users are updated as well.
      
      More benefits from the change are expected as soon as planned support
      for accepting/passing those bitmaps directly from/to respective GPIO
      chip callbacks if applicable is implemented.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
      Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Peter Korsgaard <peter.korsgaard@barco.com>
      Cc: Peter Rosin <peda@axentia.se>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Rojhalat Ibrahim <imr@rtschenk.de>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Kishon Vijay Abraham I <kishon@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Michael Hennerich <Michael.Hennerich@analog.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Yegor Yefremov <yegorslists@googlemail.com>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b9762beb
    • Uwe Kleine-König's avatar
      gpiolib: Don't support irq sharing for userspace · fa38869b
      Uwe Kleine-König authored
      This concerns gpio edge detection for GPIO IRQs used from
      userspace for GPIO event listeners.
      
      Trying to work out the right event if it's not sure that the
      examined gpio actually moved is impossible.
      
      Consider two gpios "gpioA" and "gpioB" that share an interrupt.
      gpioA's irq should trigger on any edge, gpioB's on a falling edge.
      If now the common irq fires and both gpio lines are high, there
      are several possibilities that could have happend:
      
       a) gpioA just had a low-to-high edge
       b) gpioB just had a high-to-low-to-high spike
       c) a combination of both a) and b)
      
      While c) is unlikely (in most setups) a) and b) alone are bad
      enough. Currently the code assumes case a) unconditionally and
      doesn't report an event for gpioB. Note that even if there is no
      irq sharing involved a spike for a gpio might not result in an
      event if it's configured to trigger for a single edge only.
      
      The only way to improve this is to drop support for interrupt
      sharing. This way a spike results in an event for the right gpio
      at least. Note that apart from dropping IRQF_SHARED this
      effectively undoes commit df1e76f2
      ("gpiolib: skip unwanted events, don't convert them to opposite edge").
      
      This obviously breaks setups that rely on interrupt sharing,
      but given that this cannot be reliable, this is probably an
      acceptable trade-off.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      [Assuming there are no users of interrupt sharing yet]
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fa38869b
    • Geert Uytterhoeven's avatar
  6. 12 Sep, 2018 2 commits
  7. 11 Sep, 2018 2 commits
  8. 10 Sep, 2018 4 commits
    • Hans Verkuil's avatar
      gpio-bcm-kona: use new req/relres and dis/enable_irq funcs · 1c939cb5
      Hans Verkuil authored
      Since this driver does not use the gpiolib irqchip helpers it will have to
      allocate the irq resources and irq_en/disable itself.
      
      Use the new gpiochip_req/relres_irq helpers to request/release all the
      resources.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: Ray Jui <rjui@broadcom.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      1c939cb5
    • Hans Verkuil's avatar
      gpio/driver.rst: document gpiochip_disable/enable_irq() · 4f8183ae
      Hans Verkuil authored
      Document these new functions.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      4f8183ae
    • Hans Verkuil's avatar
      gpiolib: override irq_enable/disable · 461c1a7d
      Hans Verkuil authored
      When using the gpiolib irqchip helpers install irq_enable/disable
      hooks for the irqchip to ensure that gpiolib knows when the irq
      is enabled or disabled, allowing drivers to disable the irq and then
      use it as an output pin, and later switch the direction to input and
      re-enable the irq.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      461c1a7d
    • Hans Verkuil's avatar
      gpiolib: add flag to indicate if the irq is disabled · 4e9439dd
      Hans Verkuil authored
      GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio
      as an interrupt. This is done when the irq is requested and it marks the
      gpio as in use by an interrupt.
      
      This is problematic for cases where a gpio pin is used as an interrupt
      pin, then, after the irq is disabled, is used as a regular gpio pin.
      Currently it is not possible to do this other than by first freeing
      the interrupt so gpiochip_unlock_as_irq is called, since an attempt to
      switch the gpio direction for output will fail since gpiolib believes
      that the gpio is in use for an interrupt and it does not know that it
      the irq is actually disabled.
      
      There are currently two drivers that would like to be able to do this:
      the tda998x_drv.c driver where a regular gpio pin needs to be temporarily
      reconfigured as an interrupt pin during CEC calibration, and the cec-gpio
      driver where you want to configure the gpio pin as an interrupt while
      waiting for traffic over the CEC bus, or as a regular pin when receiving or
      transmitting a CEC message.
      
      The solution is to add a new flag that is set when the irq is enabled,
      and have gpiod_direction_output check for that flag.
      
      We also add functions that drivers that do not use GPIOLIB_IRQCHIP
      can call when they enable/disable the irq.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      4e9439dd