1. 30 6月, 2016 1 次提交
  2. 13 5月, 2016 1 次提交
  3. 05 5月, 2016 3 次提交
    • P
      i2c: mux: relax locking of the top i2c adapter during mux-locked muxing · 6ef91fcc
      Peter Rosin 提交于
      With a i2c topology like the following
      
                             GPIO ---|  ------ BAT1
                              |      v /
         I2C  -----+----------+---- MUX
                   |                   \
                 EEPROM                 ------ BAT2
      
      there is a locking problem with the GPIO controller since it is a client
      on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
      will lock the whole i2c bus prior to attempting to switch the mux to the
      correct i2c segment. In the above case, the GPIO device is an I/O expander
      with an i2c interface, and since the GPIO subsystem knows nothing (and
      rightfully so) about the lockless needs of the i2c mux code, this results
      in a deadlock when the GPIO driver issues i2c transfers to modify the
      mux.
      
      So, observing that while it is needed to have the i2c bus locked during the
      actual MUX update in order to avoid random garbage on the slave side, it
      is not strictly a must to have it locked over the whole sequence of a full
      select-transfer-deselect mux client operation. The mux itself needs to be
      locked, so transfers to clients behind the mux are serialized, and the mux
      needs to be stable during all i2c traffic (otherwise individual mux slave
      segments might see garbage, or worse).
      
      Introduce this new locking concept as "mux-locked" muxes, and call the
      pre-existing mux locking scheme "parent-locked".
      
      Modify the i2c mux locking so that muxes that are "mux-locked" locks only
      the muxes on the parent adapter instead of the whole i2c bus when there is
      a transfer to the slave side of the mux. This lock serializes transfers to
      the slave side of the muxes on the parent adapter.
      
      Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved
      gpio/pinctrl devices have a parent that is an i2c adapter in the same
      adapter tree that is muxed, and request a "mux-locked mux" if that is the
      case.
      
      Modify the select-transfer-deselect code for "mux-locked" muxes so
      that each of the select-transfer-deselect ops locks the mux parent
      adapter individually.
      Signed-off-by: NPeter Rosin <peda@axentia.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      6ef91fcc
    • P
      i2c: muxes always lock the parent adapter · fa96f0cb
      Peter Rosin 提交于
      Instead of checking for i2c parent adapters for every lock/unlock, simply
      override the locking for muxes to always lock/unlock the parent adapter
      directly.
      Signed-off-by: NPeter Rosin <peda@axentia.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      fa96f0cb
    • P
      i2c: allow adapter drivers to override the adapter locking · 8320f495
      Peter Rosin 提交于
      Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
      unlock_bus ops in the adapter. These funcs/ops take an additional flags
      argument that indicates for what purpose the adapter is locked.
      
      There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they
      are both implemented the same. For now. Locking the root adapter means
      that the whole bus is locked, locking the segment means that only the
      current bus segment is locked (i.e. i2c traffic on the parent side of
      a mux is still allowed even if the child side of the mux is locked).
      
      Also support a trylock_bus op (but no function to call it, as it is not
      expected to be needed outside of the i2c core).
      
      Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking
      scheme (i.e. lock with the I2C_LOCK_ROOT_ADAPTER flag).
      
      Locking the root adapter and locking the segment is the same thing for
      all root adapters (e.g. in the normal case of a simple topology with no
      i2c muxes). The two locking variants are also the same for traditional
      muxes (aka parent-locked muxes). These muxes traverse the tree, locking
      each level as they go until they reach the root. This patch is preparatory
      for a later patch in the series introducing mux-locked muxes, which behave
      differently depending on the requested locking. Since all current users
      are using i2c_lock_adapter, which is a wrapper for I2C_LOCK_ROOT_ADAPTER,
      we only need to annotate the calls that will not need to lock the root
      adapter for mux-locked muxes. I.e. the instances that needs to use
      I2C_LOCK_SEGMENT instead of i2c_lock_adapter/I2C_LOCK_ROOT_ADAPTER. Those
      instances are in the i2c_transfer and i2c_smbus_xfer functions, so that
      mux-locked muxes can single out normal i2c accesses to its slave side
      and adjust the locking for those accesses.
      Signed-off-by: NPeter Rosin <peda@axentia.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      8320f495
  4. 13 4月, 2016 1 次提交
    • L
      i2c: let I2C masters ignore their children for PM · 04f59143
      Linus Walleij 提交于
      When using a certain I2C device with runtime PM enabled on
      a certain I2C bus adaper the following happens:
      
      struct amba_device *foo
         \
         struct i2c_adapter *bar
            \
            struct i2c_client *baz
      
      The AMBA device foo has its device PM struct set to ignore
      children with pm_suspend_ignore_children(&foo->dev, true).
      This makes runtime PM work just fine locally in the driver:
      the fact that devices on the bus are suspended or resumed
      individually does not affect its operation, and the hardware
      does not power up unless transferring messages.
      
      However this child ignorance property is not inherited into
      the struct i2c_adapter *bar.
      
      On system suspend things will work fine.
      
      On system resume the following annoying phenomenon occurs:
      
      - In the pm_runtime_force_resume() path of
        struct i2c_client *baz, pm_runtime_set_active(&baz->dev); is
        eventually called.
      
      - This becomes __pm_runtime_set_status(&baz->dev, RPM_ACTIVE);
      
      - __pm_runtime_set_status() detects that RPM state is changed,
        and checks whether the parent is:
        not active (RPM_ACTIVE) and not ignoring its children
        If this happens it concludes something is wrong, because
        a parent that is not ignoring its children must be active
        before any children activate.
      
      - Since the struct i2c_adapter *bar does not ignore
        its children, the PM core thinks that it must indeed go
        online before its children, the check bails out with
        -EBUSY, i.e. the i2c_client *baz thinks it can't work
        because it's parent is not online, and it respects its
        parent.
      
      - In the driver the .resume() callback returns -EBUSY from
        the runtime_force_resume() call as per above. This leaves
        the device in a suspended state, leading to bad behaviour
        later when the device is used. The following debug
        print is made with an extra printg patch but illustrates
        the problem:
      
      [   17.040832] bh1780 2-0029: parent (i2c-2) is not active
                     parent->power.ignore_children = 0
      [   17.040832] bh1780 2-0029: pm_runtime_force_resume:
                     pm_runtime_set_active() failed (-16)
      [   17.040863] dpm_run_callback():
                     pm_runtime_force_resume+0x0/0x88 returns -16
      [   17.040863] PM: Device 2-0029 failed to resume: error -16
      
      Fix this by letting all struct i2c_adapter:s ignore their
      children: i2c children have no business doing keeping
      their parents awake: they are completely autonomous
      devices that just use their parent to talk, a usecase
      which must be power managed in the host on a per-message
      basis.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      04f59143
  5. 12 4月, 2016 1 次提交
  6. 30 3月, 2016 1 次提交
    • W
      i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE · 8dcf3217
      Wolfram Sang 提交于
      Jan reported this:
      
      ===
      After enabling CONFIG_I2C_DEBUG_CORE my system was broken
      (no network, console login not possible). System log was
      flooded with the this message:
      
       ...
      [  608.052077] rtc-ds1307 0-0068: uevent
      [  608.052500] rtc-ds1307 0-0068: uevent
      [  608.052925] rtc-ds1307 0-0068: uevent
       ...
      
      The culprit is the dev_dbg printk in the i2c uevent handler.
      If this is activated (for instance by CONFIG_I2C_DEBUG_CORE)
      it results in an endless loop with systemd-journald.
      
      This happens if user-space scans the system log and reads the uevent
      file to get information about a newly created device, which seems fair
      use to me. Unfortunately reading the "uevent" file uses the same
      function that runs for creating the uevent for a new device,
      generating the next syslog entry.
      
      Ideally user-space would implement a recursion detection and
      after reading the same device file for the 1000th time call it a
      day, but nevertheless I think we should avoid this problem by
      removing the debug print completely or using another print variant.
      
      The same problem seems to be reported here:
      https://bugs.freedesktop.org/show_bug.cgi?id=76886
      ===
      
      His patch converted the message to pr_debug, but I think the debug can
      simply go. We have other means to see code paths these days. This
      enables us to clean up the function some more while we are here.
      Reported-by: NJan Glauber <jglauber@cavium.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Acked-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Tested-by: NJan Glauber <jglauber@cavium.com>
      8dcf3217
  7. 15 3月, 2016 1 次提交
  8. 12 3月, 2016 1 次提交
  9. 21 2月, 2016 1 次提交
  10. 10 1月, 2016 1 次提交
  11. 18 12月, 2015 1 次提交
  12. 14 12月, 2015 1 次提交
  13. 20 11月, 2015 1 次提交
  14. 25 10月, 2015 1 次提交
    • D
      i2c: add ACPI support for I2C mux ports · 8eb5c87a
      Dustin Byford 提交于
      Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
      device property compatible string match), enumerating I2C client devices
      connected through an I2C mux needs a little extra work.
      
      This change implements a method for describing an I2C device hierarchy that
      includes mux devices by using an ACPI Device() for each mux channel along
      with an _ADR to set the channel number for the device.  See
      Documentation/acpi/i2c-muxes.txt for a simple example.
      
      To make this work the ismt, i801, and designware pci/platform devs now
      share an ACPI companion with their I2C adapter dev similar to how it's done
      in OF.  This is done on the assumption that power management functions will
      not be called directly on the I2C dev that is sharing the ACPI node.
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NDustin Byford <dustin@cumulusnetworks.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      8eb5c87a
  15. 20 10月, 2015 1 次提交
  16. 15 10月, 2015 1 次提交
  17. 27 8月, 2015 1 次提交
    • D
      i2c: allow specifying separate wakeup interrupt in device tree · 3fffd128
      Dmitry Torokhov 提交于
      Instead of having each i2c driver individually parse device tree data in
      case it or platform supports separate wakeup interrupt, and handle
      enabling and disabling wakeup interrupts in their power management
      routines, let's have i2c core do that for us.
      
      Platforms wishing to specify separate wakeup interrupt for the device
      should use named interrupt syntax in their DTSes:
      
      	interrupt-parent = <&intc1>;
      	interrupts = <5 0>, <6 0>;
      	interrupt-names = "irq", "wakeup";
      
      This patch is inspired by work done by Vignesh R <vigneshr@ti.com> for
      pixcir_i2c_ts driver.
      
      Note that the original code tried to preserve any existing wakeup
      settings from userspace but was not quite right in that regard:
      it would preserve wakeup flag set by userspace upon driver rebinding;
      but it would re-arm the wakeup flag if it was disabled by userspace.
      
      We think that resetting the flag upon re-binding the driver is proper
      behavior as the driver is responsible for setting up and handling
      wakeups.
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Tested-by: NVignesh R <vigneshr@ti.com>
      [wsa: updated the commit message]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      3fffd128
  18. 24 8月, 2015 8 次提交
  19. 10 8月, 2015 2 次提交
    • V
      i2c: core: add and export of_get_i2c_adapter_by_node() interface · 48e9743d
      Vladimir Zapolskiy 提交于
      of_find_i2c_adapter_by_node() call requires quite often missing
      put_device(), and i2c_put_adapter() releases a device locked by
      i2c_get_adapter() only. In general module_put(adapter->owner) and
      put_device(dev) are not interchangeable.
      
      This is a common error reproduction scenario as a result of the
      misusage described above (for clearness this is run on iMX6 platform
      with HDMI and I2C bus drivers compiled as kernel modules):
      
          root@mx6q:~# lsmod | grep i2c
          i2c_imx                10213  0
          root@mx6q:~# lsmod | grep dw_hdmi_imx
          dw_hdmi_imx             3631  0
          dw_hdmi                11846  1 dw_hdmi_imx
          imxdrm                  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
          drm_kms_helper        113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
          root@mx6q:~# rmmod dw_hdmi_imx
          root@mx6q:~# lsmod | grep i2c
          i2c_imx                10213  -1
      
                                       ^^^^^
      
          root@mx6q:~# rmmod i2c_imx
          rmmod: ERROR: Module i2c_imx is in use
      
      To fix existing users of these interfaces and to avoid any further
      confusion and misusage in future, add one more interface
      of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in
      sense that an I2C bus device driver found and locked by user can be
      correctly unlocked by i2c_put_adapter().
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      48e9743d
    • V
      i2c: core: manage i2c bus device refcount in i2c_[get|put]_adapter · 611e12ea
      Vladimir Zapolskiy 提交于
      In addition to module_get()/module_put() add get_device()/put_device()
      calls into i2c_get_adapter()/i2c_put_adapter() exported
      interfaces. This is done to lock I2C bus device, if it is in use by a
      client.
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      611e12ea
  20. 01 8月, 2015 1 次提交
  21. 31 7月, 2015 1 次提交
  22. 10 7月, 2015 1 次提交
  23. 02 6月, 2015 1 次提交
  24. 01 6月, 2015 3 次提交
  25. 13 5月, 2015 2 次提交
  26. 24 4月, 2015 1 次提交
  27. 16 4月, 2015 1 次提交
    • M
      i2c: core: Export bus recovery functions · c1c21f4e
      Mark Brown 提交于
      Current -next fails to link an ARM allmodconfig because drivers that use
      the core recovery functions can be built as modules but those functions
      are not exported:
      
      ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
      ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
      ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined!
      
      Add exports to fix this.
      
      Fixes: 5f9296ba (i2c: Add bus recovery infrastructure)
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      c1c21f4e