1. 18 10月, 2019 1 次提交
  2. 03 10月, 2019 2 次提交
  3. 14 9月, 2019 1 次提交
  4. 13 8月, 2019 1 次提交
  5. 11 6月, 2019 1 次提交
  6. 31 5月, 2019 1 次提交
  7. 25 5月, 2019 1 次提交
  8. 15 4月, 2019 2 次提交
  9. 04 4月, 2019 1 次提交
  10. 28 3月, 2019 1 次提交
  11. 20 3月, 2019 1 次提交
    • N
      drm/amd/display: Add plane capabilities to dc_caps · e5c41970
      Nicholas Kazlauskas 提交于
      [Why]
      The current dc_caps doesn't provide the information needed to
      determine the count and type of each plane to be exposed to userspace.
      
      There are three types of DRM planes that are exposed to userspace:
      
      1. Primary planes (can be used for modesetting)
      2. Overlay planes (can be blended below or above a primary plane)
      3. Cursor planes (blended topmost)
      
      We need to know the number and type of each in amdgpu_dm to expose
      to userspace.
      
      Hardware supports blending planes below, above or both ways depending
      on the ASIC. Alpha support is also ASIC dependent. Some hardware has
      dedicated pipes for overlays and other hardware combines the pipes.
      
      All of this should be exposed in a way that DM can query and use.
      
      [How]
      Introduce the dc_plane_cap structure that describes the capabilities
      for the hw planes.
      
      It describes:
      - the type of the plane
      - whether the plane can blend with planes below it
      - whether the plane can blend with planes above it
      - whether the plane supports per pixel alpha blending
      - supported formats on the plane (partial list for now)
      
      Pre DCN ASICs don't have their full capabilities described for now.
      They can be updated as needed in the future.
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
      Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      e5c41970
  12. 26 1月, 2019 1 次提交
  13. 15 1月, 2019 2 次提交
    • D
      drm/amd/display: Change from aux_engine to dce_aux · 1877ccf6
      David Francis 提交于
      [Why]
      The aux_engine struct is needlessly complex and
      is defined multiple times.  It contains function pointers
      that each have only one version and are called only from
      inside dce_aux.
      
      [How]
      Replace aux_engine with a new struct called dce_aux.
      Remove all function pointers and call functions directly.
      Remove unused functions
      Signed-off-by: NDavid Francis <David.Francis@amd.com>
      Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      1877ccf6
    • J
      drm/amd/display: remove sink reference in dc_stream_state · ceb3dbb4
      Jun Lei 提交于
      [why]
      dc_stream_state containing a pointer to sink is poor design.
      Sink describes the display, and the specifications or capabilities
      it has.  That information is irrelevant for dc_stream_state, which describes
      hardware state, and is generally used for hardware programming.  It
      could further be argued that dc_sink itself is just a convenience dc
      provides, and DC should be perfectly capable of programming hardware
      without any dc_sinks (for example, emulated sinks).
      
      [how]
      Phase 1:
      Deprecate use of dc_sink pointer in dc_stream.  Most references are trivial
      to remove, but some call sites are risky (such as is_timing_changed) with
      no obvious logical replacement.  These will be removed in follow up change.
      
      Add dc_link pointer to dc_stream.  This is the typical reason DC really needed
      sink pointer, and most call sites are replaced with this.
      
      DMs also need minor updates, as all 3 DMs leverage stream->sink for
      some functionality.  this is replaced instead by a pointer to private data
      inside dc_stream_state, which is used by DMs as a quality of life improvment
      for some key functionality.  it allows DMs to set pointers have to their own objects
      which associate OS objects to dc_stream_states (such as DisplayTarget
      and amdgpu_dm_connector).  Without the private pointer, DMs would be
      forced to perform a lookup for callbacks.
      Signed-off-by: NJun Lei <Jun.Lei@amd.com>
      Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
      Acked-by: NDavid Francis <David.Francis@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      ceb3dbb4
  14. 06 11月, 2018 5 次提交
  15. 10 10月, 2018 2 次提交
  16. 15 9月, 2018 1 次提交
  17. 11 9月, 2018 1 次提交
  18. 28 8月, 2018 1 次提交
  19. 07 8月, 2018 1 次提交
  20. 27 7月, 2018 1 次提交
  21. 25 7月, 2018 1 次提交
  22. 14 7月, 2018 1 次提交
  23. 06 7月, 2018 3 次提交
  24. 16 5月, 2018 1 次提交
  25. 12 4月, 2018 1 次提交
  26. 08 3月, 2018 1 次提交
  27. 06 3月, 2018 2 次提交
  28. 20 2月, 2018 2 次提交