- 05 Mar, 2014 40 commits
-
-
Daniel Vetter authored
... it's this time of the year again. Originally we've frobbed this to fix up some regressions, but maybe our DP code improved sufficiently now that we can dare to do again what the spec recommends. This reverts commit 2514bc51 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs I'm pretty sure I'll regret this patch, but otoh I expect we won't make progress here without poking the devil occasionally. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694 Cc: peter@colberg.org Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
Itai BEN YAACOV <candeb@free.fr> Tested-by:
David En <d.engraf@arcor.de> Reported-and-Tested-by:
Marcus Bergner <marcusbergner@gmail.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Mika Kuoppala authored
As we now have intel_uncore_forcewake_reset() no need to do explicit put after reset. v2: rebase Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Damien Lespiau authored
While reading some code, out of boredom, stumbled on a tiny tiny fix. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
That macro was only ever used to convert ring->private into a gem object (hence the forceful cast). ring->private doesn't even exist anymore as it was transmogrified by Chris in: commit 0d1aacac Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 26 20:58:11 2013 +0100 drm/i915: Embed the ring->private within the struct intel_ring_buffer Signed-off-by:
-
Damien Lespiau authored
Its last usage outside of i915_gem.c was removed in: commit 1f70999f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 27 22:43:07 2014 +0000 drm/i915: Prevent recursion by retiring requests when the ring is full Signed-off-by:
-
Patrik Jakobsson authored
This patch fixes the blank screen bug introduced in 3.14-rc1 on the MacBook Air 6,2. The comments state that we need to force edp vdd so lets put it back. The regression was introduced by the following commit: commit dff392db Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Damien Lespiau authored
In the future, we need to be able to specify per-pipe number of planes/sprites. Let's start today! Signed-off-by:
-
Damien Lespiau authored
This macro is similar to for_each_pipe() we already have. Convert the two call sites we have at the same time. Signed-off-by:
-
Damien Lespiau authored
Consistency throughout the code base is good and remove some room for mistakes (as explained in the "drm/i915: Use a pipe variable to cycle through the pipes" commit) So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe) when it's reasonable and practical to do so (eg. when there isn't another pipe variable already). Suggested-by:
-
Damien Lespiau authored
'i' is already defined in the function scope and used elsewhere. Let's use it instead. Signed-off-by:
-
Damien Lespiau authored
I recently fumbled a patch because I wrote twice num_sprites[i], and it was the right thing to do in only 50% of the cases. This patch ensures I need to write num_sprites[pipe], ie it should be self-documented that it's per-pipe number of sprites without having to look at what is 'i' this time around. It's all a lame excuse, but it does make it harder to redo the same mistake. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
According to BSpec we need to always set this magic bit in ring buffer mode. Signed-off-by:
-
Ville Syrjälä authored
If we need precisely N lanes to satisfy the FDI bandwidth requirement, the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP() to get a more accurate answer. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
On DDI there's no PLL as such to generate the pixel clock for VGA. Instead we derive the pixel clock from the FDI link frequency. So to make .compute_config match what .get_config does, we need to set the port_clock based on the FDI link frequency. Note that we don't even check the port_clock when selecting the PLL for VGA output. We just assume SPLL at 1.35GHz is what we want, and that does match with the asumption of FDI frequency of 2.7Ghz we have in intel_fdi_link_freq(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74955Signed-off-by:
-
Mika Kuoppala authored
as they don't exists. v2: rename gen6_*_mt_* to gen7_*_mt_* as they never get called with gen6 (Chris) Signed-off-by: -
Mika Kuoppala authored
When we get control from BIOS there might be mt forcewake bits already set. This causes us to do double mt get without proper clear/ack sequence. Fix this by clearing mt forcewake register on init, like we do with older gens. Signed-off-by:
-
Jani Nikula authored
BDW is no longer flagged as preliminary hw, but without i915.preliminary_hw_support module param set the logs are filled with WARNs about it. Just make semaphores off the BDW per-chip default for now. CC: Ben Widawsky <ben@bwidawsk.net> Reported-by:
Sebastien Dufour <sebastien.dufour@intel.com> Signed-off-by:
-
Kenneth Graunke authored
Ben and I believe this will be necessary on production hardware. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> [danvet: Shuffle lines to group all ROW_CHICKEN writes and add a cautious comment that this might not be needed on production hw.] Reviewed-by:
-
Kenneth Graunke authored
I believe this will be necessary on production hardware. Signed-off-by:
-
Mika Kuoppala authored
For example if we get bug reports with similar error states and suspend count is always 1, that might lead the Sherlocks to right general direction. Suggested-by:
-
Mika Kuoppala authored
By default we keep only the error state from first hang. However some sneaky user might have cleared the first error state and we assume mistakenly that it is from first hang. As sometimes this matters, it is better to explicitly store the reset count. Signed-off-by:
-
Mika Kuoppala authored
We capture error state not only when the GPU hangs but also on other situations as in interrupt errors and in situations where we can kick things forward without GPU reset. There will be log entry on most of these cases. But as error state capture might be only thing we have, if dmesg was not captured. Or as in GEN4 case, interrupt error can trigger error state capture without log entry, the exact reason why capture was made is hard to decipher. v2: Split out the the error code stuff to separate patch (Ben) References: https://bugs.freedesktop.org/show_bug.cgi?id=74193Signed-off-by:
-
Mika Kuoppala authored
commit 011cf577 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Tue Feb 4 12:18:55 2014 +0000 drm/i915: Generate a hang error code added error code debug into dmesg. Store this also with error state to make matching dmesg logs and error states easier. As we need to have full ring state for error code generation, do full capture always, print hang message into log and then decide if we need to keep the error state. Signed-off-by:
-
Chris Wilson authored
After finding the guilty batch and request, we can use it to find the process that submitted the batch and then add the culprit into the error state. This is a slightly different approach from Ben's in that instead of adding the extra information into the struct i915_hw_context, we use the information already captured in struct drm_file which is then referenced from the request. v2: Also capture the workaround buffer for gen2, so that we can compare its contents against the intended batch for the active request. v3: Rebase (Mika) v4: Check for null context (Chris) checkpatch warnings fixed Link: http://lists.freedesktop.org/archives/intel-gfx/2013-August/032280.html Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v4) Acked-by: -
Chris Wilson authored
In the past, it was possible to have multiple batches per request due to a stray signal or ENOMEM. As a result we had to scan each active object (filtered by those having the COMMAND domain) for the one that contained the ACTHD pointer. This was then made more complicated by the introduction of ppgtt, whereby ACTHD then pointed into the address space of the context and so also needed to be taken into account. This is a fairly robust approach (though the implementation is a little fragile and depends upon the per-generation setup, registers and parameters). However, due to the requirements for hangstats, we needed a robust method for associating batches with a particular request and having that we can rely upon it for finding the associated batch object for error capture. If the batch buffer tracking is not robust enough, that should become apparent quite quickly through an erroneous error capture. That should also help to make sure that the runtime reporting to userspace is robust. It also means that we then report the oldest incomplete batch on each ring, which can be useful for determining the state of userspace at the time of a hang. v2: Use i915_gem_find_active_request (Mika) v3: remove check for ring->get_seqno, split long lines (Ben) v4: check that context is available (Chris) checkpatch warnings fixed Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3) Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v3) Signed-off-by: -
Chris Wilson authored
In place of true activity counting, we walk the list of vma associated with an object managing each on the vm's active/inactive list everytime we call move-to-inactive. This depends upon the vma->mm_list being cleared after unbinding, or else we run into difficulty when tracking the object in multiple vm's - we see a use-after free and corruption of the mm_list. Signed-off-by:
-
Ville Syrjälä authored
It occured to me that when we're trying to wake up both render and media wells on VLV, we might end up calling the low level force_wake_get/put two times even though one call would be enough. Make that happen by figuring out which wells really need to be woken up based on the forcewake counts. Signed-off-by:
Deepak S <deepak.s@intel.com> Signed-off-by:
-
Ville Syrjälä authored
VLV is the only platform where we increment/decrement the forcewake count around register access. Drop the inc/dec on VLV to make the forcewake code a bit more unified. The inc/dec are not necessary since we hold the uncore lock around the whole operation. Signed-off-by:
-
Ville Syrjälä authored
Use the render/media specific forcewake counts to properly restore the forcewake status after a GPU reset on VLV. Signed-off-by:
-
Chris Wilson authored
After a hang and failed reset, we cannot use the GPU to execute the page flip instructions. Instead we can force a synchronous mmio flip. (Later, we can reduce the synchronicity of the mmio flip by moving some of the delays off to a worker, like the current page flip code; see vblank tasks.) References: https://bugs.freedesktop.org/show_bug.cgi?id=72631Signed-off-by:
-
Paulo Zanoni authored
I could swear this was already happening in the current code... Also, put the reads and writes in a generic place, so we don't forget it again when we add runtime PM support to new platforms. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Just to be sure... Signed-off-by:
-
Paulo Zanoni authored
Because we shouldn't be runtime suspended when forcewake is supposed to be enabled. Signed-off-by:
-
Paulo Zanoni authored
Since the addition of dev_priv->mm.busy, there's no more need for dev_priv->pc8.gpu_idle, so kill it. Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and hsw_disable_package_c8, so just use them. Also, when we boot the machine, dev_priv->mm.busy initially considers the machine as idle. This is opposed to dev_priv->pc8.gpu_idle, which considered it busy. So dev_priv->pc8.disable_count has to be initalized to 1 now. Signed-off-by:
-
Paulo Zanoni authored
These are places where we read (not write) registers while we're runtime suspended. Signed-off-by:
-
Paulo Zanoni authored
Otherwise we'll read registers that return 0xffffffff, trigger some WARNs, think CRT is actually connected (because certain bits are 1), and fail the drm-resources-equal testcase! Tested on a SNB machine with runtime PM support (which is not upstream yet, but is already on my public tree at freedesktop.org, and will hopefully eventually become upstream). Testcase: igt/pm_pc8/drm-resources-equal Signed-off-by:
-
Paulo Zanoni authored
When we call gen6_gt_force_wake_put we don't actually put force_wake, we just schedule gen6_force_wake_work through mod_delayed_work, and that will eventually release force_wake. The problem is that we call intel_runtime_pm_put directly at gen6_gt_force_wake_put, so most of the times we put our runtime PM reference before the delayed work happens, so we may runtime suspend while force_wake is still supposed to be enabled if the graphics autosuspend_delay_ms is too small. Now the nice thing about the current code is that after it triggers the delayed work function it gets a refcount, and it only triggers the delayed work function if refcount is zero. This guarantees that when we schedule the funciton, it will run before we try to schedule it again, which simplifies the problem and allows for the current solution to work properly (hopefully!). v2: - Keep the VLV refcounts balanced (Jesse) Signed-off-by:
-
Paulo Zanoni authored
Because intel_mark_idle still touches some registers: it needs the machine to be awake. If you set both the autosuspend and PC8 delays to zero, you can get a "Device suspended" WARN when gen6_rps_idle touches registers. This is not easy to reproduce, but happens once in a while when running pm_pc8. Testcase: igt/pm_pc8 Signed-off-by:
-
