aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-04-09drm/i915: Extract intel_dp_joiner_needs_dsc()Ville Syrjälä3-18/+15
Pull the "does joiner need DSC?" check into a helper. MST will want to use this too at some point. Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-09drm/i915: s/intel_dp_can_bigjoiner()/intel_dp_has_bigjoiner()/Ville Syrjälä2-3/+3
Rename intel_dp_can_bigjoiner() to intel_dp_has_bigjoiner() to better reflect its function. Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-09drm/xe/lnl: Enable GuC Wa_14019882105Badal Nilawar3-7/+39
Enable GuC Wa_14019882105 to block interrupts during C6 flow when the memory path has been blocked v2: Make helper function generic and name it as guc_waklv_enable_simple (John Harrison) v3: Make warning descriptive (John Harrison) v4: s/drm_WARN/xe_gt_WARN/ (Michal) Cc: John Harrison <[email protected]> Signed-off-by: Badal Nilawar <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-09drm/xe/guc: Add support for workaround KLVsBadal Nilawar3-3/+66
To prevent running out of bits, new workaround (w/a) enable flags are being added via a KLV system instead of a 32 bit flags word. v2: GuC version check > 70.10 is not needed as base line xe doesnot support anything below < 70.19 v3: Use 64 bit ggtt address for future compatibility (John Harrison/Daniele) v4: %s/PAGE_SIZE/SZ_4K/ (Michal) Cc: John Harrison <[email protected]> Signed-off-by: Badal Nilawar <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-09drm/i915: use check_add_overflow() and drop local variantsJani Nikula2-17/+3
Prefer common check_add_overflow() from overflow.h over the locally rolled versions of it. While check_add_overflow() does require a variable to assign to, unlike add_overflows_t(), it's still better than having multiple versions around. Cc: Kees Cook <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-09drm/i915: move pipestat_irq_mask to display substructJani Nikula4-9/+8
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/2e2f1c9576126927ea63a54639077c01d44ad5b6.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915: move de_irq_mask to display substructJani Nikula4-17/+14
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/733fc96df9153c6af8979d9b23d3aa3734937b56.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915: move display_irqs_enabled to display substructJani Nikula6-15/+14
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f6ac8e4c6ec8621bacf3db58a2bf156bd636f1d1.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915: move vblank_enabled to display substructJani Nikula4-10/+11
The info is related to display, and should be placed under i915->display. Start a new irq sub-substruct. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/eb89ed70020ea78396e1fec6f1a97693f2bdb96b.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915: move max_dotclk_freq to display substructJani Nikula14-20/+17
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ea012aa72c93f3d436ccacf8f75683757d144b82.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915: move skl_preferred_vco_freq to display substructJani Nikula4-14/+10
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4e9877d1641bce905cc9dd5eabe40df51ddbe9b5.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915/gt: drop display clock info from gt debugfsJani Nikula1-4/+0
The same info is available in i915_cdclk_info. Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/50461f13ab09b162de25d3f3587890548f4db499.1712599670.git.jani.nikula@intel.com
2024-04-09nouveau: fix devinit paths to only handle display on GSP.Dave Airlie2-4/+9
This reverts: nouveau/gsp: don't check devinit disable on GSP. and applies a further fix. It turns out the open gpu driver, checks this register, but only for display. Match that behaviour and in the turing path only disable the display block. (ampere already only does displays). Fixes: 5d4e8ae6e57b ("nouveau/gsp: don't check devinit disable on GSP.") Reviewed-by: Danilo Krummrich <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe: Capture GuC CT snapshot when stoppedMatthew Brost1-1/+1
It is useful capture the GuC CT snapshot if the GuC CT has been forcefully put into the stopped state. Enable snapshot capture when in this state. Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe: Always capture exec queues on snapshotMatthew Brost3-25/+6
Always capture exec queues on snapshot regardless if exec queue has pending jobs or not. Having jobs or not does indicate whether the exec queue capture is useful. Example bugs that would not be easily detected by skipping capture when pending job list is empty: - Jobs pending on exec queue have dependencies - Leaking exec queue refs - GuC protocol issues (i.e. losing G2H) In addition to above bugs, in general it just useful to see every exec queue registered with the GuC and its state. Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/uapi: Restore flags VM_BIND_FLAG_READONLY and VM_BIND_FLAG_IMMEDIATEFrancois Dugast2-2/+15
The commit 84a1ed5e6756 ("drm/xe/uapi: Remove unused flags") is partially reverted. At the time, flags not used by user space were removed during cleanup. Some flags now needed by the compute runtime are brought back in this commit: - DRM_XE_VM_BIND_FLAG_READONLY is used to write protect kernel ISA thus preventing accidental overwrites. - DRM_XE_VM_BIND_FLAG_IMMEDIATE is used to trigger mapping at the time of binding in order to prevent faulting at execution time. The changes in the compute runtime are ready and approved, see link below. v2: Include a link to the PR in the commit message (Matthew Brost) v3: Update kernel doc and improve commit message (Lucas De Marchi) Cc: Mateusz Jablonski <[email protected]> Cc: Michal Mrozek <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Lucas De Marchi <[email protected]> Link: https://github.com/intel/compute-runtime/pull/717 Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-08drm/xe: Remove dead clock codeLucas De Marchi2-6/+1
xe_gt_clock_cycles_to_ns() is not called from anywhere after PMU handling was removed in commit 90a8b23f9b85 ("drm/xe/pmu: Remove PMU from Xe till uapi is finalized"). Drop it. Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-08drm/i915/vrr: Disable VRR when using bigjoinerVille Syrjälä1-0/+7
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change switch between non-VRR and VRR timings generators on the fly, or even when sending the push to the transcoder. For now just disable VRR when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit f9d5e51db65652dbd8a2102fd7619440e3599fd2) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915: Disable live M/N updates when using bigjoinerVille Syrjälä1-1/+5
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change the timings at the same time. For now just disable live M/N updates when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit ef79820db723a2a7c229a7251c12859e7e25a247) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915: Disable port sync when bigjoiner is usedVille Syrjälä1-0/+5
The current modeset sequence can't handle port sync and bigjoiner at the same time. Refuse port sync when bigjoiner is needed, at least until we fix the modeset sequence. v2: Add a FIXME (Vandite) Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit b37e1347b991459c38c56ec2476087854a4f720b) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/psr: Disable PSR when bigjoiner is usedVille Syrjälä1-0/+11
Bigjoiner seem to be causing all kinds of grief to the PSR code currently. I don't believe there is any hardware issue but the code simply not handling this correctly. For now just disable PSR when bigjoiner is needed. Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Arun R Murthy <[email protected]> Acked-by: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit 372fa0c79d3f289f813d8001e0a8a96d1011826c) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/guc: Fix the fix for reset lock confusionJohn Harrison2-14/+13
The previous fix for the circlular lock splat about the busyness worker wasn't quite complete. Even though the reset-in-progress flag is cleared at the start of intel_uc_reset_finish, the entire function is still inside the reset mutex lock. Not sure why the patch appeared to fix the issue both locally and in CI. However, it is now back again. There is a further complication that the wedge code path within intel_gt_reset() jumps around so much that it results in nested reset_prepare/_finish calls. That is, the call sequence is: intel_gt_reset | reset_prepare | __intel_gt_set_wedged | | reset_prepare | | reset_finish | reset_finish The nested finish means that even if the clear of the in-progress flag was moved to the end of _finish, it would still be clear for the entire second call. Surprisingly, this does not seem to be causing any other problems at present. As an aside, a wedge on fini does not call the finish functions at all. The reset_in_progress flag is left set (twice). So instead of trying to cancel the worker anywhere at all in the reset path, just add a cancel to intel_guc_submission_fini instead. Note that it is not a problem if the worker is still active during a reset. Either it will run before the reset path starts locking things and will simply block the reset code for a tiny amount of time. Or it will run after the locks have been acquired and will early exit due to the try-lock. Also, do not use the reset-in-progress flag to decide whether a synchronous cancel is safe (from a lockdep perspective) or not. Instead, use the actual reset mutex state (both the genuine one and the custom rolled BACKOFF one). Fixes: 0e00a8814eec ("drm/i915/guc: Avoid circular locking issue on busyness flush") Signed-off-by: John Harrison <[email protected]> Cc: Zhanjun Dong <[email protected]> Cc: John Harrison <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Umesh Nerlige Ramappa <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Matt Roper <[email protected]> Cc: Jonathan Cavitt <[email protected]> Cc: Prathap Kumar Valsan <[email protected]> Cc: Alan Previn <[email protected]> Cc: Madhumitha Tolakanahalli Pradeep <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Ashutosh Dixit <[email protected]> Cc: Dnyaneshwar Bhadane <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3563d855312acedcd445a3767f0cb07906f1c26f) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/hdcp: Fix get remote hdcp capability functionSuraj Kandpal1-1/+4
HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable. --v2 -Assign hdcp_capable and hdcp2_capable to false [Chaitanya] --v3 -Fix variable assignment [Chaitanya] Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim function") Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Chaitanya Kumar Borah <[email protected]> Signed-off-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6809f9246d43f7cb07310ca6a3deb7aa1c0ea938) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/cdclk: Fix voltage_level programming edge caseVille Syrjälä1-10/+27
Currently we only consider the relationship of the old and new CDCLK frequencies when determining whether to do the repgramming from intel_set_cdclk_pre_plane_update() or intel_set_cdclk_post_plane_update(). It is technically possible to have a situation where the CDCLK frequency is decreasing, but the voltage_level is increasing due a DDI port. In this case we should bump the voltage level already in intel_set_cdclk_pre_plane_update() (so that the voltage_level will have been increased by the time the port gets enabled), while leaving the CDCLK frequency unchanged (as active planes/etc. may still depend on it). We can then reduce the CDCLK frequency to its final value from intel_set_cdclk_post_plane_update(). In order to handle that correctly we shall construct a suitable amalgam of the old and new cdclk states in intel_set_cdclk_pre_plane_update(). And we can simply call intel_set_cdclk() unconditionally in both places as it will not do anything if nothing actually changes vs. the current hw state. v2: Handle cdclk_state->disable_pipes v3: Only synchronize the cd2x update against the pipe's vblank when the cdclk frequency is changing during the current commit phase (Gustavo) Cc: [email protected] Cc: Gustavo Sousa <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 34d127e2bdef73a923aa0dcd95cbc3257ad5af52) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/cdclk: Fix CDCLK programming order when pipes are activeVille Syrjälä2-2/+8
Currently we always reprogram CDCLK from the intel_set_cdclk_pre_plane_update() when using squash/crawl. The code only works correctly for the cd2x update or full modeset cases, and it was simply never updated to deal with squash/crawl. If the CDCLK frequency is increasing we must reprogram it before we do anything else that might depend on the new higher frequency, and conversely we must not decrease the frequency until everything that might still depend on the old higher frequency has been dealt with. Since cdclk_state->pipe is only relevant when doing a cd2x update we can't use it to determine the correct sequence during squash/crawl. To that end introduce cdclk_state->disable_pipes which simply indicates that we must perform the update while the pipes are disable (ie. during intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new CDCLK frequency comparsiong as for cd2x updates. The only remaining problem case is when the voltage_level needs to increase due to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are being disabled). The current approach will not bump the voltage level up until after the port has already been enabled, which is too late. But we'll take care of that case separately. v2: Don't break the "must disable pipes case" v3: Keep the on stack 'pipe' for future use Cc: [email protected] Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL") Reviewed-by: Uma Shankar <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3aecee90ac12a351905f12dda7643d5b0676d6ca) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/msm/dp: Account for the timeout in wait_hpd_asserted() callbackDouglas Anderson3-6/+9
The DP wait_hpd_asserted() callback is passed a timeout which indicates how long we should wait for HPD. This timeout was being ignored in the MSM DP implementation and instead a hardcoded 500 ms timeout was used. Fix it to use the proper timeout. As part of this we move the hardcoded 500 ms number into the AUX transfer function, which isn't given a timeout. The wait in the AUX transfer function will be removed in a future commit. Fixes: e2969ee30252 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/583128/ Link: https://lore.kernel.org/r/20240315143621.v2.2.I7758d18a1773821fa39c034b16a12ef3f18a51ee@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connectedDouglas Anderson3-0/+25
As documented in the description of the transfer() function of "struct drm_dp_aux", the transfer() function can be called at any time regardless of the state of the DP port. Specifically if the kernel has the DP AUX character device enabled and userspace accesses "/dev/drm_dp_auxN" directly then the AUX transfer function will be called regardless of whether a DP device is connected. For eDP panels we have a special rule where we wait (with a 5 second timeout) for HPD to go high. This rule was important before all panels drivers were converted to call wait_hpd_asserted() and actually can be removed in a future commit. For external DP devices we never checked for HPD. That means that trying to access the DP AUX character device (AKA `hexdump -C /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my system: $ time hexdump -C /dev/drm_dp_aux0 hexdump: /dev/drm_dp_aux0: Connection timed out real 0m8.200s We want access to the drm_dp_auxN character device to fail faster than 8 seconds when no DP cable is plugged in. Let's add a test to make transfers fail right away if a device isn't plugged in. Rather than testing the HPD line directly, we have the dp_display module tell us when AUX transfers should be enabled so we can handle cases where HPD is signaled out of band like with Type C. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/583127/ Link: https://lore.kernel.org/r/20240315143621.v2.1.I16aff881c9fe82b5e0fc06ca312da017aa7b5b3e@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dpu: add current resource allocation to dumped stateDmitry Baryshkov4-0/+78
Provide atomic_print_state callback to the DPU's private object. This way the debugfs/dri/0/state will also include RM's internal state. Example output (RB5 board, HDMI and writeback encoder enabled) resource mapping: pingpong=31 36 # # # # - - - - - mixer=31 36 # # # # - ctl=# # 31 36 # # dspp=# # # # dsc=# # # # - - cdm=# Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/579648/ Link: https://lore.kernel.org/r/[email protected]
2024-04-08drm/msm/dp: allow voltage swing / pre emphasis of 3Dmitry Baryshkov3-27/+15
Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and pre-emphasis to 2, while the real maximum value for the sum of the voltage swing and pre-emphasis is 3. Fix the DP code to remove this limitation. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Kuogee Hsieh <[email protected]> Tested-by: Kuogee Hsieh <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577006/ Link: https://lore.kernel.org/r/[email protected]
2024-04-08drm/msm/dp: Remove now unused connector_type from descBjorn Andersson1-31/+17
Now that the connector_type is dynamically determined, the connector_type of the struct msm_dp_desc is unused. Clean it up. Remaining duplicate entries are squashed. Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/588020/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Add support for the X1E80100Abel Vesa1-0/+9
Add the X1E80100 DP descs and compatible. This platform will be using a single compatible for both eDP and DP mode. The actual mode will be set based on the presence of the panel node in DT. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/584536/ Link: https://lore.kernel.org/r/20240324-x1e80100-display-refactor-connector-v4-2-e0ebaea66a78@linaro.org Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Add support for determining the eDP/DP mode from DTAbel Vesa1-1/+28
Instead of relying on different compatibles for eDP and DP, lookup the panel node in devicetree to figure out the connector type and then pass on that information to the PHY. External DP doesn't have a panel described in DT, therefore, assume it's eDP if panel node is present. Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/584534/ Link: https://lore.kernel.org/r/20240324-x1e80100-display-refactor-connector-v4-1-e0ebaea66a78@linaro.org Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08Merge tag 'phy_dp_modes_6.10' into msm-next-lumagDmitry Baryshkov338-2909/+129403
Merge DisplayPort subnode API in order to allow DisplayPort driver to configure the PHYs either to the DP or eDP mode, depending on hardware configuration. Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceAleksandr Mishin1-0/+3
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/client: Fully protect modes[] with dev->mode_config.mutexVille Syrjälä1-1/+2
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]>
2024-04-08drm/xe: Label RING_CONTEXT_CONTROL as maskedAshutosh Dixit2-4/+3
RING_CONTEXT_CONTROL is a masked register. v2: Also clean up setting register value (Lucas) Reviewed-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08gpu: host1x: Do not setup DMA for virtual devicesThierry Reding1-8/+0
The host1x devices are virtual compound devices and do not perform DMA accesses themselves, so they do not need to be set up for DMA. Ideally we would also not need to set up DMA masks for the virtual devices, but we currently still need those for legacy support on old hardware. Tested-by: Jon Hunter <[email protected]> Acked-by: Jon Hunter <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe: Remove debug message from migrate_clear()José Roberto de Souza1-3/+0
This messages is printed a lot and from my understanding it do not bring any value, so here dropping it. Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/display: Fix double mutex initializationLucas De Marchi1-5/+0
All of these mutexes are already initialized by the display side since commit 3fef3e6ff86a ("drm/i915: move display mutex inits to display code"), so the xe shouldn´t initialize them. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Jani Nikula <[email protected]> Cc: Arun R Murthy <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-08drm/xe/vf: Mark supported firmwares as preloadedMichal Wajdeczko3-3/+19
On current platforms supported firmwares, like GuC and HuC, must be loaded by the PF driver. Mark those firmwares as 'preloaded' so we will skip fetching and loading them on the VF drivers but still correctly report them as 'running'. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/vf: Don't try to read legacy GuC MMIO notification if VFMichal Wajdeczko1-0/+3
Legacy SOFT_SCRATCH registers are not accessible from the VF. Any G2H notification posted there will be handled by the PF driver. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/vf: Don't try to program MOCS if VFMichal Wajdeczko1-0/+3
VFs drivers don't have access to MOCS registers. It is a PF driver responsibility to program MOCS according to the HW team guidelines. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/vf: Don't emit access to Global HWSP if VFMichal Wajdeczko1-4/+7
VFs can't access Global HWSP, don't emit questionable MI_FLUSH_DW while processing a migration job. Bspec: 52398 Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915: Update pipes in reverse order for bigjoinerVille Syrjälä2-3/+19
With bigjoiner the master crtc is the one that will send out the uapi event/etc. We want that to happen after all the slaves are done, so let's try to do the commits in reverse order so that the master comes last. Even worse, the modeset helper will simply complete the commit on the slave pipe immediately as it consider the crtc to be inactive (it can't see our crtc_state->hw.active/etc.). With regular sync updates this generally doesn't matter all that much as the slave pipe should typically finish its work during the same frame as the master pipe. However in case the slave pipe's commit slips into the next frame we end up in a bit of trouble. This is most visible with either async flips (currently disabled with bigjoiner exactly for this reason), and DSB gamma updates. With DSB the problem happens because the DSB itself will wait until the next start vblank before starting to execute. So if the master pipe already finished its commit and the DSB on the slave pipe is still waiting for the next vblank we will assume the DSB as gotten stuck and terminate it. Reversing the commit order should ameliarate this for the most part as the master pipe is guaranteed to start its commit after the slave pipe started. The one thing that can still screw us over is the fact that we aren't necessarily going to commit the pipes in the reverse order as the actual order is dictated by the DDB overlap avoidance. But that can only happen while other pipes are being enabled/disabled, and so in the normal steady state we should be safe. The full fix will involve making the commit machinery aware of the slave pipes and not finish their commits prematurely. But that will involve a bit more work than this. And this commit order reversal will still be beneficial to avoid userspace getting an -EBUSY from the following page flip if the second pipe's commit does stretch into the next frame. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Arun R Murthy <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]>
2024-04-08drm/i915: Fix intel_modeset_pipe_config_late() for bigjoinerVille Syrjälä1-14/+32
Currently intel_modeset_pipe_config_late() is called after the bigjoiner state copy, and it will actually not do anything for bigjoiner slaves. This can lead to a mismatched state between the master and slave. The two things that we do in the encoder .compute_config_late() hook are mst master transcoder and port sync master transcoder elections. So if either of either MST or port sync is combined with bigjoiner then we can see the mismatch. Currently this problem is more or less theoretical; MST+bigjoiner has not been implemented yet, and port sync+bigjoiner would require a tiled display with >5k tiles (or a very high dotclock per tile). Although we do have kms_tiled_display in igt which can fake a tiled display, and we can now force bigjoiner via debugfs, so it is possible to trigger this if you try hard enough. Reorder the code such that intel_modeset_pipe_config_late() will be called before the bigjoiner state copy happens so that both pipes will end up with the same state. Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/vrr: Disable VRR when using bigjoinerVille Syrjälä1-0/+7
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change switch between non-VRR and VRR timings generators on the fly, or even when sending the push to the transcoder. For now just disable VRR when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/i915: Disable live M/N updates when using bigjoinerVille Syrjälä1-1/+5
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change the timings at the same time. For now just disable live M/N updates when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/i915: Disable port sync when bigjoiner is usedVille Syrjälä1-0/+5
The current modeset sequence can't handle port sync and bigjoiner at the same time. Refuse port sync when bigjoiner is needed, at least until we fix the modeset sequence. v2: Add a FIXME (Vandite) Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/i915/psr: Disable PSR when bigjoiner is usedVille Syrjälä1-0/+11
Bigjoiner seem to be causing all kinds of grief to the PSR code currently. I don't believe there is any hardware issue but the code simply not handling this correctly. For now just disable PSR when bigjoiner is needed. Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Arun R Murthy <[email protected]> Acked-by: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/xe/guc: Initialize GuC ID manager soonerMichal Wajdeczko1-9/+5
The GuC submission cleanup code may depend on the GuC ID manager, thus we can't initialize it after registering a submission cleanup action, as reverse cleanup sequence will destroy GuC ID manager prior to a call to guc_submit_fini(). Move GuC ID manager initialization up, right after managed mutex initialization, to have it available during guc_submit_fini(). Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.