1. 14 7月, 2017 1 次提交
  2. 13 7月, 2017 2 次提交
  3. 04 7月, 2017 1 次提交
  4. 03 7月, 2017 1 次提交
    • G
      drm/atomic: initial support for asynchronous plane update · fef9df8b
      Gustavo Padovan 提交于
      In some cases, like cursor updates, it is interesting to update the
      plane in an asynchronous fashion to avoid big delays. The current queued
      update could be still waiting for a fence to signal and thus block any
      subsequent update until its scan out. In cases like this if we update the
      cursor synchronously through the atomic API it will cause significant
      delays that would even be noticed by the final user.
      
      This patch creates a fast path to jump ahead the current queued state and
      do single planes updates without going through all atomic steps in
      drm_atomic_helper_commit(). We take this path for legacy cursor updates.
      
      For now only single plane updates are supported, but we plan to support
      multiple planes updates and async PageFlips through this interface as well
      in the near future.
      
      v6:	- move check code to drm_atomic_helper.c (Daniel Vetter)
      
      v5:
      	- improve comments (Eric Anholt)
      
      v4:
      	- fix state->crtc NULL check (Archit Taneja)
      
      v3:
      	- fix iteration on the wrong crtc state
      	- put back code to forbid updates if there is a queued update for
      	the same plane (Ville Syrjälä)
      	- move size checks back to drivers (Ville Syrjälä)
      	- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
      
      v2:
      	- allow updates even if there is a queued update for the same
      	plane.
              - fixes on the documentation (Emil Velikov)
              - unconditionally call ->atomic_async_update (Emil Velikov)
              - check for ->atomic_async_update earlier (Daniel Vetter)
              - make ->atomic_async_check() the last step (Daniel Vetter)
              - add ASYNC_UPDATE flag (Eric Anholt)
              - update state in core after ->atomic_async_update (Eric Anholt)
      	- update docs (Eric Anholt)
      
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Eric Anholt <eric@anholt.net>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.com>
      Reviewed-by: Archit Taneja <architt@codeaurora.org> (v5)
      Acked-by: Eric Anholt <eric@anholt.net> (v5)
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170630180322.29007-2-gustavo@padovan.org
      fef9df8b
  5. 30 6月, 2017 1 次提交
  6. 27 6月, 2017 1 次提交
  7. 22 6月, 2017 1 次提交
  8. 31 5月, 2017 1 次提交
  9. 30 5月, 2017 1 次提交
  10. 22 5月, 2017 1 次提交
  11. 04 5月, 2017 1 次提交
  12. 03 5月, 2017 1 次提交
  13. 18 4月, 2017 1 次提交
  14. 07 4月, 2017 4 次提交
  15. 06 4月, 2017 2 次提交
  16. 05 4月, 2017 2 次提交
  17. 30 3月, 2017 1 次提交
  18. 29 3月, 2017 7 次提交
  19. 27 3月, 2017 1 次提交
  20. 06 3月, 2017 3 次提交
  21. 28 2月, 2017 5 次提交
  22. 27 2月, 2017 1 次提交
    • M
      drm: Add a new connector atomic property for link status · 40ee6fbe
      Manasi Navare 提交于
      At the time userspace does setcrtc, we've already promised the mode
      would work. The promise is based on the theoretical capabilities of
      the link, but it's possible we can't reach this in practice. The DP
      spec describes how the link should be reduced, but we can't reduce
      the link below the requirements of the mode. Black screen follows.
      
      One idea would be to have setcrtc return a failure. However, it
      already should not fail as the atomic checks have passed. It would
      also conflict with the idea of making setcrtc asynchronous in the
      future, returning before the actual mode setting and link training.
      
      Another idea is to train the link "upfront" at hotplug time, before
      pruning the mode list, so that we can do the pruning based on
      practical not theoretical capabilities. However, the changes for link
      training are pretty drastic, all for the sake of error handling and
      DP compliance, when the most common happy day scenario is the current
      approach of link training at mode setting time, using the optimal
      parameters for the mode. It is also not certain all hardware could do
      this without the pipe on; not even all our hardware can do this. Some
      of this can be solved, but not trivially.
      
      Both of the above ideas also fail to address link degradation *during*
      operation.
      
      The solution is to add a new "link-status" connector property in order
      to address link training failure in a way that:
      a) changes the current happy day scenario as little as possible, to
      avoid regressions, b) can be implemented the same way by all drm
      drivers, c) is still opt-in for the drivers and userspace, and opting
      out doesn't regress the user experience, d) doesn't prevent drivers
      from implementing better or alternate approaches, possibly without
      userspace involvement. And, of course, handles all the issues presented.
      In the usual happy day scenario, this is always "good". If something
      fails during or after a mode set, the kernel driver can set the link
      status to "bad" and issue a hotplug uevent for userspace to have it
      re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
      again. If the theoretical capabilities of the link can't be reached,
      the mode list is trimmed based on that.
      
      v7 by Jani:
      * Rebase, simplify set property while at it, checkpatch fix
      v6:
      * Fix a typo in kernel doc (Sean Paul)
      v5:
      * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
      v4:
      * Add comments in kernel-doc format (Daniel Vetter)
      * Update the kernel-doc for link-status (Sean Paul)
      v3:
      * Fixed a build error (Jani Saarinen)
      v2:
      * Removed connector->link_status (Daniel Vetter)
      * Set connector->state->link_status in drm_mode_connector_set_link_status_property
      (Daniel Vetter)
      * Set the connector_changed flag to true if connector->state->link_status changed.
      * Reset link_status to GOOD in update_output_state (Daniel Vetter)
      * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Acked-by: NTony Cheng <tony.cheng@amd.com>
      Acked-by: NHarry Wentland <harry.wentland@amd.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Sean Paul <seanpaul@chromium.org>
      Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
      40ee6fbe