aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-04-08drm/xe/guc: Use drm_device-managed version of mutex_init()Michal Wajdeczko1-2/+4
This is safer approach and will help resolve a cleanup ordering conflict related to the GuC ID manager. 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]
2024-04-08drm/xe/display: clean up compat i915_vgpu.hJani Nikula1-26/+0
There's a bunch of unnecessary stuff not needed by display code. Remove. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e583679c00aae8fec78f988fa857cfc724a9fa2d.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/xe/display: remove compat i915_gem.hJani Nikula2-10/+0
It's only there for GEM_BUG_ON(), but the display code no longer uses it. Good riddance. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8de7815d9c80125b86e0b85a1af80d4f8686eef6.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/xe/display: clean up a lot of cruft from compat i915_drv.hJani Nikula1-32/+0
There's a bunch of unused cruft. Just throw away. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d773f26cced0b376a30a6cb1e38c9581b469d8cf.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915: move i915_fixed.h to display/intel_fixed.hJani Nikula3-7/+1
All the users are in display, move the fixed point header under display. We could also consider making these more general purpose things, but that takes a bunch more effort. This allows the immediate cleanup of xe compat i915_fixed.h. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/320c451e116c7807e544a50c67ba79b087a4f218.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915/dmc: define firmware URL locallyJani Nikula3-13/+3
Avoid the dependency on intel_uc_fw.h, and allow removal of xe compat intel_uc_fw.h. If there needs to be duplication of the URL, at least have the duplication in a sensible way. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/15935837a0c15f861bb2a688cc53514f47153ef3.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915: use IS_JASPERLAKE()/IS_ELKHARTLAKE() instead of IS_PLATFORM()Jani Nikula1-2/+2
Avoid direct IS_PLATFORM() usage when we have the platform helpers. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7ca5fabac6a6f5ac8e102b84d1e28502e79296f0.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915/psr: Panel replay has to be enabled before link trainingJouni Högander4-3/+23
Panel replay has to be enabled on sink side before link training. Take this into account in fastset check and in initial fastset check. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Unify panel replay enable/disable sinkJouni Högander3-23/+50
Unify enabling and disabling of psr/panel replay for a sink. Modify intel_psr_enable_sink accordingly and use it for both cases. v3: - move psr2_su_region_et_valid to be check for PSR2 only v2: - enable panel replay for sink before link training - write ALPM_CONFIG only for PSR - add DP_PSR_CRC_VERIFICATION only for PSR - take care of disable sink as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Do not write registers/bits not applicable for panel replayJouni Högander1-25/+45
Bspec is saying this mask register: Only PSR_MASK[Mask FBC modify] and PSR_MASK[Mask Hotplug] are used in panel replay mode. Status register: Only SRD_STATUS[SRD state] field is used in panel replay mode. Due to this stop writing and reading registers and bits not used by panel replay if panel replay is used. Bspec: 53370, 68920 v2: - use intel_dp_is_edp with PSR_MASK register - handle LunarLake as well - hanle ALPM configuration as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Check possible errors for panel replay as wellJouni Högander1-5/+16
On HPD interrupt we want to check if the reason for HPD was some panel replay error detected by monitor/panel. This is already done for PSR. We want to do this for panel replay as well. Modify intel_psr_short_pulse to support panel replay as well. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Do not update phy power state in case of non-eDP panel replayJouni Högander1-4/+8
Currently panel replay is supporting only main link on mode -> Do not update phy power state for non-eDP panel replay. Bspec: 53370 v2: use intel_dp_is_edp to differentiate Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Intel_psr_pause/resume needs to support panel replayJouni Högander1-2/+2
Currently intel_psr_pause and intel_psr_resume do nothing in case of panel replay. Change them to perform pause and return also in case of panel replay. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as wellJouni Högander1-5/+6
Current code is setting only intel_crtc_state->has_panel_replay in panel replay case. There are lots of stuff behind intel_crtc_state->has_psr that is needed for panel replay as well. Instead of converting each check to has_psr || has_panel_replay set has_psr in case of panel replay as well. Code can then differentiate between psr and panel replay by using intel_crtc_state->has_panel_replay. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Add some documentation of variables used in psr codeJouni Högander1-0/+16
We are adding more boolean variable into intel_psr and intel_crtc_state structs. Add some documentation about these for sake of clarity. v2: Modify has_psr + has_panel_replay to mean panel replay Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-07drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probeDouglas Anderson2-3/+14
If we're using the AUX channel for eDP backlight and it fails to probe for some reason, let's _not_ fail the panel probe. At least one case where we could fail to init the backlight is because of a dead or physically missing panel. As talked about in detail in the earlier patch in this series, ("drm/panel-edp: If we fail to powerup/get EDID, use conservative timings"), this can cause the entire system's display pipeline to fail to come up and that's non-ideal. If we fail to init the backlight for some transitory reason, we should dig in and see if there's a way to fix this (perhaps retries?). Even in that case, though, having a panel whose backlight is stuck at 100% (the default, at least in the panel Samsung ATNA33XC20 I tested) is better than having no panel at all. Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.3.I552e8af0ddb1691cc0fe5d27ea3d8020e36f7006@changeid
2024-04-07drm/panel-edp: If we fail to powerup/get EDID, use conservative timingsDouglas Anderson1-5/+7
If at boot we fail to power up the eDP panel (most often happens if the eDP panel never asserts HPD to us) or if we are unable to read the EDID at bootup to figure out the panel's ID then let's use the conservative eDP panel powerup/powerdown timings but _not_ fail the probe. It might seem strange to _not_ fail the probe in this case since we were unable to powerup the panel and confirm it's there. However, there is a reason to do this. Specifically, if we fail to probe the panel then it really throws the whole display pipeline for loop. Most DRM subsystems are written so that they wait until all components (including the panel) have probed before they set everything up. When the panel doesn't come up then this never happens. As a side effect of not setting everything up then other display adapters don't get initialized. As a practical example, I can see that if I open up a sc7180-trogdor based Chromebook that's using the generic "edp-panel" and unplug the eDP panel that it causes the _external_ DP monitor not to function. This is obviously bad because it means that a device with a dead eDP panel becomes e-waste when it could instead still be given useful life with an external display. NOTES: - When we fail to probe like this, boot is a bit slow because we try several times to power the panel up. This doesn't feel horrible because it'll eventually work and the retries are known to help bring some panels up. - In the case where we hit the condition of failing to power up, the display will likely _never_ have a chance to work again until reboot. Once the panel-edp pm_runtime resume function fails it doesn't ever seem to retry. This is probably for the best given that we don't have any real timing/modes. eDP isn't expected to be "hotplugged" so this makes some sense. - It turns out that this makes panel-edp behave more similarly for users of the generic "edp-panel" compatible string and the old fixed panel compatible string. With the old fixed panel compatible string we don't talk to the panel during probe so we'd actually behave much the same way that we'll now behave for the generic "edp-panel". Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.2.Ia7a55a9657b0b6aa4644fd497a0bc595a771258c@changeid
2024-04-07drm/panel-edp: Abstract out function to set conservative timingsDouglas Anderson1-20/+20
If we're using the generic "edp-panel" compatible string and we fail to detect an eDP panel then we fall back to conservative timings for powering up and powering down the panel. Abstract out the function for setting these timings so it can be used in future patches. No functional change expected--just code movement. Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.1.I659b2517d9f619d09e804e071591ecab76335dfb@changeid
2024-04-06drm/i915: Fix i915_display_info output when connectors are not activeVille Syrjälä1-11/+3
Currently intel_connector_info(), which prints the per-connector output for i915_display_info, just bails out early if the connector doesn't have a current encoder. That leads to very confusing output where some of your connected (and properly detected) outputs appear to have no enumerated modes. Get rid of the encoder stuff and just rely on the connector itself so that the output is always consistent. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Suraj Kandpal <[email protected]>
2024-04-05drm/msm/adreno: Set highest_bank_bit for A619Luca Weiss1-0/+4
The default highest_bank_bit of 15 didn't seem to cause issues so far but downstream defines it to be 14. But similar to [0] leaving it on 14 (or 15 for that matter) causes some corruption issues with some resolutions with DisplayPort, like 1920x1200. So set it to 13 for now so that there's no screen corruption. [0] commit 6a0dbcd20ef2 ("drm/msm/a6xx: set highest_bank_bit to 13 for a610") Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support") Signed-off-by: Luca Weiss <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/585215/ Signed-off-by: Rob Clark <[email protected]>
2024-04-05drm/msm: fix the `CRASHDUMP_READ` target of `a6xx_get_shader_block()`Miguel Ojeda1-1/+1
Clang 14 in an (essentially) defconfig arm64 build for next-20240326 reports [1]: drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error: variable 'out' set but not used [-Werror,-Wunused-but-set-variable] The variable `out` in these functions is meant to compute the `target` of `CRASHDUMP_READ()`, but in this case only the initial value (`dumper->iova + A6XX_CD_DATA_OFFSET`) was being passed. Thus use `out` as it was intended by Connor [2]. There was an alternative patch at [3] that removed the variable altogether, but that would only use the initial value. Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx") Closes: https://lore.kernel.org/lkml/CANiq72mjc5t4n25SQvYSrOEhxxpXYPZ4pPzneSJHEnc3qApu2Q@mail.gmail.com/ [1] Link: https://lore.kernel.org/lkml/CACu1E7HhCKMJd6fixZSPiNAz6ekoZnkMTHTcLFVmbZ-9VoLxKg@mail.gmail.com/ [2] Link: https://lore.kernel.org/lkml/[email protected]/ [3] Signed-off-by: Miguel Ojeda <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/584955/ Signed-off-by: Rob Clark <[email protected]>
2024-04-05drm/xe: Drop xe_vm_assert_held() macro definition from xe_bo.hMichal Wajdeczko1-8/+0
It is already defined in xe_vm.h and shouldn't be duplicated. 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-05drm/xe: Move PTE/PDE bit definitions to proper headerMichal Wajdeczko6-21/+25
We already have dedicated header for GGTT/PPGTT definitions. It's also cleaner to separate them from implementation macros. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Matt Roper <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/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]
2024-04-05nouveau: fix function cast warningArnd Bergmann1-1/+6
Calling a function through an incompatible pointer type causes breaks kcfi, so clang warns about the assignment: drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from 'void (*)(const void *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] 73 | .fini = (void(*)(void *))kfree, Avoid this with a trivial wrapper. Fixes: c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes)") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05nouveau/gsp: Avoid addressing beyond end of rpc->entriesKees Cook1-1/+1
Using the end of rpc->entries[] for addressing runs into both compile-time and run-time detection of accessing beyond the end of the array. Use the base pointer instead, since was allocated with the additional bytes for storing the strings. Avoids the following warning in future GCC releases with support for __counted_by: In function 'fortify_memcpy_chk', inlined from 'r535_gsp_rpc_set_registry' at ../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1123:3: ../include/linux/fortify-string.h:553:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 553 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ for this code: strings = (char *)&rpc->entries[NV_GSP_REG_NUM_ENTRIES]; ... memcpy(strings, r535_registry_entries[i].name, name_len); Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/xe: fix multicast support for Xe_LP platformsAndrzej Hajda1-1/+6
Xe_LP has six sublices per slice. v2: fixed commit message and subject (Matt) Bspec: 66696 Fixes: bde5d76785bc ("drm/xe: Add helper macro to loop each DSS") Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-05Revert "drm/qxl: simplify qxl_fence_wait"Alex Constantino1-5/+45
This reverts commit 5a838e5d5825c85556011478abde708251cc0776. Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would result in a '[TTM] Buffer eviction failed' exception whenever it reached a timeout. Due to a dependency to DMA_FENCE_WARN this also restores some code deleted by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2"). Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") Link: https://lore.kernel.org/regressions/[email protected]/ Reported-by: Timo Lindfors <[email protected]> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514 Signed-off-by: Alex Constantino <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/bridge: dw-hdmi: Make DRM_DW_HDMI selectableMaxime Ripard1-1/+1
Commit c0e0f139354c ("drm: Make drivers depends on DRM_DW_HDMI") turned select dependencies into depends on ones. However, DRM_DW_HDMI was not manually selectable which resulted in no way to enable the drivers that were now depending on it. Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") Reported-by: Mark Brown <[email protected]> Reported-by: Alexander Stein <[email protected]> Reviewed-by: Mark Brown <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/display: Select DRM_KMS_HELPER for DP helpersMaxime Ripard1-0/+1
The DisplayPort helpers rely on some (__drm_atomic_helper_private_obj_duplicate_state, drm_kms_helper_hotplug_event) helpers found in files compiled by DRM_KMS_HELPER. Prior to commit d674858ff979 ("drm/display: Make all helpers visible and switch to depends on"), DRM_DISPLAY_DP_HELPER was only selectable so it wasn't really a big deal. However, since that commit, it's now something that can be enabled as is, and since there's no expressed dependency with DRM_KMS_HELPER, it can break too. Since DRM_KMS_HELPER is a selectable option for now, let's select it for DRM_DISPLAY_DP_HELPER. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: d674858ff979 ("drm/display: Make all helpers visible and switch to depends on") Reviewed-by: Mark Brown <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/xe/guc: Reuse code while debugging GuC paramsMichal Wajdeczko1-10/+11
There is no need to duplicate code to print GuC parameters. Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/xe/guc: Prefer GT oriented logs for GuC messagesMichal Wajdeczko1-43/+36
A platform can have more than one GuC, so we should use GT-oriented logs to correctly identify the source of the message. Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/ast: Fix soft lockupJammy Huang1-0/+3
There is a while-loop in ast_dp_set_on_off() that could lead to infinite-loop. This is because the register, VGACRI-Dx, checked in this API is a scratch register actually controlled by a MCU, named DPMCU, in BMC. These scratch registers are protected by scu-lock. If suc-lock is not off, DPMCU can not update these registers and then host will have soft lockup due to never updated status. DPMCU is used to control DP and relative registers to handshake with host's VGA driver. Even the most time-consuming task, DP's link training, is less than 100ms. 200ms should be enough. Signed-off-by: Jammy Huang <[email protected]> Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory Display-Port") Reviewed-by: Jocelyn Falempe <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Cc: KuoHsiang Chou <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Jocelyn Falempe <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.19+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/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]
2024-04-05drm/i915/display: Initialize capability variablesSuraj Kandpal1-1/+1
Initialize HDCP capability variables to false to avoid UBSAN warning in boolean value as some functions invoking this could return without filling the two capability values. --v2 -Fix Typo [Chaitanya] 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]
2024-04-05Merge tag 'drm-intel-fixes-2024-04-04' of ↵Dave Airlie15-42/+185
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes Display fixes: - A few DisplayPort related fixes (Imre, Arun, Ankit, Ville) - eDP PSR fixes (Jouni) Core/GT fixes: - Remove some VM space restrictions on older platforms (Andi) - Disable automatic load CCS load balancing (Andi) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05Merge tag 'drm-xe-fixes-2024-04-04' of ↵Dave Airlie15-145/+140
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Stop using system_unbound_wq for preempt fences, as this can cause starvation when reaching more than max_active defined by workqueue - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency Signed-off-by: Dave Airlie <[email protected]> From: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/tizan6wdpxu4ayudeikjglxdgzmnhdzj3li3z2pgkierjtozzw@lbfddeg43a7h
2024-04-05Merge tag 'drm-misc-fixes-2024-04-04' of ↵Dave Airlie5-10/+15
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: display: - fix typos in kerneldoc nouveau: - uvmm: fix remap address calculation - minor cleanups panfrost: - fix power-transition timeouts prime: - unbreak dma-buf export for virt-gpu Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-04drm/xe/xe_hw_engine_class_sysfs: use sysfs_emit() for attr's _show()Bommu Krishnaiah1-18/+18
sprintf() is deprecated for sysfs, use preferred sysfs_emit() instead. v2: used sysfs_emit instand of sprintf Signed-off-by: Bommu Krishnaiah <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Cc: Tejas Upadhyay <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-04drm/xe: prefer snprintf over sprintfBommu Krishnaiah5-11/+11
since the sprintf() function lacks built-in protection against buffer overflows using the snprintf() function. v2: Removed hard coded values and used sizeof() Signed-off-by: Bommu Krishnaiah <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Cc: Tejas Upadhyay <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-04drm/xe: Protect devcoredump access after unbindRodrigo Vivi2-3/+4
While we don't have the full flow protection when devcoredump is accessed after device unbind. Let's at least for now protect against null dereference: [ 422.766508] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 423.119584] RIP: 0010:xe_vm_snapshot_free+0x30/0x180 [xe] While at it, I also fixed a non-standard code-declaration block on the similar function of xe_guc_submit. v2: - Use IS_ERR_OR_NULL (Nirmoy) - Expand to other functions Cc: José Roberto de Souza <[email protected]> Cc: Nirmoy Das <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-04drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()Boris Brezillon1-4/+9
Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called. Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Cc: <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Co-developed-by: Dmitry Osipenko <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-04drm: fix DRM_DISPLAY_DP_HELPER dependenciesArnd Bergmann2-2/+2
Both the exynos and rockchip drivers ran into link failures after a Kconfig cleanup: aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_resume': exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume' aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_suspend': exynos_dp.c:(.text+0xf4): undefined reference to `analogix_dp_suspend' x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function `cdn_dp_connector_mode_valid': cdn-dp-core.c:(.text+0x13a): undefined reference to `drm_dp_bw_code_to_link_rate' x86_64-linux-ld: cdn-dp-core.c:(.text+0x148): undefined reference to `drm_dp_bw_code_to_link_rate' x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function `cdn_dp_check_link_status': cdn-dp-core.c:(.text+0x1396): undefined reference to `drm_dp_channel_eq_ok' In both cases, the problem is that ROCKCHIP_CDN_DP and DRM_EXYNOS_DP are 'bool' symbols that depend on the the 'tristate' DRM_DISPLAY_HELPER symbol, but end up not working when the SoC specific part is built-in but the helper is in a loadable module. Use the same trick that DRM_ROCKCHIP already uses for the EXTCON dependency and disallow DP support when it would not work. Fixes: 0323287de87d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2024-04-04drm/mediatek: padding: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240330-b4-module-owner-drm-mediatek-v1-11-fd5c4b8d633e@linaro.org/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-04-04drm/mediatek: mdp_rdma: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240330-b4-module-owner-drm-mediatek-v1-10-fd5c4b8d633e@linaro.org/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-04-04drm/mediatek: ethdr: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240330-b4-module-owner-drm-mediatek-v1-9-fd5c4b8d633e@linaro.org/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-04-04drm/mediatek: rdma: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240330-b4-module-owner-drm-mediatek-v1-8-fd5c4b8d633e@linaro.org/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-04-04drm/xe: Use ordered wq for preempt fence waitingMatthew Brost3-2/+14
Preempt fences can sleep waiting for an exec queue suspend operation to complete. If the system_unbound_wq is used for waiting and the number of waiters exceeds max_active this will result in other users of the system_unbound_wq getting starved. Use a device private work queue for preempt fences to avoid starvation of the system_unbound_wq. Even though suspend operations can complete out-of-order, all suspend operations within a VM need to complete before the preempt rebind worker can start. With that, use a device private ordered wq for preempt fence waiting. v2: - Add comment about cleanup on failure (Matt R) - Update commit message (Lucas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit 37c15c4aae1fe3f67efd2641db8d8c25c2d524ab) Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-04drm/xe: Move vma rebinding to the drm_exec locking loopThomas Hellström5-75/+83
Rebinding might allocate page-table bos, causing evictions. To support blocking locking during these evictions, perform the rebinding in the drm_exec locking loop. Also Reserve fence slots where actually needed rather than trying to predict how many fence slots will be needed over a complete wound-wait transaction. v2: - Remove a leftover call to xe_vm_rebind() (Matt Brost) - Add a helper function xe_vm_validate_rebind() (Matt Brost) v3: - Add comments and squash with previous patch (Matt Brost) Fixes: 24f947d58fe5 ("drm/xe: Use DRM GPUVM helpers for external- and evicted objects") Fixes: 29f424eb8702 ("drm/xe/exec: move fence reservation") Cc: Matthew Auld <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 7ee7dd6f301341d5b1204fc19fa620d7f7f7e90d) Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-04drm/xe: Make TLB invalidation fences unorderedThomas Hellström3-10/+1
They can actually complete out-of-order, so allocate a unique fence context for each fence. Fixes: 5387e865d90e ("drm/xe: Add TLB invalidation fence after rebinds issued from execs") Cc: Matthew Brost <[email protected]> Cc: <[email protected]> # v6.8+ Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0453f1757501df2e82b66b3183a24bba5a6f8fa3) Signed-off-by: Lucas De Marchi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.