summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-04-13drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revsMika Kuoppala
Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa) suggest that WaForceContextSaveRestoreNonCoherent is needed for all revs. Extending this to all revs cures a gpu hang with rev 0xa when running heaven4.0 gpu benchmark. We have been here before, with problems enabling gt4e and extending up to revision F0 instead of false claims of bspec of E0 only. See commit <e238659ddd88> ("drm/i915/skl: Default to noncoherent access up to F0"). In retrospect we should have covered this with this big blanket back then already, as E0 vs F0 discrepancy was suspicious enough. Previously the WaForceEnableNonCoherent has been tied to context non-coherence, atleast in relevant hsds. So keep this tie and extended this alongside. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: stable@vger.kernel.org Reported-by: Mike Lothian <mike@fireburn.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-2-git-send-email-mika.kuoppala@intel.com
2016-04-13drm/i915/skl: Fix rc6 based gpu/system hangMika Kuoppala
For all gt3 and gt4 skylake variants, extend the usage of WaRsDisableCoarsePowerGating for all revisions. Without this gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or system hang. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: <stable@vger.kernel.org> Reported-by: Mikael Djurfeldt <mikael@djurfeldt.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=94161 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-1-git-send-email-mika.kuoppala@intel.com
2016-04-13drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->genJani Nikula
Sudden realization: $ grep -ho "INTEL_INFO([^)]*)->[a-zA-Z0-9_]*" *.[ch] | sed 's/.*->//' |\ sort | uniq -c | sort -rn | head -5 446 gen 24 num_pipes 10 ring_mask 9 color 4 subslice_per_slice Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460022497-29304-1-git-send-email-jani.nikula@intel.com
2016-04-13drm/i915: Use new i915_gem_object_pin_map for LRCTvrtko Ursulin
We can use the new pin/lazy unpin API for simplicity and more performance in the execlist submission paths. v2: * Fix error handling and convert more users. * Compact some names for readability. v3: * intel_lr_context_free was not unpinning. * Special case for GPU reset which otherwise unbalances the HWS object pages pin count by running the engine initialization only (not destructors). v4: * Rebased on top of hws setup/init split. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460472042-1998-1-git-send-email-tvrtko.ursulin@linux.intel.com [tursulin: renames: s/hwd/hws/, s/obj_addr/vaddr/] Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-13drm/i915: Split execlists hardware status page initialisation from setupTvrtko Ursulin
Split the hardware status page into setup and initialisation, where setup means setting up the driver state to support the engine, and initialization means programming the hardware with the before set up state. This way the design matches the design of the engine setup/init code which is split in the same fashion and it enables the stages to be used in a balanced fashion (engine setup - hws setup, engine init - hws init). This will enable the upcoming improvements to slot in without any kludges on the GPU reset path. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Don't read out port_clock on CHV when DPLL is disabledVille Syrjälä
Check whether the DPLL is even enabled before readoing out the dividers and trying to derive port_clock on CHV. We already did this on VLV. Also remove the comment "MIPI" comment from the VLV code since we call this function whenever the pipe is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Dump pfit PGM_RATIOS as hexVille Syrjälä
pgm_ratios in stored as a register value in pipe config, so let's dump this one as hex as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Fix CHV DSI PLL refclk during state readoutVille Syrjälä
Use the proper refclock frequency (100MHz) when reading out the current DSI clock on CHV. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Power down the DSI PLL before reconfiguring itVille Syrjälä
On VLV at least, the BIOS may leave the DSI PLL enabled in some wonky state where it just refuses to lock. Simply disabling the PLL before reconfiguring it is not enough to fix it, but power gating the PLL prior to reconfiguring does work. This happens on BYT FFRD8 when booting with HDMI connected so the DSI display will not be lit up by the BIOS. Also we can remove the code for BXT that disables the PLL before enabling it again. v2: s/vlv/intel/ since BXT made thing generic v3: Remove the BXT disable PLL before enable trick Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-11-git-send-email-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Change lfsr_converts[] to u16Ville Syrjälä
All the values in the DSI PLL LFSR seed table fit into 9bits, so change the type to u16 from u32 to save a bit of space. drivers/gpu/drm/i915/i915.ko: -.rodata 90824 +.rodata 90760 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"Ville Syrjälä
Enable the unclaimd register detection stuff on vlv/chv since we've now fixed the known problems during suspend. This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Move DPINVGTT setup to vlv_display_irq_reset()Ville Syrjälä
DPINVGTT lives inside the disp2d power well so we can't frob it unless we know the power well is active. Let's this stuff into vlv_display_irq_reset() which is only called at the right times so that we don't get unclaimed register access errors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Move vlv_init_display_clock_gating() to the display power wellVille Syrjälä
The registers frobbed by vlv_init_display_clock_gating() libve inside the disp2d power well, so frobbing them while the power well is down results in unclaimed register access warning (and of course the values won't stick). Let's do this setup after we know the power well is enabled. It's also worth noting that DSPCLK_GATE_D and CBR1_VLV lose their state when the power well goes down, but fortunately the values we've been writing are actually the reset defaults. MI_ARB_VLV actually retains its value even if the power well was turned off, we just can't access it while the power well is down. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstallVille Syrjälä
We expect vlv_display_irq_reset() to have been called prior to vlv_display_irq_postinstall() so let's WARN if that isn't the case. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()Ville Syrjälä
Replace the hand rolled IMR/IER setup in vlv_display_irq_postinstall() with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to avoid consusion since we no longer deal with IIR here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Clear display interrupt before enabling when turning on the power wellVille Syrjälä
For a bit of extra paranoia make sure the display irqs are all cleared before we enabled them when turning on the power well. This should really be the case already since the power well was off which resets everything. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Move vlv/chv display irq code to a more logical placeVille Syrjälä
Reshuffle the code a bit to move the vlv/chv display irq functions away from the main irq hooks, next to the other sub (de,gt,etc.) hooks. v2: Rebased due to changes in vlv_display_irq_reset() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460476604-2035-1-git-send-email-ville.syrjala@linux.intel.com
2016-04-12drm/i915: Skip display irq setup if display irqs aren't flagged as enabledVille Syrjälä
During runtime PM we'll be reinitializing interrupt support from the ground up. However since the display power well will be off at that time, well end up with a ton of unclaimed register accesses from the display irq setup. Since we turned off the power well already before runtime suspend, we've flagged display irqs as disabled during runtime PM transitions. So we can just check that flag to see if we should do skip display irqs during irq setup. During driver load display irqs will be flagged as enabled since we've turned on the power well already, however the power well code will have skipped the display irq setup since irq support as a whole wasn't yet enabled when the power well was enabled. So we'll want to do the display irq setup in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Fix up vlv/chv display irq setupVille Syrjälä
The vlv/chv display irq setup was a bit of mess after I ran out of steam when working on it last. Fix it up so that we just have a _reset() and _postinstall() hooks for the display irqs, and use those consistently. v2: Clear out pipestat_irq_mask[] and PIPE_FIFO_UNDERRUN_STATUS in vlv_display_irq_reset() (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460476574-1921-1-git-send-email-ville.syrjala@linux.intel.com
2016-04-12drm/i915: Remove "VLV magic" from irq setupVille Syrjälä
No clue what this is supposed to achieve. I think it's been there since the very beginning, so presumably some kind of kludge for very early silicon. Let's just throw it out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Replace ILK eDP underrun suppression with something betterVille Syrjälä
The underruns we were seeing when enabling eDP port A on ILK seem to have been caused by prematurely clearing the LP1+ watermark values when disabling LP1+ watermarks. Now that the watermarks are handled properly, we can rip out the underrun suppression around the port A enable. We still need to worry about the underruns on FDI when enabling the eDP PLL. But as Bspec tells us, we can avoid that by a vblank wait on the pipe driving FDI just prior to enabling the eDP PLL. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-04-12drm/i915: Make sure LP1+ watermarks levels are preserved when going from 1 ↵Ville Syrjälä
to 2 pipes Once again ILK is unhappy if we clear out the LP1+ watermark levels outright, and instead we must disable the levels we don't want while still leaving the actual programmed watermark levels intact. Fixes underruns on the already enabled pipe when programming watermarks while enabling the second pipe. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matt Roper <matthew.d.roper@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93787 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-04-12drm/i915: Try to shut up more ILK underrunsVille Syrjälä
Take a bigger hammer to the underrun suppression on ILK. Instead of trying to suppress them at specific points in the modeset sequence just silence them across the entire sequence. This gets rid of some underruns at least on my ILK. Note that this changes SNB and IVB to follow the same approach just to keep the code less convoluted. The difference is that on those platforms we won't suppress CPU underruns for port A since it doesn't seem to be necessary. My ILK has port A eDP and two PCH HDMI ports, so I can't be sure this is as effective on other PCH port types. Perhaps we still need some of Daniel's extra vblank waits [2]? I've still been able to trigger an underrun on the other pipe, but fixing that perhaps needs the LP1+ disable trick I implemented here [1] which never got merged. A few details which hamper stress testing on my ILK are that sometimes the PCH transcoder gets messed up and refuses to shut down, and sometimes even the panel power sequencer apparently gets stuck on the always on position. [1] https://lists.freedesktop.org/archives/intel-gfx/2014-March/041317.html [2] https://lists.freedesktop.org/archives/intel-gfx/2016-January/086397.html v2: Add a note that we also get underruns when enabling PCH ports Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-04-12drm/i915: Only grab correct forcewake for the engine with execlistsTvrtko Ursulin
Rather than blindly waking up all forcewake domains on command submission, we can teach each engine what is (or are) the correct one to take. On platforms with multiple forcewake domains like VLV, CHV, SKL and BXT, this has the potential of lowering the GPU and CPU power use and submission latency. To implement it we add a function named intel_uncore_forcewake_for_reg whose purpose is to query which forcewake domains need to be taken to read or write a specific register with raw mmio accessors. These enables the execlists engine setup to query which forcewake domains are relevant per engine on the currently running platform. v2: * Kerneldoc. * Split from intel_uncore.c macro extraction, WARN_ON, no warns on old platforms. (Chris Wilson) v3: * Single domain per engine, mention all registers, bi-directional function and a new name, fix handling of gen6 and gen7 writes. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460468251-14069-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-12drm/i915: Remove forcewake request registers from the shadowed tableTvrtko Ursulin
Chris Wilson points out that we can remove them from the array since they are always written to with raw accessors. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Extract knowledge of register forcewake domainsTvrtko Ursulin
Knowledge of which register per platform belonds in which forcewake domain was embedded in the MMIO accessors themselves. Extract it into standalone macros so they can be used from new code in the following patches. This causes GCC to compile some of the MMIO accessors slightly differently and grows the code a tiny amount. But none of the growth is on the fast-path so it does not matter hugely. Affected sizes before: 00000000000026f0 00000000000001a5 t gen6_read16 0000000000002390 00000000000001a5 t gen6_read32 00000000000028a0 00000000000001a5 t gen6_read64 00000000000061d0 000000000000019e t gen8_write16 0000000000006510 000000000000019d t gen8_write32 0000000000006370 000000000000019d t gen8_write64 00000000000021f0 000000000000019d t gen8_write8 Affected sizes after: 0000000000002840 00000000000001aa t gen6_read16 00000000000024e0 00000000000001a9 t gen6_read32 00000000000029f0 00000000000001a9 t gen6_read64 0000000000004f20 00000000000001b5 t gen8_write16 0000000000004ba0 00000000000001b4 t gen8_write32 00000000000050e0 00000000000001b4 t gen8_write64 0000000000004d60 00000000000001b4 t gen8_write8 Other MMIO accessors are not affected in size. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Do not serialize forcewake acquire across domainsTvrtko Ursulin
On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460045074-1006-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-12drm/i915: Simplify for_each_fw_domain iteratorsTvrtko Ursulin
As the vast majority of users do not use the domain id variable, we can eliminate it from the iterator and also change the latter using the same principle as was recently done for for_each_engine. For a couple of callers which do need the domain mask, store it in the domain array (which already has the domain id), then both can be retrieved thence. Result is clearer code and smaller generated binary, especially in the tight fw get/put loops. Also, relationship between domain id and mask is no longer assumed in the macro. v2: Improve grammar in the commit message and rename the iterator to for_each_fw_domain_masked for consistency. (Dave Gordon) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
2016-04-12drm/i915: Use consistent forcewake auto-release timeout across kernel configsTvrtko Ursulin
Because it is based on jiffies, current implementation releases the forcewake at any time between straight away and between 1ms and 10ms, depending on the kernel configuration (CONFIG_HZ). This is probably not what has been desired, since the dynamics of keeping parts of the GPU awake should not be correlated with this kernel configuration parameter. Change the auto-release mechanism to use hrtimers and set the timeout to 1ms with a 1ms of slack. This should make the GPU power consistent across kernel configs, and timer slack should enable some timer coalescing where multiple force-wake domains exist, or with unrelated timers. For GlBench/T-Rex this decreases the number of forcewake releases from ~480 to ~300 per second, and for a heavy combined OGL/OCL test from ~670 to ~360 (HZ=1000 kernel). Even though this reduction can be attributed to the average release period extending from 0-1ms to 1-2ms, as discussed above, it will make the forcewake timeout consistent for different CONFIG_HZ values. Real life measurements with the above workload has shown that, with this patch, both manage to auto-release the forcewake between 2-4 times per 10ms, even though the number of forcewake gets is dramatically different. T-Rex requests between 5-10 explicit gets and 5-10 implict gets in each 10ms period, while the OGL/OCL test requests 250 and 380 times in the same period. The two data points together suggest that the nature of the forwake accesses is bursty and that further changes and potential timeout extensions, or moving the start of timeout from the first to the last automatic forcewake grab, should be carefully measured for power and performance effects. v2: * Commit spelling. (Dave Gordon) * More discussion on numbers in the commit. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Get panel_type from OpRegion panel detailsVille Syrjälä
We've had problems on several occasions with using the panel type from the VBT block 40. Usually it seems to be 2, which often doesn't give us the correct timings for the panel. After some more digging I found a way to get a panel type via the OpRegion SWSCI GBDA "Get Panel Details" method. Let's try to use it. The spec has this to say about the output: "Bits [15:8] - Panel Type Bits contain the panel type user setting from CMOS 00h = Not Valid, use default Panel Type & Timings from VBT 01h - 0Fh = Panel Number" Another version of the spec lists the valid range as 1-16, which makes more sense since VBT supports 16 panels. Based on actual results from Rob's G45, 1-16 is what we need to accept. The other bits in the output don't look relevant for the problem at hand. The input is specified as: "Bits [31:4] - Reserved Reserved (must be zero) Bits [3:0] - Panel Number These bits contain the sequential index of Panel, starting at 0 and counting upwards from the first integrated Internal Flat-Panel Display Encoder present, and then from the first external Display Encoder (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels. 0h - 0Fh = Panel number" For now I've just hardcoded the input panel number as 0. That would seem like a decent choise for LVDS. Not so sure about eDP when port != A. v2: Accept values 1-16 Filter out bogus results in opregion code (Jani) Add debug logging for all the different branches (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rob Kramer <rob@solution-space.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460359431-11003-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Rob Kramer <rob@solution-space.com>
2016-04-12drm/i915: Replace the static panel_type variable with dev_priv->vbt.panel_typeVille Syrjälä
Store the extracted panel_type under dev_priv.vbt instead of keeping around a static variable for it. Cc: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Reject panel_type > 0xf from VBTVille Syrjälä
VBT can only contain 16 panel entries, indexed with the panel_type. To play it safe we should reject panel_type > 0xf, so that we don't read past the valid data. v2: Add debug logging (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460359329-10817-1-git-send-email-ville.syrjala@linux.intel.com
2016-04-12drm/i915: Make GMBUS timeout message DRM_DEBUG_KMSVille Syrjälä
There's no real reason the user should care that we're about to fall back to bitbanging, so let's change the message from DRM_INFO to DRM_DEBUG_KMS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-5-git-send-email-ville.syrjala@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94890 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Restore GMBUS operation after a failed bit-banging fallbackVille Syrjälä
When the GMBUS based i2c transfer times out, we try to fall back to bit-banging and retry the operation that way. However if the bit-banging attempt also fails, we should probably go back to the GMBUS method for the next attempt. Maybe there simply wasn't anyone one the bus at this time. There's also a bit of a mess going on with the force_bit handling. It's supposed to be a ref count actually, and it is as far as intel_gmbus_force_bit() is concerned. But it's treated as just a flag by the timeout based bit-banging fallback. I suppose that's fine since we should never end up in the timeout fallback case if force_bit was already non-zero. However now that we want to restore things back to where they were after the bit-banging attempt failed, we're going to have to do things a bit differently to avoid clobbering the force_bit count as set up by intel_gmbus_force_bit(). So let's dedicate the high bit as a flag for the low level timeout based fallback and treat the rest of the bits as a ref count just as before. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-12drm/i915: Protect force_bit with gmbus_mutexVille Syrjälä
Extend the protection of gmbus_mutex around the force_bit RMW in intel_gmbus_force_bit(), in case someone gets the idea of calling it from a separate thread while there's other stuff happening on the same bus. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-11drm/i915/userptr: Store i915 backpointer for i915_mm_structChris Wilson
Since we only ever use the drm_i915_private from the stored i915_mm_struct->dev, save some electrons by storing the right backpointer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-3-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/userptr: Hold mmref whilst calling get-user-pagesChris Wilson
Holding a reference to the containing task_struct is not sufficient to prevent the mm_struct from being reaped under memory pressure. If this happens whilst we are calling get_user_pages(), explosions erupt - sometimes an immediate GPF, sometimes page flag corruption. To prevent the target mm from being reaped as we are reading from it, acquire a reference before we begin. Testcase: igt/gem_shrink/*userptr Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-2-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returnsChris Wilson
In order to ensure that all invalidations are completed before the operation returns to userspace (i.e. before the munmap() syscall returns) we need to wait upon the outstanding operations. We are allowed to block inside the invalidate_range_start callback, and as struct_mutex is the inner lock with mmap_sem we can wait upon the struct_mutex without provoking lockdep into warning about a deadlock. However, we don't actually want to wait upon outstanding rendering whilst holding the struct_mutex if we can help it otherwise we also block other processes from submitting work to the GPU. So first we do a wait without the lock and then when we reacquire the lock, we double check that everything is ready for removing the invalidated pages. Finally to wait upon the outstanding unpinning tasks, we create a private workqueue as a means to conveniently wait upon all at once. The drawback is that this workqueue is per-mm, so any threads concurrently invalidating objects will wait upon each other. The advantage of using the workqueue is that we can wait in parallel for completion of rendering and unpinning of several objects (of particular importance if the process terminates with a whole mm full of objects). v2: Apply a cup of tea to the changelog. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699 Testcase: igt/gem_userptr_blits/sync-unmap-cycles Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-04-11drm/i915: Update DRIVER_DATE to 20160411Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-04-11Merge tag 'v4.6-rc3' into drm-intel-next-queuedDaniel Vetter
Linux 4.6-rc3 Backmerge requested by Chris Wilson to make his patches apply cleanly. Tiny conflict in vmalloc.c with the (properly acked and all) patch in drm-intel-next: commit 4da56b99d99e5a7df2b7f11e87bfea935f909732 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 4 14:46:42 2016 +0100 mm/vmap: Add a notifier for when we run out of vmap address space and Linus' tree. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-04-11drm/i915: Avoid allocating a vmap arena for a single pageChris Wilson
If we want a contiguous mapping of a single page sized object, we can forgo using vmap() and just use a regular kmap(). Note that this is only suitable if the desired pgprot_t is compatible. v2: Use is_vmalloc_addr() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-7-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
2016-04-11drm,i915: Introduce drm_malloc_gfp()Chris Wilson
I have instances where I want to use drm_malloc_ab() but with a custom gfp mask. And with those, where I want a temporary allocation, I want to try a high-order kmalloc() before using a vmalloc(). So refactor my usage into drm_malloc_gfp(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-6-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/shrinker: Restrict vmap purge to objects with vmapsChris Wilson
When called because we have run out of vmap address space, we only need to recover objects that have vmappings and not all. v2: Start using is_vmalloc_addr() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-5-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
2016-04-11drm/i915: Refactor duplicate object vmap functionsChris Wilson
We now have two implementations for vmapping a whole object, one for dma-buf and one for the ringbuffer. If we couple the mapping into the obj->pages lifetime, then we can reuse an obj->mapping for both and at the same time couple it into the shrinker. There is a third vmapping routine in the cmdparser that maps only a range within the object, for the time being that is left alone, but will eventually use these routines in order to cache the mapping between invocations. v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala) v3: Call unpin_vmap from the right dmabuf unmapper v4: Rename vmap to map as we don't wish to imply the type of mapping involved, just that it contiguously maps the object into kernel space. Add kerneldoc and lockdep annotations Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-4-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
2016-04-11drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_objChris Wilson
After we pin the ringbuffer into the GGTT, all error paths need to unpin it again. Move this common step into one block, and make the unable to iomap error code consistent (i.e. treat it as out of memory to avoid confusing it with a invalid argument). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-3-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_bufChris Wilson
We only need the struct_mutex to manipulate the pages_pin_count on the object, we do not need to hold our BKL when freeing the exported scatterlist. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-2-git-send-email-chris@chris-wilson.co.uk
2016-04-11drm/i915: implement WaClearTdlStateAckDirtyBitsTim Gore
This is to fix a GPU hang seen with mid thread pre-emption and pooled EUs. v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID v3. And use correct type for register addresses Signed-off-by: Tim Gore <tim.gore@intel.com> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458571049-854-1-git-send-email-tim.gore@intel.com
2016-04-11drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bitDongwon Kim
For BXT, description of polarities of PORT_PLL_REF_SEL has been reversed for newer Gen9LP steppings according to the recent update in Bspec. This bit now should be set for "Non-SSC" mode for all Gen9LP starting from B0 stepping. v2: Only B0 and newer stepping should be affected by this change. Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94866 Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458176773-26925-1-git-send-email-dongwon.kim@intel.com
2016-04-11drm/i915: Rename hw state checker to hw state verifier.Maarten Lankhorst
Check functions are used by atomic to see if the new state will be allowed. There's also a hw state checker which checks afterwards that the committed state is correct. Rename it to hw state verifier to reduce some confusion. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56FB8785.8020506@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2016-04-11drm/i915: Move modeset state verifier calls.Maarten Lankhorst
The modeset state verifier no longer has full access to the hardware, instead it should only verify affected crtc's. Looking for disabled stuff can be verified immediately after all crtc disables have completed, while each enabled crtc can be verified right after being enabled. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458741487-23801-3-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [mlankhorst: check -> verify]
generated by cgit (git 2.34.1) at 2025-04-24 09:08:40 +0000