1. 11 4月, 2013 3 次提交
  2. 27 3月, 2013 1 次提交
  3. 06 3月, 2013 2 次提交
  4. 12 2月, 2013 1 次提交
  5. 29 11月, 2012 1 次提交
  6. 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
  7. 16 10月, 2012 1 次提交
  8. 13 9月, 2012 1 次提交
  9. 11 9月, 2012 2 次提交
  10. 18 7月, 2012 1 次提交
  11. 04 7月, 2012 1 次提交
    • J
      gpio/omap: fix invalid context restore of gpio bank-0 · 7b86cef3
      Jon Hunter 提交于
      Currently the gpio _runtime_resume/suspend functions are calling the
      get_context_loss_count() platform function if the function is populated for
      a gpio bank. This function is used to determine if the gpio bank logic state
      needs to be restored due to a power transition. This function will be populated
      for all banks, but it should only be called for banks that have the
      "loses_context" variable set. It is pointless to call this if loses_context is
      false as we know the context will never be lost and will not need restoring.
      
      For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will
      never lose context. We found that the get_context_loss_count() was being called
      for bank-0 during the probe and returning 1 instead of 0 indicating that the
      context had been lost. This was causing the context restore function to be
      called at probe time for this bank and because the context had never been saved,
      was restoring an invalid state. This ultimately resulted in a crash [1].
      
      This issue is a regression that was exposed by commit 1b128703 (gpio/omap: fix
      missing check in *_runtime_suspend()).
      
      There are multiple bugs here that need to be addressed ...
      
      1. Why the always-on power domain returns a context loss count of 1? This needs
         to be fixed in the power domain code [2]. However, the gpio driver should not
         assume the loss count is 0 to begin with.
      2. The omap gpio driver should never be calling get_context_loss_count for a
         gpio bank in a always-on domain. This is pointless and adds unneccessary
         overhead.
      3. The OMAP gpio driver assumes that the initial power domain context loss count
         will be 0 at the time the gpio driver is probed. However, it could be
         possible that this is not the case and an invalid context restore could be
         performed during the probe. To avoid this only populate the
         get_context_loss_count() function pointer after the initial call to
         pm_runtime_get() has occurred. This will ensure that the first
         pm_runtime_put() initialised the loss count correctly.
      
      This patch addresses issues 2 and 3 above.
      
      [1] http://marc.info/?l=linux-omap&m=134065775323775&w=2
      [2] http://marc.info/?l=linux-omap&m=134100413303810&w=2
      
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      Cc: Franky Lin <frankyl@broadcom.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: NeilBrown <neilb@suse.de>
      Reported-by: NFranky Lin <frankyl@broadcom.com>
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NFranky Lin <frankyl@broadcom.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      7b86cef3
  12. 27 6月, 2012 1 次提交
    • G
      gpio/omap: fix irq loss while in idle with debounce on · 9e303f22
      Grazvydas Ignotas 提交于
      It seems that currently GPIO module is not working correctly during idle
      when debounce is enabled - the system almost never responds to button
      presses (observed on OMAP3530 ES2.1 and OMAP3630 ES1.2 pandora boards).
      Even though wakeups are probably working, it seems that the GPIO module
      itself is unable to detect input events and generate interrupts.
      OMAP35x TRM also states that:
        "If the debounce clock is inactive, the debounce cell gates all
         input signals and thus cannot be used."
      
      So whenever we are disabling debounce clocks (for PM or other reasons),
      be sure the module's debounce feature is disabled too.
      
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      9e303f22
  13. 18 5月, 2012 2 次提交
    • K
      gpio/omap: (re)fix wakeups on level-triggered GPIOs · b3c64bc3
      Kevin Hilman 提交于
      commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend())
      broke wakeups on level-triggered GPIOs by adding the enabled
      non-wakeup GPIO check before the workaround that enables wakeups
      on level-triggered IRQs, effectively disabling that workaround.
      
      To fix, move the enabled non-wakeup GPIO check after the
      level-triggered IRQ workaround.
      Reported-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Tested-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      b3c64bc3
    • K
      gpio/omap: fix broken context restore for non-OFF mode transitions · 22770de1
      Kevin Hilman 提交于
      The fix in commit 1b128703 (gpio/omap: fix missing check in
      *_runtime_suspend()) exposed another bug in the context restore path.
      
      Currently, the per-bank context restore happens whenever the context
      loss count is different in runtime suspend and runtime resume *and*
      whenever the per-bank contex_loss_count == 0:
      
      	if (context_lost_cnt_after != bank->context_loss_count ||
      					!context_lost_cnt_after) {
      		omap_gpio_restore_context(bank);
      
      Restoring context when the context_lost_cnt_after == 0 is clearly
      wrong, since this will be true until the first off-mode transition
      (which could be never, if off-mode is never enabled.)  This check
      causes the context to be restored on *every* runtime PM transition.
      
      Before commit 1b128703 (gpio/omap: fix missing check in
      *_runtime_suspend()), this code was never executed in non-OFF mode, so
      there were never spurious context restores happening.  After that
      change though, spurious context restores could happen.
      
      To fix, simply remove the !context_lost_cnt_after check. It is not
      needed.
      
      This bug was found when noticing that the smc911x NIC on 3530/Overo
      was not working, and git bisect tracked it down to this patch.  It
      seems that the spurious context restore was causing the smsc911x to
      not be properly probed on this platform.
      Tested-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      22770de1
  14. 12 5月, 2012 7 次提交
  15. 10 5月, 2012 1 次提交
    • T
      gpio/omap: fix incorrect initialization of omap_gpio_mod_init · 6edd94db
      Tarun Kanti DebBarma 提交于
      Initialization of irqenable, irqstatus registers is the common
      operation done in this function for all OMAP platforms, viz. OMAP1,
      OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced
      wrongly to take care of OMAP2+ platforms were overwriting initially
      programmed OMAP1 value breaking functionality on OMAP1.
      Somehow incorrect assumption was made that each _gpio_rmw()'s were
      mutually exclusive. On close observation it is found that the first
      _gpio_rmw() which is supposedly done to take care of OMAP1 platform
      is generic enough and takes care of OMAP2+ platform as well.
      Therefore remove the latter _gpio_rmw() to irqenable as they are
      redundant now.
      
      Writing to ctrl and debounce_en registers for OMAP2+ platforms are
      modified to match the original(pre-cleanup) code where the registers
      are initialized with 0. In the cleanup series since we are using
      _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading
      and writing the same values to ctrl and debounce_en. This is not an
      issue for debounce_en register because it has 0x0 as the default value.
      But in the case of ctrl register the default value is 0x2 (GATINGRATIO
       = 0x1) so that we end up writing 0x2 instead of intended 0 value.
      Therefore changing back to __raw_writel() as this is sufficient for
      this case besides simpler to understand.
      
      Also, change irqstatus initalization logic that avoids comparison
      with bool, besides making it fit in a single line.
      
      Cc: stable@vger.kernel.org
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Reported-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      6edd94db
  16. 21 3月, 2012 2 次提交
    • T
      gpio/omap: fix redundant decoding of gpio offset · 7fcca715
      Tarun Kanti DebBarma 提交于
      In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
      un-necessary operation to compute gpio mask. The gpio offset passed
      to gpio_get() is sufficient to do that.
      
      Here is Russell's original comment:
      Can someone explain to me this:
      
      static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
      {
             void __iomem *reg = bank->base + bank->regs->datain;
      
             return (__raw_readl(reg) & GPIO_BIT(bank, gpio)) != 0;
      }
      
      static int gpio_get(struct gpio_chip *chip, unsigned offset)
      {
             struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
             void __iomem *reg = bank->base;
             int gpio = chip->base + offset;
             u32 mask = GPIO_BIT(bank, gpio);
      
             if (gpio_is_input(bank, mask))
                     return _get_gpio_datain(bank, gpio);
             else
                     return _get_gpio_dataout(bank, gpio);
      }
      
      Given that bank->width on OMAP is either 32 or 16, and GPIO numbers for
      any GPIO chip are always aligned to 32 or 16, why does this code bother
      adding the chips base gpio number and then modulo the width?
      
      Surely this means if - for argument sake - you registered a GPIO chip
      with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
      bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
      chip 1 bit 0..7.
      
      However, if you registered a GPIO chip with 16 lines first, it would
      mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
      chip 1 bit 0..15.
      
      Surely this kind of behaviour is not intended?
      
      Is there a reason why the bitmask can't just be (1 << offset) where
      offset is passed into these functions as GPIO number - chip->base ?
      Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
      Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      7fcca715
    • T
      gpio/omap: fix incorrect update to context.irqenable1 · 2a900eb7
      Tarun Kanti DebBarma 提交于
      In _enable_gpio_irqbank() when bank->regs->set_irqenable is TRUE,
      gpio_mask can be directly set by writing to set_irqenable register
      without overwriting current value. In order to ensure the same is
      stored in context.irqenable1, we must avoid overwriting it with
      gpio_mask at the end of the function. Instead, update irqenable1
      appropriately by OR'ing with gpio_mask.
      For the case where bank->regs->set_irqenable is FALSE, irqenable1
      can be directly overwritten with 'l' which holds correct computed
      value.
              if (bank->regs->set_irqenable) {
                      reg += bank->regs->set_irqenable;
                      l = gpio_mask;
              } else {
                      reg += bank->regs->irqenable;
                      l = __raw_readl(reg);
                      if (bank->regs->irqenable_inv)
                              l &= ~gpio_mask;
                      else
                              l |= gpio_mask;
              }
      
      Make similar change for _disable_gpio_irqbank().
      Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      2a900eb7
  17. 20 3月, 2012 5 次提交
  18. 13 3月, 2012 2 次提交
    • T
      gpio/omap: Fix section warning for omap_mpuio_alloc_gc() · 8805f410
      Tony Lindgren 提交于
      Make omap_mpuio_alloc_gc() __devinit as omap_gpio_chip_init()
      is __devinit. Otherwise we get:
      
      WARNING: vmlinux.o(.devinit.text+0xa10): Section mismatch in reference
      from the function omap_gpio_chip_init() to the function .init.text:omap_mpuio_alloc_gc()
      The function __devinit omap_gpio_chip_init() references
      a function __init omap_mpuio_alloc_gc().
      If omap_mpuio_alloc_gc is only used by omap_gpio_chip_init then
      annotate omap_mpuio_alloc_gc with a matching annotation.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      8805f410
    • K
      gpio/omap: fix wakeups on level-triggered GPIOs · 68942edb
      Kevin Hilman 提交于
      While both level- and edge-triggered GPIOs are capable of generating
      interrupts, only edge-triggered GPIOs are capable of generating a
      module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.)
      
      In order to ensure that devices using level-triggered GPIOs as
      interrupts can also cause wakeups (e.g. from idle), this patch enables
      edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO
      bank is runtime-suspended (which also happens during idle.)
      
      This fixes a problem found in GPMC-connected network cards with GPIO
      interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting
      with NFSroot was very slow since the GPIO IRQs used by the NIC were
      not generating PRCM wakeups, and thus not waking the system from idle.
      NOTE: until v3.3, this boot-time problem was somewhat masked because
      the UART init prevented WFI during boot until the full serial driver
      was available.  Preventing WFI allowed regular GPIO interrupts to fire
      and this problem was not seen.  After the UART runtime PM cleanups, we
      no longer avoid WFI during boot, so GPIO IRQs that were not causing
      wakeups resulted in very slow IRQ response times.
      
      Tested on platforms using level-triggered GPIOs for network IRQs using
      the SMSC911x NIC: 3530/Overo and 3630/Zoom3.
      Reported-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      68942edb
  19. 06 3月, 2012 4 次提交
  20. 25 2月, 2012 1 次提交