- 14 May, 2011 3 commits
-
-
Jesse Barnes authored
This makes the Ironlake+ code trivial and generally simplifies things. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Jesse Barnes authored
Set the IRQ handling functions in driver load so they'll just be used directly, rather than branching over most of the code in the chipset functions. Signed-off-by:
-
Jesse Barnes authored
Rather than branching in ironlake_pch_enable, add a new train_fdi function to the display function pointer struct and use it instead. Signed-off-by:
-
- 13 May, 2011 1 commit
-
-
Ben Widawsky authored
Forcewake needs to register itself with drm to use the remove function. The file also should be read only. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 11 May, 2011 1 commit
-
-
Keith Packard authored
Signed-off-by:
-
- 10 May, 2011 31 commits
-
-
Ben Widawsky authored
forcewake is controlled by the open and close of the debugfs file. This assures that buggy applications cannot cause the GT to stay on forever. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
The render P-state handling code requires reading from a GT register. This means that FORCEWAKE must be written to, a resource which is shared and should be protected by struct_mutex. Hence we can not manipulate that register from within the interrupt handling and so must delegate the task to a workqueue. Signed-off-by:
-
Ben Widawsky authored
Found by the new strict checking for the mutex being held whilst manipulating the forcewake status. Signed-off-by:
-
Ben Widawsky authored
Provide a reference count to track the forcewake state of the GPU and give a safe mechanism for userspace to wake the GT. This also potentially saves a UC read if the GT is known to be awake already. The reference count is atomic, but the register access and hardware wake sequence is protected by struct_mutex. Signed-off-by:
-
Ben Widawsky authored
Moved the macros around to properly do reads and writes for the given GPU. This is to address special requirements for gen6 (SNB) reads and writes. Registers in the range 0-0x40000 on gen6 platforms require special handling. Instead of relying on the callers to pick the registers correctly, move the logic into the read and write functions. Signed-off-by:
-
Chris Wilson authored
If the outputs are active and continuing to access the GATT when we teardown the PTEs, then there is a potential for us to hang the GPU. The hang tends to be a PGTBL_ER with either an invalid host access or an invalid display plane fetch. v2: Reorder IRQ initialisation to defer until after GEM is setup. Reported-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
Rick Bramley <richard.bramley@hp.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35635Reported-and-tested-by:
Zdenek Kabelac <zdenek.kabelac@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36048Reviewed-by:
-
Chris Wilson authored
Rely on the GPU snooping into the CPU cache for appropriately bound objects on MI_FLUSH. Or perhaps one day we will have a cache-coherent CPU/GPU package... Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
... to clarify just how we use it inside the driver and remove the confusion of the poorly matching agp_type names. We still need to translate through agp_type for interface into the fake AGP driver. Signed-off-by:
-
Ben Widawsky authored
Currently this is only useful for the rc6 stuff. But this would also be useful when I finally get around to the logical context + ppgtt stuff. Signed-off-by:
-
Jesse Barnes authored
For debug & testing. Signed-off-by:
-
Ben Widawsky authored
There is a race condition between setting PWRCTXA and executing MI_SET_CONTEXT. PWRCTXA must not be set until a valid context has been written (or else the GPU could possible go into rc6, and return to an invalid context). Reported-and-Tested-by:
Gu Rui <chaos.proton@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582Signed-off-by:
-
Ben Widawsky authored
Added a new function which waits for the ringbuffer space to be equal to (total - 8). This is the empty condition of the ringbuffer, and equivalent to head==tail. Also modified two users of this functionality elsewhere in the code. Signed-off-by:
-
Ben Widawsky authored
In the failure cases during rc6 initialization, both the power context and render context may get !refcount without holding struct_mutex. However, on rc6 disabling, the lock is held by the caller. Rearranged the locking so that it's safe in both cases. Signed-off-by:
-
Eric Anholt authored
They're used in one place, and not providing any descriptive value, with their names just being approximately the conjunction of the struct name and the struct field. This diff was produced with gcc -E, copying the new struct definitions out, moving a couple of the old comments into place in the new structs, and reindenting. Signed-off-by:
-
Eric Anholt authored
We used to have these from the product of (pch, non-pch) * (pipe a, pipe b). Now we can just use the nice per-pipe reg macros in the split out crtc_mode_sets. Signed-off-by:
-
Eric Anholt authored
Signed-off-by:
-
Eric Anholt authored
Ironlake is where the PCH split started. Signed-off-by:
-
Eric Anholt authored
Signed-off-by:
-
Eric Anholt authored
While g4x had DP, eDP came with Ironlake, so we don't need that code here. Signed-off-by:
-
Eric Anholt authored
Signed-off-by:
-
Eric Anholt authored
Signed-off-by:
-
Eric Anholt authored
This path, which shouldn't be *that* complicated, is now so littered with per-chipset tweaks that it's hard to trace the order of what happens. HAS_PCH_SPLIT() is the most radical change across chipsets, so it seems like a natural split to simplify the code. This first commit just copies the existing code without changing anything. v2: updated to track removal of call to intel_enable_plane from i9xx_crtc_mode_set Signed-off-by:
-
Chris Wilson authored
We need to ensure that we feed valid memory into the display plane attached to the pipe when switching the pipe on. Otherwise, the display engine may read through an invalid PTE and so throw an PGTBL_ER exception. As we need to perform load detection before even the first object is allocated for the fbdev, there is no pre-existing object large enough for us to borrow to use as the framebuffer. So we need to create one and cleanup afterwards. At other times, the current fbcon may be large enough for us to borrow it for duration of load detection. Found by assert_fb_bound_for_plane(). Reported-by:
Knut Petersen <Knut_Petersen@t-online.de> References: https://bugs.freedesktop.org/show_bug.cgi?id=36246Signed-off-by:
-
Chris Wilson authored
As we now never attempt to steal a crtc for load detection, we either set a mode on a new pipe, or change the dpms mode on an existing pipe. Never both, so we can simplify the code slightly. Signed-off-by:
-
Chris Wilson authored
As we only allow the use of a disabled CRTC, we don't need to handle the case where we are reusing an already enabled pipe. Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
... and the no longer relevant comment. The code ceased stealing a pipe for load detection a long time ago. Signed-off-by:
-
Chris Wilson authored
Keep all the state required for undoing and restoring the previous pipe configuration together in a single struct passed from intel_get_load_detect_pipe() to intel_release_load_detect_pipe() rather than stuffing them inside the common encoder structure. Signed-off-by:
-
Chris Wilson authored
Check the return value from drm_crtc_set_mode(), report the failure via a debug message and propagate the error back to the caller. This prevents us from blissfully continuing to do the load detection on a disabled pipe. Fortunately actual failure for modesetting is very rare, and reported failures even rarer. Signed-off-by:
-
Chris Wilson authored
... and so remove the confusion as to whether to use the returned crtc or intel_encoder->base.crtc with the subsequent load-detection. Even though they were the same, the two instances of load-detection code disagreed over which was the more correct. Signed-off-by:
-
Chris Wilson authored
Required so that we don't obliterate the queue if initialising the rings after the global IRQ handler is installed. [Jesse, you recently looked at refactoring the IRQ installation routines, does moving the initialisation of ring buffer data structures away from that routine make sense in your grand scheme?] Signed-off-by:
-
- 09 May, 2011 3 commits
-
-
Alex Williamson authored
If we're using vga switcheroo, the device may be turned off and poking it can return random state. This provokes an OOPS fixed separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a DP before it is attached). Trying to use and respond to events on a device that has been turned off by the user is in principle a silly thing to do. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Chris Wilson authored
Despite the fixes in 548f245b (drm/i915: fix per-pipe reads after "cleanup"), we missed one neighbouring read that was mistakenly replaced with the reg value in 9db4a9c7 (drm/i915: cleanup per-pipe reg usage). This was preventing us from correctly determining the mode the BIOS left the panel in for machines that neither have an OpRegion nor access to the VBT, (e.g. the EeePC 700). Signed-off-by:
-
Chris Wilson authored
When enabling the plane, it is helpful to have already pointed that plane to valid memory or else we may incur the wrath of a PGTBL_ER. This code preserved the behaviour from the bad old days for unknown reasons... Found by assert_fb_bound_for_plane(). References: https://bugs.freedesktop.org/show_bug.cgi?id=36246Signed-off-by:
-
- 04 May, 2011 1 commit
-
-
Chris Wilson authored
Given that the hardware may be left in a random condition by the BIOS, it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit without us ever enabling/attaching the DP encoder to a pipe. Thus causing a NULL deference when we attempt to wait for a vblank on that crtc. Reported-and-tested-by:
Bryan Christ <bryan.christ@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314Signed-off-by:
Bo Wang <bo.b.wang@intel.com> Cc: stable@kernel.org Signed-off-by:
-
