Thomas Zimmermann
a16f6ba43d
drm/client: Add client free callback to unprepare fb_helper
...
Add free callback to struct drm_client_funcs. Invoke function to
free the client memory as part of the release process. Implement
free for fbdev emulation.
Fbdev emulation allocates and prepares client memory in
drm_fbdev_client_setup(). The release happens in fb_destroy from
struct fb_ops. Multiple implementations of this callback exist in
the various drivers that provide an fbdev implementation. Each of
them needs to follow the implementation details of the fbdev setup
code.
Adding a free callback for the client puts the unprepare and release
of the fbdev client in a single place.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com > # core, msm
Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com > # omapdrm
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com > # gma500
Acked-by: Alex Deucher <alexander.deucher@amd.com >
Link: https://lore.kernel.org/r/20251009132006.45834-2-tzimmermann@suse.de
2025-10-24 08:44:10 +02:00
Matthew Brost
ce29214ada
drm/xe: Check return value of GGTT workqueue allocation
...
Workqueue allocation can fail, so check the return value of the GGTT
workqueue allocation and fail driver initialization if the allocation
fails.
Fixes: dd08ebf6c3 ("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
(cherry picked from commit 1f1314e8e7 )
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
2025-10-23 20:09:30 -07:00
Matt Roper
6d5511e56b
drm/xe/xe3p_xpc: Add MCR steering for NODE and L3BANK ranges
...
The bspec was originally missing the information related to steering of
L3-related ranges. Now that a late-breaking spec update has added the
necessary information, implement the steering rules in the code. Note
that the sole L3BANK range is the same as the one used on Xe_LPG, so we
can re-use the existing table for that MCR type.
Bspec: 74418
Fixes: be614ea19d ("drm/xe/xe3p_xpc: Add MCR steering")
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com >
Link: https://lore.kernel.org/r/20251021224556.437970-3-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
2025-10-23 16:22:06 -07:00
Matt Roper
5fa20ff843
drm/xe/xe3p_xpc: Treat all PSMI MCR ranges as "INSTANCE0"
...
Early versions of the B-spec originally indicated that Xe3p_XPC had two
ranges of PSMI registers requiring MCR steering (one starting at 0xB500,
one starting at 0xB600), and that reads of registers in these ranges
required different grpid values to ensure that a non-terminated value is
obtained. A late-breaking spec update has simplified this; both ranges
can be safely steered to grpid=0 for reads.
Drop the "PSMI19" replication type and related code, and consolidate
both register ranges into a single entry in the "INSTANCE0" steering
table.
Bspec: 74418
Fixes: be614ea19d ("drm/xe/xe3p_xpc: Add MCR steering")
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com >
Link: https://lore.kernel.org/r/20251021224556.437970-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
2025-10-23 15:12:22 -07:00
Matthew Brost
9ea9b45701
drm/xe: Use SVM range helpers in PT layer
...
We have helpers SVM range start, end, and size. Use them in the PT
layer rather than directly looking at the struct.
Signed-off-by: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com >
Link: https://lore.kernel.org/r/20251022230122.922382-1-matthew.brost@intel.com
2025-10-23 13:57:49 -07:00
Matt Roper
402377bb25
drm/xe/cri: Setup MOCS table
...
CRI has a new MOCS table, but uses the same general ops as other Xe2/Xe3
platforms.
Bspec: 71582
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com >
Link: https://patch.msgid.link/20251021-cri-v1-3-bf11e61d9f49@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
2025-10-23 07:11:38 -07:00
Balasubramani Vivekanandan
5e0de2dfbc
drm/xe/cri: Add CRI platform definition
...
Add platform definition and PCI IDs for Crescent Island.
Other platforms use INTEL_VGA_DEVICE since they have a
PCI_BASE_CLASS_DISPLAY class. This is not the case for CRI, so just
match on devid, which should be sufficient.
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com >
Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com >
Link: https://lore.kernel.org/r/20251021-cri-v1-1-bf11e61d9f49@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
2025-10-23 03:46:03 -07:00
Matthew Auld
f558630a7d
drm/xe/migrate: skip bounce buffer path on xe2
...
Now that we support MEM_COPY we should be able to use the PAGE_COPY
mode, otherwise falling back to BYTE_COPY mode when we have odd
sizing/alignment.
v2:
- Use info.has_mem_copy_instr
- Rebase on latest changes.
v3 (Matt Brost):
- Allow various pitches including 1byte pitch for MEM_COPY
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-8-matthew.auld@intel.com
2025-10-23 10:48:41 +01:00
Matthew Auld
1e12dbae9d
drm/xe/migrate: support MEM_COPY instruction
...
Make this the default on xe2+ when doing a copy. This has a few
advantages over the exiting copy instruction:
1) It has a special PAGE_COPY mode that claims to be optimised for
page-in/page-out, which is the vast majority of current users.
2) It also has a simple BYTE_COPY mode that supports byte granularity
copying without any restrictions.
With 2) we can now easily skip the bounce buffer flow when copying
buffers with strange sizing/alignment, like for memory_access. But that
is left for the next patch.
v2 (Matt Brost):
- Use device info to check whether device should use the MEM_COPY
path. This should fit better with making this a configfs tunable.
- And with that also keep old path still functional on xe2 for possible
experimentation.
- Add a define for PAGE_COPY page-size.
v3 (Matt Brost):
- Fallback to an actual linear copy for pitch=1.
- Also update NVL.
BSpec: 57561
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-7-matthew.auld@intel.com
2025-10-23 10:48:39 +01:00
Matthew Auld
0171dcce33
drm/xe/migrate: trim batch buffer sizing
...
We have an extra two dwords, but it looks like we should only need one
for the extra bb_end. Likely this is just leftover from back when the
arb handling was moved into the ring programming.
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-6-matthew.auld@intel.com
2025-10-23 10:48:38 +01:00
Matthew Auld
1413329456
drm/xe/migrate: fix batch buffer sizing
...
In xe_migrate_vram() the copy can straddle page boundaries, so the len
might look like a single page, but actually accounting for the offset
within the page we will need to emit more than one PTE. Otherwise in
some cases the batch buffer will be undersized leading to warnings
later. We already have npages so use that instead.
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-5-matthew.auld@intel.com
2025-10-23 10:48:37 +01:00
Matthew Auld
fb188d8b00
drm/xe/migrate: fix chunk handling for 2M page emit
...
On systems with PAGE_SIZE > 4K the chunk will likely be rounded down to
zero, if say we have single 2M page, so one huge pte, since we also try
to align the chunk to PAGE_SIZE / XE_PAGE_SIZE, which will be 16 on 64K
systems. Make the ALIGN_DOWN conditional for 4K PTEs where we can
encounter gpu_page_size < PAGE_SIZE.
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-4-matthew.auld@intel.com
2025-10-23 10:48:36 +01:00
Matthew Auld
aaeef7a9c8
drm/xe/migrate: rework size restrictions for sram pte emit
...
We allow the input size to not be aligned to PAGE_SIZE, which leads to
various bugs in build_pt_update_batch_sram() for PAGE_SIZE > 4K systems.
For example if ptes is exactly one gpu_page_size then the chunk size is
rounded down to zero. The simplest fix looks to be forcing PAGE_SIZE
aligned inputs.
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-3-matthew.auld@intel.com
2025-10-23 10:48:34 +01:00
Matthew Auld
3c767f762b
drm/xe/migrate: fix offset and len check
...
Restriction here is pitch of 4bytes to match pixel width (32b), and hw
restriction where src and dst must be aligned to 64bytes. If any of that
is not possible then we need a bounce buffer.
Signed-off-by: Matthew Auld <matthew.auld@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Link: https://lore.kernel.org/r/20251022163836.191405-2-matthew.auld@intel.com
2025-10-23 10:48:33 +01:00
Jani Nikula
68aeace1b1
drm/xe/compat: drop include xe_device.h from i915_drv.h
...
xe_device.h and xe_device_has_flat_ccs() are no longer needed since
commit 3a5c5c472c ("drm/i915/display: add HAS_AUX_CCS() feature
check").
Reviewed-by: Jouni Högander <jouni.hogander@intel.com >
Link: https://lore.kernel.org/r/20251022121450.452649-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2025-10-23 12:06:01 +03:00
Jani Nikula
9987033428
drm/i915/display: drop a few unnecessary i915_drv.h includes
...
We've stopped using struct drm_i915_private in intel_fb.c and
skl_universal_plane.c, so we can drop the i915_drv.h includes.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com >
Link: https://lore.kernel.org/r/20251022121450.452649-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
2025-10-23 12:06:00 +03:00
Thomas Zimmermann
b36ca97592
drm/sysfb: Use new CRTC state in begin_fb_access
...
Retrieve the CRTC's new state with drm_atomic_get_new_crtc_state()
in drm_sysfb_plane_helper_begin_fb_access(). The blit function might
be incorrect otherwise.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Fixes: cb71de0925 ("drm/sysfb: Lookup blit function during atomic check")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Closes: https://lore.kernel.org/dri-devel/aPJrs7_u8KcalNsC@intel.com/
Cc: Thomas Zimmermann <tzimmermann@suse.de >
Cc: Javier Martinez Canillas <javierm@redhat.com >
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com >
Link: https://lore.kernel.org/r/20251020125227.41308-1-tzimmermann@suse.de
2025-10-23 10:36:14 +02:00
Ville Syrjälä
6b1209d158
drm/i915/dmc: Set DMC_EVT_CTL_ENABLE for disabled event handlers as well
...
DMC_EVT_CTL_ENABLE cannot be cleared once set. So currently
any event we never enable will have DMC_EVT_CTL_ENABLE cleared,
whereas any event which has been enabled even once will have
DMC_EVT_CTL_ENABLE set. For that reason assert_dmc_loaded() has
a special case to ignore any mismatches in DMC_EVT_CTL_ENABLE.
Eliminate the special case by always configuring DMC_EVT_CTL_ENABLE
based on the original firmware event definition. Now all
event handlers will have DMC_EVT_CTL_ENABLE set, whether or
not the event has been enabled in the past.
All disabled event handlers will still have the event type set
to DMC_EVENT_FALSE so they will not actually trigger despite
DMC_EVT_CTL_ENABLE being set.
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-4-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-22 21:40:00 +03:00
Ville Syrjälä
9c2503beb8
drm/i915/dmc: Fixup TGL/ADL-S HRR event handler type
...
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-22 21:39:42 +03:00
Ville Syrjälä
4df3b340ff
drm/i915/dmc: Clear HRR EVT_CTL/HTP to zero on ADL-S
...
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: 43175c92d4 ("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-22 21:39:16 +03:00
Imre Deak
3bd3763a74
drm/i915/dp: Simplify intel_dp_needs_8b10b_fec()
...
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 7c027070e9 ("drm/i915/dp_mst: Track DSC enabled status on the
MST link") and
commit 470b84af45 ("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-22 20:36:14 +03:00
Matthew Brost
f6c1345a85
drm/xe: Avoid PM wake reference during VF migration
...
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-22 09:10:07 -07:00
Matthew Brost
480b358e7d
drm/xe: Do not wake device during a GT reset
...
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: dd08ebf6c3 ("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-22 09:10:06 -07:00
Matthew Brost
1f1314e8e7
drm/xe: Check return value of GGTT workqueue allocation
...
Workqueue allocation can fail, so check the return value of the GGTT
workqueue allocation and fail driver initialization if the allocation
fails.
Fixes: dd08ebf6c3 ("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-22 09:10:05 -07:00
Tomasz Lis
13fb4b39e9
drm/xe/vf: Do not disable VF migration on ATS-M
...
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-22 16:00:50 +02:00
Tomasz Lis
9a940bb52d
drm/xe: Assert that VF will never use fixed placement of BOs
...
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-22 16:00:49 +02:00
Tomasz Lis
c886343397
drm/xe/vf: Fix GuC FW check for VF migration support
...
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: ff1d2b5e3d ("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-22 16:00:47 +02:00
Tomasz Lis
c94a7702d3
drm/xe/vf: Revert logic of vf.migration.enabled
...
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-22 16:00:45 +02:00
Gustavo Sousa
9d26a9beae
drm/xe/tests/pci: Check dma_mask_size, va_bits and vm_max_level
...
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-22 09:49:29 -03:00
Gustavo Sousa
5823d37a79
drm/xe/tests/pci: Convert GT count check to general device check
...
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-22 09:49:16 -03:00
José Expósito
f97180f094
drm/vkms: Allow to configure connector status via configfs
...
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-22 13:19:26 +02:00
José Expósito
466f43885a
drm/vkms: Allow to update the connector status
...
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-22 13:19:26 +02:00
José Expósito
6f00987f5c
drm/vkms: Allow to configure connector status
...
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-22 13:19:26 +02:00
José Expósito
8c29107a61
drm/vkms: Allow to configure the default device creation
...
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-22 13:19:26 +02:00
Louis Chauvet
64229b846a
drm/vkms: Allow to attach connectors and encoders via configfs
...
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-22 13:19:26 +02:00
Louis Chauvet
272acbca96
drm/vkms: Allow to configure multiple connectors via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
fad1138b23
drm/vkms: Allow to attach encoders and CRTCs via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
67d8cf92e1
drm/vkms: Allow to configure multiple encoders via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
95fa73787a
drm/vkms: Allow to attach planes and CRTCs via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
ee5c2c7d4b
drm/vkms: Allow to configure CRTC writeback support via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
3e4d5b30d2
drm/vkms: Allow to configure multiple CRTCs via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
187bc30625
drm/vkms: Allow to configure the plane type via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
2f1734ba27
drm/vkms: Allow to configure multiple planes via configfs
...
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-22 13:19:25 +02:00
Louis Chauvet
13fc9b9745
drm/vkms: Add and remove VKMS instances via configfs
...
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-22 13:19:25 +02:00
José Expósito
7965d1c535
drm/vkms: Expose device creation and destruction
...
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-22 13:19:25 +02:00
Marcus Folkesson
7e73cefd2b
drm/sitronix/st7571-i2c: remove unneeded semicolon
...
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-22 09:56:52 +02:00
Shuicheng Lin
2a407bc3ab
drm/xe: Fix stolen size check to allow equal WOPCM size
...
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: 65369b8e29 ("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-21 13:09:31 -04:00
Danilo Krummrich
0242623384
rust: driver: let probe() return impl PinInit<Self, Error>
...
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-21 18:40:48 +02:00
Aurabindo Pillai
72a1eb3cf5
drm/amd/display: use GFP_NOWAIT for allocation in interrupt handler
...
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: c210b757b4 ("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 c04812cbe2 )
Cc: stable@vger.kernel.org
2025-10-21 09:52:06 -04:00
Charlene Liu
bec947cbe9
drm/amd/display: increase max link count and fix link->enc NULL pointer access
...
[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 d7f5a61e1b )
Cc: stable@vger.kernel.org
2025-10-21 09:50:27 -04:00