- 15 May, 2020 2 commits
-
-
Ville Syrjälä authored
Apparently the 128x128 and 256x256 ARGB cursor modes were only added on LPT/CST. While the display section of bspec isn't super clear on the subject, it does highlight these two modes in a different color, has a few changlog entries indicating the 256x256 mode was added for a LPT DCN, and that the 128x128 mode was also added later (though no DCN/platform note there). The "device dependencies" bspec section does list the 256x256x32 as a new feature for LPT/CST, and goes on to mention that current hw only has the 64x64x32 mode (which reinforces the notion that the 128x128 mode was also added at the same time). Testing on actual hardware confirms all of this. CI shows all the 128x128 and 256x256 tests failing on GDG, and my ALV definitely doesn't like them. So we shall limit GDG/ALV to 64x64 only. And while at it let's adjust the mobile gen2 case to list the two platforms explicitly so that the if-ladder looks reasonably uniform. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-2-ville.syrjala@linux.intel.comAcked-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 14 May, 2020 26 commits
-
-
Joonas Lahtinen authored
To ensure cross-driver locking compatibility, document the expected guidelines for implementing the GEM locking in i915. Note that this is a description of how things should end up after being reworked, and does not reflect the current state of things. v2: Use rst note:: tag (Rodrigo) Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830105053.17491-1-joonas.lahtinen@linux.intel.com
-
Ville Syrjälä authored
Pull the code to do the CS timestamp ns<->ticks conversion into helpers and use them all over. The check in i915_perf_noa_delay_set() seems a bit dubious, so we switch it to do what I assume it wanted to do all along (ie. make sure the resulting delay in CS timestamp ticks doesn't exceed 32bits)? Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Ville Syrjälä authored
kHz isn't accurate enough for storing the CS timestamp frequency on some of the platforms. Store the value in Hz instead. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Ville Syrjälä authored
Bunch of places use a 64bit divisor needlessly. Switch to 32bit divisor. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
Flip the switch and enable SAGV support for Gen12 also. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid simultaneous legacy SAGV PCode requests and restricting qgv points. Put the actual restriction to commit function, added serialization(thanks to Ville) to prevent commit being applied out of order in case of nonblocking and/or nomodeset commits. v4: - Minor code refactoring, fixed few typos(thanks to James Ausmus) - Change the naming of qgv point masking/unmasking functions(James Ausmus). - Simplify the masking/unmasking operation itself, as we don't need to mask only single point per request(James Ausmus) - Reject and stick to highest bandwidth point if SAGV can't be enabled(BSpec) v5: - Add new mailbox reply codes, which seems to happen during boot time for TGL and indicate that QGV setting is not yet available. v6: - Increase number of supported QGV points to be in sync with BSpec. v7: - Rebased and resolved conflict to fix build failure. - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus) v8: - Don't report an error if we can't restrict qgv points, as SAGV can be disabled by BIOS, which is completely legal. So don't make CI panic. Instead if we detect that there is only 1 QGV point accessible just analyze if we can fit the required bandwidth requirements, but no need in restricting. v9: - Fix wrong QGV transition if we have 0 planes and no SAGV simultaneously. v10: - Fix CDCLK corruption, because of global state getting serialized without modeset, which caused copying of non-calculated cdclk to be copied to dev_priv(thanks to Ville for the hint). v11: - Remove unneeded headers and spaces(Matthew Roper) - Remove unneeded intel_qgv_info qi struct from bw check and zero out the needed one(Matthew Roper) - Changed QGV error message to have more clear meaning(Matthew Roper) - Use state->modeset_set instead of any_ms(Matthew Roper) - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used - Keep using crtc_state->hw.active instead of .enable(Matthew Roper) - Moved unrelated changes to other patch(using latency as parameter for plane wm calculation, moved to SAGV refactoring patch) v12: - Fix rebase conflict with own temporary SAGV/QGV fix. - Remove unnecessary mask being zero check when unmasking qgv points as this is completely legal(Matt Roper) - Check if we are setting the same mask as already being set in hardware to prevent error from PCode. - Fix error message when restricting/unrestricting qgv points to "mask/unmask" which sounds more accurate(Matt Roper) - Move sagv status setting to icl_get_bw_info from atomic check as this should be calculated only once.(Matt Roper) - Edited comments for the case when we can't enable SAGV and use only 1 QGV point with highest bandwidth to be more understandable.(Matt Roper) v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä) - Changed comment for zero new_mask in qgv points masking function to better reflect reality(Ville Syrjälä) - Simplified bit mask operation in qgv points masking function (Ville Syrjälä) - Moved intel_qgv_points_mask closer to gen11 SAGV disabling, however this still can't be under modeset condition(Ville Syrjälä) - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask (Ville Syrjälä) - Extracted PCode changes to separate patch.(Ville Syrjälä) - Now treat num_planes 0 same as 1 to avoid confusion and returning max_bw as 0, which would prevent choosing QGV point having max bandwidth in case if SAGV is not allowed, as per BSpec(Ville Syrjälä) - Do the actual qgv_points_mask swap in the same place as all other global state parts like cdclk are swapped. In the next patch, this all will be moved to bw state as global state, once new global state patch series from Ville lands v14: - Now using global state to serialize access to qgv points - Added global state locking back, otherwise we seem to read bw state in a wrong way. v15: - Added TODO comment for near atomic global state locking in bw code. v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed with Jani Nikula. - Take bw_state_changed flag into use. v17: - Moved qgv point related manipulations next to SAGV code, as those are semantically related(Ville Syrjälä) - Renamed those into intel_sagv_(pre)|(post)_plane_update (Ville Syrjälä) v18: - Move sagv related calls from commit tail into intel_sagv_(pre)|(post)_plane_update(Ville Syrjälä) v19: - Use intel_atomic_get_bw_(old)|(new)_state which is intended for commit tail stage. v20: - Return max bandwidth for 0 planes(Ville) - Constify old_bw_state in bw_atomic_check(Ville) - Removed some debugs(Ville) - Added data rate to debug print when no QGV points(Ville) - Removed some comments(Ville) v21, v22, v23: - Fixed rebase conflict v24: - Changed PCode mask to use ICL_ prefix v25: - Resolved rebase conflict v26: - Removed redundant NULL checks(Ville) - Removed redundant error prints(Ville) v27: - Use device specific drm_err(Ville) - Fixed parenthesis ident reported by checkpatch Line over 100 warns to be fixed together with existing code style. Signed-off-by: -
Stanislav Lisovskiy authored
Starting from TGL we need to have a separate wm0 values for SAGV and non-SAGV which affects how calculations are done. v2: Remove long lines v3: Removed COLOR_PLANE enum references v4, v5, v6: Fixed rebase conflict v7: - Removed skl_plane_wm_level accessor from skl_allocate_pipe_ddb(Ville) - Removed sagv_uv_wm0(Ville) - can_sagv->use_sagv_wm(Ville) v8: - Moved tgl_crtc_can_enable_sagv function up(Ville) - Changed comment regarding pipe_wm usage(Ville) - Call intel_can_enable_sagv and tgl_compute_sagv_wm only for Gen12(Ville) - Some sagv debugs removed(Ville) - skl_print_wm_changes improvements(Ville) - Do assignment instead of memcpy in skl_pipe_wm_get_hw_state(Ville) v9: - Removed can_sagv variable(Ville) - Removed spurious line(Ville) - Changed u32 to unsigned int as agreed(Ville) - Assign sagv only for gen12 in skl_pipe_wm_get_hw_state(Ville) Signed-off-by: -
https://github.com/intel/gvt-linuxJoonas Lahtinen authored
gvt-next-2020-05-12 - Support PPGTT update via LRI cmd (Zhenyu) - Remove extra kmap for shadow ctx update (Zhenyu) - Move workload cleanup out of execlist handling code (Zhenyu) Signed-off-by:
-
Gwan-gyeong Mun authored
In order to use a common VSC SDP Colorimetry calculating code on PSR, it uses a new psr vsc sdp compute routine. Because PSR routine has its own scenario and timings of writing a VSC SDP, the current PSR routine needs to have its own drm_dp_vsc_sdp structure member variable on struct i915_psr. In order to calculate colorimetry information, intel_psr_update() function and intel_psr_enable() function extend a drm_connector_state argument. There are no changes to PSR mechanism. v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp v4: Rebased v8: Rebased v10: When a PSR is enabled, it needs to add DP_SDP_VSC to infoframes.enable. It is needed for comparing between HW and pipe_state of VSC_SDP. v11: If PSR is disabled by flag, it don't enable psr on pipe compute. v12: Fix an inconsistent indenting Signed-off-by:Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-15-gwan-gyeong.mun@intel.com
-
Gwan-gyeong Mun authored
In order to use a common VSC SDP Colorimetry calculating code on PSR, it adds a compute routine for PSR VSC SDP. As PSR routine can not use infoframes.vsc of crtc state, it also adds new writing of DP SDPs (Secondary Data Packet) for PSR. PSR routine has its own scenario and timings of writing a VSC SDP. v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp v4: Use struct drm_device logging macros v10: 1) Fix packing of VSC SDP where Pixel Encoding/Colorimetry Format is not supported. 2) Change a checking of PSR state. Signed-off-by: -
Gwan-gyeong Mun authored
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp() to make sure not to send VSC SDP and HDR Metadata Infoframe SDP. v5: Polish commit message [Uma] Signed-off-by:
-
Gwan-gyeong Mun authored
Call intel_dp_set_infoframes() function on pipe updates to make sure that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable) on fastsets. Signed-off-by:
-
Gwan-gyeong Mun authored
Compared to implementation of DP and HDMI's encoder->infoframes_enabled, the lspcon's implementation returns its active state. (we expect enabled infoframe states of HW.) It leads to pipe state mismatch error when ddi_get_config is called. Because the current implementation of lspcon is not ready to support readout infoframes, we need to return 0 here. In order to support readout to lspcon, we need to implement read_infoframe and infoframes_enabled. And set_infoframes also have to set an appropriate bit on crtc_state->infoframes.enable Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Gwan-gyeong Mun authored
Added state readout for DP VSC SDP and enabled state validation for DP VSC SDP. v2: Minor style fix v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp v4: Use struct drm_device logging macros v10: Skip checking of VSC SDP when a crtc config has psr. Signed-off-by:
-
Gwan-gyeong Mun authored
Added state readout for DP HDR Metadata Infoframe SDP. v9: Rebased v10: Rebased Signed-off-by:
-
Gwan-gyeong Mun authored
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata Infoframe SDP), it replaces intel_dp_vsc_enable() function and intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes() function. And it removes unused functions. Before: intel_dp_vsc_enable() and intel_dp_hdr_metadata_enable() compute sdp configs and program sdp registers on enable callback of encoder. After: It separates computing of sdp configs and programming of sdp register. The compute config callback of encoder calls computing sdp configs. The enable callback of encoder calls programming sdp register. v3: Rebased v5: Polish commit message [Uma] v10: Rebased Signed-off-by:
-
Gwan-gyeong Mun authored
Dump out the DP VSC SDP in the normal crtc state dump v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp Use drm core's DP VSC SDP logging function Signed-off-by: -
Gwan-gyeong Mun authored
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump. HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata Infoframe SDP use the same member variable in infoframes of crtc state. Signed-off-by:
-
Gwan-gyeong Mun authored
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the normal crtc state dump. Signed-off-by:
-
Gwan-gyeong Mun authored
When receiving video it is very useful to be able to log DP VSC SDP. This greatly simplifies debugging. v2: Minor style fix v3: Move logging functions to drm core [Jani N] v5: Rebased v10: Rebased Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Gwan-gyeong Mun authored
It adds code to read the DP SDPs from the video DIP and unpack them into the crtc state. It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to unpack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_unpack(). And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A naming rule and style of intel_read_dp_sdp() function references intel_read_infoframe() function of intel_hdmi.c v2: Minor style fix v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp v4: Use struct drm_device logging macros v5: Addressed review comments from Uma - Polish commit message and comments - Combine the if checks of sdp.HB2 and sdp.HB3 - Add 6bpc to unpacking of VSC SDP Signed-off-by:
-
Gwan-gyeong Mun authored
It adds an unpack only function for DRM infoframe for dynamic range and mastering infoframe readout. It unpacks the information data block contained in the binary buffer into a structured frame of the HDMI Dynamic Range and Mastering (DRM) information frame. In contrast to hdmi_drm_infoframe_unpack() function, it does not verify a checksum. It can be used for unpacking a DP HDR Metadata Infoframe SDP case. DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe. But DP SDP header and payload structure are different from HDMI DRM Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of a verifying checksum. v9: Add clear comments to hdmi_drm_infoframe_unpack_only() and hdmi_drm_infoframe_unpack() (Laurent Pinchart) Signed-off-by: -
Chris Wilson authored
The second try at staging the transfer of the breadcrumb. In part one, we realised we could not simply move to the second engine as we were only holding the breadcrumb lock on the first. So in commit 6c81e21a ("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we removed it from the first engine and marked up this request to reattach the signaling on the new engine. However, this failed to take into account that we only attach the breadcrumb if the new request is added at the start of the queue, which if we are transferring, it is because we know there to be a request to be signaled (and hence we would not be attached). In this attempt, we try to transfer the completed requests to the irq_worker on its rq->engine->breadcrumbs. This preserves the coupling between the rq and its breadcrumbs, so that i915_request_cancel_breadcrumb() does not attempt to manipulate the list under the wrong lock. v2: Code sharing is fun. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1862 Fixes: 6c81e21a ("drm/i915/gt: Stage the transfer of the virtual breadcrumb") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513074809.18194-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
While this does not appear to fix any issues, the backend itself knows when it wants to emit a breadcrumb, so let it make the final call. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513074809.18194-16-chris@chris-wilson.co.uk
-
Chris Wilson authored
By providing the default values configured into the kernel via sysfs, it is much more convenient for userspace to restore those sane defaults, or at least know what are considered good baseline. This is useful, for example, to cleanup after any failed userspace prior to commencing new jobs. /sys/class/drm/card0/engine/rcs0/ ├── capabilities ├── class ├── .defaults │ ├── heartbeat_interval_ms │ ├── max_busywait_duration_ns │ ├── preempt_timeout_ms │ ├── stop_timeout_ms │ └── timeslice_duration_ms ├── heartbeat_interval_ms ├── instance ├── known_capabilities ├── max_busywait_duration_ns ├── mmio_base ├── name ├── preempt_timeout_ms ├── stop_timeout_ms └── timeslice_duration_ms Signed-off-by:
Maciej Patelczyk <maciej.patelczyk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200514062905.28668-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Now that we have fast timeslicing on semaphores, we no longer need to prioritise none-semaphore work as we will yield any work blocked on a semaphore to the next in the queue. Previously with no timeslicing, blocking on the semaphore caused extremely bad scheduling with multiple clients utilising multiple rings. Now, there is no impact and we can remove the complication. Signed-off-by:
-
- 13 May, 2020 9 commits
-
-
Chris Wilson authored
These were used to set various timeouts for the reset procedure (deciding when the engine was dead, and even if the reset itself was not making forward progress). No longer used. Signed-off-by:
-
Chris Wilson authored
The initial-breadcrumb is used to mark the end of the awaiting and the beginning of the user payload. We verify that we do not start the user payload before all signaler are completed, checking our semaphore setup by looking for the initial breadcrumb being written too early. We also want to ensure that we do not add semaphore waits after we have already closed the semaphore section, an issue for later deferred waits. Signed-off-by:
-
Chris Wilson authored
Since there can only be one of in_fence/exec_fence, just use the single in_fence local. v2: Consolidate lookup Signed-off-by:
-
Nathan Chancellor authored
When building with clang: drivers/gpu/drm/i915/gt/gen8_ppgtt.c:392:24: warning: duplicate 'inline' declaration specifier [-Wduplicate-decl-specifier] declaration specifier [-Wduplicate-decl-specifier] static __always_inline inline void ^ include/linux/compiler_types.h:138:16: note: expanded from macro 'inline' #define inline inline __gnu_inline __inline_maybe_unused notrace ^ 1 warning generated. __always_inline is defined as 'inline __attribute__((__always_inline))' so we do not need to specify it twice. Fixes: 84eac0c6 ("drm/i915/gt: Force pte cacheline to main memory") Link: https://github.com/ClangBuiltLinux/linux/issues/1024Reported-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
-
Chris Wilson authored
It is possible for a residual tasklet to be pending execution as we resume (whether that's some prior test kicking off the tasklet, or if we are in a suspend/resume stress test). As such, we do not want that tasklet to execute in the middle of our sanitization, such that it sees the poisoned state. For example, <4>[ 449.386553] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 449.386555] CPU: 1 PID: 5115 Comm: i915_selftest Tainted: G U W 5.7.0-rc4-CI-CI_DRM_8472+ #1 <4>[ 449.386556] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4>[ 449.386585] RIP: 0010:process_csb+0x6bf/0x830 [i915] <4>[ 449.386588] Code: 00 48 c7 c2 10 bc 4c a0 48 c7 c7 d4 75 34 a0 e8 87 0e e6 e0 bf 01 00 00 00 e8 9d e0 e5 e0 31 f6 bf 09 00 00 00 e8 e1 ba d6 e0 <0f> 0b 8b 87 10 05 00 00 85 c0 0f 85 5f f9 ff ff 48 c7 c1 70 a5 4f <4>[ 449.386591] RSP: 0018:ffffc90000170ea0 EFLAGS: 00010297 <4>[ 449.386594] RAX: 0000000080000101 RBX: 0000000000000000 RCX: 0000000000000000 <4>[ 449.386596] RDX: ffff88849d5bc040 RSI: 0000000000000000 RDI: 0000000000000009 <4>[ 449.386598] RBP: ffffc90000170f00 R08: 0000000000000000 R09: 0000000000000000 <4>[ 449.386600] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88843ccea018 <4>[ 449.386602] R13: ffff88843ccea658 R14: ffff88843ccea640 R15: ffff88843ccea000 <4>[ 449.386605] FS: 00007f826a813300(0000) GS:ffff88849fe80000(0000) knlGS:0000000000000000 <4>[ 449.386607] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 449.386609] CR2: 0000560366b94280 CR3: 000000048ba02002 CR4: 0000000000760ee0 <4>[ 449.386611] PKRU: 55555554 <4>[ 449.386613] Call Trace: <4>[ 449.386616] <IRQ> <4>[ 449.386646] ? execlists_submission_tasklet+0xcf/0x140 [i915] <4>[ 449.386674] execlists_submission_tasklet+0x2f/0x140 [i915] <4>[ 449.386679] tasklet_action_common.isra.16+0x6c/0x1c0 <4>[ 449.386684] __do_softirq+0xdf/0x49e <4>[ 449.386687] irq_exit+0xba/0xc0 <4>[ 449.386690] smp_apic_timer_interrupt+0xb7/0x280 <4>[ 449.386693] apic_timer_interrupt+0xf/0x20 <4>[ 449.386695] </IRQ> <4>[ 449.386698] RIP: 0010:_raw_spin_unlock_irqrestore+0x49/0x60 <4>[ 449.386701] Code: c7 02 75 1f 53 9d e8 26 ab 75 ff bf 01 00 00 00 e8 7c a3 69 ff 65 8b 05 7d 9b 5c 7e 85 c0 74 0c 5b 5d c3 e8 09 aa 75 ff 53 9d <eb> df e8 ca 39 5b ff 5b 5d c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 <4>[ 449.386703] RSP: 0018:ffffc90000a6b950 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 <4>[ 449.386706] RAX: 0000000080000001 RBX: 0000000000000202 RCX: 0000000000000000 <4>[ 449.386708] RDX: ffff88849d5bc040 RSI: ffff88849d5bc900 RDI: ffffffff82386f12 <4>[ 449.386710] RBP: ffff88847d400f00 R08: ffff88849d5bc900 R09: 0000000000000000 <4>[ 449.386712] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffff0b0b <4>[ 449.386714] R13: 000000000000000c R14: ffff88847d40bf70 R15: ffff88847d40cef8 <4>[ 449.386742] reset_csb_pointers+0x59/0x140 [i915] <4>[ 449.386769] execlists_sanitize+0x3e/0x60 [i915] <4>[ 449.386797] gt_sanitize+0xd6/0x260 [i915] As part of the reset preparation, engine->reset.prepare() prevents the tasklet from running, so pull the sanitization inside the critical section for reset. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1812 Fixes: 23122a4d ("drm/i915/gt: Scrub execlists state on resume") Signed-off-by:
-
Stanislav Lisovskiy authored
Seems that only skl needs to have SAGV turned off for multipipe scenarios, so lets do it this way. If anything blows up - we can always revert this patch. v2: Changed if condition to look better (Ville). Signed-off-by:
-
Stanislav Lisovskiy authored
Introduce platform dependent SAGV checking in combination with bandwidth state pipe SAGV mask. This is preparation to adding TGL support, which requires different way of SAGV checking. v2, v3, v4, v5, v6: Fix rebase conflict v7: - Nuke icl specific function, use skl for icl as well, gen specific active_pipes check to be added in the next patch(Ville) v8: - Use more generic intel_crtc_can_enable_sagv for checking(Ville) Signed-off-by: -
Stanislav Lisovskiy authored
For future Gen12 SAGV implementation we need to seemlessly alter wm levels calculated, depending on whether we are allowed to enable SAGV or not. So this accessor will give additional flexibility to do that. Currently this accessor is still simply working as "pass-through" function. This will be changed in next coming patches from this series. v2: - plane_id -> plane->id(Ville Syrjälä) - Moved wm_level var to have more local scope (Ville Syrjälä) - Renamed yuv to color_plane(Ville Syrjälä) in skl_plane_wm_level v3: - plane->id -> plane_id(this time for real, Ville Syrjälä) - Changed colorplane id type from boolean to int as index (Ville Syrjälä) - Moved crtc_state param so that it is first now (Ville Syrjälä) - Moved wm_level declaration to tigher scope in skl_write_plane_wm(Ville Syrjälä) v4: - Started to use enum values for color plane - Do sizeof for a type what we are memset'ing - Zero out wm_uv as well(Ville Syrjälä) v5: - Fixed rebase conflict caused by COLOR_PLANE_* enum removal v6: - Do not use skl_plane_wm_level accessor in skl_allocate_pipe_ddb v7: - Get rid of wm_uv, which is not used in skl_plane_write_wm(Ville) Signed-off-by: -
Chris Wilson authored
Upon gt resume, we first poison then sanitize the engine. However, our testing shows that gen9 will very rarely retain the poisoned value from the HWSP mappings of the execlists status registers. This suggests that it is reading back from the HWSP, so rejig the register reset. v2: Maybe RING_CONTEXT_STATUS_PTR is write masked. It is. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1812Signed-off-by:
-
- 12 May, 2020 2 commits
-
-
Swathi Dhanavanthri authored
This w/a is fixed in B0 stepping and needs to be restricted for A0 stepping only. Bspec: 33451 Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Chris Wilson authored
i915_gem_evict_something() is charged with finding a slot within the GTT that we may reuse. Since our goal is not to stall, we first look for a slot that only overlaps idle vma. To this end, on the first pass we move any active vma to the end of the search list. However, we only stopped moving active vma after we see the first active vma twice. If during the search, that first active vma completed, we would not notice and keep on extending the search list. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1746 Fixes: 2850748e ("drm/i915: Pull i915_vma_pin under the vm->mutex") Fixes: b1e3177b ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by:
-
- 11 May, 2020 1 commit
-
-
Chris Wilson authored
This reverts commit 0b718ba1. There are still some residual issues with asynchronous binding and execution, but since commit 92581f9f ("drm/i915: Immediately execute the fenced work") we prefer not to use asynchronous binds, and the remaining issues do not seem restricted to Cherryview [at least the ones seen over a few dozen CI runs, less frequent issues are sure to be discovered!] These issues seem to be mitigated, if not eliminated entirely, by the previous commit 84eac0c6 ("drm/i915/gt: Force pte cacheline to main memory"). Signed-off-by:
-
