1. 23 May, 2019 4 commits
  2. 22 May, 2019 4 commits
  3. 21 May, 2019 8 commits
  4. 20 May, 2019 11 commits
  5. 19 May, 2019 1 commit
  6. 18 May, 2019 3 commits
  7. 17 May, 2019 3 commits
    • Trent Piepho's avatar
      i2c: mxc: Hide kconfig based control in DM_I2C mode · ca0a8f3e
      Trent Piepho authored and Heiko Schocher's avatar Heiko Schocher committed
      
      
      These options only apply when not using DM_I2C.  When using device
      trees, the dt will enable and control the speeds of the I2C
      controller(s) and these configuration options have no effect.
      
      So disable them in DM_I2C mode.  Otherwise they show up as decoys, and
      make it look like one is enabling I2C controllers and setting the speed
      when really it's doing nothing.
      
      However, a system using a SPL build will not use DM_I2C in the SPL, even
      if DM_I2C is enabled for the main u-boot.  And so the SPL might use the
      kconfig based I2C speed controls while the main u-boot does not.
      
      Cc: Sriram Dash <sriram.dash@nxp.com>
      Cc: Priyanka Jain <priyanka.jain@nxp.com>
      Cc: Heiko Schocher <hs@denx.de>
      Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
      ca0a8f3e
    • Trent Piepho's avatar
      i2c: mxc_i2c: Fix read and read->write xfers in DM mode · c854933f
      Trent Piepho authored and Heiko Schocher's avatar Heiko Schocher committed
      This is an old driver that supports both device mapped and non-mapped
      mode, and covers a wide range of hardware.  It's hard to change without
      risking breaking something.  I have to tried to be exceedingly detailed
      in this patch, so please excuse the length of the commit essay that
      follows.
      
      In device mapped mode the I2C xfer function does not handle plain read,
      and some other, transfers correctly.
      
      What it can't handle are transactions that:
          Start with a read, or,
          Have a write followed by a read, or,
          Have more than one read in a row.
      
      The common I2C/SMBUS read register and write register transactions
      always start with a write, followed by a write or a read, and then end.
      These work, so the bug is not apparent for most I2C slaves that only use
      these common xfer forms.
      
      The existing xfer loop initializes by sending the chip address in write
      mode after it deals with bus arbitration and master setup.  When
      processing each message, if the next message will be a read, it sends a
      repeated start followed by the chip address in read mode after the
      current message.
      
      Obviously, this does not work if the first message is a read, as the
      chip is always addressed in write mode initially by i2c_init_transfer().
      
      A write following a read does not work because the repeated start is
      only sent when the next message is a read.  There is no logic to send it
      when the current message is a read and next is write.  It should be sent
      every time the bus changes direction.
      
      The ability to use a plain read was added to this driver in
      commit 2feec4ea
      
       ("imx: mxc_i2c: tweak the i2c transfer method"),
      but this applied only the non-DM code path.
      
      This patch fixes the DM code path.  The xfer function will call
      i2c_init_transfer() with an alen of -1 to avoid sending the chip
      address.  The same way the non-DM code achieves this.  The xfer
      function's message loop will send the address and mode before each
      message if the bus changes direction, and on the first message.
      
      When reading data, the master hardware is one byte ahead of what we
      receive.  I.e., reading a byte from the data register returns a byte
      *already received* by the master, and causes the master to start the RX
      of the *next* byte.  Therefor, before we read the final byte of a
      message, we must tell the master what to do next.  I add a "last" flag
      to i2c_read_data() to tell it if the message is to be followed by a stop
      or a repeated start.  When last == true it acts exactly as before.
      
      The non-DM code can only create an xfer where the read, if any, is the
      final message of the xfer.  And so the only callsite of i2c_read_data()
      in the non-DM code has the "last" parameter as true.  Therefore, this
      change has no effect on the non-DM code.  As all other changes are in
      the DM xfer function, which is not even compiled in non-DM code, I am
      confident that this patch has no effect on boards not using I2C_DM.
      This greatly reduces the range of hardware that could be affected.
      
      For DM boards, I have verified every transaction the "i2c" command can
      create on a scope and they are all exactly as they are supposed to be.
      I also tested write->read->write, which isn't possible with the i2c
      command, and it works as well.  I didn't fix multiple reads in a row, as
      it's a lot more invasive and obviously no one has every wanted them
      since they've never worked.  It didn't seem like the extra complexity
      was justified to support something no one uses.
      
      Cc: Nandor Han <nandor.han@ge.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Breno Matheus Lima <brenomatheus@gmail.com>
      Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
      c854933f
    • Trent Piepho's avatar
      i2c: mxc_i2c: Document how non-DM functions work · 6314b3c7
      Trent Piepho authored and Heiko Schocher's avatar Heiko Schocher committed
      
      
      It is not very clear how these work in relation to the exact I2C xfers
      they produce.  In paticular, the address length is somewhat overloaded
      in the read method.  Clearly document the existing behavior.  Maybe this
      will help the next person who needs to work on this driver and not break
      non-DM boards.
      
      Cc: Nandor Han <nandor.han@ge.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Breno Matheus Lima <brenomatheus@gmail.com>
      Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
      6314b3c7
  8. 14 May, 2019 5 commits
  9. 10 May, 2019 1 commit