1. 12 May, 2014 12 commits
  2. 07 May, 2014 8 commits
  3. 06 May, 2014 13 commits
  4. 05 May, 2014 7 commits
    • Ben Widawsky's avatar
      drm/i915: Support 64b relocations · d9ceb957
      Ben Widawsky authored
      All the rest of the code to enable this is in my branch. Without my
      branch, hitting > 32b offsets is impossible. The code has always
      "supported" 64b, but it's never actually been run of tested. This change
      doesn't actually fix anything. [1] I am not sure why X won't work yet. I
      do not get hangs or obvious errors.
      
      There are 3 fixes grouped together here. First is to remove the
      hardcoded 0 for the upper dword of the relocation. The next fix is to
      use a 64b value for target_offset. The final fix is to not directly
      apply target_offset to reloc->delta. reloc->delta is part of ABI, and so
      we cannot change it. As it stands, 32b is enough to represent everything
      we're interested in representing anyway. The main problem is, we cannot
      add greater than 32b values to it directly.
      
      [1] Almost all of intel-gpu-tools is not yet ready to test 64b
      relocations. There are a few places that expect 32b values for offsets
      and these all won't work.
      
      Cc: Rafael Barbalho <rafael.barbalho@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d9ceb957
    • Ben Widawsky's avatar
      drm/i915: Support 64b execbuf · 9bcb144c
      Ben Widawsky authored
      Previously, our code only had a 32b offset value for where the
      batchbuffer starts. With full PPGTT, and 64b canonical GPU address
      space, that is an insufficient value. The code to expand is pretty
      straight forward, and only one platform needs to do anything with the
      extra bits.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9bcb144c
    • Daniel Vetter's avatar
      drm/i915/sdvo: Remove ->mode_set callback · 192d47a6
      Daniel Vetter authored
      SDVO is used by both crtcs using the i9xx_ and the ironlake_
      functions. For both cases there is nothing between the
      encoder->mode_set and the encoder->pre_enable calls that touches the
      hardware.
      
      The vlv_ functions are different since they enable the pll before the
      ->pre_enable hook. But SDVO isn't supported on vlv platforms, so this
      doesn't matter.
      
      We've also already clean up all the sdvo state computation logic, all
      relevant parts are already in the ->compute_config hook.  So we can
      just get rid of the ->mode_set hook by converting it to a ->pre_enable
      hook.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      192d47a6
    • Daniel Vetter's avatar
      drm/i915/crt: Remove ->mode_set callback · 894ed1ec
      Daniel Vetter authored
      We only set a few bits in the ADPA register, which we then read back
      in the enable/disable hooks. So we can just move that bit of state
      computation code to the place where we need it since setting these
      bits without enabling the CRT encoder has no effects.
      
      The only exceptions are the hotplug bits since they affect the hotplug
      detection logic, but we already set those in the ->reset function and
      then never touch them.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      894ed1ec
    • Daniel Vetter's avatar
      drm/i915/tv: Remove ->mode_set callback · 809a2a8b
      Daniel Vetter authored
      Currently for the i9xx crtc hooks there's nothing between the call to
      encoder->mode_set and encoder->pre_enable which touches the hardware.
      
      Therefore, since tv is only used on gen3/4, we can just move the hook.
      Yay for easy cases!
      
      The only other important thing to check is that the new
      ->pre_enable hook is idempotent wrt the sw state since now it can
      be called multiple times (due to DPMS). After a the bit of refactoring
      this is now easy to check: It only reads crtc->config and computes
      derived state but otherwise leaves it as-is, so we're good.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      809a2a8b
    • Daniel Vetter's avatar
      drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set · 3fa2dd14
      Daniel Vetter authored
      The pipe and plane _are_ disabled when we call this. So replace it
      all with the corresponding assert (as self-documenting code) and
      rip out all the lore.
      
      Checking for a disabled plane would require us to export those macros
      from intel_display.c, but if the pipe is off the plane isn't working
      either. So this single check is good enough.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3fa2dd14
    • Daniel Vetter's avatar
      drm/i915/tv: De-magic device check · 5da92eef
      Daniel Vetter authored
      We only support TV-out on gen3/4 mobile platforms, and i915gm is the
      only one that matches.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5da92eef