| Age | Commit message (Collapse) | Author |
|---|
|
Move the parent interface at one step lower level, allowing
deduplication.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/0cb4077a5a39274c7a2dae95d548d7b33365a518.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add the initial plane handling functions to the display parent
interface. Add the call wrappers in dedicated intel_initial_plane.c
instead of intel_parent.c, as we'll be refactoring the calls heavily.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/ab91c891677fe2bb83bf5aafa5ee984b2442b84d.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Follow the more naturally flowing naming. Rename both the header and the
vblank wait function.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/32c2d68a9ae7d2262ad2c63e873e522e67bc78df.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Follow i915 with the more naturally flowing naming.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/62eb56fe348a8fe7c17333d784192da701367cc7.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_plane_initial.c is i915 specific. Move it to i915 core. Start
renaming stuff with the slightly more natural "initial plane" rather
than "plane initial".
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/cdad733192690a61fbb44921c57fc68cc1cd809f.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Pass the correct alignment from intel_fb_pin_to_ggtt() down to
__xe_pin_fb_vma().
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Closes: https://lore.kernel.org/intel-xe/aNL_RgLy13fXJbYx@intel.com/
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: b0228a337de8 ("drm/xe/display: align framebuffers according to hw requirements")
Cc: <stable@vger.kernel.org> # v6.13+
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/20251208181550.6618-1-tursulin@igalia.com
|
|
Swap the pixel data when writing to framebuffer memory on big-endian
machines. Fixes incorrect output. Aspeed graphics does not appear to
support big-endian framebuffers after AST2400, although the feature
has been documented.
There's a lengthy discussion at [1].
v5:
- avoid restricted cast from __be16 (kernel test robot)
Signed-off-by: René Rebe <rene@exactco.de>
Link: https://lore.kernel.org/dri-devel/20251202.170626.2134482663677806825.rene@exactco.de/ # [1]
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20251212.210504.1355099120650239629.rene@exactco.de
|
|
Replace the bogus "GPL v2" with "GPL" as MODULE_LICNSE() string. The
value does not declare the module's exact license, but only lets the
module loader test whether the module is Free Software or not.
See commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs.
"GPL v2" bogosity") in the details of the issue. The fix is to use
"GPL" for all modules under any variant of the GPL.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 4b2b5e142ff4 ("drm: Move GEM memory managers into modules")
Link: https://patch.msgid.link/20251209140141.94407-3-tzimmermann@suse.de
|
|
Fix the compile-time warnings
Warning: drm_gem_shmem_helper.c:104 function parameter 'shmem' not described in 'drm_gem_shmem_init'
Warning: drm_gem_shmem_helper.c:104 function parameter 'size' not described in 'drm_gem_shmem_init'
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: e3f4bdaf2c5b ("drm/gem/shmem: Extract drm_gem_shmem_init() from drm_gem_shmem_create()")
Link: https://patch.msgid.link/20251209140141.94407-2-tzimmermann@suse.de
|
|
Acquire and release the GEM object's reservation lock around calls
to the object's purge operation. The tests use
drm_gem_shmem_purge_locked(), which led to errors such as show below.
[ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_helper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740
Only export the new helper drm_gem_shmem_purge() for Kunit tests.
This is not an interface for regular drivers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20251212160317.287409-6-tzimmermann@suse.de
|
|
Acquire and release the GEM object's reservation lock around calls
to the object's madvide operation. The tests use
drm_gem_shmem_madvise_locked(), which led to errors such as show below.
[ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_helper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140
Only export the new helper drm_gem_shmem_madvise() for Kunit tests.
This is not an interface for regular drivers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20251212160317.287409-5-tzimmermann@suse.de
|
|
Acquire and release the GEM object's reservation lock around vmap and
vunmap operations. The tests use vmap_locked, which led to errors such
as show below.
[ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0
[ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350
[ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370
[ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330
Only export the new vmap/vunmap helpers for Kunit tests. These are
not interfaces for regular drivers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20251212160317.287409-4-tzimmermann@suse.de
|
|
Automatically unpin pages on cleanup. The test currently fails with
the error
[ 58.246263] drm-kunit-mock-device drm_gem_shmem_test_get_sg_table.drm-kunit-mock-device: [drm] drm_WARN_ON(refcount_read(&shmem->pages_pin_count))
while cleaning up the GEM object. The pin count has to be zero at this
point.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: d586b535f144 ("drm/shmem-helper: Add and use pages_pin_count")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20251212160317.287409-3-tzimmermann@suse.de
|
|
GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of
the rsp. tests, so that each matches the helper it tests.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20251212160317.287409-2-tzimmermann@suse.de
|
|
RZ/G3E SoC is embedded with Mali-G52 GPU system. The system hangs after
STR in the following condition:
STR -> Wakeup from STR -> Unload panfrost using 'modprobe -r panfrost'.
Fix this issue by asserting/deasserting the reset during suspend/resume.
Rename the variable allwinner_h616_data->default_pm_rt_data for data
reuse and make it as generic GPU PM runtime data.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20251203125104.67596-1-biju.das.jz@bp.renesas.com
Signed-off-by: Adrian Larumbe <adrianml@alumnos.upm.es>
|
|
Since we recently started warning about uses of this function after the
atomic check phase completes, we've started getting warnings about this in
nouveau. It appears a misplaced drm_atomic_get_crtc_state() call has been
hiding in our .prepare_fb callback for a while.
So, fix this by adding a new nv50_head_atom_get_new() function and use that
in our .prepare_fb callback instead.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://patch.msgid.link/20251211190256.396742-1-lyude@redhat.com
|
|
GEN7_GRAS_NC_MODE_CNTL was only programmed for BR and not for BV pipe
but it needs to be programmed for both.
Program both pipes in hw_init and introducea separate reglist for it in
order to add this register to the dynamic reglist which supports
restoring registers per pipe.
Fixes: 91389b4e3263 ("drm/msm/a6xx: Add a pwrup_list field to a6xx_info")
Cc: stable@vger.kernel.org
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/691553/
Message-ID: <20251201-gras_nc_mode_fix-v3-1-92a8a10d91d0@gmail.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Previously this register would become 0 after IFPC took place which
broke all usages of counters.
Fixes: a6a0157cc68e ("drm/msm/a6xx: Enable IFPC on Adreno X1-85")
Cc: stable@vger.kernel.org
Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com>
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/690960/
Message-ID: <20251127-ifpc_counters-v3-1-fac0a126bc88@gmail.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Move the call to preempt_prepare_postamble() after verifying that
preempt_postamble_ptr is valid. If preempt_postamble_ptr is NULL,
dereferencing it in preempt_prepare_postamble() would lead to a crash.
This change avoids calling the preparation function when the
postamble allocation has failed, preventing potential NULL pointer
dereference and ensuring proper error handling.
Fixes: 50117cad0c50 ("drm/msm/a6xx: Use posamble to reset counters on preemption")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Patchwork: https://patchwork.freedesktop.org/patch/687659/
Message-ID: <20251113082839.3821867-1-alok.a.tiwari@oracle.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
On plaforms with an a7xx GPU not supporting IFPC, the ifpc_reglist
if still deferenced in a7xx_patch_pwrup_reglist() which causes
a kernel crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
...
pc : a6xx_hw_init+0x155c/0x1e4c [msm]
lr : a6xx_hw_init+0x9a8/0x1e4c [msm]
...
Call trace:
a6xx_hw_init+0x155c/0x1e4c [msm] (P)
msm_gpu_hw_init+0x58/0x88 [msm]
adreno_load_gpu+0x94/0x1fc [msm]
msm_open+0xe4/0xf4 [msm]
drm_file_alloc+0x1a0/0x2e4 [drm]
drm_client_init+0x7c/0x104 [drm]
drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib]
drm_client_setup+0xb4/0xd8 [drm_client_lib]
msm_drm_kms_post_init+0x2c/0x3c [msm]
msm_drm_init+0x1a4/0x228 [msm]
msm_drm_bind+0x30/0x3c [msm]
...
Check the validity of ifpc_reglist before deferencing the table
to setup the register values.
Fixes: a6a0157cc68e ("drm/msm/a6xx: Enable IFPC on Adreno X1-85")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/688944/
Message-ID: <20251117-topic-sm8x50-fix-a6xx-non-ifpc-v1-1-e4473cbf5903@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Use drm_draw_can_convert_from_xrgb8888() instead of
drm_draw_color_from_xrgb8888() while checking if a color format is
usable. This avoids a WARN in case the first format is not usable.
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251217-drm_draw_conv_check-v3-3-15b6f8bc1cbc@valla.it
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
|
|
Use drm_draw_can_convert_from_xrgb8888() instead of
drm_draw_color_from_xrgb8888() while searching for a usable color
format. This avoids a WARN in case the first format is not usable.
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251217-drm_draw_conv_check-v3-2-15b6f8bc1cbc@valla.it
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
|
|
Add drm_draw_can_convert_from_xrgb8888() function that can be used to
determine if a XRGB8888 color can be converted to the specified format.
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://patch.msgid.link/20251217-drm_draw_conv_check-v3-1-15b6f8bc1cbc@valla.it
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
|
|
Print the GuC queue submission state when an engine reset occurs, as
this provides clues about the cause of the reset.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20251218224546.4057424-1-matthew.brost@intel.com
|
|
Set the kernel log level for unhandled page faults to match the log
level (info) for engine resets. Currently, dmesg output can be confusing
because it shows an engine reset without indicating the page fault that
caused it. Without this change, the GuC log must be examined to
determine the source of the engine reset.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patch.msgid.link/20251218223745.4045207-1-matthew.brost@intel.com
|
|
We use forcewake to prevent the SoC from actually entering
PC8 while performing the PC8 disable sequence. Hide that
behind a new parent interface to eliminate the naked
forcewake/uncore usage from the display power code.
v2: Mark the interface optional and warn if
someone calls it when not provided (Jani)
Include the header to make sure the extern
declaration matches the definition (Jani)
v3: Rebase due to shuffling
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251218182052.18756-1-ville.syrjala@linux.intel.com
|
|
A new step has been added to Bspec with respect to the C10 PHY, which
instructs the driver to toggle powerdown value for boths PHY lanes to P0
and then P2 when driving an HDMI connector. This update in the Bspec
reflects the changes required by Wa_14026084006, so document it.
Note that, unlike other display workarounds, this one is actually tied
to the C10 PHY and not to a specific display IP. As such, let's just
document it in intel_cx0_phy.c instead of adding it to
intel_display_wa.c.
Bspec: 64568, 74489
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20251216-wa_14026084006-c10-hdmi-toggle-powerdown-v1-2-08677b03e2f1@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
We do not use the function intel_cx0_powerdown_change_sequence()
exclusively to take the PHY out of reset, hence the warning message on
failure is misleading. Furthermore, in an upcoming change, we will also
use that function to implement a new C10 PHY workaround.
Use a more accurate message by saying that we failed to change the
powerdown state.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20251216-wa_14026084006-c10-hdmi-toggle-powerdown-v1-1-08677b03e2f1@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Fix static analysis tool reported issue. Add index bound check before
accessing info array to prevent out of bound.
Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode")
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20251219105224.871930-6-riana.tauro@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Fix sparse warnings. Use static for survivability info attributes.
Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512101919.G12cuhBJ-lkp@intel.com/
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20251219105224.871930-5-riana.tauro@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Replace sprintf() calls with sysfs_emit() to follow current kernel
coding standards.
sysfs_emit() is the preferred method for formatting sysfs output as it
provides better bounds checking and is more secure.
Signed-off-by: Madhur Kumar <madhurkumar004@gmail.com>
Link: https://patch.msgid.link/20251214083659.2412218-1-madhurkumar004@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo adjusted commit message while pushing it]
|
|
There is no reason to accept an invalid minimum/maximum DSC source input
BPP value (i.e a minimum DSC input BPP value above the maximum pipe BPP
or a maximum DSC input BPP value below the minimum pipe BPP value), fail
the state computation in these cases.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-17-imre.deak@intel.com
|
|
There is no reason to accept an invalid maximum sink compressed BPP
value (i.e. 0), fail the state computation in this case.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-16-imre.deak@intel.com
|
|
There is no reason to accept a minimum/maximum link BPP value above the
maximum throughput BPP value, fail the state computation in this case.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-15-imre.deak@intel.com
|
|
Make sure that state computation fails if the minimum/maximum link BPP
values got invalid as a result of limiting both of these values
separately to the corresponding source/sink capability limits.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-14-imre.deak@intel.com
|
|
and eDP
The pipe joiner maximum compressed BPP must be limited based on the pipe
joiner memory size and BW, do that for all DP outputs by adjusting the
max compressed BPP value already in
intel_dp_compute_config_link_bpp_limits() (which is used by all output
types).
This way the BPP doesn't need to be adjusted in
dsc_compute_compressed_bpp() (called for DP-SST after the above limits
were computed already), so remove the adjustment from there.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-13-imre.deak@intel.com
|
|
A DSC compressed stream requires FEC (except for eDP), which has a BW
overhead on non-UHBR links that must be accounted for explicitly. Do
that during computing the required BW.
Note that the overhead doesn't need to be accounted for on UHBR links
where FEC is always enabled and so the corresponding overhead is part of
the channel coding efficiency instead (i.e. the overhead is part of the
available vs. the required BW).
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-12-imre.deak@intel.com
|
|
On MST links the symbol alignment and SSC have a BW overhead, which
should be accounted for when calculating the required stream BW, do so
during mode validation for an uncompressed stream.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-11-imre.deak@intel.com
|
|
Use intel_dp_effective_data_rate() to calculate the required link BW for
compressed streams on non-UHBR DP-SST links. This ensures that the BW is
calculated the same way for all DP output types and DSC/non-DSC modes,
during mode validation as well as during state computation.
This approach also allows for accounting with BW overhead due to DSC,
FEC being enabled on a link. Acounting for these will be added by
follow-up changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-10-imre.deak@intel.com
|
|
Use intel_dp_effective_data_rate() to calculate the required link BW for
eDP, DP-SST and MST links. This ensures that the BW is calculated the
same way for all DP output types, during mode validation as well as
during state computation. This approach also allows for accounting with
BW overheads due to the SSC, DSC, FEC being enabled on a link, as well
as due to the MST symbol alignment on the link. Accounting for these
overheads will be added by follow-up changes.
This way also computes the stream BW on a UHBR link correctly, using the
corresponding symbol size to effective data size ratio (i.e. ~97% link
BW utilization for UHBR vs. only ~80% for non-UHBR).
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-9-imre.deak@intel.com
|
|
is_bw_sufficient_for_dsc_config() should return true if the required BW
equals the available BW, make it so.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-8-imre.deak@intel.com
|
|
Factor out intel_dp_link_bw_overhead(), used later for BW calculation
during DP SST mode validation and state computation.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-7-imre.deak@intel.com
|
|
The encoder state computation should use the
drm_display_mode::crtc_clock member, instead of the clock member, the
former one possibly having a necessary adjustment wrt. to the latter
due to driver specific constraints. In practice the two values should
not differ at spots changed in this patch, since only MSO and 3D modes
would make them different, neither MSO or 3D relevant here, but still
use the expected crtc_clock version for consistency.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-6-imre.deak@intel.com
|
|
Convert intel_dp_output_bpp() and intel_dp_mode_min_output_bpp() to
return an x16 fixed point bpp value, as this value will be always the
link BPP (either compressed or uncompressed) tracked in the same x16
fixed point format.
While at it rename
intel_dp_output_bpp() to intel_dp_output_format_link_bpp_x16() and
intel_dp_mode_min_output_bpp() to intel_dp_mode_min_link_bpp_x16() to
better reflect that these functions return an x16 link BPP value
specific to a particular output format or mode.
Also rename intel_dp_output_bpp()'s bpp parameter to pipe_bpp, to
clarify which kind of (pipe vs. link) BPP the parameter is.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-5-imre.deak@intel.com
|
|
A DSC sink supporting DSC slice count N, not necessarily supports slice
counts less than N. Hence the driver should check the sink's support for
a particular slice count before using that slice count, fix
intel_dp_dsc_get_slice_count() accordingly.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-4-imre.deak@intel.com
|
|
A DSC sink supporting DSC slice count N, not necessarily supports slice
counts less than N. Hence the driver should check the sink's support for
a particular slice count before using that slice count. Add the helper
functions required for this.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-3-imre.deak@intel.com
|
|
eDP 1.5 supports all the slice counts reported via DP_DSC_SLICE_CAP_1,
so adjust drm_dp_dsc_sink_max_slice_count() accordingly.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-2-imre.deak@intel.com
|
|
Commit 33729a5fc0ca ("iommu/io-pgtable-arm: Remove split on unmap
behavior") did away with the treatment of partial unmaps of huge IOPTEs.
In the case of Panthor, that means an attempt to run a VM_BIND unmap
operation on a memory region whose start address and size aren't 2MiB
aligned, in the event it intersects with a huge page, would lead to ARM
IOMMU management code to fail and a warning being raised.
Presently, and for lack of a better alternative, it's best to have
Panthor handle partial unmaps at the driver level, by unmapping entire
huge pages and remapping the difference between them and the requested
unmap region.
This could change in the future when the VM_BIND uAPI is expanded to
enforce huge page alignment and map/unmap operational constraints that
render this code unnecessary.
When a partial unmap for a huge PTE is attempted, we also need to expand
the locked region to encompass whole huge pages.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20251217213252.677020-2-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
Ensure all related groups are evicted and suspended before VM
destruction takes place.
This fixes an issue where panthor_vm_destroy() destroys and unmaps the
heap context while there are still on slot groups using this.
The FW will do a write out to the heap context when a CSG (group) is
suspended, so a premature unmap of the heap context will cause a
GPU page fault.
This page fault is quite harmless, and do not affect the continued
operation of the GPU.
Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20251219093546.1227697-1-ketil.johnsen@arm.com
Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
Backmerging to bring in 6.19-rc1. An important upstream bugfix and
to help unblock PTL CI.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
