1. 11 3月, 2011 3 次提交
  2. 10 1月, 2011 11 次提交
  3. 23 10月, 2010 3 次提交
  4. 29 9月, 2010 1 次提交
  5. 05 8月, 2010 15 次提交
  6. 03 8月, 2010 7 次提交
    • 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: Fix update area calculations with multiple scaled overlays · 8cab90fd
      Tomi Valkeinen 提交于
      When there are multiple scaled overlays simply checking whether the update
      area intersects any of them in order is not enough. If eg. VID1 starts out
      completely outside the update area but VID2 causes the update area to
      increase in such a way that VID1 now falls partially within the increased
      update area VID1 should be rechecked and the update area possibly
      increased even further to fully encompass VID1. So simply keep looping
      over the overlays until such time that none of the overlays caused the
      update area to change.
      Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      8cab90fd
    • V
      OMAP: DSS2: clear spurious SYNC_LOST_DIGIT interrupts · 75c7d59d
      Ville Syrjälä 提交于
      When DSS transitions from off mode to on VENC may generate a spurious
      SYNC_LOST_DIGIT error. Just ack it when restoring the context. Also
      restore IRQENABLE last to avoid triggering interrupts before the
      context is fully restored.
      Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      75c7d59d