[WHY & HOW]
0 stream cases do not go through any DML validation which leaves DCN
clocks in unoptimized states.
If requesting DML validation or programming with 0 streams, program
DCN clocks to lowest DPM state.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY & HOW]
If the enable state is already as expect then just return.
Reviewed-by: Robin Chen <robin.chen@amd.com>
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This commit addresses multiple warnings by adding defensive
checks for NULL pointers before dereferencing them. The changes ensure
that pointers such as are validated, preventing potential undefined
behavior.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been
initialized, and dmc is thus NULL.
That would be the case when the call path is
intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as
intel_power_domains_init_hw() is called *before* intel_dmc_init().
However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()
conditionally, depending on the current and target DC states. At probe,
the target is disabled, but if DC6 is enabled, the function is called,
and an oops follows. Apparently it's quite unlikely that DC6 is enabled
at probe, as we haven't seen this failure mode before.
It is also strange to have DC6 enabled at boot, since that would require
the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and
the driver stopping / reprogramming the firmware is a poorly specified
sequence and as such unlikely an intentional BIOS behaviour. It's more
likely that BIOS is leaving an unintentionally enabled DC6 HW state
behind (without actually loading the required DMC firmware for this).
The tracking of the DC6 allowed counter only works if starting /
stopping the counter depends on the _SW_ DC6 state vs. the current _HW_
DC6 state (since stopping the counter requires the DC5 counter captured
when the counter was started). Thus, using the HW DC6 state is incorrect
and it also leads to the above oops. Fix both issues by using the SW DC6
state for the tracking.
This is v2 of the fix originally sent by Jani, updated based on the
first Link: discussion below.
Link: https://lore.kernel.org/all/3626411dc9e556452c432d0919821b76d9991217@intel.com
Link: https://lore.kernel.org/all/20260228130946.50919-2-ltao@redhat.com
Fixes: 88c1f9a4d3 ("drm/i915/dmc: Create debugfs entry for dc6 counter")
Cc: Mohammed Thasleem <mohammed.thasleem@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Tao Liu <ltao@redhat.com>
Cc: <stable@vger.kernel.org> # v6.16+
Tested-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260309164803.1918158-1-imre.deak@intel.com
Move the get/put/ref/flush_for_display calls to the display parent
interface.
For i915, move the hooks next to the other i915 core frontbuffer code in
i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for
the same.
Note: The intel_frontbuffer_flush() calls from
i915_gem_object_frontbuffer.c will partially route back to i915 core via
the parent interface. This is less than stellar.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed
through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might
as well call the functions directly, instead of going through display
code. This would only get worse with get/put being moved to the parent
interface.
To make this easier, convert overlay code from struct intel_frontbuffer
to struct i915_frontbuffer, and add a
i915_gem_object_frontbuffer_track() wrapper for clarity.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/829b304a6451e80fbce554bdc7788077245e803a.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to
i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer
functions are there already, and the relevant declarations are in
i915_gem_object_frontbuffer.h too.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/d779ef44b4b43feda9df63f1225a947a9cd23ba8.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
After commit 541c8f2468 ("dma-buf: detach fence ops on signal v3"),
dma_fence::ops == NULL can't be used to check if the fence is initialized.
Use dma_fence_was_initialized() instead.
v2:
- Use dma_fence_was_initialized() instead of open-coding it
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: Christian König <christian.koenig@amd.com>
Reported-by: Steven Price <steven.price@arm.com>
Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Fixes: 541c8f2468 ("dma-buf: detach fence ops on signal v3")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260309124318.222902-1-boris.brezillon@collabora.com
Replace the open-coded lsdc_dumb_map_offset() with the generic
drm_gem_ttm_dumb_map_offset() helper, which is functionally identical.
This removes unnecessary boilerplate and aligns with the DRM convention
for TTM-based drivers.
Signed-off-by: Amin GATTOUT <amin.gattout@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260308-master-v1-1-af32d71c8a1d@gmail.com
On successful vmap, set the page_mark_accessed_on_put and _dirty_on_put
flags in the gem-shmem object. Signals that the contained pages require
LRU and dirty tracking when they are being released back to SHMEM. Clear
these flags on put, so that the buffer remains quiet until the next call
to vmap. There's no means of handling dirty status in vmap as there's no
write-only mapping available.
Both flags, _accessed_on_put and _dirty_on_put, have always been part of
the gem-shmem object, but never used much. So most drivers did not track
the page status correctly.
Only the v3d and imagination drivers make limited use of _dirty_on_put. In
the case of imagination, move the flag setting from init to cleanup. This
ensures writeback of modified pages but does not interfere with the
internal vmap/vunmap calls. V3d already implements this behaviour.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> # gem-shmem
Acked-by: Frank Binns <frank.binns@imgtec.com> # imagination
Tested-by: Frank Binns <frank.binns@imgtec.com> # imagination
Link: https://patch.msgid.link/20260227114509.165572-7-tzimmermann@suse.de
Invoke folio_mark_accessed() in mmap page faults to add the folio to
the memory manager's LRU list. Userspace invokes mmap to get the memory
for software rendering. Compositors do the same when creating the final
on-screen image, so keeping the pages in LRU makes sense. Avoids paging
out graphics buffers when under memory pressure.
In pfn_mkwrite, further invoke the folio_mark_dirty() to add the folio
for writeback should the underlying file be paged out from system memory.
This rarely happens in practice, yet it would corrupt the buffer content.
This has little effect on a system's hardware-accelerated rendering, which
only mmaps for an initial setup of textures, meshes, shaders, etc.
v4:
- test for VM_FAULT_NOPAGE before marking folio as accessed (Boris)
- test page-array bounds in mkwrite handler (Boris)
v3:
- rewrite for VM_PFNMAP
v2:
- adapt to changes in drm_gem_shmem_try_mmap_pmd()
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-6-tzimmermann@suse.de
The current mmap page-fault handler requires some changes before it
can track folio access.
Call to folio_test_pmd_mappable() into the mmap page-fault handler
before calling drm_gem_shmem_try_map_pmd(). The folio will become
useful for tracking the access status.
Also rename drm_gem_shmem_try_map_pmd() to _try_insert_pfn_pmd()
and only pass the page fault and page-frame number. The new name and
parameters make it similar to vmf_insert_pfn_pmd().
No functional changes. If PMD mapping fails or is not supported,
insert a regular PFN as before.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-5-tzimmermann@suse.de
Return the exact VM_FAULT_ mask from drm_gem_shmem_try_map_pmd(). Gives
the caller better insight into the result. Return 0 if nothing was done.
If the caller sees VM_FAULT_NOPAGE, drm_gem_shmem_try_map_pmd() added a
PMD entry to the page table. As before, return early from the page-fault
handler in that case.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-4-tzimmermann@suse.de
Not having a page pointer in the mmap fault handler is an error. Test
for this situation and return VM_FAULT_SIGBUS if so. Also replace several
lookups of the page with a local variable.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-3-tzimmermann@suse.de
Replace shmem->base with obj in several places. It is the same value,
but the latter is easier to read.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260227114509.165572-2-tzimmermann@suse.de
Now that the two-pass notifier flow uses xe_vma_userptr_do_inval() for
the fence-wait + TLB-invalidate work, extend it to support a further
deferred TLB wait:
- xe_vma_userptr_do_inval(): when the embedded finish handle is free,
submit the TLB invalidation asynchronously (xe_vm_invalidate_vma_submit)
and return &userptr->finish so the mmu_notifier core schedules a third
pass. When the handle is occupied by a concurrent invalidation, fall
back to the synchronous xe_vm_invalidate_vma() path.
- xe_vma_userptr_complete_tlb_inval(): new helper called from
invalidate_finish when tlb_inval_submitted is set. Waits for the
previously submitted batch and unmaps the gpusvm pages.
xe_vma_userptr_invalidate_finish() dispatches between the two helpers
via tlb_inval_submitted, making the three possible flows explicit:
pass1 (fences pending) -> invalidate_finish -> do_inval (sync TLB)
pass1 (fences done) -> do_inval -> invalidate_finish
-> complete_tlb_inval (deferred TLB)
pass1 (finish occupied) -> do_inval (sync TLB, inline)
In multi-GPU scenarios this allows TLB flushes to be submitted on all
GPUs in one pass before any of them are waited on.
Also adds xe_vm_invalidate_vma_submit() which submits the TLB range
invalidation without blocking, populating a xe_tlb_inval_batch that
the caller waits on separately.
v3:
- Add locking asserts and notifier state asserts (Matt Brost)
- Update the locking documentation of the notifier
state members (Matt Brost)
- Remove unrelated code formatting changes (Matt Brost)
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260305093909.43623-5-thomas.hellstrom@linux.intel.com
xe_vm_range_tilemask_tlb_inval() submits TLB invalidation requests to
all GTs in a tile mask and then immediately waits for them to complete
before returning. This is fine for the existing callers, but a
subsequent patch will need to defer the wait in order to overlap TLB
invalidations across multiple VMAs.
Introduce xe_tlb_inval_range_tilemask_submit() and
xe_tlb_inval_batch_wait() in xe_tlb_inval.c as the submit and wait
halves respectively. The batch of fences is carried in the new
xe_tlb_inval_batch structure. Remove xe_vm_range_tilemask_tlb_inval()
and convert all three call sites to the new API.
v3:
- Don't wait on TLB invalidation batches if the corresponding batch
submit returns an error. (Matt Brost)
- s/_batch/batch/ (Matt Brost)
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260305093909.43623-4-thomas.hellstrom@linux.intel.com
In multi-GPU scenarios, asynchronous GPU job latency is a bottleneck if
each notifier waits for its own GPU before returning. The two-pass
mmu_interval_notifier infrastructure allows deferring the wait to a
second pass, so all GPUs can be signalled in the first pass before
any of them are waited on.
Convert the userptr invalidation to use the two-pass model:
Use invalidate_start as the first pass to mark the VMA for repin and
enable software signalling on the VM reservation fences to start any
gpu work needed for signaling. Fall back to completing the work
synchronously if all fences are already signalled, or if a concurrent
invalidation is already using the embedded finish structure.
Use invalidate_finish as the second pass to wait for the reservation
fences to complete, invalidate the GPU TLB in fault mode, and unmap
the gpusvm pages.
Embed a struct mmu_interval_notifier_finish in struct xe_userptr to
avoid dynamic allocation in the notifier callback. Use a finish_inuse
flag to prevent two concurrent invalidations from using it
simultaneously; fall back to the synchronous path for the second caller.
v3:
- Add locking asserts in notifier components (Matt Brost)
- Clean up newlines (Matt Brost)
- Update the userptr notifier state member locking documentation
(Matt Brost)
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260305093909.43623-3-thomas.hellstrom@linux.intel.com
During initial checks the ANX7625 bridge can be powered on before
setting up the Type-C port. At this point, when
anx7625_ocm_loading_check() checks if it can disable PD or not, it will
notice that typec_port is not set and disable PD, breaking orientation
and HPD handling. Unify the check between anx7625_ocm_loading_check()
anx7625_i2c_probe() and anx7625_typec_register() and check for the
presence of the "connector" node.
Fixes: 8ad0f7d2e6 ("drm: bridge: anx7625: implement message sending")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Xin Ji <xji@analogixsemi.com>
Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260211-anx7625-fix-pd-v1-1-1dd31451b06f@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The typec_set_*() functions do not tolerate being passed the NULL
typec_port instance. However, if CONFIG_TYPEC is enabled, but anx7625
DT node doesn't have the usb-c connector fwnode, then typec_port remains
NULL, crashing the kernel. Prevent calling typec_set_foo() functions by
checking that ctx->typec_port is not NULL in anx7625_typec_set_status().
Call trace:
typec_set_orientation+0x18/0x68 (P)
anx7625_typec_set_status+0x108/0x13c
anx7625_work_func+0x124/0x438
process_one_work+0x214/0x648
worker_thread+0x1b4/0x358
kthread+0x14c/0x214
ret_from_fork+0x10/0x20
Code: 910003fd a90153f3 aa0003f3 2a0103f4 (f9431400)
Fixes: f81455b2d3 ("drm: bridge: anx7625: implement minimal Type-C support")
Reported-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
[db: dropped chunk anx7625_typec_unregister(), wrote commit message]
Cc: Amit Kucheria <akucheri@qti.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260215-anx-fix-no-typec-v1-1-75172a5ca88b@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
When CONFIG_TYPEC is enabled, but USB_ROLE_SWITCH=m, the anx7625 driver
fails to link as built-in:
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_remove':
anx7625.c:(.text+0x6ec): undefined reference to `usb_role_switch_put'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_typec_set_status':
anx7625.c:(.text+0x3080): undefined reference to `usb_role_switch_set_role'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_probe':
anx7625.c:(.text+0x5368): undefined reference to `fwnode_usb_role_switch_get'
The problem is that both dependencies are optional in the sense of allowing
the anx7625 driver to call the exported interfaces to be used from a loadable
module, but cannot work for built-in drivers. It would be possible to handle
all nine combinations of the CONFIG_TYPEC and CONFIG_USB_ROLE_SWITCH tristate
options, but that does add a lot of complexity that seems unnecessary when
in reality any user of this driver would have both enabled anyway.
Turn both dependencies into hard 'depends on' here to only allow configurations
where it's possible to actually use them, and remove the misguided IS_REACHABLE()
check that did nothing here.
Fixes: f81455b2d3 ("drm: bridge: anx7625: implement minimal Type-C support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260304083604.724519-1-arnd@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
There are higher level sleep states that will cause RC6 state readout to
come back with an "in-reset" value. That is the case with NVL-P. As
those states are only possible if the GT is already in C6, let's just
translate the "reset value" into C6 when doing the readout.
Bspec: 67651
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-7-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Wa_16028780921 involves writing to a register that is locked by firmware
prior to driver loading and doesn't have any effect if implemented by
the KMD. Since the implementation of the workaround actually belongs
the firmware, just drop the ineffective implementation by the KMD.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-6-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Implement the KMD part of Wa_14026539277, which applies to NVL-P A0.
The KMD implementation is just one component of the workaround, which
also depends on Pcode to implement its part in order to be complete.
v2:
- Add FUNC(xe_rtp_match_not_sriov_vf) to skip applying the workaround
to SRIOV VFs. (Matt)
v3:
- Make Wa_14026539277 a device workaround instead of a GT workaround.
(Matt)
v4:
- Drop FUNC(xe_rtp_match_not_sriov_vf) and use a direct check with
IS_SRIOV_VF() in the workaround implementation. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v3
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-5-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Add support for matching platform-level stepping, which will be used for
an upcoming NVL-P workaround.
As support for reading platform-level stepping information is added only
as needed in the driver, add a warning when the rule finds a STEP_NONE
value, which is an indication that the driver is missing such a support.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-4-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
There will be a NVL-P workaround for which we will need to know the
platform-level stepping information in order to decide whether to apply
it or not.
While NVL-P has a nice mapping between the PCI revid and our symbolic
stepping enumeration, not all platforms are like that: (i) Some
platforms will have a single PCI revid used for a set platform level
steppings (ii) and some might even require specific mappings.
To make things simpler, let's include stepping information in the device
info only on demand, for those platforms where it is needed for
workaround checks.
v2:
- Call xe_step_platform_get() very early, to allow device workarounds
to use it in early stages of device initialization. (Matt)
Bspec: 74201
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v1
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-3-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The macros IS_PLATFORM_STEP() and IS_SUBPLATFORM_STEP() are unused since
commit 87c299fa3a ("drm/xe/guc: Port Wa_14014475959 to xe_wa and fix
it") and commit 63bbd800ff ("drm/xe/guc: Port
Wa_22012727170/Wa_22012727685 to xe_wa"), respectively, and we can drop
them now. Furthermore, in upcoming changes we will add logic to read
platform-level step information from PCI RevID and keeping those macros
around would potentially cause confusion.
v2:
- Cite commits that made the macros unused. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-2-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
In an upcoming change, we will add a member to struct xe_step_info to
represent the platform-level stepping. As such, we should stop assigning
the value returned by functions xe_step_pre_gmdid_get() and
xe_step_gmdid_get() directly to xe->info.step.
Since there are no other users for those functions, let's simply update
them to modify xe->info.step directly.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-1-be9c902ee34e@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The vga_get_uninterruptible() function can return an error if it fails to
set up VGA decoding for the requested device.
If VGA decoding is unavailable, we don't need to be careful to leave the
VGA emulation in a usable state, as vgacon will also be unable to get
access later on, so just skip over the VGA accesses and the vga_put() call
matching the failed vga_get_uninterruptible().
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1824
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260306151347.758836-1-Simon.Richter@hogyros.de
Similar to i915's commit cebc13de7e
("drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access"), except
that instead of putting the register on the allowlist for UMD to
program, the KMD is doing the programming at context initialization
based on a queue creation flag.
This is a recommended tuning setting for both gen12 and Xe_HP
platforms.
If a render queue is created with
DRM_XE_EXEC_QUEUE_SET_STATE_CACHE_PERF_FIX, COMMON_SLICE_CHICKEN3 will
be programmed at initialization to enable the render color cache to
key with BTP+BTI (binding table pool + binding table entry) instead of
just BTI (binding table entry). This enables the UMD to avoid emitting
render-target-cache-flush + stall-at-pixel-scoreboard every time a
binding table entry pointing to a render target is changed.
v2: Use xe_lrc_write_ring()
v3: Update xe_query.c to report availability
v4: Rename defines to add DISABLE_
v5: update commit message
v6: rebase
Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39982
Bspec: 73993, 73994, 72161, 31870, 68331
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patch.msgid.link/20260306075504.1288676-1-lionel.g.landwerlin@intel.com
Add support for the DSI LCD panel module found in Motorola Atrix 4G or
Droid X2 smartphones. Exact panel vendor and model are unknown hence panel
uses generic compatible based on board where it is used. The panel has a
540x960 resolution with 24 bit RGB per pixel.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260223064630.12720-3-clamor95@gmail.com
Add WaveShare 13.3inch 1920x1080 DSI Capacitive Touch Display support.
While the panel is described as DPI panel, it is part of a larger unit
in non-removable metal casing, so the actual internal configuration is
not known. The panel is attached to "waveshare,dsi2dpi" bridge via DT.
It is likely that internally, this panel is an LVDS panel, connected to
ICN6211 DSI-to-DPI bridge and then another unknown DPI-to-LVDS bridge.
Current device link is at https://www.waveshare.com/13.3inch-dsi-lcd.htm
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260117005028.126361-1-marek.vasut+renesas@mailbox.org
All of these GPIO calls are in process context where they can sleep.
Use the appropriate function call to allow use of this driver with GPIO
controllers that might sleep.
Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260303152124.187791-1-jkeeping@inmusicbrands.com
The taiguan-xti05101-01a is a 10.1" TFT panel. The MIPI controller on this
panel is the same as the other panels here, so add this panel to this
driver.
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260214085409.3489057-4-yelangyan@huaqin.corp-partner.google.com
The LXD M9189A panel is based on the EK79007AD3 DSI display controller.
It currently supports only 4 lane operation.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260218-drm-panel-ek79007ad3-v4-3-8ec448bf3ede@pengutronix.de
These are 60 Hz panels, but the currently set pixel clocks result in modes
with refresh rates of 63 Hz and ~63.41 Hz.
Adjust the clocks to target 60 Hz.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260218-mantix-pixel-clock-v1-1-c22c034ba5c1@puri.sm
Add support for the Powertip PH800480T032-ZHC19 7" (800x480) parallel
LCD-TFT panel.
Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260217123759.169317-2-florijan.plohl@norik.com
It's the responsibility of the DRM modeset driver to unprepare
and disable the panel. Doing so here leads to regulator underflows.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260216-mantix-shutdown-v1-1-d2e93a8ccc4c@puri.sm
This is now done by the DRM framework itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260215085140.20499-4-clamor95@gmail.com
Switch to use of drm_connector_helper_get_modes_fixed helper for get_modes
operation.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260215085140.20499-3-clamor95@gmail.com
Rename renesas,inversion to renesas,column-inversion according to schema.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260215085140.20499-2-clamor95@gmail.com
