1. 17 Sep, 2018 6 commits
  2. 14 Sep, 2018 1 commit
  3. 13 Sep, 2018 2 commits
    • 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
  4. 12 Sep, 2018 2 commits
  5. 11 Sep, 2018 2 commits
  6. 10 Sep, 2018 16 commits
  7. 04 Sep, 2018 7 commits
  8. 31 Aug, 2018 1 commit
  9. 30 Aug, 2018 3 commits
    • Justin Chen's avatar
      gpio: brcmstb: allow 0 width GPIO banks · bfba223d
      Justin Chen authored
      Sometimes we have empty banks within the GPIO block. This commit allows
      proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
      incrementing the bank and number of GPIOs, but not initializing them.
      This will mean a call into the non-existent GPIOs will return an error.
      
      Also remove "GPIO registered" dev print. This information is misleading
      since the incremented banks and gpio_base do not reflect the actual GPIOs
      that get initialized. We leave this information out since it is already
      printed with dev_dbg.
      Signed-off-by: default avatarJustin Chen <justinpopo6@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      bfba223d
    • Linus Walleij's avatar
      gpio: ftgpio: Support debounce timer · 36f3f19a
      Linus Walleij authored
      The FTGPIO010 has a debounce timer or rather prescaler that
      will affect interrupts fireing off the block. We can support
      this to get proper debounce on e.g. keypresses.
      
      Since the same prescaler is used across all GPIO lines of
      the silicon block, we need to bail out if the prescaler is
      already set and in use by another line.
      
      If the prescaler is already set to what we need, fine, we
      reuse it. This happens more often than not when the same
      debounce time is set for several GPIO keys, so we support
      that usecase easily with this code.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      36f3f19a
    • Linus Walleij's avatar
      gpio: ftgpio: Support optional silicon clock · da02d794
      Linus Walleij authored
      The GPIO silicon is clocked with a PCLK (peripheral clock)
      on all systems, however not all platforms model it and include
      it in e.g. the device tree, so add clock handling but make it
      optional so we bail out safely if it is e.g. always on.
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      da02d794