- 19 Sep, 2014 40 commits
-
-
Daniel Vetter authored
Now we tackle the functions also called from interrupt handlers. - intel_check_page_flip is exclusively called from irq handlers, so a plain spin_lock is all we need. In i915_irq.c we have the convention to give all such functions an _irq_handler postfix, but that would look strange and als be a bit a misleading name. I've opted for a WARN_ON(!in_irq()) instead. - The other two places left are called both from interrupt handlers and from our reset work, so need the full irqsave dance. Annotate them with a short comment. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
It's good practice to use the more specific versions for irq save spinlocks both as executable documentation and to enforce saner design. The _irqsave version really should only be used if the calling context is unknown and there's a good reason to call a function from all kinds of places. This is the first step whice replaces all occurances of _irqsave in process context with the simpler irq disable/enable variants. We don't have any funky spinlock nesting going on, especially since the event_lock is the outermost of the irq/vblank related spinlocks. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
We changed to an interrupt based vblank wait (as opposed to polling) in: commit 44bd93a3d367913d883be6abba9a6e51a53c4e90 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 25 23:36:44 2014 +0200 drm/i915: Use generic vblank wait However we already had vblank waits on the wrong side of drm_vblank_{on,off}() calls due to various workarounds, so now we get a warning more or less every time we do a modeset, and we fail to wait for the vblank like we should. Move the drm_vblank_{on,off}() calls back out from intel_crtc_{enable,disable}_planes() so that all of these vblank waits return to proper operation. Also move the cxsr wait a bit earlier so that we can keep the encoder disable after we've turned off vblanks. Moving stuff out from the plane enable/disable functions seems preferrable to moving the workaround stuff in since the workarounds are required only on specific platforms. While at it switch over to the drm_crtc_ variants of the vblank on/off functions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82525 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82490 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Requested by Chris, and also requested to keep it since it's a more accurate name in his opinion. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This has the upside that it will no longer steal interrupts from the interrupt handler on pre-g4x. Furthermore this will now scream properly on all platforms if we don't have hw counters enabled. v2: Adjust to the new names. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Originally the irq safe spinlock was required because of asle interrupts. But since commit 91a60f20 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Oct 31 18:55:48 2013 +0200 drm/i915: move opregion asle request handling to a work queue there's no need for this any more. So switch to the simpler mutex. v2: Cite the right commit, spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
This does not seem to make a difference for the structs in question, but document the intent. v2: also pack union child_device_config (Daniel) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Yet another place that wasn't properly transformed when implementing SOix. While at it convert the checks to WARN_ON on gen5+ (since we don't have UMS potentially doing stupid things on those platforms). And also add the corresponding checks to the put functions (again with a WARN_ON) for gen5+. v2: Drop the WARNINGS in the irq_put functions (including the existing one for vebox), Chris convinced me that they're not that terribly useful. v3: Don't forget about execlist code. Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: "Volkin, Bradley D" <bradley.d.volkin@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>
-
Imre Deak authored
We want to enable/disable display IRQs only if global i915 IRQs are enabled. To check the latter it's not enough to consult the DRM dev->irq_enabled flag, since runtime PM can disable/enable IRQs and it won't adjust this flag only the i915 specific dev_priv->pm._irqs_disabled flag. Fix this by using the proper intel_irqs_enabled() helper instead. Fortunately this didn't cause an actual problem since even if we enabled display IRQs too early (before enabling global i915 IRQs) the VLV_MASTER_IER would still be clear masking all IRQs. This issue was caught by commit 920dd15a2b2fc60d054646a8a1ffd6aeb6090e05 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 27 10:43:37 2014 +0200 drm/i915: WARN if interrupts aren't on in en/disable_pipestat Signed-off-by: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
It seems cleaner if we keep CURCNTR at 0 when the cursor is disabled, so don't set the CURSOR_PIPE_CSC_ENABLE bit unless the cursor is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
To make the code a bit more undestandable move the intel_crtc->cursor_base assignment into the low level update cursor routines. That's were we compare the current value with the new one so immediately seeing that it gets assigned only afterwards helps one to understand that it gets assigned only after the comparison. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
If a page isn't allocated as __GFP_MOVEABLE it won't move around, so no need to grab a reference to lock it into place. Discovered while reviewing page allocation handling in i915 gem. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
While discussing/reviewing __GFP_MOVEABLE behaviour and interactions with our various page allocations on irc Chris brought up that the scratch page isn't allocated as moveable, but we still grab/put a reference to lock it in place. Which is unecessary. So drop that. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Gustavo Padovan authored
7e4bf45dbd99a965c7b5d5944c6dc4246f171eb5 introduced the regression. We fix it by doing the right assignment of crtc_y Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83747Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
The data structure it was supposed to be sanity checking has long gone. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
Factor out a piece of code from intel_pipe_set_base() that updates the pipe size and adjust fitter. This will help refactor the update primary plane path. v2: use struct intel_crtc as argument to intel_update_pipe_size() v3: use 'crtc' as argument name Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
Optimize code avoiding helding dev mutex if old fb and current fb are the same. v2: take Ville's comments - move comment along with the pin_and_fence call - check for error before calling i915_gem_track_fb - move old_obj != obj to an upper if condition Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
The !crtc->enabled case will now be handled by the !visible code, since the handling is basically the same. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This was lost in commit e11aa362 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw which makes the second part of this commen a bit nonsense. Both were originally added in commit 15239099 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 5 09:50:58 2013 +0100 drm/i915: enable irqs earlier when resuming Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
As a preparation for atomic updates we need to split the code to check everything we are going to commit first. This patch starts the work to split intel_primary_plane_setplane() into check() and commit() parts. More work is expected on this to get a better split of the two steps. Ideally the commit() step should never fail. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
Due to the upcoming atomic modesetting feature we need to separate some update functions into a check step that can fail and a commit step that should, ideally, never fail. The commit part can still fail, but that should be solved in another upcoming patch. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
Due to the upcoming atomic modesetting feature we need to separate some update functions into a check step that can fail and a commit step that should, ideally, never fail. This commit splits intel_update_plane() and its commit part can still fail due to the fb pinning procedure. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Gustavo Padovan authored
This new struct will be the storage of src and dst coordinates between the check and commit stages of a plane update. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Now that vlv has runtime pm we kinda should check for that like on the pch split platforms. Looks like this was simply lost in the vlv rpm enabling. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Michel Thierry authored
Use full PPGTT as the default option in gen7. Note that aliasing PPGTT is the default option for gen8 (see HAS_PPGTT) since we're still fighting troubles around context switching and execlists. This may well come back to bite me later. Signed-off-by: Michel Thierry <michel.thierry@intel.com> [danvet: Explain that gen8 full ppgtt is blocked on execlists for now.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
If something while getting panel CRC this means that probably hw I/O error so hw is busted and try again shouldn't help much. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Based upon a patch from Deepak, but reworked to only apply on gen7+ and with the logic a bit clarified. v2: Fix s/SHIFT/MASK/ fumble that Ville spotted. Cc: Deepak S <deepak.s@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
If we believe that the device can cross cache domains in its prefetcher (i.e. we allow neighbouring pages in different domains), we don't supply a color_adjust callback. Use the presence of this callback to better determine when we should be verifying that the GTT space we just used is valid. v2: Remove the superfluous struct drm_device function param as well. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Also adjust the comment per irc discussion with Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with the security bit (i.e. only privileged batches were allowed to run from ggtt). From Haswell only, you are able to select the security bit separate from the address space - and we always requested to use ppgtt. This breaks the golden render state batch execution with full-ppgtt as that is only present in the global GTT and more generally any secure batch that is not colocated in the ppgtt and ggtt. So we need to disable the use of the ppgtt selector bit for secure batches, or else we hang immediately upon boot and thence after every GPU reset... v2: Only HSW differentiates between secure dispatch and ggtt, so simply ignore the differentiation and always use secure==ggtt. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rectify commit message as noted by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Deepak S authored
In chv, we have two power wells Render & Media. We need to use corresponsing forcewake count. If we dont follow this we are getting error "*ERROR*: Timed out waiting for forcewake old ack to clear" due to multiple entry into __vlv_force_wake_get. Signed-off-by: Deepak S <deepak.s@linux.intel.com> Requested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Michel Thierry authored
Also here, i915_gem_evict_vm causes an unbind, which can end up dropping the last ref to the ppgtt. Triggered by igt gem_evict_everything test. Testcase: igt/gem_evict_everything Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Chris Wilson <chris@cris-wilsonc.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Somehow I've overlooked this when simplifying the irq reinit scheme on gen4.5+ in commit 78ad455f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu May 22 22:18:21 2014 +0200 drm/i915: Improve irq handling after gpu resets Since display interrups in general survive a gpu reset on those platforms there's also no need to reinit the hotplug settings. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
drm_send_vblank_event() demands that we hold the event spinlock whilst calling it, so do so. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fix the double lock as requested by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Before we process the final unbind on an object and move it to the unbound list, it is semantically cleaner if there are no more active references to the object. (An active reference would imply that it was still being accessed by the GPU after it became inaccessible.) The caveat is that all callsites must be prepared for the object to disappeared during the unbind - i.e. they must hold their own reference. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Due to the lazy retirement semantics, even though we have unbound an object, it may still hold onto an active reference. So in the debug code, play safe. v2: Export i915_gem_shrink() rather than opencoding it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
eDP panels are generally designed to support only a single clock and lane configuration. commit 56071a20 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue May 6 14:56:52 2014 +0300 drm/i915: use lane count and link rate from VBT as minimums for eDP should have started using the optimal link parameters for eDP panels. Turns out a certain other OS uses DPCD instead of VBT, which means trusting VBT on this may not be so reliable after all. Follow suit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81647Tested-by: Adam Jirasek <libm3l@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79386Tested-by: Narthana Epa <narthana.epa+freedesktop@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
This goes back to commit 06ea66b6 Author: Todd Previte <tprevite@gmail.com> Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> [danvet: Pimp commit message a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Oops, apparently intel_hdmi/intel_dp is the encoder - an object with a distinct lifetime to the connector, and so we cannot simply reuse the common function to unset and free the edid. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
830 is very unhappy of the watermark value is too low (indicating a very high watermark in fact, ie. memory fetch will occur with an almost full FIFO). Limit the watermark value to at least 8 cache lines. That also matches the burst size we use on most platforms. BSpec seems to indicate we should limit the watermark to 'burst size + 1'. But on gen4 we already use a hardcoded 8 as the watermark value (as the spec says we should), so just use 8 as the limit on gen2/3 as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
The spec says: "For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata, GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31 (DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in both the DPLL A Control Register (06014h-06017h) and DPLL B Control Register (06018h-0601Bh)." The pipe A and B force quirks take care of DPLL_VCO_ENABLE, so we just need a bit of special care to handle DPLL_DVO_2X_MODE. v2: Recompute num_dvo_pipes on the spot, use PIPE_A/PIPE_B instead of pipe/!pipe for the register offsets in disable (Daniel) Add a comment about the ordering in enable and another one about filtering out the DVO 2x bit in state readout Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-