aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-02-08drm/amd/display: fix cursor offset on rotation 180Melissa Wen1-1/+1
Cursor gets clipped off in the middle of the screen with hw rotation 180. Fix a miscalculation of cursor offset when it's placed near the edges in the pipe split case. Cursor bugs with hw rotation were reported on AMD issue tracker: https://gitlab.freedesktop.org/drm/amd/-/issues/2247 The issues on rotation 270 was fixed by: https://lore.kernel.org/amd-gfx/[email protected]/ that partially addressed the rotation 180 too. So, this patch is the final bits for rotation 180. Reported-by: Xaver Hugl <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Fixes: 9d84c7ef8a87 ("drm/amd/display: Correct cursor position on horizontal mirror") Signed-off-by: Melissa Wen <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-02-08drm/amd/amdgpu: enable athub cg 11.0.3Kenneth Feng1-1/+3
enable athub cg on gc 11.0.3 Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Likun Gao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08Revert "drm/amd/display: disable S/G display on DCN 3.1.4"Alex Deucher1-0/+1
This reverts commit 9aa15370819294beb7eb67c9dcbf654d79ff8790. This is fixed now so we can re-enable S/G display on DCN 3.1.4. Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-02-08drm/amd/display: properly handling AGP aperture in vm setupAlex Deucher1-14/+28
Take into account whether or not the AGP aperture is enabled or not when calculating the system aperture. Fixes white screens with DCN 3.1.4. Based on a patch from Yifan Zhang <[email protected]> Cc: Yifan Zhang <[email protected]> Acked-by: Harry Wentland <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-02-08drm/amd/display: disable S/G display on DCN 3.1.2/3Alex Deucher1-2/+0
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352 Cc: [email protected] Cc: [email protected] Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: disable S/G display on DCN 2.1.0Alex Deucher1-1/+0
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352 Cc: [email protected] Cc: [email protected] Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/Elliot Berman3-3/+3
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h. This removes 1 of a few remaining Qualcomm-specific headers into a more approciate subdirectory under include/. Suggested-by: Bjorn Andersson <[email protected]> Signed-off-by: Elliot Berman <[email protected]> Reviewed-by: Guru Das Srinagesh <[email protected]> Acked-by: Mukesh Ojha <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-08drm/amdgpu/smu: skip pptable init under sriovJane Jian1-0/+6
sriov does not need to init pptable from amdgpu driver we finish it from PF Signed-off-by: Jane Jian <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08amd/amdgpu: remove test ib on hw ringJesseZhang2-2/+1
test ib function is not necessary on hw ring, so remove it. v2: squash in NULL check fix Signed-off-by: JesseZhang <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/finiGuilherme G. Piccoli1-1/+7
Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: <TASK> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/[email protected]/ [1] https://lore.kernel.org/amd-gfx/[email protected]/ Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)") Suggested-by: Christian König <[email protected]> Cc: Guchun Chen <[email protected]> Cc: Luben Tuikov <[email protected]> Cc: Mario Limonciello <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/pm/smu7: move variables to where they are usedAlex Deucher1-6/+8
Move variable declarations to where they are used. Fixes a segfault on smu7 V0 structures where some tables don't exist. Cc: Evan Quan <[email protected]> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2388 Fixes: b1a9557a7d00 ("drm/amd/pm: fulfill powerplay peak profiling mode shader/memory clock settings") Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/i915: Remove unused/wrong INF_UNIT_LEVEL_CLKGATELucas De Marchi1-3/+0
INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually used it can just be removed. Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915: Fix GEN8_MISCCPCTLLucas De Marchi4-14/+10
Register 0x9424 is not replicated on any platform, so it shouldn't be declared with REG_MCR(). Declaring it with _MMIO() is basically duplicate of the GEN7 version, so just remove the GEN8 and change all the callers to use the right functions. Old versions of the gen8 bspec page used to contain a table with MCR registers, apparently implying 0x9400 - 0x94ff registers were replicated. However that table went away and there is no information related to the ranges for gen8 anymore. Moreover the current behavior of the driver wouldn't do anything special for 0x9424 since there is no equivalent table in intel_gt_mcr.c: the driver would just fallback to intel_uncore_{read,write}(). Therefore, do not care about the possible special case for gen8 and just use the register as non-MCR for all the platforms. One place doing read + write is also converted to intel_uncore_rmw(). v2: Reword commit message adding the justification wrt gen8 Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly") Cc: Balasubramani Vivekanandan <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Gustavo Sousa <[email protected]> Cc: Matt Atwood <[email protected]> Cc: Ashutosh Dixit <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/amdgpu: Use the TGID for trace_amdgpu_vm_update_ptesFriedrich Vock1-1/+1
The pid field corresponds to the result of gettid() in userspace. However, userspace cannot reliably attribute PTE events to processes with just the thread id. This patch allows userspace to easily attribute PTE update events to specific processes by comparing this field with the result of getpid(). For attributing events to specific threads, the thread id is also contained in the common fields of each trace event. Reviewed-by: Christian König <[email protected]> Signed-off-by: Friedrich Vock <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amdgpu: Add unique_id support for GC 11.0.1/2Kent Russell1-0/+2
These can support unique_id, so create the sysfs file for them Signed-off-by: Kent Russell <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/pm: bump SMU 13.0.7 driver_if header versionEvan Quan2-15/+16
This can suppress the warning caused by version mismatch. Signed-off-by: Evan Quan <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: 3.2.222Aric Cyr1-1/+1
This version brings along the following: - FW 0.0.153.0 - Code re-organize for dc_link.c - Bug fixes on rotation, DRR and more Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Aric Cyr <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: avoid disable otg when dig was disabledJingwen Zhu1-6/+20
[Why] This is a workaround for an dcn3.15 hang that happens if otg dispclk is ramped while otg is on and stream enc is off. But this w/a should not trigger when we have a dig active. [How] Avoid disable otg when dig was disabled. [Note] Reapplying commit b07bb766b6d5 ("drm/amd/display: avoid disable otg when dig was disabled") which was incorrectly reverted. Reviewed-by: Josip Pavic <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Jingwen Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/pm: bump SMU 13.0.0 driver_if header versionEvan Quan2-3/+4
This can suppress the warning caused by version mismatch. Signed-off-by: Evan Quan <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/pm: add SMU 13.0.7 missing GetPptLimit message mappingEvan Quan1-0/+1
Add missing GetPptLimit message mapping. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amdgpu: fix enum odm_combine_mode mismatchArnd Bergmann3-15/+15
A conversion from 'bool' to 'enum odm_combine_mode' was incomplete, and gcc warns about this with many instances of display/dc/dml/dcn20/display_mode_vba_20.c:3899:44: warning: implicit conversion from 'enum <anonymous>' to 'enum odm_combine_mode' [-Wenum-conversion] 3899 | locals->ODMCombineEnablePerState[i][k] = false; Change the ones that we get a warning for, using the same numerical values to leave the behavior unchanged. Fixes: 5fc11598166d ("drm/amd/display: expand dml structs") Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/amdgpu: add complete header search pathRandy Dunlap1-0/+1
The path for the "mod_info_packet.h" header file is incomplete, so add its location to the header search path in the amdgpu Makefile. See on ARCH=alpha (275 times in one build). In file included from ../drivers/gpu/drm/amd/amdgpu/amdgpu.h:90, from ../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:43: ../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:62:10: fatal error: mod_info_packet.h: No such file or directory 62 | #include "mod_info_packet.h" | ^~~~~~~~~~~~~~~~~~~ compilation terminated. Fixes: 5b49da02ddbe ("drm/amd/display: Enable Freesync over PCon") Signed-off-by: Randy Dunlap <[email protected]> Cc: Signed-off-by: Sung Joon Kim <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amdgpu: Fix incorrect filenames in sysfs commentsKent Russell1-2/+2
This looks like a standard copy/paste mistake. Replace the incorrect serial_number references with product_name and product_model Signed-off-by: Kent Russell <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: fix cursor offset on rotation 180Melissa Wen1-1/+1
Cursor gets clipped off in the middle of the screen with hw rotation 180. Fix a miscalculation of cursor offset when it's placed near the edges in the pipe split case. Cursor bugs with hw rotation were reported on AMD issue tracker: https://gitlab.freedesktop.org/drm/amd/-/issues/2247 The issues on rotation 270 was fixed by: https://lore.kernel.org/amd-gfx/[email protected]/ that partially addressed the rotation 180 too. So, this patch is the final bits for rotation 180. Reported-by: Xaver Hugl <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Fixes: 9d84c7ef8a87 ("drm/amd/display: Correct cursor position on horizontal mirror") Signed-off-by: Melissa Wen <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: [FW Promotion] Release 0.0.153.0Anthony Koo1-1/+1
[Why&How] - Reduce reserved size from 9 to 8 dwords to reduce structure size and allow the union dmub_rb_cmd to fit into max 64-bytes cmd size Reviewed-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Anthony Koo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: Drop CONFIG_BACKLIGHT_CLASS_DEVICE ifdefsHans de Goede1-3/+0
Remove CONFI_BACKLIGHT_CLASS_DEVICE ifdef that was accidently introduced back. Reviewed-by: Hamza Mahfooz <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: break down dc_link.cWenjing Liu48-5056/+5430
[why] dc_link contains over 30k line of code, the decision is to break it down to files residing in link folder based on functionality. This change is the last break down change which will remove dc_link.c file after everything is broken down. [how] Move remaining dc_link.c functions into link_detection, link_dpms, link_validation, link_resource, and link_fpga and remove dc_link. Reviewed-by: George Shen <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Wenjing Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: Add HDMI manufacturer OUI and device id readLeo (Hanghong) Ma3-0/+43
[Why && How] Add support to read manufacturer OUI and device id from HDMI SCDC. Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Leo (Hanghong) Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: Fix null pointer deref error on rotationAurabindo Pillai1-4/+6
[Why&How] Fix the null pointer dererefence error when rotating the monitor on a DCN32 variant, which causes a call trace like: [ 42.469548] RIP: 0010:dcn20_program_front_end_for_ctx.cold+0x68/0x435 [amdgpu] [ 42.477140] Code: c1 4c 01 e8 48 8b b0 f0 01 00 00 e8 b6 1c 4c f9 42 f6 84 2b a0 0a 00 00 02 74 30 4d 03 ac 24 68 04 00 00 49 8b 85 f0 01 00 00 <83> b8 50 06 00 00 02 75 18 49 8b bd e0 02 00 00 48 8b 07 48 8b 40 [ 42.496225] RSP: 0018:ffffaf744326f6a0 EFLAGS: 00010282 [ 42.501539] RAX: 0000000000000000 RBX: ffff948765180000 RCX: 0000000000000000 [ 42.508797] RDX: 0000000000000000 RSI: ffffffffbaea5329 RDI: 00000000ffffffff [ 42.516055] RBP: ffff948701674400 R08: 0000000000000000 R09: ffffaf744326f538 [ 42.523312] R10: 0000000000000003 R11: ffff948a1d33ffe8 R12: ffff948708700000 [ 42.530569] R13: ffff94876e901180 R14: 0000000000000002 R15: 0000000000000001 [ 42.537825] FS: 00007f1c7c04a5c0(0000) GS:ffff948a05a80000(0000) knlGS:0000000000000000 [ 42.546055] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.551898] CR2: 0000000000000650 CR3: 0000000127dd6000 CR4: 00000000003506e0 [ 42.559155] Call Trace: [ 42.561645] <TASK> [ 42.563782] commit_planes_for_stream+0x8b1/0x1410 [amdgpu 2059945d14fb66c82032430b723fcb84d8250d46] [ 42.573298] dc_update_planes_and_stream+0x3f9/0x9f0 [amdgpu 2059945d14fb66c82032430b723fcb84d8250d46] [ 42.582986] amdgpu_dm_atomic_commit_tail+0x19be/0x3270 [amdgpu 2059945d14fb66c82032430b723fcb84d8250d46] [ 42.592944] ? vsnprintf+0x35e/0x550 [ 42.596593] commit_tail+0x94/0x130 [ 42.600146] drm_atomic_helper_commit+0x112/0x140 [ 42.604931] drm_atomic_commit+0x96/0xc0 [ 42.608922] ? drm_plane_get_damage_clips.cold+0x1c/0x1c [ 42.614326] drm_mode_atomic_ioctl+0x97b/0xb90 [ 42.618848] ? drm_atomic_set_property+0xb40/0xb40 [ 42.623633] drm_ioctl_kernel+0xc9/0x170 [ 42.627694] drm_ioctl+0x22f/0x410 [ 42.631157] ? drm_atomic_set_property+0xb40/0xb40 [ 42.636031] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu 2059945d14fb66c82032430b723fcb84d8250d46] [ 42.644537] __x64_sys_ioctl+0x90/0xd0 [ 42.648355] do_syscall_64+0x5b/0x80 [ 42.651992] ? do_syscall_64+0x67/0x80 [ 42.655808] ? exit_to_user_mode_prepare+0x1e/0x140 [ 42.660773] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 42.665913] RIP: 0033:0x7f1c7f31aaff [ 42.669550] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 [ 42.688635] RSP: 002b:00007fff29eca1a0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 42.696334] RAX: ffffffffffffffda RBX: 00007fff29eca250 RCX: 00007f1c7f31aaff [ 42.703591] RDX: 00007fff29eca250 RSI: 00000000c03864bc RDI: 0000000000000009 [ 42.710848] RBP: 00000000c03864bc R08: 000000000000000e R09: 000000000000000e [ 42.718104] R10: 0000000000000007 R11: 0000000000000246 R12: 00005643f0991d70 [ 42.725361] R13: 0000000000000009 R14: 00005643f22d0c50 R15: 00005643f0a74550 [ 42.732621] </TASK> Reviewed-by: Samson Tam <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: Do not commit pipe when updating DRRWesley Chalmers5-1/+29
[WHY] DRR and Pipe cannot be updated on the same frame, or else underflow will occur. Reviewed-by: Jun Lei <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Wesley Chalmers <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: Do not set DRR on pipe commitWesley Chalmers1-3/+0
[WHY] Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a pipe commit can cause underflow. [HOW] Defer all DPP adjustment requests till optimized_required is false. Reviewed-by: Jun Lei <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Wesley Chalmers <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/display: fix read errors pertaining to dp_lttpr_status_show()Hamza Mahfooz1-50/+22
Currently, it is likely that we will read the relevant LTTPR caps after link training has completed (which can cause garbage data to be read), however according to the DP 2.0 spec that should be done before link training has commenced. So, instead of reading the registers on demand, use the values provided to us by DC. Reviewed-by: Aurabindo Pillai <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08drm/amd/amdgpu: enable athub cg 11.0.3Kenneth Feng1-1/+3
enable athub cg on gc 11.0.3 Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Likun Gao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-02-08Revert "drm/i915/hwmon: Enable PL1 power limit"Ashutosh Dixit1-5/+0
This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610. 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and caused a major regression on ATSM. The change enabled the PL1 power limit but FW sets the default value of the PL1 limit to 0 which implies HW now works at minimum power and therefore the lowest effective frequency. This means all workloads now run slower resulting in even GuC FW load operations timing out, rendering ATSM unusable. A different solution to the original issue of the PL1 limit being disabled on ATSM is needed but till that is developed, revert 0349c41b0596. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8062 Signed-off-by: Ashutosh Dixit <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT listMatt Roper1-7/+7
The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround has 'BUS' style reset, indicating that it does not lose its value on engine resets. Furthermore, this register is part of the GT forcewake domain rather than the RENDER domain, so it should not be impacted by RCS engine resets. As such, we should implement this on the GT workaround list rather than an engine list. Bspec: 19219 Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915/pvc: Annotate two more workaround/tuning registers as MCRMatt Roper2-6/+12
XEHPC_LNCFMISCCFGREG0 and XEHPC_L3SCRUB are both in MCR register ranges on PVC (with HALFBSLICE and L3BANK replication respectively), so they should be explicitly declared as MCR registers and use MCR-aware workaround handlers. The workarounds/tuning settings should still be applied properly on PVC even without the MCR annotation, but readback verification on CONFIG_DRM_I915_DEBUG_GEM builds could potentitally give false positive "workaround lost on load" warnings on parts fused such that a unicast read targets a terminated register instance. Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly") Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915: Fix VBT DSI DVO port handlingVille Syrjälä1-10/+23
Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> (cherry picked from commit 118b5c136c04da705b274b0d39982bb8b7430fc5) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-02-08drm/i915/bios: set default backlight controller indexJani Nikula1-0/+1
With backlight controller set to -1 in intel_panel_init_alloc() to distinguish uninitialized values, and controller later being set only if it's present in VBT, we can end up with -1 for the controller: [drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 255, controller 4294967295 There's no harm if it happens on platforms that ignore controller due to only one backlight controller being present, like on VLV above, but play it safe. Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk") Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915/pxp: fix __le64 access to get rid of sparse warningJani Nikula1-1/+1
__le64 and friends should go through the cpu_to_* and *_to_cpu accessors: drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: expected restricted __le64 [assigned] [usertype] huc_base_address drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: got unsigned long long [assigned] [usertype] huc_phys_addr Cc: Tomas Winkler <[email protected]> Cc: Alan Previn <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Tomas Winkler <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915/gt: add sparse lock annotation to avoid warningsJani Nikula1-0/+2
Annotate intel_gt_mcr_lock() and intel_gt_mcr_unlock() to fix sparse warnings: drivers/gpu/drm/i915/gt/intel_gt_mcr.c:397:9: warning: context imbalance in 'intel_gt_mcr_lock' - wrong count at exit drivers/gpu/drm/i915/gt/intel_gt_mcr.c:412:6: warning: context imbalance in 'intel_gt_mcr_unlock' - unexpected unlock Cc: Matt Roper <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915/uncore: cast iomem to avoid sparse warningJani Nikula1-2/+3
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes through drmm. drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs Cc: Matt Roper <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915/dmc: drop "ucode" from function namesJani Nikula4-20/+20
The ucode part in the init, fini, suspend and resume function names is just unnecessary. Drop it. Cc: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-02-08drm/i915: Pick the backlight controller based on VBT on ICP+Ville Syrjälä1-3/+31
Use the second backlight controller on ICP+ if the VBT asks us to do so. On pre-MTP we also check the chicken bit to make sure the pins have been correctly muxed by the firmware. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-02-08drm/i915: Populate encoder->devdata for DSI on icl+Ville Syrjälä2-4/+14
We now have some eDP+DSI dual panel systems floating around where the DSI panel is the secondary LFP and thus needs to consult "panel type 2" in VBT in order to locate all the other panel type dependant stuff correctly. To that end we need to pass in the devdata to intel_bios_init_panel_late(), otherwise it'll just assume we want the primary panel type. So let's try to just populate the vbt.ports[] stuff and encoder->devdata for icl+ DSI panels as well. We can't do this on older platforms as there we risk a DSI port aliasing with a HDMI/DP port, which is a totally legal thing as the DSI ports live in their own little parallel universe. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-02-08drm/i915: Fix VBT DSI DVO port handlingVille Syrjälä1-10/+23
Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2023-02-07drm/etnaviv: show number of NN cores in GPU debugfs infoLucas Stach1-0/+2
For NPUs the number of NN cores is a interesting property, which is useful to show in the debugfs information. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Tomeu Vizoso <[email protected]>
2023-02-07drm/etnaviv: export client GPU usage statistics via fdinfoLucas Stach1-1/+42
This exposes a accumulated GPU active time per client via the fdinfo infrastructure. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]>
2023-02-07drm/etnaviv: allocate unique ID per drm_fileLucas Stach2-0/+15
Allows to easily track if several fd are pointing to the same execution context due to being dup'ed. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]>
2023-02-07drm/scheduler: track GPU active time per entityLucas Stach1-0/+6
Track the accumulated time that jobs from this entity were active on the GPU. This allows drivers using the scheduler to trivially implement the DRM fdinfo when the hardware doesn't provide more specific information than signalling job completion anyways. [Bagas: Append missing colon to @elapsed_ns] Signed-off-by: Bagas Sanjaya <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Andrey Grodzovsky <[email protected]>
2023-02-07drm/i915/pcode: Give the punit time to settle before fatally failingAravind Iddamsetty1-4/+31
During module load the punit might still be busy with its booting routines. During this time we try to communicate with it but we fail because we don't receive any feedback from it and we return immediately with a -EINVAL fatal error. At this point the driver load is "dramatically" aborted. The following error message notifies us about it. i915 0000:4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3) It would be enough to wait a little in order to give the punit the chance to come up bright and shiny, ready to interact with the driver. Wait up 10 seconds for the punit to settle and complete any outstanding transactions upon module load. If it still fails try again with a longer timeout, 180s, 3 minutes. If it still fails then return -EPROBE_DEFER, in order to give the punit a second chance. Even if these timers might look long, we should consider that the punit, depending on the platforms, might need long times to complete its routines. Besides we want to try anything possible to move forward before deciding to abort the driver's load. The issue has been reported in: https://gitlab.freedesktop.org/drm/intel/-/issues/7814 The changes in this patch are valid only and uniquely during boot. The common transactions with the punit during the driver's normal operation are not affected. Signed-off-by: Aravind Iddamsetty <[email protected]> Co-developed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.