- 25 Oct, 2019 8 commits
-
-
Ville Syrjälä authored
The change to skip the PCH reference initialization during fastboot did end up breaking FDI. To fix that let's try to do the PCH reference init whenever we're disabling a DPLL that was using said reference previously. Cc: stable@vger.kernel.org Tested-by:
Andrija <akijo97@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112084 Fixes: b16c7ed9 ("drm/i915: Do not touch the PCH SSC reference if a PLL is using it") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022185643.1483-1-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Chris Wilson authored
The parallel switch test has an underlying assumption that its requests are executed in order of submission, which is only true if the backend manages to keep up. Ensure the order of execution matches the submission order by explicit dependencies and so when we wait on the last request, we know we wait on completion of the entire queue. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016225730.29447-1-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
Intel_lrc.c is the only caller and so to avoid some header file ordering issues in future patches move these two over there. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Anna Karas authored
Replace PLLs names used in documentation to that used in the code. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Fixes: 68ff39c3 ("drm/i915/tgl: Add new pll ids") Signed-off-by:
Anna Karas <anna.karas@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Anna Karas authored
Add description of wakeref member of intel_shared_dpll structure to documentation. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Anna Karas authored
Update header files containing i915_perf_stream, i915_perf_stream_ops and i915_oa_ops definitions since they have been moved from i915_drv.h to i915_perf_types.h. Cc: Robert Bragg <robert@sixbynine.org> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Chris Wilson authored
BAT is growing a little fat and CI is under pressure and needs to trim off some redundant runtime. An easy option is to reduce the selftest runtimes, so try halving our default subtest timeout. While this reduces the number of iterations used, for the majority of tests that are passing, repeat runs (with different CI_DRM) will make up the difference -- a negative consequence though is that we may reduce the frequency of sporadic failures. Hopefully, we have no tests that were crucially dependent on the previous 1s timeout... Suggested-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191025092749.13468-1-chris@chris-wilson.co.uk
-
José Roberto de Souza authored
Right now if sink reported any PSR error or if it fails to acknowledge the PSR wakeup it sets a flag and do not attempt to enable PSR anymore. That is the safest approach to avoid repetitive glitches and allowed us to have PSR enabled by default. But from time to time even good PSR panels have a PSR error, causing tests to fail. And for now we are not yet to the point were we could try to recover from PSR errors, so lets add this information to the debugfs so IGT can check if PSR is disabled because of sink errors or not and eliminate this noise from CI runs. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ap Kamal <kamal.ap@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023214932.94679-1-jose.souza@intel.com
-
- 24 Oct, 2019 19 commits
-
-
Matt Roper authored
Gen11+ has more hardware planes than gen9 so we need to test additional pipe interrupt register bits to recognize any GTT faults that happen on these extra planes. Bspec: 50335 Signed-off-by:
-
Tapani Pälli authored
As with commit 3fe0107e, this change fixes multiple tests that are using the invocation counts. Documentation doesn't list the workaround for TGL but applying it fixes the tests. Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Acked-by:
-
Mika Kuoppala authored
On testing the whitelists, using any of the nonpriv flags when trying to access the register offset will lead to failure. Define address mask to get the mmio offset in order to guard against any current and future flag usage. v2: apply also on scrub_whitelisted_registers (Lionel) Cc: Tapani Pälli <tapani.palli@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Ap Kamal authored
'Link CRC error' will now have same error level as other PSR2 errors like 'RFB storage error' and 'VSC SDP uncorrectable error'. Signed-off-by:
Ap Kamal <kamal.ap@intel.com> Reviewed-by:
-
Ville Syrjälä authored
snb supports fp16 pixel formats on the sprite planes. Expose that capability. Nothing special needs to be done, it just works. v2: Rebase on top of icl fp16 Split snb+ sprite bits into a separate patch Reviewed-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
ivb+ supports fp16 pixel formats on the sprite planes planes. Expose that capability. On ivb/hsw fp16 scanout is slightly busted. The output from the plane will have 1/4 the expected value. For the sprite plane we can fix that up with the plane gamma unit. This was fixed on bdw. v2: Rebase on top of icl fp16 Split the ivb+ sprite birs into a separate patch v3: Move ivb_need_sprite_gamma() check one level up so that we don't waste time programming garbage into he gamma registers Reviewed-by: -
Ville Syrjälä authored
gen4+ supports fp16 pixel formats on the primary planes. Add the relevant code. On ivb fp16 scanout is slightly busted. The output from the plane will have 1/4 the expected value. For the primary plane we would have to use the pipe gamma or pipe csc to correct that which would affect all the other planes as well, hence we simply choose not to expose fp16 on the ivb primary plane. On hsw the primary plane got fixed. On gmch platforms I observed that the plane width must be below 2k pixels with fp16 or else we get a corrupted image. This limitation does not seem to be documented in bspec. I verified the exact limit using the chv pipe B primary plane since it has windowing capability. The stride limits are unaffected by fp16. v2: Rebase on top of icl fp16 Split thea gen4+ primary plane bits into a separate patch Deal with HAS_GMCH() Reviewed-by: -
Ville Syrjälä authored
skl+ supports fp16 pixel formats on all universal planes. Add the necessary bits to expose that capability. The main different to icl is that we can't scale fp16, so need to add the relevant checks. v2: Rebase on top of icl fp16 Split skl+ bits into a separate patch Reviewed-by: -
Ville Syrjälä authored
Now that the planes declare their minimum cdclk requirements properly we don't need to check the cdclk in skl_max_scale() anymore. Just check against the maximum downscale ratio, and move the code next to it's only caller. v2: Add a comment explaining the HQ vs. not thing Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
The normal cdclk handling now takes care of making sure the plane's pixel rate doesn't exceed the spec appointed percentage of the cdclk frequency. Thus we can nuke skl_check_pipe_max_pixel_rate(). Reviewed-by:
-
Ville Syrjälä authored
Various pixel formats and plane scaling impose additional constraints on the cdclk frequency. Provide a new plane->min_cdclk() hook that will be used to compute the minimum acceptable cdclk frequency for each plane. Annoyingly on some platforms the numer of active planes affects this calculation so we must also toss in more planes into the state when the number of active planes changes. The sequence of state computation must also be changed: 1. check_plane() (updates plane's visibility etc.) 2. figure out if more planes now require update min_cdclk computaion 3. calculate the new min cdclk for each plane in the state 4. if the minimum of any plane now exceeds the current logical cdclk we recompute the cdclk 4. during cdclk computation take the planes' min_cdclk into accoutn 5. follow the normal cdclk programming to change the cdclk frequency. This may now require a modeset (except on bxt/glk in some cases), which either succeeds or fails depending on whether userspace has given us permission to perform a modeset or not. v2: Fix plane id check in intel_crtc_add_planes_to_state() Only print the debug message when cdclk needs bumping Use dev_priv->cdclk... as the old state explicitly Reviewed-by: -
Ville Syrjälä authored
check_digital_port_conflicts() is done needlessly late. Move it earlier. This will be needed as later on we want to set any_ms=true a bit later for non-modesets too and we can't call this guy without the connection_mutex held. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
So far we've sort of protected the global state under dev_priv with the connection_mutex. I wan to change that so that we can change the cdclk even for pure plane updates. To that end let's formalize the protection of the global state to follow what I started with the cdclk code already (though not entirely properly) such that any crtc mutex will suffice as a read lock, and all crtcs mutexes act as the write lock. We'll also pimp intel_atomic_state_clear() to clear the entire global state, so that we don't accidentally leak stale information between the locking retries. As a slight optimization we'll only lock the crtc mutexes to protect the global state, however if and when we actually have to poke the hw (eg. if the actual cdclk changes) we must serialize commits across all crtcs so that a parallel nonblocking commit can't get ahead of the cdclk reprogamming. We do that by adding all crtcs to the state. TODO: the old global state examined during commit may still be a problem since it always looks at the _latest_ swapped state in dev_priv. Need to add proper old/new state for that too I think. v2: Remeber to serialize the commits if necessary Signed-off-by:
-
Ville Syrjälä authored
To make the logs a bit less confusing let's toss in some debug prints to indicate whether the cdclk reprogramming is going to happen with a single pipe active or whether we need to turn all pipes off for the duration. Signed-off-by:
-
Anna Karas authored
Add missing descriptions of i915_perf_stream structure members to documentation. Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Robert Bragg <robert@sixbynine.org> Signed-off-by:
-
Chris Wilson authored
Split the legacy submission backend from the common CS ring buffer handling. Signed-off-by:
-
Tvrtko Ursulin authored
One more thing which relied on implicit dev_priv can be covnerted to use the new mmio accessors. Signed-off-by:
-
Chris Wilson authored
Make trebly sure that all possible callbacks and their delayed brethren are complete before asserting that the i915_active should be idle after flushing all barriers. Signed-off-by:
-
Chris Wilson authored
When setting up the system to perform the atomic reset, we need to serialise with any ongoing interrupt tasklet or else: <0> [472.951428] i915_sel-4442 0d..1 466527056us : __i915_request_submit: rcs0 fence 11659:2, current 0 <0> [472.951554] i915_sel-4442 0d..1 466527059us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes <0> [472.951681] i915_sel-4442 0d..1 466527061us : trace_ports: rcs0: submit { 11659:2, 0:0 } <0> [472.951805] i915_sel-4442 0.... 466527114us : __igt_atomic_reset_engine: i915_reset_engine(rcs0:active) under hardirq <0> [472.951932] i915_sel-4442 0d... 466527115us : intel_engine_reset: rcs0 flags=11d <0> [472.952056] i915_sel-4442 0d... 466527117us : execlists_reset_prepare: rcs0: depth<-1 <0> [472.952179] i915_sel-4442 0d... 466527119us : intel_engine_stop_cs: rcs0 <0> [472.952305] <idle>-0 1..s1 466527119us : process_csb: rcs0 cs-irq head=3, tail=4 <0> [472.952431] i915_sel-4442 0d... 466527122us : __intel_gt_reset: engine_mask=1 <0> [472.952557] <idle>-0 1..s1 466527124us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000 <0> [472.952683] <idle>-0 1..s1 466527130us : trace_ports: rcs0: promote { 11659:2*, 0:0 } <0> [472.952808] i915_sel-4442 0d... 466527131us : execlists_reset: rcs0 <0> [472.952933] i915_sel-4442 0d..1 466527133us : process_csb: rcs0 cs-irq head=3, tail=4 <0> [472.953059] i915_sel-4442 0d..1 466527134us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000 <0> [472.953185] i915_sel-4442 0d..1 466527136us : trace_ports: rcs0: preempted { 11659:2*, 0:0 } <0> [472.953310] i915_sel-4442 0d..1 466527150us : assert_pending_valid: Nothing pending for promotion! <0> [472.953436] i915_sel-4442 0d..1 466527158us : process_csb: process_csb:1930 GEM_BUG_ON(!assert_pending_valid(execlists, "promote")) We have the same CSB events being seen by process_csb() on two different processors. One being issued by the reset in the test, the other by the interrupt; this scenario is supposed to be prevented by flushing the interrupt tasklet with tasklet_disable() before we enter the atomic reset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112069Signed-off-by:
-
- 23 Oct, 2019 12 commits
-
-
Zhenyu Wang authored
As early workload scan and shadow happens in execlist mmio handler, which has already taken vgpu_lock. So remove extra lock taking here. Fixes: 952f89f0 ("drm/i915/gvt: Wean off struct_mutex") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
Replace sampling the engine state every so often with a periodic heartbeat request to measure the health of an engine. This is coupled with the forced-preemption to allow long running requests to survive so long as they do not block other users. Signed-off-by:
Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by:
-
Chris Wilson authored
Normally, we rely on our hangcheck to prevent persistent batches from hogging the GPU. However, if the user disables hangcheck, this mechanism breaks down. Despite our insistence that this is unsafe, the users are equally insistent that they want to use endless batches and will disable the hangcheck mechanism. We are looking at replacing hangcheck, in the next patch, with a softer mechanism, that sends a pulse down the engine to check if it is well. We can use the same preemptive pulse to flush an active context off the GPU upon context close, preventing resources being lost and unkillable requests remaining on the GPU after process termination. Testcase: igt/gem_ctx_exec/basic-nohangcheck Signed-off-by:
-
Chris Wilson authored
On schedule-out (CS completion) of a banned context, scrub the context image so that we do not replay the active payload. The intent is that we skip banned payloads on request submission so that the timeline advancement continues on in the background. However, if we are returning to a preempted request, i915_request_skip() is ineffective and instead we need to patch up the context image so that it continues from the start of the next request. v2: Fixup cancellation so that we only scrub the payload of the active request and do not short-circuit the breadcrumbs (which might cause other contexts to execute out of order). v3: Grammar pass Signed-off-by:
-
Chris Wilson authored
If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging unresponsive contexts more frequently (i.e. instead of using an ~10s hangcheck, we now evict at ~100ms). The challenge of lies in picking a timeout that can be reasonably serviced by HW for typical workloads, balancing the existing clients against the needs for responsiveness. Note that coupled with timeslicing, this will lead to rapid GPU "hang" detection with multiple active contexts vying for GPU time. The forced preemption mechanism can be compiled out with ./scripts/config --set-val DRM_I915_PREEMPT_TIMEOUT 0 Signed-off-by:
-
Chris Wilson authored
If we are doing a normal GPU reset triggered after detecting a long period of stalled work, we can take our time and allow the engines to quiesce. Since we've stopped submission to the engine, and if we wait long enough an innocent context should complete, leaving the engine idle. So by waiting a short amount of time, we should prevent clobbering other users when resetting a stuck context. Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by:
-
Robert M. Fosha authored
GuC enable logging H2G action definition changed some time ago from 0xE000 to 0x40. All current GuC FW blobs use this definition, so fix the action definition in driver to match. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Robert M. Fosha <robert.m.fosha@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Robert M. Fosha authored
Creating and opening the GuC log relay file enables and starts the relay potentially before the caller is ready to consume logs. Change the behavior so that relay starts only on an explicit call to the write function (with a value of '1'). Other values flush the log relay as before. v2: Style changes and fix typos. Add guc_log_relay_stop() function. (Daniele) Cc: Matthew Brost <matthew.brost@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Imre Deak authored
Atm we don't detect a PCH with PCI ID 0xA3C1 which showed up now on a CML platform. We don't have the official assignment of the PCH PCI IDs, but this looks like a CNP which was already used on CML platforms. Let's add the new ID->PCH type mapping accordingly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051Reported-and-tested-by:
Cyrus <cyrus.lien@canonical.com> Cc: Cyrus <cyrus.lien@canonical.com> Signed-off-by:
-
Jani Nikula authored
DSC isn't DP specific, so remove the dp_ prefix from the crtc state member name. Also moving the member under the dsc sub-struct gives us enough context to allow shortening the name to just config. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022133414.8293-2-jani.nikula@intel.com
-
Jani Nikula authored
Reduce verbosity in code by renaming dsc_params member of crtc state to simply dsc. There is enough context for this to be clear. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Chris Wilson authored
A lock once taken must be released again. Fixes: c31c9e82 ("drm/i915/selftests: Teach switch_to_context() to use the context") Signed-off-by:
-
- 22 Oct, 2019 1 commit
-
-
Chris Wilson authored
If retirement is running on another thread, we may inspect the status of the i915_active before its retirement callback is complete. As we expect it to be running synchronously, we can wait for any callback to complete by acquiring the i915_active.mutex. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022112111.9317-1-chris@chris-wilson.co.uk
-
