- 19 Sep, 2014 34 commits
-
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
Chris Wilson authored
The data structure it was supposed to be sanity checking has long gone. Signed-off-by:
-
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 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 authored
The !crtc->enabled case will now be handled by the !visible code, since the handling is basically the same. Signed-off-by:
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
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 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 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 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:
-
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:
-
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:
-
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 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:
-
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 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:
-
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:
-
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:
Chris Wilson <chris@cris-wilsonc.co.uk> Signed-off-by:
-
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:
-
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 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 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:
-
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 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:
-
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:
-
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ä 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:
-
- 18 Sep, 2014 1 commit
-
-
git://linuxtv.org/pinchartl/fbdevDave Airlie authored
Commit "drm/rcar-du: Use struct videomode in platform data" touches board code in arch/arm/mach-shmobile. There is, to the best of my knowledge, no risk of conflict for v3.18. Simon, are you fine with getting those changes merged through Dave's tree (and could you confirm that no conflict should occur) ? Simon acked the merge: Acked-by:
Simon Horman <horms+renesas@verge.net.au> * 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: drm/rcar-du: Add OF support drm/rcar-du: Use struct videomode in platform data video: Add DT bindings for the R-Car Display Unit video: Add THC63LVDM83D DT bindings documentation video: Add ADV7123 DT bindings documentation video: Add DT binding documentation for VGA connector devicetree: Add vendor prefix "thine" to vendor-prefixes.txt devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt drm/shmob: Update copyright notice drm/rcar-du: Update copyright notice
-
- 17 Sep, 2014 5 commits
-
-
Kees Cook authored
While zone->name is currently hard coded, the call to kobject_init_and_add() should follow the more defensive argument list usage (as already done in other places in ttm_memory.c) where "%s" is used instead of directly passing in a variable as a format string. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Ezequiel Garcia authored
In order to support the "enable GPIO" available in many panel devices, this commit adds a proper devicetree binding. By providing an enable GPIO in the devicetree, the driver can now turn off and on the panel device, and/or the backlight device. Both the backlight and the GPIO are optional properties. Tested-by:
Darren Etheridge <detheridge@ti.com> Tested-by:
Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Ezequiel Garcia authored
Instead of setting an initial value for the return code, set it explicitly on each error path. This is just a cosmetic cleanup, as preparation for the enable GPIO support. Tested-by:
-
Ezequiel Garcia authored
The current backlight support is broken; the driver expects a backlight-class in the panel devicetree node. Fix this by implementing it properly, getting an optional backlight from a phandle. This shouldn't cause any backward-compatibility DT issue because the current implementation doesn't work and is not even documented. Tested-by:
-
Ezequiel Garcia authored
Using the managed variant to allocate the resource makes the code simpler and less error-prone. Tested-by:
-
