summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-10-22drm/i915/dmc: Fixup TGL/ADL-S HRR event handler typeVille Syrjälä1-1/+16
TGL/ADL-S DMC firmware incorrectly uses the undelayed vblank trigger for the HRR event, when it should be using the delayed vblank trigger. Fixed DMC firmware was never relaesed and isntead the Windows driver just fixes this up by hand. Follow suit. Not that we actually enable the HRR event currently. But let's fix up the event ID, just in case someone ever needs to enable this. Tested-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251022100718.24803-3-ville.syrjala@linux.intel.com Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Imre Deak <imre.deak@intel.com> Tested-by: Imre Deak <imre.deak@intel.com>
2025-10-22drm/i915/dmc: Clear HRR EVT_CTL/HTP to zero on ADL-SVille Syrjälä1-1/+54
On ADL-S the main DMC HRR event DMC_EVT_CTL/HTP are never restored to their previous values during DC6 exit. This angers assert_dmc_loaded(), and basically makes the HRR handler unusable because we don't rewrite EVT_HTP when enabling DMC events. Let's just clear the HRR EVT_CTL/HTP to zero from the beginnning so that the expected value matches the post-DC6 reality. I suppose if we ever had actual use for HRR we'd have to both, reject HRR+PSR, and reprogram EVT_HTP when enabling the event. But for now we don't care about HRR so keeping both registers zeroed is fine. Cc: stable@vger.kernel.org Tested-by: Petr Vorel <pvorel@suse.cz> Fixes: 43175c92d403 ("drm/i915/dmc: Assert DMC is loaded harder") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15153 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251022100718.24803-2-ville.syrjala@linux.intel.com Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Imre Deak <imre.deak@intel.com> Tested-by: Imre Deak <imre.deak@intel.com>
2025-10-22drm/i915/dp: Simplify intel_dp_needs_8b10b_fec()Imre Deak1-3/+0
The intel_crtc_state::fec_enable check in intel_dp_needs_8b10b_fec() is redundant drop it: originally it ensured that the FEC enabled state for a CRTC other than the CRTC intel_dp_needs_8b10b_fec() called for is preserved, even if DSC is not enabled for the latter CRTC. The way FEC gets enabled for all the CRTCs on an 8b10b MST link is changed by commit 7c027070e98d ("drm/i915/dp_mst: Track DSC enabled status on the MST link") and commit 470b84af457e ("drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the link") depending on intel_dsc_enabled_on_link() in intel_dp_needs_8b10b_fec() instead of the above fec_enable check. Drop the check. Suggested-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20251020154438.416761-1-imre.deak@intel.com
2025-10-22drm/xe: Avoid PM wake reference during VF migrationMatthew Brost1-5/+0
Virtual Functions (VFs) do not use runtime PM. Avoid taking PM references during VF migration, as lockdep may get confused—VF migration occurs in the reclaim path, and waking a PM reference can trigger memory allocation warnings. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-4-matthew.brost@intel.com
2025-10-22drm/xe: Do not wake device during a GT resetMatthew Brost1-7/+12
Waking the device during a GT reset can lead to unintended memory allocation, which is not allowed since GT resets occur in the reclaim path. Prevent this by holding a PM reference while a reset is in flight. 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: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-3-matthew.brost@intel.com
2025-10-22drm/xe: Check return value of GGTT workqueue allocationMatthew Brost1-0/+3
Workqueue allocation can fail, so check the return value of the GGTT workqueue allocation and fail driver initialization if the allocation fails. 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: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-2-matthew.brost@intel.com
2025-10-22drm/xe/vf: Do not disable VF migration on ATS-MTomasz Lis1-4/+3
Our current support for the VF migration depends on the availability of the MEMIRQ rather than specific graphics version 20. Relax our early migration support checks to allow also use some older platforms like ATS-M for experiments and testing. Do not allow ADL, as supporting VF migration through MMIO interrupts would require additional changes in order to achieve reliability. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-5-tomasz.lis@intel.com
2025-10-22drm/xe: Assert that VF will never use fixed placement of BOsTomasz Lis1-0/+6
Most BOs do not care at which offset they will be accessed within GGTT or PPGTT. The few which do care, should be only created on PF, and mapped within GGTT. On VFs, mapping at fixed offset is prohibited, as each VF is granted access to a range of GGTT address space. Since fixed addresses of GGTT mapping can only be used on PF, add an assert which makes sure no attempt of fixed placement will happen for a driver probed on a VF. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-4-tomasz.lis@intel.com
2025-10-22drm/xe/vf: Fix GuC FW check for VF migration supportTomasz Lis3-23/+57
The check whether GuC ABI version meets requirements shall be performed after said version is received from GuC. Doing it in wrong order was triggering a warning: xe 0000:00:02.1: [drm] Assertion `gt->sriov.vf.guc_version.major` failed! With this change, dislodge part of the VF migration support check and moved it to after GuC handshake. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Tested-by: Matthew Brost <matthew.brost@intel.com> #v1 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6349 Fixes: ff1d2b5e3d28 ("drm/xe: Read VF GMD_ID with a specifically-allocated dummy GT") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-3-tomasz.lis@intel.com
2025-10-22drm/xe/vf: Revert logic of vf.migration.enabledTomasz Lis2-8/+5
Convert `enabled` property into `disabled`. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-2-tomasz.lis@intel.com
2025-10-22drm/xe/tests/pci: Check dma_mask_size, va_bits and vm_max_levelGustavo Sousa1-0/+7
Members dma_mask_size, va_bits and vm_max_level of struct xe_device_desc are all expected to be non-zero. Add checks for that in check_platform_desc(). Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251020-xe-kunit-dma_mask_size-va_bits-vm_max_level-v2-2-27b03971bc7e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-10-22drm/xe/tests/pci: Convert GT count check to general device checkGustavo Sousa1-5/+4
We already have check_graphics_ip() and check_media_ip() as general functions to check the IP descriptors. The check in check_platform_gt_count() is simple enough such that we can convert the function to a more general device check. In an upcoming change, we will also add some checks for other members of struct xe_device_desc. As such, rename check_platform_gt_count() to check_platform_desc(). While at it, use inline (unsigned int) casting of max_gt_per_tile to keep checks for each member localized; and use KUNIT_EXPECT_*() variants of the macros to allow multiple issues to be reported. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251020-xe-kunit-dma_mask_size-va_bits-vm_max_level-v2-1-27b03971bc7e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-10-22drm/vkms: Allow to configure connector status via configfsJosé Expósito3-0/+61
When a connector is created, add a `status` file to allow to update the connector status to: - 1 connector_status_connected - 2 connector_status_disconnected - 3 connector_status_unknown If the device is enabled, updating the status hot-plug or unplugs the connector. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-17-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to update the connector statusJosé Expósito2-0/+31
Implement the drm_connector_funcs.detect() callback to update the connector status by returning the status stored in the configuration. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-16-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure connector statusJosé Expósito3-2/+56
Allow to store the connector status in vkms_config_connector and add a getter and a setter functions as well a KUnit test. This change only adds the configuration, the connector status is not used yet. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-15-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure the default device creationJosé Expósito1-0/+7
Add a new module param to allow to create or not the default VKMS instance. Useful when combined with configfs to avoid having additional VKMS instances. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-13-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to attach connectors and encoders via configfsLouis Chauvet1-0/+62
Create a default subgroup at /config/vkms/connectors/connector/possible_encoders that will contain symbolic links to the possible encoders for the connector. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-12-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure multiple connectors via configfsLouis Chauvet1-0/+87
Create a default subgroup at /config/vkms/connectors to allow to create as many connectors as required. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-11-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to attach encoders and CRTCs via configfsLouis Chauvet1-0/+58
Create a default subgroup at /config/vkms/encoders/encoder/possible_crtcs that will contain symbolic links to the possible CRTCs for the encoder. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-10-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure multiple encoders via configfsLouis Chauvet1-0/+87
Create a default subgroup at /config/vkms/encoders to allow to create as many encoders as required. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-9-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to attach planes and CRTCs via configfsLouis Chauvet1-0/+58
Create a default subgroup at /config/vkms/planes/plane/possible_crtcs that will contain symbolic links to the possible CRTCs for the plane. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-8-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure CRTC writeback support via configfsLouis Chauvet1-0/+42
When a CRTC is created, add a `writeback` file to allow to enable or disable writeback connector support Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-7-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure multiple CRTCs via configfsLouis Chauvet1-0/+85
Create a default subgroup at /config/vkms/crtcs to allow to create as many CRTCs as required. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-6-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure the plane type via configfsLouis Chauvet1-0/+46
When a plane is created, add a `type` file to allow to set the type: - 0 overlay - 1 primary - 2 cursor Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-5-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Allow to configure multiple planes via configfsLouis Chauvet1-0/+88
Create a default subgroup at /config/vkms/planes to allow to create as many planes as required. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-4-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Add and remove VKMS instances via configfsLouis Chauvet5-1/+190
Allow to create, enable, disable and destroy VKMS instances using configfs. For the moment, it is not possible to add pipeline items, so trying to enable the device will fail printing an informative error to the log. Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Co-developed-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-3-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/vkms: Expose device creation and destructionJosé Expósito2-2/+22
In preparation for configfs support, expose vkms_create() and vkms_destroy(). Tested-by: Mark Yacoub <markyacoub@google.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Co-developed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20251016175618.10051-2-jose.exposito89@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-22drm/sitronix/st7571-i2c: remove unneeded semicolonMarcus Folkesson1-1/+1
Fix style issue reported by Kernel test robot. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202510221125.Cg0sM4xJ-lkp@intel.com/ Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20251022-st7571-semicolon-v1-1-83d322618ff4@gmail.com
2025-10-21drm/xe: Fix stolen size check to allow equal WOPCM sizeShuicheng Lin1-1/+1
On some platforms without dedicated stolen memory, the calculated stolen size may be exactly equal to the WOPCM size. The current assertion incorrectly requires it to be strictly greater, causing a false failure. Relax the check to allow equality. Fixes: 65369b8e2961 ("drm/xe: Change return type of detect_bar2_dgfx() from s64 to u64") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6359 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251016225506.2256127-2-shuicheng.lin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-21rust: driver: let probe() return impl PinInit<Self, Error>Danilo Krummrich3-25/+17
The driver model defines the lifetime of the private data stored in (and owned by) a bus device to be valid from when the driver is bound to a device (i.e. from successful probe()) until the driver is unbound from the device. This is already taken care of by the Rust implementation of the driver model. However, we still ask drivers to return a Result<Pin<KBox<Self>>> from probe(). Unlike in C, where we do not have the concept of initializers, but rather deal with uninitialized memory, drivers can just return an impl PinInit<Self, Error> instead. This contributes to more clarity to the fact that a driver returns it's device private data in probe() and the Rust driver model owns the data, manages the lifetime and - considering the lifetime - provides (safe) accessors for the driver. Hence, let probe() functions return an impl PinInit<Self, Error> instead of Result<Pin<KBox<Self>>>. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-10-21drm/amd/display: use GFP_NOWAIT for allocation in interrupt handlerAurabindo Pillai1-2/+2
schedule_dc_vmin_vmax() is called by dm_crtc_high_irq(). Hence, we cannot have the former sleep. Use GFP_NOWAIT for allocation in this function. Fixes: c210b757b400 ("drm/amd/display: fix dmub access race condition") Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c04812cbe2f247a1c1e53a9b6c5e659963fe4065) Cc: stable@vger.kernel.org
2025-10-21drm/amd/display: increase max link count and fix link->enc NULL pointer accessCharlene Liu2-1/+10
[why] 1.) dc->links[MAX_LINKS] array size smaller than actual requested. max_connector + max_dpia + 4 virtual = 14. increase from 12 to 14. 2.) hw_init() access null LINK_ENC for dpia non display_endpoint. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Reviewed-by: Chris Park <chris.park@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45) Cc: stable@vger.kernel.org
2025-10-21drm/amd/display: Fix NULL pointer dereferenceMeenakshikumar Somasundaram1-1/+2
[Why] On a mst branch with multi display setup, dc context is obselete after updating the first stream. Referencing the same dc context for the next stream update to fetch dc pointer leads to NULL pointer dereference. [How] Get the dc pointer from the link rather than context. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit dc69b48988b171d6ccb3a083607e4dff015e2c0d) Cc: stable@vger.kernel.org
2025-10-21gpu: nova-core: bitfield: Add support for custom visibilityJoel Fernandes2-32/+39
Add support for custom visibility to allow for users to control visibility of the structure and helpers. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Reviewed-by: Edwin Peer <epeer@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> [acourbot@nvidia.com: fix long lines warnings and typo in commit message.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251016151323.1201196-5-joelagnelf@nvidia.com>
2025-10-21gpu: nova-core: bitfield: Add support for different storage widthsJoel Fernandes2-37/+49
Previously, bitfields were hardcoded to use u32 as the underlying storage type. Add support for different storage types (u8, u16, u32, u64) to the bitfield macro. New syntax is: struct Name(<type ex., u32>) { ... } Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Reviewed-by: Edwin Peer <epeer@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> [acourbot@nvidia.com: fix long lines warnings.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251016151323.1201196-4-joelagnelf@nvidia.com>
2025-10-21gpu: nova-core: bitfield: Move bitfield-specific code from register! into ↵Joel Fernandes3-249/+332
new macro Move the bitfield-specific code from the register macro into a new macro called bitfield. This will be used to define structs with bitfields, similar to C language. Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Edwin Peer <epeer@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251016151323.1201196-3-joelagnelf@nvidia.com>
2025-10-21gpu: nova-core: register: use field type for Into implementationAlexandre Courbot2-16/+32
The getter method of a field works with the field type, but its setter expects the type of the register. This leads to an asymmetry in the From/Into implementations required for a field with a dedicated type. For instance, a field declared as pub struct ControlReg(u32) { 3:0 mode as u8 ?=> Mode; ... } currently requires the following implementations: impl TryFrom<u8> for Mode { ... } impl From<Mode> for u32 { ... } Change this so the `From<Mode>` now needs to be implemented for `u8`, i.e. the primitive type of the field. This is more consistent, and will become a requirement once we start using the TryFrom/Into derive macros to implement these automatically. Reported-by: Edwin Peer <epeer@nvidia.com> Closes: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/ Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251016151323.1201196-2-joelagnelf@nvidia.com>
2025-10-21drm/i915/display: Add no_psr_reason to PSR debugfsMichał Grzelak2-4/+21
There is no reason in debugfs why PSR has been disabled. Currently, without this information, IGT tests cannot decide whether PSR has been disabled on purpose or was it abnormal behavior. Because of it, the status of the test cannot be decided correctly. Add no_psr_reason field into struct intel_psr. Add no_psr_reason into struct intel_crtc_state to prevent staying out of sync when _psr_compute_config is not using computed state. Write the reason, e.g. PSR setup timing not met, into proper PSR debugfs file. Update the reason from new_crtc_state in intel_psr_pre_plane_update. Extend format of debugfs file to have reason when it is non-NULL. Clean the reason when PSR is activated. Refactor intel_psr_post_plane_update to use no_psr_reason along keep_disabled. Changelog: v10->v11 - update the reason from new_crtc_state instead of old_crtc_state [Jouni] v9->v10 - log reason into intel_crtc_state instead of intel_dp->psr [Jouni] - remove clearing no_psr_reason in intel_psr_compute_config [Jouni] - change update of no_psr_reason into more readable form [Jouni] v8->v9 - add no_psr_reason into struct intel_crtc_state [Jouni] - update the reason in intel_psr_pre_plane_update [Jouni] - elaborate on motivation of the feature in commit message [Sebastian] - copy changelog to commit message [Sebastian] v7->v8 - reset no_psr_reason at the begin of intel_psr_compute_config [Jouni] - restore keep_disabled [Jouni] - drop setting "Sink not reliable" [Jouni] - add WA number [Jouni] - if non-NULL, write no_psr_reason after PSR mode [Jouni] v6->v7 - rebase onto new drm-tip v5->v6 - move setting no_psr_reason to intel_psr_post_plane_update [Jouni] - remove setting no_psr_reason when disabling PSR is temporary [Jouni] v4->v5 - fix indentation errors from checkpatch v3->v4 - change format of logging workaround #1136 v2->v3 - change reason description to be more specific [Mika] - remove BSpecs number & WA number from being written into no_psr_reason - replace spaces with tabs v1->v2 - set other reasons than "PSR setup timing not met" - clear no_psr_reason when activating PSR. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20251002095640.1347990-2-michal.grzelak@intel.com
2025-10-21drm/xe/display: Make panic support work on vram.Maarten Lankhorst1-14/+36
Add a special path for VRAM using xe_res iterators to ensure a panic screen is shown on VRAM as well. Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251016075701.379023-3-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
2025-10-21drm/xe: Extract xe_bo_is_visible_vramMaarten Lankhorst2-1/+19
This will make it possible to call from xe_display code. Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://lore.kernel.org/r/20251016075701.379023-2-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-10-21drm/panic: Fix 24bit pixel crossing page boundariesJocelyn Falempe1-2/+44
When using page list framebuffer, and using RGB888 format, some pixels can cross the page boundaries, and this case was not handled, leading to writing 1 or 2 bytes on the next virtual address. Add a check and a specific function to handle this case. Fixes: c9ff2808790f0 ("drm/panic: Add support to scanout buffer as array of pages") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251009122955.562888-7-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-10-21drm/panic: Fix divide by 0 if the screen width < font widthJocelyn Falempe1-1/+1
In the unlikely case that the screen is tiny, and smaller than the font width, it leads to a divide by 0: draw_line_with_wrap() chars_per_row = sb->width / font->width = 0 line_wrap.len = line->len % chars_per_row; This will trigger a divide by 0 Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251009122955.562888-6-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-10-21drm/panic: Fix kmsg text drawing rectangleJocelyn Falempe1-1/+1
The rectangle height was larger than the screen size. This has no real impact. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251009122955.562888-5-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-10-21drm/panic: Fix qr_code, ensure vmargin is positiveJocelyn Falempe1-1/+4
Depending on qr_code size and screen size, the vertical margin can be negative, that means there is not enough room to draw the qr_code. So abort early, to avoid a segfault by trying to draw at negative coordinates. Fixes: cb5164ac43d0f ("drm/panic: Add a QR code panic screen") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251009122955.562888-4-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-10-21drm/panic: Fix overlap between qr code and logoJocelyn Falempe1-1/+1
The borders of the qr code was not taken into account to check if it overlap with the logo, leading to the logo being partially covered. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251009122955.562888-3-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-10-21drm/panic: Fix drawing the logo on a small narrow screenJocelyn Falempe1-0/+3
If the logo width is bigger than the framebuffer width, and the height is big enough to hold the logo and the message, it will draw at x coordinate that are higher than the width, and ends up in a corrupted image. Fixes: 4b570ac2eb54 ("drm/rect: Add drm_rect_overlap()") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251009122955.562888-2-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-10-21Merge tag 'drm-misc-next-2025-10-02' of ↵Simona Vetter123-1634/+4506
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19: UAPI Changes: Cross-subsystem Changes: - fbcon cleanups. - Make drivers depend on FB_TILEBLITTING instead of selecting it, and hide FB_MODE_HELPERS. Core Changes: - More preparations for rust. - Throttle dirty worker with vblank - Use drm_for_each_bridge_in_chain_scoped in drm's bridge code and assorted fixes. - Ensure drm_client_modeset tests are enabled in UML. - Rename ttm_bo_put to ttm_bo_fini, as a further step in removing the TTM bo refcount. - Add POST_LT_ADJ_REQ training sequence. - Show list of removed but still allocated bridges. - Add a simulated vblank interrupt for hardware without it, and add some helpers to use them in vkms and hypervdrm. Driver Changes: - Assorted small fixes, cleanups and updates to host1x, tegra, panthor, amdxdna, gud, vc4, ssd130x, ivpu, panfrost, panthor, sysfb, bridge/sn65dsi86, solomon, ast, tidss. - Convert drivers from using .round_rate() to .determine_rate() - Add support for KD116N3730A07/A12, chromebook mt8189, JT101TM023, LQ079L1SX01, raspberrypi 5" panels. - Improve reclocking on tegra186+ with nouveau. - Improve runtime pm in amdxdna. - Add support for HTX_PAI in imx. - Use a helper to calculate dumb buffer sizes in most drivers. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/b412fb91-8545-466a-8102-d89c0f2758a7@linux.intel.com
2025-10-21Merge tag 'drm-xe-next-2025-10-20' of ↵Dave Airlie143-2099/+4645
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Highlights: UAPI Changes: Loosen used tracking restriction (Matthew Auld) New SR-IOV debugfs structure and debugfs updates (Michal Wajdeczko) Hide the GPU madvise flag behind a VM_BIND flag (Thomas Hellström) Always expose VRAM provisioning data on discrete GPUs (Lukasz Laguna) Cross-subsystem Changes: Allow VRAM mappings for userptr when used with SVM (Matthew Brost) Driver Changes: Allow pinning of p2p dma-buf (Thomas Hellstrom) Use per-tile debugfs where appropriate (Michal Wajdeczko) Add documentation for Execution Queues (Niranjana Vishwanathapura) PF improvements (Michal Wajdeczko) VF migration recovery redesign work (Matthew Brost) User / Kernel VRAM partitioning (Piotr Piórkowski) Update Tile-based messages (Michal Wajdeczko) Allow configfs to disable specific GT types (Matt Roper) VF provisioning improvements (Michal Wajdeczko) Initial Xe3P support (Various people) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/aPXzbOb7eGbkgMrr@fedora
2025-10-21drm/xe/xe3p_lpm: Add special check in Media GT for Main GAMCTRLBalasubramani Vivekanandan2-0/+25
For Xe3p arch some subunits of an IP may be different. The GMD_ID register returns the Xe3p arch and dedicates the reserved field to mark possible subunit differences. Generally this is an under-the-hood implementation detail that drivers don't need to worry about, but the new Main_GAMCTRL may be enabled or not depending on those. Those reserved bits are described for Xe3p as: "If Zero, No special case to be handled. If Non-Zero, special case to be handled by Software agent.". That special case is defined per Arch. So if media version is 35, also check the additional reserved bits. To avoid confusion with the usual meaning of "reserved", define them as GMD_ID_SUBIP_FLAG_MASK. Bspec: 74201 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251019-xe3p-gamctrl-v1-2-ad66d3c1908f@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-21drm/xe/xe3p_lpm: Configure MAIN_GAMCTRL_QUEUE_SELECTBrian Welty5-1/+37
Starting from Xe3p, there are two different copies of some of the GAM registers: the traditional MCR variant at their old locations, and a new unicast copy known as "main_gamctrl." The Xe driver doesn't use these registers directly, but we need to instruct the GuC on which set it should use. Since the new, unicast registers are preferred (since they avoid the need for unnecessary MCR synchronization), set a new GuC feature flag, GUC_CTL_MAIN_GAMCTRL_QUEUES to convey this decision. A new helper function, xe_guc_using_main_gamctrl_queues(), is added for use in the 3 independent places that need to handle configuration of the new reporting queues. The mmio write to enable the main gamctl is only done during the general GuC upload. The gamctrl registers are not accessed by the GuC during hwconfig load. Last, the ADS blob for communicating the queue addresses contains both a DPA and GGTT offset. The GuC documentation states that DPA is now MBZ when using the MAIN_GAMCTRL queues. Bspec: 76445, 73540 Signed-off-by: Brian Welty <brian.welty@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251019-xe3p-gamctrl-v1-1-ad66d3c1908f@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 20:17:27 +0300