1. 10 Jan, 2019 2 commits
    • Sowjanya Komatineni's avatar
      i2c: tegra: Fix Maximum transfer size · b67d4530
      Sowjanya Komatineni authored
      Tegra194 supports maximum 64K Bytes transfer per packet.
      Tegra186 and prior supports maximum 4K Bytes transfer per packet.
      
      This patch fixes this payload difference between Tegra194 and prior
      Tegra chipsets using separate i2c_adapter_quirks.
      Signed-off-by: default avatarSowjanya Komatineni <skomatineni@nvidia.com>
      Acked-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      b67d4530
    • Yi Zeng's avatar
      i2c: dev: prevent adapter retries and timeout being set as minus value · 6ebec961
      Yi Zeng authored
      If adapter->retries is set to a minus value from user space via ioctl,
      it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to
      adapter->algo->master_xfer and adapter->algo->smbus_xfer that is
      registered by the underlying bus drivers, and return value 0 to all the
      callers. The bus driver will never be accessed anymore by all users,
      besides, the users may still get successful return value without any
      error or information log print out.
      
      If adapter->timeout is set to minus value from user space via ioctl,
      it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer
      always break after the the first try, due to the time_after always
      returns true.
      Signed-off-by: default avatarYi Zeng <yizeng@asrmicro.com>
      [wsa: minor grammar updates to commit message]
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      6ebec961
  2. 03 Jan, 2019 2 commits
  3. 21 Dec, 2018 1 commit
  4. 17 Dec, 2018 6 commits
  5. 11 Dec, 2018 5 commits
  6. 06 Dec, 2018 6 commits
    • Masahiro Yamada's avatar
      i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode · ece27a33
      Masahiro Yamada authored
      Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
      tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
      
      tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
        Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
        Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      ece27a33
    • Masahiro Yamada's avatar
      i2c: uniphier: fix violation of tLOW requirement for Fast-mode · 8469636a
      Masahiro Yamada authored
      Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
      tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
      
      tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
        Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
        Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      8469636a
    • Masahiro Yamada's avatar
      i2c: uniphier-f: fill TX-FIFO only in IRQ handler for repeated START · cd8843f5
      Masahiro Yamada authored
      - For a repeated START condition, this controller starts data transfer
         immediately after the slave address is written to the TX-FIFO.
      
       - Once the TX-FIFO empty interrupt is asserted, the controller makes
         a pause even if additional data are written to the TX-FIFO.
      
      Given those circumstances, the data after a repeated START may not be
      transferred if the interrupt is asserted while the TX-FIFO is being
      filled up. A more reliable way is to append TX data only in the
      interrupt handler.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      cd8843f5
    • Masahiro Yamada's avatar
      i2c: uniphier-f: fix timeout error after reading 8 bytes · c2a653de
      Masahiro Yamada authored
      I was totally screwed up in commit eaba6878 ("i2c: uniphier-f:
      fix race condition when IRQ is cleared"). Since that commit, if the
      number of read bytes is multiple of the FIFO size (8, 16, 24... bytes),
      the STOP condition could be issued twice, depending on the timing.
      If this happens, the controller will go wrong, resulting in the timeout
      error.
      
      It was more than 3 years ago when I wrote this driver, so my memory
      about this hardware was vague. Please let me correct the description
      in the commit log of eaba6878.
      
      Clearing the IRQ status on exiting the IRQ handler is absolutely
      fine. This controller makes a pause while any IRQ status is asserted.
      If the IRQ status is cleared first, the hardware may start the next
      transaction before the IRQ handler finishes what it supposed to do.
      
      This partially reverts the bad commit with clear comments so that I
      will never repeat this mistake.
      
      I also investigated what is happening at the last moment of the read
      mode. The UNIPHIER_FI2C_INT_RF interrupt is asserted a bit earlier
      (by half a period of the clock cycle) than UNIPHIER_FI2C_INT_RB.
      
      I consulted a hardware engineer, and I got the following information:
      
      UNIPHIER_FI2C_INT_RF
          asserted at the falling edge of SCL at the 8th bit.
      
      UNIPHIER_FI2C_INT_RB
          asserted at the rising edge of SCL at the 9th (ACK) bit.
      
      In order to avoid calling uniphier_fi2c_stop() twice, check the latter
      interrupt. I also commented this because it is obscure hardware internal.
      
      Fixes: eaba6878 ("i2c: uniphier-f: fix race condition when IRQ is cleared")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      c2a653de
    • Hans de Goede's avatar
      i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node · 0544ee4b
      Hans de Goede authored
      Some AMD based HP laptops have a SMB0001 ACPI device node which does not
      define any methods.
      
      This leads to the following error in dmesg:
      
      [    5.222731] cmi: probe of SMB0001:00 failed with error -5
      
      This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
      silencing the error. In case of a failure of the i2c_add_adapter() call
      this commit now propagates the error from that call instead of -EIO.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      0544ee4b
    • Adamski, Krzysztof (Nokia - PL/Wroclaw)'s avatar
      i2c: axxia: properly handle master timeout · 6c7f25ca
      According to Intel (R) Axxia TM Lionfish Communication Processor
      Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
      have a programmable Master Wait Timer, which among others, checks the
      time between commands send in manual mode. When a timeout (25ms) passes,
      TSS bit is set in Master Interrupt Status register and a Stop command is
      issued by the hardware.
      
      The axxia_i2c_xfer(), does not properly handle this situation, however.
      For each message a separate axxia_i2c_xfer_msg() is called and this
      function incorrectly assumes that any interrupt might happen only when
      waiting for completion. This is mostly correct but there is one
      exception - a master timeout can trigger if enough time has passed
      between individual transfers. It will, by definition, happen between
      transfers when the interrupts are disabled by the code. If that happens,
      the hardware issues Stop command.
      
      The interrupt indicating timeout will not be triggered as soon as we
      enable them since the Master Interrupt Status is cleared when master
      mode is entered again (which happens before enabling irqs) meaning this
      error is lost and the transfer is continued even though the Stop was
      issued on the bus. The subsequent operations completes without error but
      a bogus value (0xFF in case of read) is read as the client device is
      confused because aborted transfer. No error is returned from
      master_xfer() making caller believe that a valid value was read.
      
      To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
      Status register is checked before each transfer. If it is set, there was
      a timeout before this transfer and (as described above) the hardware
      already issued Stop command so the transaction should be aborted thus
      -ETIMEOUT is returned from the master_xfer() callback. In order to be
      sure no timeout was issued we can't just read the status just before
      starting new transaction as there will always be a small window of time
      (few CPU cycles at best) where this might still happen. For this reason
      we have to temporally disable the timer before checking for TSS bit.
      Disabling it will, however, clear the TSS bit so in order to preserve
      that information, we have to read it in ISR so we have to ensure that
      the TSS interrupt is not masked between transfers of one transaction.
      There is no need to call bus recovery or controller reinitialization if
      that happens so it's skipped.
      Signed-off-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Reviewed-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      6c7f25ca
  7. 03 Dec, 2018 3 commits
  8. 30 Nov, 2018 1 commit
  9. 27 Nov, 2018 8 commits
  10. 09 Nov, 2018 4 commits
  11. 31 Oct, 2018 2 commits