- 24 Aug, 2012 8 commits
-
-
Ben Widawsky authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 <chris@chris-wilson.co.uk> 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 19 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:
Dave Airlie <airlied@gmail.com> Signed-Off-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:
-
Xu, Anhua authored
Wrong order of parameters passed-in when calling hdmi/adpa /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed. This bug was indroduced by commit 1519b995 Author: Keith Packard <keithp@keithp.com> Date: Sat Aug 6 10:35:34 2011 -0700 drm/i915: Fix PCH port pipe select in CPT disable paths The reachable tag for this commit is v3.1-rc1-3-g1519b995Signed-off-by:
-
Daniel Vetter authored
Backmerge Linux 3.6-rc2 to resolve a few funny conflicts before we put even more madness on top: - drivers/gpu/drm/i915/i915_irq.c: Just a spurious WARN removed in -fixes, that has been changed in a variable-rename in -next, too. - drivers/gpu/drm/i915/intel_ringbuffer.c: -next remove scratch_addr (since all their users have been extracted in another fucntion), -fixes added another user for a hw workaroudn. Signed-off-by:
-
- 16 Aug, 2012 2 commits
-
-
Linus Torvalds authored
-
Ian Kent authored
Following a report of a crash during an automount expire I found that the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong. Not only is the locking wrong but the function is more complex than it needs to be. The function is meant to calculate (and dget) the next entry in the list of directories contained in the root of an autofs mount point (an autofs indirect mount to be precise). The main problem was that the d_lock of the owner of the list was not being taken when walking the list, which lead to list corruption under load. The only other lock that needs to be taken is against the next dentry candidate so it can be checked for usability. Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
