summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorLines
2025-11-28drm/panthor: Kill lock_region()Boris Brezillon-10/+10
The meat in lock_region() is about packing a region range into a single u64. The rest is just a regular reg write plus a as_send_cmd_and_wait() call that can easily be inlined in mmu_hw_do_operation_locked(). v2: - New patch v3: - Don't LOCK is the region has a zero size v4: - Collect R-b Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Always wait after sending a command to an ASBoris Brezillon-15/+12
There's currently no situation where we want to issue a command to an AS and not wait for this command to complete. The wait is either explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's turn write_cmd() into as_send_cmd_and_wait() that has the wait after a command is sent. v2: - New patch v3: - Collect R-b v4: - No changes Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251128084841.3804658-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-28drm/panthor: Prevent potential UAF in group creationAkash Goel-4/+15
This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags Fixes: de85488138247 ("drm/panthor: Add the scheduler logical block") Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Akash Goel <akash.goel@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: https://patch.msgid.link/20251127164912.3788155-1-akash.goel@arm.com
2025-11-28drm/{i915,xe}/hdcp: use parent interface for HDCP GSC callsJani Nikula-81/+126
The HDCP GSC implementation is different for both i915 and xe. Add it to the display parent interface, and call the hooks via the parent interface. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/e397073e91f8aa7518754b3b79f65c1936be91ad.1764090990.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/hdcp: move i915 specific HDCP GSC implementation to i915Jani Nikula-2/+5
The HDCP GSC implementation is different for both i915 and xe. Move the i915 specific implementation from display to i915 core. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/d362b256934c6c739d9decda717df2dbc3752481.1764090990.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/display/dp_mst: Add protection against 0 vcpiSuraj Kandpal-1/+2
When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayed_destroy_work ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0. Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc [drm_display_helper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6303 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251119094650.799135-1-suraj.kandpal@intel.com
2025-11-28Merge tag 'drm-xe-fixes-2025-11-27' of ↵Dave Airlie-12/+10
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix resource leak in xe_guc_ct_init_noalloc()'s error path (Shuicheng Lin) - Fix stack_depot usage without STACKDEPOT_ALWAYS_INIT (Lucas) - Fix overflow in conversion from clock tics to msec (Harish Chegondi) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/7ejiqjgthpqybg5svmkind2pszk4fqadxuq7rngchaaw76iept@5pn6sngqj6lk
2025-11-28Merge tag 'drm-misc-fixes-2025-11-27' of ↵Dave Airlie-27/+22
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: bridge: - sil902x: Fix HDMI detection imagination: - Update documentation sti: - Fix leaks in probe vga_switcheroo: - Avoid race condition during fbcon initialization Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251127081007.GA13578@2a02-2454-fd5e-fd00-689d-32c0-780c-bb87.dyn6.pyur.net
2025-11-28Merge tag 'amd-drm-fixes-6.18-2025-11-26' of ↵Dave Airlie-20/+36
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-11-26: amdgpu: - Unified MES fix - HDMI fix - Cursor fix - Bightness fix - EDID reading improvement - UserQ fix - Cyan Skillfish IP discovery fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251126204925.3316684-1-alexander.deucher@amd.com
2025-11-28Merge tag 'drm-misc-next-fixes-2025-11-26' of ↵Dave Airlie-1/+16
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v6.19: - Restrict the pointer size of flush pages to prevent a regression. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/0090a4fc-9cc4-4c03-bfe5-d1b1f0cc7e05@linux.intel.com
2025-11-28Revert "drm/i915/dp: change aux_ctl reg read to polling read"Ville Syrjälä-5/+7
This reverts commit 5a9b0c7418448ed3766f61ba0a71d08f259c3181. The switch from AUX interrupts to pollign was very hand-wavy. Yes, there have been some situations in CI on a few platforms where the AUX hardware seemingly forgets to signal the timeout, but those have been happening after we switched to polling as well. So I don't think we have any conclusive evidence that polling actually helps here. Someone really should root cause the actual problem, and see if there is a proper workaround we could implemnt (eg. disabling clock gating/etc.). In the meantime just go back to using the interrupt for AUX completion. If the hardware fails to signal the timeout we will just hit the wait_event_timeout() software timeout instead. I suppose we could try to tune the software timeout to more closely match the expected hardware timeout. Might need to use wait_event_hrtimeout() or something to avoid jiffies granularity issues... The AUX polling is also a hinderance towards using poll_timeout_us() because we have a very long timeout, but would need a fairly short polling interval to keep AUX transfer reasonably fast. Someone would need to come up with good numbers in a somewhat scientific way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119185310.10428-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Enable DDI A/B AUX interrupts on LNL+Ville Syrjälä-5/+14
Apparently the DDI A/B AUX interrupts move onto the PICA side on LNL. Unmask them properly so that we actually get the interrupts. The interrupt handler was already trying to handle them despite the interrupts remaining masked. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119185310.10428-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Eliminate one more frequent drm_format_info()Ville Syrjälä-14/+20
Another (somewhat expensive) drm_format_info() call has appeared in intel_plane_can_async_flip(). That one may get called several times per commit so we need to get rid of it. Fortunately most callers already have the framebuffer at hand, so we can just grab the format info from there. The one exception is intel_plane_format_mod_supported_async() where we have to do the lookup. But that only gets called (a bunch of times) during driver init to build the IN_FORMATS_ASYNC blob, and afterwards there is no runtime cost. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251112233030.24117-4-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-11-28drm/i915: Expose the IN_FORMATS_ASYNC blob for all planesVille Syrjälä-0/+4
Since old kernel versions wouldn't expose the IN_FORMATS_ASYNC blob, userspace can't really use the absence of the blob to determine that async flips aren't supported. Thus it seems better to always expose the blob on all planes, whether they support async flips or not. The blob will simply not indicate any format+modifier combinations as supported on planes that aren't async flip capable. Currently we expose the blob for all skl+ universal planes (even though we implement async flips only for the first plane on each pipe), and i9xx primary planes (for ilk+ we have async flips support, for pre-ilk we do not). Complete the full set by also expsosing the blob on pre-skl sprite planes, and cursors. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251112233030.24117-3-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-11-28drm/i915/panic: Clean up the variablesVille Syrjälä-33/+29
Use the standard variable names for things, and get rid of any annoying aliasing variables. And sprinkle the consts in while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/panic: Get the crtc from the correct placeVille Syrjälä-1/+2
Use hw.crtc as opposed to uapi.crtc in the panic code. I suspect this stuff doesn't handle joiner correctly in other ways either but can't be bothered to dig deeper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Use hw.active instead of uapi.active in the initial plane readoutVille Syrjälä-4/+8
We're interested in the actual hardware state rather than the uapi state, so grab the crtc active flag from the correct spot. In practice the two will be identical here becase .get_initial_plane_config() will reject the initial FB when joiner is active. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/psr: Use hw.rotation instead of uapi.rotationVille Syrjälä-1/+1
Presumably we're tryign to check if the hw plane is actually rotated or not, so grab that information from the correct plane (hw.rotation). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915/psr: Use hw.crtc instead of uapi.crtcVille Syrjälä-3/+3
uapi.crtc is not set for joiner secondary pipes, so generally should not be used anywhere after the initial state copy. Switch to hw.crtc which actually indicates that the plane is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28drm/i915: Use the proper (hw.crtc) for the cursor unpin vblank workerVille Syrjälä-3/+3
uapi.crtc is NULL for joiner secondary pipes, so using that is nonsense in most places. Switch to hw.crtc so that we use the deferred cursor unpin also on joiner secondary pipes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251119181606.17129-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-28Merge tag 'drm-xe-next-fixes-2025-11-21' of ↵Dave Airlie-5/+16
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - A couple of SR-IOV fixes (Michal Winiarski) - Fix a potential UAF (Sanjay) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aSA08EW9JMU3LkIu@fedora
2025-11-27drm/xe/gt: Introduce runtime suspend/resumeRaag Jadav-5/+162
If power state is retained between suspend/resume cycle, we don't need to perform full GT re-initialization. Introduce runtime helpers for GT which greatly reduce suspend/resume delay. v2: Drop redundant xe_gt_sanitize() and xe_guc_ct_stop() (Daniele) Use runtime naming for guc helpers (Daniele) v3: Drop redundant logging, add kernel doc (Michal) Use runtime naming for ct helpers (Michal) v4: Fix tags (Rodrigo) v5: Include host_l2_vram workaround (Daniele) Reuse xe_guc_submit_enable/disable() helpers (Daniele) Co-developed-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20251030122357.128825-5-raag.jadav@intel.com
2025-11-27drm/xe/pm: Assert on runtime suspend if VFs are enabledRaag Jadav-0/+9
We hold an additional reference to the runtime PM to keep PF in D0 during VFs lifetime, as our VFs do not implement the PM capability. This means we should never be runtime suspending as long as VFs are enabled. v8: Add !IS_SRIOV_VF() assert (Matthew Brost) Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20251030122357.128825-4-raag.jadav@intel.com
2025-11-27drm/xe/guc_submit: Introduce pause/unpause() helpers for PFRaag Jadav-0/+32
Introduce pause/unpause() helpers which stop/start further runs of submission tasks on given GuC and can be called from PF context. This is in preparation of usecases where we simply need to stop/start the scheduler without losing GuC state and don't require dealing with VF migration. v7: Reword commit message (Matthew Brost) Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20251030122357.128825-3-raag.jadav@intel.com
2025-11-27drm/xe/vf: Update pause/unpause() helpers with VF namingRaag Jadav-12/+16
Now that pause/unpause() helpers have been updated for VF migration usecase, update their naming to match the functionality and while at it, add IS_SRIOV_VF() assert to make sure they are not abused. v7: Add IS_SRIOV_VF() assert (Matthew Brost) Use "vf" suffix (Michal) Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20251030122357.128825-2-raag.jadav@intel.com
2025-11-27drm/xe: Move VRAM MM debugfs creation to tile levelPiotr Piórkowski-12/+9
Previously, VRAM TTM resource manager debugfs entries (vram0_mm / vram1_mm) were created globally in the XE debugfs root directory. But technically, each tile has an associated VRAM TTM manager, which it can own. Let's create VRAM memory manager debugfs entries directly under each tile's debugfs directory for better alignment with the per-tile memory layout. Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251127073643.144379-1-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-27drm/xe/xe_sriov_packet: Return int from pf_descriptor_initJonathan Cavitt-1/+1
pf_descriptor_init currently returns a size_t, which is an unsigned integer data type. This conflicts with it returning a negative errno value on failure. Make it return an int instead. This mirrors how pf_trailer_init is used later. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Alex Zuo <alex.zuo@intel.com> Link: https://patch.msgid.link/20251117190114.69953-2-jonathan.cavitt@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-26drm/amd/display: Enable support for Gamma 2.2Alex Hung-3/+9
This patchset enables support for the Gamma 2.2. With this patch the following IGT subtests pass: kms_colorop --run plane-XR30-XR30-gamma_2_2 kms_colorop --run plane-XR30-XR30-gamma_2_2_inv-gamma_2_2 kms_colorop --run plane-XR30-XR30-gamma_2_2_inv-gamma_2_2-gamma_2_2_inv Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-52-alex.hung@amd.com
2025-11-26drm/colorop: Add DRM_COLOROP_1D_CURVE_GAMMA22 to 1D CurveAlex Hung-0/+2
Add "DRM_COLOROP_1D_CURVE_GAMMA22" and DRM_COLOROP_1D_CURVE_GAMMA22_INV subtypes to drm_colorop of DRM_COLOROP_1D_CURVE. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-51-alex.hung@amd.com
2025-11-26drm/amd/display: Disable CRTC degamma when color pipeline is enabledAlex Hung-14/+12
The degamma is to be handled by Color pipeline API. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-50-alex.hung@amd.com
2025-11-26drm/amd/display: Ensure 3D LUT for color pipelineAlex Hung-71/+78
Check dpp.hw_3d_lut before creating shaper tf/lut and 3dlut colorops in colorpipeline and handling these colorops. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-49-alex.hung@amd.com
2025-11-26drm/amd/display: Add AMD color pipeline docHarry Wentland-20/+102
Add kernel doc for AMD color pipeline. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-48-alex.hung@amd.com
2025-11-26drm/amd/display: add 3D LUT coloropAlex Hung-0/+175
This adds support for a 3D LUT. The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. Multiplier 3. 3x4 CTM 4. 1D curve colorop 5. 1D LUT 6. 3D LUT 7. 1D curve colorop 8. 1D LUT Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-47-alex.hung@amd.com
2025-11-26drm/colorop: Add 3D LUT support to color pipelineAlex Hung-0/+86
It is to be used to enable HDR by allowing userpace to create and pass 3D LUTs to kernel and hardware. new drm_colorop_type: DRM_COLOROP_3D_LUT. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-46-alex.hung@amd.com
2025-11-26drm/colorop: allow non-bypass coloropsHarry Wentland-31/+49
Not all HW will be able to do bypass on all color operations. Introduce an 32 bits 'flags' for all colorop init functions and DRM_COLOROP_FLAG_ALLOW_BYPASS for creating the BYPASS property when it's true. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-45-alex.hung@amd.com
2025-11-26drm/colorop: Define LUT_1D interpolationHarry Wentland-3/+46
We want to make sure userspace is aware of the 1D LUT interpolation. While linear interpolation is common it might not be supported on all HW. Give driver implementers a way to specify their interpolation. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-44-alex.hung@amd.com
2025-11-26drm/amd/display: Swap matrix and multiplierAlex Hung-10/+10
Swap the order of matrix and multiplier as designed in hardware. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-43-alex.hung@amd.com
2025-11-26drm/amd/display: add multiplier coloropAlex Hung-0/+55
This adds support for a multiplier. This multiplier is programmed via the HDR Multiplier in DCN. With this change the following IGT tests pass: kms_colorop --run plane-XR30-XR30-multiply_125 kms_colorop --run plane-XR30-XR30-multiply_inv_125 The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. 3x4 CTM 3. Multiplier 4. 1D curve colorop 5. 1D LUT 6. 1D curve colorop 7. 1D LUT Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-42-alex.hung@amd.com
2025-11-26drm/colorop: Add multiplier typeAlex Hung-0/+40
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER. It's a simple multiplier to all pixel values. The value is specified via a S31.32 fixed point provided via the "MULTIPLIER" property. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-41-alex.hung@amd.com
2025-11-26drm/amd/display: add 3x4 matrix coloropAlex Hung-0/+67
This adds support for a 3x4 color transformation matrix. With this change the following IGT tests pass: kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_enc kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_dec The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. 3x4 CTM 3. 1D curve colorop 4. 1D LUT 5. 1D curve colorop 6. 1D LUT Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-40-alex.hung@amd.com
2025-11-26drm/amd/display: add shaper and blend colorops for 1D Curve Custom LUTAlex Hung-77/+251
This patch adds colorops for custom 1D LUTs in the SHAPER and BLND HW blocks. With this change the following IGT tests pass: kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. 1D curve colorop 3. 1D LUT 4. 1D curve colorop 5. 1D LUT The 1D curve colorops support sRGB, BT2020, and PQ scaled to 125.0. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-39-alex.hung@amd.com
2025-11-26drm/colorop: Add 1D Curve Custom LUT typeAlex Hung-0/+52
We've previously introduced DRM_COLOROP_1D_CURVE for pre-defined 1D curves. But we also have HW that supports custom curves and userspace needs the ability to pass custom curves, aka LUTs. This patch introduces a new colorop type, called DRM_COLOROP_1D_LUT that provides a SIZE property which is used by a driver to advertise the supported SIZE of the LUT, as well as a DATA property which userspace uses to set the LUT. DATA and size function in the same way as current drm_crtc GAMMA and DEGAMMA LUTs. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-38-alex.hung@amd.com
2025-11-26drm: Add Enhanced LUT precision structureUma Shankar-0/+43
Existing LUT precision structure drm_color_lut has only 16 bit precision. This is not enough for upcoming enhanced hardwares and advance usecases like HDR processing. Hence added a new structure with 32 bit precision values. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-36-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for BT.709 and BT.2020 TFsHarry Wentland-3/+9
This adds support for the BT.709/BT.2020 transfer functions on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER, and BLND blocks. With this change the following IGT subtests pass: kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf kms_colorop --run plane-XR30-XR30-bt2020_oetf Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-35-alex.hung@amd.com
2025-11-26drm/colorop: add BT2020/BT709 OETF and Inverse OETFHarry Wentland-0/+2
The BT.709 and BT.2020 OETFs are the same, the only difference being that the BT.2020 variant is defined with more precision for 10 and 12-bit per color encodings. Both are used as encoding functions for video content, and are therefore defined as OETF (opto-electronic transfer function) instead of as EOTF (electro-optical transfer function). Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-34-alex.hung@amd.com
2025-11-26drm/amd/display: Enable support for PQ 125 EOTF and InverseHarry Wentland-12/+25
This patchset enables support for the PQ_125 EOTF and its inverse on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER, and BLND blocks. With this patchset the following IGT subtests are passing: kms_colorop --run plane-XR30-XR30-pq_125_eotf kms_colorop --run plane-XR30-XR30-pq_125_inv_eotf kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf-pq_125_eotf Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-33-alex.hung@amd.com
2025-11-26drm/colorop: Add PQ 125 EOTF and its inverseHarry Wentland-0/+2
The PQ function defines a mapping of code values to nits (cd/m^2). The max code value maps to 10,000 nits. Windows DWM's canonical composition color space (CCCS) defaults to composing SDR contents to 80 nits and uses a float value of 1.0 to represent this. For this reason AMD HW hard-codes a PQ function that is scaled by 125, yielding 80 nit PQ values for 1.0 and 10,000 nits at 125.0. This patch introduces this scaled PQ EOTF and its inverse as 1D curve types. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-32-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for sRGB EOTF in BLND blockAlex Hung-0/+94
Expose a 3rd 1D curve colorop, with support for DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block to perform the sRGB transform when the colorop is not in bypass With this change the following IGT test passes: kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb_eotf The color pipeline now consists of the following colorops: 1. 1D curve colorop w/ sRGB EOTF support 2. 1D curve colorop w/ sRGB Inverse EOTF support 3. 1D curve colorop w/ sRGB EOTF support Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-31-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for sRGB Inverse EOTF in SHAPER blockAlex Hung-0/+93
Expose a 2nd curve colorop with support for DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to perform the sRGB Inverse EOTF on the shaper block when the colorop is not in bypass. With this change the follow IGT tests pass: kms_colorop --run plane-XR30-XR30-srgb_inv_eotf kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf The color pipeline now consists of the following colorops: 1. 1D curve colorop w/ sRGB EOTF support 2. 1D curve colorop w/ sRGB Inverse EOTF support Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-30-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for sRGB EOTF in DEGAM blockAlex Hung-3/+211
Expose one 1D curve colorop with support for DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform the sRGB transform when the colorop is not in bypass. With this change the following IGT test passes: kms_colorop --run plane-XR30-XR30-srgb_eotf The color pipeline now consists of a single colorop: 1. 1D curve colorop w/ sRGB EOTF Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-29-alex.hung@amd.com
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-24 16:04:49 +0000