1. 16 11月, 2022 1 次提交
  2. 14 9月, 2022 1 次提交
  3. 17 8月, 2022 1 次提交
  4. 21 7月, 2022 1 次提交
  5. 14 7月, 2022 1 次提交
  6. 13 7月, 2022 1 次提交
  7. 30 6月, 2022 1 次提交
    • M
      drm/amdgpu/amdgpu_dm: fix kernel-doc markups · 2639d3e4
      Mauro Carvalho Chehab 提交于
      There are 4 undocumented fields at struct amdgpu_display_manager.
      
      Add documentation for them, fixing those warnings:
      
      	drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'dmub_outbox_params' not described in 'amdgpu_display_manager'
      	drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'num_of_edps' not described in 'amdgpu_display_manager'
      	drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'disable_hpd_irq' not described in 'amdgpu_display_manager'
      	drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'dmub_aux_transfer_done' not described in 'amdgpu_display_manager'
      	drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'delayed_hpd_wq' not described in 'amdgpu_display_manager'
      Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      2639d3e4
  8. 22 6月, 2022 2 次提交
  9. 11 5月, 2022 1 次提交
  10. 25 4月, 2022 1 次提交
  11. 07 4月, 2022 1 次提交
  12. 01 4月, 2022 1 次提交
  13. 17 2月, 2022 1 次提交
  14. 26 1月, 2022 1 次提交
  15. 17 1月, 2022 1 次提交
  16. 08 1月, 2022 1 次提交
  17. 15 12月, 2021 1 次提交
  18. 23 11月, 2021 1 次提交
  19. 07 10月, 2021 1 次提交
  20. 15 9月, 2021 2 次提交
    • A
      drm/amd/display: Add flag to detect dpms force off during HPD · 035f5496
      Aurabindo Pillai 提交于
      [Why] When a connector is unplugged, dpms is forced off so that some
      connector allocations are cleared off. This is done outside the commit
      sequence from the userspace. This causes HUBP blank. Due to the blank
      hubp, a non blocking commit which queues flip will encounter a timeout
      waiting for the flip_done because prior to writing the surface flip
      address, hubp was in blank.
      
      [How] Add a marker to DM's crtc state and use this field to indicate
      whether dpms was forced off during an HPD. Check for this marker before
      queuing the flip.
      Reviewed-by: NAnson Jacob <Anson.Jacob@amd.com>
      Acked-by: NMikita Lipski <mikita.lipski@amd.com>
      Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
      Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      035f5496
    • W
      drm/amd/display: Fork thread to offload work of hpd_rx_irq · 8e794421
      Wayne Lin 提交于
      [Why]
      Currently, we will try to get dm.dc_lock in handle_hpd_rx_irq() when
      link lost happened, which is risky and could cause deadlock.
      e.g. If we are under procedure to enable MST streams and then monitor
      happens to toggle short hpd to notify link lost, then
      handle_hpd_rx_irq() will get blocked due to stream enabling flow has
      dc_lock. However, under MST, enabling streams involves communication
      with remote sinks which need to use handle_hpd_rx_irq() to handle
      sideband messages. Thus, we have deadlock here.
      
      [How]
      Target is to have handle_hpd_rx_irq() finished as soon as possilble.
      Hence we can react to interrupt quickly. Besides, we should avoid to
      grabe dm.dc_lock within handle_hpd_rx_irq() to avoid deadlock situation.
      
      Firstly, revert patches which introduced to use dm.dc_lock in
      handle_hpd_rx_irq():
      
      * commit ("drm/amd/display: NULL pointer error during ")
      
      * commit ("drm/amd/display: Only one display lights up while using MST")
      
      * commit ("drm/amd/display: take dc_lock in short pulse handler only")
      
      Instead, create work to handle irq events which needs dm.dc_lock.
      Besides:
      
      * Create struct hpd_rx_irq_offload_work_queue for each link to handle
        its short hpd events
      
      * Avoid to handle link lost/ automated test if the link is disconnected
      
      * Defer dc_lock needed works in dc_link_handle_hpd_rx_irq(). This
        function should just handle simple stuff for us (e.g. DPCD R/W).
        However, deferred works should still be handled by the order that
        dc_link_handle_hpd_rx_irq() used to be.
      
      * Change function name dm_handle_hpd_rx_irq() to
        dm_handle_mst_sideband_msg() to be more specific
      Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
      Acked-by: NMikita Lipski <mikita.lipski@amd.com>
      Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
      Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      8e794421
  21. 02 9月, 2021 1 次提交
  22. 17 8月, 2021 2 次提交
    • N
      drm/amd/display: Use vblank control events for PSR enable/disable · 58aa1c50
      Nicholas Kazlauskas 提交于
      [Why]
      PSR can disable the HUBP along with the OTG when PSR is active.
      
      We'll hit a pageflip timeout when the OTG is disable because we're no
      longer updating the CRTC vblank counter and the pflip high IRQ will
      not fire on the flip.
      
      In order to flip the page flip timeout occur we should modify the
      enter/exit conditions to match DRM requirements.
      
      [How]
      Use our deferred handlers for DRM vblank control to notify DMCU(B)
      when it can enable or disable PSR based on whether vblank is disabled or
      enabled respectively.
      
      We'll need to pass along the stream with the notification now because
      we want to access the CRTC state while the CRTC is locked to get the
      stream state prior to the commit.
      
      Retain a reference to the stream so it remains safe to continue to
      access and release that reference once we're done with it.
      
      Enable/disable logic follows what we were previously doing in
      update_planes.
      
      The workqueue has to be flushed before programming streams or planes
      to ensure that we exit out of idle optimizations and PSR before
      these events occur if necessary.
      
      To keep the skip count logic the same to avoid FBCON PSR enablement
      requires copying the allow condition onto the DM IRQ parameters - a
      field that we can actually access from the worker.
      Reviewed-by: NRoman Li <Roman.Li@amd.com>
      Acked-by: NWayne Lin <wayne.lin@amd.com>
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      58aa1c50
    • N
      drm/amd/display: Fix multi-display support for idle opt workqueue · 09a5df6c
      Nicholas Kazlauskas 提交于
      [Why]
      The current implementation for idle optimization support only has a
      single work item that gets reshuffled into the system workqueue
      whenever we receive an enable or disable event.
      
      We can have mismatched events if the work hasn't been processed or if
      we're getting control events from multiple displays at once.
      
      This fixes this issue and also makes the implementation usable for
      PSR control - which will be addressed in another patch.
      
      [How]
      We need to be able to flush remaining work out on demand for driver stop
      and psr disable so create a driver specific workqueue instead of using
      the system one. The workqueue will be single threaded to guarantee the
      ordering of enable/disable events.
      
      Refactor the queue to allocate the control work and deallocate it
      after processing it.
      
      Pass the acrtc directly to make it easier to handle psr enable/disable
      in a later patch.
      
      Rename things to indicate that it's not just MALL specific.
      Reviewed-by: NRoman Li <Roman.Li@amd.com>
      Acked-by: NWayne Lin <wayne.lin@amd.com>
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      09a5df6c
  23. 29 7月, 2021 1 次提交
  24. 22 6月, 2021 1 次提交
  25. 12 6月, 2021 1 次提交
  26. 09 6月, 2021 1 次提交
  27. 20 5月, 2021 2 次提交
  28. 11 5月, 2021 3 次提交
  29. 16 4月, 2021 1 次提交
  30. 10 4月, 2021 4 次提交
  31. 24 3月, 2021 1 次提交