1. 27 3月, 2015 1 次提交
  2. 10 3月, 2015 1 次提交
  3. 26 1月, 2015 1 次提交
    • T
      gpio: omap: Fix bad device access with setup_irq() · 3d009c8c
      Tony Lindgren 提交于
      Similar to omap_gpio_irq_type() let's make sure that the GPIO
      is usable as an interrupt if the platform init code did not
      call gpio_request(). Otherwise we can get invalid device access
      after setup_irq():
      
      WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340()
      44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access
      ...
      [<c05f21e4>] (__irq_svc) from [<c05f1974>] (_raw_spin_unlock_irqrestore+0x34/0x44)
      [<c05f1974>] (_raw_spin_unlock_irqrestore) from [<c00914a8>] (__setup_irq+0x244/0x530)
      [<c00914a8>] (__setup_irq) from [<c00917d4>] (setup_irq+0x40/0x8c)
      [<c00917d4>] (setup_irq) from [<c0039c8c>] (omap_system_dma_probe+0x1d4/0x2b4)
      [<c0039c8c>] (omap_system_dma_probe) from [<c03b2200>] (platform_drv_probe+0x44/0xa4)
      ...
      
      We can fix this the same way omap_gpio_irq_type() is handling it.
      
      Note that the long term solution is to change the gpio-omap driver
      to handle the banks as separate driver instances. This will allow
      us to rely on just runtime PM for tracking the bank specific state.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Javier Martinez Canillas <javier@dowhile0.org>
      Cc: Kevin Hilman <khilman@kernel.org>
      Cc: Santosh Shilimkar <ssantosh@kernel.org>
      Tested-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3d009c8c
  4. 04 12月, 2014 1 次提交
  5. 29 10月, 2014 1 次提交
  6. 23 9月, 2014 2 次提交
  7. 09 7月, 2014 3 次提交
  8. 16 5月, 2014 1 次提交
  9. 04 5月, 2014 1 次提交
  10. 29 4月, 2014 4 次提交
  11. 24 2月, 2014 1 次提交
  12. 25 11月, 2013 1 次提交
  13. 16 10月, 2013 1 次提交
  14. 01 10月, 2013 2 次提交
  15. 16 8月, 2013 2 次提交
  16. 31 7月, 2013 3 次提交
  17. 21 7月, 2013 3 次提交
  18. 26 6月, 2013 1 次提交
  19. 17 6月, 2013 1 次提交
  20. 14 5月, 2013 1 次提交
    • J
      gpio/omap: ensure gpio context is initialised · 352a2d5b
      Jon Hunter 提交于
      Commit a2797bea (gpio/omap: force restore if context loss is not
      detectable) broke gpio support for OMAP when booting with device-tree
      because a restore of the gpio context being performed without ever
      initialising the gpio context. In other words, the context restored was
      bad.
      
      This problem could also occur in the non device-tree case, however, it
      is much less likely because when booting without device-tree we can
      detect context loss via a platform specific API and so context restore
      is performed less often.
      
      Nevertheless we should ensure that the gpio context is initialised
      on the first pm-runtime resume for gpio banks that could lose their
      state regardless of whether we are booting with device-tree or not.
      
      The context loss count was being initialised on the first pm-runtime
      suspend following a resume, by populating the get_count_loss_count()
      function pointer after the first pm-runtime resume. To make the code
      more readable and logical, initialise the context loss count on the
      first pm-runtime resume if the context is not yet valid.
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      352a2d5b
  21. 11 4月, 2013 4 次提交
  22. 27 3月, 2013 2 次提交
  23. 06 3月, 2013 2 次提交