1. 15 11月, 2012 1 次提交
    • 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 7 次提交
    • N
      I2C: OMAP: Fix timeout problem during suspend. · b4fde5e7
      Neil Brown 提交于
      On a board with OMAP3 processor and TWL4030 Power management,
      we need to talk to the TWL4030 during late suspend but cannot
      because the I2C interrupt is disabled (as late suspend disables
      interrupt).
      
      e.g. I get messages like:
      
      [   62.161102] musb-omap2430 musb-omap2430: LATE power domain suspend
      [   63.167205] omap_i2c omap_i2c.1: controller timed out
      [   63.183044] twl: i2c_read failed to transfer all messages
      [   64.182861] omap_i2c omap_i2c.1: controller timed out
      [   64.198455] twl: i2c_write failed to transfer all messages
      [   65.198455] omap_i2c omap_i2c.1: controller timed out
      [   65.203765] twl: i2c_write failed to transfer all messages
      
      The stack shows omap2430_runtime_suspend calling twl4030_set_suspend
      which tries to power-down the USB PHY (twl4030_phy_suspend ->
      twl4030_phy_power -> __twl4030_phy_power which as a nice WARN_ON
      that helps).
      
      Then we get the same in resume:
      
      [   69.603912] musb-omap2430 musb-omap2430: EARLY power domain resume
      [   70.610473] omap_i2c omap_i2c.1: controller timed out
      [   70.626129] twl: i2c_write failed to transfer all messages
      etc.
      
      So don't disable interrupts for I2C.
      Acked-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      b4fde5e7
    • S
      I2C: OMAP: Rename the 1p153 to the erratum id i462 · c8db38f0
      Shubhrajyoti D 提交于
      The section number in the recent errata document has changed.
      Rename the erratum 1p153 to the unique id i462 instead, so that
      it is easier to reference. Also change the function name and comments
      to reflect the same.
      
      Cc: Jon Hunter <jon-hunter@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      c8db38f0
    • S
      I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached · e7e62df0
      Shubhrajyoti D 提交于
      Currently in the 1.153 errata handling, while waiting for transmitter
      underflow, if NACK is got the XUDF(Transmit underflow) flag is also set.
      Fix this by setting the XUDF(Transmit underflow) flag after wait for the
      condition is over.
      
      Cc: Alexander Shishkin <virtuoso@slind.org>
      Acked-by: NMoiz Sonasath <m-sonasath@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      e7e62df0
    • T
      I2C: OMAP: prevent the overwrite of the errata flags · 9aa8ec67
      Tasslehoff Kjappfot 提交于
      i2c_probe set the dev->errata flag, but omap_i2c_init cleared the flag again.
      Prevent the overwrite of the errata flags.Move the errata handling to a unified
      place in probe to prevent such errors.
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTasslehoff Kjappfot <tasskjapp@gmail.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      9aa8ec67
    • S
      I2C: OMAP: Handle error check for pm runtime · 3b0fb97c
      Shubhrajyoti D 提交于
      If PM runtime get_sync fails return with the error
      so that no further reads/writes goes through the interface.
      This will avoid possible abort. Add a error message in case
      of failure with the cause of the failure.
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      3b0fb97c
    • S
      I2C: OMAP: Fix the crash in i2c remove · 0861f430
      Shubhrajyoti D 提交于
          In omap_i2c_remove we are accessing the I2C_CON register without
          enabling the clocks. Fix the same by ensure device is accessible by calling
          pm_runtime_get_sync before accessing the registers and calling pm_runtime_put
          after accessing.
      
          This fixes the following crash.
          [  154.723022] ------------[ cut here ]------------
          [  154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4()
          [  154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2
          [  154.742614] Modules linked in: i2c_omap(-)
          [  154.746948] Backtrace:
          [  154.746948] [<c0013078>] (dump_backtrace+0x0/0x110) from [<c026c158>] (dump_stack+0x18/0x1c)
          [  154.752716]  r6:00000070 r5:c002c43c r4:df9b9e98 r3:df9b8000
          [  154.764465] [<c026c140>] (dump_stack+0x0/0x1c) from [<c0041a2c>] (warn_slowpath_common+0x5c/0x6c)
          [  154.768341] [<c00419d0>] (warn_slowpath_common+0x0/0x6c) from [<c0041ae0>] (warn_slowpath_fmt+0x38/0x40)
          [  154.776153]  r8:00000180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00
          [  154.790771] r3:00000009
          [  154.791778] [<c0041aa8>] (warn_slowpath_fmt+0x0/0x40) from [<c002c43c>] (l3_interrupt_handler+0x1b4/0x1c4)
          [  154.803710]  r3:c0361598 r2:c02ef74c
          [  154.807403] [<c002c288>] (l3_interrupt_handler+0x0/0x1c4) from [<c0085f44>] (handle_irq_event_percpu+0x58/0
          [  154.818237]  r8:0000002a r7:00000000 r6:00000000 r5:df808054 r4:df8893c0
          [  154.825378] [<c0085eec>] (handle_irq_event_percpu+0x0/0x188) from [<c00860b8>] (handle_irq_event+0x44/0x64)
          [  154.835662] [<c0086074>] (handle_irq_event+0x0/0x64) from [<c0088ec0>] (handle_fasteoi_irq+0xa4/0x10c)
          [  154.845458]  r6:0000002a r5:df808054 r4:df808000 r3:c034a150
          [  154.846466] [<c0088e1c>] (handle_fasteoi_irq+0x0/0x10c) from [<c0085ed0>] (generic_handle_irq+0x30/0x38)
          [  154.854278]  r5:c034aa48 r4:0000002a
          [  154.862091] [<c0085ea0>] (generic_handle_irq+0x0/0x38) from [<c000fd38>] (handle_IRQ+0x60/0xc0)
          [  154.874450]  r4:c034ea70 r3:000001f8
          [  154.878234] [<c000fcd8>] (handle_IRQ+0x0/0xc0) from [<c0008478>] (gic_handle_irq+0x20/0x5c)
          [  154.887023]  r7:ffffff40 r6:df9b9fb0 r5:c034e2b4 r4:0000001a
          [  154.887054] [<c0008458>] (gic_handle_irq+0x0/0x5c) from [<c000ea80>] (__irq_usr+0x40/0x60)
          [  154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8)
          [  154.907104] 9fa0:                                     beaf1f04 4006be00 0000000f 0000000c
          [  154.915710] 9fc0: 4006c000 00000000 00008034 ffffff40 00000007 00000000 00000000 0007b8d7
          [  154.916778] 9fe0: 00000000 beaf1b68 0000d23c 4005baf0 80000010 ffffffff
          [  154.931335]  r6:ffffffff r5:80000010 r4:4005baf0 r3:beaf1f04
          [  154.937316] ---[ end trace 1b75b31a2719ed21 ]--
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Linux PM list <linux-pm@vger.kernel.org>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      0861f430
    • S
      I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero · 33d54985
      Shubhrajyoti D 提交于
      By definition, wait_for_completion_timeout() returns an unsigned value and
      therefore, it is not necessary to check if the return value is less than zero
      as this is not possible.
      
      This is based on a patch from Jon Hunter <jon-hunter@ti.com>
      Changes from his patch
      - Declare a long as the wait_for_completion_timeout returns long.
      
      Original patch is
      http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7b0000bc736e60c4188a11aaa74bc6e6Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      33d54985