1. 05 8月, 2010 2 次提交
  2. 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
  3. 26 2月, 2010 2 次提交
  4. 24 2月, 2010 13 次提交
  5. 23 2月, 2010 1 次提交
  6. 15 2月, 2010 6 次提交
  7. 12 2月, 2010 1 次提交
    • T
      OMAP: DSS2: enable VDDS_DSI when using DPI · 8a2cfea8
      Tomi Valkeinen 提交于
      It looks like on OMAP3 some DSS pins need VDDS_DSI to function properly.
      
      This has not been confirmed from TI, but looking at figure 15-1 "Display
      subsystem highlight" from the TRM, some data pins come near the DSI and SDI
      blocks. This is not very hard evidence, but the fact remains that with the
      power on, pixels are ok, and with the power off, pixels are not ok.
      
      It may also be that VDDS_SDI is needed to power some pins, but as normally
      both VDDS_SDI and VDDS_DSI come from the same power source, this hasn't
      been shown.
      
      It seems that a single driver can only get a regulator once. This patch
      solves it by getting all the required regulators in one place, and from
      which the submodules then get the regulators they need.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      8a2cfea8
  8. 11 1月, 2010 1 次提交
  9. 08 1月, 2010 4 次提交
  10. 09 12月, 2009 1 次提交