1. 17 11月, 2016 1 次提交
  2. 24 9月, 2016 1 次提交
  3. 31 8月, 2016 1 次提交
  4. 26 8月, 2016 2 次提交
    • J
      i2c: core: Add function for finding the bus speed from ACPI, take 2 · 5853b22d
      Jarkko Nikula 提交于
      ACPI 5 specification doesn't have property for the I2C bus speed but
      I2cSerialBus resource descriptor which define each controller-slave
      connection define the maximum speed supported by that connection.
      
      Thus finding the maximum safe speed for the bus is to walk through all
      I2cSerialBus resources that are associated to I2C controller and use the
      speed of slowest connection.
      
      Add function i2c_acpi_find_bus_speed() to the i2c-core that adapter
      drivers can call prior registering itself to core.
      
      This implies two-step walk through the I2cSerialBus resources: call to
      i2c_acpi_find_bus_speed() does the first scan and finds the safe bus
      speed that adapter drivers can set up. Adapter driver registration does
      the second scan when i2c-core creates the I2C slaves by calling the
      i2c_acpi_register_devices(). In that way the bus speed is set in case
      slave device probe gets called during registration and does communication.
      
      Previous version commit 55d38d06 ("i2c: core: Add function for finding
      the bus speed from ACPI") got reverted due merge conflicts from
      commit 525e6fab ("i2c / ACPI: add support for ACPI reconfigure
      notifications").
      
      This version is a bit bigger than previous version but is still sharing
      the lowest and complicated part of I2cSerialBus lookup routines with the
      existing code.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      5853b22d
    • P
      i2c: add i2c_trylock_bus wrapper, use it · fb79e09a
      Peter Rosin 提交于
      This unifies usage with i2c_lock_bus and i2c_unlock_bus, and paves the
      way for the next patch which looks a bit saner with this preparatory
      work taken care of beforehand.
      Signed-off-by: NPeter Rosin <peda@axentia.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      fb79e09a
  5. 19 7月, 2016 1 次提交
  6. 14 7月, 2016 1 次提交
    • J
      i2c: core: Add function for finding the bus speed from ACPI · 55d38d06
      Jarkko Nikula 提交于
      ACPI 5 specification doesn't have property for the I2C bus speed but
      I2cSerialBus resource descriptors which define each controller-slave
      connection define the maximum speed supported by that connection.
      
      Thus finding the maximum safe speed for the bus is to walk all
      I2cSerialBus resources that are associated to I2C controller and use
      the speed of slowest connection.
      
      Add function i2c_acpi_find_bus_speed() to the i2c-core that adapter
      drivers can call prior registering itself to core.
      
      This implies two-step walk through the I2cSerialBus resources: call to
      i2c_acpi_find_bus_speed() does the first scan and finds the safe bus
      speed that adapter drivers can set up. Adapter driver registration does
      the second scan when i2c-core creates the I2C slaves by calling the
      i2c_acpi_register_devices(). In that way the bus speed is set in case
      slave device probe gets called during registration and does
      communication.
      
      Implement this by reusing the existing ACPI I2C walk routines in the
      i2c-core. Extend them so that slowest connection speed is saved during
      the walk and I2C slaves are registered only when calling through the
      i2c_acpi_register_devices() with the i2c_adapter pointer.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      55d38d06
  7. 17 6月, 2016 2 次提交
  8. 14 6月, 2016 1 次提交
    • J
      i2c: Add generic support passing secondary devices addresses · 0f614d83
      Jean-Michel Hautbois 提交于
      Some I2C devices have multiple addresses assigned, for example each address
      corresponding to a different internal register map page of the device.
      So far drivers which need support for this have handled this with a driver
      specific and non-generic implementation, e.g. passing the additional address
      via platform data.
      
      This patch provides a new helper function called i2c_new_secondary_device()
      which is intended to provide a generic way to get the secondary address
      as well as instantiate a struct i2c_client for the secondary address.
      
      The function expects a pointer to the primary i2c_client, a name
      for the secondary address and an optional default address. The name is used
      as a handle to specify which secondary address to get.
      
      The default address is used as a fallback in case no secondary address
      was explicitly specified. In case no secondary address and no default
      address were specified the function returns NULL.
      
      For now the function only supports look-up of the secondary address
      from devicetree, but it can be extended in the future
      to for example support board files and/or ACPI.
      Signed-off-by: NJean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      0f614d83
  9. 05 5月, 2016 2 次提交
    • 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: 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
  10. 12 4月, 2016 1 次提交
  11. 13 1月, 2016 1 次提交
    • P
      i2c: create builtin_i2c_driver to avoid registration boilerplate · c698d639
      Paul Gortmaker 提交于
      In commit f309d444 ("platform_device:
      better support builtin boilerplate avoidance") we introduced the
      builtin_driver macro.
      
      Here we use that support and extend it to I2C driver registration,
      so where a driver is clearly non-modular and builtin-only, we can
      register it in a similar fashion.  And existing code that is clearly
      non-modular can be updated with the simple mapping of
      
           module_i2c_driver(...)  ---> builtin_i2c_driver(...)
      
      We've essentially cloned the former to make the latter, and taken
      out the remove/module_exit parts since those never get used in a
      non-modular build of the code.
      
      A similar thing was done in commit b4eb6cdb
      ("PCI: Add builtin_pci_driver() to avoid registration boilerplate").
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      c698d639
  12. 14 12月, 2015 1 次提交
  13. 01 12月, 2015 2 次提交
  14. 24 8月, 2015 2 次提交
  15. 10 8月, 2015 1 次提交
    • 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
  16. 10 4月, 2015 1 次提交
  17. 27 3月, 2015 1 次提交
  18. 17 3月, 2015 1 次提交
  19. 13 3月, 2015 1 次提交
  20. 27 1月, 2015 1 次提交
  21. 23 12月, 2014 1 次提交
    • L
      i2c: Remove support for legacy PM · 523c5b89
      Lars-Peter Clausen 提交于
      There haven't been any I2C driver that use the legacy suspend/resume
      callbacks for a while now and new drivers are supposed to use PM ops. So
      remove support for legacy suspend/resume for I2C drivers.
      
      Since there aren't any special bus specific things to do during
      suspend/resume and since the PM core will automatically fallback directly to
      using the device's PM ops if no bus PM ops are specified there is no need to
      have any I2C bus PM ops.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      523c5b89
  22. 12 12月, 2014 1 次提交
  23. 04 11月, 2014 1 次提交
  24. 25 9月, 2014 1 次提交
  25. 19 8月, 2014 1 次提交
  26. 27 6月, 2014 2 次提交
    • L
      I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI config · da3c6647
      Lan Tianyu 提交于
      Clean up ACPI related code in the i2c core and add CONFIG_I2C_ACPI
      to enable I2C ACPI code.
      
      Current there is a race between removing I2C ACPI operation region
      and ACPI AML code accessing. So make i2c core built-in if CONFIG_I2C_ACPI
      is set.
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      da3c6647
    • L
      I2C/ACPI: Add i2c ACPI operation region support · 5d98e61d
      Lan Tianyu 提交于
      ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation region.
      It allows ACPI aml code able to access such kind of devices to implement
      some ACPI standard method.
      
      ACPI Spec defines some access attribute to associate with i2c protocol.
      AttribQuick 	       	       		Read/Write Quick Protocol
      AttribSendReceive			Send/Receive Byte Protocol
      AttribByte 			 	Read/Write Byte Protocol
      AttribWord				Read/Write Word Protocol
      AttribBlock				Read/Write Block Protocol
      AttribBytes				Read/Write N-Bytes Protocol
      AttribProcessCall			Process Call Protocol
      AttribBlockProcessCall			Write Block-Read Block Process Call Protocol
      AttribRawBytes 				Raw Read/Write N-BytesProtocol
      AttribRawProcessBytes			Raw Process Call Protocol
      
      On the Asus T100TA, Bios use GenericSerialBus operation region to access
      i2c device to get battery info.
      
      Sample code From Asus T100TA
      
          Scope (_SB.I2C1)
          {
              Name (UMPC, ResourceTemplate ()
              {
                  I2cSerialBus (0x0066, ControllerInitiated, 0x00061A80,
                      AddressingMode7Bit, "\\_SB.I2C1",
                      0x00, ResourceConsumer, ,
                      )
              })
      
      	...
      
              OperationRegion (DVUM, GenericSerialBus, Zero, 0x0100)
              Field (DVUM, BufferAcc, NoLock, Preserve)
              {
                  Connection (UMPC),
                  Offset (0x81),
                  AccessAs (BufferAcc, AttribBytes (0x3E)),
                  FGC0,   8
              }
      	...
           }
      
           Device (BATC)
           {
               Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
               Name (_UID, One)  // _UID: Unique ID
      	 ...
      
                  Method (_BST, 0, NotSerialized)  // _BST: Battery Status
                  {
                      If (LEqual (AVBL, One))
                      {
                          Store (FGC0, BFFG)
                          If (LNotEqual (STAT, One))
                          {
                              ShiftRight (CHST, 0x04, Local0)
                              And (Local0, 0x03, Local0)
                              If (LOr (LEqual (Local0, One), LEqual (Local0, 0x02)))
                              {
                                  Store (0x02, Local1)
                              }
      	...
      
          }
      
      The i2c operation region is defined under I2C1 scope. _BST method under
      battery device BATC read battery status from the field "FCG0". The request
      would be sent to i2c operation region handler.
      
      This patch is to add i2c ACPI operation region support. Due to there are
      only "Byte" and "Bytes" protocol access on the Asus T100TA, other protocols
      have not been tested.
      
      About RawBytes and RawProcessBytes protocol, they needs specific drivers to interpret
      reference data from AML code according ACPI 5.0 SPEC(5.5.2.4.5.3.9 and 5.5.2.4.5.3.10).
      So far, not found such case and will add when find real case.
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      5d98e61d
  27. 06 3月, 2014 1 次提交
    • W
      i2c: add deprecation warning for class based instantiation · 0c176170
      Wolfram Sang 提交于
      Class based instantiation can cause noticeable delays when booting. This
      mechanism is used when it is not possible to describe slaves on I2C
      busses. As we do have other mechanisms, most embedded I2C will not need
      classes and for embedded it is explicitly not recommended to use them. Add
      a deprecation warning for drivers which want to disable class based
      instantiation in the near future to gain boot-up time, so users relying
      on this technique can switch to something better. They really should.
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      0c176170
  28. 27 1月, 2014 1 次提交
  29. 15 1月, 2014 1 次提交
    • S
      i2c: Re-instate body of i2c_parent_is_i2c_adapter() · 2fac2b89
      Stephen Warren 提交于
      The body of i2c_parent_is_i2c_adapter() is currently guarded by
      I2C_MUX. It should be CONFIG_I2C_MUX instead.
      
      Among potentially other problems, this resulted in i2c_lock_adapter()
      only locking I2C mux child adapters, and not the parent adapter. In
      turn, this could allow inter-mingling of mux child selection and I2C
      transactions, which could result in I2C transactions being directed to
      the wrong I2C bus, and possibly even switching between busses in the
      middle of a transaction.
      
      One concrete issue caused by this bug was corrupted HDMI EDID reads
      during boot on the NVIDIA Tegra Seaboard system, although this only
      became apparent in recent linux-next, when the boot timing was changed
      just enough to trigger the race condition.
      
      Fixes: 3923172b ("i2c: reduce parent checking to a NOOP in non-I2C_MUX case")
      Cc: Phil Carmody <phil.carmody@partner.samsung.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      2fac2b89
  30. 04 10月, 2013 1 次提交
    • L
      i2c: Remove redundant 'driver' field from the i2c_client struct · 0acc2b32
      Lars-Peter Clausen 提交于
      The 'driver' field of the i2c_client struct is redundant. The same data can be
      accessed through to_i2c_driver(client->dev.driver). The generated code for both
      approaches in more or less the same.
      
      E.g. on ARM the expression client->driver->command(...) generates
      
      		...
      		ldr     r3, [r0, #28]
      		ldr     r3, [r3, #32]
      		blx     r3
      		...
      
      and the expression to_i2c_driver(client->dev.driver)->command(...) generates
      
      		...
      		ldr     r3, [r0, #160]
          	ldr     r3, [r3, #-4]
          	blx     r3
      		...
      
      Other architectures will generate similar code.
      
      All users of the 'driver' field outside of the I2C core have already been
      converted. So this only leaves the core itself. This patch converts the
      remaining few users in the I2C core and then removes the 'driver' field from the
      i2c_client struct.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      0acc2b32
  31. 23 8月, 2013 2 次提交
  32. 07 8月, 2013 1 次提交
  33. 02 4月, 2013 1 次提交
    • L
      i2c: Make return type of i2c_del_adapter() void · 71546300
      Lars-Peter Clausen 提交于
      i2c_del_adapter() is usually called from a drivers remove callback. The Linux
      device driver model does not allow the remove callback to fail and all resources
      allocated in the probe callback need to be freed, as well as all resources which
      have been provided to the rest of the kernel(for example a I2C adapter) need to
      be revoked. So any function revoking such resources isn't allowed to fail
      either. i2c_del_adapter() adheres to this requirement and will never fail. But
      i2c_del_adapter()'s return type is int, which may cause driver authors to think
      that it can fail. This led to code constructs like:
      
      	ret = i2c_del_adapter(...);
      	BUG_ON(ret);
      
      Since i2c_del_adapter() always returns 0 the BUG_ON is never hit and essentially
      becomes dead code, which means it can be removed. Making the return type of
      i2c_del_adapter() void makes it explicit that the function will never fail and
      should prevent constructs like the above from re-appearing in the kernel code.
      
      All callers of i2c_del_adapter() have already been updated in a previous patch
      to ignore the return value, so the conversion of the return type from int to
      void can be done without causing any build failures.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Reviewed-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      71546300