- 16 May, 2020 2 commits
-
-
Nathan Chancellor authored
When CONFIG_DRM_I915_DEBUG_GEM is not set, clang warns: drivers/gpu/drm/i915/gvt/scheduler.c:884:1: warning: function 'check_shadow_context_ppgtt' is not needed and will not be emitted [-Wunneeded-internal-declaration] check_shadow_context_ppgtt(struct execlist_ring_context *c, struct intel_vgpu_mm *m) ^ 1 warning generated. This warning is similar to -Wunused-function but rather than warning that the function is completely unused, it warns that it is used in some expression within the file but that expression will be evaluated to a constant or be optimized away in the final assembly, essentially making it appeared used but really isn't. Usually, this happens when a function or variable is only used in sizeof, where it will appear to be used but will be evaluated at compile time and not be required to be emitted. In this case, the function is only used in GEM_BUG_ON, which is defined as BUILD_BUG_ON_INVALID, which intentionally follows this pattern. To fix this warning, add __maybe_unused to make it clear that this is intentional depending on the configuration. Fixes: bec3df93 ("drm/i915/gvt: Support PPGTT table load command") Link: https://github.com/ClangBuiltLinux/linux/issues/1027Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
As we no longer use the shmemfs allocation directly, we do not expect to receive -ENOSPC from a backing store allocation. The potential sources for -ENOSPC are then our own internal eviction code, so the choice is either to kill the potential application with SIGBUS or to retry the faulthandler. In this patch we retry the fault handler, but since this is a should never happen condition, it is arguable that we gather up copious debug and kill the application. At worst, we cause an interruptible busy-wait, stalling the application -- all causes should be transient and the system should eventually recover. A small stall is hopefully a better outcome than random oomkiller. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200515200031.12034-1-chris@chris-wilson.co.uk
-
- 15 May, 2020 14 commits
-
-
Ville Syrjälä authored
Combine the two per-pipe dbuf debugs into one, and use the canonical [CRTC:%d:%s] style to identify the crtc. Also use the same style as the plane code uses for the ddb start/end, and prefix bitmask properly with 0x to make it clear they are in fact bitmasks. The "how many total slices we are going to use" debug we move to outside the crtc loop so it gets printed only once at the end. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-12-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Encapsulate the dbuf state more by moving the pre/post plane functions out from intel_display.c. We stick them into intel_pm.c since that's where the rest of the code lives for now. Eventually we should add a new file for this stuff at which point we also need to decide if it makes sense to even split the wm code from the ddb code, or to keep them together. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
skl_ddb_get_hw_state() is redundant and kinda called in thw wrong spot anyway. Just kill it. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add a global state to track the dbuf slices. Gets rid of all the nasty coupling between state->modeset and dbuf recomputation. Also we can now totally nuke state->active_pipe_changes. dev_priv->wm.distrust_bios_wm still remains, but that too will get nuked soon. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The low level dbuf slice code is rather inconsitent with its functiona naming and organization. Make it more consistent. Also share the enable/disable functions between all platforms since the same code works just fine for all of them. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Polish some of the dbuf code to give more meaningful debug messages and whatnot. Also we can switch over to the per-device debugs/warns at the same time. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe on icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's active or not). Let's make the behaviour consistent and always return 0 for any inactive pipe. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Arnd Bergmann authored
After the function is no longer marked 'inline', there is now a new warning pointing out that the only caller is inside of an #ifdef: drivers/gpu/drm/i915/display/intel_panel.c:493:12: warning: 'scale_user_to_hw' defined but not used [-Wunused-function] 493 | static u32 scale_user_to_hw(struct intel_connector *connector, | ^~~~~~~~~~~~~~~~ Move the function itself into that #ifdef as well. Fixes: 81b55ef1 ("drm/i915: drop a bunch of superfluous inlines") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Ville Syrjälä authored
Put the customary () around the macro argument in the overlay colorkey macros. And while at switch to using a consistent case for the hex constants. Signed-off-by:
-
Ville Syrjälä authored
We pass the plane data through the pipe gamma for all the other planes. Can't see why we should treat the overlay differently, so let's enable pipe gamma for it as well. Signed-off-by:
-
Ville Syrjälä authored
Put the overlay color conversion unit into 10bit mode if the pipe isn't using the 8bit legacy gamma. Not 100% sure this is what the intention of the bit was but makes at least some sense to me. Signed-off-by:
-
Ville Syrjälä authored
As with the video sprites the colorkey is always specified as 8bpc. For 10bpc primary plane formats we just ignore the two lsbs of each component. For C8 we'll replicate the same key to each chanel, which is what the hardware wants. Signed-off-by:
-
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:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 14 May, 2020 24 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 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
-
