1. 24 Mar, 2018 15 commits
    • Chris Packham's avatar
      i2c: pca-platform: unconditionally use devm_gpiod_get_optional · 06783261
      Chris Packham authored
      Allow for the reset-gpios property to be defined in the device tree
      or via a GPIO lookup table.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      06783261
    • Chris Packham's avatar
      sh: sh7785lcr: add GPIO lookup table for i2c controller reset · df0d3234
      Chris Packham authored
      Define the GPIO connected to the PCA9564 using a GPIO lookup table. This
      will allow the i2c-pca-platform driver to use the device managed APIs to
      lookup the gpio instead of using platform_data.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      df0d3234
    • Abhishek Sahu's avatar
      i2c: qup: reorganization of driver code to remove polling for qup v2 · 7545c7db
      Abhishek Sahu authored
      Following are the major issues in current driver code
      
      1. The current driver simply assumes the transfer completion
         whenever its gets any non-error interrupts and then simply do the
         polling of available/free bytes in FIFO.
      2. The block mode is not working properly since no handling in
         being done for OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_READ.
      3. An i2c transfer can contain multiple message and QUP v2
         supports reconfiguration during run in which the mode should be same
         for all the sub transfer. Currently the mode is being programmed
         before every sub transfer which is functionally wrong. If one message
         is less than FIFO length and other message is greater than FIFO
         length, then transfers will fail.
      
      Because of above, i2c v2 transfers of size greater than 64 are failing
      with following error message
      
      	i2c_qup 78b6000.i2c: timeout for fifo out full
      
      To make block mode working properly and move to use the interrupts
      instead of polling, major code reorganization is required. Following
      are the major changes done in this patch
      
      1. Remove the polling of TX FIFO free space and RX FIFO available
         bytes and move to interrupts completely. QUP has QUP_MX_OUTPUT_DONE,
         QUP_MX_INPUT_DONE, OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ
         interrupts to handle FIFO’s properly so check all these interrupts.
      2. Determine the mode for transfer before starting by checking
         all the tx/rx data length in each message. The complete message can be
         transferred either in DMA mode or Programmed IO by FIFO/Block mode.
         in DMA mode, both tx and rx uses same mode but in PIO mode, the TX and
         RX can be in different mode.
      3. During write, For FIFO mode, TX FIFO can be directly written
         without checking for FIFO space. For block mode, the QUP will generate
         OUT_BLOCK_WRITE_REQ interrupt whenever it has block size of available
         space.
      4. During read, both TX and RX FIFO will be used. TX will be used
         for writing tags and RX will be used for receiving the data. In QUP,
         TX and RX can operate in separate mode so configure modes accordingly.
      5. For read FIFO mode, wait for QUP_MX_INPUT_DONE interrupt which
         will be generated after all the bytes have been copied in RX FIFO. For
         read Block mode, QUP will generate IN_BLOCK_READ_REQ interrupts
         whenever it has block size of available data.
      6. Split the transfer in chunk of one QUP block size(256 bytes)
         and schedule each block separately. QUP v2 supports reconfiguration
         during run in which QUP can transfer multiple blocks without issuing a
         stop events.
      7. Port the SMBus block read support for new code changes.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarSricharan R <sricharan@codeaurora.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      7545c7db
    • Abhishek Sahu's avatar
      i2c: qup: reorganization of driver code to remove polling for qup v1 · fbfab1ab
      Abhishek Sahu authored
      Following are the major issues in current driver code
      
      1. The current driver simply assumes the transfer completion
         whenever its gets any non-error interrupts and then simply do the
         polling of available/free bytes in FIFO.
      2. The block mode is not working properly since no handling in
         being done for OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ.
      
      Because of above, i2c v1 transfers of size greater than 32 are failing
      with following error message
      
      	i2c_qup 78b6000.i2c: timeout for fifo out full
      
      To make block mode working properly and move to use the interrupts
      instead of polling, major code reorganization is required. Following
      are the major changes done in this patch
      
      1. Remove the polling of TX FIFO free space and RX FIFO available
         bytes and move to interrupts completely. QUP has QUP_MX_OUTPUT_DONE,
         QUP_MX_INPUT_DONE, OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ
         interrupts to handle FIFO’s properly so check all these interrupts.
      2. During write, For FIFO mode, TX FIFO can be directly written
         without checking for FIFO space. For block mode, the QUP will generate
         OUT_BLOCK_WRITE_REQ interrupt whenever it has block size of available
         space.
      3. During read, both TX and RX FIFO will be used. TX will be used
         for writing tags and RX will be used for receiving the data. In QUP,
         TX and RX can operate in separate mode so configure modes accordingly.
      4. For read FIFO mode, wait for QUP_MX_INPUT_DONE interrupt which
         will be generated after all the bytes have been copied in RX FIFO. For
         read Block mode, QUP will generate IN_BLOCK_READ_REQ interrupts
         whenever it has block size of available data.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarSricharan R <sricharan@codeaurora.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      fbfab1ab
    • Abhishek Sahu's avatar
      i2c: qup: send NACK for last read sub transfers · f7714b4e
      Abhishek Sahu authored
      According to I2c specification, “If a master-receiver sends a
      repeated START condition, it sends a not-acknowledge (A) just
      before the repeated START condition”. QUP v2 supports sending
      of NACK without stop with QUP_TAG_V2_DATARD_NACK so added the
      same.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAustin Christ <austinwc@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      f7714b4e
    • Abhishek Sahu's avatar
      i2c: qup: fix buffer overflow for multiple msg of maximum xfer len · 6f2f0f64
      Abhishek Sahu authored
      The BAM mode requires buffer for start tag data and tx, rx SG
      list. Currently, this is being taken for maximum transfer length
      (65K). But an I2C transfer can have multiple messages and each
      message can be of this maximum length so the buffer overflow will
      happen in this case. Since increasing buffer length won’t be
      feasible since an I2C transfer can contain any number of messages
      so this patch does following changes to make i2c transfers working
      for multiple messages case.
      
      1. Calculate the required buffers for 2 maximum length messages
         (65K * 2).
      2. Split the descriptor formation and descriptor scheduling.
         The idea is to fit as many messages in one DMA transfers for 65K
         threshold value (max_xfer_sg_len). Whenever the sg_cnt is
         crossing this, then schedule the BAM transfer and subsequent
         transfer will again start from zero.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      6f2f0f64
    • Abhishek Sahu's avatar
      i2c: qup: change completion timeout according to transfer length · ecb6e1e5
      Abhishek Sahu authored
      Currently the completion timeout is being taken according to
      maximum transfer length which is too high if SCL is operating in
      high frequency. This patch calculates timeout on the basis of
      one-byte transfer time and uses the same for completion timeout.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      ecb6e1e5
    • Abhishek Sahu's avatar
      i2c: qup: use the complete transfer length to choose DMA mode · 08f15963
      Abhishek Sahu authored
      Currently each message length in complete transfer is being
      checked for determining DMA mode and if any of the message length
      is less than FIFO length then non DMA mode is being used which
      will increase overhead. DMA can be used for any length and it
      should be determined with complete transfer length. Now, this
      patch selects DMA mode if the total length is greater than FIFO
      length.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAustin Christ <austinwc@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      08f15963
    • Abhishek Sahu's avatar
      i2c: qup: proper error handling for i2c error in BAM mode · 3f450d3e
      Abhishek Sahu authored
      Currently the i2c error handling in BAM mode is not working
      properly in stress condition.
      
      1. After an error, the FIFO are being written with FLUSH and
         EOT tags which should not be required since already these tags
         have been written in BAM descriptor itself.
      
      2. QUP state is being moved to RESET in IRQ handler in case
         of error. When QUP HW encounters an error in BAM mode then it
         moves the QUP STATE to PAUSE state. In this case, I2C_FLUSH
         command needs to be executed while moving to RUN_STATE by writing
         to the QUP_STATE register with the I2C_FLUSH bit set to 1.
      
      3. In Error case, sometimes, QUP generates more than one
         interrupt which will trigger the complete again. After an error,
         the flush operation will be scheduled after doing
         reinit_completion which should be triggered by BAM IRQ callback.
         If the second QUP IRQ comes during this time then it will call
         the complete and the transfer function will assume the all the
         BAM HW descriptors have been completed.
      
      4. The release DMA is being called after each error which
         will free the DMA tx and rx channels. The error like NACK is very
         common in I2C transfer and every time this will be overhead. Now,
         since the error handling is proper so this release channel can be
         completely avoided.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarSricharan R <sricharan@codeaurora.org>
      Reviewed-by: default avatarAustin Christ <austinwc@codeaurora.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      3f450d3e
    • Abhishek Sahu's avatar
      i2c: qup: fix the transfer length for BAM RX EOT FLUSH tags · 7e6c35fe
      Abhishek Sahu authored
      In case of FLUSH operation, BAM copies INPUT EOT FLUSH (0x94)
      instead of normal EOT (0x93) tag in input data stream when an
      input EOT tag is received during flush operation. So only one tag
      will be written instead of 2 separate tags.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      7e6c35fe
    • Abhishek Sahu's avatar
      i2c: qup: schedule EOT and FLUSH tags at the end of transfer · c5adc0fa
      Abhishek Sahu authored
      The role of FLUSH and EOT tag is to flush already scheduled
      descriptors in BAM HW in case of error. EOT is required only
      when descriptors are scheduled in RX FIFO. If all the messages
      are WRITE, then only FLUSH tag will be used.
      
      A single BAM transfer can have multiple read and write messages.
      The EOT and FLUSH tags should be scheduled at the end of BAM HW
      descriptors. Since the READ and WRITE can be present in any order
      so for some of the cases, these tags are not being written
      correctly.
      
      Following is one of the example
      
         READ, READ, READ, READ
      
      Currently EOT and FLUSH tags are being written after each READ.
      If QUP gets NACK for first READ itself, then flush will be
      triggered. It will look for first FLUSH tag in TX FIFO and will
      stop there so only descriptors for first READ descriptors be
      flushed. All the scheduled descriptors should be cleared to
      generate BAM DMA completion.
      
      Now this patch is scheduling FLUSH and EOT only once after all the
      descriptors. So, flush will clear all the scheduled descriptors and
      BAM will generate the completion interrupt.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarSricharan R <sricharan@codeaurora.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      c5adc0fa
    • Abhishek Sahu's avatar
      i2c: qup: remove redundant variables for BAM SG count · 6d5f37f1
      Abhishek Sahu authored
      The rx_nents and tx_nents are redundant. rx_buf and tx_buf can
      be used for total number of SG entries. Since rx_buf and tx_buf
      give the impression that it is buffer instead of count so rename
      it to tx_cnt and rx_cnt for giving it more meaningful variable
      name.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAustin Christ <austinwc@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      6d5f37f1
    • Abhishek Sahu's avatar
      i2c: qup: minor code reorganization for use_dma · eb422b53
      Abhishek Sahu authored
      1. Assigns use_dma in qup_dev structure itself which will
         help in subsequent patches to determine the mode in IRQ handler.
      2. Does minor code reorganization for loops to reduce the
         unnecessary comparison and assignment.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Reviewed-by: default avatarAustin Christ <austinwc@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      eb422b53
    • Abhishek Sahu's avatar
      i2c: qup: fixed releasing dma without flush operation completion · 7239872f
      Abhishek Sahu authored
      The QUP BSLP BAM generates the following error sometimes if the
      current I2C DMA transfer fails and the flush operation has been
      scheduled
      
          “bam-dma-engine 7884000.dma: Cannot free busy channel”
      
      If any I2C error comes during BAM DMA transfer, then the QUP I2C
      interrupt will be generated and the flush operation will be
      carried out to make I2C consume all scheduled DMA transfer.
      Currently, the same completion structure is being used for BAM
      transfer which has already completed without reinit. It will make
      flush operation wait_for_completion_timeout completed immediately
      and will proceed for freeing the DMA resources where the
      descriptors are still in process.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Acked-by: default avatarSricharan R <sricharan@codeaurora.org>
      Reviewed-by: default avatarAustin Christ <austinwc@codeaurora.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      7239872f
    • Abhishek Sahu's avatar
      i2c: qup: fix copyrights and update to SPDX identifier · 0668bc44
      Abhishek Sahu authored
      The file has been updated from 2016 to 2018 so fixed the
      copyright years.
      Signed-off-by: default avatarAbhishek Sahu <absahu@codeaurora.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      0668bc44
  2. 17 Mar, 2018 7 commits
  3. 06 Mar, 2018 2 commits
  4. 05 Mar, 2018 1 commit
    • Javier Martinez Canillas's avatar
      i2c: core: report OF style module alias for devices registered via OF · af503716
      Javier Martinez Canillas authored
      The buses should honor the firmware interface used to register the device,
      but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C
      devices registered via OF.
      
      This means that user-space will never get an OF stype uevent MODALIAS even
      when the drivers modules contain aliases exported from both the I2C and OF
      device ID tables. For example, an Atmel maXTouch Touchscreen registered by
      a DT node with compatible "atmel,maxtouch" has the following module alias:
      
      $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
      i2c:maxtouch
      
      So udev won't be able to auto-load a module for an OF-only device driver.
      Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
      table only has a workaround for how the I2C core reports the module alias.
      
      This patch changes the I2C core to report an OF related MODALIAS uevent if
      the device was registered via OF. So for the previous example, after this
      patch, the reported MODALIAS for the Atmel maXTouch will be the following:
      
      $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
      of:NtrackpadT<NULL>Catmel,maxtouch
      
      NOTE: This patch may break out-of-tree drivers that were relying on this
            behavior, and only had an I2C device ID table even when the device
            was registered via OF. There are no remaining drivers in mainline
            that do this, but out-of-tree drivers have to be fixed and define
            a proper OF device ID table to have module auto-loading working.
      Signed-off-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Tested-by: default avatarDmitry Mastykin <mastichi@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      af503716
  5. 02 Mar, 2018 3 commits
  6. 27 Feb, 2018 4 commits
  7. 26 Feb, 2018 8 commits