1. 15 11月, 2012 4 次提交
    • S
      i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207 · a748021c
      Shubhrajyoti D 提交于
      The errata i207 is enabled for 2430 and 3xxx. Use the revision check
      to enable the erratum instead.
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      a748021c
    • S
      i2c: omap: Fix the revision register read · 47dcd016
      Shubhrajyoti D 提交于
      The revision register on OMAP4 is a 16-bit lo and a 16-bit
      hi. Currently the driver reads only the lower 8-bits.
      Fix the same by preventing the truncating of the rev register
      for OMAP4.
      
      Also use the scheme bit ie bit-14 of the hi register to know if it
      is OMAP_I2C_IP_VERSION_2.
      
      On platforms previous to OMAP4 the offset 0x04 is IE register whose
      bit-14 reset value is 0, the code uses the same to its advantage.
      
      Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
      to fetch the revision register.
      
      The dev->regs is populated after reading the rev_hi. A NULL check
      has been added in the resume handler to prevent the access before
      the setting of the regs.
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      47dcd016
    • S
      i2c: omap: adopt pinctrl support · 2d4b4520
      Sebastien Guiriec 提交于
      Some GPIO expanders need some early pin control muxing. Due to
      legacy boards sometimes the driver uses subsys_initcall instead of
      module_init. This patch takes advantage of defer probe feature
      and pin control in order to wait until pin control probing before
      GPIO driver probing. It has been tested on OMAP5 board with TCA6424
      driver.
      Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
      Acked-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      2d4b4520
    • F
      i2c: omap: ensure writes to dev->buf_len are ordered · d60ece5f
      Felipe Balbi 提交于
      if we allow compiler reorder our writes, we could
      fall into a situation where dev->buf_len is reset
      for no apparent reason.
      
      This bug was found with a simple script which would
      transfer data to an i2c client from 1 to 1024 bytes
      (a simple for loop), when we got to transfer sizes
      bigger than the fifo size, dev->buf_len was reset
      to zero before we had an oportunity to handle XDR
      Interrupt. Because dev->buf_len was zero, we entered
      omap_i2c_transmit_data() to transfer zero bytes,
      which would mean we would just silently exit
      omap_i2c_transmit_data() without actually writing
      anything to DATA register. That would cause XDR
      IRQ to trigger forever and we would never transfer
      the remaining bytes.
      
      After adding the memory barrier, we also drop resetting
      dev->buf_len to zero in omap_i2c_xfer_msg() because
      both omap_i2c_transmit_data() and omap_i2c_receive_data()
      will act until dev->buf_len reaches zero, rendering the
      other write in omap_i2c_xfer_msg() redundant.
      
      This patch has been tested with pandaboard for a few
      iterations of the script mentioned above.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      d60ece5f
  2. 14 11月, 2012 1 次提交
  3. 06 10月, 2012 1 次提交
  4. 12 9月, 2012 23 次提交
  5. 11 9月, 2012 1 次提交
  6. 18 8月, 2012 1 次提交
  7. 24 7月, 2012 1 次提交
  8. 12 7月, 2012 4 次提交
  9. 08 7月, 2012 4 次提交