1. 02 6月, 2014 2 次提交
  2. 30 5月, 2014 3 次提交
  3. 27 5月, 2014 8 次提交
  4. 26 5月, 2014 4 次提交
  5. 23 5月, 2014 1 次提交
  6. 19 5月, 2014 7 次提交
  7. 16 5月, 2014 2 次提交
    • D
      Merge tag 'topic/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel into drm-next · 425a9a3a
      Dave Airlie 提交于
      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
    • D
      drm: fix memory leak around mode_group (v2) · ad222799
      Dave Airlie 提交于
      This mode group id_list was never being freed.
      
      v2: take David's suggestion to free in minor_free.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ad222799
  8. 06 5月, 2014 6 次提交
  9. 05 5月, 2014 7 次提交
    • B
      drm/i915: Support 64b relocations · d9ceb957
      Ben Widawsky 提交于
      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: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d9ceb957
    • B
      drm/i915: Support 64b execbuf · 9bcb144c
      Ben Widawsky 提交于
      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: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9bcb144c
    • D
      drm/i915/sdvo: Remove ->mode_set callback · 192d47a6
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      192d47a6
    • D
      drm/i915/crt: Remove ->mode_set callback · 894ed1ec
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      894ed1ec
    • D
      drm/i915/tv: Remove ->mode_set callback · 809a2a8b
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      809a2a8b
    • D
      drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set · 3fa2dd14
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3fa2dd14
    • D
      drm/i915/tv: De-magic device check · 5da92eef
      Daniel Vetter 提交于
      We only support TV-out on gen3/4 mobile platforms, and i915gm is the
      only one that matches.
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5da92eef