1. 16 Dec, 2014 5 commits
    • Brad Volkin's avatar
      drm/i915: Mark shadow batch buffers as purgeable · 0079a7df
      Brad Volkin authored
      By adding a new exec_entry flag, we cleanly mark the shadow objects
      as purgeable after they are on the active list.
      
      v2:
      - Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
        fnc (danvet, from v4 6/7 feedback)
      
      v3:
      - Remove duplicate 'madv = I915_MADV_WILLNEED' (danvet, from v6 4/5)
      
      Issue: VIZ-4719
      Signed-off-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-By: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0079a7df
    • Brad Volkin's avatar
      drm/i915: Use batch length instead of object size in command parser · b9ffd80e
      Brad Volkin authored
      Previously we couldn't trust the user-supplied batch length because
      it came directly from userspace (i.e. untrusted code). It would have
      affected what commands software parsed without regard to what hardware
      would actually execute, leaving a potential hole.
      
      With the parser now copying the user supplied batch buffer and writing
      MI_NOP commands to any space after the copied region, we can safely use
      the batch length input. This should be a performance win as the actual
      batch length is frequently much smaller than the allocated object size.
      
      v2: Fix handling of non-zero batch_start_offset
      
      Issue: VIZ-4719
      Signed-off-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-By: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b9ffd80e
    • Brad Volkin's avatar
      drm/i915: Use batch pools with the command parser · 78a42377
      Brad Volkin authored
      This patch sets up all of the tracking and copying necessary to
      use batch pools with the command parser and dispatches the copied
      (shadow) batch to the hardware.
      
      After this patch, the parser is in 'enabling' mode.
      
      Note that performance takes a hit from the copy in some cases
      and will likely need some work. At a rough pass, the memcpy
      appears to be the bottleneck. Without having done a deeper
      analysis, two ideas that come to mind are:
      1) Copy sections of the batch at a time, as they are reached
         by parsing. Might improve cache locality.
      2) Copy only up to the userspace-supplied batch length and
         memset the rest of the buffer. Reduces the number of reads.
      
      v2:
      - Remove setting the capacity of the pool
      - One global pool instead of per-ring pools
      - Replace batch_obj with shadow_batch_obj and hook into eb->vmas
      - Memset any space in the shadow batch beyond what gets copied
      - Rebased on execlist prep refactoring
      
      v3:
      - Rebase on chained batch handling
      - Squash in setting the secure dispatch flag
      - Add a note about the interaction w/secure dispatch pinning
      - Check for request->batch_obj == NULL in i915_gem_free_request
      
      v4:
      - Fix read domains for shadow_batch_obj
      - Remove the set_to_gtt_domain call from i915_parse_cmds
      - ggtt_pin/unpin in the parser block to simplify error handling
      - Check USES_FULL_PPGTT before setting DISPATCH_SECURE flag
      - Remove i915_gem_batch_pool_put calls
      
      v5:
      - Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after
        the parser (danvet, from v4 0/7 feedback)
      
      Issue: VIZ-4719
      Signed-off-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-By: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      78a42377
    • Brad Volkin's avatar
      drm/i915: Implement a framework for batch buffer pools · 493018dc
      Brad Volkin authored
      This adds a small module for managing a pool of batch buffers.
      The only current use case is for the command parser, as described
      in the kerneldoc in the patch. The code is simple, but separating
      it out makes it easier to change the underlying algorithms and to
      extend to future use cases should they arise.
      
      The interface is simple: init to create an empty pool, fini to
      clean it up, get to obtain a new buffer. Note that all buffers are
      expected to be inactive before cleaning up the pool.
      
      Locking is currently based on the caller holding the struct_mutex.
      We already do that in the places where we will use the batch pool
      for the command parser.
      
      v2:
      - s/BUG_ON/WARN_ON/ for locking assertions
      - Remove the cap on pool size
      - Switch from alloc/free to init/fini
      
      v3:
      - Idiomatic looping structure in _fini
      - Correct handling of purged objects
      - Don't return a buffer that's too much larger than needed
      
      v4:
      - Rebased to latest -nightly
      
      v5:
      - Remove _put() function and clean up comments to match
      
      v6:
      - Move purged check inside the loop (danvet, from v4 1/7 feedback)
      
      v7:
      - Use single list instead of two. (Chris W)
      - s/active_list/cache_list
      - Squashed in debug patches (Chris W)
        drm/i915: Add a batch pool debugfs file
      
        It provides some useful information about the buffers in
        the global command parser batch pool.
      
        v2: rebase on global pool instead of per-ring pools
        v3: rebase
      
        drm/i915: Add batch pool details to i915_gem_objects debugfs
      
        To better account for the potentially large memory consumption
        of the batch pool.
      
      v8:
      - Keep cache in LRU order (danvet, from v6 1/5 feedback)
      
      Issue: VIZ-4719
      Signed-off-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-By: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      493018dc
    • Imre Deak's avatar
      drm/i915: fix use after free during eDP encoder destroying · c8bd0e49
      Imre Deak authored
      After
      
      commit a18c0af1
      uthor: Thierry Reding <treding@nvidia.com>
      Date:   Wed Dec 10 11:38:49 2014 +0100
      
          drm: Zero out DRM object memory upon cleanup
      
      we will use the eDP encoder during destroying it. Fix this by calling
      drm_encoder_cleanup() at a point when the encoder is not used any more.
      This caused a NULL pointer dereference in pps_lock(), I can't see that
      it caused any other problem.
      
      All the other encoders seem to call drm_encoder_cleanup() at a safe
      place.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c8bd0e49
  2. 15 Dec, 2014 12 commits
    • Damien Lespiau's avatar
      drm/i915/skl: Skylake also supports DP MST · c86ea3d0
      Damien Lespiau authored
      I've checked that TRANS_DDI_MODE, DP_TP_CTL MST bits are identical to
      HSW/BDW on SKL, as well as the long vs short HPD bits. So we have a good
      chance to be working as well as prevous platforms.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c86ea3d0
    • Damien Lespiau's avatar
      drm/i915: Consolidate DDI clock reading out in a single function · 22606a18
      Damien Lespiau authored
      2 pieces of code need to read out the DDI clock: the DDI encoder and the
      MST encoder .get_config() vfuncs.
      
      Until now the SKL read out code was only in the former, so let's move
      the pre and post SKL logic in intel_ddi_clock_get() and this this one
      everywhere.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      22606a18
    • Deepak M's avatar
      drm/i915: Parsing LFP brightness control from VBT · 371abae8
      Deepak M authored
      LFP brighness control from the VBT block 43 indicates which
      controller is used for brightness.
      LFP1 brightness control method:
      Bit 7-4 = This field controller number of the brightnes controller.
      0 = Controller 0
      1 = Controller 1
      2 = Controller 2
      3 = Controller 3
      Others = Reserved
      Bits 3-0 = This field specifies the brightness control pin to be used on the
      platform.
      0 = PMIC pin is used for brightness control
      1 = LPSS PWM is used for brightness control
      2 = Display DDI is used for brightness control
      3 = CABC method to control brightness
      Others = Reserved
      
      Adding the above fields in dev_priv->vbt and corresponding changes in
      parse_backlight()
      
      v2: Jani's review comments addressed
      	- Move PWM definitions to intel_bios.h
      	- Moving vbt_version to intel_vbt_data
      	- Rename brightness to bl_ctrl_data
      	- Logging just control_pin instead of string
      	- Avoid adding vbt_version in dev_priv
      	- Since only DDI option is available as of now, let control pin DDI
      	affect dev_priv->vbt.backlight.present
      
      v3: Jani's review comments addressed
      	- Drop control_pin
      	- Use bdb->version
      	- set controller to 0 instead of using control pin define
      	- check controller bounds
      	- remove superfluous changes in intel_parse_bios
      Signed-off-by: default avatarDeepak M <m.deepak@intel.com>
      Signed-off-by: default avatarVandana Kannan <vandana.kannan@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      371abae8
    • Sonika Jindal's avatar
      drm/i915/skl: Correcting the flushing of pipe · d9d8e6b3
      Sonika Jindal authored
      We were incorreectly bypassing the flush everytime which led to fifo
      underrun when more than one plane is enabled.
      Signed-off-by: default avatarSonika Jindal <sonika.jindal@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: Satheeshakrishna M<satheeshakrishna.m@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d9d8e6b3
    • Thomas Daniel's avatar
      drm/i915/bdw: Enable execlists by default where supported · 27401d12
      Thomas Daniel authored
      Execlist support in the i915 driver is now considered good enough for the
      feature to be enabled by default on Gen8 and later and routinely tested.
      Adjusted i915 parameters structure initialization to reflect this and updated
      the comment in intel_sanitize_enable_execlists().
      
      There's still work to do before we can let the wider massive onto it,
      but there's still time left before the 3.20 cutoff.
      
      v2: Update the MODULE_PARM_DESC too.
      
      Issue: VIZ-2020
      Signed-off-by: default avatarThomas Daniel <thomas.daniel@intel.com>
      [danvet: Add note that there's still some work left to do.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      27401d12
    • Sonika Jindal's avatar
      drm/i915/skl: Correctly updating sprite wm parameter · a712f8eb
      Sonika Jindal authored
      The pipe wm parameters is not correctly updated with sprite parameters
      because it copies them for each plane from plane_list to the sprite
      offset in pipe wm parameters. Since plane_list also contains primary and
      cursor planes, we end up updating wrong params for sprites.
      Signed-off-by: default avatarSonika Jindal <sonika.jindal@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a712f8eb
    • Tvrtko Ursulin's avatar
      drm/i915: Documentation for multiple GGTT views · 45f8f69a
      Tvrtko Ursulin authored
      A short section describing background, implementation and intended usage.
      
      v2:
          * Align section name between template and DOC comment. (Michel Thierry)
      
      For: VIZ-4544
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      45f8f69a
    • Tvrtko Ursulin's avatar
      drm/i915: Infrastructure for supporting different GGTT views per object · fe14d5f4
      Tvrtko Ursulin authored
      Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
      to map objects into the same address space multiple times.
      
      Added a GGTT view concept and linked it with the VMA to distinguish between
      multiple instances per address space.
      
      New objects and GEM functions which do not take this new view as a parameter
      assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
      previous behaviour.
      
      This now means that objects can have multiple VMA entries so the code which
      assumed there will only be one also had to be modified.
      
      Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
      which is DMA mapped on first VMA instantiation and unmapped on the last one
      going away.
      
      v2:
          * Removed per view special casing in i915_gem_ggtt_prepare /
            finish_object in favour of creating and destroying DMA mappings
            on first VMA instantiation and last VMA destruction. (Daniel Vetter)
          * Simplified i915_vma_unbind which does not need to count the GGTT views.
            (Daniel Vetter)
          * Also moved obj->map_and_fenceable reset under the same check.
          * Checkpatch cleanups.
      
      v3:
          * Only retire objects once the last VMA is unbound.
      
      v4:
          * Keep scatter-gather table for alternative views persistent for the
            lifetime of the VMA.
          * Propagate binding errors to callers and handle appropriately.
      
      v5:
          * Explicitly look for normal GGTT view in i915_gem_obj_bound to align
            usage in i915_gem_object_ggtt_unpin. (Michel Thierry)
          * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry)
          * Removed stray semi-colon in i915_gem_object_set_cache_level.
      
      For: VIZ-4544
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      [danvet: Drop hunk from i915_gem_shrink since it's just prettification
      but upsets a __must_check warning.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fe14d5f4
    • Deepak S's avatar
      drm/i915: Forcewake Register Range changes for CHV · db5ff4ac
      Deepak S authored
      According to updated BSpec, Render/Common/media Wells register range changed.
      Updating the same to match the spec and avoid extra forcewake for none
      forcewake range.
      
      v2: Update media forcewake range (Ville)
      Signed-off-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      db5ff4ac
    • Gaurav K Singh's avatar
      drm/i915: Changes related to the sequence port no for · f915084e
      Gaurav K Singh authored
      From now on for both DSI Ports A & C, the seq_port value has been
      set to 0. seq_port value is parsed from Sequence block#53 of VBT.
      So, for packets that needs to be read/write for DSI single link on
      Port A and Port C will now be based on the DVO port from VBT block 2,
      instead of seq_port.
      Signed-off-by: default avatarGaurav K Singh <gaurav.k.singh@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f915084e
    • Daniel Vetter's avatar
      drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON · 5f77eeb0
      Daniel Vetter authored
      Faster feedback to errors is always better. This is inspired by the
      addition to WARN_ONs to mask/enable helpers for registers to make sure
      callers have the arguments ordered correctly: Pretty much always the
      arguments are static.
      
      We use WARN_ON(1) a lot in default switch statements though where we
      should always handle all cases. So add a new macro specifically for
      that.
      
      The idea to use __builtin_constant_p is from Chris Wilson.
      
      v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
      Dave. My first attempt used __cond as the temp var, which is the same
      used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
      sprinkle i915 into the name.
      
      Also use a temporary variable to only evaluate the condition once,
      suggested by Damien.
      
      v3: It's crazy but apparently 32bit gcc can't compile out the
      BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
      why, but until clue grows just disable this nifty idea on 32bit
      builds. Reported by 0-day builder.
      
      v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
      Now reported by Imre.
      
      v5: Chris suggested to add the case to MISSING_CASE for speedier
      debug.
      
      v6: Even some gcc 4.9 versions don't see through the maze, so give up
      for now. Keep the skeleton and MISSING_CASE stuff though.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      5f77eeb0
    • Daniel Vetter's avatar
      drm/i915: Name the lrc irq handler correctly · 3f7531c3
      Daniel Vetter authored
      We consistently use the _irq_handler postfix for functions called in
      hardirq context. Especially when it's a non-static function hardirq is
      a crazy enough calling context to warrant this level of ocd. So rename
      it.
      
      Cc: Thomas Daniel <thomas.daniel@intel.com>
      Reviewed-by: default avatarThomas Daniel <thomas.daniel@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      3f7531c3
  3. 10 Dec, 2014 14 commits
  4. 08 Dec, 2014 3 commits
  5. 06 Dec, 2014 6 commits
    • John Harrison's avatar
      drm/i915: Additional request structure tracing · bcfcc8ba
      John Harrison authored
      Added the request structure's 'uniq' identifier to the trace information. Also
      renamed the '_complete' trace event to '_notify' as it actually happens in the
      IRQ 'notify_ring()' function. The intention is to add a new '_complete' trace
      event which occurs when a request structure is actually marked as complete.
      However, at the moment the completion status is re-tested every time the query
      is made so there isn't a completion event as such.
      
      v2: New patch added to series.
      
      v3: Rebased to remove completion caching as that is apparently contentious.
      
      Change-Id: Ic9bcde67d175c6c03b96217cdcb6e4cc4aa45d67
      For: VIZ-4377
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarThomas Daniel <Thomas.Daniel@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bcfcc8ba
    • John Harrison's avatar
      drm/i915: Add unique id to the request structure for debugging · 67e2937b
      John Harrison authored
      For debugging purposes, it is useful to be able to uniquely identify a given
      request structure as it works its way through the system. This becomes
      especially tricky once the seqno value is lazily allocated as then the request
      has nothing but its pointer to identify it for much of its life.
      
      Change-Id: Ie76b2268b940467f4cdf5a4ba6f5a54cbb96445d
      For: VIZ-4377
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarThomas Daniel <Thomas.Daniel@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      67e2937b
    • John Harrison's avatar
      drm/i915: Zero fill the request structure · aaeb1ba0
      John Harrison authored
      There is a general theory that kzmalloc is better/safer than kmalloc, especially
      for interesting data structures. This change updates the request structure
      allocation to be zero filled.
      
      This also fixes crashes in the reset code. Quoting Mika's patch:
      
      "Clean the request structure on alloc. Otherwise we might end up
      referencing uninitialized fields.  This is apparent when we try to
      cleanup the preallocated request on ring reset, before any request has
      been submitted to the ring.  The request->ctx is foobar and we end up
      freeing the foobarness."
      
      Note that this fixes a regression introduced in
      
      commit 9eba5d4a
      Author: John Harrison <John.C.Harrison@Intel.com>
      Date:   Mon Nov 24 18:49:23 2014 +0000
      
          drm/i915: Ensure OLS & PLR are always in sync
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=86959
      References: https://bugs.freedesktop.org/show_bug.cgi?id=86962
      References: https://bugs.freedesktop.org/show_bug.cgi?id=86992
      Change-Id: I68715ef758025fab8db763941ef63bf60d7031e2
      For: VIZ-4377
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarThomas Daniel <Thomas.Daniel@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aaeb1ba0
    • John Harrison's avatar
      drm/i915: Fix up seqno -> request merge issues · 146d84f0
      John Harrison authored
      The display related patches earlier in this series were edited during merge to
      improve the request unreferencing. Specifically, the need for de-referencing at
      interrupt time was removed. However, the resulting code did a 'deref(req) ; req
      = NULL' sequence rather than using the 'req_assign(req, NULL)' wrapper. The two
      are functionally equivalent, but using the wrapper is more consistent with all
      the other places where requests are assigned.
      
      Note that the whole point of the wrapper is that using it everywhere that
      request pointers are assigned means that the reference counting is done
      automatically and can't be accidentally forgotten about. Plus it allows simpler
      future maintainance if the reference counting mechanisms ever need to change.
      
      For: VIZ-4377
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      146d84f0
    • Matt Roper's avatar
      drm/i915: Make all plane disables use 'update_plane' (v5) · cf4c7c12
      Matt Roper authored
      If we extend the commit_plane handlers for each plane type to be able to
      handle fb=0, then we can easily implement plane disable via the
      update_plane handler.  The cursor plane already works this way, and this
      is the direction we need to go to integrate with the atomic plane
      handler.  We can now kill off the type-specific disable functions, as
      well as the redundant intel_plane_disable() (not to be confused with
      intel_disable_plane()).
      
      Note that prepare_plane_fb() only gets called as part of update_plane
      when fb!=NULL (by design, to match the semantics of the atomic plane
      helpers); this means that our commit_plane handlers need to handle the
      frontbuffer tracking for the disable case, even though they don't handle
      it for normal updates.
      
      v2:
       - Change BUG_ON to WARN_ON (Ander/Daniel)
      
      v3:
       - Drop unnecessary plane->crtc check since a previous patch to plane
         update ensures that plane->crtc will always be non-NULL, even for
         disable calls that might pass NULL from userspace.  (Ander)
       - Drop a s/crtc/plane->crtc/ hunk that was unnecessary.  (Ander)
      
      v4:
       - Fix missing whitespace (Ander)
      
      v5:
       - Use state's crtc rather than plane's crtc in
         intel_check_primary_plane().  plane->crtc could be NULL, but we've
         already fixed up state->crtc to ensure it's non-NULL (even if
         userspace passed it as NULL during a disable call).  (Ander)
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cf4c7c12
    • Matt Roper's avatar
      drm/i915: Ensure state->crtc is non-NULL for plane updates · e614c3c9
      Matt Roper authored
      When disabling a plane, it is legal to pass crtc = NULL.  Since planes
      on Intel hardware are tied to a fixed CRTC, go ahead and set state->crtc
      to the appropriate crtc in cases where it is passed to us as NULL.
      
      In a future patch, we will start using the update handler for plane
      disables, so this will help ensure we always have a non-NULL crtc
      pointer to work with.
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e614c3c9