1. 03 Jul, 2015 1 commit
  2. 06 May, 2015 1 commit
  3. 16 Dec, 2014 3 commits
    • Grygorii Strashko's avatar
      i2c: davinci: generate STP always when NACK is received · 99dfbb31
      Grygorii Strashko authored
      commit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream.
      According to I2C specification the NACK should be handled as follows:
      "When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
      Acknowledge signal. The master can then generate either a STOP condition to
      abort the transfer, or a repeated START condition to start a new transfer."
      [I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]
      Currently the Davinci i2c driver interrupts the transfer on receipt of a
      NACK but fails to send a STOP in some situations and so makes the bus
      stuck until next I2C IP reset (idle/enable).
      For example, the issue will happen during SMBus read transfer which
      consists from two i2c messages write command/address and read data:
      S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
      <--- write -----------------------> <--- read --------------------->
      The I2C client device will send NACK if it can't recognize "Command Code"
      and it's expected from I2C master to generate STP in this case.
      But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
      not be generated.
      Hence, fix it by generating Stop condition (STP) always when NACK is received.
      This patch fixes Davinci I2C in the same way it was done for OMAP I2C
      commit cda2109a26eb ("i2c: omap: query STP always when NACK is received").
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reported-by: default avatarHein Tibosch <hein_tibosch@yahoo.es>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alexander Kochetkov's avatar
      i2c: omap: fix i207 errata handling · 2cf69220
      Alexander Kochetkov authored
      commit ccfc866356674cb3a61829d239c685af6e85f197 upstream.
      commit 6d9939f6 (i2c: omap: split out [XR]DR
      and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
      Set) get handled. 6d9939f6 code doesn't correspond to workaround provided by
      According to errata ISR must filter out spurious RDR before data read not after.
      ISR must read RXSTAT to get number of bytes available to read. Because RDR
      could be set while there could no data in the receive FIFO.
      Restored pre 6d9939f6 way of handling errata.
      Found by code review. Real impact haven't seen.
      Tested on Beagleboard XM C.
      Signed-off-by: default avatarAlexander Kochetkov <al.kochet@gmail.com>
      Fixes: 6d9939f6 i2c: omap: split out [XR]DR and [XR]RDY
      Tested-by: default avatarFelipe Balbi <balbi@ti.com>
      Reviewed-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alexander Kochetkov's avatar
      i2c: omap: fix NACK and Arbitration Lost irq handling · daeac098
      Alexander Kochetkov authored
      commit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream.
      commit 1d7afc95 (i2c: omap: ack IRQ in parts)
      changed the interrupt handler to complete transfers without clearing
      XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
      fired again. As a result, ISR keep processing transfer after it was already
      complete (from the driver code point of view).
      A didn't see real impacts of the 1d7afc95, but it is really bad idea to
      have ISR running on user data after transfer was complete.
      It looks, what 1d7afc95 violate TI specs in what how AL and NACK should be
      handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
      According to specs (if I understood correctly), in case of NACK and AL driver
      must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
      NACK, AL, ARDY, and XDR (Master Transmitter Mode).
      All that is done down the code under the if condition:
      if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
      The patch restore pre 1d7afc95 logic of handling NACK and AL interrupts, so
      no interrupts is fired after ISR informs the rest of driver what transfer
      Note: instead of removing break under NACK case, we could just replace 'break'
      with 'continue' and allow NACK transfer to finish using ARDY event. I found
      that NACK and ARDY bits usually set together. That case confirm TI wiki:
      In order if someone interested in the event traces for NACK and AL cases,
      I sent them to mailing list.
      Tested on Beagleboard XM C.
      Signed-off-by: default avatarAlexander Kochetkov <al.kochet@gmail.com>
      Fixes: 1d7afc95 i2c: omap: ack IRQ in parts
      Acked-by: default avatarFelipe Balbi <balbi@ti.com>
      Tested-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 14 Nov, 2014 1 commit
  5. 05 Oct, 2014 2 commits
  6. 05 Sep, 2014 1 commit
  7. 07 Jun, 2014 6 commits
  8. 13 Feb, 2014 1 commit
  9. 04 Dec, 2013 2 commits
  10. 04 Nov, 2013 1 commit
  11. 18 Oct, 2013 1 commit
  12. 15 Aug, 2013 1 commit
  13. 25 Jul, 2013 1 commit
  14. 18 May, 2013 1 commit
  15. 17 May, 2013 6 commits
    • Alexander Sverdlin's avatar
      i2c: suppress lockdep warning on delete_device · e9b526fe
      Alexander Sverdlin authored
      i2c: suppress lockdep warning on delete_device
      Since commit 846f9974 the following lockdep
      warning is thrown in case i2c device is removed (via delete_device sysfs
      attribute) which contains subdevices (e.g. i2c multiplexer):
      [ INFO: possible recursive locking detected ]
      3.8.7-0-sampleversion-fct #8 Tainted: G           O
      bash/3743 is trying to acquire lock:
        (s_active#110){++++.+}, at: [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
      but task is already holding lock:
        (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
      other info that might help us debug this:
        Possible unsafe locking scenario:
        *** DEADLOCK ***
        May be due to missing lock nesting notation
      4 locks held by bash/3743:
        #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff802b3c3c>] sysfs_write_file+0x4c/0x208
        #1:  (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
        #2:  (&adap->userspace_clients_lock/1){+.+.+.}, at: [<ffffffff80454a18>] i2c_sysfs_delete_device+0x90/0x238
        #3:  (&__lockdep_no_validate__){......}, at: [<ffffffff803dcc24>] device_release_driver+0x24/0x48
      stack backtrace:
      Call Trace:
      [<ffffffff80575cc8>] dump_stack+0x8/0x34
      [<ffffffff801b50fc>] __lock_acquire+0x161c/0x2110
      [<ffffffff801b5c3c>] lock_acquire+0x4c/0x70
      [<ffffffff802b60cc>] sysfs_addrm_finish+0x19c/0x1e0
      [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
      [<ffffffff802b7d8c>] sysfs_remove_group+0x64/0x148
      [<ffffffff803d990c>] device_remove_attrs+0x9c/0x1a8
      [<ffffffff803d9b1c>] device_del+0x104/0x1d8
      [<ffffffff803d9c18>] device_unregister+0x28/0x70
      [<ffffffff8045505c>] i2c_del_adapter+0x1cc/0x328
      [<ffffffff8045802c>] i2c_del_mux_adapter+0x14/0x38
      [<ffffffffc025c108>] pca954x_remove+0x90/0xe0 [pca954x]
      [<ffffffff804542f8>] i2c_device_remove+0x80/0xe8
      [<ffffffff803dca9c>] __device_release_driver+0x74/0xf8
      [<ffffffff803dcc2c>] device_release_driver+0x2c/0x48
      [<ffffffff803dbc14>] bus_remove_device+0x13c/0x1d8
      [<ffffffff803d9b24>] device_del+0x10c/0x1d8
      [<ffffffff803d9c18>] device_unregister+0x28/0x70
      [<ffffffff80454b08>] i2c_sysfs_delete_device+0x180/0x238
      [<ffffffff802b3cd4>] sysfs_write_file+0xe4/0x208
      [<ffffffff8023ddc4>] vfs_write+0xbc/0x160
      [<ffffffff8023df6c>] SyS_write+0x54/0xd8
      [<ffffffff8013d424>] handle_sys64+0x44/0x64
      The problem is already known for USB and PCI subsystems. The reason is that
      delete_device attribute is defined statically in i2c-core.c and used for all
      devices in i2c subsystem.
      Discussion of original USB problem:
      Commit 356c05d5 introduced new macro to suppress
      lockdep warnings for this special case and included workaround for USB code.
      LKML discussion of the workaround:
      As i2c case is in principle the same, the same workaround could be used here.
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nsn.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
    • Russell King's avatar
      i2c: mv64xxx: work around signals causing I2C transactions to be aborted · d295a86e
      Russell King authored
      Do not use interruptible waits in an I2C driver; if a process uses
      signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
      cause the I2C driver to abort a transaction in progress by another
      driver, which can cause that driver to fail.  I2C drivers are not
      expected to abort transactions on signals.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
    • Jean Delvare's avatar
      i2c: i801: Document feature bits in modinfo · 53229345
      Jean Delvare authored
      Duplicate the feature bits documentation in modinfo, as not every user
      will read the driver's source code or documentation file.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
    • Mika Westerberg's avatar
      i2c: designware: add Intel BayTrail ACPI ID · 5a7e6bd8
      Mika Westerberg authored
      This is the same controller as on Intel Lynxpoint but the ACPI ID is
      different (8086F41). Add support for this.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
    • Mika Westerberg's avatar
      i2c: designware: always clear interrupts before enabling them · 2a2d95e9
      Mika Westerberg authored
      If the I2C bus is put to a low power state by an ACPI method it might pull
      the SDA line low (as its power is removed). Once the bus is put to full
      power state again, the SDA line is pulled back to high. This transition
      looks like a STOP condition from the controller point-of-view which sets
      STOP detected bit in its status register causing the driver to fail
      subsequent transfers.
      Fix this by always clearing all interrupts before we start a transfer.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
    • Josef Ahmad's avatar
      i2c: designware: fix RX FIFO overrun · e6f34cea
      Josef Ahmad authored
      i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive
      to/from the bus into the TX FIFO.
      For master-rx transactions, the maximum amount of data that can be
      received is calculated depending solely on TX and RX FIFO load.
      This is racy - TX FIFO may contain master-rx data yet to be
      processed, which will eventually land into the RX FIFO. This
      data is not taken into account and the function may request more
      data than the controller is actually capable of storing.
      This patch ensures the driver takes into account the outstanding
      master-rx data in TX FIFO to prevent RX FIFO overrun.
      Signed-off-by: default avatarJosef Ahmad <josef.ahmad@linux.intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
  16. 23 Apr, 2013 2 commits
  17. 19 Apr, 2013 4 commits
  18. 17 Apr, 2013 1 commit
  19. 16 Apr, 2013 2 commits
  20. 15 Apr, 2013 2 commits
    • Lucas Stach's avatar
      i2c: mxs: do error checking and handling in PIO mode · 92b775c2
      Lucas Stach authored
      In PIO mode we can end up with the same errors as in DMA mode, but as IRQs
      are disabled there we have to check for them manually after each command.
      Also don't use the big controller reset hammer when receiving a NAK from a
      slave. It's sufficient to tell the controller to continue at a clean state.
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Tested-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
    • Lucas Stach's avatar
      i2c: mxs: remove races in PIO code · 535ebd21
      Lucas Stach authored
      This commit fixes the three following races in PIO code:
      - The CTRL0 register is racy in itself, when programming transfer state and
        run bit in the same cycle the hardware sometimes ends up using the state
        from the last transfer. Fix this by programming state in one cycle, make
        sure the write is flushed down APBX bus by reading back the reg and only
        then trigger the run bit.
      - Only clear the DMAREQ bit in DEBUG0 after the read/write to the data reg
        happened. Otherwise we are racing with the hardware about who touches
        the data reg first.
      - When checking for completion of a transfer it's not sufficient to check
        if the data engine finished, but also a check for i2c bus idle is needed.
        In PIO mode we are really fast to program the next transfer after a finished
        one, so the controller possibly tries to start a new transfer while the
        clkgen engine is still busy writing the NAK/STOP from the last transfer to
        the bus.
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>