- 22 Aug, 2013 17 commits
-
-
Ben Widawsky authored
VMAs can be created and not bound. One may think of it as lazy cleanup, and safely gloss over the conditions which manufacture it. In either case, when the object backing the i915 vma is destroyed, we must cleanup the vma without stumbling into a bunch of pitfalls that assume the vma is bound. NOTE: I was pretty certain the above condition could only happen when we introduced the use of VMAs being looked up at execbuf, and already existing. Paulo has hit this though, so I must be missing something. As I believe the patch is correct anyway, therefore I won't scratch my head too hard. v2: use goto destroy as a compromise (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Use the standard inversely ordered goto label stack for everything. Spotted while reviewing place where we might need to to call vma_destroy but failed to do so. Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: -
Ben Widawsky authored
Ideally we could use for_each_ring with the ring flags as I've done a couple times (http://lists.freedesktop.org/archives/intel-gfx/2013-June/029450.html). Until Daniel merges that patch though, we can just use this. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ben Widawsky authored
We require n-1 mailboxes for proper semaphore synchronization. All semaphore synchronization code relies on proper values in these mailboxes. The fact that we failed to touch the vebox ring by itself was unlikely to be an issue since the HW should be initializing the values to 0. However the error framework for testing seqno wrap introduced by Mika, in addition to the hangcheck via seqno, and i915_error_first_batchbuffer() combined caused a nice explosion. The problem is caused by seqno wrap because the wrap condition is not properly setup. The wrap code attempts to set the sync mailboxes all to 0, and then set the current seqno to one less than 0. In all cases, the vebox mailbox wasn't properly being initialized. This caused a wrap to not occur. When hangcheck kicks in with the bogus seqno values, the rest just doesn't work. It makes me wonder if we shouldn't consider a dumber version of hangcheck... How we messed this up: VECS support was written before the aforementioned other features. Upon VECS being rebased, these facts were missed. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198Signed-off-by:
-
Stéphane Marchesin authored
It's basically the same deal as the RC6+ issues on ivy bridge except this time with RC6 on sandy bridge. Like last time the core of the issue is that the timings don't work 100% with our voltage regulator. So from time to time, the kernel will print a warning message about the GPU not getting out of RC6. In particular, I found this fairly easy to reproduce during suspend/resume. Changing the threshold to 125000 instead of 50000 seems to fix the issue. The previous patch used 150000 but as it turns out this doesn't work everywhere. After getting such a machine, I bisected the highest value which works, which is 125000, so here it is. I also measured the idle power usage before/after this patch and didn't see a difference on a sandy bridge laptop. On haswell and up, it makes a big difference, so we want to keep it at 50k there. It also seems like haswell doesn't have the RC6 issues that sandy bridge has so the 50k value is fine. Signed-off-by:
Stéphane Marchesin <marcheu@chromium.org> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Paulo Zanoni authored
The machines that fall in this category are the SDVs that have a PCI ID starting with 0x0C. These are very early pre-production machines and may not fully work. Other Haswell SDVs have PCI IDs that match the real Haswell machines and we expect them to work better. Even though they have problems, they still mostly work so I don't see a reason to refuse loading our driver. But I do see a reason to reject bug reports from these machines, so the message should help the bug triagers. As far as I know, we don't implement some workarounds that are specific to these machines and suspend/resume may not work on most of them, but besides this, they may work. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Chris Wilson authored
After computing the stage changes for the set_config, record those in the debug log. Signed-off-by:
-
Paulo Zanoni authored
Caught by "make W=1 drivers/gpu/drm/i915/". Signed-off-by:
-
Chris Wilson authored
This is primarily for the benefit of the create2 ioctl so that the caller can avoid the later step of rebinding the bo with new PTE bits. After introducing WT (and possibly GFDT) cacheing for display targets, not everything in the display is earmarked as UC, and more importantly what is is controlled by the kernel. Note that set_cache_level/get_cache_level for DISPLAY is not necessarily idempotent; get_cache_level may return UC for architectures that have no special cache domain for the display engine. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Haswell GT3e has the unique feature of supporting Write-Through cacheing of objects within the eLLC/LLC. The purpose of this is to enable the display plane to remain coherent whilst objects lie resident in the eLLC/LLC - so that we, in theory, get the best of both worlds, perfect display and fast access. However, we still need to be careful as the CPU does not see the WT when accessing the cache. In particular, this means that we need to flush the cache lines after writing to an object through the CPU, and on transitioning from a cached state to WT. v2: Actually do the clflush on transition to WT, nagging by Ville. v3: Flush the CPU cache after writes into WT objects. v4: Rease onto LLC updates and report WT as "uncached" for get_cache_level_ioctl to remain symmetric with set_cache_level_ioctl. Signed-off-by:
-
Jani Nikula authored
Although I could not reproduce this (different compiler version, perhaps), reportedly we get: drivers/gpu/drm/i915/i915_irq.c:1943:27: warning: ‘score’ may be used uninitialized in this function [-Wuninitialized] Drop the 'score' variable altogether as it's not really needed. Reported-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jani Nikula authored
The short lowercase names are bound to collide. The default warnings don't even warn about shadowing. Signed-off-by:
-
Jani Nikula authored
It's been there since i8xx_irq_handler() was added in commit c2798b19 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Apr 22 21:13:57 2012 +0100 drm/i915: i8xx interrupt handler Signed-off-by:
-
Guillaume Clement authored
Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off. This could also happen to i915. Signed-off-by:
Guillaume Clement <gclement@baobob.org> Signed-off-by:
-
Ben Widawsky authored
I just noticed in our code we don't really check the assertion, and given some of the code I am changing in this area, I feel a WARN is very nice to have. Signed-off-by:
-
Daniel Vetter authored
Resolve the catch-22 of igt needing a stable number and patches first needing testcases by reserving the interface number up-front. v2: Improve the spelling a bit. v3: More spelling fail spotted by Chris. Requested-by:
-
Chris Wilson authored
Now that we skip clflushes more often, return a boolean indicating whether the clflush was actually performed, and only if it was do the chipset flush. (Though on most of the architectures where the clflush will be skipped, the chipset flush is a no-op!) Signed-off-by:
-
- 10 Aug, 2013 4 commits
-
-
Chris Wilson authored
As a corollary to reviewing the interaction between LLC and our cache domains, the GPU PTE bits are independent of the CPU PAT bits. As such we can set the cache level on stolen memory based on how we wish the GPU to cache accesses to it. So we are free to set the same default cache levels as for normal bo, i.e. enable LLC cacheing by default where appropriate. Signed-off-by:
-
Chris Wilson authored
As mentioned in the previous commit, reads and writes from both the CPU and GPU go through the LLC. This gives us coherency between the CPU and GPU irrespective of the attribute settings either device sets. We can use to avoid having to clflush even uncached memory. Except for the scanout. The scanout resides within another functional block that does not use the LLC but reads directly from main memory. So in order to maintain coherency with the scanout, writes to uncached memory must be flushed. In order to optimize writes elsewhere, we start tracking whether an framebuffer is attached to an object. v2: Use pin_display tracking rather than fb_count (to ensure we flush cursors as well etc) and only force the clflush along explicit writes to the scanout paths (i.e. pin_to_display_plane and pwrite into scanout). v3: Force the flush after hitting the slowpath in pwrite, as after dropping the lock the object's cache domain may be invalidated. (Ville) Based on a patch by Ville Syrjälä. Signed-off-by:
-
Chris Wilson authored
The display engine has unique coherency rules such that it requires special handling to ensure that all writes to cursors, scanouts and sprites are clflushed. This patch introduces the infrastructure to simply track when an object is being accessed by the display engine. v2: Explain the is_pin_display() magic as the sources for obj->pin_count and their individual rules is not obvious. (Ville) Signed-off-by:
-
Chris Wilson authored
The LLC is a fun device. The cache is a distinct functional block within the SA that arbitrates access from both the CPU and GPU cores. As such all writes to memory land first in the LLC before further action is taken. For example, an uncached write from either the CPU or GPU will then proceed to memory and evict the cacheline from the LLC. This means that a read from the LLC always returns the correct information even if the PTE bit in the GPU differs from the PAT bit in the CPU. For the older snooping architecture on non-LLC, the fundamental principle still holds except that some coordination is required between the CPU and GPU to explicitly perform the snooping (which is handled by our request tracking). The upshot of this is that we know that we can issue a read from either LLC devices or snoopable memory and trust the contents of the cache - i.e. we can forgo a clflush before a read in these circumstances. Writing to memory from the CPU is a little more tricky as we have to consider that the scanout does not read from the CPU cache at all, but from main memory. So we have to currently treat all requests to write to uncached memory as having to be flushed to main memory for coherency with all consumers. Signed-off-by:
-
- 09 Aug, 2013 11 commits
-
-
Ville Syrjälä authored
Due to a misplaced memset(), we never actually enabled the FBC WM on HSW. Move the memset() to happen a bit earlier, so that it won't clobber results->enable_fbc_wm. Signed-off-by:
-
Jesse Barnes authored
Ryan noticed that on his board, HDMI was wired up to port C but not exposed by the kernel, which had only expected DP on that port. Fix that up by enumerating both ports if possible. Tested-by:
"Matsumura, Ryan" <ryan.matsumura@intel.com> Acked-by:
-
Dan Carpenter authored
The '!' here was not intended. Since '!' has higher precedence than compare, it means the check is never true. This regression was introduced in commit 71fff20f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Aug 6 22:24:03 2013 +0300 drm/i915: Kill fbc_enable from hsw_lp_wm_results Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dan Carpenter authored
There is an extra semi-colon here so we just leak and never unbind anything. This regression has been introduced in commit 07fe0b12 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:10 2013 -0700 drm/i915: plumb VM into bind/unbind code Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Caught by the dead code police! Signed-off-by:
-
Damien Lespiau authored
And also fix a small typo in the intel_encoder_dpms() comment. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Did you say OCD? Signed-off-by:
-
Damien Lespiau authored
This code was dead since: commit 432e58ed Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 25 19:32:06 2010 +0000 drm/i915: Avoid allocation for execbuffer object list so just put it to rest for good. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
- 08 Aug, 2013 8 commits
-
-
Chris Wilson authored
I was curious as to what objects were currently allocated from stolen memory, and so exported it from debugfs. Signed-off-by:
-
Ville Syrjälä authored
ILK and VLV codepaths didn't update sprite watermarks when disabling a sprite. Make them do that. Signed-off-by:
-
Ville Syrjälä authored
We're going to want to know the crtc in the watermark code to avoid doing more work than we have to. We should also pass the plane we're disabling so that we know where to stick our watermark parameters without having to go look the plane up. Signed-off-by:
-
Ville Syrjälä authored
Check plane->fb in intel_disable_plane() to determine if the plane is already disabled. If the plane has an fb, then it must also have a crtc, so we can drop the plane->crtc check and just call intel_enable_primary() directly. v2: WARN and bail if the plane doesn't have a crtc when it should Signed-off-by:
-
Ville Syrjälä authored
We're going to want to know which CRTC we're dealing with, so pass it down to the update/disable_plane hooks. Signed-off-by:
-
Ville Syrjälä authored
Give a name to the plane watermark related data we have currently stored under intel_plane->wm. We also observe that this data is more or less the same that we have in the hsw_pipe_wm_parameters structure, so use it there as well. v2: Make pahole happier Reviewed-by:
-
Ville Syrjälä authored
There is a bunch of global state that needs to be considered when checking watermarks for validity. Move most of that to a new structure intel_wm_config, to avoid having to pass around so many variables. One notable thing left out is the DDB partitioning information, since we often anyway need to check the same watermarks against both 1/2 and 5/6 DDB partitioning layouts. v2: s/pipes_active/num_pipes_active Reviewed-by:
-
Ville Syrjälä authored
There are quite a few variables we need to take into account to determine the maximum watermark levels, so it feels a bit cleaner to calculate those rather than just have a bunch of what look like magic numbers. v2: s/pipes_active/num_pipes_active s/othwewise/otherwise Reviewed-by:
-
