1. 25 10月, 2010 3 次提交
  2. 30 9月, 2010 3 次提交
    • G
      of/i2c: Fix module load order issue caused by of_i2c.c · 925bb9c6
      Grant Likely 提交于
      Commit 959e85f7, "i2c: add OF-style registration and binding" caused a
      module dependency loop where of_i2c.c calls functions in i2c-core, and
      i2c-core calls of_i2c_register_devices() in of_i2c.  This means that
      when i2c support is built as a module when CONFIG_OF is set, then
      neither i2c_core nor of_i2c are able to be loaded.
      
      This patch fixes the problem by moving the of_i2c_register_devices()
      calls back into the device drivers.  Device drivers already
      specifically request the core code to parse the device tree for
      devices anyway by setting the of_node pointer, so it isn't a big
      deal to also call the registration function.  The drivers just become
      slightly more verbose.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      925bb9c6
    • R
      i2c: Fix checks which cause legacy suspend to never get called · 64b4782f
      Rajendra Nayak 提交于
      For devices which are not adapted to runtime PM a call to
      pm_runtime_suspended always returns true.
      
      Hence the pm_runtime_suspended checks below prevent legacy
      suspend from getting called.
      
      So do a pm_runtime_suspended check only for devices with a
      dev_pm_ops populated (which hence do not rely on the legacy
      suspend.)
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      64b4782f
    • V
      i2c: Fix for suspend/resume issue · 753419f5
      Vishwanath BS 提交于
      In current i2c core driver, call to pm_runtime_set_active from
      i2c_device_pm_resume will unconditionally enable i2c module and
      increment child count of the parent. Because of this, in CPU Idle
      path, i2c does not idle, preventing Core to enter retention. Also i2c
      module will not be suspended upon system suspend as
      pm_runtime_set_suspended is not called from i2c_device_pm_suspend.
      
      This issue is fixed by removing pm_runtime_set_active call from resume
      path which is not necessary.
      This fix has been tested on OMAP4430.
      Signed-off-by: NPartha Basak <p-basak2@ti.com>
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      753419f5
  3. 12 8月, 2010 7 次提交
  4. 10 7月, 2010 1 次提交
  5. 06 7月, 2010 1 次提交
  6. 03 6月, 2010 4 次提交
  7. 22 5月, 2010 1 次提交
  8. 11 5月, 2010 1 次提交
    • R
      i2c: Fix bus-level power management callbacks · 2f60ba70
      Rafael J. Wysocki 提交于
      There are three issues with the i2c bus type's power management
      callbacks at the moment.  First, they don't include any hibernate
      callbacks, although they should at least include the .restore()
      callback (there's no guarantee that the driver will be present in
      memory before loading the image kernel and we must restore the
      pre-hibernation state of the device).  Second, the "legacy"
      callbacks are not going to be invoked by the PM core since the bus
      type's pm object is not NULL.  Finally, the system sleep PM
      (ie. suspend/resume) callbacks don't check if the device has been
      already suspended at run time, in which case they should skip
      suspending it.  Also, it looks like the i2c bus type can use the
      generic subsystem-level runtime PM callbacks.
      
      For these reasons, rework the system sleep PM callbacks provided by
      the i2c bus type to handle hibernation correctly and to invoke the
      "legacy" callbacks for drivers that provide them.  In addition to
      that make the i2c bus type use the generic subsystem-level runtime
      PM callbacks.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NJean Delvare <khali@linux-fr.org>
      2f60ba70
  9. 04 5月, 2010 3 次提交
  10. 29 4月, 2010 1 次提交
    • G
      i2c/of: Allow device node to be passed via i2c_board_info · d12d42f7
      Grant Likely 提交于
      The struct device_node *of_node pointer is moving out of dev->archdata
      and into the struct device proper.  of_i2c.c needs to set the of_node
      pointer before the device is registered.  Since the i2c subsystem
      doesn't allow 2 stage allocation and registration of i2c devices, the
      of_node pointer needs to be passed via the i2c_board_info structure
      so that it is set prior to registration.
      
      This patch adds of_node to struct i2c_board_info (conditional on
      CONFIG_OF), sets of_node in i2c_new_device(), and modifies of_i2c.c
      to use the new parameter.  The calling of dev_archdata_set_node()
      from of_i2c will be removed in a subsequent patch when of_node is
      removed from archdata and all users are converted over.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      d12d42f7
  11. 02 3月, 2010 2 次提交
  12. 17 1月, 2010 2 次提交
  13. 15 12月, 2009 3 次提交
  14. 07 12月, 2009 4 次提交
  15. 26 11月, 2009 1 次提交
    • J
      i2c: Fix userspace_device list corruption · bbd2d9c9
      Jean Delvare 提交于
      Fix userspace_device list corruption. The corruption was caused by
      clients not being removed when adapters with such clients were
      themselves removed. Something like the following would trigger it
      (assuming i2c-stub gets adapter number 3):
      
      # modprobe i2c-stub chip_addr=0x50
      # echo 24c08 0x50 > /sys/bus/i2c/devices/i2c-3/new_device 
      # rmmod i2c-stub
      # modprobe i2c-stub chip_addr=0x50
      # echo 24c08 0x50 > /sys/bus/i2c/devices/i2c-3/new_device 
      
      For the records, the stack trace in the kernel logs look like this:
      
      kernel: WARNING: at lib/list_debug.c:30 __list_add+0x8b/0x90()
      kernel: Hardware name: (...)
      kernel: list_add corruption. prev->next should be next (c137fc84), but was (null). (prev=f57111b8).
      kernel: Modules linked in: (...)
      kernel: Pid: 4669, comm: bash Not tainted 2.6.32-rc8 #259
      kernel: Call Trace:
      kernel:  [<c111eb8b>] ? __list_add+0x8b/0x90
      kernel:  [<c111eb8b>] ? __list_add+0x8b/0x90
      kernel:  [<c103265c>] warn_slowpath_common+0x6c/0xc0
      kernel:  [<c111eb8b>] ? __list_add+0x8b/0x90
      kernel:  [<c10326f6>] warn_slowpath_fmt+0x26/0x30
      kernel:  [<c111eb8b>] __list_add+0x8b/0x90
      kernel:  [<c11ba165>] i2c_sysfs_new_device+0x1c5/0x250
      kernel:  [<c10861be>] ? might_fault+0x2e/0x80
      kernel:  [<c11b9fa0>] ? i2c_sysfs_new_device+0x0/0x250
      kernel:  [<c118c625>] dev_attr_store+0x25/0x30
      kernel:  [<c10e305c>] sysfs_write_file+0x9c/0xf0
      kernel:  [<c109d35c>] vfs_write+0x9c/0x160
      kernel:  [<c10e2fc0>] ? sysfs_write_file+0x0/0xf0
      kernel:  [<c109d4dd>] sys_write+0x3d/0x70
      kernel:  [<c1002ed8>] sysenter_do_call+0x12/0x36
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      bbd2d9c9
  16. 19 9月, 2009 3 次提交