summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-05-08drm/i915/bios: Define VBT block 15 (Dot Clock Override Table) contentsVille Syrjälä
Define the contents of VBT block 15 (Dot Clock Override Table) The contents were reverse engineered by intuition. The gen2 stuff seems solid as I can verify that against real world VBT data. The gen3 stuff less so as all the gen3+ VBTs I have just filla the entire block with zeroes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-16-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define VBT block 12 (Driver Persistent Algorithm) contentsVille Syrjälä
Define the contents of VBT block 12 (Driver Persistent Algorithm). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-15-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define VBT block 10 (Mode Removal Table) contentsVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-14-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define VBT blocks 6,7,8 (register tables) contentsVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define VBT block 5 (Generic Mode Table)Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-12-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define VBT block 4 (Mode Support List) contentsVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define VBT block 3 (Display Toggle Option) contentsVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-10-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Add version notes for some blocksVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Flag "VBIOS only" VBT data blocksVille Syrjälä
Several data blocks are mean to be consumbed by VBIOS only. Flag them as such. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-8-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define "TV" child device handleVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-7-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Rename SDVO DTD blocks a bitVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-6-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Get rid of "LVDS" from all LFP data stuffVille Syrjälä
The LFP data applies to all kinds of display interfaces, so stop calling things by the "LVDS" name. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Indicate which VBT structures are based on EDIDVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Remove version number comment from DEVICE_HANDLE_EFP4Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915/bios: Define eDP DSC disable bitVille Syrjälä
There's a new "DSC disable" bit in the eDP VBT block. Define it. TODO: actually use it? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503122449.27266-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm: deprecate driver dateJani Nikula
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 <hamza.mahfooz@amd.com> Acked-by: Simon Ser <contact@emersion.fr> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240429164336.1406480-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915: Remove counter productive REGION_* wrappersVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502121423.1002-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-08drm/i915: Pass the region ID rather than a bitmask to HAS_REGION()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502121423.1002-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-08drm/i915: Fix HAS_REGION() usage in intel_gt_probe_lmem()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502121423.1002-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-08drm: xlnx: zynqmp_dpsub: Fix compilation errorAnatoliy Klymenko
Fix W=1 clang 19 compilation error in zynqmp_disp_layer_drm_formats(). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404260946.4oZXvHD2-lkp@intel.com/ Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: b0f0469ab662 ("drm: xlnx: zynqmp_dpsub: Anounce supported input formats") Link: https://patchwork.freedesktop.org/patch/msgid/20240426-dp-live-fmt-fix-v3-2-e904b5ae51d7@amd.com (cherry picked from commit c72211751870ffa2cff5d91834059456cfa7cbd5) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-05-08drm: xlnx: zynqmp_dpsub: Fix few function commentsAnatoliy Klymenko
Fix arguments description for zynqmp_disp_layer_find_live_format() and zynqmp_disp_layer_set_live_format(). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404260616.KFGDpCDN-lkp@intel.com/ Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: 1b5151bd3a2e ("drm: xlnx: zynqmp_dpsub: Set input live format") Link: https://patchwork.freedesktop.org/patch/msgid/20240426-dp-live-fmt-fix-v3-1-e904b5ae51d7@amd.com (cherry picked from commit 87f36e03c0f1d69245ad295309418e982c88fbe7) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-05-08drm/i915: pass dev_priv explicitly to PORT_DFT2_G4XJani Nikula
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0db8ee7b66b9660fc9fd80598257c6d36f0f506b.1714990089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915: pass dev_priv explicitly to PIPE_CRC_*Jani Nikula
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/849315d4417a2ce60e867648d9a040c5e96bc22d.1714990089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-08drm/i915: pass dev_priv explicitly to PIPE_CRC_CTLJani Nikula
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2ac4438aa885be9d0fcf5c697beee99a4cd2c23f.1714990089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-07drm/xe/ads: Use flexible-arrayLucas De Marchi
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 <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506141917.205714-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-05-07drm/xe: Fix xe_device.hMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240507110959.2747-4-michal.wajdeczko@intel.com
2024-05-07drm/xe: Don't rely on xe_force_wake.h to be included elsewhereMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240507110959.2747-3-michal.wajdeczko@intel.com
2024-05-07drm/xe: Don't rely on xe_assert.h to be included elsewhereMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240507110959.2747-2-michal.wajdeczko@intel.com
2024-05-07drm/xe: skip error capture when exec queue is killedTejas Upadhyay
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 <tejas.upadhyay@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430131229.2228809-1-tejas.upadhyay@intel.com
2024-05-07Revert "drm/i915: Remove extra multi-gt pm-references"Janusz Krzysztofik
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 <janusz.krzysztofik@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@linux.intel.com> Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references") Link: https://patchwork.freedesktop.org/patch/msgid/20240506180253.96858-2-janusz.krzysztofik@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-07drm/xe/vm_doc: Fix some typosFrancois Dugast
Fix some typos and add / remove / change a few words to improve readability and prevent some ambiguities. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506202950.109750-1-francois.dugast@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-07drm/connector: Add \n to message about demoting connector force-probesDouglas Anderson
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 <quic_abhinavk@quicinc.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240502153234.1.I2052f01c8d209d9ae9c300b87c6e4f60bd3cc99e@changeid
2024-05-07drm/msm/gen_header: allow skipping the validationDmitry Baryshkov
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 <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20240409120108.2303d0bd@canb.auug.org.au/ Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/592558/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-05-07drm/msm/a6xx: Cleanup indexed regs const'nessRob Clark
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 <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/592699/
2024-05-07drm/i915/bios: Fix parsing backlight BDB dataKarthikeyan Ramasubramanian
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: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit c286f6a973c66c0d993ecab9f7162c790e7064c8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-07drm/i915/bios: Fix parsing backlight BDB dataKarthikeyan Ramasubramanian
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: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2024-05-07drm/xe: Fix xe_mocs.hMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506205254.2659-1-michal.wajdeczko@intel.com
2024-05-06Reapply "drm/qxl: simplify qxl_fence_wait"Linus Torvalds
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 <rostedt@goodmis.org> Link: https://lore.kernel.org/all/20240502081641.457aa25f@gandalf.local.home/ Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Alex Constantino <dreaming.about.electric.sheep@gmail.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Timo Lindfors <timo.lindfors@iki.fi> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-05-06drm/i915/audio: Fix audio time stamp programming for DPChaitanya Kumar Borah
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: stable@vger.kernel.org # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Co-developed-by: Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430091825.733499-1-chaitanya.kumar.borah@intel.com (cherry picked from commit 8e056b50d92ae7f4d6895d1c97a69a2a953cf97b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-06drm/i915/gt: Automate CCS Mode setting during engine resetsAndi Shyti
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 <gnattuoc@me.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895 Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: <stable@vger.kernel.org> # v6.2+ Tested-by: Gnattu OC <gnattuoc@me.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Krzysztof Gibala <krzysztof.gibala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240426000723.229296-1-andi.shyti@linux.intel.com (cherry picked from commit 4cfca03f76413db115c3cc18f4370debb1b81b2b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-05-06drm/xe: Use ordered WQ for G2H handlerMatthew Brost
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: <stable@vger.kernel.org> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506034758.3697397-1-matthew.brost@intel.com
2024-05-06drm/xe/mocs: Add debugfs node to dump mocsJanga Rahul Kumar
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 <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Janga Rahul Kumar <janga.rahul.kumar@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503193902.2056202-3-janga.rahul.kumar@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-05-06drm/xe: Relocate regs_are_mcr functionJanga Rahul Kumar
Relocate regs_are_mcr funciton to a higher position in the file for improved visibility. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Janga Rahul Kumar <janga.rahul.kumar@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503193902.2056202-2-janga.rahul.kumar@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-05-06drm/xe: Refactor default device atomic settingsNirmoy Das
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 <michal.mrozek@intel.com> Reviewed-by: Oak Zeng <oak.zeng@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-6-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-05-06drm/xe: Add function to check if BO has single placementNirmoy Das
A new helper function xe_bo_has_single_placement() to check if a BO has single placement. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-5-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-05-06drm/xe: Introduce has_device_atomics_on_smem device infoNirmoy Das
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 <oak.zeng@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-4-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-05-06drm/xe: Move vm bind bo validation to a helper functionNirmoy Das
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 <matthew.brost@intel.com> Reviewed-by: Oak Zeng <oak.zeng@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-3-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-05-06drm/xe: Introduce has_atomic_enable_pte_bit device infoNirmoy Das
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 <oak.zeng@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-2-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-05-06drm/panel-edp: Add ID for KD KD116N09-30NH-A016Douglas Anderson
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 <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240502164746.1.Ia32fc630e5ba41b3fdd3666d9e343568e03c4f3a@changeid
2024-05-06drm/i915: pass dev_priv explicitly to PORT_ALPM_LFPS_CTLJani Nikula
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 <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f8a3bbade94258852b8129c5f5918fb06ceab54b.1714471597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-28 16:06:41 +0000