- 20 Jun, 2012 20 commits
-
-
Jesse Barnes authored
With the code in place, we can bind the driver, should make bisect possible. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Enable the on-chip messaging between the display engine and the GT. v2: use bit definitions for DPFLIPSTAT reg Signed-off-by:
-
Jesse Barnes authored
And restructure the IRQ handling a little. We can use pipestat for most things, and make sure we don't affect pipe events when enabling and disabling vblank interupts. We can leave vblank interrupts masked but enabled so we're not dependent on the first client to toggle the disable timer. We can also mask all render based interrupts, since the ring code will handle unmasking them for us. v2: roll in vblank masking, remove unneeded variable (Daniel) Signed-off-by:
-
Jesse Barnes authored
Needs some more work and testing. Signed-off-by:
-
Jesse Barnes authored
VLV is a gen7 device, but we don't currently handle that in the switch. So add it and write the PTEs correctly. Signed-off-by:
-
Jesse Barnes authored
The PTE format is similar to SNB, but we don't support an MLC and don't need chipset flushing. Note: I have my questions whether this is right, given that MLC died for snb & ivb, that ivb has grown a L3$ cache instead (which vlv seems to have, too) and that the LLC bit here isn't actually LLC, but just means 'snoop cpu caches'. But I plan to burn this all with the heat of a thousands suns in my gtt rework, so who cares ;-) Signed-off-by:
-
Jesse Barnes authored
Signed-off-by:
-
Jesse Barnes authored
Since the offsets have all moved around. v2: switch IS_DISPLAYREG and IS_VALLEYVIEW checks around since the latter is cheaper (Daniel) bail out early in IS_DISPLAYREG if the reg is in the new range (Daniel) Signed-off-by: -
Jesse Barnes authored
ValleyView is similar to IbexPeak here, but with different register offsets. v2: use SDVOB instead ov VLV_HDMIB (Daniel) drop unnecessary eDP check in DP_C init (Daniel) eDP support will be coming later from Shobit. Signed-off-by: -
Jesse Barnes authored
Might be able to merge this back in at some point, but we're seeing bugs with ADPA based detection, so keep it separate for now with explicit hotplug trigger usage. v2: drop superfluous debug message v3: comment forced detection, need to debug (Eugeni) Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
Shobhit Kumar authored
VLV supports two dp panels, there are two set of panel power sequence registers which needed to be programmed based on the configured pipe. This patch add supports for the same Acked-by:
Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Beeresh G <beeresh.g@intel.com> Reviewed-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by:
Jesse Barnes <jesse.barnes@intel.com> Signed-off-by:
-
Jesse Barnes authored
Add some VLV limit structures and update the PLL code. v2: resolve conflicts, Vijay to re-post with PLL valid checks and fixed limits v3: re-add dpio write function v4: squash in Vijay's fixes for the PLL limits and clean up the m/n finder Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Daniel Vetter authored
This is just the minimal patch to disable all this code so that we can do decent amounts of QA before we rip it all out. The complicating thing is that we need to flush the gpu caches after the batchbuffer is emitted. Which is past the point of no return where execbuffer can't fail any more (otherwise we risk submitting the same batch multiple times). Hence we need to add a flag to track whether any caches associated with that ring are dirty. And emit the flush in add_request if that's the case. Note that this has a quite a few behaviour changes: - Caches get flushed/invalidated unconditionally. - Invalidation now happens after potential inter-ring sync. I've bantered around a bit with Chris on irc whether this fixes anything, and it might or might not. The only thing clear is that with these changes it's much easier to reason about correctness. Also rip out a lone get_next_request_seqno in the execbuffer retire_commands function. I've dug around and I couldn't figure out why that is still there, with the outstanding lazy request stuff it shouldn't be necessary. v2: Chris Wilson complained that I also invalidate the read caches when flushing after a batchbuffer. Now optimized. v3: Added some comments to explain the new flushing behaviour. Cc: Eric Anholt <eric@anholt.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
-
Daniel Vetter authored
It seems to blow up my ilk in all kinds of strange ways. And now that we're no longer resetting the entire modeset state, it shouldn't be necessary any longer. This essentially reverts commit f817586c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 10 15:50:11 2012 +0200 drm/i915: re-init modeset hw state after gpu reset safe for the introduction of modeset_init_hw, that one is nice to prevent code duplication between driver load and resume. v2: Add a comment to the code to warn future travellers of the dragon dungeon ahead, suggested by Chris Wilson. Acked-by:
-
Daniel Vetter authored
Otherwise userspace has no way to figure this out. Reviewed-by:
-
Daniel Vetter authored
The idr code already passes us the pointer associated with that id, so no need to look it up again. Also, we'll kill the idr right away, so there's no issue with leaving these dangling pointers behind - the current code does the same. v2: Also drop the file argument, spotted by Ben Widawsky. Reviewed-by:
-
Daniel Vetter authored
It found some unused variables. Reviewed-by:
-
Daniel Vetter authored
This is our customary "no such object" errno, not -EINVAL. Reviewed-by:
-
Daniel Vetter authored
It doesn't hurt and it at least prevents us from OOPSing left and right at quite a few places. This also allows us to simplify the code a bit by folding the only line of context_open into the callsite. We obviuosly also need to run the cleanup code unconditionally, too. Reviewed-by:
-
Daniel Vetter authored
commit 8e96d9c4 Author: Ben Widawsky <ben@bwidawsk.net> Date: Mon Jun 4 14:42:56 2012 -0700 drm/i915: reset the GPU on context fini broke module unload because it reset the gpu before we've stopped touching it. Later on in the unload sequence the ringbuffer code complained that the gpu would idle properly (because intel_gpu_reset only resets the hw and not our sw state). v2: Reorder things so that we reset the gpu _before_ we release the backing storage of the default context. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51183Reviewed-by:
-
- 18 Jun, 2012 8 commits
-
-
Jesse Barnes authored
Prevents a possible hang: WaDisableL3Bank2xClockGate. v2: only apply to VLV, IVB doesn't need this anymore References: https://bugs.freedesktop.org/show_bug.cgi?id=50245Signed-off-by:
-
Jesse Barnes authored
Another required workaround for a potential hang: WaDisableTDLUnitClockGating. v2: only apply this to VLV, IVB doesn't need it anymore (Eugeni) References: https://bugs.freedesktop.org/show_bug.cgi?id=50245Signed-off-by:
-
Jesse Barnes authored
According to the bspec for MBCTL: Driver must set bit in the following scenarios: - to realod teh h/w boot context every time it gets loaded through OS - after an FLR clears the register (BIOS won't run afterwards) References: https://bugs.freedesktop.org/show_bug.cgi?id=50237Signed-off-by:
-
Jesse Barnes authored
The RCBP workaround still applies on these chips, and we need VDS as well. v2: remove MB boot fetch that snuck in (Daniel) add workaround tags to comments for easier internal tracking (Daniel) v3: only apply RCPB and VDS on SNB and VLV, IVB doesn't need them (Eugeni) References: https://bugs.freedesktop.org/show_bug.cgi?id=50251Signed-off-by: -
Daniel Vetter authored
I've added a bit of logic such that running the hangman test on chips without any hw reset support at all doesn't wedge the gpu because the reset failed. This relied on checking for non-null stop_rings. Unfortunately I've botched a rebase somewhere and stop_rings is still cleared at the old place before the reset code. Fix this up so that running the i-g-t tests on gen2/3 doesn't result in a wedged gpu. v2: Actually remove the lines instead of adding them twice ... my git license should be revoked immediately. Signed-Off-by: -
Ben Widawsky authored
I'm seeing about a 5% FPS improvement across various benchmarks on my IVB i3. Rumor has it that the higher end parts show even more benefit. This derives from a patch originally given to me by Bernard. The docs are confusing about the definition names (ie. medium really seems like max), but it would seem it gives more cache to the GT at the expense of uncore. This configuration makes the split most in favor of the GT. I've not tried the other IDICOS values. Cc: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Ben Widawsky authored
This got dropped as a result of the last round of comments. I didn't test it on unsupported HW (which this is likely the case). Note that this prevents hw context from blowing up on any pre-gen6 hw. Signed-off-by:
-
Eugeni Dodonov authored
Somehow this went unnoticed in the past reviews, but the condition would never timeout properly. This was initially introduced in the v2 of original SBI enabling patch. Highly embarrassing. Note that we now actually time out for the read, which resulted in gcc complaining that we can now return unitialized garbage if that happens. There's not much we can do here because there's not much point in thread -EIO all the way down through these functions. Hence simply shut up the compiler. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 16 Jun, 2012 1 commit
-
-
Daniel Vetter authored
VGA hotplug detection "works" by measuring the resistance across certain pins. A lot of kvm switches fumble this and wire up cheap resistors with the wrong resistance or don't bother at all. To accomodate these, also try to detect a connected monitor by trying to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother with an actual load-detection cycle when the output is life - that would be actual work to implement because things moved around. This is the big difference to Chris Wilson's original approach: commit 9e612a00 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin This blew up on Linus' machine because it errornously detected a vga screen (without and edid and hence only the default modes), leading to it's prompt removal: commit 8f53369b Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 8 14:53:06 2012 -0700 Revert "drm/i915/crt: Do not rely upon the HPD presence pin" Some digging around in Bspec shows the reason why load detect doesn't work on newer chips - the legacy VGA load detect bit isn't wired up any longer: Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4: "RGB Comparator / Sense. This bit is here for compatibility and will always return one. Monitor detection must be done be done through the programming of registers in the MMIO space. 0 = Below threshold 1 = Above threshold" v2: Add a comment in the code that load detect on hotplug capable machines is broken and pimp the commit message with a quote of Bspec to show why. Reported-and-tested-by:
Matthieu LAVIE <boiteamadmax@hotmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501Reviewed-by:
-
- 14 Jun, 2012 11 commits
-
-
Ben Widawsky authored
It's the only way we know how to make the GPU actually forget about the default context. Signed-off-by: -
Ben Widawsky authored
Use the rsvd1 field in execbuf2 to specify the context ID associated with the workload. This will allow the driver to do the proper context switch when/if needed. v2: Add checks for context switches on rings not supporting contexts. Before the code would silently ignore such requests. Signed-off-by: -
Ben Widawsky authored
Add the interfaces to allow user space to create and destroy contexts. Contexts are destroyed automatically if the file descriptor for the dri device is closed. Following convention as usual here causes checkpatch warnings. v2: with is_initialized, no longer need to init at create drop the context switch on create (daniel) v3: Use interruptible lock (Chris) return -ENODEV in !GEM case (Chris) Signed-off-by: -
Ben Widawsky authored
To keep things as sane as possible, switch to the default context before idling. This should help free context objects, as well as put things in a more well defined state before suspending. v2: remove seqno from context switch call (daniel) return error on failed context switch instead of WARN+continue (daniel) v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris) Signed-off-by: -
Ben Widawsky authored
Signed-off-by: -
Ben Widawsky authored
With the code to do HW context switches in place have the driver load the default context for the render ring when the driver loads. The default context will be an ever present context that is available to switch to at any time for the given ring. Signed-off-by: -
Ben Widawsky authored
From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf [DevSNB] If Flush TLB invalidation Mode is enabled it's the driver's responsibility to invalidate the TLBs at least once after the previous context switch after any GTT mappings changed (including new GTT entries). This can be done by a pipelined PIPE_CONTROL with TLB inv bit set immediately before MI_SET_CONTEXT. On GEN7 the invalidation mode is explicitly set, but this appears to be lacking for GEN6. Since I don't know the history on this, I've decided to dynamically read the value at ring init time, and use that value throughout. v2: better comment (daniel) Signed-off-by:
-
Ben Widawsky authored
This has showed up in several other patches. It's required for the next context workaround. I tested this one on its own and saw no differences in basic tests (performance or otherwise). This patch is relatively likely to cause regressions, hence why it's split out. Signed-off-by: -
Ben Widawsky authored
The workaround itself applies to gen7 only (according to the docs) and as Eric Anholt points out shouldn't be required since we don't use HW scheduling features, and therefore arbitration. Though since it is a small, and simple addition, and we don't really understand the issue, just do it. FWIW, I eventually want to play with some of the arbitration stuff, and I'd hate to forget about this. Signed-off-by: -
Daniel Vetter authored
This way round we don't introduce and ugly layering violations and use the interface as I planned to use it. Signed-Off-by: -
Ben Widawsky authored
Implement the context switch code as well as the interfaces to do the context switch. This patch also doesn't match 1:1 with the RFC patches. The main difference is that from Daniel's responses the last context object is now stored instead of the last context. This aids in allows us to free the context data structure, and context object independently. There is room for optimization: this code will pin the context object until the next context is active. The optimal way to do it is to actually pin the object, move it to the active list, do the context switch, and then unpin it. This allows the eviction code to actually evict the context object if needed. The context switch code is missing workarounds, they will be implemented in future patches. v2: actually do obj->dirty=1 in switch (daniel) Modified comment around above Remove flags to context switch (daniel) Move mi_set_context code to i915_gem_context.c (daniel) Remove seqno , use lazy request instead (daniel) v3: use i915_gem_request_next_seqno instead of outstanding_lazy_request (Daniel) remove id's from trace events (Daniel) Put the context BO in the instruction domain (Daniel) Don't unref the BO is context switch fails (Chris) Signed-off-by:
-
