1. 29 11月, 2012 1 次提交
  2. 07 11月, 2012 1 次提交
  3. 31 10月, 2012 1 次提交
  4. 28 10月, 2012 1 次提交
    • J
      gpio/omap: fix off-mode bug: clear debounce settings on free/reset · c9c55d92
      Jon Hunter 提交于
      This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
      clock enable mask on free/reset". The title has been updated slightly to
      reflect (what should be) the final fix.
      
      When a GPIO is freed or shutdown, we need to ensure that any debounce settings
      are cleared and if the GPIO is the only GPIO in the bank that is currently
      using debounce, then disable the debounce clock as well to save power.
      
      Currently, the debounce settings are not cleared on a GPIO free or shutdown and
      so during a context restore on subsequent off-mode transition, the previous
      debounce values are restored from the shadow copies (bank->context.debounce*)
      leading to mismatch state between driver state and hardware state.
      
      This was discovered when board code was doing
      
        gpio_request_one()
        gpio_set_debounce()
        gpio_free()
      
      which was leaving the GPIO debounce settings in a confused state.  If that GPIO
      bank is subsequently used with off-mode enabled, bogus state would be restored,
      leaving GPIO debounce enabled which then prevented the CORE powerdomain from
      transitioning.
      
      To fix this, introduce a new function called _clear_gpio_debounce() to clear
      any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
      last debounce-enabled GPIO in the bank, the debounce will also be cut.
      
      Please note that we cannot use _gpio_dbck_disable() to disable the debounce
      clock because this has been specifically created for the gpio suspend path
      and is intended to shutdown the debounce clock while debounce is enabled.
      
      Special thanks to Kevin Hilman for root causing the bug. This fix is a
      collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
      Santosh Shilimkar.
      
      Testing:
      - This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
        enabling debounce and then freeing the gpio and checking the register
        contents, the saved register context and the debounce clock state.
      - Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
        ads7846 touchscreen in its board file using the above sequence, and so was
        failing off-mode tests in dynamic idle. Verified that off-mode tests are
        passing with this patch.
      
      V5 changes:
      - Corrected author
      Reported-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c9c55d92
  5. 26 10月, 2012 1 次提交
  6. 24 10月, 2012 1 次提交
  7. 18 10月, 2012 1 次提交
  8. 17 10月, 2012 1 次提交
  9. 16 10月, 2012 1 次提交
  10. 01 10月, 2012 1 次提交
    • A
      gpio: pcf857x: select IRQ_DOMAIN · 901acf5b
      Arnd Bergmann 提交于
      Patch 6e20a0a4 "gpio: pcf857x: enable gpio_to_irq() support"
      added IRQ domain support to the pcf857x driver, but some configurations
      (e.g. davinci_all_defconfig) don't already enable CONFIG_IRQ_DOMAIN.
      
      Always selecting it from the Kconfig in this case is what other
      such drivers do as well, and avoids these build errors:
      
      Without this patch, building davinci_all_defconfig results in:
      
      drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_to_irq':
      drivers/gpio/gpio-pcf857x.c:167:2: error: implicit declaration of function 'irq_create_mapping'
      drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_demux_work':
      drivers/gpio/gpio-pcf857x.c:183:3: error: implicit declaration of function 'irq_find_mapping'
      drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_cleanup':
      drivers/gpio/gpio-pcf857x.c:218:3: error: implicit declaration of function 'irq_domain_remove'
      drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_init':
      drivers/gpio/gpio-pcf857x.c:230:2: error: implicit declaration of function 'irq_domain_add_linear'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      901acf5b
  11. 30 9月, 2012 1 次提交
  12. 25 9月, 2012 1 次提交
  13. 22 9月, 2012 1 次提交
    • T
      gpio: introduce gpio-mvebu driver for Marvell SoCs · fefe7b09
      Thomas Petazzoni 提交于
      This driver aims at replacing the arch/arm/plat-orion/gpio.c driver,
      and is designed to be compatible with all Marvell EBU SoCs: Orion,
      Kirkwood, Dove, Armada 370/XP and Discovery.
      
      It has been successfully tested on Dove and Armada XP at the moment.
      
      Compared to the plat-orion driver, this new driver has the following
      added benefits:
      
       *) Support for Armada 370 and Armada XP
       *) It is integrated with the mvebu pinctrl driver so that GPIO pins
          are properly muxed, and the GPIO driver knows which GPIO pins are
          output-only or input-only.
       *) Properly placed in drivers/gpio
       *) More extensible mechanism to support platform differences. The
          plat-orion driver uses a simple mask-offset DT property, which
          works fine for Discovery MV78200 but not for Armada XP. The new
          driver uses different compatible strings to identify the different
          variants of the GPIO controllers.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NAndrew Lunn <andrew@lunn.ch>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      fefe7b09
  14. 21 9月, 2012 1 次提交
  15. 19 9月, 2012 4 次提交
  16. 14 9月, 2012 1 次提交
    • J
      gpio: gpio-ich: Share ownership of GPIO groups · 4f600ada
      Jean Delvare 提交于
      The ICH chips have their GPIO pins organized in 2 or 3 independent
      groups of 32 GPIO pins. It can happen that the ACPI BIOS wants to make
      use of pins in one group, preventing the OS to access these. This does
      not prevent the OS from accessing the other group(s).
      
      This is the case for example on my Asus Z8NA-D6 board. The ACPI BIOS
      wants to control GPIO 18 (group 1), while I (the OS) need to control
      GPIO 52 and 53 (group 2) for SMBus multiplexing.
      
      So instead of checking for ACPI resource conflict on the whole I/O
      range, check on a per-group basis, and consider it a success if at
      least one of the groups is available for the OS to use.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Peter Tyser <ptyser@xes-inc.com>
      Cc: Aaron Sierra <asierra@xes-inc.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      4f600ada
  17. 13 9月, 2012 5 次提交
  18. 12 9月, 2012 2 次提交
  19. 11 9月, 2012 3 次提交
  20. 08 9月, 2012 5 次提交
  21. 07 9月, 2012 3 次提交
  22. 06 9月, 2012 2 次提交
  23. 04 9月, 2012 1 次提交