1. 11 3月, 2011 9 次提交
  2. 10 1月, 2011 2 次提交
  3. 23 10月, 2010 1 次提交
  4. 05 8月, 2010 12 次提交
  5. 03 8月, 2010 6 次提交
    • T
      OMAP: DSS2: DSI: change DSI timeout functions · 4ffa3571
      Tomi Valkeinen 提交于
      Using nanoseconds as arguments to functions that set the DSI timeouts was
      perhaps not so good idea. The timeouts are based on different DSI clocks,
      so the possible range for the timeouts vary greatly depending on the
      clocks. Also, the multipliers used with the timeouts cause big gaps in the
      timeout range, meaning that the nanosecond based functions could cause the
      timeout to be quite far from the intended value.
      
      This patch changes the functions to take the plain tick values with the
      multiplier enable/disable bits, and sets the TA/LP_RX/HS_TX timeouts to
      maximum. While the timeouts could be much lower, the fact is that when
      TA/LP_RX/HS_TX timeout happens, we are in an error situation and not in a
      hurry anyway.
      
      STOP_STATE_COUNTER is a different matter, but it is only used at
      initialization time, and won't normally affect the performance.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      4ffa3571
    • T
      OMAP: DSS2: DSI: handle error in synchronous write · b63ac1e3
      Tomi Valkeinen 提交于
      Check if the peripheral answered something, and if so, dump the data
      and return an error.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      b63ac1e3
    • T
      OMAP: DSS2: DSI: change dsi_vc_dcs_read_2 parameters · 0c244f77
      Tomi Valkeinen 提交于
      Change dsi_vc_dcs_read_2() data parameter to two u8 parameters to make the
      byte-order clear.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      0c244f77
    • T
      OMAP: DSS2: DSI: use a private workqueue · 0f16aa0a
      Tomi Valkeinen 提交于
      Using the shared workqueue led to to a deadlock in the case where the
      display was unblanked via keyboard.
      
      What happens is something like this:
      
      - User presses a key
      
      context 1:
      - drivers/char/keyboard.c calls schedule_console_callback()
      - fb_unblank takes the console semaphore
      - dsi bus lock is taken, and frame transfer is started (dsi bus lock is
        left on)
      - Unblank code tries to set the panel backlight, which tries to take dsi
        bus lock, but is blocked while the frame transfer is going on
      
      context 2, shared workqueue, console_callback in drivers/char/vt.c:
      - Tries to take console semaphore
      - Blocks, as console semaphore is being held by context 1
      - No other shared workqueue work can be run
      
      context 3, HW irq, caused by FRAMEDONE interrupt:
      - Interrupt handler schedules framedone-work in shared workqueue
      - Framedone-work is never ran, as the shared workqueue is blocked. This
        means that the unblank thread stays blocked, which means that context 2
        stays blocked.
      
      While I think the real problem is in keyboard/virtual terminal code, using
      a private workqueue in the DSI driver is perhaps safer and more robust
      than using the shared one. The DSI works should not be delayed more than a
      millisecond or so, and even if the private workqueue gives us no hard
      promise of doing so, it's still safer bet than the shared workqueue.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      0f16aa0a
    • T
      OMAP: DSS2: DSI: print errors in dsi_vc_flush_receive_data() · 86a7867e
      Tomi Valkeinen 提交于
      dsi_vc_flush_receive_data() is meant to dump data when something has gone
      wrong, and thus we should use DSSERR, not DSSDBG.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      86a7867e
    • T
      OMAP: DSS2: DSI: Increase HS TX timeout · 5ab8e30c
      Tomi Valkeinen 提交于
      For some reason screen updates of certain odd widths seem to be triggering
      HS TX timeouts on OMAP 3430, even if bigger updates do not. The reason for
      this is unknown, but increasing the timeout removes the problem with no
      (so far) noticeable problems. I haven't seen this problem on OMAP 3630.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      5ab8e30c
  6. 26 2月, 2010 2 次提交
  7. 24 2月, 2010 8 次提交