1. 15 Dec, 2014 6 commits
    • 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
  2. 10 Dec, 2014 14 commits
  3. 08 Dec, 2014 3 commits
  4. 06 Dec, 2014 11 commits
  5. 05 Dec, 2014 6 commits