- 07 Mar, 2014 10 commits
-
-
Imre Deak authored
Since the encoder is tied to its port, we need to make sure the power domain for that port is on before reading out the encoder HW state. Note that this also covers also all connector get_hw_state handlers, since all those just call the corresponding encoder get_hw_state handler, which checks - after this change - for all power domains the connector needs. v2: - no change v3: - push down the power domain checks into the specific encoder get_hw_state handlers (Daniel) Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
The connector detect and get_mode handlers need to access the port specific HW blocks to read the EDID etc. Get/put the port power domains around these handlers. v2: - get port power domain for HDMI too (Ville) - get port power domain for the DP,HDMI audio detect handlers (Jesse) - Leave the intel_runtime_pm_get/put in the DP detect function in place. Instead of just removing them, these should be moved to the appropriate power_well enable/disable handlers. We can do this after Paulo's 'Merge PC8 with runtime PM, v2' patchset. v3: - rebased on latest -nightly Signed-off-by:
-
Imre Deak authored
Parts that poke port specific HW blocks like the encoder HW state readout or connector hotplug detect code need a way to check whether required power domains are on or enable/disable these. For this purpose add a set of power domains that refer to the port HW blocks. Get the proper port power domains during modeset. For now when requesting the power domain for a DDI port get it for a 4 lane configuration. This can be optimized later to request only the 2 lane power domain, when proper support is added on the VLV PHY side for this. Atm, the PHY setup code assumes a 4 lane config in all cases. Signed-off-by:
-
Imre Deak authored
Reading code free of special cases wins over the small overhead of calling a noop handler. Suggested by Jesse. Signed-off-by:
-
Imre Deak authored
Split the 'set' power well handler into an 'enable', 'disable' and 'sync_hw' handler. This maps more conveniently to higher level operations, for example it allows us to push the hsw package c8 handling into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS hand-over setting into the hsw/bdw sync_hw handler. No functional change. Signed-off-by:
-
Imre Deak authored
Whenever we request a power domain it has to guarantee that all HW resources are enabled that are needed to access a HW register associated with that power domain. In case a register is on an always-on power well this won't result in turning on a power well, but it may require enabling some other HW resource. One such resource is the HSW/BDW device D0 state that is required for all register accesses and thus for all power wells/power domains. So far the init power domain (guaranteeing access to all HW registers) was part of the default i9xx always-on power well, but not the HSW/BDW always-on power wells. Add the domain to the latter power wells too. Atm, all the always-on power wells have noop handlers, so this doesn't change the functionality. v2: - clarify semantics of always-on power wells (Paulo) Signed-off-by:
-
Imre Deak authored
These macros are used only locally, so move them to the .c file. No functional change. v2: - add init power domain to always-on power wells in the following - separate - patch (Paulo) Signed-off-by:
-
Daniel Vetter authored
There are too many oustanding issues: - Fence handling in the current code is broken. There's a patch series from me, but it's blocked on and extended review (which includes writing the testcases). - IOMMU mapping handling is broken, we need to properly refcount it - currently it gets destroyed when the first vma is unbound, so way too early. - There's a pending reset issue on snb. Since Mika's reset work and full ppgtt have been pulled in in separate branches and ended up intermittingly breaking each another it's unclear who's the exact culprit here. - We still have persistent evidince of crazy recursion bugs through vma_unbind and ppgtt_relase, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=73383 This issue (and a few others meanwhile resolved) have blocked our performance measuring/tuning group since 3 months. - Secure batch dispatching is broken. This is blocking Brad Volkin's command checker work since 3 months. All these issues are confirmed to only happen when full ppgtt is enabled, falling back to aliasing ppgtt resolves them. But even aliasing ppgtt itself still has a regression: - We currently unconditionally bind objects into the aliasing ppgtt, which means all priviledged objects like ringbuffers are visible to unpriviledged access again. On top of that this also breaks the command checker for aliasing ppgtt, since it can't hide the validated batch any more. Furthermore topic/full-ppgtt has never been reviewed: - Lifetime rules around vma unbinding/release are unclear, resulting into this awesome hack called ppgtt_release. Which seems to take the blame for most of the recursion fallout. - Context/ring init works different on gpu reset than anywhere else. Such differeneces have in the past always lead to really hard to track down bugs. - Aliasing ppgtt is treated in a bunch of places as a real address space, but it isn't - the real address space is always the global gtt in that case. This results in a bit a mess between contexts and ppgtt object, further complication the context/ppgtt/vma lifetime rules. - We don't have any docs describing the overall concepts introduced with full ppgtt. A short, concise overview describing vmas and some of the strange bits around them (like the unbound vmas used by execbuf, or the new binding rules) really is needed. Note that a lot of the post topic/full-ppgtt merge fallout has already been addressed, this entire list here of 10 issues really only contains the still outstanding issues. Finally the 3.15 merge window is approaching and I think we need to use the remaining time to ensure that our fallback option of using aliasing ppgtt is in solid shape. Hence I think it's time to throw the switch. While at it demote the helper from static inline status because really. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Imre Deak authored
These functions will be needed by the valleyview specific power well update functionality added in an upcoming patch, so move them earlier. No functional change. v2: - no change v3: - rebase on latest -nightly Signed-off-by:
-
Imre Deak authored
These functions are used only by a single call site and are simple enough to just fold them in. Note that in later patches the parts folded in here are further simplified as we'll remove hsw_{disable,enable}_package_c8 and the NULL check of the power well enable/disable handlers. All this means that at the end intel_display_power_get/put() becomes more understandable as we don't need to jump between two functions when reading the code. No functional change. v2: - clarify the rational for the change (Chris) Signed-off-by:
-
- 05 Mar, 2014 30 commits
-
-
Ville Syrjälä authored
We have two names for the same register CHICKEN_PIPESL_1 and HSW_PIPE_SLICE_CHICKEN_1. Unify it to just one. Also rename the FBCQ disable bit to resemble the name we've given to a similar bit on earlier platforms. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ville Syrjälä authored
gen7_enable_fbc() may write to some registers which we've already touched, so use RMW so that we don't undo any previous updates. Also note that we implemnt WaFbcAsynchFlipDisableFbcQueue:bdw. Signed-off-by:
-
Ville Syrjälä authored
Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1 registers with 0xffffffff. Move the parens to the correct place to avoid this. In particular this caused bit 30 of said registers to be set, which caused the sprite CSC to produce incorrect results. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220Signed-off-by:
-
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:
-
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 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ä 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:
-
