An error occurred fetching the project authors.
  1. 20 Jan, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: use drm_modeset_lock_all · a0e99e68
      Daniel Vetter authored
      Two exceptions:
      - debugfs files only read information which is not related to crtc, so
        can stay on the modeset_config lock.
      - Same holds for the edp vdd work in intel_dp.c. Add a corresponding
        WARN_ON and a comment next to the intel_dp struct fields for
        documentation.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a0e99e68
  2. 17 Jan, 2013 1 commit
    • Ben Widawsky's avatar
      drm/i915: Create a gtt structure · 5d4545ae
      Ben Widawsky authored
      The purpose of the gtt structure is to help isolate our gtt specific
      properties from the rest of the code (in doing so it help us finish the
      isolation from the AGP connection).
      
      The following members are pulled out (and renamed):
      gtt_start
      gtt_total
      gtt_mappable_end
      gtt_mappable
      gtt_base_addr
      gsm
      
      The gtt structure will serve as a nice place to put gen specific gtt
      routines in upcoming patches. As far as what else I feel belongs in this
      structure: it is meant to encapsulate the GTT's physical properties.
      This is why I've not added fields which track various drm_mm properties,
      or things like gtt_mtrr (which is itself a pretty transient field).
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      [Ben modified commit messages]
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5d4545ae
  3. 30 Nov, 2012 1 commit
  4. 23 Oct, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix overlay on i830M · a9193983
      Daniel Vetter authored
      The overlay on the i830M has a peculiar failure mode: It works the
      first time around after boot-up, but consistenly hangs the second time
      it's used.
      
      Chris Wilson has dug out a nice errata:
      
      "1.5.12 Clock Gating Disable for Display Register
      Address Offset:	06200h–06203h
      
      "Bit 3
      Ovrunit Clock Gating Disable.
      0 = Clock gating controlled by unit enabling logic
      1 = Disable clock gating function
      DevALM Errata ALM049: Overlay Clock Gating Must be Disabled:  Overlay
      & L2 Cache clock gating must be disabled in order to prevent device
      hangs when turning off overlay.SW must turn off Ovrunit clock gating
      (6200h) and L2 Cache clock gating (C8h)."
      
      Now I've nowhere found that 0xc8 register and hence couldn't apply the
      l2 cache workaround. But I've remembered that part of the magic that
      the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache
      allocations so that the overlay scaler has some scratch space.
      
      And while pondering how that could explain the hang the 2nd time we
      enable the overlay, I've remembered that the old ums overlay code did
      _not_ issue the OVERLAY_OFF cmd.
      
      And indeed, disabling the OFF cmd results in the overlay working
      flawlessly, so I guess we can workaround the lack of the above
      workaround by simply never disabling the overlay engine once it's
      enabled.
      
      Note that we have the first part of the above w/a already implemented
      in i830_init_clock_gating - leave that as-is to avoid surprises.
      
      v2: Add a comment in the code.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827
      Cc: stable@vger.kernel.org
      Tested-by: default avatarRhys <rhyspuk@gmail.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a9193983
  5. 12 Oct, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Disallow preallocation of requests · acb868d3
      Chris Wilson authored
      The intention was to allow the caller to avoid a failure to queue a
      request having already written commands to the ring. However, this is a
      moot point as the i915_add_request() can fail for other reasons than a
      mere allocation failure and those failure cases are more likely than
      ENOMEM. So the overlay code already had to handle i915_add_request()
      failures, and due to
      
      commit 3bb73aba
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jul 20 12:40:59 2012 +0100
      
          drm/i915: Allow late allocation of request for i915_add_request()
      
      the error handling code in intel_overlay.c was subject to causing
      double-frees, as found by coverity.
      
      Rather than further complicate i915_add_request() and callers, realise
      the battle is lost and adapt intel_overlay.c to take advantage of the
      late allocation of requests.
      
      v2: Handle callers passing in a NULL seqno.
      v3: Ditto. This time for sure.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      acb868d3
  6. 02 Oct, 2012 2 commits
  7. 24 Aug, 2012 1 commit
  8. 17 Aug, 2012 1 commit
  9. 25 May, 2012 1 commit
  10. 04 May, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo · f7bacf19
      Daniel Vetter authored
      Our handling of the crtc timing computation has been nicely
      cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
      the place. But with
      
      commit f9bef081
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sun Apr 15 19:53:19 2012 +0200
      
          drm/i915: don't clobber the special upscaling lvds timings
      
      and
      
      commit ca9bfa7e
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Jan 28 14:49:20 2012 +0100
      
          drm/i915: fixup interlaced vertical timings confusion, part 1
      
      we now only set the crtc timing fields in the encoder->mode_fixup
      (lvds only) and in crtc->mode_fixup (for everyone else). And since
      
      commit 75c13993
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Jan 28 23:48:46 2012 +0100
      
          drm/i915: fixup overlay checks for interlaced modes
      
      the only places we actually need the crtc timings is in the mode_set
      function.
      
      I guess the idea of the drm core is that every time it creates a drm
      mode, it also sets the timings. But afaics it never uses them, safe
      for the precise vblank timestamp code (but that can only run on active
      modes, i.e.  after our mode_fixup functions have been called). The
      problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
      timings are pretty much bogus for us anyway (at least with interlaced
      support).
      
      So I guess it's the drivers job that every active modes needs to have
      crtc timings that suits it, and with these patches we should have
      that. drm core doesn't seem to care about modes that just get passed
      around. Hence we can now safely rip out all the remaining calls to
      set_crtcinfo left in the driver and clean up this confusion.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f7bacf19
  11. 03 May, 2012 4 commits
  12. 16 Feb, 2012 1 commit
  13. 10 Feb, 2012 2 commits
    • Daniel Vetter's avatar
      drm/i915: fixup overlay checks for interlaced modes · 75c13993
      Daniel Vetter authored
      The drm core _really_ likes to frob around with the crtc timings and
      put halfed vertical timings (in fields) in there. Which confuses the
      overlay code, resulting in it's refusal to display anything at the
      lower half of an interlaced pipe.
      Tested-by: default avatarChristopher Egert <cme3000@gmail.com>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      75c13993
    • Daniel Vetter's avatar
      drm/i915: fixup interlaced vertical timings confusion, part 1 · ca9bfa7e
      Daniel Vetter authored
      We have a pretty decent confusion about vertical timings of interlaced
      modes. Peter Ross has written a patch that makes interlace modes work
      on a lot more platforms/output combinations by doubling the vertical
      timings.
      
      The issue with that patch is that core drm _does_ support specifying
      whether we want these vertical timings in fields or frames, we just
      haven't managed to consistently use this facility. The relavant
      function is drm_mode_set_crtcinfo, which fills in the crtc timing
      information.
      
      The first thing to note is that the drm core keeps interlaced modes in
      frames, but displays modelines in fields. So when the crtc modeset
      helper copies over the mode into adjusted_mode it will already contain
      vertical timings in half-frames. The result is that the fixup code in
      intel_crtc_mode_fixup doesn't actually do anything (in most cases at
      least).
      
      Now gen3+ natively supports interlaced modes and wants the vertical
      timings in frames. Which is what sdvo already fixes up, at least under
      some conditions.
      
      There are a few other place that demand vertical timings in fields
      but never actually deal with interlaced modes, so use frame timings
      for consistency, too. These are:
      - lvds panel,
      - dvo encoders - dvo is the only way gen2 could support interlaced
        mode, but currently we don't support any encoders that do.
      - tv out - despite that the tv dac sends out an interlaced signal it
        expects a progressive mode pipe configuration.
      All these encoders enforce progressive modes by resetting
      interlace_allowed.
      
      Hence we always want crtc vertical timings in frames. Enforce this in
      our crtc mode_fixup function and rip out any redudant timing
      computations from the encoders' mode_fixup function.
      
      v2-4: Adjust the vertical timings a bit.
      
      v5: Split out the 'subtract-one for interlaced' fixes.
      
      v6: Clarify issues around tv-out and gen2.
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: default avatarChristopher Egert <cme3000@gmail.com>
      Tested-by: default avatarAlfonso Fiore <alfonso.fiore@gmail.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ca9bfa7e
  14. 26 Jan, 2012 1 commit
  15. 20 Sep, 2011 1 commit
  16. 30 Jun, 2011 1 commit
  17. 28 Jun, 2011 2 commits
  18. 10 Jun, 2011 2 commits
  19. 22 Feb, 2011 2 commits
    • Chris Wilson's avatar
      drm/i915: Use a device flag for non-interruptible phases · ce453d81
      Chris Wilson authored
      The code paths for modesetting are growing in complexity as we may need
      to move the buffers around in order to fit the scanout in the aperture.
      Therefore we face a choice as to whether to thread the interruptible status
      through the entire pinning and unbinding code paths or to add a flag to
      the device when we may not be interrupted by a signal. This does the
      latter and so fixes a few instances of modesetting failures under stress.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      ce453d81
    • Chris Wilson's avatar
      drm/i915: Protect against drm_gem_object not being the first member · c8725226
      Chris Wilson authored
      Dave Airlie spotted that we had a potential bug should we ever rearrange
      the drm_i915_gem_object so not the base drm_gem_object was not its first
      member. He noticed that we often convert the return of
      drm_gem_object_lookup() immediately into drm_i915_gem_object and then
      check the result for nullity. This is only valid when the base object is
      the first member and so the superobject has the same address. Play safe
      instead and use the compiler to convert back to the original return
      address for sanity testing.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      c8725226
  20. 07 Feb, 2011 2 commits
  21. 05 Dec, 2010 1 commit
  22. 02 Dec, 2010 1 commit
    • Chris Wilson's avatar
      drm/i915: Pipelined fencing [infrastructure] · d9e86c0e
      Chris Wilson authored
      With this change, every batchbuffer can use all available fences (save
      pinned and scanout, of course) without ever stalling the gpu!
      
      In theory. Currently the actual pipelined update of the register is
      disabled due to some stability issues. However, just the deferred update
      is a significant win.
      
      Based on a series of patches by Daniel Vetter.
      
      The premise is that before every access to a buffer through the GTT we
      have to declare whether we need a register or not. If the access is by
      the GPU, a pipelined update to the register is made via the ringbuffer,
      and we track the last seqno of the batches that access it. If by the
      CPU we wait for the last GPU access and update the register (either
      to clear or to set it for the current buffer).
      
      One advantage of being able to pipeline changes is that we can defer the
      actual updating of the fence register until we first need to access the
      object through the GTT, i.e. we can eliminate the stall on set_tiling.
      This is important as the userspace bo cache does not track the tiling
      status of active buffers which generate frequent stalls on gen3 when
      enabling tiling for an already bound buffer.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d9e86c0e
  23. 23 Nov, 2010 1 commit
  24. 04 Nov, 2010 1 commit
    • Daniel Vetter's avatar
      drm/i915: kill mappable/fenceable disdinction · 75e9e915
      Daniel Vetter authored
      a00b10c3 "Only enforce fence limits inside the GTT" also
      added a fenceable/mappable disdinction when binding/pinning buffers.
      This only complicates the code with no pratical gain:
      
      - In execbuffer this matters on for g33/pineview, as this is the only
        chip that needs fences and has an unmappable gtt area. But fences
        are only possible in the mappable part of the gtt, so need_fence
        implies need_mappable. And need_mappable is only set independantly
        with relocations which implies (for sane userspace) that the buffer
        is untiled.
      
      - The overlay code is only really used on i8xx, which doesn't have
        unmappable gtt. And it doesn't support tiled buffers, currently.
      
      - For all other buffers it's a bug to pass in a tiled bo.
      
      In short, this disdinction doesn't have any practical gain.
      
      I've also reverted mapping the overlay and context pages as possibly
      unmappable. It's not worth being overtly clever here, all the big
      gains from unmappable are for execbuf bos.
      
      Also add a comment for a clever optimization that confused me
      while reading the original patch by Chris Wilson.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      75e9e915
  25. 29 Oct, 2010 1 commit
    • Chris Wilson's avatar
      drm/i915: Only enforce fence limits inside the GTT. · a00b10c3
      Chris Wilson authored
      So long as we adhere to the fence registers rules for alignment and no
      overlaps (including with unfenced accesses to linear memory) and account
      for the tiled access in our size allocation, we do not have to allocate
      the full fenced region for the object. This allows us to fight the bloat
      tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside
      the GTT we still suffer the additional alignment constraints, so it doesn't
      magic allow us to render larger scenes without stalls -- we need the
      expanded GTT and fence pipelining to overcome those...]
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      a00b10c3
  26. 27 Oct, 2010 4 commits
  27. 26 Oct, 2010 1 commit
    • Peter Zijlstra's avatar
      mm: stack based kmap_atomic() · 3e4d3af5
      Peter Zijlstra authored
      Keep the current interface but ignore the KM_type and use a stack based
      approach.
      
      The advantage is that we get rid of crappy code like:
      
      	#define __KM_PTE			\
      		(in_nmi() ? KM_NMI_PTE : 	\
      		 in_irq() ? KM_IRQ_PTE :	\
      		 KM_PTE0)
      
      and in general can stop worrying about what context we're in and what kmap
      slots might be appropriate for that.
      
      The downside is that FRV kmap_atomic() gets more expensive.
      
      For now we use a CPP trick suggested by Andrew:
      
        #define kmap_atomic(page, args...) __kmap_atomic(page)
      
      to avoid having to touch all kmap_atomic() users in a single patch.
      
      [ not compiled on:
        - mn10300: the arch doesn't actually build with highmem to begin with ]
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3e4d3af5
  28. 21 Sep, 2010 1 commit