1. 11 Sep, 2019 1 commit
  2. 10 Sep, 2019 1 commit
  3. 09 Sep, 2019 3 commits
  4. 28 Aug, 2019 2 commits
  5. 23 Aug, 2019 1 commit
  6. 16 Aug, 2019 1 commit
  7. 14 Aug, 2019 1 commit
  8. 28 Jul, 2019 1 commit
  9. 22 Jul, 2019 1 commit
    • Michael Wu's avatar
      gpiolib: fix incorrect IRQ requesting of an active-low lineevent · 223ecaf1
      Michael Wu authored
      When a pin is active-low, logical trigger edge should be inverted to match
      the same interrupt opportunity.
      
      For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in
      ACTIVE_LOW case, the button pushed triggers rising edge. For user space the
      IRQ requesting doesn't need to do any modification except to configuring
      GPIOHANDLE_REQUEST_ACTIVE_LOW.
      
      For example, we want to catch the event when the button is pushed. The
      button on the original board drives level to be low when it is pushed, and
      drives level to be high when it is released.
      
      In user space we can do:
      
      	req.handleflags = GPIOHANDLE_REQUEST_INPUT;
      	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
      
      	while (1) {
      		read(fd, &dat, sizeof(dat));
      		if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE)
      			printf("button pushed\n");
      	}
      
      Run the same logic on another board which the polarity of the button is
      inverted; it drives level to be high when pushed, and level to be low when
      released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:
      
      	req.handleflags = GPIOHANDLE_REQUEST_INPUT |
      		GPIOHANDLE_REQUEST_ACTIVE_LOW;
      	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
      
      At the result, there are no any events caught when the button is pushed.
      By the way, button releasing will emit a "falling" event. The timing of
      "falling" catching is not expected.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichael Wu <michael.wu@vatics.com>
      Tested-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      223ecaf1
  10. 16 Jul, 2019 1 commit
    • Linus Walleij's avatar
      Revert "gpio/spi: Fix spi-gpio regression on active high CS" · da7f1349
      Linus Walleij authored
      This reverts commit fbbf145a.
      
      It seems I was misguided in my fixup, which was working at the
      time but did not work on the final v5.2.
      
      The patch tried to avoid a quirk the gpiolib code not to treat
      "spi-gpio" CS gpios "special" by enforcing them to be active
      low, in the belief that since the "spi-gpio" driver was
      parsing the device tree on its own, it did not care to inspect
      the "spi-cs-high" attribute on the device nodes.
      
      That's wrong. The SPI core was inspecting them inside the
      of_spi_parse_dt() funtion and setting SPI_CS_HIGH on the
      nodes, and the driver inspected this flag when driving the
      line.
      
      As of now, the core handles the GPIO and it will consistently
      set the GPIO descriptor to 1 to enable CS, strictly requireing
      the gpiolib to invert it. And the gpiolib should indeed
      enforce active low on the CS line.
      
      Device trees should of course put the right flag on the GPIO
      handles, but it used to not matter. If we don't enforce active
      low on "gpio-gpio" we may run into ABI backward compatibility
      issues, so revert this.
      
      Cc: linux-spi@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20190715204529.9539-1-linus.walleij@linaro.org
      da7f1349
  11. 15 Jul, 2019 5 commits
  12. 06 Jul, 2019 2 commits
  13. 04 Jul, 2019 6 commits
  14. 03 Jul, 2019 6 commits
  15. 02 Jul, 2019 1 commit
    • Linus Walleij's avatar
      gpio/spi: Fix spi-gpio regression on active high CS · fbbf145a
      Linus Walleij authored
      I ran into an intriguing bug caused by
      commit ""spi: gpio: Don't request CS GPIO in DT use-case"
      affecting all SPI GPIO devices with an active high
      chip select line.
      
      The commit switches the CS gpio handling over to the GPIO
      core, which will parse and handle "cs-gpios" from the OF
      node without even calling down to the driver to get the
      job done.
      
      However the GPIO core handles the standard bindings in
      Documentation/devicetree/bindings/spi/spi-controller.yaml
      that specifies that active high CS needs to be specified
      using "spi-cs-high" in the DT node.
      
      The code in drivers/spi/spi-gpio.c never respected this
      and never tried to inspect subnodes to see if they contained
      "spi-cs-high" like the gpiolib OF quirks does. Instead the
      only way to get an active high CS was to tag it in the
      device tree using the flags cell such as
      cs-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;
      
      This alters the quirks to not inspect the subnodes of SPI
      masters on "spi-gpio" for the standard attribute "spi-cs-high",
      making old device trees work as expected.
      
      This semantic is a bit ambigous, but just allowing the
      flags on the GPIO descriptor to modify polarity is what
      the kernel at large mostly uses so let's encourage that.
      
      Fixes: 249e2632 ("spi: gpio: Don't request CS GPIO in DT use-case")
      Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-spi@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fbbf145a
  16. 27 Jun, 2019 7 commits