1. 30 1月, 2019 1 次提交
  2. 24 1月, 2019 1 次提交
  3. 21 1月, 2019 1 次提交
  4. 16 1月, 2019 2 次提交
    • L
      drm/i915: Pass down rc in intel_encoder->compute_config() · 204474a6
      Lyude Paul 提交于
      Something that I completely missed when implementing the new MST VCPI
      atomic helpers is that with those helpers, there's technically a chance
      of us having to grab additional modeset locks in ->compute_config() and
      furthermore, that means we have the potential to hit a normal modeset
      deadlock. However, because ->compute_config() only returns a bool this
      means we can't return -EDEADLK when we need to drop locks and try again
      which means we end up just failing the atomic check permanently. Whoops.
      
      So, fix this by modifying ->compute_config() to pass down an actual
      error code instead of a bool so that the atomic check can be restarted
      on modeset deadlocks.
      
      Thanks to Ville Syrjälä for pointing this out!
      
      Changes since v1:
      * Add some newlines
      * Return only -EINVAL from hsw_crt_compute_config()
      * Propogate return code from intel_dp_compute_dsc_params()
      * Change all of the intel_dp_compute_link_config*() variants
      * Don't miss if (hdmi_port_clock_valid()) branch in
        intel_hdmi_compute_config()
      
      [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix
       linux-next & drm-tip conflict, while waiting for proper propagation of
       the DP MST series that this commit fixes. In hindsight, a topic branch
       might have been a better approach for it.]
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Fixes: eceae147 ("drm/dp_mst: Start tracking per-port VCPI allocations")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com
      (cherry picked from commit 96550555)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Acked-by: NDaniel Vetter <daniel@ffwll.ch>
      204474a6
    • L
      drm/i915: Pass down rc in intel_encoder->compute_config() · 96550555
      Lyude Paul 提交于
      Something that I completely missed when implementing the new MST VCPI
      atomic helpers is that with those helpers, there's technically a chance
      of us having to grab additional modeset locks in ->compute_config() and
      furthermore, that means we have the potential to hit a normal modeset
      deadlock. However, because ->compute_config() only returns a bool this
      means we can't return -EDEADLK when we need to drop locks and try again
      which means we end up just failing the atomic check permanently. Whoops.
      
      So, fix this by modifying ->compute_config() to pass down an actual
      error code instead of a bool so that the atomic check can be restarted
      on modeset deadlocks.
      
      Thanks to Ville Syrjälä for pointing this out!
      
      Changes since v1:
      * Add some newlines
      * Return only -EINVAL from hsw_crt_compute_config()
      * Propogate return code from intel_dp_compute_dsc_params()
      * Change all of the intel_dp_compute_link_config*() variants
      * Don't miss if (hdmi_port_clock_valid()) branch in
        intel_hdmi_compute_config()
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Fixes: eceae147 ("drm/dp_mst: Start tracking per-port VCPI allocations")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com
      96550555
  5. 15 1月, 2019 1 次提交
  6. 28 12月, 2018 1 次提交
  7. 25 12月, 2018 1 次提交
  8. 18 12月, 2018 2 次提交
    • I
      drm/i915/icl: Fix HPD handling for TypeC legacy ports · f6bff60e
      Imre Deak 提交于
      Atm HPD disconnect events on TypeC ports will break things, since we'll
      switch the TypeC mode (between legacy and disconnected modes as well as
      among USB DP alternate, Thunderbolt alternate and disconnected modes) on
      the fly from the HPD disconnect interrupt work while the port may be
      still active.
      
      Even if the port happens to be not active during the disconnect we'd
      still have a problem during a subsequent modeset or AUX transfer that
      could happen regardless of the port's connected state. For instance the
      system resume display mode restore code and userspace could perform a
      modeset on the port or userspace could start an AUX transfer even if the
      port is in disconnected state.
      
      To fix this keep TypeC legacy ports in legacy mode whenever we're not
      suspended. This mode is a static configuration as opposed to the
      Thunderbolt and USB DP alternate modes between which we can switch
      dynamically.
      
      We determine if a TypeC port is legacy (wired to a legacy HDMI or a
      legacy DP connector) via the VBT DDI port specific USB-TypeC and
      Thunderbolt flags. If both these flags are cleared then the port is
      configured for legacy mode.
      
      On such legacy ports we'll run the TypeC PHY connect sequence explicitly
      during driver loading and system resume (vs. running the sequence during
      HPD processing). The connect will succeed even if the display is not
      connected to begin with (or disappears during the suspended state) since
      for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED
      flag is always set (as opposed to the USB DP alternate mode where it
      gets set only when a display is connected).
      
      Correspondingly run the TypeC PHY disconnect sequence during system
      suspend and driver unloading. For the unloading case I had to split
      up intel_dp_encoder_destroy() to be able to have the 1. flush any
      pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and
      kfree on the encoder object.
      
      For now run the PHY disconnect during suspend only for TypeC legacy
      ports. We will need to disconnect even in USB DP alternate mode in the
      future, but atm we don't have a way to reconnect the port in this mode
      during resume if the display disappears while being suspended. So for
      now punt on this case.
      
      Note that we do not disconnect the port during runtime suspend; in
      legacy mode there are no shared HW resources (PHY lanes) with other HW
      blocks (USB), so no need to release / reacquire these resources as with
      USB DP alternate mode. The only reason to disconnect legacy ports during
      system suspend is that the PORT_TX_DFLEXDPPMS /
      DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
      connected again during system resume. We'll also have to turn the check
      for this flag into a poll, after figuring out what's the proper timeout
      value for it.
      
      v2:
      - Remove the redundant special casing of legacy mode when doing a
        disconnect in icl_tc_port_connected(). It's guaranteed already that we
        won't disconnect legacy ports in that function.
      - Add a note about the new intel_ddi_encoder_destroy() hook.
      - Reword the commit message after switching to the VBT based detection.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-4-imre.deak@intel.com
      f6bff60e
    • C
      drm/i915/icl: combo port vswing programming changes per BSPEC · b265a2a6
      Clint Taylor 提交于
      In August 2018 the BSPEC changed the ICL port programming sequence to
      closely resemble earlier gen programming sequence. Restrict combo phy to
      HBR max rate unless eDP panel is connected to port.
      
      v2: remove debug code that Imre found
      v3: simplify translation table if-else
      v4: edp translation table now based on link rate and low_swing
      v5: Misc review comments + r-b
      BSpec: 21257
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1545084827-5776-1-git-send-email-clinton.a.taylor@intel.com
      b265a2a6
  9. 11 12月, 2018 1 次提交
  10. 03 12月, 2018 3 次提交
  11. 30 11月, 2018 6 次提交
  12. 21 11月, 2018 1 次提交
  13. 15 11月, 2018 1 次提交
  14. 09 11月, 2018 2 次提交
  15. 05 11月, 2018 2 次提交
  16. 02 11月, 2018 6 次提交
  17. 01 11月, 2018 1 次提交
  18. 23 10月, 2018 2 次提交
  19. 18 10月, 2018 2 次提交
  20. 17 10月, 2018 2 次提交
  21. 15 10月, 2018 1 次提交
    • S
      drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON · 668b6c17
      Shashank Sharma 提交于
      LSPCON chips can generate YCBCR outputs, if asked nicely :).
      
      In order to generate YCBCR 4:2:0 outputs, a source must:
      - send YCBCR 4:4:4 signals to LSPCON
      - program color space as 4:2:0 in AVI infoframes
      
      Whereas for YCBCR 4:4:4 outputs, the source must:
      - send YCBCR 4:4:4 signals to LSPCON
      - program color space as 4:4:4 in AVI infoframes
      
      So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
      pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
      information indicates LSPCON FW to start scaling down from YCBCR
      4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
      LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.
      
      V2: rebase
      V3: Addressed review comments from Ville
          - add enum crtc_output_format instead of bool ycbcr420
          - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
            cases in this way we will have YCBCR 4:4:4 framework ready (except
            the ABI part)
      V4: Added r-b from Maarten (for v3)
          Addressed review comments from Ville:
          - Do not add a non-atomic state variable to determine lspcon output.
            Instead add bool in CRTC state to indicate lspcon based scaling.
      V5: Addressed review comments from Ville:
          - Change the state bool name from external scaling to something more
            relavent.
          - Keep the info and adjusted_mode structures const.
          - use crtc_state instead of pipe_config.
          - Push all the config change into lspcon_ycbcr420_config function.
      V6: Rebase, small changes to accommodate changes in patch 2.
      V7: Fixed checkpatch warnings for alignment
      V8: Rebase
      
          PS: Ignored following warnings to match the current formatting:
          drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
           -:53: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
          #53: FILE: drivers/gpu/drm/i915/i915_reg.h:8721:
          +#define  TRANS_MSA_SAMPLING_444        (2<<1)
                                                ^
          -:54: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
          #54: FILE: drivers/gpu/drm/i915/i915_reg.h:8722:
          +#define  TRANS_MSA_CLRSP_YCBCR         (2<<3)
      V9: Rebase
      V10: Rebase
      V11: Rebase
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-8-git-send-email-shashank.sharma@intel.com
      668b6c17