- 19 Nov, 2014 3 commits
-
-
Tom O'Rourke authored
In sandybridge_pcode_read and sandybridge_pcode_write, extend the mbox parameter from u8 to u32. On Haswell and Sandybridge, bits 7:0 encode the mailbox command and bits 28:8 are used for address control for specific commands. Based on suggestion from Ville Syrjälä. Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
For whatever reasons this can happen. For real testcases the test will notice the -EIO and fall over, but we also have some testcases that just read all debugfs files. And that shouldn't cause dmesg spam. So tune it down a bit so that we still have the information for debugging. And change the errno so that real testcases can easily differentiate. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84890Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
With multiple rings, we may continue to render on the blitter whilst executing an infinite shader on the render ring. As we currently, rearm the timer with each execbuf, in this scenario the hangcheck will never fire and we will never detect the lockup on the render ring. Instead, only arm the timer once per hangcheck, so that hangcheck runs more frequently. v2: Rearrange code to avoid triggering a BUG_ON in add_timer from softirq context. Testcase: igt/gem_reset_stats/defer-hangcheck* Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86225Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 Nov, 2014 4 commits
-
-
Daniel Vetter authored
This goes back to commit 362b8af7 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Thu Jan 30 00:19:38 2014 -0800 drm/i915: Move per ring error state to ring_error Spotted while reading error states. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Jani Nikula authored
Indicate the monitor has been disconnected on disable. The regression has been introduced in commit 5fad84a7 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Nov 4 10:30:23 2014 +0200 drm/i915: rewrite hsw/bdw audio codec enable/disable sequences Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424 Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
The lack of a break here wasn't for falling through to some other important code, so made me do a double take. Add a break just to make things a little less confusing. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
kmap never fails. Spotted-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
- 17 Nov, 2014 17 commits
-
-
Matt Roper authored
When invalid cloning configurations were detected during modeset, we never copied the error code into the return value variable, leading us to return 0 (success) to userspace. This regression has been introduced in commit 50f52756 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 7 13:11:00 2014 -0800 drm/i915: use compute_config in set_config v4 Testcase: igt/kms_setmode Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86226Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
On SKL DPLL0 is used to derive CDCLK but can also be used to drive an eDP port (as long as we don't want SSC). DPLL0 is special enough to not be handled by the shared DPLL framework (drives CDCLK, not supposed to enable the HDMI mode), So we need to compute the configuration separately from the other DPLLs. Note that we don't need to reprogram DPLL0 (which would mean bringing down CDCLK) to support the various eDP 1.3 link rates as they all share the same VCO (8100). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Let's document PSR a bit. No functional changes. v2: Add actual DocBook entry and accept Daniel's improvements. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
No functional changes. Just cleaning and reorganizing it. v2: Rebase it puting it to begin of psr rework. This helps to blame easily at least latest changes. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
No functional change. Just making it public for use outside intel_dp.c Allowing split psr functions. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give 0x0 no matter what the state of the render and media wells. There was also some hint in the Gunit HAS that thread status not being needed on VLV, and hence dropped when bringing stuff over from the IVB design. Not really a definite comment about the specific register itself though. Also the w/a itself is no longer listed for VLV in the database. It was there some time ago in the past, but I guess someone figured out the mistake and dropped it. So let's just drop it from the code as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same meaning since SNB. So treating them as something special for HSW doesn't make sense to me. Also the bits *seem* to work exactly the same way on IVB, HSW GT2 and HSW GT3. At least intel_reg_read gives the identical results on all platforms with and without forcewake. Also the HSW PM guide rev 0.99 (ww05 2013) doesn't say anything about those bits. It just says to poll for bits [2:0]. As does the more recent BDW PM guide. So just drop the HSW special case and treat all platforms the same way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
When reading out a DDI config that uses a PLL that is not part of the shared_dpll scheme (DPLL0), it's totally normal to end up in the default: case of that switch. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
According to "Cherryview_GFXclocks_y14w36d1.xlsx" the GPU frequency divider should be 10 in when the CZ clock is 400 MHz. Change the code to agree so that we report the correct frequencies. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
The divider used in the GPU frequency calculations is compatible between vlv and chv. vlv just wants doubled values compared to chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Always print the final PCBR register value on both vlv and chv, and also tell us whether the BIOS was a good citizen or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Our freq<->opcode conversions assume that GPLL is always used. Apparently that should be the case always, but let's scream if we ever encounter something different. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Remove the magic number for the GPLLENABLE bit by adding a name for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Even with the rps debug messages signficantly recuced by commit 67956867 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 2 15:12:17 2014 +0300 drm/i915: Don't spam dmesg with rps messages on vlv/chv we still get an inordinate amount of spam from this. Just kill the debug print. If someone wants to observe it they can just use the tracepoint. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
On chv the pipe-a power well is the new disp2d well, and it kills pretty much everything in the display block. So we need to do the the same dance that vlv does wrt. display irqs and hpd when the power well goes up or down. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 Nov, 2014 16 commits
-
-
Ville Syrjälä authored
Replace the misinformed notes about CHV snoop behaviour with something that's hopefully closer to reality. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Throw away the hand rolled display irq setup code on chv, and instead just call vlv_display_irq_postinstall() and vlv_display_irq_uninstall(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Pull the vlv display irq uninstall code into a separate function, for eventual sharing with chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Running the driver without execlists and hence PPGTT (either aliasing or full) isn't a supported configuration on gen9+. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
intel_ddi.c:955:41: sparse: constant 8400000000 is so big it is long intel_ddi.c:955:53: sparse: constant 9000000000 is so big it is long intel_ddi.c:955:65: sparse: constant 9600000000 is so big it is long intel_ddi.c:1028:23: sparse: constant 9600000000 is so big it is long intel_ddi.c:1031:23: sparse: constant 9000000000 is so big it is long intel_ddi.c:1034:23: sparse: constant 8400000000 is so big it is long Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Given the history, there's some chance we'll keep the same WM code for a bit (previously, we were able to reuse the same WM code from ILK to BDW, so that sounds like a fair assumption). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Tvrtko Ursulin authored
Write and reads following the block changed use engine specific use counters and unless that is matched here force wake use counting goes bad. Same force wake is attempted to be taken twice which leads to at least time outs. NOTE: Depending on feedback from hardware designers it may not be necessary to grab force wakes on Gen9 here. But for Gen8 it is needed due to a race between RC6 and ELSP writes. v2: Added blitter force wake engine and made more future proof. Added commit note. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Ville found out that the DATA1 register exists since SNB with some scarce apparitions in the specs throughout the times. In his own words: Also according to Bspec the mailbox data1 register already existed since snb. The hsw cdclk change sequence also mentions that it should be set to 0, but eg. the bdw IPS sequence doesn't mention it. I guess in theory some pcode command might cause it to be clobbered, so I'm thinking we should just explicitly set it to 0 for all platforms in the pcode read/write functions Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Michael H. Nguyen authored
The LRC increased in size on gen9. Make sure we return the right size in get_lr_context_size() v2. Corrected the size, should be 22 pages. I unintentionally mailed out a test patch w/ size equaling 23 pages. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Michael H. Nguyen <michael.h.nguyen@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Use the new AUX port irq bits where needed. v2: Rebase on top of upstream changes v3: Rebase on top of Oscar change to write IIR as soon as possible (Damien) v4: Rebase on top of the for_each_pipe() change adding dev_priv as first argument (Damien) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
This moved around on SKL, so we need to make sure we read/write the correct regs. v2: fixup WIN_POS offsets (Paulo) zero out WIN_POS reg at disable time (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuougseek.org> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
A few bits have changed in MI_DISPLAY_FLIP to accomodate the new planes. DE_RRMR seems to have kept its plane flip bits backward compatible. v2: Rebase on top of nightly v3: Rebase on top of nightly (minor conflict in i915_reg.h) v4: Remove code that is now part of intel_crtc_page_flip() Don't use BUG() in default: Use intel_crtc->unpin_work->gtt_offset (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Vandana Kannan authored
The eDP WA to stop link train based on port type is for HSW/BDW, not required for SKL+. Suggested by Satheesh v2: Simplified the check befoe stop_link_train. Suggested by Satheesh. v3: stop_link_train need not be called from intel_enable_ddi for gen >= 9 Suggested-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Cc: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
v2: rebase on top of the hw state flattening. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Satheeshakrishna M authored
This patch implements SKL DPLL programming that includes: - DPLL allocation - wide range PLL calculation and programming - DP link rate programming - DDI to DPLL mapping v2: Incorporated following changes - Added vfunc for function required outside - Fixed multiple comments in WRPLL calculation v3: - Fix the DCO computation - Move the initialization up to not clobber the computed values - Use the correct macro for DP link rate programming. - Use wait_for() to wait for the PLL locked bit v4: Rebase on top of nigthly (Damien) v5: A few code cleanups in the WRPLL computation (Damien) - Use uint32_t when possible - Use abs_diff() in the WRPLL computation - Make the 64bits divisions use div64_u64() - Fix typo in dco_central_feq_deviation (freq) - Replace the chain of breaks with a goto v6: Port of the patch to work on top of the shared DPLLs (Damien) v7: Don't try to handle eDP in ddi_pll_select() (Damien) v8: Modified as per review comments from Paulo (Satheesh) v9: Rebase on top of Ander's clock computation staging work for atomic (Damien) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v3) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Satheeshakrishna M authored
Skylake deprecates the usage of PORT_CLK_SEL and we are advised to use the new DPLL_CRTL2 for the DDI->PLL mapping. v2: Modified as per review comments Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-