aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-02-27drm/i915/hdcp: Allocate stream id after HDCP AKE stageSuraj Kandpal1-72/+65
Allocate stream id after HDCP AKE stage and not before so that it can also be done during link integrity check. Right now for MST scenarios LIC fails after hdcp enablement for this reason. --v2 -no need for else block in prepare_streams function [Ankit] --v3 -remove intel_hdcp argument from required_content_stream function [Ankit] Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-27drm/i915/hdcp: Don't enable HDCP1.4 directly from check_linkSuraj Kandpal1-9/+3
Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP1.4 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-27drm/i915/hdcp: Don't enable HDCP2.2 directly from check_linkSuraj Kandpal1-23/+2
Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP2.2 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. --v2 -Don't change the function prototype in this function [Ankit] Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-27drm/i915/hdcp: Extract hdcp structure from correct connectorSuraj Kandpal1-2/+5
Currently intel_hdcp is not being extracted from primary connector this patch fixes that. Fixes: 524240b231ea ("drm/i915/hdcp: Propagate aux info in DP HDCP functions") Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-27drm/mediatek: Filter modes according to hardware capabilityHsiao Chien Sung6-0/+116
We found a stability issue on MT8188 when connecting an external monitor in 2560x1440@144Hz mode. Checked with the designer, there is a function called "prefetch" which is working during VBP (triggered by VSYNC). If the duration of VBP is too short, the throughput requirement could increase more than 3 times and lead to stability issues. The mode settings that VDOSYS supports are mainly affected by clock rate and throughput, display driver should filter these settings according to the SoC's limitation to avoid unstable conditions. Since currently the mode filter is only available on MT8195 and MT8188 and they share the same compatible name, the reference number (8250) is hard coded instead of in the driver data. Signed-off-by: Hsiao Chien Sung <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-02-26drm/xe/guc: Handle timing out of signaled jobs gracefullyMatthew Brost1-13/+19
Timing out of signaled jobs can happen during regular operations (e.g. an exec queue closed immediately after last fence signaled). The TDR can pass the worker which free jobs. Rather than running through the TDR if signaled job is found, simply free it without any debug messages. Cc: Thomas Hellström <[email protected]> Reported-by: José Roberto de Souza <[email protected]> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1271 Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Tested-by: José Roberto de Souza <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: get rid of MAX_BINDSPaulo Zanoni1-4/+1
Mesa has been issuing a single bind operation per ioctl since xe.ko changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to issue every single bind operation it can in the same ioctl, it hits the MAX_BINDS assertion when running Vulkan conformance tests. Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 issues 960 bind operations in a single ioctl, it's the most I could find in the conformance suite. I don't see a reason to keep the MAX_BINDS restriction: it doesn't seem to be preventing any specific issue. If the number is too big for the memory allocations, then those will fail. Nothing related to num_binds seems to be using the stack. Let's just get rid of it. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746 Cc: Matthew Brost <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Use vmalloc for array of bind allocation in bind IOCTLMatthew Brost1-11/+14
Use vmalloc in effort to allow a user pass in a large number of binds in an IOCTL (mesa use case). Also use array allocations rather open coding the size calculation. v2: Use __GFP_ACCOUNT for allocations (Thomas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/amdkfd: Add partition id field to location_idLijo Lazar1-2/+3
On devices which have multi-partition nodes, keep partition id in location_id[31:28]. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Jonathan Kim <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu: reserve more memory for MES runtime DRAMTim Huang1-3/+10
This patch fixes a MES firmware boot failure issue when backdoor loading the MES firmware. MES firmware runtime DRAM size is changed to 512k, the driver needs to reserve this amount of memory in FB, otherwise adjacent memory will be overwritten by the MES firmware startup code. Signed-off-by: Tim Huang <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu: Enable gpu reset for S3 abort cases on Raven seriesPrike Liang1-20/+25
Currently, GPU resets can now be performed successfully on the Raven series. While GPU reset is required for the S3 suspend abort case. So now can enable gpu reset for S3 abort cases on the Raven series. Signed-off-by: Prike Liang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu/pm: Fix the power1_min_cap valueMa Jun5-25/+20
It's unreasonable to use 0 as the power1_min_cap when OD is disabled. So, use the same lower limit as the value used when OD is enabled. Fixes: 1958946858a6 ("drm/amd/pm: Support for getting power1_cap_min value") Signed-off-by: Ma Jun <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu: Do not program SQ_TIMEOUT_CONFIG in SRIOVVictor Lu1-0/+3
VF should not program this register. Signed-off-by: Victor Lu <[email protected]> Reviewed-by: Zhigang Luo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu: Fix ineffective ras_mask settingsStanley.Yang1-0/+1
Check amdgpu_ras_mask to fix ineffective ras_mask setting due to special asic without sram ecc enable but with poison supported. Signed-off-by: Stanley.Yang <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdkfd: Skip packet submission on fatal errorLijo Lazar6-7/+23
If fatal error is detected, packet submission won't go through. Return error in such cases. Also, avoid waiting for fence when fatal error is detected. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu: Add fatal error detected flagLijo Lazar3-0/+39
For a RAS error that needs a full reset to recover, set the fatal error status. Clear the status once the device is reset. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amd/display: Prevent potential buffer overflow in map_hw_resourcesSrinivasan Shanmugam1-0/+5
Adds a check in the map_hw_resources function to prevent a potential buffer overflow. The function was accessing arrays using an index that could potentially be greater than the size of the arrays, leading to a buffer overflow. Adds a check to ensure that the index is within the bounds of the arrays. If the index is out of bounds, an error message is printed and break it will continue execution with just ignoring extra data early to prevent the buffer overflow. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7 drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7 Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2") Cc: Rodrigo Siqueira <[email protected]> Cc: Roman Li <[email protected]> Cc: Qingqing Zhuo <[email protected]> Cc: Aurabindo Pillai <[email protected]> Cc: Tom Chung <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Suggested-by: Roman Li <[email protected]> Reviewed-by: Roman Li <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/amdgpu: Fix the runtime resume failure issueMa Jun1-0/+3
Don't set power state flag when system enter runtime suspend, or it may cause runtime resume failure issue. Fixes: 3a9626c816db ("drm/amd: Stop evicting resources on APUs in suspend") Signed-off-by: Ma Jun <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-26drm/mgag200: Add a workaround for low-latencyJocelyn Falempe3-0/+37
We found a regression in v5.10 on real-time server, using the rt-kernel and the mgag200 driver. It's some really specialized workload, with <10us latency expectation on isolated core. After the v5.10, the real time tasks missed their <10us latency when something prints on the screen (fbcon or printk) The regression has been bisected to 2 commits: commit 0b34d58b6c32 ("drm/mgag200: Enable caching for SHMEM pages") commit 4862ffaec523 ("drm/mgag200: Move vmap out of commit tail") The first one changed the system memory framebuffer from Write-Combine to the default caching. Before the second commit, the mgag200 driver used to unmap the framebuffer after each frame, which implicitly does a cache flush. Both regressions are fixed by this commit, which restore WC mapping for the framebuffer in system memory, and add a cache flush. This is only needed on x86_64, for low-latency workload, so the new kconfig DRM_MGAG200_IOBURST_WORKAROUND depends on PREEMPT_RT and X86. For more context, the whole thread can be found here [1] Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://lore.kernel.org/dri-devel/[email protected]/ # 1 Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/msm/adreno: Add A702 supportKonrad Dybcio3-9/+117
The A702 is a weird mix of 600 and 700 series.. Perhaps even a testing ground for some A7xx features with good ol' A6xx silicon. It's basically A610 that's been beefed up with some new registers and hw features (like APRIV!), that was then cut back in size, memory bus and some other ways. Add support for it, tested with QCM2290 / RB1. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/579752/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm: Fix page fault client detection on a660 family and a7xxConnor Abbott1-10/+85
Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/575918/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm: More fully implement devcoredump for a7xxConnor Abbott4-632/+1462
Use the vendor-provided snapshot headers to dump the contextless registers, shader blocks, and cluster registers. Still unimplemented are the GMU registers and "external core" registers, which would require more work because they use register spaces we don't have described in devicetree and dump registers from multiple spaces in a single list. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/575919/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm: Fix snapshotting a7xx indexed regsConnor Abbott1-2/+2
We were overwriting the last indexed reg (CP_ROQ) and we were snapshotting the same CP_MEMPOOL block twice instead of snapshotting CP_BV_MEMPOOL as intended. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/575920/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm: Import a7xx crashdump register lists from kgslConnor Abbott2-0/+1681
This imports these files as-is, the following commits will have to make slight changes to get them to compile because downstream uses un-namespaced enums that conflict with a6xx. However we should try as much as possible to stick to downstream's format to make importing new gens easier. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/575921/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm: add support for A750 GPUNeil Armstrong4-5/+49
Add support for the A750 GPU found on the SM8650 platform Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU doesn't have an HWCFG block but a separate register set. The A750 GPU info are added under the adreno_is_a750() macro and the ADRENO_7XX_GEN3 family id. Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/578693/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm/adreno: Add A305B supportLuca Weiss3-7/+26
Add support for the Adreno 305B GPU that is found in MSM8226(v2) SoC. Previously this was mistakenly claimed to be supported but using wrong a configuration. In MSM8226v1 there's also a A305B but with chipid 0x03000510 which should work with the same configuration but due to lack of hardware for testing this is not added. Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: David Heidelberg <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/575274/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm/a7xx: Fix LLC typoRob Clark1-1/+1
We'd miss actually activating LLC. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/573043/
2024-02-26drm/msm/adreno: Update generated headersRob Clark9-1738/+5589
This updates the GPU headers to latest from mesa, using gen_header.py (which is used to generate headers at bulid time for mesa), rather than headergen2 (which doesn't have proper support for A6XX vs A7XX register variants). Mostly just uninteresting churn, but there are a couple spots in a7xx paths which update REG_A6XX_foo to REG_A7XX_foo for registers which are a7xx specific. Cc: Connor Abbott <[email protected]> Signed-off-by: Rob Clark <[email protected]> Acked-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/574880/
2024-02-26drm/msm/adreno: Add support for SM7150 SoC machineDanila Tikhonov1-0/+22
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0, 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up to zero decimal places. Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn). Add this as machine = "qcom,sm7150", because speed-bin values are different from atoll (sc7180/sm7125). Signed-off-by: Danila Tikhonov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/578902/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/msm/a6xx: specify UBWC config for sc7180Dmitry Baryshkov1-2/+1
Historically the Adreno driver has not been updating memory configuration registers on a618 (SC7180 platform) implying that the default configuration is fine. After the rework performed in the commit 8814455a0e54 ("drm/msm: Refactor UBWC config setting") the function a6xx_calc_ubwc_config() still contained this shortcut and did not calculate UBWC configuration. However the function which now actually updates hardware registers, a6xx_set_ubwc_config(), doesn't contain such check. Rather than adding the check to a6xx_set_ubwc_config(), fill in the UBWC config for a618 (based on readings from SC7180). Reported-by: Leonard Lausen <[email protected]> Link: https://gitlab.freedesktop.org/drm/msm/-/issues/49 Fixes: 8814455a0e54 ("drm/msm: Refactor UBWC config setting") Cc: Connor Abbott <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/579113/ Signed-off-by: Rob Clark <[email protected]>
2024-02-26drm/ttm/tests: depend on UML || COMPILE_TESTChristian König1-2/+3
At least the device test requires that no other driver using TTM is loaded. So make those unit tests depend on UML || COMPILE_TEST to prevent people from trying them on bare metal. Signed-off-by: Christian König <[email protected]> Acked-by: Alex Deucher <[email protected]> Link: https://lore.kernel.org/all/20240219230116.77b8ad68@yea/
2024-02-26Merge drm/drm-fixes into drm-misc-fixesMaxime Ripard177-954/+1379
Sima needs a more recent release to apply a patch. Signed-off-by: Maxime Ripard <[email protected]>
2024-02-26drm/xe: Extend uAPI to query HuC micro-controler firmware versionFrancois Dugast1-4/+34
The infrastructure to query GuC firmware version is already in place. It is extended with a new micro-controller type to query the HuC firmware version. It can be used from user space to know if HuC is running. Cc: John Harrison <[email protected]> Cc: Francois Dugast <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26Merge drm/drm-next into drm-misc-next-fixesThomas Zimmermann657-5531/+37218
Backmerging from drm/drm-next to prepare drm-misc-next-fixes for the rest of the release cycle. Signed-off-by: Thomas Zimmermann <[email protected]>
2024-02-26drm/xe: Remove useless mem_access on PAT dumpsRodrigo Vivi1-10/+0
PAT dumps are already protected by the xe_pm_runtime_{get,put} around the debugfs call. So, these can be removed. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Convert gt_reset from mem_access to xe_pm_runtimeRodrigo Vivi1-3/+4
We need to ensure that device is in D0 on any kind of GT reset. We are likely already protected by outer bounds like exec, but if exec/sched ref gets dropped on a hang, we might transition to D3 before we are able to perform the gt_reset and recover. Suggested-by: Matthew Brost <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Remove mem_access from suspend and resume functionsRodrigo Vivi1-8/+0
At these points, we are sure that device is awake in D0. Likely in the middle of the transition, but awake. So, these extra protections are useless. Let's remove it and continue with the killing of xe_device_mem_access. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Convert gsc_work from mem_access to xe_pm_runtimeRodrigo Vivi1-2/+3
Let's directly use xe_pm_runtime_{get,put} instead of the mem_access helpers that are going away soon. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Remove useless mem_access protection for query ioctlsRodrigo Vivi1-4/+0
Every IOCTL is already protected on its outer bounds by xe_pm_runtime_{get,put} calls, so we can now remove these. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Convert hwmon from mem_access to xe_pm_runtime callsRodrigo Vivi1-12/+13
Continue the work to kill the mem_access in favor of a pure runtime pm. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Replace dma_buf mem_access per direct xe_pm_runtime callsRodrigo Vivi1-2/+3
Continue on the path to entirely remove mem_access helpers in favour of the direct xe_pm_runtime calls. This item is one of the direct outer bounds of the protection. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Runtime PM wake on every debugfs callRodrigo Vivi5-16/+66
Let's ensure our PCI device is awaken on every debugfs call. Let's increase the runtime_pm protection and start moving that to the outer bounds. Also let's remove the mem_access_{get,put} from where they are not needed anymore. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Remove mem_access from guc_pc callsRodrigo Vivi1-54/+10
We are now protected by init, sysfs, or removal and don't need these mem_access protections around GuC_PC anymore. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Runtime PM wake on every sysfs callRodrigo Vivi7-5/+129
Let's ensure our PCI device is awaken on every sysfs call. Let's increase the runtime_pm protection and start moving that to the outer bounds. For now, for the files with small number of attr functions, let's only call the runtime pm functions directly. For the hw_engines entries with many files, let's add the sysfs_ops wrapper. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Convert kunit tests from mem_access to xe_pm_runtimeRodrigo Vivi3-12/+22
Let's convert the kunit tests that are currently relying on xe_device_mem_access_{get,put} towards the direct xe_pm_runtime_{get,put}. While doing this we need to move the get/put calls towards the outer bounds of the tests to ensure consistency with the other usages of pm_runtime on the regular paths. v2: include xe_pm.h in tests/xe_mocs.c and sort the include block while at it. Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Runtime PM wake on every IOCTLRodrigo Vivi3-2/+51
Let's ensure our PCI device is awaken on every IOCTL entry. Let's increase the runtime_pm protection and start moving that to the outer bounds. v2: minor typo fix and renaming function to make it clear that is intended to be used by ioctl only. (Matt) v3: Make it NULL if CONFIG_COMPAT is not selected. Cc: Matthew Auld <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Convert mem_access assertion towards the runtime_pm stateRodrigo Vivi3-1/+29
The mem_access helpers are going away and getting replaced by direct calls of the xe_pm_runtime_{get,put} functions. However, an assertion with a warning splat is desired when we hit the worst case of a memory access with the device really in the 'suspended' state. Also, this needs to be the first step. Otherwise, the upcoming conversion would be really noise with warn splats of missing mem_access gets. v2: Minor doc changes as suggested by Matt Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26drm/xe: Document Xe PM componentRodrigo Vivi1-11/+98
Replace outdated information with a proper PM documentation. Already establish the rules for the runtime PM get and put that Xe needs to follow. Also add missing function documentation to all the "exported" functions. v2: updated after Francois' feedback. s/grater/greater (Matt) v3: detach D3 from runtime_pm remove opportunistic S0iX (Anshuman) Cc: Matthew Auld <[email protected]> Cc: Anshuman Gupta <[email protected]> Acked-by: Francois Dugast <[email protected]> Reviewed-by: Francois Dugast <[email protected]> #v2 Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-26Merge drm/drm-next into drm-misc-nextThomas Zimmermann657-5531/+37218
Backmerging to get drm-misc-next up to v6.8-rc6. Signed-off-by: Thomas Zimmermann <[email protected]>
2024-02-26drm/edid/firmware: Remove built-in EDIDsMaxime Ripard1-148/+14
The EDID firmware loading mechanism introduced a few built-in EDIDs that could be forced on any connector, bypassing the EDIDs it exposes. While convenient, this limited set of EDIDs doesn't take into account the connector type, and we can end up with an EDID that is completely invalid for a given connector. For example, the edid/800x600.bin file matches the following EDID: edid-decode (hex): 00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00 05 16 01 03 6d 1b 14 78 ea 5e c0 a4 59 4a 98 25 20 50 54 01 00 00 45 40 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80 14 00 15 d0 10 00 00 1e 00 00 00 ff 00 4c 69 6e 75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b 3d 24 26 05 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c 69 6e 75 78 20 53 56 47 41 0a 20 20 00 c2 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.3 Vendor & Product Identification: Manufacturer: LNX Model: 0 Made in: week 5 of 2012 Basic Display Parameters & Features: Analog display Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p Blank level equals black level Sync: Separate Composite Serration Maximum image size: 27 cm x 20 cm Gamma: 2.20 DPMS levels: Standby Suspend Off RGB color display First detailed timing is the preferred timing Color Characteristics: Red : 0.6416, 0.3486 Green: 0.2919, 0.5957 Blue : 0.1474, 0.1250 White: 0.3125, 0.3281 Established Timings I & II: DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz Standard Timings: DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz Detailed Timing Descriptors: DTD 1: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz (277 mm x 208 mm) Hfront 40 Hsync 128 Hback 88 Hpol P Vfront 1 Vsync 4 Vback 23 Vpol P Display Product Serial Number: 'Linux #0' Display Range Limits: Monitor ranges (GTF): 59-61 Hz V, 36-38 kHz H, max dotclock 50 MHz Display Product Name: 'Linux SVGA' Checksum: 0xc2 So, an analog monitor EDID. However, if the connector was an HDMI monitor for example, it breaks the HDMI specification that requires, among other things, a digital display, the VIC 1 mode and an HDMI Forum Vendor Specific Data Block in an CTA-861 extension. We thus end up with a completely invalid EDID, which thus might confuse HDMI-related code that could parse it. After some discussions on IRC, we identified mainly two ways to fix this: - We can either create more EDIDs for each connector type to provide a built-in EDID that matches the resolution passed in the name, and still be a sensible EDID for that connector type; - Or we can just prevent the EDID to be exposed to userspace if it's built-in. Or possibly both. However, the conclusion was that maybe we just don't need the built-in EDIDs at all and we should just get rid of them. So here we are. Acked-by: Daniel Vetter <[email protected]> Acked-by: Jani Nikula <[email protected]> Acked-by: Pekka Paalanen <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.