Skip to content
Snippets Groups Projects
  1. Dec 11, 2019
    • Tom Rini's avatar
      Merge tag 'fix-for-2020.01' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c · 3031cded
      Tom Rini authored
      i2c bugfixes for 2020.01
      - i2c: i2c_cdns: fix write timeout on fifo boundary
        fixes timout issue when writting number of bytes is multiple
        of the FIFO depth.
      3031cded
    • Tom Rini's avatar
      Merge tag 'u-boot-atmel-fixes-2020.01-a' of https://gitlab.denx.de/u-boot/custodians/u-boot-atmel · addb1d9f
      Tom Rini authored
      - First set of u-boot-atmel fixes for 2020.01 cycle:
        This set includes a small fix for gpio bank names, one for removing
        unused headers (also touches some other boards), and a fix for the QSPI
        env read on one of the boards.
      addb1d9f
    • Michael Auchter's avatar
      i2c: i2c_cdns: fix write timeout on fifo boundary · 3104162a
      Michael Auchter authored
      
      This fixes an issue that would cause I2C writes to timeout when the
      number of bytes is a multiple of the FIFO depth (i.e. 16 bytes).
      
      Within the transfer loop, after writing the data register with a new
      byte to transfer, if the transfer size equals the FIFO depth, the loop
      pauses until the INTERRUPT_COMP bit asserts to indicate data has been
      sent. This same check is performed after the loop as well to ensure data
      has been transferred prior to returning.
      
      In the case where the amount of data to be written is a multiple of the
      FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to
      assert after writing the final byte, and then wait for this bit to
      assert once more. However, since the transfer has finished at this
      point, no new data has been written to the data register, and hence
      INTERRUPT_COMP will never assert.
      
      Fix this by only waiting for INTERRUPT_COMP in the transfer loop if
      there's still data to be written.
      
      Signed-off-by: default avatarMichael Auchter <michael.auchter@ni.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      3104162a
  2. Dec 10, 2019
  3. Dec 09, 2019
Loading