- 01 Jun, 2018 10 commits
-
-
Ville Syrjälä authored
We already handle the color encoding mode properly. Remove the broken NV12 special case. Cc: Vidya Srinivas <vidya.srinivas@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 8ed30ab6 ("drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521185613.5097-1-ville.syrjala@linux.intel.comReviewed-By:
Vidya Srinivas <vidya.srinivas@intel.com>
-
Ville Syrjälä authored
The sprite code has a bunch of spaces where tabs should be used. Fix it up. v2: Make the patch subject more specific (Jani) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Call the enum i9xx_plane_id variable i9xx_plane like we do elsewhere. Cc: Hans de Goede <j.w.r.degoede@gmail.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
We disable trickle feed whenever possible, except for the cursors on SNB/IVB. Let's try disabling it there too if for no other reason than consistency. Signed-off-by:
-
Ville Syrjälä authored
Use MCURSOR_ instead of CURSOR_ as the prefix for the non-845/865 cursor defines consistently, and move the pipe CSC enable bit next to the other non-845/865 cursor defines. v2: Take care of gvt uses as well v3: Another gvt use popped up Signed-off-by:
-
Ville Syrjälä authored
Like we do for encoder let's make the plane->get_hw_state() return the pipe to which the plane is currently attached. We don't currently allow planes to move between the pipes, but perhaps one day we will. In either case this makes the code more uniform and perhaps makes intel_plane_mapping_ok() slightly more clear. Note that for i965 and g4x planes A and B still have pipe select bits but they're hardwired to pipe A and B respectively. This means we can safely interpret those bits just like on gen2/3. This allows the same readout code work for plane C (which can still be assigned to eiter pipe on i965) should we ever expose it. g4x no longer allows moving the cursor planes between the pipes, but the pipe select bits can still be set in the register. Thus we have to ignore those bits. OTOH i965 still allows the cursors to move between pipes thus we have to trust the bits there. Signed-off-by:
-
Chris Wilson authored
On resume, we have to rewrite all the PDE entries for gen7 ppgtts. If we switch on full-ppgtt, there is then one address space with no PDE, the GGTT. Currently under aliasing-ppgtt, the GGTT address space does have an associated ppgtt and so the restore works just fine. We would have a similar problem if we tried disabling aliasing-ppgtt (i915.enable_ppgtt=0). So skip the empty ppgtt, as being non-existent it doesn't need restoring. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180601093554.13083-2-chris@chris-wilson.co.ukReviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
On hsw and older, we do not need to allocate the ppgtt on the fly and so ppgtt->allocate_va_range() is NULL. Fixup ppgtt_bind_vma not to call it, in that case! v2: PIN_UPDATE still exists. Signed-off-by:
-
Chris Wilson authored
As we store the intel_context on the request (rq->hw_context), we can simply compare that against the local intel_context for the i915->kernel_context rather than using the rq->gem_context. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180601094002.13329-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Now that we always switch to the kernel context upon idling, we can make that assertion. References: 4dfacb0b ("drm/i915: Switch to kernel context before idling at runtime") Signed-off-by:
-
- 31 May, 2018 6 commits
-
-
Chris Wilson authored
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and disabling reset (gem_eio/suspend). This results in the device continuing on without being reset, but since it has gone through HW sanitization to account for the suspend/resume cycle, we have to assume the device has been reset to its defaults. A simple way around this is to skip the sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180531082246.9763-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we reset the GPU on suspend/resume, we also do need to reset the engine state tracking so call into the engine backends. This is especially important so that we can also sanitize the state tracking across resume. References: https://bugs.freedesktop.org/show_bug.cgi?id=106702Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180531082246.9763-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
During suspend we want to flush out all active contexts and their rendering. To do so we queue a request from the kernel's context, once we know that request is done, we know the GPU is completely idle. To speed up that switch bump the GPU clocks. Switching to the kernel context prior to idling is also used to enforce a barrier before changing OA properties, and when evicting active rendering from the global GTT. All cases where we do want to race-to-idle. v2: Limit the boosting to only the switch before suspend. v3: Limit it to the wait-for-idle on suspend. Signed-off-by:
-
Chris Wilson authored
We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through the slow and irregular retire work handler. Signed-off-by:
-
Michal Wajdeczko authored
SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and those events are now handled by intel_guc_to_host_event_handler_mmio(). We should not try to read it on MMIO action error as 1) we may be using different set of registers for GuC MMIO communication, and 2) GuC may use CTB mechanism for sending events to host. While here, upgrade error message to DRM_ERROR. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Maarten Lankhorst authored
Normally this is called on a modeset, but the call is missing when we inherit the mode from the BIOS, so make sure it's called somewhere in hardware readout. Changes since v1: - Unconditionally call intel_opregion_notify_encoder. (Ville) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516085038.36785-1-maarten.lankhorst@linux.intel.comReviewed-by:
-
- 30 May, 2018 2 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
Since we use i915_gem_find_active_request() from inside intel_engine_dump() and may call that at any time, we do not guarantee that the engine is paused nor that the signal kthreads and irq handler are suspended, so we cannot assert that the breadcrumb doesn't advance and that the irq hasn't happened on another CPU signaling the request we believe to be idle. The second assert removed (that request->engine == engine) remains valid, but is now more rigorously checked during retirement. Fixes: f636edb2 ("drm/i915: Make i915_engine_info pretty printer to standalone") Signed-off-by:
-
- 29 May, 2018 6 commits
-
-
Dhinakaran Pandiyan authored
DPCD 2009h "Synchronization latency in sink" has bits that tell us the maximum number of frames sink can take to resynchronize to source timing when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum number of frames following PSR exit that the Source device needs to wait for PSR entry." We currently use this value only to setup the number frames to wait before PSR2 selective update. But, based on the above description it makes more sense to use this to configure idle frames for both PSR1 and and PSR2. This will ensure we wait the required number of frames before activation whether it is PSR1 or PSR2. The minimum number of idle frames remains 6, while allowing sink synchronization latency and VBT to increase this value. This also solves the flip-flop between sink and source frames that I noticed on my Thinkpad X260 during PSR exit. This specific panel has a value of 8h, which according to the spec means the "Source device must wait for more than eight active frames after PSR exit before initiating PSR entry. (In this case, should be provided by the panel supplier.)" VBT however has a value of 0. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Oscar Mateo authored
Prevents an error in the GAM unit. Also known as WaGamTlbPendError References: HSDES#1406463099 References: HSDES#1406465643 Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
-
Oscar Mateo authored
Enables blend optimization for floating point RTs v2: Rebased on top of the WA refactoring v3: Added References (Mika) References: HSDES#1406393558 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Oscar Mateo authored
Disable blend embellishment in RCC. Also, some other registers style fixed in passing. v2: Rebased on top of the WA refactoring v3: Added References (Mika) v4: - Fixed in B0 - Mentioned style fixes in commit message References: HSDES#2006665173 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Oscar Mateo authored
Redirects the state cache to the CS Command buffer section for performance reasons. v2: Rebased v3: Rebased on top of the WA refactoring v3: Added References (Mika) References: HSDES#1604325460 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Oscar Mateo authored
Revert to the legacy implementation. v2: GEN7_ROW_CHICKEN2 is masked v3: - Rebased - Renamed to Wa_2006611047 - A0 and B0 only v4: - Add spaces around '<<' (and fix the surrounding code as well) - Mark the WA as pre-prod v5: Rebased on top of the WA refactoring v6: Added References (Mika) v7: Fixed in B0 References: HSDES#2006611047 Signed-off-by:
-
- 25 May, 2018 10 commits
-
-
Michal Wajdeczko authored
Some functions already use i915 name instead of dev_priv. Let's rename this param in all remaining functions, except those that still use legacy macros. v2: don't forget about function descriptions (Sagar) v3: rebased v4: rebased v5: rebased, pulled out from the series Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Let's suppress the underruns around every modeset sequence instead of trying to avoid it. Planes are disabled at this point anyway so we don't really gain anything from keeping the underrun reporting enabled. Also for PCH ports we already suppress all underruns here anyway so trying avoid it for the CPU eDP doesn't seem all that important. Maybe this gets rid of some lingering spurious underruns? Signed-off-by:
-
Ville Syrjälä authored
VBT seems to have some bits to tell us whether the internal LVDS port has something hooked up. In theory one might expect the VBT to not have a child device for the LVDS port if there's no panel hooked up, but in practice many VBTs still add the child device. The "LVDS config" bits seem more reliable though, so let's check those. So far we've used the "LVDS config" bits to check for eDP support on ILK+, and disable the internal LVDS when the value is 3. That value is actually documented as "Both internal LVDS and SDVO LVDS", but in practice it looks to mean "eDP" on all the ilk+ VBTs I've seen. So let's keep that interpretation, but for pre-ILK we will consider the value 3 to also indicate the presence of the internal LVDS. Currently we have 25 DMI matches for the "no internal LVDS" quirk. In an effort to reduce that let's toss in a WARN when the DMI match and VBT both tell us that the internal LVDS is not present. The hope is that people will report a bug, and then we can just nuke the corresponding entry from the DMI quirk list. Credits to Jani for this idea. v2: Split the basic int_lvds_support thing to a separate patch (Jani) v3: Rebase v4: Limit this to VBT version >= 134 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Ville Syrjälä authored
My ILK seems to generate a spurious PCH underrun with most interlaced HDMI modes. Add a second vblank wait to avoid it. We have seen some spurious PCH underruns still in CI as well, some of which seem to be progressive DP. The logs also point towards some spurious underrins with progressive HDMI on SNB. While I don't have a solid explanation for those let's try to kill all the birds with one stone and always do the double wait. Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106387Signed-off-by:
-
Ville Syrjälä authored
We can always figure out which pipe is affected by the panel power sequencer lockout mechanism. So no need for the pipe A fallback anymore. The only case we may have to worry about is an invalid port select in the power sequencer, but INVALID_PIPE is just fine in that case. We'll get the WARN about the bogus pps port select anyway. Cc: Jani Nikula <jani.nikula@intel.com> Suggested-by:
-
Chris Wilson authored
In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started to turn off (e.g. swapin fails if scsi is suspended). Fortunately, we are provided with a such a hook, pm_ops.prepare(). v2: Compile cleanup v3: Fewer asserts, fewer problems? v4: Ville pointed out that in some circumstances (such as switching off the overlay) the display code may issue a GPU request. This is unexpected, and will result in us going to sleep with us believing the GPU is still awake (though all user work has been saved). Add a comment to remind our future selves of what trouble brews. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106640 Testcase: igt/drv_suspend after igt/gem_tiled_swapping Signed-off-by:
-
Chris Wilson authored
After a reset, we will ensure that there is at least one request submitted to HW to ensure that a context is loaded for powersaving. Let's wait for this submission via a tasklet to complete before we drop our forcewake, ensuring the system is ready for rc6 before we let it possibly sleep. Signed-off-by:
-
Chris Wilson authored
Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0xffffffff_ffffffff] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x000001f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x000002a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x000002a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x00000f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x00000260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x000002a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x00000001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x00000300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fffffefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x00000000_0000609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x00000000_0000609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x00000000_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x00000000 <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x02800000 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 00000002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8 <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2 <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3 <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2 <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4 <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! The RING_MODE indicates that is idle and has the STOP_RING bit set, so try clearing it. v2: Only clear the bit on restarting the ring, as we want to be sure the STOP_RING bit is kept if reset fails on wedging. v3: Spot when the ring state doesn't make sense when re-initialising the engine and dump it to the logs so that we don't have to wait for an error later and try to guess what happened earlier. v4: Prepare to print all the unexpected state, not just the first. Signed-off-by:
-
Tvrtko Ursulin authored
This is to avoid an error with structure declared in parameter list if the include ordering changes. Signed-off-by:
-
Tvrtko Ursulin authored
struct i915_gem_context embeds struct i915_sched_attr so needs to include the respective header. Signed-off-by:
-
- 24 May, 2018 6 commits
-
-
Chris Wilson authored
We were not very carefully checking to see if an older request on the engine was an earlier switch-to-kernel-context before deciding to emit a new switch. The end result would be that we could get into a permanent loop of trying to emit a new request to perform the switch simply to flush the existing switch. What we need is a means of tracking the completion of each timeline versus the kernel context, that is to detect if a more recent request has been submitted that would result in a switch away from the kernel context. To realise this, we need only to look in our syncmap on the kernel context and check that we have synchronized against all active rings. v2: Since all ringbuffer clients currently share the same timeline, we do have to use the gem_context to distinguish clients. As a bonus, include all the tracing used to debug the death inside suspend. v3: Test, test, test. Construct a selftest to exercise and assert the expected behaviour that multiple switch-to-contexts do not emit redundant requests. Reported-by:
-
Dhinakaran Pandiyan authored
While touching the code around this, I noticed that absence of ALPM capability does not stop us from enabling PSR2. But, the spec unambiguously states that ALPM is required for PSR2 and so does this commit that introduced this code drm/i915/psr: enable ALPM for psr2 As per edp1.4 spec , alpm is required for psr2 operation as it's used for all psr2 main link power down management and alpm enable bit must be set for psr2 operation. Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by:Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by:
Tarun Vyas <tarun.vyas@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Noticed that we assume the best case of 0 latency when the DPCD read fails, reasonable pessimism is safer. eDP spec does say that if latency is greater than 8, the panel supplier needs to provide it. I didn't see anything specific in the VBT for this, so let's go with 8 frames as a fallback. Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
intel_dp->psr_dpcd already has the required values. Cc: Jose Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
By moving the check from psr_compute_config() to psr_init_dpcd(), we get to set the dev_priv->psr.sink_support flag only when the panel is capable of changing power state. An additional benefit is that the check will be performed only at init time instead of every atomic_check. This should change the psr_basic IGT failures on HSW to skips. v2: Return early when SET_POWER_CAPABLE bit is 0 (Jose) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106217 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106346 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Ville noticed that we are unncessarily reading DPCD's after knowing panel did not support PSR. Looks like this check that was present earlier got removed unintentionally, let's put it back. While we do this, add the PSR version number in the debug print. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
