- 27 Aug, 2012 1 commit
-
-
Sedat Dilek authored
When I pulled-in today's drm-intel-next into linux-next (next-20120824) I saw this build-breakage: drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_object_get_pages_gtt': drivers/gpu/drm/i915/i915_gem.c:1778:40: error: '__GFP_NO_KSWAPD' undeclared (first use in this function) drivers/gpu/drm/i915/i915_gem.c:1778:40: note: each undeclared identifier is reported only once for each function it appears in This is caused by commit ba099ef165f8 ("mm: remove __GFP_NO_KSWAPD") and commit b6beae2c2014 ("mm: remove __GFP_NO_KSWAPD fixes") in linux-next (next-20120824). Fix this by removing __GFP_NO_KSWAPD from drm/i915 driver. Signed-off-by:Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 Aug, 2012 1 commit
-
-
Daniel Vetter authored
It blows up. And hopefully this is the root-cause of the mysterious rc6 related hang on ilk. For reference, the commit that enabled rc6 on ilk again is: commit 456470eb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 8 23:35:40 2012 +0200 drm/i915: enable rc6 on ilk again Reported-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
- 24 Aug, 2012 10 commits
-
-
Chris Wilson authored
If we need to stall in order to complete the pin_and_fence operation during execbuffer reservation, there is a high likelihood that the operation will be interrupted by a signal (thanks X!). In order to simplify the cleanup along that error path, the object was unconditionally unbound and the error propagated. However, being interrupted here is far more common than I would like and so we can strive to avoid the extra work by eliminating the forced unbind. v2: In discussion over the indecent colour of the new functions and unwind path, we realised that we can use the new unreserve function to clean up the code even further. Signed-off-by:
-
Ben Widawsky authored
Using the extracted INSTDONE reading, and our new register definitions, update our hangcheck detection and error collection to use it. This primarily means changing == to memcmp, and changing = to memcpy. Hopefully this will give more info on error dump, and provide more accurate hangcheck detection (both are actually TBD). Also, remove the reading of instdone1 from the ring error collection function, and just crap everything in capture_error_state (that could be split into a separate patch if it wasn't so trivial). v2: Now assuming i915_get_extra_instdone does the memset we can clean up the code a bit (Jani) v3: use ARRAY_SIZE as requested earlier by Jani (didn't change sizeof) Updated commit msg Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ben Widawsky authored
Signed-off-by:
-
Ben Widawsky authored
INSTDONE is used in many places, and it varies from generation to generation. This provides a good reason for us to extract the logic to read the relevant information. The patch has no functional change. It's prep for some new stuff. v2: move the memset inside of i915_get_extra_instdone (Jani) v3,4: bugs caught by (Jani) Reviewed-by:
-
Chris Wilson authored
The principal use for set-to-domain is for userspace to serialise operations with a particular buffer, for example to maintain coherency with a CPU map or to ratelimit its rendering by waiting on all previous operations before continuing. As such we tend to hold the struct_mutex for long periods during the synchronisation and so cause contention issues with other users of the graphics device, even for independent operations as memory management. An example is the contention between compiz and X which causes jitter in the display and a drop in peak throughput. The ultimate solution would be a set of fine grained locks and lockless operations, but an intermediate step is to first attempt the synchronisation for set-to-domain without holding the mutex. This introduces a number of race conditions, so we limit it use to the ioctl periphery where we have no dependent state and can safely complete with a locked synchronisation afterwards. Signed-off-by:
-
Chris Wilson authored
Move the wait-for-rendering logic around in the file so that we can group it together with the subsequent variations. The general goal is to have the lower level routines clustered together and then the higher level logic building upon those low level routines that came before. Signed-off-by:
-
Chris Wilson authored
This prevents the case of unbinding the object in order to process the relocations through the GTT and then rebinding it only to then proceed to use cpu relocations as the object is now in the CPU write domain. By choosing to use cpu relocations up front, we can therefore avoid the rebind penalty. Signed-off-by:
-
Chris Wilson authored
As we wish to create specialised object constructions in the near future that share the same basic GEM object struct, export the default initializer. Signed-off-by:
-
Chris Wilson authored
If the object has no backing shmemfs filp, then we obviously cannot perform a truncation operation upon it. Signed-off-by:
-
Chris Wilson authored
Avoid stalling and waiting for the GPU by checking to see if there is sufficient inactive space in the aperture for us to bind the buffer prior to writing through the GTT. If there is inadequate space we will have to stall waiting for the GPU, and incur overheads moving objects about. Instead, only incur the clflush overhead on the target object by writing through shmem. Signed-off-by:
-
- 23 Aug, 2012 1 commit
-
-
Tejun Heo authored
This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Signed-off-by:
Tejun Heo <tj@kernel.org> Reviewed-by:
-
- 22 Aug, 2012 3 commits
-
-
Ben Widawsky authored
ERR_INT on HSW will display unclaimed MMIO accesses. This can be either the result of a driver bug writing to an invalid addresses, or the result of RC6. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Antti Koskipaa <antti.koskipaa@linux.intel.com> Signed-off-by:
-
Ben Widawsky authored
ERR_INT can generate interrupts. However since most of the conditions seem quite fatal the patch opts to simply report it in error state instead of adding more complexity to the interrupt handler for little gain (the bits are sticky anyway). Signed-off-by:
-
Chris Wilson authored
This addresses WaPruneModeWithIncorrectHsyncOffset. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=50236Signed-off-by:
-
- 21 Aug, 2012 6 commits
-
-
Xu, Anhua authored
In intel_dp_mode_set we OR in the exact same bits twice at the same spot. Kill one of the redundant assignments. This little regression was introduced by: commit 417e822d Author: Keith Packard <keithp@keithp.com> Date: Tue Nov 1 19:54:11 2011 -0700 drm/i915: Treat PCH eDP like DP in most places PCH eDP has many of the same needs as regular PCH DP connections, including the DP_CTl bit settings, the TRANS_DP_CTL register. The reachable tag for this commit is: v3.1-5461-g417e822dSigned-off-by:
Anhua Xu <anhua.xu@intel.com> [danvet: Improved the commit message somewhat and ensured the diff is clearer.] Signed-off-by:
-
Chris Wilson authored
Given the persistence of an offset for the lifetime of an object, itis easy to contemplate how the mmap space becomes badly fragmented to the point that further allocations fail with ENOSPC. Our only recourse at this point is to try to purge the objects to release some space and reattempt the allocation. References: https://bugs.freedesktop.org/show_bug.cgi?id=39552Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
A pair of universally true checks that just need to be put in the right place depending on where in the patch sequence you go. Note that i915_gem_object_put_pages_gtt() already gains the BUG_ON(obj->gtt_space), but on reflection that needed to migrate to put_pages(). Signed-off-by: -
Chris Wilson authored
When dealing with a working set larger than the GATT, or even the mappable aperture when touching through the GTT, we end up with evicting objects only to rebind them at a new offset again later. Moving an object into and out of the GTT requires clflushing the pages, thus causing a double-clflush penalty for rebinding. To avoid having to clflush on rebinding, we can track the pages as they are evicted from the GTT and only relinquish those pages on memory pressure. As usual, if it were not for the handling of out-of-memory condition and having to manually shrink our own bo caches, it would be a net reduction of code. Alas. Note: The patch also contains a few changes to the last-hope evict_everything logic in i916_gem_execbuffer.c - we no longer try to only evict the purgeable stuff in a first try (since that's superflous and only helps in OOM corner-cases, not fragmented-gtt trashing situations). Also, the extraction of the get_pages retry loop from bind_to_gtt (and other callsites) to get_pages should imo have been a separate patch. v2: Ditch the newly added put_pages (for unbound objects only) in i915_gem_reset. A quick irc discussion hasn't revealed any important reason for this, so if we need this, I'd like to have a git blame'able explanation for it. v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed. Signed-off-by:
-
- 20 Aug, 2012 1 commit
-
-
Daniel Vetter authored
Prep work to make Chris Wilson's unbound tracking patch a bit easier to read. Alas, I'd have preferred that moving the page allocation retry loop from bind to get_pages would have been a separate patch, too. But that looks like real work ;-) Signed-off-by:
-
- 17 Aug, 2012 17 commits
-
-
Wang Xingchao authored
Added new haswell_write_eld() to initialize Haswell HDMI audio registers to generate an unsolicited response to the audio controller driver to indicate that the controller sequence should start. Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Wang Xingchao <xingchao.wang@intel.com> Signed-off-by:
-
Dave Airlie authored
We need to call these before we transfer the damaged areas to the device not before/after we setup the long lived vmaps. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
In order for udl vmap to work properly, we need to push the object into the CPU domain before we start copying the data to the USB device. This along with the udl change avoids userspace explicit mapping to be used. v2: add a flag for userspace to query to know if Intel kernel driver can deal with the vmap flushing properly. In theory udl would need a flag also, but I intend to push the patches very close to each other and other drivers should do the right thing from the start. I've added a test to my intel-gpu-tools prime branch, however testing this is a bit messy since the only way to get udl to vmap is to rendering something. I've tested this with real code as well to make sure it works. Signed-off-by:
-
Keith Packard authored
This is left over from the old PLL sharing code and isn't useful now that PLLs are shared when possible. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Damien Lespiau authored
New-ish devices have 3 pipes, so let's not just hardcode 2 but use the for_each_pipe() macro and make struct intel_display_error_state is big enough. V2: Also add the number of pipes emitted (Chris Wilson) Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Daniel Vetter authored
Yet again the too close relationship between the fb helper and the crtc helper code strikes. This time around the fb helper resets all encoder->crtc pointers to NULL before starting to set up it's own mode. Which is total bullocks, because this will clobber the existing output routing, which the new drm/i915 code depends upon to be absolutely correct. The crtc helper itself doesn't really care about that, since it disables unused encoders in a rather roundabout way anyway. Two places call drm_setup_crts: - For the initial fb config. I've auditted all current drivers, and they all allocate their encoders with kzalloc. So there's no need to clear encoder->crtc once more. - When processing hotplug events while showing the fb console. This one is a bit more tricky, but both the crtc helper code and the new drm/i915 modeset code disable encoders if their crtc is changed and that encoder isn't part of the new config. Also, both disable any disconnected outputs, too. Which only leaves encoders that are on, connected, but for some odd reason the fb helper code doesn't want to use. That would be a bug in the fb configuration selector, since it tries to light up as many outputs as possible. v2: Kill the now unused encoders variable. Acked-by:
-
Wang Xingchao authored
Use _PIPE macro to get correct register definition for IBX/CPT, discard old variable "i" way. Signed-off-by:
-
Wang Xingchao authored
HDMI audio related registers will be configured in write_eld callback. Signed-off-by:
-
Wang Xingchao authored
Add hsw audio registers definition Signed-off-by:
-
Daniel Vetter authored
Simply to make the ilk+ crtc disable path clearer and more symmetric with the enable function. Also switch to intel_crtc for the enable function. Reviewed-by:
-
Daniel Vetter authored
... and move a few others only used by i915_dma.c into the dri1 dungeon. Reviewed-by:
-
Daniel Vetter authored
All dvo drivers only support 2 dpms states, and our dvo driver even switches of the dvo port for anything else than DPMS_ON. Hence ditch this complexity and simply use bool enable. While reading through this code I've noticed that the mode_set function of ch7017 is a bit peculiar - it disable the lvds again, even though the crtc helper code should have done that ... This might be to work around an issue at driver load, we pretty much ignore the hw state when taking over. v2: Also do the conversion for the new ns2501 driver. Reviewed-by:
-
Daniel Vetter authored
Since it's redundant - we can get the attached encoder in the functions themselves. Reviewed-by:
-
Daniel Vetter authored
A few things need adjustement: - Change the dpms state by calling the dpms connector function and not some crtc helper internal callbacks. Otherwise this will break once we switch to our own dpms handling. - Instead of tracking and restoring intel_crtc->dpms_mode use the connector's dpms variable - the former relies on the dpms compuation rules used by the crtc helper. And it would break when the encoder is cloned and the other output has a different dpms state. But luckily no one is crazy enough for that. - Properly clear the connector -> encoder -> crtc linking, even when failing (note that the crtc helper removes the encoder -> crtc link in disabled_unused_functions for us). Reviewed-by:
-
Daniel Vetter authored
Now that all affected i830M systems have the pipe A quirk set, we don't need to do any special dances in the overlay code any longer. And reading through the code I'm rather dubios that it actually does what it claims to do ... As a nice benefit this rips out a users of the crtc helper dpms callback. v2: As suggested by Chris Wilson, replace the code by an appropriate WARN to ensure that the pipe A is indeed running. Reviewed-by:
-
Daniel Vetter authored
With the pipe A quirk properly fixed up for i830M, this shouldn't be required any longer. Reviewed-by:
-
Daniel Vetter authored
For some odd reason we've missed i830 and a i855 variant. Also kill the two now redundant i830 entries. v2: Don't add the missing 855 id to the pipe A quirk list, we seem to lack justification for it. Reviewed-by:
-
