summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-11-11drm/amd/amdgpu: Increase MES log buffer to dump mes scratch datashaoyunl
MES internal scratch data is useful for mes debug, it can only located in VRAM, change the allocation type and increase size for mes 11 Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Acked-by: Feifei Xu <Feifei.Xu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amdgpu: Implement virt req_ras_err_countVictor Skvortsov
Enable RAS late init if VF RAS Telemetry is supported. When enabled, the VF can use this interface to query total RAS error counts from the host. The VF FB access may abruptly end due to a fatal error, therefore the VF must cache and sanitize the input. The Host allows 15 Telemetry messages every 60 seconds, afterwhich the host will ignore any more in-coming telemetry messages. The VF will rate limit its msg calling to once every 5 seconds (12 times in 60 seconds). While the VF is rate limited, it will continue to report the last good cached data. v2: Flip generate report & update statistics order for VF Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com> Acked-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Zhigang Luo <zhigang.luo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amdgpu: VF Query RAS Caps from Host if supportedVictor Skvortsov
If VF RAS Capability support is enabled, guest is able to retrieve the real RAS support from the host. Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com> Reviewed-by: Zhigang Luo <zhigang.luo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amdgpu: Add msg handlers for SRIOV RAS TelemetryVictor Skvortsov
Add message handlers for RAS telemetry. Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com> Reviewed-by: Zhigang Luo <zhigang.luo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amdgpu: Update SRIOV Exchange Headers for RAS Telemetry SupportVictor Skvortsov
The SRIOV PF/VF Data exchange is extended by 64KB for VF RAS Telemetry data. Add Host RAS Telemetry enable capabilities bitfields. Add a new VF msg REQ_RAS_ERROR_COUNT, the host response data will be populated in the RAS Telemetry region. Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com> Reviewed-by: Zhigang Luo <zhigang.luo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amd/display: 3.2.309Aric Cyr
This version brings along the following: - DML2 fixes - DP fixes - DPMS fix - HPD fixes - Misc cleanup - ODM fix - Replay fix - SPL fix Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amd/display: Adjust VSDB parser for replay featureRodrigo Siqueira
At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. Cc: ChiaHsuan Chung <chiahsuan.chung@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amd/display: Remove unused codeRodrigo Siqueira
This commit removes a legacy debug_defaults_diags struct. Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/amd/display: Require minimum VBlank size for stutter optimizationDillon Varone
If the nominal VBlank is too small, optimizing for stutter can cause the prefetch bandwidth to increase drasticaly, resulting in higher clock and power requirements. Only optimize if it is >3x the stutter latency. Reviewed-by: Austin Zheng <austin.zheng@amd.com> Signed-off-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-11drm/bridge: cdns-mhdp8546: Remove unused functionsDr. David Alan Gilbert
cdns_mhdp_hdcp_set_lc() and cdns_mhdp_hdcp_set_public_key_param() were added by commit 6a3608eae6d3 ("drm: bridge: cdns-mhdp8546: Enable HDCP") but never used. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241005232017.305217-1-linux@treblig.org
2024-11-11drm/v3d: Fix performance counter source settings on V3D 7.xMaíra Canal
When the new register addresses were introduced for V3D 7.x, we added new masks for performance counter sources on V3D 7.x. Nevertheless, we never apply these new masks when setting the sources. Fix the performance counter source settings on V3D 7.x by introducing a new macro, `V3D_SET_FIELD_VER`, which allows fields setting to vary by version. Using this macro, we can provide different values for source mask based on the V3D version, ensuring that sources are correctly configure on V3D 7.x. Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106121736.5707-1-mcanal@igalia.com
2024-11-11drm/i915/psr: stop using bitwise OR with booleans in wm_optimization_wa()Jani Nikula
Bitwise OR for booleans is a bit of an abuse. We can trivially drop the usage. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f7ea5854c9a306f56f4142f8d37d567ee2f768a7.1730201504.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/psr: add LATENCY_REPORTING_REMOVED() register bit helperJani Nikula
Drop the wa_16013835468_bit_get() function in favour of the register macro. It doesn't have to be so complicated, and we don't have to use the workaround name in everything that's related to it. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/22934fee1ea37c777c35e4b520d5f11b6cd953d0.1730201504.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/dp: demote source OUI read/write failure logging to debugJani Nikula
Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP sinks as well") started writing source OUI for non-eDP sinks as well, increasing the possibilities of hitting read/write failures either due to the sink behaviour or hotplug or whatever. Even before that, commit 3fb0501f0c07 ("drm/i915/display/dp: Reduce log level for SOURCE OUI write failures") already reduced write failures to info level when source OUI was just for eDP. Further reduce the log level to just debug. Switch to struct intel_display while at it. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3372 Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106162325.4065078-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann
Backmerging to get fixes from v6.12-rc7. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-11-11Merge tag 'drm-misc-next-2024-11-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.13: UAPI Changes: - Add 1X7X5 media-bus formats. Cross-subsystem Changes: - Maintainer updates for VKMS and IT6263. - Add media-bus-fmt for MEDIA_BUS_FMT_RGB101010_1X7X5_*. - Add IT6263 DT bindings and driver. Core Changes: - Add ABGR210101010 support to panic handler. - Use ATOMIC64_INIT in drm_file.c - Improve scheduler teardown documentation. Driver Changes: - Make mediatek compile on ARM again. - Add missing drm/drm_bridge.h header include, already in drm-next. - Small fixes and cleanups to vkms, bridge/it6505, panfrost, panthor. - Add panic support to nouveau for nv50+. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/344afe41-d27b-408a-8542-bfecfd3555f6@linux.intel.com
2024-11-09drm/rockchip: vop: Fix a dereferenced before check warningAndy Yan
The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077) Fixes: 5ddb0bd4ddc3 ("drm/atomic: Pass the full state to planes async atomic check and update") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241021072818.61621-1-andyshrk@163.com
2024-11-09rockchip/drm: vop2: add support for gamma LUTPiotr Zalewski
Add support for gamma LUT in VOP2 driver. The implementation was inspired by one found in VOP1 driver. Blue and red channels in gamma LUT register write were swapped with respect to how gamma LUT values are written in VOP1. Gamma LUT port selection was added before the write of new gamma LUT table. If the current SoC is rk356x, check if no other CRTC has gamma LUT enabled in atomic_check (only one video port can use gamma LUT at a time) and disable gamma LUT before the LUT table write. If the current SoC isn't rk356x, "seamless" gamma lut update is performed similarly to how it was done in the case of RK3399 in VOP1[1]. In seamless update gamma LUT disable before the write isn't necessary, check if no other CRTC has gamma LUT enabled is also not necessary, different register is being used to select gamma LUT port[2] and after setting DSP_LUT_EN bit, GAMMA_UPDATE_EN bit is set[3]. Gamma size is set and drm color management is enabled for each video port's CRTC except ones which have no associated device. Patch was tested on RK3566 (Pinetab2). When using userspace tools which set eg. constant color temperature no issues were noticed. When using userspace tools which adjust eg. color temperature the slight screen flicker is visible probably because of gamma LUT disable needed in the case of RK356x before gamma LUT write. Compare behaviour of eg.: ``` gammastep -O 3000 ``` To eg.: ``` gammastep -l 53:23 -t 6000:3000 ``` In latter case color temperature is slowly adjusted at the beginning which causes screen to slighly flicker. Then it adjusts every few seconds which also causes slight screen flicker. [1] https://lists.infradead.org/pipermail/linux-rockchip/2021-October/028132.html [2] https://lore.kernel.org/linux-rockchip/48249708-8c05-40d2-a5d8-23de960c5a77@rock-chips.com/ [3] https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c#L3437 Helped-by: Daniel Stone <daniel@fooishbar.org> Helped-by: Dragan Simic <dsimic@manjaro.org> Helped-by: Diederik de Haas <didi.debian@cknow.org> Helped-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Piotr Zalewski <pZ010001011111@proton.me> Reviewed-by: Andy Yan <andyshrk@163.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241101185545.559090-3-pZ010001011111@proton.me
2024-11-09drm/rockchip: vop2: Don't spam logs in atomic updateAndy Yan
Demote the error message to drm_dbg_kms to only print the message if the respective debug messages are enabled. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241028074140.382199-1-andyshrk@163.com
2024-11-09drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()Thomas Zimmermann
The code for detecting and updating the connector status in cdn_dp_pd_event_work() has a number of problems. - It does not aquire the locks to call the detect helper and update the connector status. These are struct drm_mode_config.connection_mutex and struct drm_mode_config.mutex. - It does not use drm_helper_probe_detect(), which helps with the details of locking and detection. - It uses the connector's status field to determine a change to the connector status. The epoch_counter field is the correct one. The field signals a change even if the connector status' value did not change. Replace the code with a call to drm_connector_helper_hpd_irq_event(), which fixes all these problems. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event") Cc: Chris Zhong <zyw@rock-chips.com> Cc: Guenter Roeck <groeck@chromium.org> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Andy Yan <andy.yan@rock-chips.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241105133848.480407-1-tzimmermann@suse.de
2024-11-09drm/xe/guc: Do not assert CTB state while sending MMIOTomasz Lis
During VF post-migration recovery, MMIO communication channel to GuC is used, despite CTB channel being enabled. This behavior is rooted in the save-restore architecture specification. Therefore, a VF driver cannot assert that CTB is disabled while sending MMIO messages to GuC. Such assertion needs to be PF only, or be removed. This patch simply removes the assertion. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Suggested-by: Michał Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107151357.1623733-2-tomasz.lis@intel.com
2024-11-09drm/xe/guc: Prefer GT oriented logs in submit codeMichal Wajdeczko
For better diagnostics, use xe_gt_err() instead of drm_err(). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107194741.2167-3-michal.wajdeczko@intel.com
2024-11-09drm/xe/guc: Prefer GT oriented asserts in submit codeMichal Wajdeczko
For better diagnostics, use xe_gt_assert() instead of xe_assert(). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107194741.2167-2-michal.wajdeczko@intel.com
2024-11-08drm/xe: improve hibernation on igpuMatthew Auld
The GGTT looks to be stored inside stolen memory on igpu which is not treated as normal RAM. The core kernel skips this memory range when creating the hibernation image, therefore when coming back from hibernation the GGTT programming is lost. This seems to cause issues with broken resume where GuC FW fails to load: [drm] *ERROR* GT0: load failed: status = 0x400000A0, time = 10ms, freq = 1250MHz (req 1300MHz), done = -1 [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 [drm] *ERROR* GT0: firmware signature verification failed [drm] *ERROR* CRITICAL: Xe has declared device 0000:00:02.0 as wedged. Current GGTT users are kernel internal and tracked as pinned, so it should be possible to hook into the existing save/restore logic that we use for dgpu, where the actual evict is skipped but on restore we importantly restore the GGTT programming. This has been confirmed to fix hibernation on at least ADL and MTL, though likely all igpu platforms are affected. This also means we have a hole in our testing, where the existing s4 tests only really test the driver hooks, and don't go as far as actually rebooting and restoring from the hibernation image and in turn powering down RAM (and therefore losing the contents of stolen). v2 (Brost) - Remove extra newline and drop unnecessary parentheses. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3275 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241101170156.213490-2-matthew.auld@intel.com
2024-11-08drm/xe: Add gt_id to xe_sched_job tracesLucas De Marchi
In order to uniquely identify the jobs, xe_sched_job tracepoints need to have the tuple (gt_id, guc_id). Find a "hole" where the next entry is unaligned and add one more field. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107060606.3130885-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-11-09Merge tag 'drm-xe-fixes-2024-11-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix ccs_mode setting for Xe2 and later (Balasubramani) - Synchronize ccs_mode setting with client creation (Balasubramani) - Apply scheduling WA for LNL in additional places as needed (Nirmoy) - Fix leak and lock handling in error paths of xe_exec ioctl (Matthew Brost) - Fix GGTT allocation leak leading to eventual crash in SR-IOV (Michal Wajdeczko) - Move run_ticks update out of job handling to avoid synchronization with reader (Lucas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4ffcebtluaaaohquxfyf5babpihmtscxwad3jjmt5nggwh2xpm@ztw67ucywttg
2024-11-09Merge tag 'drm-misc-fixes-2024-11-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: imagination: - Track PVR context per file - Break ref-counting cycle panel-orientation-quirks: - Fix matching Lenovo Yoga Tab 3 X90F panthor: - Lock VM array - Be strict about I/O mapping flags Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241108085058.GA37468@linux.fritz.box
2024-11-08drm/i915/xe3lpd: Use DMC wakelock by defaultGustavo Sousa
Although Bspec doesn't explicitly mentions that, as of Xe3_LPD, using DMC wakelock is the officially recommended way of accessing registers that would be off during DC5/DC6 and the legacy method (where the DMC intercepts MMIO to wake up the hardware) is to be avoided. As such, update the driver to use the DMC wakelock by default starting with Xe3_LPD. Since the feature is somewhat new to the driver, also allow disabling it via a module parameter for debugging purposes. For that, make the existing parameter allow values -1 (per-chip default), 0 (disabled) and 1 (enabled), similarly to what is done for other parameters. v2: - Describe -1 in the same area where 0 and 1 are described. (Luca) Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-16-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Sanitize enable_dmc_wl according to hardware supportGustavo Sousa
Instead of checking for HAS_DMC_WAKELOCK() multiple times, let's use it to sanitize the enable_dmc_wl parameter and use that variable when necessary. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-15-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Add and use HAS_DMC_WAKELOCK()Gustavo Sousa
A HAS_DMC_WAKELOCK() macro gives more semantic than openly checking the display version. Define it and use it where appropriate. v2: - Make this patch contain only the non-functional refactor. Functional changes related to including HAS_DMC() in the macro are done in upcoming changes. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-14-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Couple enable/disable with dynamic DC statesGustavo Sousa
Enabling and disabling the DMC wakelock should be done as part of enabling and disabling of dynamic DC states, respectively. We should not enable or disable DMC wakelock independently of DC states, otherwise we would risk ending up with an inconsistent state where dynamic DC states are enabled and the DMC wakelock is disabled, going against current recommendations and making MMIO transactions potentially slower. In future display IPs that could have a worse outcome if DMC trap implementation is completely removed. So, let's make things safer by tying stuff together, removing the independent calls, and also put warnings in place to detect inconsistent calls. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-13-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Deal with existing references when disablingGustavo Sousa
It is possible that there are active wakelock references at the time we are disabling the DMC wakelock mechanism. We need to deal with that in two ways: (A) Implement the missing step from Bspec: The Bspec instructs us to clear any existing wakelock request bit after disabling the mechanism. That gives a clue that it is okay to disable while there are locks held and we do not need to wait for them. However, since the spec is not explicit about it, we need still to get confirmation with the hardware team. Let's thus implement the spec and add a TODO note. (B) Ensure a consistent driver state: The enable/disable logic would be problematic if the following sequence of events would happen: 1. Function A calls intel_dmc_wl_get(); 2. Some function calls intel_dmc_wl_disable(); 3. Some function calls intel_dmc_wl_enable(); 4. Function A is done and calls intel_dmc_wl_put(). At (2), the refcount becomes zero and then (4) causes an invalid decrement to the refcount. That would cause some issues: - At the time between (3) and (4), function A would think that the hardware lock is held but it could not be really held until intel_dmc_wl_get() is called by something else. - The call made to (4) could cause the refcount to become zero and consequently the hardware lock to be released while there could be innocent paths trusting they still have the lock. To fix that, we need to keep the refcount correctly in sync with intel_dmc_wl_{get,put}() calls and retake the hardware lock when enabling the DMC wakelock with a non-zero refcount. One missing piece left to be handled here is the following scenario: 1. Function A calls intel_dmc_wl_get(); 2. Some function calls intel_dmc_wl_disable(); 3. Some function calls intel_dmc_wl_enable(); 4. Concurrently with (3), function A performs the MMIO in between setting DMC_WAKELOCK_CFG_ENABLE and asserting the lock with __intel_dmc_wl_take(). I'm mostly sure this would cause issues future display IPs if DMC trap implementation was completely removed. We need to check with the hardware team whether it would be safe to assert the hardware lock before setting DMC_WAKELOCK_CFG_ENABLE to avoid this scenario. If not, then we would have to deal with that via software synchronization. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-12-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Allow simpler syntax for single reg in range tablesGustavo Sousa
Allow simpler syntax for defining entries for single registers in range tables. That makes them easier to type as well as to read, allowing one to quickly tell whether a range actually refers to a single register or a "true range". Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-11-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Track registers touched by the DMCGustavo Sousa
There are extra registers that require the DMC wakelock when specific dynamic DC states are in place. Those are registers that are touched by the DMC and require DC exit for proper access. Add the range tables for them and use the correct one depending on the enabled DC state. v2: - Do not look into power domains guts (i.e. display->power.domains.dc_state). (Jani) - Come up with better names for variables containing register ranges. (Luca) - Keep a copy of dc_state in struct intel_dmc_wl. - Update commit message for a clearer explanation for the need of these new tables. Bspec: 71583 Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-10-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Rename lnl_wl_range to powered_off_rangesGustavo Sousa
In an upcoming change, we will add extra range tables for registers that are touched by the DMC during DC states. The range table that we are currently using is meant for registers that are powered off during DC states. As such, let's rename the table to powered_off_ranges and also add a comment regarding its purpose in the function that uses it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-9-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Extract intel_dmc_wl_reg_in_range()Gustavo Sousa
We will be using more than one range table in intel_dmc_wl_check_range(). As such, move the logic to a new function and name it intel_dmc_wl_reg_in_range(). Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-8-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Use sentinel item for range tablesGustavo Sousa
We are currently using ARRAY_SIZE() to iterate address ranges in intel_dmc_wl_check_range(). In upcoming changes, we will be using more than a single table and will extract the range checking logic into a dedicated function that takes a range table as argument. As we will not able to use ARRAY_SIZE() then, let's make range tables contain a sentinel item at the end and use that instead of having to pass the size as parameter in this future function. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-7-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Get wakelock when disabling dynamic DC statesGustavo Sousa
Bspec says that disabling dynamic DC states require taking the DMC wakelock to cause an DC exit before writing to DC_STATE_EN. Implement that. In fact, testing on PTL revealed we end up failing to exit DC5/6 without this step. Bspec: 71583 Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-6-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Check for non-zero refcount in release workGustavo Sousa
When the DMC wakelock refcount reaches zero, we know that there are no users and that we can do the actual release operation on the hardware, which is queued with a delayed work. The idea of the delayed work is to avoid performing the release if a new lock user appears (i.e. refcount gets incremented) in a very short period of time. Based on the above, the release work should bail out if refcount is non-zero (meaning new lock users appeared in the meantime), but our current code actually does the opposite: it bails when refcount is zero. That means that the wakelock is not released when it should be; and that, when the work is not canceled in time, it ends up being releasing when it should not. Fix that by inverting the condition. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-5-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Use non-sleeping variant of MMIO waitGustavo Sousa
Some display MMIO transactions for offsets in the range that requires the DMC wakelock happen in atomic context (this has been confirmed during tests on PTL). That means that we need to use a non-sleeping variant of MMIO waiting function. Implement __intel_de_wait_for_register_atomic_nowl() and use it when waiting for acknowledgment of acquire/release. v2: - No __intel_de_wait_for_register_atomic_nowl() wrapper to convert i915 to display. (Jani) - Add a quick explanation why DMC_WAKELOCK_CTL_TIMEOUT_US is defined in microseconds. (Luca) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-4-gustavo.sousa@intel.com
2024-11-08drm/xe: Mimic i915 behavior for non-sleeping MMIO waitGustavo Sousa
In upcoming display changes, we will modify the DMC wakelock MMIO waiting code to choose a non-sleeping variant implementation, because the wakelock is also taking in atomic context. While xe provides an explicit parameter (namely "atomic") to prevent xe_mmio_wait32() from sleeping, i915 does not and implements that behavior when slow_timeout_ms is zero. So, for now, let's mimic what i915 does to allow for display to use non-sleeping MMIO wait. In the future, we should come up with a better and explicit interface for this behavior in i915, at least while display code is not an independent entity with proper interfaces between xe and i915. v2: - Make the tone in comment the comment added in __intel_wait_for_register() more explanatory than a FIXME-like text. (Luca) Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-3-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of reg.regGustavo Sousa
The macro i915_mmio_reg_offset() is the proper interface to get a register's offset. Use that instead of looking directly at reg.reg. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-2-gustavo.sousa@intel.com
2024-11-08drm/amd/display: Handle dml allocation failure to avoid crashRyan Seto
[Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Ryan Seto <ryanseto@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: Use region6 size in fw_meta_infoJinZe Xu
[Why] If driver allocated region6 size is not same as the size in firmware, dmcub won't enable region6. [How] Use region6 size in dmcub_fw_meta instead of a constant value. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: JinZe Xu <jinze.xu@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: Update SPL Taps Required For Integer ScalingAustin Zheng
Number of taps is incorrectly being set when integer scaling is enabled. Taps required when src_rect != dst_rect previously not considered. Perform the calculations when integer scaling is enabled. Set taps to 1 if the scaling ratio is 1:1. Reviewed-by: Samson Tam <samson.tam@amd.com> Signed-off-by: Austin Zheng <Austin.Zheng@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: disabling p-state checks for DCN31 and DCN314Emily Nie
[Why] IGT displays Dmesg warnings which are likely false [How] Disabling p-state checks leading to this warning for DCN31 and DCN314 Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Emily Nie <Emily.Nie@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: always blank stream before disable crtcFudongwang
Garbage will show due to dig is on. So blank stream needed. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Fudongwang <Fudong.Wang@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: Read DP tunneling support only for DPIA endpointsAurabindo Pillai
Unconditionally reading DP tunneling support results in extraneous errors messages on certain devices. Fix this by guarding the DPCD read for DP tunneling support for USB4 DPIA endpoints. Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: Adding flag for forced MST blocked discoveryMeenakshikumar Somasundaram
[Why] Need a flag to force MST blocked discovery for certain branch devices. [How] Added a flag to force MST blocked discovery in struct dc_panel_patch. Reviewed-by: PeiChen Huang <peichen.huang@amd.com> Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-11-08drm/amd/display: Fix Panel Replay not update screen correctlyTom Chung
[Why] In certain use case such as KDE login screen, there will be no atomic commit while do the frame update. If the Panel Replay enabled, it will cause the screen not updated and looks like system hang. [How] Delay few atomic commits before enabled the Panel Replay just like PSR. Fixes: be64336307a6c ("drm/amd/display: Re-enable panel replay feature") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3686 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3682 Tested-By: Corey Hickey <bugfood-c@fatooh.org> Tested-By: James Courtier-Dutton <james.dutton@gmail.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-09 06:08:12 +0000