- 02 Aug, 2016 15 commits
-
-
Keith Packard authored
There are two paths into intel_cleanup_plane_fb, the normal completion path and the failure path. In the failure case, intel_cleanup_plane_fb is called before drm_atomic_helper_swap_state, so any wait_req reference made in intel_prepare_plane_fb will be in old_intel_state->wait_req. In the normal completion path, drm_atomic_helper_swap_state has already been called, so the plane state holding the just-used wait_req will not be in old_intel_state->wait_req, rather it will be in the state associated with the plane itself. Clearing this reference ensures that the wait_req will be freed as soon as it the related mode setting operation is complete, rather than waiting for some future mode setting operation to eventually dereference it. The existing dereference of old_intel_state->wait_req is still required as that will hold the wait_req when the mode setting operation fails. cc: Daniel Vetter <daniel.vetter@intel.com> cc: David Airlie <airlied@linux.ie> cc: intel-gfx@lists.freedesktop.org cc: dri-devel@lists.freedesktop.org Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
If we have have a buffer, we should also have a size, and vice versa. Let's check it both ways instead of just one. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469717704-13020-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
According to Bspec FW_BLC_SELF exists on 915G also. Let's program it. The only open question is whether there's is a memory self-refresh enable bit somewhere as well. For 945G/GM it's in FW_BLC_SELF, for 915GM it's in INSTPM. For 915G I can't find one in the docs. Let's drop a FIXME about this, in case someone with the hardware is ever bored enough to look for it. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Bspec says: "FW_BLC_SELF ... Programming Note [DevALV] and [DevCST]: When calculating watermark values for 15/16bpp, assume 32bpp for purposes of calculation using the high priority bandwidth analysis spreadsheet." Let's do that. Perhaps this might even help with the problem that resulted in commit 2ab1bc9d ("drm/i915: Disable self-refresh for untiled fbs on i915gm") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Make the BDW and SKL code a bit more similar by extracting the low vswing handling for BDW into a helper, as we already have it like that for SKL+. Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
We no longer have any need to look up the intel_digital_port based on the passed in intel_encoder, but we still want to look up the port. Let's just move that logic into intel_ddi_get_encoder_port() and drop the dig_port stuff. Signed-off-by:
-
Ville Syrjälä authored
Program the 'iboost_bit' based on what the VBT says it should be for the specific port type, rather than assume it's always the same for DP and HDMI. Signed-off-by:
-
Ville Syrjälä authored
DDI buffer prorgramming works quite differently depending on the mode of the DDI port (DP/eDP/FDI vs. HDMI/DVI). Let's split the function that does the programming into two matching variants as well. Signed-off-by:
-
Ville Syrjälä authored
When the DDI port is in HDMI/DVI mode, it automagically uses the buffer translations values from entry 9. Let's make that explicit in the code. Signed-off-by:
-
Ville Syrjälä authored
Now that the SKL iboost programming is done from intel_ddi_pre_enable() for HDMI, let's move the BXT bxt_ddi_vswing_sequence() call there as well. This makes things look more similar to the DP/eDP case which is handled in ddi_signal_levels(). Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we fail to program the iboost stuff for HDMI/DVI. Let's remedy that. Cc: stable@vger.kernel.org Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements") Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com>
-
Ville Syrjälä authored
Give a proper name for the SKL DDI_BUF_TRANS iboost bit. Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Bspec says: "For DDIA with x4 capability (DDI_BUF_CTL DDIA Lane Capability Control = DDIA x4), the I_boost value has to be programmed in both tx_blnclegsctl_0 and tx_blnclegsctl_4." Currently we only program tx_blnclegsctl_0. Let's do the other one as well. Cc: stable@vger.kernel.org Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements") Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Matthew Auld authored
The fbc enabled/active sanity checks are already done in __intel_fbc_disable so no need to do them again. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467710914-15146-1-git-send-email-matthew.auld@intel.com
-
Chris Wilson authored
In the middle of intel_gt_init_powersave() we have an if-chain that ends with a universal else clause to read gen6+ registers. Older platforms like Pineview that end up here do not like those registers and may even OOPS whilst reading them! Fixes: 3ea9a80132 ("drm/i915: Perform static RPS frequency setup ...") Signed-off-by:
-
- 01 Aug, 2016 1 commit
-
-
David Weinehall authored
When reading the SSEU statistics, we need to call intel_runtime_pm_get() first, otherwise we might end up triggering "Device suspended during HW access". Signed-off-by:
-
- 29 Jul, 2016 1 commit
-
-
Chris Wilson authored
It appears that we never told Pineview it has a RENDER_RING. This was all fine until we started using the ring_mask for determining all the available rings to initialise for legacy ringbuffer submission in commit 88d2ba2e ("drm/i915: Unify engine init loop"). Though really it is a latent bug since the ring_mask inception in commit 73ae478c ("drm/i915: Replace has_bsd/blt/vebox with a mask"). To prevent similar mishaps in future, add a WARN_ON() if we find ourselves with a device without any rings. Fixes: 73ae478c ("drm/i915: Replace has_bsd/blt/vebox with a mask") Fixes: 88d2ba2e ("drm/i915: Unify engine init loop") Signed-off-by:
-
- 28 Jul, 2016 2 commits
-
-
Chris Wilson authored
The merge conflict resolution caused some dev->dev_private to return from the dead. Kill them with to_i915(). Signed-off-by:
-
Ville Syrjälä authored
SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck in an infinite batch buffer loop. The GPU apparently hogs something critical and CPUs start to lose interrupts and whatnot. We can keep the system limping along by unmasking some interrupts in GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for that task, so let's never mask it. v2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93122Signed-off-by:
-
- 27 Jul, 2016 6 commits
-
-
Chris Wilson authored
We still have lots of comments that refer to the old ring when we mean struct intel_engine_cs and its hardware correspondence. This patch fixes an instance inside hangcheck to talk about engines. Signed-off-by:
-
Chris Wilson authored
A few places we use ring when referring to the struct intel_engine_cs. An anachronism we are pruning out. Signed-off-by:
-
Chris Wilson authored
Inside the error capture itself, we refer to not only the hardware engine, its ringbuffer but also the capture state. Finding clear names for each whilst avoiding mixing ring/intel_engine_cs is tricky. As a compromise we keep using ering for the error capture. v2: Use 'ee' locals for struct drm_i915_error_engine Signed-off-by:
-
Chris Wilson authored
This patch transitions the execbuf engine selection away from using the ring nomenclature - though we still refer to the user's incoming selector as their user_ring_id. Signed-off-by:
-
Chris Wilson authored
When we refer to intel_engine_cs, we want to use engine so as not to confuse ourselves about ringbuffers. v2: Rename all the functions as well, as well as a few more stray comments. v3: Split the really long error message strings Signed-off-by:
-
Ville Syrjälä authored
Bspec tells us to keep bashing the PCU for up to 3ms when trying to inform it about an upcoming change in the cdclk frequency. Currently we only keep at it for 15*10usec (+ whatever delays gets added by the sandybridge_pcode_read() itself). Let's change the limit to 3ms. I decided to keep 10 usec delay per iteration for now, even though the spec doesn't really tell us to do that. Cc: stable@vger.kernel.org Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume") Cc: David Weinehall <david.weinehall@intel.com> Signed-off-by:
David Weinehall <david.weinehall@intel.com> Reviewed-by:
-
- 26 Jul, 2016 4 commits
-
-
Chris Wilson authored
The obj->batch_pool_link is only inspected when traversing the batch pool list and when on the batch pool list the object is referenced. Thus when freeing the batch pool list, we only need to unreference the object and do not have to worry about the obj->batch_pool_link. Signed-off-by:
-
Chris Wilson authored
Upon release of the file (i.e. the user calls close(fd)), we decouple all objects from the client list so that we don't chase the dangling file_priv. As we always inspect file_priv first, we only need to nullify that pointer and can safely ignore the list_head. Signed-off-by:
-
Chris Wilson authored
list_first_entry_or_null() can generate better code than using if (!list_empty()) {ptr = list_first_entry()) ..., so put it to use. Signed-off-by: -
Chris Wilson authored
Since intel_engine_enable_signaling() is now only called via fence_enable_sw_signaling(), we can rely on it to provide serialisation and run-once for us and so make ourselves slightly simpler. Signed-off-by:
-
- 25 Jul, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 24 Jul, 2016 2 commits
-
-
Chris Wilson authored
In order to close a race with a long running hangcheck comparing a stale interrupt counter with a just started waiter, we need to first bump the counter as we start the fresh wait. References: https://bugs.freedesktop.org/show_bug.cgi?id=96974Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469351421-13493-2-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
During the idle-worker we disable the hangcheck and so kick any waiters that should have been completed (since the GPU is now idle). Unlike the hangcheck, we do not take any care to avoid the race between the irq handler and ourselves, and so it is possible for us to declare a missed interrupt even as the bottom-half is being scheduled to run. Let's ignore this race to stop a potential false-positive error. References: https://bugs.freedesktop.org/show_bug.cgi?id=96974Signed-off-by:
-
- 21 Jul, 2016 8 commits
-
-
Chris Wilson authored
This reverts commit b12e0ee2 ("drm/i915: Enable RC6 immediately"), as it was never meant to be sent anywhere other than the bug report for experimentation. Signed-off-by:
-
Daniel Vetter authored
I forgot to remove these when reworking the firmware loading sequence last year. The new sequence is that we load firmware, and if it's not there we entirely (and permanently) fail dmc setup. Reported-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468505704-17391-1-git-send-email-daniel.vetter@ffwll.ch
-
Dave Gordon authored
The exit path in intel_overlay_put_image_ioctl() first unlocks the struct_mutex, then drops its reference to 'new_bo' by calling i915_gem_object_put(). As it isn't holding the mutex at this point, this should be i915_gem_object_put_unlocked(). This was previously correct but got splatted in the recent s/drm_gem_object_unreference/i915_gem_object_put/ where the _unlocked suffix was lost in this one case. v2: don't bother fixing whitespace glitch [Chris Wilson] Chris can do it next time he touches gem_evict.c ;) Fixes: f8c417cd drm/i915: Rename drm_gem_object_unreference in preparation ... Signed-off-by: -
Chris Wilson authored
Now that PCU communication is reasonably fast, we do not need to defer RC6 initialisation to a workqueue. References: https://bugs.freedesktop.org/show_bug.cgi?id=97017Signed-off-by:
-
Tim Gore authored
WaC6DisallowByGfxPause is currently applied unconditionally but is not required in all revisions. v2: extend application of workaround to agree with w/a database, which differs from the HSD. References: HSD#2133391 Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469008825-19442-1-git-send-email-tim.gore@intel.com
-
Dave Gordon authored
'ring' is an old deprecated term for a GPU engine, so we're trying to phase out all such terminology. eb_select_ring() not only has 'ring' (meaning engine) in its name, but it has an ugly calling convention whereby it returns an errno and stores a pointer-to-engine indirectly through an output parameter. As there is only one error it ever returns (-EINVAL), we can make it return the pointer directly, and have the caller pass back the error code -EINVAL if the pointer result is NULL. Thus we can replace - ret = eb_select_ring(dev_priv, file, args, &engine); - if (ret) - return ret; with + engine = eb_select_engine(dev_priv, file, args); + if (!engine) + return -EINVAL; for increased clarity and maybe save a few cycles too. Signed-off-by:
-
Dave Gordon authored
'ring' is an old deprecated term for a GPU engine. Chris Wilson wants to use the name for what is currently known as an intel_ringbuffer, but it will be dreadfully confusing if some rings are ringbuffers but other rings are still engines. So this patch changes the names of a bunch of parameters called 'ring' to either 'engine' or 'engine_id' according to what they actually are. Signed-off-by:
-
Dave Gordon authored
'ring' is an old deprecated term for a GPU engine. Here we make the terminology more consistent by renaming the 'ring' parameter of lots of macros that calculate addresses within the MMIO space of an engine. Signed-off-by:
-
