1. 02 Jun, 2014 3 commits
  2. 30 May, 2014 3 commits
  3. 27 May, 2014 8 commits
  4. 26 May, 2014 4 commits
  5. 23 May, 2014 1 commit
  6. 19 May, 2014 6 commits
  7. 18 May, 2014 1 commit
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel into drm-next · e5daa1dd
      Dave Airlie authored
      - ring init improvements (Chris)
      - vebox2 support (Zhao Yakui)
      - more prep work for runtime pm on Baytrail (Imre)
      - eDram support for BDW (Ben)
      - prep work for userptr support (Chris)
      - first parts of the encoder->mode_set callback removal (Daniel)
      - 64b reloc fixes (Ben)
      - first part of atomic plane updates (Ville)
      
      * tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel: (75 commits)
        drm/i915: Remove useless checks from primary enable/disable
        drm/i915: Merge LP1+ watermarks in safer way
        drm/i915: Make sure computed watermarks never overflow the registers
        drm/i915: Add pipe update trace points
        drm/i915: Perform primary enable/disable atomically with sprite updates
        drm/i915: Make sprite updates atomic
        drm/i915: Support 64b relocations
        drm/i915: Support 64b execbuf
        drm/i915/sdvo: Remove ->mode_set callback
        drm/i915/crt: Remove ->mode_set callback
        drm/i915/tv: Remove ->mode_set callback
        drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set
        drm/i915/tv: De-magic device check
        drm/i915/tv: extract set_color_conversion
        drm/i915/tv: extract set_tv_mode_timings
        drm/i915/dvo: Remove ->mode_set callback
        drm/i915: Make encoder->mode_set callbacks optional
        drm/i915: Make primary_enabled match the actual hardware state
        drm/i915: Move ring_begin to signal()
        drm/i915: Virtualize the ringbuffer signal func
        ...
      e5daa1dd
  8. 16 May, 2014 2 commits
    • Dave Airlie's avatar
      Merge tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel into drm-next · 425a9a3a
      Dave Airlie authored
      Update pull request with drm core patches. Mostly some polish for the
      primary plane stuff and a pile of patches all over from Thierry. Has
      survived a few days in drm-intel-nightly without causing ill.
      
      I've frobbed my scripts a bit to also tag my topic branches so that you
      have something stable to pull - I've accidentally pushed a bunch more
      patches onto this branch before you've taken the old pull request.
      
      * tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel:
        drm: Make drm_crtc_helper_disable() return void
        drm: Fix indentation of closing brace
        drm/dp: Fix typo in comment
        drm: Fixup flip-work kerneldoc
        drm/fb: Fix typos
        drm/edid: Cleanup kerneldoc
        drm/edid: Drop revision argument for drm_mode_std()
        drm: Try to acquire modeset lock on panic or sysrq
        drm: remove unused argument from drm_open_helper
        drm: Handle ->disable_plane failures correctly
        drm: Simplify fb refcounting rules around ->update_plane
        drm/crtc-helper: gc usless connector loop in disable_unused_functions
        drm/plane_helper: don't disable plane in destroy function
        drm/plane-helper: Fix primary plane scaling check
        drm: make mode_valid callback optional
        drm/edid: Fill PAR in AVI infoframe based on CEA mode list
      425a9a3a
    • Dave Airlie's avatar
      drm: fix memory leak around mode_group (v2) · ad222799
      Dave Airlie authored
      This mode group id_list was never being freed.
      
      v2: take David's suggestion to free in minor_free.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ad222799
  9. 06 May, 2014 6 commits
  10. 05 May, 2014 6 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