1. 16 Dec, 2014 12 commits
  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 2 commits
    • Daniel Vetter's avatar
      drm/i915: Check mask/bit helper functions · 15a17aae
      Daniel Vetter authored
      After a bit of irc discussion we've concluded that it would be prudent
      to check that callers use the mask/enable paramters correctly. So add
      a WARN_ON.
      
      Spurred by Damien's bugfix which added _MASKED_FIELD.
      
      v2: We use WARN_ON(1) a lot to catch default cases in switch blocks
      which should always be extended. So this doesn't work really. Dunno
      why gcc only started complaining when I've moved the WARN out of the
      static inline helper to address a feedback from Jani.
      
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      15a17aae
    • Daniel Vetter's avatar
      drm/i915: Move golden context init into ->init_context · 8f0e2b9d
      Daniel Vetter authored
      Similar to a patch from Thomas Daniel for lrc contexts. This keeps
      both sides somewhat in sync and should make Dave Gordon happy.
      
      Note that both the wa and the golden context init code suffer a bit
      from an inssuficient split into driver load and hw init code. Which
      means we have a bunch of tests all over the place to check whether the
      one-time initialization has been done already or not.
      
      All that one-tim code should be moved into the one-time ring setup
      code, but that's work for later.
      
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Cc: Thomas Daniel <thomas.daniel@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: default avatarDave Gordon <david.s.gordon@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8f0e2b9d