- 03 May, 2012 40 commits
-
-
Ben Widawsky authored
This extra bit of interrupt enabling code doesn't belong in the wait seqno function. If anything we should pull it out to a helper so the throttle code can also use it. The history is a bit vague, but I am going to attempt to just dump it, unless someone can argue otherwise. Removing this allows for a shared lock free wait seqno function. To keep tabs on this issue though, the IER value is stored on error capture (recommended by Chris Wilson) v2: fixed typo EIR->IER (Ben) Fix some white space (Ben) Move IER capture to globally instead of per ring (Ben) Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: ier is a 16 bit reg on gen2!] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
This originates from a hack by me to quickly fix a bug in an earlier patch where we needed control over whether or not waiting on a seqno actually did any retire list processing. Since the two operations aren't clearly related, we should pull the parameter out of the wait function, and make the caller responsible for retiring if the action is desired. The only function call site which did not get an explicit retire_request call (on purpose) is i915_gem_inactive_shrink(). That code was already calling retire_request a second time. v2: don't modify any behavior excepit i915_gem_inactive_shrink(Daniel) Signed-off-by:
-
Daniel Vetter authored
I've missed this one. v2: Chris Wilson noticed another register. v3: Color choice improvements. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
-
Chris Wilson authored
Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Chris Wilson authored
Since there is only one remaining user of I915_INTERRUPT_ENABLE_FIX, expand it at the callsite. Quoting Jesse Barnes: "I'd really like to get rid of these defines at the top of i915_irq.c. Some are unused and the others just make you check for the right bits everytime your read the code." Signed-off-by:
-
Chris Wilson authored
We appear to allow too many pending pageflips as evidenced by an apparent pin-leak. So borrow the pageflip completion logic from i8xx for handling PendingFlip in a robust manner. v2: Address Jesse's reminders about the nuances of gen3 IRQ handling. References: https://bugzilla.kernel.org/show_bug.cgi?id=41882Signed-off-by:
-
Chris Wilson authored
Bring the for-each-pipe loops together so that the code is easier on the eyes. Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
A couple of miscellaneous cleanups as well to move per-loop condition variables within the scope of the loop and the update of the DRI1 breadcrumb to the tail of the function. Signed-off-by:
-
Chris Wilson authored
And a couple of miscellaneous cleanups to the main body of the IRQ loop; move per-loop condition variables within the scope of the loop and move the old DRI1 breadcrumb to the tail of the function and so only execute it once. Signed-off-by:
-
Chris Wilson authored
On later gen3, you are able to select the meaning of the FlipPending status bit in IIR and change it to FlipDone. This was sometimes done by the BIOS leading to confusion on just how pageflipping worked on gen3. Simplify the implementation by using the legacy meaning for all gen3 machines. Note: this makes all gen3 machines equally broken... Signed-off-by:
-
Chris Wilson authored
In preparation for rewriting the gen3 irq handler. Signed-off-by:
-
Chris Wilson authored
And remove the cargo-culted copy from the valleyview irq handler. Signed-off-by:
-
Chris Wilson authored
The waitqueues are already initialised during ring initialisation so kill the redundant and duplicated code to do so in each generations IRQ installer. Signed-off-by:
-
Chris Wilson authored
Rather than duplicate similar code across the IRQ installers, perform the initialisation of the workers upfront. This will lead to simpler teardown and quiescent code as we can assume that the workers have been initialised. Signed-off-by:
-
Daniel Vetter authored
Calling these when gem assumes full control of the hw won't end in anything else than tears. So be a bit more paranoid here. Just serves as documentation. v2: Bail out with ENODEV as suggested by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
Always true these days. It has been added originally to work around some issues with the agp layer in 2.6.29: commit ac5c4e76 Author: Dave Airlie <airlied@redhat.com> Date: Fri Dec 19 15:38:34 2008 +1000 drm/i915: GEM on PAE has problems - disable it for now. Reviewed-by:
-
Daniel Vetter authored
We always set it so there's no point in checking. We could instead add a bit that tells us whether gem is actually initialized (i.e. either kms or gem_init_ioctl called), but that's imho not worth it. So just rip it out. There's a little change in the wait_ring timeout, but we've never run with anything else than the 60 second timeout, even on dri1 userspace. Reviewed-by:
-
Daniel Vetter authored
This ioctl used in a kms driver is only useful to create massive havoc. v2: Bail out with -ENODEV as suggested by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
Also ditch the cargo-culted dev_priv checks - either we have a giant hole in our setup code or this is useless. Plainly bogus to check for it in either case. v2: Chris Wilson noticed that I've missed one bogus dev_priv check. v3: The check in the overlay code is redundant (Chris) Reviewed-by:
-
Chris Wilson authored
The specs recommend that this bit be set on PineView. No reason is given, but it sounds like a powersaving bit that we should expect the BIOS to be setting... v2: Rebase on top of _MASKED_ENABLE_BIT Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
We slightly modify the initialisation sequence to move the initialisation of the memory managers earlier and in particular before probing outputs and detecting any existing output configuration. This is essential if we wish to track preallocated objects and preserve them whilst initialising GEM. Signed-off-by:
-
Chris Wilson authored
The use of the mm_list by deferred-free breaks the following patches to extend the range of objects tracked. We can simplify things if we just make the unbind during free uninterrutible. Note that unbinding should never fail, because we hold an additional reference on every active object. Only the ilk vt-d workaround breaks this, but already takes care of not failing by waiting for the gpu to quiescent non-interruptible. But the existence of the deferred free list casted some doubts on this theory, hence WARN if the unbind fails and only then retry non-interruptible. We can kill this additional code after a release in case the theory is indeed right and no one has hit that WARN. Signed-off-by:
-
Chris Wilson authored
Simplify object tracking by removing the inactive but pinned list. The only place where this was used is for counting the available memory, which is just as easy performed by checking all objects on the rare occasions it is required (application startup). For ease of debugging, we keep the reporting of pinned objects through the error-state and debugfs. Signed-off-by:
-
Chris Wilson authored
This was only used by one external caller who would just be as happy with evict-everything, so perform the replacement and make the function private. In the process we note that unbinding the inactive list should not fail, and make it a warning instead. Signed-off-by:
-
Chris Wilson authored
Currently, we only bump the inactive LRU of an object when we bind into the GTT for a page-fault. As the object may be used many times before its mapping is zapped, we do not mark it as active as frequently as we should. Userspace should be calling set-to-GTT-domain before each pointer deference (for synchronous access) and so is a good place to mark the buffer as active. Marking the buffer as recently used places it at the end of the inactive eviction queue, though still before anything with outstanding rendering. This reduces the likelihood of evicting a buffer that is going to be used again by the CPU in the near future. This way we can hopefully avoid to kick out upload buffers right before we use them on the gpu. Note that we need to check that the object is not active or pinned, for otherwise we create havoc on the active/pinned lists, which also use obj->mm_list. The active lists are sorted by and evicted in last GPU rendering order, access by the CPU to a still active buffer therefore does not affect its eviction ordering. Pinned objects are currently excluded from eviction, therefore the only list that we need to bump for GTT access by the CPU is the inactive list. Signed-off-by:
-
Chris Wilson authored
Enabling the plane before we have assigned valid address means that it will access random PTE (often with conflicting memory types) and cause GPU lockups. However, enabling the plane too early appears to workaround a number of bugs in our modesetting code. Cc: Franz Melchior <melchior.franz@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=39947 References: https://bugs.freedesktop.org/show_bug.cgi?id=41091 References: https://bugs.freedesktop.org/show_bug.cgi?id=49041Signed-off-by:
-
Chris Wilson authored
We were attempting to use a per-ring spinlock whilst modifying global IRQ flags. A recipe for rare missed interrupts. Signed-off-by:
-
Daniel Vetter authored
Copy&pasted from the vlv setup code. According to docs, we need that on ivb, too. v2: Use new masked bit handling macros. Reviewed-by:
-
Daniel Vetter authored
... and put them to so good use. Note that there's functional change in vlv clock gating code, we now no longer spuriously read back the current value of the bit. According to Bspec the high bits should always read zero, so ORing this in should have no effect. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
-
Jesse Barnes authored
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just treat them as part of the pipe. So split the code out and manage PCH PLLs separately, allocating them when needed or trying to re-use existing PCH PLL setups when the timings match. v2: add num_pch_pll field to dev_priv (Daniel) don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) put register offsets in pll struct (Chris) v3: Decouple enable/disable of PLLs from get/put. v4: Track temporary PLL disabling during modeset v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni) v6: Avoid mishandling allocation failure by embedding the small array of PLLs into the device struct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+) Reviewed-by: -
Chris Wilson authored
gen2 hardware has some significant differences from the other interrupt routines that were glossed over and then forgotten about in the transition to KMS. Such as - 16bit IIR - PendingFlip status bit This patch reintroduces a handler specifically for gen2 for the purpose of handling pageflips correctly, simplifying code in the process. v2: Also fixup ring get/put irq to only access 16bit registers (Daniel) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24202 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41793Signed-off-by:
-
Chris Wilson authored
If we fail to unbind and so abort the change in tiling, we will have removed the VMA for the object for no reason. The likelihood of unbind failing is slim (other than ERESTARTSYS which will cause userspace to try again), so the change is mostly for the principle. Also improve the slightly stale comment. Signed-off-by:
-
Chris Wilson authored
Rename obj->tiling_changed to obj->fence_dirty so that it is clear that it flags when the parameters for an active fence (including the no-fence) register are changed. Also, do not set this flag when the object does not have a fence register allocated currently and the gpu does not depend upon the unfence. This case works exactly like when a tiled object lost its fence and hence does not need additional handling for the tiling change in the code. v2: Use fence_dirty to better express what the flag tracks and add a few more details to the comments to serve as a reminder of how the GPU also uses the unfenced register slot. Signed-off-by:
-
Daniel Vetter authored
When fixing up the crt load detect code I've failed to notice the same problem in the tv load detect code. Again, unconditionally use the load detect pipe infrastructure, it gets things right. Reviewed-by:
-
Daniel Vetter authored
This got lost in the intel_pm.c move. Signed-off-by: -
Ben Widawsky authored
As with one of the earlier patches in the series, we're forced to cast for copy_[to|from]_user. Again because of the nature of the GEN x86 exclusivity, this should be safe. Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> [danvet: Added some bikeshed.] Signed-off-by:
-
Daniel Vetter authored
These were mostly straight forward. No forced casting needed. Signed-off-by:
-
Ben Widawsky authored
With the exception of a forced cast for phys_obj stuff (a problem in other patches as well) all of these are fairly simple __iomem compliance fixes. As with other patches, yank/paste errors may exist. Signed-off-by:
-
