1. 25 8月, 2017 2 次提交
  2. 23 8月, 2017 1 次提交
    • C
      drm/i915: Boost GPU clocks if we miss the pageflip's vblank · 74d290f8
      Chris Wilson 提交于
      If we miss the current vblank because the gpu was busy, that may cause a
      jitter as the frame rate temporarily drops. We try to limit the impact
      of this by then boosting the GPU clock to deliver the frame as quickly
      as possible. Originally done in commit 6ad790c0 ("drm/i915: Boost GPU
      frequency if we detect outstanding pageflips") but was never forward
      ported to atomic and finally dropped in commit fd3a4024 ("drm/i915:
      Rip out legacy page_flip completion/irq handling").
      
      One of the most typical use-cases for this is a mostly idle desktop.
      Rendering one frame of the desktop's frontbuffer can easily be
      accomplished by the GPU running at low frequency, but often exceeds
      the time budget of the desktop compositor. The result is that animations
      such as opening the menu, doing a fullscreen switch, or even just trying
      to move a window around are slow and jerky. We need to respond within a
      frame to give the best impression of a smooth UX, as a compromise we
      instead respond if that first frame misses its goal. The result should
      be a near-imperceivable initial delay and a smooth animation even
      starting from idle. The cost, as ever, is that we spend more power than
      is strictly necessary as we overestimate the required GPU frequency and
      then try to ramp down.
      
      This of course is reactionary, too little, too late; nevertheless it is
      surprisingly effective.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-chris@chris-wilson.co.ukTested-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NRadoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
      74d290f8
  3. 22 8月, 2017 4 次提交
  4. 21 8月, 2017 2 次提交
  5. 16 8月, 2017 1 次提交
  6. 11 8月, 2017 1 次提交
    • B
      drm/i915: Add format modifiers for Intel · 714244e2
      Ben Widawsky 提交于
      This was based on a patch originally by Kristian. It has been modified
      pretty heavily to use the new callbacks from the previous patch.
      
      v2:
        - Add LINEAR and Yf modifiers to list (Ville)
        - Combine i8xx and i965 into one list of formats (Ville)
        - Allow 1010102 formats for Y/Yf tiled (Ville)
      
      v3:
        - Handle cursor formats (Ville)
        - Put handling for LINEAR in the mod_support functions (Ville)
      
      v4:
        - List each modifier explicitly in supported modifiers (Ville)
        - Handle the CURSOR plane (Ville)
      
      v5:
        - Split out cursor and sprite handling (Ville)
      
      v6:
        - Actually use the sprite funcs (Emil)
        - Use unreachable (Emil)
      
      v7:
        - Only allow Intel modifiers and LINEAR (Ben)
      
      v8
        - Fix spite assert introduced in v6 (Daniel)
      
      v9
        - Change vendor check logic to avoid magic 56 (Emil)
        - Reorder skl_mod_support (Ville)
        - make intel_plane_funcs static, could be done as of v5 (Ville)
        - rename local variable intel_format_modifiers to modifiers (Ville)
          - actually use sprite modifiers
        - split out modifier/formats by platform (Ville)
      
      v10:
        - Undo vendor check from v9
      
      v11:
        - Squash CCS advertisement into this patch (daniels)
        - Don't advertise CCS on higher sprite planes (daniels)
      
      v12:
        - Don't advertise Y-tiled or CCS on any sprite planes, since we don't
          allocate enough DDB space for it to work. (daniels)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v8)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      714244e2
  7. 04 8月, 2017 1 次提交
  8. 27 7月, 2017 2 次提交
  9. 21 7月, 2017 3 次提交
  10. 19 7月, 2017 1 次提交
    • D
      drm/i915: Fix fbdev unload sequence · 4f256d82
      Daniel Vetter 提交于
      First thing we need to do is unregister the fbdev instance, but we
      can't just go ahead and kfree it. That must wait until the hotplug and
      polling work are stopped, since they can race with the with the
      teardown. That means we need to split up the fbdev teardown into the
      unregister part and the cleanup part.
      
      I originally suspected that this was broken in one of the unload
      shuffles, but on closer inspection the oldest sequence I've dug out
      also gets this wrong. Just not quite so badly.
      
      I've run drv_module_reload a few hundred times and it's rock solid
      compared to insta-death beforehand. This bug seems to have been
      uncovered by
      
      commit 88be58be
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jul 6 15:00:19 2017 +0200
      
          drm/i915/fbdev: Always forward hotplug events
      
      But the effect of that seems to only be to increase the race window
      enough to make it blow up easier. I'm not exactly clear on what's
      going on there ...
      
      v2: Fix whitespace and use fetch_and_zero (Chris).
      
      Testcase: igt/drv_module_reload
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791
      Cc: martin.peres@free.fr
      Cc: chris@chris-wilson.co.uk
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-2-daniel.vetter@ffwll.ch
      4f256d82
  11. 18 7月, 2017 1 次提交
  12. 28 6月, 2017 1 次提交
    • C
      drm/i915: Avoid keeping waitboost active for signaling threads · 7b92c1bd
      Chris Wilson 提交于
      Once a client has requested a waitboost, we keep that waitboost active
      until all clients are no longer waiting. This is because we don't
      distinguish which waiter deserves the boost. However, with the advent of
      fence signaling, the signaler threads appear as waiters to the RPS
      interrupt handler. So instead of using a single boolean to track when to
      keep the waitboost active, use a counter of all outstanding waitboosted
      requests.
      
      At this point, I have removed all vestiges of the rate limiting on
      clients. Whilst this means that compositors should remain more fluid,
      it also means that boosts are more prevalent. See commit b29c19b6
      ("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion
      on the pros and cons of both approaches.
      
      A drawback of this implementation is that it requires constant request
      submission to keep the waitboost trimmed (as it is now cancelled when the
      request is completed). This will be fine for a busy system, but near
      idle the boosts may be kept for longer than desired (effectively tens of
      vblanks worstcase) and there is a reliance on rc6 instead.
      
      v2: Remove defunct rps.client_lock
      Reported-by: NMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170628123548.9236-1-chris@chris-wilson.co.uk
      7b92c1bd
  13. 15 6月, 2017 1 次提交
  14. 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
  15. 12 6月, 2017 3 次提交
  16. 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
  17. 30 5月, 2017 5 次提交
  18. 29 5月, 2017 1 次提交
  19. 11 5月, 2017 1 次提交
  20. 10 5月, 2017 3 次提交
  21. 08 5月, 2017 1 次提交
  22. 19 4月, 2017 1 次提交
  23. 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
  24. 12 4月, 2017 1 次提交