aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-05-30drm/i915: Remove stale asserts from i915_gem_find_active_request()Chris Wilson1-9/+8
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: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to standalone") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]>
2018-05-29drm/i915/psr: Set idle frame count based on sink synchronization latencyDhinakaran Pandiyan1-20/+20
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 <[email protected]> Cc: Jose Roberto de Souza <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-29drm/i915/icl: Wa_1406463099Oscar Mateo2-2/+10
Prevents an error in the GAM unit. Also known as WaGamTlbPendError References: HSDES#1406463099 References: HSDES#1406465643 Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-29drm/i915/icl: WaEnableFloatBlendOptimizationOscar Mateo2-0/+6
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 <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-29drm/i915/icl: Wa_2006665173Oscar Mateo2-7/+16
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 <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-29drm/i915/icl: WaEnableStateCacheRedirectToCSOscar Mateo2-0/+5
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 <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-29drm/i915/icl: WaDisableImprovedTdlClkGatingOscar Mateo2-2/+10
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: Oscar Mateo <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-25drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.cMichal Wajdeczko1-65/+64
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: Michal Wajdeczko <[email protected]> Reviewed-by: Sagar Arun Kamble <[email protected]> Cc: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-25drm/i915: Simplify ilk-ivb underrun suppressionVille Syrjälä1-8/+4
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]>
2018-05-25drm/i915: Consult VBT "LVDS config" bits to determine whether internal LVDS ↵Ville Syrjälä3-5/+30
is present 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 <[email protected]> Cc: Ondrej Zary <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-25drm/i915: Try to suppress more spurious PCH underruns on ILK-IVBVille Syrjälä1-2/+9
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=106387 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Chris Wilson <[email protected]>
2018-05-25drm/i915: Initialize panel_pipe to INVALID_PIPEVille Syrjälä1-1/+1
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 <[email protected]> Suggested-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-25drm/i915: Prepare GEM for suspend earlierChris Wilson1-10/+37
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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: Ville Syrjälä <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]>
2018-05-25drm/i915/execlists: Wait for ELSP submission on restartChris Wilson2-1/+16
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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kuoppala <[email protected]>
2018-05-25drm/i915: Flush the ring stop bit after clearing RING_HEAD in resetChris Wilson1-0/+22
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: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-25drm/i915: Forward declare struct intel_contextTvrtko Ursulin1-0/+2
This is to avoid an error with structure declared in parameter list if the include ordering changes. Signed-off-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-25drm/i915: Include i915_scheduler.h from i915_gem_context.hTvrtko Ursulin1-0/+1
struct i915_gem_context embeds struct i915_sched_attr so needs to include the respective header. Signed-off-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915: Look for an active kernel context before switchingChris Wilson6-15/+231
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: Mika Kuoppala <[email protected]> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: Fix ALPM cap check for PSR2Dhinakaran Pandiyan1-10/+10
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 <[email protected]> Cc: Vathsala Nagaraju <[email protected]> Reviewed-by: Vathsala Nagaraju <[email protected]> Reviewed-by: Tarun Vyas <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: Fall back to max. synchronization latency if DPCD read failsDhinakaran Pandiyan1-2/+2
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 <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: Avoid unnecessary DPCD read of DP_PSR_CAPSDhinakaran Pandiyan1-10/+1
intel_dp->psr_dpcd already has the required values. Cc: Jose Roberto de Souza <[email protected]> Reviewed-by: Tarun Vyas <[email protected]> Reviewed-by: Vathsala Nagaraju <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: Check for SET_POWER_CAPABLE bit at PSR init time.Dhinakaran Pandiyan2-8/+11
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 <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: Avoid DPCD reads when panel does not support PSRDhinakaran Pandiyan1-6/+8
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ä <[email protected]> Reviewed-by: Tarun Vyas <[email protected]> Reviewed-by: Vathsala Nagaraju <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: Nuke PSR support for VLV and CHVDhinakaran Pandiyan6-270/+27
PSR hardware and hence the driver code for VLV and CHV deviates a lot from their DDI counterparts. While the feature has been disabled for a long time now, retaining support for these platforms is a maintenance burden. There have been multiple refactoring commits to just keep the existing code for these platforms in line with the rest. There are known issues that need to be fixed to enable PSR on these platforms, and there is no PSR capable platform in CI to ensure the code does not break again if we get around to fixing the existing issues. On account of all these reasons, let's nuke this code for now and bring it back if a need arises in the future. Cc: Jani Nikula <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Ville Syrjälä <[email protected]> Acked-by: Jani Nikula <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/psr: vbt change for psrVathsala Nagaraju4-27/+72
For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt structure. Since spec does not mention from which VBT version this change was added to vbt.bsf file, we cannot depend on bdb->version check to change for all the platforms. There is RCR inplace for GOP team to provide the version number to make generic change. Since Kabylake with bdb version 209 is having this change, limiting this change to gen9_bc and version 209+ to unblock google. Tested on skl(bdb version 203,without options) and kabylake(bdb version 209,212) having new options. bspec 20131 v2: (Jani and Rodrigo) move the 165 version check to intel_bios.c v3: Jani Move the abstraction to intel_bios. v4: Jani Rename tp*_wakeup_time to have "us" suffix. For values outside range[0-3],default to max 2500us. Old decimal value was wake up time in multiples of 100us. v5: Jani and Rodrigo Handle option 2 in default condition. Print oustide range value. For negetive values default to 2500us. v6: Jani Handle default first and then fall through for case 2. v7: Rodrigo Apply this change for IS_GEN9_BC and vbt version > 209 v8: Puthik Add new function vbt_psr_to_us. v9: Jani Change to v7 version as it's more readable. DK add comment /*fall through*/ after case2. Cc: Rodrigo Vivi <[email protected]> Cc: Puthikorn Voravootivat <[email protected]> Cc: Dhinakaran Pandiyan <[email protected]> Cc: Jani Nikula <[email protected]> Cc: José Roberto de Souza <[email protected]> Signed-off-by: Maulik V Vaghela <[email protected]> Signed-off-by: Vathsala Nagaraju <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReadsYunwei Zhang2-0/+39
L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0 instead of correct values. However, this is not going to be the case in any production silicon. Therefore, we only check at initialization and issue a warning should this really happen. References: HSDES#1405586840 v2: - use fls instead of find_last_bit (Chris) - use is_power_of_2() instead of counting bit set (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Move local variable into scope where they are used (Ursulin) - use a new local variable to reduce long line of code (Ursulin) v6: - Some coding style and use more local variables for clearer logic (Ursulin) Cc: Oscar Mateo <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Signed-off-by: Yunwei Zhang <[email protected]> Reviewed-by: Oscar Mateo <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/icl: Enable WaProgramMgsrForCorrectSliceSpecificMmioReadsYunwei Zhang2-3/+12
WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Icelake as well. References: HSD#1405586840, BSID#0575 v2: - GEN11 mask is different from its predecessors. (Oscar) - Better separate GEN10 and GEN11. (Oscar) Cc: Oscar Mateo <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Signed-off-by: Yunwei Zhang <[email protected]> Reviewed-by: Oscar Mateo <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-24drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReadsYunwei Zhang3-5/+54
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Moved WA explanation Comments(Oscar) - Rebased. v8: - Renamed sanitize_mcr to calculate_s_ss_select. (Oscar) - calculate s/ss selector instead of whole mcr. (Oscar) v9: - Updated function name (Oscar) - Remove redundant variables (Oscar) v10: - Separate pre-GEN10 and GEN11 mask. (Oscar) Cc: Oscar Mateo <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Signed-off-by: Yunwei Zhang <[email protected]> Reviewed-by: Oscar Mateo <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-23drm/i915/icl: Disable pipe CSC and gamma in cursor planeJosé Roberto de Souza1-4/+6
'Pipe CSC enable' bit is more than just deprecated in ICL+, it was disabled in commit 077ef1f09c25 ("drm/i915/icl: Don't set pipe CSC/Gamma in PLANE_COLOR_CTL") for primary and sprite planes as it was causing those planes to be rendered as always black but it was not disabled in cursor plane, also causing it to be rendered as black. As mentioned in the commit referenced above, this is a workaround too and the CSC and gamma per plane values needs to be setup before enable CSC and gamma again. BSpec: 4278 and 7635 Cc: James Ausmus <[email protected]> Cc: Paulo Zanoni <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-23drm/i915/selftests: Pin the mock kernel contextChris Wilson2-10/+14
The driver assumes that the kernel context is pinned and always available for use from any process or atomic context. Make it so for selftesting as well! Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-23drm/i915: WARN if power sequencer is not connected to the LVDS port on pre-ilkVille Syrjälä1-0/+5
We don't support using the power sequencer with other ports besides LVDS on pre-ilk platforms. WARN if someone has mistakenly connected the power sequencer to the wrong port. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-23drm/i915: Implement the missing bits of assert_panel_unlocked()Ville Syrjälä1-2/+16
Add the missing eDP port handling into assert_panel_unlocked(). We now have intel_dp_port_enabled() which makes this trivial. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-23drm/i915: Allow eDP on port C in theoryVille Syrjälä1-2/+12
The power sequencer has bits to allow DP C to be used for eDP. Currently we assume this will never happen, but I guess it could theoretically be a thing. Make the code do the right thing in that case, and toss in a MISSING_CASE() for any other port. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-23drm/i915: Clean up DP pipe select bitsVille Syrjälä4-95/+91
Clean up the DP pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state(), the port state asserts, and the VLV power sequencer code. v2: Return PIPE_A for cpt/ppt when the port isn't selected by any transcoder. Returning INVALID_PIPE explodes *somewhere* on some machines (can't immediately see where though). This now matches the old behaviour. v3: Order the defines shift,mask,value (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-23drm/i915: Nuke intel_trans_dp_port_sel()Ville Syrjälä1-25/+14
for_each_encoder_on_crtc() is legacy and shouldn't be used by atomic drivers. Let's throw out intel_trans_dp_port_sel() and replace it with intel_get_crtc_new_encoder() which looks the atomic state instead. Since we now have to call intel_get_crtc_new_encoder() during the commit phase we'll need to plumb in the top level atomic state. The crtc_state->state pointers are no longer valid at that point. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-23drm/i915: Parametrize TRANS_DP_PORT_SELVille Syrjälä2-21/+11
Parametrize the TRANS_DP_PORT_SEL macros. v2: WARN for bogus ports (Jani) Order the defines mask,value (Jani) Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-23drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi codeVille Syrjälä3-32/+30
The ddi code no longer uses intel_ddi_get_crtc_new_encoder(). Move it elsewhere where we have some users left. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22drm/i915/query: nospec expects no more than an unsigned longChris Wilson1-1/+4
nospec quite reasonably asserts that it will never be used with an index larger than unsigned long (that being the largest possibly index into an C array). However, our ubi uses the convention of u64 for any large integer, running afoul of the assertion on 32b. Reduce our index to an unsigned long, checking for type overflow first. drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl': include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) Reported-by: [email protected] Fixes: 84b510e22da7 ("drm/i915/query: Protect tainted function pointer lookup") Signed-off-by: Chris Wilson <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22drm/i915: Eliminate the unused dev_priv->vbt.lvds_vbtVille Syrjälä2-4/+0
dev_priv->vbt.lvds_vbt is set but never actually used. Kill it. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22drm/i915: Replace vbt edp.support with int_lvds_supportVille Syrjälä3-11/+13
Replace dev_priv->vbt.edp.support with dev_priv->vbt.int_lvds_support. We'll want to extend its use beyond the LVDS vs. eDP case in the future. v2: Nuke the edp.support from parse_edp() (Jani) Only clear int_lvds_support for gen5+ to preserve the current behaviour (Jani) Cc: Jani Nikula <[email protected]> Cc: Ondrej Zary <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2018-05-22drm/i915/gtt: Allow pagedirectory allocations to failChris Wilson1-8/+8
As we handle the allocation failure of the page directory and tables by propagating the failure back to userspace, allow it to fail if direct reclaim is unable to satisfy the request (i.e. disable the oomkiller). The premise being that if we are unable to allocate a single page for the pagetable, we will not be able to handle the multitude of pages required for the gfx operation and we should back off to allow the system to recover. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106609 Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22drm/i915/query: Protect tainted function pointer lookupChris Wilson1-3/+7
Smatch identifies i915_query_ioctl() as being a potential victim of Spectre due to its use of a tainted user index into a function pointer array. Use array_index_nospec() to defang the user index before using it to lookup the function pointer. Fixes: a446ae2c6e65 ("drm/i915: add query uAPI") Signed-off-by: Chris Wilson <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."Jani Nikula6-45/+8
This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e. Per the report, no matter what display mode you select with xrandr, the i915 driver will always select the alternate fixed mode. For the reporter this means that the display will always run at 40Hz which is quite annoying. This may be due to the mode comparison. But there are some other potential issues. The choice of alt_fixed_mode seems dubious. It's the first non-preferred mode, but there are no guarantees that the only difference would be refresh rate. Similarly, there may be more than one preferred mode in the probed modes list, and the commit changes the preferred mode selection to choose the last one on the list instead of the first. (Note that the probed modes list is the raw, unfiltered, unsorted list of modes from drm_add_edid_modes(), not the pretty result after a drm_helper_probe_single_connector_modes() call.) Finally, we already have eerily similar code in place to find the downclock mode for DRRS that seems like could be reused here. Back to the drawing board. Note: This is a hand-crafted revert due to conflicts. If it fails to backport, please just try reverting the original commit directly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469 Reported-by: Rune Petersen <[email protected]> Reported-by: Mark Spencer <[email protected]> Fixes: dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP if available.") Cc: Clint Taylor <[email protected]> Cc: David Weinehall <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Jim Bride <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.14+ Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Dhinakaran Pandiyan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22drm/i915: Move GEM BO inside drm_framebufferDaniel Stone2-4/+3
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. v2: Only hold a single reference per framebuffer, not per plane. (Ville) v3: Drop NULL check in intel_fb_obj. (Ville) Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-22drm/i915: Use intel_fb_obj() everywhereDaniel Stone3-15/+17
We already have a macro to pull the GEM object from a FB, so use it everywhere. We'll make use of this later to move the object storage. Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-21drm/i915/gvt: Fix crash after request->hw_context changeZhenyu Wang1-36/+16
When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context. v2: Move request alloc earlier as already try to track shadow status depending on request state, which also facilitate to use request->hw_context for target engine context reference. Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request") Cc: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Zhi Wang <[email protected]> Cc: Weinan Li <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-19drm/i915/selftests: Wait longer for the old active requestChris Wilson1-14/+34
When testing reset, we wait for 1s on the main thread for the hang to start. Meanwhile, we continue submitting requests on all the background threads, and we may have more threads than cores and so potentially starve the waiter from being woken within the timeout. As the hang timeout and the active timeouts are the same, it is hard to distinguish which caused the timeout. Bump the active thread timeouts to 5s, compared to the 1s timeout for the hang, so that we preferentially report the hang timing out, while hopefully ensuring that we do at least wake up the hang thread first before declaring the background active timeout. Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin <[email protected]>
2018-05-19drm/i915: Allow init_breadcrumbs to be used from irq contextChris Wilson1-2/+3
In order to support engine reset from irq (timer) context, we need to be able to re-initialise the breadcrumbs. So we need to promote the plain spin_lock_irq to a safe spin_lock_irqsave. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-19drm/i915/execlists: Handle copying default context state for atomic resetChris Wilson3-11/+20
We want to be able to reset the GPU from inside a timer callback (hardirq context). One step requires us to copy the default context state over to the guilty context, which means we need to plan in advance to have that object accessible from within an atomic context. The atomic context prevents us from pinning the object or from peeking into the shmemfs backing store (all may sleep), so we choose to pin the default_state into memory when the engine becomes active. This compromise allows us to swap out the default state when idle, when required. References: 5692251c254a ("drm/i915/lrc: Scrub the GPU state of the guilty hanging request") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-05-19drm/i915: Make intel_engine_dump irqsafeChris Wilson1-4/+7
To be useful later, enable intel_engine_dump() to be called from irq context (i.e. using saving and restoring irq start rather than assuming we enter with irqs enabled). Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.