aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-09-28drm/amdkfd: Fix a race condition of vram buffer unref in svm codeXiaogang Chen1-2/+9
prange->svm_bo unref can happen in both mmu callback and a callback after migrate to system ram. Both are async call in different tasks. Sync svm_bo unref operation to avoid random "use-after-free". Signed-off-by: Xiaogang Chen <[email protected]> Reviewed-by: Philip Yang <[email protected]> Reviewed-by: Jesse Zhang <[email protected]> Tested-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/display: Check all enabled planes in dm_check_crtc_cursorMichel Dänzer1-2/+12
It was only checking planes which had any state changes in the same commit. However, it also needs to check other enabled planes. Not doing this meant that a commit might spuriously "succeed", resulting in the cursor plane displaying with incorrect scaling. See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1824263 for an example. Fixes: d1bfbe8a3202 ("amd/display: check cursor plane matches underlying plane") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/display: Initialize writeback connectorAlex Hung4-2/+265
[WHAT] Create a drm_writeback_connector when connector signal equals SIGNAL_TYPE_VIRTUAL. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Move microcode init from sw_init to early_init for CIK SDMAMario Limonciello1-4/+5
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Move microcode init from sw_init to early_init for SDMA v2.4Mario Limonciello1-4/+5
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Move microcode init from sw_init to early_init for SDMA v3.0Mario Limonciello1-4/+5
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Move microcode init from sw_init to early_init for SDMA v5.2Mario Limonciello1-4/+5
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Move microcode init from sw_init to early_init for SDMA v6.0Mario Limonciello1-4/+5
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Move microcode init from sw_init to early_init for SDMA v5.0Mario Limonciello1-4/+5
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/display: Fix null pointer dereference in error messageCong Liu1-2/+1
This patch fixes a null pointer dereference in the error message that is printed when the Display Core (DC) fails to initialize. The original message includes the DC version number, which is undefined if the DC is not initialized. Fixes: 9788d087caff ("drm/amd/display: improve the message printed when loading DC") Signed-off-by: Cong Liu <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/display: Create one virtual connector in DCHarry Wentland2-3/+11
[WHAT] Prepare a virtual connector for writeback. Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Drop error message about failing to load SDMA firmwareMario Limonciello8-24/+8
The error path for SDMA firmware loading is unnecessarily noisy. When a firmware is missing 3 errors show up: ``` amdgpu 0000:07:00.0: Direct firmware load for amdgpu/green_sardine_sdma.bin failed with error -2 [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* Failed to load sdma firmware! [drm:amdgpu_device_init [amdgpu]] *ERROR* early_init of IP block <sdma_v4_0> failed -19 ``` The error code for the device init is bubbled up already, remove the second one. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/pm: fix the print_clk_levels issue for SMU v13.0.6Le Ma1-12/+12
Pass the correct size to smu_v13_0_6_print_clks, otherwise the same place in buf will be re-written. Signed-off-by: Le Ma <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/pm: deprecate allow_xgmi_power_down interfaceLe Ma5-43/+2
Replace with set_plpd_mode uniformly for places to use. Signed-off-by: Le Ma <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/pm: integrate plpd allow/disallow into select_xgmi_plpd_policy in ↵Le Ma3-28/+38
ppt level The allow_xgmi_power_down(true/false) will be generally replaced by: - allow: select_xgmi_plpd_policy(XGMI_PLPD_DEFAULT) - disallow: select_xgmi_plpd_policy(XGMI_PLPD_DISALLOW) Signed-off-by: Le Ma <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/pm: init plpd_mode properly for different asicsLe Ma1-0/+17
Assign DEFAULT mode if it supports plpd, otherwise keeps NONE v2: reduce ip version checks Signed-off-by: Le Ma <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/display: Remove unused DPCD declarationsStylon Wang1-58/+1
[Why & How] These DPCD addresses are either declared in other header files where it makes more sense or simply not used by any DC code. Remove them to reduce redundancies and potential confusion. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Stylon Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd/display: Skip entire amdgpu_dm build if !CONFIG_DRM_AMD_DCHarry Wentland1-5/+8
[WHY] Previously this only excluded build for a few amdgpu_dm binaries which makes no sense. [HOW] Wrap the entire Makefile in "ifneq ($(CONFIG_DRM_AMD_DC),)" Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28drm/amd: Limit seamless boot by default to APUsMario Limonciello1-0/+3
A hang is reported on DCN 3.2 with seamless boot enabled. As the benefits come from an eDP setup, limit it to only enabled by default with APUs. Suggested-by: [email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/amd-gfx/[email protected]/T/#m2887e919d7c01b2a4860d2261b366d22e070f309 Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-09-28vfio: use __aligned_u64 in struct vfio_device_gfx_plane_infoStefan Hajnoczi1-1/+1
The memory layout of struct vfio_device_gfx_plane_info is architecture-dependent due to a u64 field and a struct size that is not a multiple of 8 bytes: - On x86_64 the struct size is padded to a multiple of 8 bytes. - On x32 the struct size is only a multiple of 4 bytes, not 8. - Other architectures may vary. Use __aligned_u64 to make memory layout consistent. This reduces the chance of 32-bit userspace on a 64-bit kernel breakage. This patch increases the struct size on x32 but this is safe because of the struct's argsz field. The kernel may grow the struct as long as it still supports smaller argsz values from userspace (e.g. applications compiled against older kernel headers). Suggested-by: Jason Gunthorpe <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]>
2023-09-28drm/i915/fdi: Recompute state for affected CRTCs on FDI linksImre Deak3-0/+52
Recompute the state of all CRTCs on an FDI link during a modeset that may be affected by the modeset of other CRTCs on the same link. This ensures that each CRTC on the link maximizes its BW use (after another CRTC is disabled). In practice this means recomputing pipe B's config on IVB if pipe C gets disabled. v2: - Add the change recomputing affected CRTC states in a separate patch. (Ville) v3: (Ville) - Constify old and new crtc states. - Check for fused off pipe C. - Fix new vs. old crtc state mixup. - Drop check for pipe C's enabled state. Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915/fdi: Improve FDI BW sharing between pipe B and CImre Deak9-40/+140
At the moment modesetting pipe C on IVB will fail if pipe B uses 4 FDI lanes. Make the BW sharing more dynamic by trying to reduce pipe B's link bpp in this case, until pipe B uses only up to 2 FDI lanes. For this instead of the encoder compute config retry loop - which reduced link bpp only for the encoder's pipe - reduce the maximum link bpp for pipe B/C as required after all CRTC states are computed and recompute the CRTC states with the new bpp limit. Atm, all FDI encoder's compute config function returns an error if a BW constrain prevents increasing the pipe bpp value. The corresponding crtc_state->bw_constrained check can be replaced with checking crtc_state->max_link_bpp_x16, add TODO comments for this. SDVO is an exception where this case is only handled in the outer config retry loop, failing the modeset with a WARN, add a FIXME comment to handle this in the encoder code similarly to other encoders. v2: - Don't assume that a CRTC is already in the atomic state, while reducing its link bpp. - Add DocBook description to intel_fdi_atomic_check_link(). v3: - Enable BW management for FDI links in a separate patch. (Ville) v4: (Ville) - Fail the SDVO encoder config computation if it doesn't support the link bpp limit. - Add TODO: comments about checking link_bpp_x16 instead of bw_constrained. v5: - Replace link bpp limit check with a FIXME: comment in intel_sdvo_compute_config(). (Ville) Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> [Amended commit message wrt. changes in v5] Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915: Add helpers for BW management on shared display linksImre Deak7-5/+311
At the moment a modeset fails if the config computation of a pipe can't fit its required BW to the available link BW even though the limitation may be resolved by reducing the BW requirement of other pipes. To improve the above this patch adds helper functions checking the overall BW limits after all CRTC states have been computed. If the check fails the maximum link bpp for a selected pipe will be reduced and all the CRTC states will be recomputed until either the overall BW limit check passes, or further bpp reduction is not possible (because all pipes/encoders sharing the link BW reached their minimum link bpp). Atm, the MST encoder allocates twice the required BW for YUV420 format streams. A follow-up patchset will fix that, add a code comment about this. This change prepares for upcoming patches enabling the above BW management on FDI and MST links. v2: - Rename intel_crtc_state::max_link_bpp to max_link_bpp_x16 and intel_link_bw_limits::max_bpp to max_bpp_x16. (Jani) v3: - Add the helper functions in a separate patch. (Ville) - Add the functions to intel_link_bw.c instead of intel_atomic.c (Ville) - Return -ENOSPC instead of -EINVAL to userspace in case of a link BW limit failure. v4: - Make intel_atomic_check_config() static. v5: (Ville) - Rename intel_link_bw_limits::min_bpp_pipes to min_bpp_reached_pipes and intel_link_bw_reset_pipe_limit_to_min() to intel_link_bw_set_min_bpp_for_pipe(). - Rename pipe_bpp to link_bpp in intel_link_bw_reduce_bpp(). - Add FIXME: comment about MST encoder's YUV420 BW allocation and tracking the link bpp limit accordingly. v6: - Move intel_link_bw_compute_pipe_bpp() to intel_fdi.c (Ville) - WARN_ON(BIT(pipe) & min_bpp_reached_pipes) in intel_link_bw_set_bpp_limit_for_pipe(). (Ville) - Rename intel_link_bw_set_min_bpp_for_pipe() to intel_link_bw_set_bpp_limit_for_pipe() and intel_link_bw_limits::min_bpp_reached_pipes to bpp_limit_reached_pipes. (Ville) - Remove unused header includes. Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915: Factor out a helper to check/compute all the CRTC statesImre Deak1-32/+46
Factor out intel_atomic_check_config() to check and compute all the CRTC states. This will be used by a follow up patch to recompute/check the state until required by BW limitations between CRTCs. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915: Rename intel_modeset_all_pipes() to intel_modeset_all_pipes_late()Imre Deak4-7/+7
Rename intel_modeset_all_pipes() to intel_modeset_all_pipes_late() to clarify when the function can be called (vs. intel_modeset_pipes_in_mask_early()). Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915: Add helper to modeset a set of pipesImre Deak2-21/+83
Add intel_modeset_pipes_in_mask_early() to modeset a provided set of pipes, used in a follow-up patch. As opposed to intel_modeset_all_pipes() which modesets only the active pipes - others don't requiring programming the HW - modeset all enabled pipes in intel_modeset_pipes_in_mask_early() which may need to recompute their state even if they are not active (that is in the DPMS off state). While at it add DocBook descriptions for the two exported functions. v2: - Add a flag controlling if active planes are force updated as well. - Add DockBook descriptions. v3: - For clarity use _early/_late suffixes for the exported functions instead of the update_active_planes parameter. (Ville) v4: - In intel_modeset_pipes_in_mask_early() update only the crtc flags relevant to the early phase. (Ville) - Rename intel_modeset_all_pipes() in a separate patch. Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915/dp: Limit the output link bpp in DSC modeImre Deak3-0/+12
Limit the output link bpp in DSC mode to the link_config_limits link.min_bpp_x16 .. max_bpp_x16 range the same way it's done in non-DSC mode. Atm this doesn't make a difference, the link bpp range being 0 .. max pipe bpp, but a follow-up patch will need a way to reduce max link bpp below its current value. v2: - Add to_bpp_int_roundup() instead of open coding it. (Jani) Cc: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915/dp: Update the link bpp limits for DSC modeImre Deak4-22/+108
In non-DSC mode the link bpp can be set in 2*3 bpp steps in the pipe bpp range, while in DSC mode it can be set in 1/16 bpp steps to any value up to the maximum pipe bpp. Update the limits accordingly in both modes to prepare for a follow-up patch which may need to reduce the max link bpp value and starts to check the link bpp limits in DSC mode as well. While at it add more detail to the link limit debug print and print it also for DSC mode. v2: - Add to_bpp_frac_dec() instead of open coding it. (Jani) v3: (Ville) - Add BPP_X16_FMT / BPP_X16_ARG. - Add TODO: comment about initializing the DSC link bpp limits earlier. Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915/dp: Skip computing a non-DSC link config if DSC is neededImre Deak2-14/+33
Computing the non-DSC mode link config is redundant once it's determined that DSC will be needed, so skip computing it. In a follow-up patch this simplifies setting the link limits which are dependent on the DSC vs. non-DSC mode. While at it sanitize the debug print about the MST DSC fallback path, making it similar to the SST DSC one. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915/dp: Track the pipe and link bpp limits separatelyImre Deak4-18/+45
A follow-up patch will need to limit the output link bpp both in the non-DSC and DSC configuration, so track the pipe and link bpp limits separately in the link_config_limits struct. Use .4 fixed point format for link bpp matching the 1/16 bpp granularity in DSC mode and for now keep this limit matching the pipe bpp limit. v2: (Jani) - Add to_bpp_int(), to_bpp_x16() helpers instead of opencoding them. - Rename link_config_limits::link.min/max_bpp to min/max_bpp_x16. Cc: Jani Nikula <[email protected]> Reviewed-by: Luca Coelho <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915/dp: Factor out helpers to compute the link limitsImre Deak2-45/+68
Factor out helpers that DP / DP_MST encoders can use to compute the link rate/lane count and bpp limits. A follow-up patch will call these to recalculate the limits if DSC compression is required. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/i915: Don't set PIPE_CONTROL_FLUSH_L3 for aux invalNirmoy Das1-1/+10
PIPE_CONTROL_FLUSH_L3 is not needed for aux invalidation so don't set that. Fixes: ad8ebf12217e ("drm/i915/gt: Ensure memory quiesced before invalidation") Cc: Jonathan Cavitt <[email protected]> Cc: Andi Shyti <[email protected]> Cc: <[email protected]> # v5.8+ Cc: Andrzej Hajda <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Matt Roper <[email protected]> Cc: Tejas Upadhyay <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Prathap Kumar Valsan <[email protected]> Cc: Tapani Pälli <[email protected]> Cc: Mark Janes <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Acked-by: Matt Roper <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Tested-by: Tapani Pälli <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/bridge: lt9611uxc: use drm_bridge_get_edid() instead of using ->get_edid ↵Jani Nikula1-1/+1
directly Make drm_bridge_get_edid() the one place to call the hook. Cc: Andrzej Hajda <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Robert Foss <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Jonas Karlman <[email protected]> Cc: Jernej Skrabec <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28drm/bridge: use drm_bridge_get_edid() instead of using ->get_edid directlyJani Nikula1-1/+1
Make drm_bridge_get_edid() the one place to call the hook. Cc: Andrzej Hajda <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Robert Foss <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Jonas Karlman <[email protected]> Cc: Jernej Skrabec <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-27drm/mediatek: dsi: Add mode_valid callback to DSI bridgeShuijing Li1-0/+20
Support IGT (Intel GPU Tools) in Mediatek DSI driver. According to the description of MIPI Alliance Specification for D-PHY Version 1.1, the maximum supported data rate is 1.5Gbps, so add mode_valid callback to dsi bridge to filter out the data rate exceeding the Specification. Signed-off-by: Shuijing Li <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2023-09-27drm/nouveau/kms/nv50: hide unused variablesArnd Bergmann1-3/+1
After a recent change, two variables are only used in an #ifdef: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1569:13: error: unused variable 'ret' [-Werror=unused-variable] 1569 | int ret; | ^~~ drivers/gpu/drm/nouveau/dispnv50/disp.c:1568:28: error: unused variable 'aux' [-Werror=unused-variable] 1568 | struct drm_dp_aux *aux = &nv_connector->aux; | ^~~ Move them into the same conditional block, along with the nv_connector variable that becomes unused during that fix. Fixes: 757033808c95 ("drm/nouveau/kms/nv50-: fixup sink D3 before tearing down link") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Danilo Krummrich <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-27drm/i915/dsb: Use DEwake to combat PkgC latencyVille Syrjälä3-14/+82
Normally we could be in a deep PkgC state all the way up to the point when DSB starts its execution at the transcoders undelayed vblank. The DSB will then have to wait for the hardware to wake up before it can execute anything. This will waste a huge chunk of the vblank time just waiting, and risks the DSB execution spilling into the vertical active period. That will be very bad, especially when programming the LUTs as the anti-collision logic will cause DSB to corrupt LUT writes during vertical active. To avoid these problems we can instruct the DSB to pre-wake the display engine on a specific scanline so that everything will be 100% ready to go when we hit the transcoder's undelayed vblank. One annoyance is that the scanline is specified as just that, a single scanline. So if we happen to start the DSB execution after passing said scanline no DEwake will happen and we may drop back into some PkgC state before reaching the transcoder's undelayed vblank. To prevent that we'll use the "force DEwake" bit to manually force the display engine to stay awake. We'll then have to clear the force bit again after the DSB is done (the force bit remains effective even when the DSB is otherwise disabled). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915: Introduce intel_crtc_scanline_to_hw()Ville Syrjälä2-0/+15
Add a helper to convert our idea of a scanline to the hw's idea of the same scanline (ie. apply crtc->scanline_offset in reverse). We'll need this to tell the DSB do stuff on a specific scanline. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915: Introduce skl_watermark_max_latency()Ville Syrjälä2-0/+16
The DSB code will want to know the maximum PkgC latency it has to contend with. Add a helper to expose that information. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Evade transcoder undelayed vblank when using DSBVille Syrjälä1-1/+4
We want to start the DSB execution from the transcoder's undelayed vblank, so in order to guarantee atomicity with the all the other mmio register writes we need to evade both vblanks. Note that currently we don't add any vblank delay, so this is effectively a nop. But in the future when we start to program double buffered registers from the DSB we'll need to delay the pipe's vblank to provide the register programming "window2" for the DSB. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Use non-posted register writes for legacy LUTVille Syrjälä1-0/+11
The DSB has problems writing the legacy LUT. The two workarounds I've discoverted are: - write each entry twice back to back - use non-posted writes Let's use non-posted writes as that seems a bit more standard. TODO: measure which is faster Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Load LUTs using the DSB during vblankVille Syrjälä4-7/+32
Loading LUTs with the DSB outside of vblank doesn't really work due to the palette anti-collision logic. Apparently the DSB register writes don't get stalled like CPU mmio writes do and instead we end up corrupting the LUT entries. Disabling the anti-collision logic would allow us to successfully load the LUT outside of vblank, but presumably that risks the LUT reads from the scanout (temporarily) getting corrupted data from the LUT instead. The anti-collision logic isn't active during vblank so that is when we can successfully load the LUT with the DSB. That is what we want to do anyway to avoid tearing. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Don't use DSB to load the LUTs during full modesetVille Syrjälä1-0/+4
Using the DSB for LUT loading during full modesets would require some actual though. Let's just use mmio for the time being. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Add support for non-posted DSB registers writesVille Syrjälä2-0/+23
Writing specific transcoder registers (and as it turns out, the legacy LUT as well) via DSB needs a magic sequence to emit non-posted register writes. Add a helper for this. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Introduce intel_dsb_reg_write_masked()Ville Syrjälä2-0/+20
Add a function for emitting masked register writes. Note that the mask is implemented through byte enables, so can only mask off aligned 8bit sets of bits. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Introduce intel_dsb_noop()Ville Syrjälä2-0/+10
Add a helper for emitting a number of DSB NOOPs commands. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Define the contents of some intstructions bit betterVille Syrjälä1-4/+8
Add some defines to specify what goes inside certain DSB instructions. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Define more DSB bitsVille Syrjälä1-0/+31
Define all the DSB register bits so I don't have to look through bspec to find them. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915/dsb: Use non-locked register accessVille Syrjälä1-9/+9
Avoid the locking overhead for DSB registers. We don't need the locks and intel_dsb_commit() in particular needs to be called from the vblank evade critical section and thus needs to be fast. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-09-27drm/i915: Do not disable preemption for resetsTvrtko Ursulin1-8/+6
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a preempt disable section over the hardware reset callback to prepare the driver for being able to reset from atomic contexts. In retrospect I can see that the work item at a time was about removing the struct mutex from the reset path. Code base also briefly entertained the idea of doing the reset under stop_machine in order to serialize userspace mmap and temporary glitch in the fence registers (see eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"), but that never materialized and was soon removed in 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") and replaced with a SRCU based solution. As such, as far as I can see, today we still have a requirement that resets must not sleep (invoked from submission tasklets), but no need to support invoking them from a truly atomic context. Given that the preemption section is problematic on RT kernels, since the uncore lock becomes a sleeping lock and so is invalid in such section, lets try and remove it. Potential downside is that our short waits on GPU to complete the reset may get extended if CPU scheduling interferes, but in practice that probably isn't a deal breaker. In terms of mechanics, since the preemption disabled block is being removed we just need to replace a few of the wait_for_atomic macros into busy looping versions which will work (and not complain) when called from non-atomic sections. v2: * Fix timeouts which are now in us. (Andi) * Update one comment as a drive by. (Andi) Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.