1. 15 6月, 2017 1 次提交
  2. 13 6月, 2017 1 次提交
    • V
      drm/i915/cnl: Implement CNL display init/unit sequence · d8d4a512
      Ville Syrjälä 提交于
      Implement the CNL display init/uninit sequence as outlined in Bspec.
      
      Quite similar to SKL/BXT. The main complicaiton is probably the extra
      procmon setup we must do based on the process/voltage information we
      can read out from some register.
      
      v2: s/skl_dbuf/gen9_dbuf/ to follow upstream
          bxt needed a cdclk sanitize step, so let's add it for cnl too
      v3: s/CHICKEN_MISC_1/CHICKEN_MISC_2/ (Ander)
      v4: Rebased by Rodrigo after Ville's cdclk rework
      v5: Removed unecessary Aux IO forced enable/disable, Fix DW10 setup
          Fix procpon Mask. (Credits-to Paulo and Clint)
          Remove A0 workaround.
      v6: Rebased on top of recent code (Rodrigo).
      v7: Respect the order of sanitize_ after set_
          (Done by Rodrigo, Requested by Ville)
      v8: Commit message updated to matvh v5 changes besides
          Remove unused DW8 and an extra blank line. (all noticed
          by Imre).
      v9: Remove __attribute__((unused)) added on latest version
          of drm/i915/cnl: Implement .set_cdclk() for CNL.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Clint Taylor <clinton.a.taylor@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-3-git-send-email-rodrigo.vivi@intel.com
      d8d4a512
  3. 12 6月, 2017 3 次提交
  4. 01 6月, 2017 1 次提交
    • M
      drm/i915/skl+: consider max supported plane pixel rate while scaling · 73b0ca8e
      Mahesh Kumar 提交于
      A display resolution is only supported if it meets all the restrictions
      below for Maximum Pipe Pixel Rate.
      
      The display resolution must fit within the maximum pixel rate output
      from the pipe. Make sure that the display pipe is able to feed pixels at
      a rate required to support the desired resolution.
      For each enabled plane on the pipe {
          If plane scaling enabled {
      	Horizontal down scale amount = Maximum[1, plane horizontal size /
      		    scaler horizontal window size]
      	Vertical down scale amount = Maximum[1, plane vertical size /
      		    scaler vertical window size]
      	Plane down scale amount = Horizontal down scale amount *
      		    Vertical down scale amount
      	Plane Ratio = 1 / Plane down scale amount
          }
          Else {
      	Plane Ratio = 1
          }
          If plane source pixel format is 64 bits per pixel {
      	Plane Ratio = Plane Ratio * 8/9
          }
      }
      
      Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe
      
      If pipe scaling is enabled {
          Horizontal down scale amount = Maximum[1, pipe horizontal source size /
      		scaler horizontal window size]
          Vertical down scale amount = Maximum[1, pipe vertical source size /
      		scaler vertical window size]
          Note: The progressive fetch - interlace display mode is equivalent to a
      		2.0 vertical down scale
          Pipe down scale amount = Horizontal down scale amount *
      		Vertical down scale amount
          Pipe Ratio = Pipe Ratio / Pipe down scale amount
      }
      
      Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio
      
      In this patch our calculation is based on pipe downscale amount
      (plane max downscale amount * pipe downscale amount) instead of Pipe
      Ratio. So,
      max supported crtc clock with given scaling = CDCLK / pipe downscale.
      Flip will fail if,
      current crtc clock > max supported crct clock with given scaling.
      
      Changes since V1:
       - separate out fixed_16_16 wrapper API definition
      Changes since V2:
       - Fix buggy crtc !active condition (Maarten)
       - use intel_wm_plane_visible wrapper as per Maarten's suggestion
      Changes since V3:
       - Change failure return from ERANGE to EINVAL
      Changes since V4:
       - Rebase based on previous patch changes
      Changes since V5:
       - return EINVAL instead of continue (Maarten)
      Changes since V6:
       - Improve commit message
       - Address review comment
      Changes since V7:
       - use !enable instead of !active
       - rename config variable for consistency (Maarten)
      Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170526151546.25025-4-mahesh1.kumar@intel.com
      73b0ca8e
  5. 30 5月, 2017 5 次提交
  6. 11 5月, 2017 1 次提交
  7. 10 5月, 2017 3 次提交
  8. 08 5月, 2017 1 次提交
  9. 19 4月, 2017 1 次提交
  10. 14 4月, 2017 1 次提交
    • M
      drm/i915: Implement Link Rate fallback on Link training failure · 9301397a
      Manasi Navare 提交于
      If link training at a link rate optimal for a particular
      mode fails during modeset's atomic commit phase, then we
      let the modeset complete and then retry. We save the link rate
      value at which link training failed, update the link status property
      to "BAD" and use a lower link rate to prune the modes. It will redo
      the modeset on the current mode at lower link rate or if the current
      mode gets pruned due to lower link constraints then, it will send a
      hotplug uevent for userspace to handle it.
      
      This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
      4.3.1.6.
      
      This patch is a resend of the original commit id (233ce881
      "drm/i915: Implement Link Rate fallback on Link training failure")
      which got reverted in this commit id (afc1ebf4 Revert
      "drm/i915: Implement Link Rate fallback on Link training failure")
      due to CI failures.
      
      After investigating the CI failures it was found that these
      were essentially the failures which were always there but hidden because
      they used to be DRM_DEBUG_KMS messages for link failures so never got
      caught by CI. But now this patch actually throws DRM_ERROR if the link
      training fails at RBR and 1 lane. So it caught these link train failures.
      
      There were two failures:
      1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
      without eDP on Port A. But our VBT initialization code in the driver writes
      VBT defaults in a way that it always sets DP flag on Port A and this does
      not get cleared after parsing the VBT outputs. This has been fixed in
      commit id (bb1d1329 "drm/i915/vbt: split out defaults that are set
      when there is no VBT) and (66578857 "drm/i915/vbt: don't propagate
      errors from intel_bios_init())
      
      2. On ILK-650 desktop - This was happening because of a bad monitor desktop
      combination. I switched the monitor in the CI lab and that helped get rid
      of the link failures on ILK system.
      
      v10:
      * Rebase on drm-tip and resend after revert
      v9:
      * Use the trimmed max values of link rate/lane count based on
      link train fallback (Daniel Vetter)
      v8:
      * Set link_status to BAD first and then call mode_valid (Jani Nikula)
      v7:
      Remove the redundant variable in previous patch itself
      v6:
      * Obtain link rate index from fallback_link_rate using
      the helper intel_dp_link_rate_index (Jani Nikula)
      * Include fallback within intel_dp_start_link_train (Jani Nikula)
      v5:
      * Move set link status to drm core (Daniel Vetter, Jani Nikula)
      v4:
      * Add fallback support for non DDI platforms too
      * Set connector->link status inside set_link_status function
      (Jani Nikula)
      v3:
      * Set link status property to BAd unconditionally (Jani Nikula)
      * Dont use two separate variables link_train_failed and link_status
      to indicate same thing (Jani Nikula)
      v2:
      * Squashed a few patches (Jani Nikula)
      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>
      Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
      9301397a
  11. 12 4月, 2017 1 次提交
  12. 11 4月, 2017 4 次提交
  13. 07 4月, 2017 1 次提交
  14. 06 4月, 2017 2 次提交
  15. 31 3月, 2017 1 次提交
  16. 28 3月, 2017 2 次提交
    • S
      drm/i915: enable scrambling · 15953637
      Shashank Sharma 提交于
      Geminilake platform sports a native HDMI 2.0 controller, and is
      capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
      mendates scrambling for these higher clocks, for reduced RF footprint.
      
      This patch checks if the monitor supports scrambling, and if required,
      enables it during the modeset.
      
      V2: Addressed review comments from Ville:
       - Do not track scrambling status in DRM layer, track somewhere in
         driver like in intel_crtc_state.
       - Don't talk to monitor at such a low layer, set monitor scrambling
         in intel_enable_ddi() before enabling the port.
      
      V3: Addressed review comments from Jani
       - In comments, function names, use "sink" instead of "monitor",
         so that the implementation could be close to the language of
         HDMI spec.
      
      V4: Addressed review comment from Maarten
       - scrambling -> hdmi_scrambling
       - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
      
      V5: Addressed review comments from Ville and Ander
       - Do not modifiy the crtc_state after compute_config. Move all
         scrambling and tmds_clock_ratio calcutations to compute_config.
       - While setting scrambling for source/sink, do not check the
         conditions again, just go by the crtc_state flags. This will
         simplyfy the condition checks.
      
      V6: Addressed review comments from Ville
       - Do not add IS_GLK check in disable/enable function, instead add it
         in compute_config, while setting state flags.
       - Remove unnecessary paranthesis.
       - Simplyfy handle_sink_scrambling function as suggested.
       - Add readout code for scrambling status in get_ddi_config and add a
         check for the same in pipe_config_compare.
      
      V7: Addressed review comments from Ander/Ville
       - No separate function for source scrambling, make it inline
       - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
       - Do not add platform check while setting source scrambling
       - Use pipe_config instead of crtc->config to set sink scrambling
       - To readout scrambling status, Compare with SCRAMBLING_MASK
         not any of its bits
       - Remove platform check in intel_pipe_config_compare while checking
         scrambling status
      
      V8: Fixed mege conflict, Addressed review comments from Ander
       - Remove the desciption/comment about scrambling fom the caller, move
         it to the function
       - Move the IS_GLK check into scrambling function
       - Fix alignment
      
      V9: Fixed review comments from Ville, Ander
       - Pass the scrambling state variables as bool input to the sink_scrambling
         function and let the disable call be unconditional.
       - Fix alignments in function calls and debug messages.
       - Add kernel doc for function intel_hdmi_handle_sink_scrambling
      
      V10: Rebase
      Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
      15953637
    • P
      drm/i915: kill intel_ddi_pll_select() · 44a126ba
      Paulo Zanoni 提交于
      All it does is pick the encoder and call intel_get_shared_dpll(). We
      can just do this in the caller. One less indirection level during code
      reading.
      
      As another plus, now the two callers of intel_get_shared_dpll() are
      {ironlake,haswell}_crtc_compute_clock().
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1490209125-20046-2-git-send-email-paulo.r.zanoni@intel.com
      44a126ba
  17. 27 3月, 2017 2 次提交
  18. 23 3月, 2017 1 次提交
  19. 13 3月, 2017 2 次提交
  20. 08 3月, 2017 2 次提交
  21. 03 3月, 2017 4 次提交