Eric Lee / smarc-uboot

20 Feb, 2014

1 commit

  • d22643e7e   i2c: i2c-mxs: Wait for I2C to empty queue ... Browse Code »

    Make sure the I2C write queue is empty before leaving the mxs_i2c_write().
    If we start and I2C write and only wait for ACK, the MXS I2C IP block may
    enter next operation while still processing the write aftermath internally.
    This will in turn disrupt one or more subsequent transfer(s).

    A testcase for this issue is as such. This testcase is also interesting because
    the first I2C_WRITE which becomes disruptive happens in the 'i2c read' command.
    The 'i2c read' command first uses I2C_WRITE to send I2C address of the chip and
    then uses I2C_READ to read data from the chip. After this command completes, the
    'i2c probe' will use sequence of I2C_WRITE commands to probe the I2C bus. The
    problem is that the first I2C_WRITE disrupted the I2C IP block operation and
    this sideeffect propagates all the way to this next I2C_WRITE used by the 'i2c
    probe' call. The result is the 'i2c probe' receives an ACK on I2C address 0x00,
    even if this ACK was owned by the previous I2C_WRITE operation. Note that the
    'i2c read' command must read from a valid I2C chip address.

    Wrong:
    > i2c probe
    Valid chip addresses: 50 51
    > i2c read 0x50 0x0.2 0x10 0x42000000
    > i2c probe
    Valid chip addresses: 00 50 51

    With this patch
    > i2c probe
    Valid chip addresses: 50 51
    > i2c read 0x50 0x0.2 0x10 0x42000000
    > i2c probe
    Valid chip addresses: 50 51

    Signed-off-by: Marek Vasut
    Cc: Heiko Schocher
    Cc: Fabio Estevam

    Marek Vasut
     

13 Nov, 2013

1 commit

  • 124913556   i2c: mxs_i2c: Squash endless loop ... Browse Code »

    The endless waiting for a bit to be set can cause a hang, add a timeout
    so we prevent such situation. A testcase for such a hang is below. The
    testcase assumes a device to be present at address 0x50 and a device to
    NOT be present at address 0x42 . Also note that the "sleep 1" induced
    delays are imperative for this bug to manifest .

    i2c read 0x42 0x0.2 0x10 0x42000000 ; sleep 1 ; \
    i2c read 0x50 0x0.2 0x10 0x42000000 ; sleep 1 ; \
    i2c read 0x42 0x0.2 0x10 0x42000000

    The expected result of the above command is:

    Error reading the chip.
    Error reading the chip.

    While without this patch, we observe a hang in the last read from 0x42
    precisely when waiting for this bit to be set.

    Signed-off-by: Marek Vasut
    Cc: Fabio Estevam
    Cc: Heiko Schocher
    Cc: Stefano Babic

    Marek Vasut
     

24 Jul, 2013

1 commit

29 Jan, 2013

1 commit

12 Dec, 2012

6 commits

  • fa5e2845a   mxs: i2c: Implement algorithm to set up arbitrary i2c speed ... Browse Code »

    This algorithm computes the values of TIMING{0,1,2} registers for the
    MX28 I2C block. This algorithm was derived by using a scope, but the
    result seems correct.

    The resulting values programmed into the registers do not correlate
    with the contents in datasheet. When using the values from the datasheet,
    the I2C clock were completely wrong.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam
    Cc: Wolfgang Denk

    Marek Vasut
     
  • 1e2fc0d19   mxs: i2c: Restore speed setting after block reset ... Browse Code »

    The I2C block reset configures the I2C bus speed to strange value.
    Read the I2C speed from the block before reseting the block and
    restore it afterwards, so the I2C operates correctly. This issue
    can be replicated by doing unsuccessful I2C transfer, after such
    transfer finishes, the I2C block clock speed is misconfigured.

    Signed-off-by: Marek Vasut
    Cc: Heiko Schocher
    Cc: Fabio Estevam

    Marek Vasut
     
  • aff36ea92   i2c: mxs: Fix TIMING2 register value ... Browse Code »

    According to FSL, the value in the TIMING2 register shall be 0x00300030
    instead of what's written in the datasheet. This new value correlates
    with older STMP36xx datasheet. Issues were detected in Linux when this
    register was misconfigured, so write this correct value.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam

    Marek Vasut
     
  • a157e0d5f   i2c: mxs: Use i2c_set_bus_speed() in i2c_init() ... Browse Code »

    Use i2c_set_bus_speed() in i2c_init() within the mxs i2c driver
    to avoid duplication of code.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam

    Marek Vasut
     
  • a06f590f7   i2c: mxs: Implement i2c_get/set_bus_speed() ... Browse Code »

    This patch implements the setup and retrieval functions for the I2C
    bus speed on the MXS I2C IP.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam

    Marek Vasut
     
  • f32a470ed   i2c: mxs: Abstract out the MXS I2C speed setup ... Browse Code »

    This patch pulls out the I2C speed setup from the i2c_init() call
    and implements the bus configuration lookup table with register
    values that needs to be programmed into the I2C IP to run at
    particular speed.

    This patch is a first step towards implementing run-time I2C bus
    speed configuration for the MXS I2C IP.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam

    Marek Vasut
     

01 Sep, 2012

2 commits

11 Jul, 2012

1 commit

  • fa86d1c0b   mxs-i2c: Fix internal address byte order ... Browse Code »

    Large EEPROMs, e.g. 24lc32, need 2 byte to address the internal memory.
    These devices require that the high byte of the internal address has to be
    written first.
    The mxs_i2c driver currently writes the address' low byte first.

    The following patch fixes the byte order of the internal address that should
    be written to the I2C device.

    Signed-off-by: Torsten Fleischer

    CC: Marek Vasut
    CC: Stefano Babic
    CC: Fabio Estevam
    Acked-by: Marek Vasut
    Acked-by: Stefano Babic

    Torsten Fleischer
     

11 Nov, 2011

1 commit