An error occurred fetching the project authors.
  1. 25 Aug, 2023 1 commit
  2. 22 Aug, 2023 1 commit
  3. 18 Aug, 2023 17 commits
  4. 11 Aug, 2023 1 commit
    • Imre Deak's avatar
      drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume · cc018c26
      Imre Deak authored
      The issue fixed in
      
      commit a8ddac7c ("drm/i915: Avoid HPD poll detect triggering a new detect cycle")
      
      on VLV, CHV is still present on platforms where the display hotplug
      detection functionality is available whenever the device is in D0 state
      (hence these platforms switch to HPD polling only when the device is
      runtime suspended).
      
      The above commit avoids an endless i915_hpd_poll_init_work() ->
      connector detect loop by making sure that by the end of
      i915_hpd_poll_init_work() all display power references acquired by the
      connector detect functions which can trigger a new cycle (display core
      power domain) are dropped. However on platforms where HPD polling is
      enabled/disabled only from the runtime suspend/resume handlers, this is
      not ensured: for instance eDP VDD, TypeC port PHYs and the runtime
      autosuspend delay may still keep the device runtime resumed (via a power
      reference acquired during connector detection and hence result in an
      endless loop like the above).
      
      Solve the problem described in the above commit on all platforms, by
      making sure that a i915_hpd_poll_init_work() -> connector detect
      sequence can't take any power reference in the first place which would
      trigger a new cycle, instead of relying on these power references to be
      dropped by the end of the sequence.
      
      With the default runtime autosuspend delay (10 sec) this issue didn't
      happen in practice, since the device remained runtime resumed for the
      whole duration of the above sequence. CI/IGT tests however set the
      autosuspend delay to 0, which makes the problem visible, see References:
      below.
      
      Tested on GLK, CHV.
      
      v2: Don't warn about a requeued work, to account for disabling
          polling directly during driver loading, reset and system resume.
      
      References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJouni Högander <jouni.hogander@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
      cc018c26
  5. 07 Aug, 2023 2 commits
  6. 05 Jul, 2023 1 commit
  7. 15 Jun, 2023 1 commit
    • Wayne Lin's avatar
      drm/dp_mst: Clear MSG_RDY flag before sending new message · 72f1de49
      Wayne Lin authored
      [Why]
      The sequence for collecting down_reply from source perspective should
      be:
      
      Request_n->repeat (get partial reply of Request_n->clear message ready
      flag to ack DPRX that the message is received) till all partial
      replies for Request_n are received->new Request_n+1.
      
      Now there is chance that drm_dp_mst_hpd_irq() will fire new down
      request in the tx queue when the down reply is incomplete. Source is
      restricted to generate interveleaved message transactions so we should
      avoid it.
      
      Also, while assembling partial reply packets, reading out DPCD DOWN_REP
      Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
      wrapped up as a complete operation for reading out a reply packet.
      Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
      be risky. e.g. If the reply of the new request has overwritten the
      DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
      DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
      for the new request. Should handle the up request in the same way.
      
      [How]
      Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
      event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might
      trigger drm_dp_mst_kick_tx() only when there is no on going message
      transaction.
      
      Changes since v1:
      * Reworked on review comments received
      -> Adjust the fix to let driver explicitly kick off new down request
      when mst irq event is handled and acked
      -> Adjust the commit message
      
      Changes since v2:
      * Adjust the commit message
      * Adjust the naming of the divided 2 functions and add a new input
        parameter "ack".
      * Adjust code flow as per review comments.
      
      Changes since v3:
      * Update the function description of drm_dp_mst_hpd_irq_handle_event
      
      Changes since v4:
      * Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align
        the size of esi[]
      Signed-off-by: default avatarWayne Lin <Wayne.Lin@amd.com>
      Reviewed-by: default avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      72f1de49
  8. 10 Jun, 2023 1 commit
  9. 02 Jun, 2023 3 commits
  10. 16 May, 2023 3 commits
    • Imre Deak's avatar
      drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects · c598c335
      Imre Deak authored
      If the output on a DP-alt link with its sink disconnected is kept
      enabled for too long (about 20 sec), then some IOM/TCSS firmware timeout
      will cause havoc on the PCI bus, at least for other GFX devices on it
      which will stop powering up. Since user space is not guaranteed to do a
      disabling modeset in time, switch such disconnected but active links to
      TBT mode - which is without such shortcomings - with a 2 second delay.
      
      If the above condition is detected already during the driver load/system
      resume sanitization step disable the output instead, as at that point no
      user space or kernel client depends on a consistent output state yet and
      because subsequent atomic modeset on such connectors - without the
      actual sink capabilities available - can fail.
      
      An active/disconnected port as above will also block the HPD status of
      other active/disconnected ports to get updated (stuck in the connected
      state), until the former port is disabled, its PHY is disconnected and
      a ~10 ms delay has elapsed. This means the link state for all TypeC
      ports/CRTCs must be rechecked after a CRTC is disabled due to the above
      reason. For this disconnect the PHY synchronously after the CRTC/port is
      disabled and recheck all CRTCs for the above condition whenever such a
      port is disabled.
      
      To account for a race condition during driver loading where the sink is
      disconnected after the above sanitization step and before the HPD
      interrupts get enabled, do an explicit check/link reset if needed from
      the encoder's late_register hook, which is called after the HPD
      interrupts are enabled already.
      
      v2:
      - Handle an active/disconnected port blocking the HPD state update of
        another active/disconnected port.
      - Cancel the delayed work resetting the link also from the encoder
        enable/suspend/shutdown hooks.
      - Rebase on the earlier intel_modeset_lock_ctx_retry() addition,
        fixing here the missed atomic state reset in case of a retry.
      - Fix handling of an error return from intel_atomic_get_crtc_state().
      - Recheck if the port needs to be reset after all the atomic state
        is locked and async commits are waited on.
      
      v3:
      - Add intel_crtc_needs_link_reset(), instead of open-coding it,
        keep intel_crtc_has_encoders(). (Ville)
      - Fix state dumping and use a bitmask to track disabled CRTCs in
        intel_sanitize_all_crtcs(). (Ville)
      - Set internal in intel_atomic_state right after allocating it.
        (Ville)
      - Recheck all CRTCs (not yet force-disabled) after a CRTC is
        force-disabled for any reason (not only due to a link state)
        in intel_sanitize_all_crtcs().
      - Reduce delay after CRTC disabling to 20ms, and use the simpler
        msleep().
      - Clarify code comment about HPD behaviour in
        intel_sanitize_all_crtcs().
      - Move all the TC link reset logic to intel_tc.c .
      - Cancel the link reset work synchronously during system suspend,
        driver unload and shutdown.
      
      v4:
      - Rebased on previous patch, which allows calling the TC port
        suspend/cleanup handlers without modeset locks held; remove the
        display driver suspended assert from the link reset work
        accordingly.
      
      v5: (Ville)
      - Remove reset work canceling from intel_ddi_pre_pll_enable().
      - Track a crtc vs. pipe mask in intel_sanitize_all_crtcs().
      - Add reset_link_commit() to clarify the
        intel_modeset_lock_ctx_retry loop.
      
      Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5860Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230512195513.2699-2-imre.deak@intel.com
      c598c335
    • Imre Deak's avatar
      drm/i915/dp: Factor out intel_dp_get_active_pipes() · 7e4460c3
      Imre Deak authored
      Factor out a helper used by a follow up patch to reset an active DP
      link.
      
      No functional changes.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-12-imre.deak@intel.com
      7e4460c3
    • Jani Nikula's avatar
      drm/i915/irq: split out hotplug irq handling · da38ba98
      Jani Nikula authored
      Split hotplug irq handling out of i915_irq.[ch] into
      display/intel_hotplug_irq.[ch].
      
      The line between the new intel_hotplug_irq.[ch] and the existing
      intel_hotplug.[ch] needs further clarification, but the first step is to
      move the stuff out of i915_irq.[ch].
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarGustavo Sousa <gustavo.sousa@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-2-jani.nikula@intel.com
      da38ba98
  11. 11 May, 2023 1 commit
  12. 05 May, 2023 7 commits
  13. 28 Apr, 2023 1 commit