aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-05-08drm/i915/bios: Define VBT block 10 (Mode Removal Table) contentsVille Syrjälä1-0/+23
Define the contents of VBT block 10 (Mode Removal Table). There seem to be two variants: - 8 byte entries for desktop systems - 10 byte entries for mobile systems, with the extra panel_flags being a bitmask of LFPs It seems starting from HSW only the mobile variant is used anymore. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Define VBT blocks 6,7,8 (register tables) contentsVille Syrjälä1-0/+16
Define the contents for VBT blocks: - Block 6 (Extended MMIO Register Table) - Block 7 (IO Software Flag Table) - Block 8 (MMIO SWF Register Table) All of these use the same basic layout, with two known variants: - data_access_size==0xce -> offset,value tuples are u8,u8 - data_access_size==0x02 -> offset,value tuples are u32,u32 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Define VBT block 5 (Generic Mode Table)Ville Syrjälä1-0/+54
Define the contents of VBT block 5 (Generic Mode Table). Details were mostly gleaned from some VBIOS sources. There are apparently two variants of the block: ALM only vs. MGM, defined here as bdb_generic_mode_table_alm and bdb_generic_mode_table_mgm. And those are the only two platforms where I've seen this block. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Define VBT block 4 (Mode Support List) contentsVille Syrjälä1-0/+9
Define the contents of VBT block 4 (Mode Support List). Slightly crazy layout with a variable length list at the start, followed by the length of said list. No real idea what these "Intel mode numbers" really are. What I see in real world VBTs seems to be always the same list of 26 numbers, ranging between 0x30 and 0x84. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Define VBT block 3 (Display Toggle Option) contentsVille Syrjälä1-1/+11
Define the contents of VBT block 3 (Display Toggle Option). On modern VBTs this is just a single byte, but on ALM there is also some extra to do with toggle lists or something. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Add version notes for some blocksVille Syrjälä1-5/+5
Document which VBT blocks were defined in which BDB version, for the cases where the spec actually states this accurately. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Flag "VBIOS only" VBT data blocksVille Syrjälä1-5/+5
Several data blocks are mean to be consumbed by VBIOS only. Flag them as such. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Define "TV" child device handleVille Syrjälä1-0/+1
Child device 0x2 used to be "TV" until redefined to mean EFP5 in version 215. Add a define for the old meaning as well. Technically it was probably deprecated a lot before version 215 since native TV encoders were last seen on CTG, and SDVO was fully gone by HSW. So something like "???-164" might also be a reasonable way to document this, but no real harm in saying "???-214" since nothing else presumably occupied that bit in the meantime. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Rename SDVO DTD blocks a bitVille Syrjälä2-18/+17
The SDVO LVDS blocks are specifically about LVDS, so stick to naming that reflects that. This also makes the names match the spec. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Get rid of "LVDS" from all LFP data stuffVille Syrjälä5-111/+111
The LFP data applies to all kinds of display interfaces, so stop calling things by the "LVDS" name. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Indicate which VBT structures are based on EDIDVille Syrjälä2-61/+62
VBT reuses a bunch of EDID data structures. Flag those as such for clarity. I chose "bdb_edid_" as the namespace for these. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Remove version number comment from DEVICE_HANDLE_EFP4Ville Syrjälä1-1/+1
DEVICE_HANDLE_EFP4 has actually been in use since the very beginning, or at least something has been occupying that bit because old VBTs actually use it, and it definitely looks to be about external displays given how its used. So let's ignore what the current spec claims and remove the misleading version number comment. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2024-05-08drm/i915/bios: Define eDP DSC disable bitVille Syrjälä1-0/+1
There's a new "DSC disable" bit in the eDP VBT block. Define it. TODO: actually use it? Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-05-08drm: deprecate driver dateJani Nikula2-4/+5
The driver date serves no useful purpose, because it's hardly ever updated. The information is misleading at best. As described in Documentation/gpu/drm-internals.rst: The driver date, formatted as YYYYMMDD, is meant to identify the date of the latest modification to the driver. However, as most drivers fail to update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. Stop printing the driver date at init, and start returning the empty string "" as driver date through the DRM_IOCTL_VERSION ioctl. The driver date initialization in drivers and the struct drm_driver date member can be removed in follow-up. Reviewed-by: Hamza Mahfooz <[email protected]> Acked-by: Simon Ser <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-05-08drm/i915: Remove counter productive REGION_* wrappersVille Syrjälä3-9/+4
This extra macro level between the region IDs and their bitmasks just makes it harder to see what is used where. Get rid of the wrappers. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-05-08drm/i915: Pass the region ID rather than a bitmask to HAS_REGION()Ville Syrjälä3-4/+4
The name 'HAS_REGION()' suggests we are checking for a single region, so seem more sensible to pass in the region ID rather than a bitmask. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-05-08drm/i915: Fix HAS_REGION() usage in intel_gt_probe_lmem()Ville Syrjälä1-1/+1
HAS_REGION() takes a bitmask, not the region ID. This causes the GEM_BUG_ON() to assert that the SMEM region is available rather than the intended LMEM region. No real harm since SMEM is always available, but also not checking what was intended. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-05-08drm: xlnx: zynqmp_dpsub: Fix compilation errorAnatoliy Klymenko1-1/+1
Fix W=1 clang 19 compilation error in zynqmp_disp_layer_drm_formats(). Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Anatoliy Klymenko <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Fixes: b0f0469ab662 ("drm: xlnx: zynqmp_dpsub: Anounce supported input formats") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit c72211751870ffa2cff5d91834059456cfa7cbd5) Signed-off-by: Thomas Zimmermann <[email protected]>
2024-05-08drm: xlnx: zynqmp_dpsub: Fix few function commentsAnatoliy Klymenko1-2/+2
Fix arguments description for zynqmp_disp_layer_find_live_format() and zynqmp_disp_layer_set_live_format(). Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Anatoliy Klymenko <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Fixes: 1b5151bd3a2e ("drm: xlnx: zynqmp_dpsub: Set input live format") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 87f36e03c0f1d69245ad295309418e982c88fbe7) Signed-off-by: Thomas Zimmermann <[email protected]>
2024-05-08drm/i915: pass dev_priv explicitly to PORT_DFT2_G4XJani Nikula2-5/+5
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PORT_DFT2_G4X register macro. Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/0db8ee7b66b9660fc9fd80598257c6d36f0f506b.1714990089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-05-08drm/i915: pass dev_priv explicitly to PIPE_CRC_*Jani Nikula2-22/+24
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_CRC_RES_* register macros. Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/849315d4417a2ce60e867648d9a040c5e96bc22d.1714990089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-05-08drm/i915: pass dev_priv explicitly to PIPE_CRC_CTLJani Nikula2-7/+7
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_CRC_CTL register macro. Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/2ac4438aa885be9d0fcf5c697beee99a4cd2c23f.1714990089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-05-07drm/xe/ads: Use flexible-arrayLucas De Marchi1-1/+1
Zero-length arrays are deprecated and flexible arrays should be used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arrays Reported-by: kernel test robot <[email protected]> Reported-by: Julia Lawall <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-07drm/xe: Fix xe_device.hMichal Wajdeczko2-6/+2
Some explicit includes are needed only from the xe_device.c. And there is no need for redundant forward declarations. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-07drm/xe: Don't rely on xe_force_wake.h to be included elsewhereMichal Wajdeczko11-0/+11
While xe_force_wake.h is now included from the xe_device.h, we want to drop that include as we don't need it there. Explicitly include xe_force_wake.h where needed. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-07drm/xe: Don't rely on xe_assert.h to be included elsewhereMichal Wajdeczko5-0/+5
While xe_assert.h is now included and used by the xe_force_wake.h, we want to stop include xe_force_wake.h from xe_device.h as it's not needed there. Explicitly include xe_assert.h where needed. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-07drm/xe: skip error capture when exec queue is killedTejas Upadhyay1-2/+4
When user closes exec queue soon after job submission, we are generating error coredump. Instead check if exec queue is killed during job timeout then skip error coredump capture. V2: - Just skip error capture - MattB Signed-off-by: Tejas Upadhyay <[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-05-07Revert "drm/i915: Remove extra multi-gt pm-references"Janusz Krzysztofik1-0/+18
This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb. There was a patch supposed to fix an issue of illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle, reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform"). However, that fix occurred insufficient -- the issue was still reported by CI. That wakeref was released on exit from i915_gem_do_execbuffer(), then potentially before completion of the request and deactivation of its associated VMAs. Moreover, CI reports indicated that single-GT platforms also suffered sporadically from the same race. Since that issue was fixed by another commit f3c71b2ded5c ("drm/i915/vma: Fix UAF on destroy against retire race"), the changes introduced by that insufficient fix were dropped as no longer useful. However, that series resulted in another VMA UAF scenario now being triggered in CI. <4> [260.290809] ------------[ cut here ]------------ <4> [260.290988] list_del corruption. prev->next should be ffff888118c5d990, but was ffff888118c5a510. (prev=ffff888118c5a510) <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62 __list_del_entry_valid_or_report+0xb7/0xe0 .. <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0 ... <4> [260.291087] Call Trace: <4> [260.291089] <TASK> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915] <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915] <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915] <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [260.292301] </TASK> ... <4> [260.292506] ---[ end trace 0000000000000000 ]--- <4> [260.292782] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6ca3: 0000 [#1] PREEMPT SMP NOPTI <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: G W 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915] ... <4> [260.428756] Call Trace: <4> [260.431192] <TASK> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915] <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [639.411134] </TASK> ... <4> [639.449979] ---[ end trace 0000000000000000 ]--- We defer actually closing, unbinding and destroying a VMA until next idle point, or until the object is freed in the meantime. By postponing the unbind, we allow for the VMA to be reopened by the client, avoiding the work required to rebind the VMA. Starting from commit b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()"), we assume that as long as a GT is held idle, no VMA would be reopened while we destroy them. That assumption is no longer true in multi-GT configurations, where a VMA we reopen may be handled by a GT different from the one that we already keep active via its engine while we set up an execbuf request. Restoring the extra GT0 PM wakeref removed from i915_gem_do_execbuffer() processing path seems to fix this issue. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608 Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Nirmoy Das <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-07drm/xe/vm_doc: Fix some typosFrancois Dugast1-12/+12
Fix some typos and add / remove / change a few words to improve readability and prevent some ambiguities. Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-07drm/connector: Add \n to message about demoting connector force-probesDouglas Anderson1-1/+1
The debug print clearly lacks a \n at the end. Add it. Fixes: 8f86c82aba8b ("drm/connector: demote connector force-probes for non-master clients") Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Simon Ser <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240502153234.1.I2052f01c8d209d9ae9c300b87c6e4f60bd3cc99e@changeid
2024-05-07drm/msm/gen_header: allow skipping the validationDmitry Baryshkov3-4/+27
We don't need to run the validation of the XML files if we are just compiling the kernel. Skip the validation unless the user enables corresponding Kconfig option. This removes a warning from gen_header.py about lxml being not installed. Reported-by: Stephen Rothwell <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592558/ Signed-off-by: Rob Clark <[email protected]>
2024-05-07drm/msm/a6xx: Cleanup indexed regs const'nessRob Clark2-10/+13
These tables were made non-const in commit 3cba4a2cdff3 ("drm/msm/a6xx: Update ROQ size in coredump") in order to avoid powering up the GPU when reading back a devcoredump. Instead let's just stash the count that is potentially read from hw in struct a6xx_gpu_state_obj, and make the tables const again. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592699/
2024-05-07drm/i915/bios: Fix parsing backlight BDB dataKarthikeyan Ramasubramanian2-20/+4
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB contents") updated the backlight BDB data accordingly. This broke the parsing of backlight BDB data in VBT for versions 236 - 238 (both inclusive) and hence the backlight controls are not responding on units with the concerned BDB version. backlight_control information has been present in backlight BDB data from at least BDB version 191 onwards, if not before. Hence this patch extracts the backlight_control information for BDB version 191 or newer. Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236). Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251). v2: removed checking the block size of the backlight BDB data [vsyrjala: this is completely safe thanks to commit e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks")] Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents") Cc: [email protected] Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Karthikeyan Ramasubramanian <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit c286f6a973c66c0d993ecab9f7162c790e7064c8) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-07drm/i915/bios: Fix parsing backlight BDB dataKarthikeyan Ramasubramanian2-20/+4
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB contents") updated the backlight BDB data accordingly. This broke the parsing of backlight BDB data in VBT for versions 236 - 238 (both inclusive) and hence the backlight controls are not responding on units with the concerned BDB version. backlight_control information has been present in backlight BDB data from at least BDB version 191 onwards, if not before. Hence this patch extracts the backlight_control information for BDB version 191 or newer. Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236). Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251). v2: removed checking the block size of the backlight BDB data [vsyrjala: this is completely safe thanks to commit e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks")] Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents") Cc: [email protected] Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Karthikeyan Ramasubramanian <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by: Ville Syrjälä <[email protected]>
2024-05-07drm/xe: Fix xe_mocs.hMichal Wajdeczko1-4/+1
We don't need to include <linux/types.h>. We don't use struct xe_exec_queue here. We should sort forward declarations. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-06Reapply "drm/qxl: simplify qxl_fence_wait"Linus Torvalds1-45/+5
This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea. Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds" and further debugging points to a possible circular locking dependency between the console_owner locking and the worker pool locking. Reverting the commit allows Steve's VM to boot to completion again. [ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ] Reported-and-bisected-by: Steven Rostedt <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Acked-by: Maxime Ripard <[email protected]> Cc: Alex Constantino <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Timo Lindfors <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2024-05-06drm/i915/audio: Fix audio time stamp programming for DPChaitanya Kumar Borah1-105/+8
Intel hardware is capable of programming the Maud/Naud SDPs on its own based on real-time clocks. While doing so, it takes care of any deviations from the theoretical values. Programming the registers explicitly with static values can interfere with this logic. Therefore, let the HW decide the Maud and Naud SDPs on it's own. Cc: [email protected] # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Co-developed-by: Kai Vehmanen <[email protected]> Signed-off-by: Kai Vehmanen <[email protected]> Signed-off-by: Chaitanya Kumar Borah <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8e056b50d92ae7f4d6895d1c97a69a2a953cf97b) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-06drm/i915/gt: Automate CCS Mode setting during engine resetsAndi Shyti3-5/+7
We missed setting the CCS mode during resume and engine resets. Create a workaround to be added in the engine's workaround list. This workaround sets the XEHP_CCS_MODE value at every reset. The issue can be reproduced by running: $ clpeak --kernel-latency Without resetting the CCS mode, we encounter a fence timeout: Fence expiration time out i915-0000:03:00.0:clpeak[2387]:2! Fixes: 6db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload") Reported-by: Gnattu OC <[email protected]> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895 Signed-off-by: Andi Shyti <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Matt Roper <[email protected]> Cc: <[email protected]> # v6.2+ Tested-by: Gnattu OC <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Tested-by: Krzysztof Gibala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 4cfca03f76413db115c3cc18f4370debb1b81b2b) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-06drm/xe: Use ordered WQ for G2H handlerMatthew Brost3-1/+8
System work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-06drm/xe/mocs: Add debugfs node to dump mocsJanga Rahul Kumar4-32/+304
This is useful to check mocs configuration. Tests/Tools can use this debugfs entry to get mocs info. v2: Address review comments. Change debugfs output style similar to pat debugfs. (Lucas De Marchi) v3: rebase. v4: Address review comments. Use function pointer inside ops struct. Update Test-with links. Remove usage of flags wherever not required. (Lucas De Marchi) v5: Address review comments. Move register defines. Modify mocs info struct to avoid holes. (Luca De Marchi) Cc: Matt Roper <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: Janga Rahul Kumar <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-06drm/xe: Relocate regs_are_mcr functionJanga Rahul Kumar1-10/+10
Relocate regs_are_mcr funciton to a higher position in the file for improved visibility. Cc: Matt Roper <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: Janga Rahul Kumar <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-06drm/xe: Refactor default device atomic settingsNirmoy Das2-4/+35
The default behavior of device atomics depends on the VM type and buffer allocation types. Device atomics are expected to function with all types of allocations for traditional applications/APIs. Additionally, in compute/SVM API scenarios with fault mode or LR mode VMs, device atomics must work with single-region allocations. In all other cases device atomics should be disabled by default also on platforms where we know device atomics doesn't on work on particular allocations types. v3: fault mode requires LR mode so only check for LR mode to determine compute API(Jose). Handle SMEM+LMEM BO's migration to LMEM where device atomics is expected to work. (Brian). v2: Fix platform checks to correct atomics behaviour on PVC. Acked-by: Michal Mrozek <[email protected]> Reviewed-by: Oak Zeng <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-06drm/xe: Add function to check if BO has single placementNirmoy Das2-0/+15
A new helper function xe_bo_has_single_placement() to check if a BO has single placement. Reviewed-by: José Roberto de Souza <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-06drm/xe: Introduce has_device_atomics_on_smem device infoNirmoy Das2-0/+4
Add has_device_atomics_on_smem to specify that a device supports device atomics on system memory. Currently XE2 supports this so set this for XE2. v2: Set has_device_atomics_on_smem for all platform but PVC. Reviewed-by: Oak Zeng <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-06drm/xe: Move vm bind bo validation to a helper functionNirmoy Das1-34/+43
Move vm bind bo validation to a helper function to make the xe_vm_bind_ioctl() more readable. v2: Capture ret value of xe_vm_bind_ioctl_validate_bo(Matt B). Remove redundant coh_mode param. Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Oak Zeng <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-06drm/xe: Introduce has_atomic_enable_pte_bit device infoNirmoy Das3-0/+6
Add has_atomic_enable_pte_bit to specify that a device has PTE_AE bit in its PTE feild. Currently XE2 and PVC supports this so set this for those two. This will help consolidate setting atomic access bit in PTE logic which is spread between multiple files. Reviewed-by: Oak Zeng <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-06drm/panel-edp: Add ID for KD KD116N09-30NH-A016Douglas Anderson1-0/+1
As evidenced by in-field reports, this panel shipped on pompom but we never added the ID and thus we're stuck w/ conservative timings. The panel was part of early patches but somehow got left off in the end. :( Add it in now. For future reference, EDID from this panel is: 00ffffffffffff002c82121200000000 321e0104951a0e780ae511965e55932c 19505400000001010101010101010101 010101010101a41f5686500084302820 55000090100000180000000000000000 00000000000000000000000000000000 000000000000000000000000000000fe 004b443131364e3039333041313600f6 We use the ASCII string from decoding the EDID ("KD116N0930A16") as the panel name. Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240502164746.1.Ia32fc630e5ba41b3fdd3666d9e343568e03c4f3a@changeid
2024-05-06drm/i915: pass dev_priv explicitly to PORT_ALPM_LFPS_CTLJani Nikula2-2/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PORT_ALPM_LFPS_CTL register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f8a3bbade94258852b8129c5f5918fb06ceab54b.1714471597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-05-06drm/i915: pass dev_priv explicitly to PORT_ALPM_CTLJani Nikula2-3/+5
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PORT_ALPM_CTL register macro. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/86e8f5649c822ff6fa0502ad88964bfcb269c6c5.1714471597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-05-06FIXME drm/i915: pass dev_priv explicitly to ALPM_CTL2Jani Nikula1-1/+1
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the ALPM_CTL2 register macro. Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/09acf2751cfd2f524e6ba97c3ac285495eae5c86.1714471597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.