- 04 Nov, 2019 10 commits
-
-
Ville Syrjälä authored
Let's try to keep the pixel format arrays somewhat sorted: 1. RGB before YUV 2. smaller bpp before larger bpp 3. X before A 4. RGB before BGR Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031165652.10868-7-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
ICL+ again supports alpha blending with 10bpc pixel formats. Expose them. v2: Add all the stuff I missed earlier! Signed-off-by:
-
Ville Syrjälä authored
VLV/CHV sprite planes also support the C8 format. Let's expose that. Signed-off-by:
-
Ville Syrjälä authored
CHV pipe B sprites gained support for the 10bpc X/ARGB pixel formats. On VLV and CHV pipe A/C these are only supported by the primary plane. Add the require bits to expose the new formats. v2: Reorder the formats for consistency Signed-off-by:
-
Ville Syrjälä authored
Currently we expose VLV/CHV alpha blending only on the sprite planes, but the primary planes can do it as well. Let's flip it on. v2: Rebase due to fp16 landing Signed-off-by:
-
Ville Syrjälä authored
SNB-BDW support 10:10:10 formats on the sprite planes. Let's expose them. v2: Rebase due to fp16 landing Signed-off-by:
-
Chris Wilson authored
Sometimes Icelake forgets to reset the CSB pointers on a GPU reset, leading to it carry on updating the old tail of the buffer. <0>[ 618.138490] i915_sel-5636 3d..1 673425465us : trace_ports: vecs0: submit { 14de2:504, 0:0 } <0>[ 618.138490] i915_sel-5636 3.... 673425493us : intel_engine_reset: vecs0 flags=100 <0>[ 618.138490] i915_sel-5636 3.... 673425493us : execlists_reset_prepare: vecs0: depth<-0 <0>[ 618.138490] i915_sel-5636 3.... 673425493us : intel_engine_stop_cs: vecs0 <0>[ 618.138490] i915_sel-5636 3.... 673425523us : __intel_gt_reset: engine_mask=40 <0>[ 618.138490] i915_sel-5636 3.... 673425568us : execlists_reset: vecs0 <0>[ 618.138490] i915_sel-5636 3d..1 673425568us : process_csb: vecs0 cs-irq head=1, tail=2 <0>[ 618.138490] i915_sel-5636 3d..1 673425568us : process_csb: vecs0 csb[2]: status=0x00000001:0x40000000 <0>[ 618.138490] i915_sel-5636 3d..1 673425569us : trace_ports: vecs0: promote { 14de2:504*, 0:0 } <0>[ 618.138490] i915_sel-5636 3d..1 673425570us : __i915_request_reset: vecs0 rq=14de2:504, guilty? yes <0>[ 618.138490] i915_sel-5636 3d..1 673425571us : __execlists_reset: vecs0 replay {head:2de0, tail:2e48} <0>[ 618.138490] i915_sel-5636 3d..1 673425572us : __i915_request_unsubmit: vecs0 fence 14de2:504, current 503 <0>[ 618.138490] i915_sel-5636 3.... 673435544us : intel_engine_cancel_stop_cs: vecs0 <0>[ 618.138490] i915_sel-5636 3.... 673435544us : process_csb: vecs0 cs-irq head=11, tail=11 <0>[ 618.138490] i915_sel-5636 3d..1 673435545us : __i915_request_submit: vecs0 fence 14de2:504, current 503 <0>[ 618.138490] i915_sel-5636 3d..1 673435546us : __execlists_submission_tasklet: vecs0: queue_priority_hint:-2147483648, submit:yes <0>[ 618.138490] i915_sel-5636 3d..1 673435548us : trace_ports: vecs0: submit { 14de2:504*, 0:0 } <0>[ 618.138490] i915_sel-5636 3.... 673435549us : execlists_reset_finish: vecs0: depth->0 <0>[ 618.138490] ksoftirq-21 2..s. 673435592us : process_csb: vecs0 cs-irq head=11, tail=3 <0>[ 618.138490] ksoftirq-21 2..s. 673435593us : process_csb: vecs0 csb[0]: status=0x00000001:0x40000000 <0>[ 618.138490] ksoftirq-21 2..s. 673435594us : trace_ports: vecs0: promote { 14de2:504*, 0:0 } <0>[ 618.138490] ksoftirq-21 2..s. 673435596us : process_csb: vecs0 csb[1]: status=0x00000018:0x40000040 <0>[ 618.138490] ksoftirq-21 2..s. 673435597us : trace_ports: vecs0: completed { 14de2:504*, 0:0 } <0>[ 618.138490] ksoftirq-21 2..s. 673435612us : process_csb: process_csb:2188 GEM_BUG_ON(!i915_request_completed(*execlists->active) && !reset_in_progress(execlists)) After the reset, we do another clflush before checking the CSB to be sure we see whatever was left in the CSB prior to the reset. So it is unlikely to be an incoherent view of the CSB, and more likely that Icelake didn't reset its pointers. References: 582a6f90 ("drm/i915/execlists: Add a paranoid flush of the CSB pointers upon reset") Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104135307.21083-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Add another for_each style macro to the pile of custom looping macros. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101134333.11612-1-jani.nikula@intel.com
-
Chris Wilson authored
Since the execlists_active() is no longer protected by the engine->active.lock, we need to protect the request pointer with RCU to prevent it being freed as we evaluate whether or not we need to preempt. Fixes: df403069 ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Fixes: 13ed13a4 ("drm/i915: Don't set queue_priority_hint if we don't kick the submission") Signed-off-by:
-
Chris Wilson authored
The counter is removed from the pm wakeref count, but it remains intact so that we can restore it upon resume. Ergo inside suspend, it may have a value. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Reviewed-by:
-
- 02 Nov, 2019 3 commits
-
-
Chris Wilson authored
Filter out warnings for the kernel context that is used to flush inactive contexts, as they do no not pose a risk. Signed-off-by:
-
Chris Wilson authored
Check that the context's ring register state still matches our expectations prior to execution. Signed-off-by:
-
Chris Wilson authored
Flushing the outer i915_active is not enough, as we need the barrier to be applied across all the active dma_fence callbacks. So we must serialise with each outstanding fence. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112096 References: f79520bb ("drm/i915/selftests: Synchronize checking active status with retirement") Signed-off-by:
-
- 01 Nov, 2019 25 commits
-
-
Chris Wilson authored
Avoid drivers/gpu/drm/i915/i915_perf.c:2442:85: warning: dubious: x | !y simply by inverting the predicate and reversing the ternary. v2: Move the long lines into their own function so there is no confusion on operator precedence. Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101192116.12647-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Call suspend_prepare first so that we don't leave GuC so confused. Signed-off-by:
-
Chris Wilson authored
Currently we shutdown rc6 during i915_gem_resume() but this is called during the preparation phase (i915_drm_prepare) for all suspend paths, but we only want to shutdown rc6 for S3+. Move the actual shutdown to i915_gem_suspend_late(). We then need to differentiate between suspend targets, to distinguish S0 (s2idle) where the device is kept awake but needs to be in a low power mode (the same as runtime suspend) from the device suspend levels where we lose control of HW and so must disable any HW access to dangling memory. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111909 Fixes: c1132367 ("drm/i915: Extract GT render sleep (rc6) management") Testcase: igt/gem_exec_suspend/power-S0 Signed-off-by:
-
Chris Wilson authored
We already track the debugfs user_forcewake on the GT, so it is natural to pull the suspend/resume handling under gt/ as well. Signed-off-by:
-
Chris Wilson authored
As we already do reload the kernel context in intel_gt_resume, repeating that action inside i915_gem_resume() as well is redundant. Signed-off-by:
-
Chris Wilson authored
Assume all responsibility for operating on the HW to sanitize the GT state upon load/resume in intel_gt_sanitize() itself. Signed-off-by:
-
Chris Wilson authored
Our timelines are currently contained within an intel_gt, and we only need to perform list/spinlock initialisation, so we can pull the intel_timelines_init() into our intel_gt_init_early(). Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101130406.4142-1-chris@chris-wilson.co.uk
-
Maarten Lankhorst authored
Now that we split plane_state which I didn't want to do yet, we can program the slave plane without requiring the master plane. This is useful for programming bigjoiner slave planes as well. We will no longer need the master's plane_state. Changes since v1: - set src/dst rectangles after copy_uapi_to_hw_state. Changes since v2: - Use the correct color_plane for pre-gen11 by using planar_linked_plane != NULL. - Use drm_format_info_is_yuv_semiplanar in skl_plane_check() to fix gen11+. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
Splitting plane state is easier than splitting crtc_state, before plane check we copy the drm properties to hw so we can do the same in bigjoiner later on. We copy the state after we did all the modeset handling, but fortunately i915 seems to be split correctly and nothing during modeset looks at plane_state. Changes since v1: - Do not clear hw state on duplication. Signed-off-by:
-
Maarten Lankhorst authored
Split up plane_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_plane_state *T; identifier x; @@ -T->base.x +T->uapi.x @@ struct intel_plane_state *T; @@ -T->base +T->uapi Signed-off-by:
-
Maarten Lankhorst authored
Split up plane_state->base to hw. This is done using the following patch: @@ struct intel_plane_state *T; identifier x =~ "^(crtc|fb|alpha|pixel_blend_mode|rotation|color_encoding|color_range)$"; @@ -T->base.x +T->hw.x Signed-off-by:
-
Maarten Lankhorst authored
get_crtc_from_states() is called before plane_state is copied to uapi, so use the uapi state there. intel_legacy_cursor_update() could probably get away with looking at the hw state, but for clarity always look at the uapi state. Changes since v1: - Convert entirety of intel_legacy_cursor_update (Ville). Signed-off-by:
-
Maarten Lankhorst authored
Prepare to split up hw and uapi machinally, by adding a uapi and hw alias. We will remove the base in a bit. This is a split from the original uapi/hw patch, which did it all in one go. Signed-off-by:
-
Maarten Lankhorst authored
Now that we separated everything into uapi and hw, it's time to make the split definitive. Remove the union and make a copy of the hw state on modeset and fastset. Color blobs are copied in crtc atomic_check(), right before color management is checked. Changes since v1: - Copy all blobs immediately after drm_atomic_helper_check_modeset(). - Clear crtc_state->hw on disable, instead of using clear_intel_crtc_state(). Changes since v2: - Use intel_crtc_free_hw_state + clear in intel_crtc_disable_noatomic(). - Make a intel_crtc_prepare_state() function that clears the crtc_state and copies hw members. - Remove setting uapi.adjusted_mode, we now have a direct call to drm_calc_timestamping_constants(). Changes since v3: - Rename prefix copy_hw_to_uapi_state() with intel_crtc. - Copy color blobs to uapi as well. - Add a intel_crtc_copy_uapi_to_hw_state_nomodeset() function for clarity. Changes since v4: - Copy hw.adjusted_mode back to uapi.adjusted_mode, to shut up the call to drm_calc_timestamping_constants() in drm_atomic_helper_update_legacy_modeset_state(). - Use drm_property_replace_blob (Ville). Changes since v5: - Use hw->mode in intel_modeset_readout_hw_state(). (Ville) - Copy to uapi.mode using drm_atomic_set_mode_for_crtc(). (Ville) Signed-off-by:
-
Maarten Lankhorst authored
Split up crtc_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_crtc_state *T; @@ -T->base +T->uapi Signed-off-by:
-
Maarten Lankhorst authored
Split up crtc_state->base to hw where appropriate. This is done using the following patch: @@ struct intel_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -T->base.x +T->hw.x @@ struct drm_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -to_intel_crtc_state(T)->base.x +to_intel_crtc_state(T)->hw.x Signed-off-by:
-
Maarten Lankhorst authored
intel_get_load_detect_pipe() needs to set uapi active, uapi enable is set by the call to drm_atomic_set_mode_for_crtc(), so we can remove it. intel_pipe_config_compare() needs to look at hw state, but I didn't change spatch to look at it. It's easy enough to do manually. intel_atomic_check() definitely needs to check for uapi enable, otherwise intel_modeset_pipe_config cannot copy uapi state to hw. Changes since v1: - Actually set uapi.active in get_load_detect_pipe(). Signed-off-by:
-
Maarten Lankhorst authored
Prepare to split up hw and uapi machinally, by adding a uapi and hw alias. We will remove the base in a bit. This is a split from the original uapi/hw patch, which did it all in one go. Signed-off-by:
-
Maarten Lankhorst authored
We are still looking at drm_crtc_state in a few places, convert those to use intel_crtc_state instead. Changes since v1: - Move to before uapi/hw split. - Add hunks for intel_pm.c as well. Changes since v2: - Incorporate Ville's feedback. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Chris Wilson authored
Vanshidhar Konda asked for the simplest test "to verify that the kernel can submit and hardware can execute batch buffers on all the command streamers in parallel." We have a number of tests in userspace that submit load to each engine and verify that it is present, but strictly we have no selftest to prove that the kernel can _simultaneously_ execute on all known engines. (We have tests to demonstrate that we can submit to HW in parallel, but we don't insist that they execute in parallel.) v2: Improve the igt_spinner support for older gen. Suggested-by:
Vanshidhar Konda <vanshidhar.r.konda@intel.com> Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
An interesting observation made with our parallel selftests was that on our small/single cpu systems we would call kthread_stop() before the kthreads were spawned. If this happens, the kthread is never run at all; completely bypassing the test. A simple yield() from the parent will ensure that all children have the opportunity to start before we reap them. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101084940.31838-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The i915_selftest module parameters only exist when CONFIG_DRM_I915_SELFTEST is set. Signed-off-by:
-
Chris Wilson authored
Don't just look at the very last request in a queue when deciding if we need to evict the context from the GPU, as that request may still be in the submission queue while the rest of the context is running! Instead, walk back along the queued requests looking for the active request and checking that. Fixes: 2e0986a5 ("drm/i915/gem: Cancel contexts when hangchecking is disabled") Testcase: igt/gem_ctx_persistence/queued Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:
-
- 31 Oct, 2019 2 commits
-
-
Matthew Auld authored
Intended for upstream testing so that we can still exercise the LMEM plumbing and !i915_ggtt_has_aperture paths. Smoke tested on Skull Canyon device. This works by allocating an intel_memory_region for a reserved portion of system memory, which we treat like LMEM. For the LMEMBAR we steal the aperture and 1:1 it map to the stolen region. To enable simply set the i915 modparam fake_lmem_start= on the kernel cmdline with the start of reserved region(see memmap=). The size of the region we can use is determined by the size of the mappable aperture, so the size of reserved region should be >= mappable_end. For now we only enable for the selftests. Depends on CONFIG_DRM_I915_UNSTABLE being enabled. eg. memmap=2G$16G i915.fake_lmem_start=0x400000000 v2: make fake_lmem_start an i915 modparam Signed-off-by:
-
José Roberto de Souza authored
Non-TC ports always have tc_mode == TC_PORT_TBT_ALT so it was switching aux to TBT mode for all combo-phy ports, happily this did not caused any issue but is better follow BSpec. Also this is reserved bit before ICL. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Fixes: e9b7e142 ("drm/i915: Sanitize the terminology used for TypeC port modes") Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191029011014.286885-1-jose.souza@intel.com
-
