1. Feb 16, 2012
    • Viresh Kumar's avatar
      gpio/gpio-pl061: No need of thaw and poweroff routines for hibernate · 6e33aced
      Viresh Kumar authored
      
      
      pl061 uses same routines for suspend/freeze/poweroff and resume/thaw/restore.
      We are only saving and restoring register values on these routines.
      
      During hibernation, in freeze() we take a snapshot of gpio registers. In thaw()
      we don't actually need to restore these registers, as power was never shut down
      till now. Similarly, in poweroff() we don't need to take snapshot of these
      registers again, as it was done during freeze() and by now the image is already
      saved on disk.
      
      This patch passes poweroff() and thaw() routines as NULL to avoid this extra
      work done.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@st.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      6e33aced
    • Ming Lei's avatar
      Fix circular locking dependency (3.3-rc2) · 864533ce
      Ming Lei authored
      
      
      Hi,
      
      On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
      > Hi guys,
      >
      > I have just triggered the folllowing:
      >
      > [   84.860321] ======================================================
      > [   84.860321] [ INFO: possible circular locking dependency detected ]
      > [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
      > [   84.860321] -------------------------------------------------------
      > [   84.860321] bash/949 is trying to acquire lock:
      > [   84.860321]  (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
      > [   84.860321]
      > [   84.860321] but task is already holding lock:
      > [   84.860321]  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
      > [   84.911468]
      > [   84.911468] which lock already depends on the new lock.
      > [   84.911468]
      > [   84.920043]
      > [   84.920043] the existing dependency chain (in reverse order) is:
      > [   84.920043]
      > [   84.927886] -> #1 (s_active#22){++++.+}:
      > [   84.927886]        [<c008f640>] check_prevs_add+0xdc/0x150
      > [   84.927886]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
      > [   84.927886]        [<c0090cdc>] __lock_acquire+0x49c/0x980
      > [   84.951660]        [<c0091838>] lock_acquire+0x98/0x100
      > [   84.951660]        [<c016a8e8>] sysfs_deactivate+0xb0/0x100
      > [   84.962982]        [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
      > [   84.962982]        [<c016b8bc>] sysfs_remove_dir+0x84/0x98
      > [   84.962982]        [<c02590d8>] kobject_del+0x10/0x78
      > [   84.974670]        [<c02c29e8>] device_del+0x140/0x170
      > [   84.974670]        [<c02c2a24>] device_unregister+0xc/0x18
      > [   84.985382]        [<c0276894>] gpio_unexport+0xbc/0xdc
      > [   84.985382]        [<c02768c8>] gpio_free+0x14/0xfc
      > [   85.001708]        [<c0276a28>] unexport_store+0x78/0x8c
      > [   85.001708]        [<c02c5af8>] class_attr_store+0x18/0x24
      > [   85.007293]        [<c0169990>] sysfs_write_file+0x100/0x184
      > [   85.018981]        [<c0109d48>] vfs_write+0xb4/0x148
      > [   85.018981]        [<c0109fd0>] sys_write+0x40/0x70
      > [   85.018981]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
      > [   85.035003]
      > [   85.035003] -> #0 (sysfs_lock){+.+.+.}:
      > [   85.035003]        [<c008f54c>] check_prev_add+0x680/0x698
      > [   85.035003]        [<c008f640>] check_prevs_add+0xdc/0x150
      > [   85.052093]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
      > [   85.052093]        [<c0090cdc>] __lock_acquire+0x49c/0x980
      > [   85.052093]        [<c0091838>] lock_acquire+0x98/0x100
      > [   85.069885]        [<c047e280>] mutex_lock_nested+0x3c/0x2f4
      > [   85.069885]        [<c0275358>] gpio_value_store+0x24/0xcc
      > [   85.069885]        [<c02c18dc>] dev_attr_store+0x18/0x24
      > [   85.087158]        [<c0169990>] sysfs_write_file+0x100/0x184
      > [   85.087158]        [<c0109d48>] vfs_write+0xb4/0x148
      > [   85.098297]        [<c0109fd0>] sys_write+0x40/0x70
      > [   85.098297]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
      > [   85.109069]
      > [   85.109069] other info that might help us debug this:
      > [   85.109069]
      > [   85.117462]  Possible unsafe locking scenario:
      > [   85.117462]
      > [   85.117462]        CPU0                    CPU1
      > [   85.128417]        ----                    ----
      > [   85.128417]   lock(s_active#22);
      > [   85.128417]                                lock(sysfs_lock);
      > [   85.128417]                                lock(s_active#22);
      > [   85.142486]   lock(sysfs_lock);
      > [   85.151794]
      > [   85.151794]  *** DEADLOCK ***
      > [   85.151794]
      > [   85.151794] 2 locks held by bash/949:
      > [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
      > [   85.170349]  #1:  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
      > [   85.170349]
      > [   85.178588] stack backtrace:
      > [   85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
      > [   85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
      > [   85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
      > [   85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
      > [   85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
      > [   85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
      > [   85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
      > [   85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
      > [   85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
      > [   85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
      > [   85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
      > [   85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
      > [   85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
      > -bash: echo: write error: Operation not permitted
      >
      > the way to trigger is:
      >
      > root@legolas:~# cd /sys/class/gpio/
      > root@legolas:/sys/class/gpio# echo 2 > export
      > root@legolas:/sys/class/gpio# echo 2 > unexport
      > root@legolas:/sys/class/gpio# echo 2 > export
      > root@legolas:/sys/class/gpio# cd gpio2/
      > root@legolas:/sys/class/gpio/gpio2# echo 1 > value
      
      Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
      fix the problem.
      
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      864533ce
  2. Feb 06, 2012
  3. Feb 04, 2012
    • Sebastian Andrzej Siewior's avatar
      gpio: Add a driver for Sodaville GPIO controller · b43ab901
      Sebastian Andrzej Siewior authored
      
      
      Sodaville has GPIO controller behind the PCI bus. To my suprissed it is
      not the same as on PXA.
      
      The interrupt & gpio chip can be referenced from the device tree like
      from any other driver. Unfortunately the driver which uses the gpio
      interrupt has to use irq_of_parse_and_map() instead of
      platform_get_irq(). The problem is that the platform device (which is
      created from the device tree) is most likely created before the
      interrupt chip is registered and therefore irq_of_parse_and_map() fails.
      
      In theory the driver works as module. In reality most of the irq
      functions are not exported to modules and it is possible that _this_
      module is unloaded while the provided irqs are still in use.
      
      Signed-off-by: default avatarHans J. Koch <hjk@linutronix.de>
      [torbenh@linutronix.de: make it work after the irq namespace cleanup,
      	                add some device tree entries.]
      Signed-off-by: default avatarTorben Hohn <torbenh@linutronix.de>
      [bigeasy@linutronix.de: convert to generic irq & gpio chip]
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      [grant.likely@secretlab.ca: depend on x86 to avoid irq_domain breakage]
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      b43ab901
  4. Jan 30, 2012
  5. Jan 20, 2012
  6. Jan 19, 2012
  7. Jan 18, 2012