aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-11-13drm/i915/display: Add default case to mipi_exec_send_packetJonathan Cavitt1-0/+3
Add a default case to the switch case statement in mipi_exec_send_packet to prevent attempts to read an uninitialized ret value. It's unlikely the default case will ever occur during regular exeuction, but if more MIPI DSI Processor-to-Peripheral transaction types are ever added, then having this in place will be a useful safety guard. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Fixes: 23db1577ce2d ("drm/i915/dsi: log send packet sequence errors") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20251104164150.16795-2-jonathan.cavitt@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-13drm/xe: remove stale runtime_pm memberJani Nikula1-3/+0
This has become unused and unnecessary. Remove. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251112185547.172113-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-13drm/i915/ltphy: include intel_display_utils.h instead of i915_utils.hJani Nikula1-1/+1
Display code stopped using i915_utils.h in favour of intel_display_utils.h. Fix recent additions. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251112181342.107911-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/xe/guc: Eliminate RPa frequency cachingSk Anirban2-31/+26
Remove the cached pc->rpa_freq field and refactor RPA frequency handling to fetch values directly from hardware registers on each request. v2: Check graphics version instead of platform (Rodrigo) v3: Fix graphics version check (Badal) Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Suggested-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251112185153.3593145-6-sk.anirban@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-12drm/xe/guc: Eliminate RPe caching for SLPC parameter handlingSk Anirban2-31/+32
RPe is runtime-determined by PCODE and caching it caused stale values, leading to incorrect GuC SLPC parameter settings. Drop the cached rpe_freq field and query fresh values from hardware on each use to ensure GuC SLPC parameters reflect current RPe. v2: Remove cached RPe frequency field (Rodrigo) v3: Remove extra variable (Vinay) Modify function name (Vinay) v4: Maintain a separate function for PVC (Rodrigo) v5: Avoid RPn update while fetching RPe frequency (Rodrigo) v6: Split platform-specific RPe comments (Vinay) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5166 Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patch.msgid.link/20251112185153.3593145-5-sk.anirban@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-12vfio/gvt: Convert to get_region_info_capsJason Gunthorpe1-71/+42
Remove the duplicate code and change info to a pointer. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/17-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-12vfio/gvt: Provide a get_region_info opJason Gunthorpe1-148/+147
Move it out of intel_vgpu_ioctl() and re-indent it. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/13-v2-2a9e24d62f1b+e10a-vfio_get_region_info_op_jgg@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-12drm/i915/cursor: Initialize 845 vs 865 cursor size separatelyVille Syrjälä1-2/+5
The if+ternary combo used for the max cursor width initialization on 845/865 is rather cumbersome. Just split this into a straight up if ladder. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915/cursor: Extract intel_cursor_mode_config_init()Ville Syrjälä3-11/+21
Move the max cursor size initialization into intel_cursor.c so that all the platform specific details about cursors are concentrated in one file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Use mode_config->cursor_width for cursor DDB allocationVille Syrjälä1-1/+2
Replace the hardcoded 256 with mode_config->cursor_width when doing the cursor DDB allocation. Currently 256 is correct for all SKL+, but this might change in the future. One less place to change should that happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915/wm: Use drm_get_format_info() in SKL+ cursor DDB allocationVille Syrjälä1-3/+9
Replace the technically inaccurate drm_format_info() with the accurate drm_get_format_info() in the SKL+ cursor DDB allocation code. Since we're only interested in the linear modifier here, the two functions do actually return the same information. But let's not use drm_format_info() to avoid setting a bad example. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915/fb: Init 'ret' in each error branch in intel_framebuffer_init()Ville Syrjälä1-1/+6
Make the order of things a bit less fragile in intel_framebuffer_init() by assigning 'ret' in each error branch instead of depending on some earlier assignment. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Nuke intel_plane_config.tilingVille Syrjälä4-11/+9
Use intel_fb_modifier_to_tiling() to convert the modifier into the fence tiling mode during BIOS FB readout, rather than hand rolling it. With this we can also stop tracking the tiling mode in the intel_plane_config. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Populate fb->format accurately in BIOS FB readoutVille Syrjälä2-2/+4
Use drm_get_format_info() instead of drm_format_info() to populate fb->format during the BIOS FB readout. The difference being that drm_get_format_info() knows about compressed formats whereas drm_format_info() doesn't. This doesn't actually matter in practice since the BIOS FB should never be compressed, but no reason we shouldn't use the more accurate function here anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Pass drm_format_info into plane->max_stride()Ville Syrjälä9-47/+47
Pass the format info into plane->max_stride() from the caller instead of doing yet another drm_format_info() lookup on the spot. drm_format_info() is both rather expensive, and technically incorrect since it doesn't return the correct format info for compressed formats (though that doesn't actually matter for the current .max_stride() implementations since they are just interested in the cpp value). Most callers already have the format info available. The only exception is intel_dumb_fb_max_stride() where we shall use the actually correct drm_get_format_info() variant. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Introduce intel_dumb_fb_max_stride()Ville Syrjälä4-10/+19
Wrap intel_plane_fb_max_stride() in intel_dumb_fb_max_stride() for the purposes of dumb fb creation. I want to change intel_plane_fb_max_stride() to take a 'struct drm_format_info' instead of the 'u32 pixel_format' so we need an excplicit format info lookup in the dumb fb path and I don't really want to have that in i915_gem_dumb_create() directly. This makes intel_plane_fb_max_stride() internal to the display code again, and thus we can pass in struct intel_display instead of struct drm_device. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/nouveau: fully define nvfw_hs_load_header_v2Timur Tabi1-1/+3
Add the missing fields of the nvfw_hs_load_header_v2 struct, so that the struct matches the actual contents of the firmware images. nvfw_hs_load_header_v2 is a struct that defines a header for some firmware images used by Nouveau. The current structure definition is incomplete; it omits the last two fields because they are unused. To maintain consistency between Nouveau, OpenRM, and Nova, and to make it easier to support possible future images, we should fully define the struct. Also add a __counted_by tag for the flex array. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251010223957.1078525-1-ttabi@nvidia.com
2025-11-12drm/nouveau/drm: Bump the driver version to 1.4.1 to report new featuresMohamed Ahmed1-1/+3
The HW can only do compression on large and huge pages, and enabling it on 4K pages leads to a MMU fault. Compression also needs kernel support for handling the compressed kinds and managing the compression tags. This increments the nouveau version number which allows NVK to enable it only when the kernel actually supports both features and avoid breaking the system if a newer mesa version is paired with an older kernel version. For the associated userspace MR, please see !36450: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36450 Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-5-83b05475f57c@mary.zone
2025-11-12drm/nouveau/mmu/tu102: Add support for compressed kindsBen Skeggs1-2/+44
Allow compressed PTE kinds to be written into PTEs when GSP-RM is present, rather than reverting to their non-compressed versions. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-4-83b05475f57c@mary.zone
2025-11-12drm/nouveau/mmu/gp100: Remove unused/broken support for compressionBen Skeggs2-37/+6
From GP100 onwards it's not possible to initialise comptag RAM without PMU firmware, which nouveau has no support for. As such, this code is essentially a no-op and will always revert to the equivalent non-compressed kind due to comptag allocation failure. It's also broken for the needs of VM_BIND/Vulkan. Remove the code entirely to make way for supporting compression on GPUs that support GSM-RM. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-3-83b05475f57c@mary.zone
2025-11-12drm/nouveau/uvmm: Allow larger pagesMary Guillemard1-2/+58
Now that everything in UVMM knows about the variable page shift, we can select larger values. The proposed approach relies on nouveau_bo::page unless if it would cause alignment issues (in which case we fall back to searching for an appropriate shift) Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-2-83b05475f57c@mary.zone
2025-11-12drm/nouveau/uvmm: Prepare for larger pagesMary Guillemard2-17/+30
Currently memory allocated by VM_BIND uAPI can only have a granuality matching PAGE_SIZE (4KiB in common case) To have a better memory management and to allow big (64KiB) and huge (2MiB) pages later in the series, we are now passing the page shift all around the internals of UVMM. Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-1-83b05475f57c@mary.zone
2025-11-12drm/xe/pf: Allow to lockdown the PF using custom guardMichal Wajdeczko7-0/+280
Some driver components, like eudebug or ccs-mode, can't be used when VFs are enabled. Add functions to allow those components to block the PF from enabling VFs for the requested duration. Introduce trivial counter to allow lockdown or exclusive access that can be used in the scenarios where we can't follow the strict owner semantics as required by the rw_semaphore implementation. Before enabling VFs, the PF will try to arm the "vfs_enabling" guard for the exclusive access. This will fail if there are some lockdown requests already initiated by the other components. For testing purposes, add debugfs file which will call these new functions from the file's open/close hooks. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Christoph Manszewski <christoph.manszewski@intel.com> Reviewed-by: Christoph Manszewski <christoph.manszewski@intel.com> Link: https://patch.msgid.link/20251109162451.4779-1-michal.wajdeczko@intel.com
2025-11-12drm/xe/pcode: Rework error mappingLucas De Marchi2-20/+26
The sparse array used for error decoding from is unnecessarily big. It should be better handled by a switch statement that will also allow us to more easily improve this code. Add a CASE_ERR() macro to keep the table compact and use it instead of the 256-entries array, which saves some space: $ bloat-o-meter xe_pcode.o.old xe_pcode.o add/remove: 0/1 grow/shrink: 2/0 up/down: 190/-4096 (-3906) Function old new delta __pcode_mailbox_rw 363 465 +102 __pcode_mailbox_rw.cold 58 146 +88 err_decode 4096 - -4096 Total: Before=7890, After=3984, chg -49.51% Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251110-pcode-errmap-v2-1-cb18c8f54238@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-12drm/i915/dp_mst: Disable Panel ReplayImre Deak1-0/+4
Disable Panel Replay on MST links until it's properly implemented. For instance the required VSC SDP is not programmed on MST and FEC is not enabled if Panel Replay is enabled. Fixes: 3257e55d3ea7 ("drm/i915/panelreplay: enable/disable panel replay") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15174 Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251107124141.911895-1-imre.deak@intel.com (cherry picked from commit e109f644b871df8440c886a69cdce971ed533088) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-12drm/xe: fix kernel-doc function name mismatch in xe_pm.cKriish Sharma1-1/+1
Documentation build reported: WARNING: ./drivers/gpu/drm/xe/xe_pm.c:131 expecting prototype for xe_pm_might_block_on_suspend(). Prototype was for xe_pm_block_on_suspend() instead The kernel-doc comment for xe_pm_block_on_suspend() incorrectly used the function name xe_pm_might_block_on_suspend(). Fix the header to match the actual function prototype. No functional changes. Fixes: f73f6dd312a5 ("drm/xe/pm: Add lockdep annotation for the pm_block completion") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511061736.CiuroL7H-lkp@intel.com/ Signed-off-by: Kriish Sharma <kriish.sharma2006@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251110184206.2113830-1-kriish.sharma2006@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-12drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hookJayesh Choudhary3-0/+31
After integrating OLDI support[0], it is necessary to identify which VP instances use OLDI, since the OLDI driver owns the video port clock (as a serial clock). Clock operations on these VPs must be delegated to the OLDI driver, not handled by the TIDSS driver. This issue also emerged in upstream discussions when DSI-related clock management was attempted in the TIDSS driver[1]. To address this, add an 'is_ext_vp_clk' array to the 'tidss_device' structure, marking a VP as 'true' during 'tidss_oldi_init()' and as 'false' during 'tidss_oldi_deinit()'. TIDSS then uses 'is_ext_vp_clk' to skip clock validation checks in 'dispc_vp_mode_valid()' for VPs under OLDI control. Since OLDI uses the DSS VP clock directly as a serial interface and manages its own rate, mode validation should be implemented in the OLDI bridge's 'mode_valid' hook. This patch adds that logic, ensuring proper delegation and avoiding spurious clock handling in the TIDSS driver. [0]: https://lore.kernel.org/all/20250528122544.817829-1-aradhya.bhatia@linux.dev/ [1]: https://lore.kernel.org/all/DA6TT575Z82D.3MPK8HG5GRL8U@kernel.org/ Fixes: 7246e0929945 ("drm/tidss: Add OLDI bridge support") Tested-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Swamil Jain <s-jain1@ti.com> Link: https://patch.msgid.link/20251104151422.307162-3-s-jain1@ti.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patch.msgid.link/ffd5ebe03391b3c01e616c0c844a4b8ddecede36.1762513240.git.jani.nikula@intel.com
2025-11-12drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display featuresJayesh Choudhary2-58/+31
The TIDSS hardware does not have independent maximum or minimum pixel clock limits for each video port. Instead, these limits are determined by the SoC's clock architecture. Previously, this constraint was modeled using the 'max_pclk_khz' and 'min_pclk_khz' fields in 'dispc_features', but this approach is static and does not account for the dynamic behavior of PLLs. This patch removes the 'max_pclk_khz' and 'min_pclk_khz' fields from 'dispc_features'. The correct way to check if a requested mode's pixel clock is supported is by using 'clk_round_rate()' in the 'mode_valid()' hook. If the best frequency match for the mode clock falls within the supported tolerance, it is approved. TIDSS supports a 5% pixel clock tolerance, which is now reflected in the validation logic. This change allows existing DSS-compatible drivers to be reused across SoCs that only differ in their pixel clock characteristics. The validation uses 'clk_round_rate()' for each mode, which may introduce additional delay (about 3.5 ms for 30 modes), but this is generally negligible. Users desiring faster validation may bypass these calls selectively, for example, checking only the highest resolution mode, as shown here[1]. [1]: https://lore.kernel.org/all/20250704094851.182131-3-j-choudhary@ti.com/ Tested-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Swamil Jain <s-jain1@ti.com> Link: https://patch.msgid.link/20251104151422.307162-2-s-jain1@ti.com [Tomi: dropped 'inline' from check_pixel_clock] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-11-12drm/sun4i: Nuke mixer pointer from layer codeJernej Skrabec6-14/+5
It's not used anymore, so remove it. This allows trully independent layer state from mixer. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-31-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: vi_scaler: Find mixer from crtcJernej Skrabec1-1/+3
With "floating" planes in DE33, mixer can't be stored in layer structure anymore. Find mixer using currently bound crtc. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-30-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: layer: replace mixer with layer structJernej Skrabec9-67/+66
This allows to almost completely decouple layer code from mixer. This is important for DE33. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-29-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: mixer: split out layer configJernej Skrabec6-76/+123
Later special plane only driver for DE33 will provide separate configuration. This change will also help layer driver migrate away from mixer structure. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-28-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: mixer: Add quirk for number of VI scalersJernej Skrabec3-5/+18
On DE2 and DE3, UI scalers are located right after VI scalers. So in order to calculate proper UI scaler base address, number of VI scalers must be known. In practice, it is same as number of VI channels, but it doesn't need to be. Let's make a quirk for this number. Code for configuring channels and associated functions won't have access to vi_num quirk anymore after rework for independent planes. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-27-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: ui_scaler: drop sanity checksJernej Skrabec1-6/+0
They can't be triggered if mixer configuration is properly specified in quirks. Additionally, number of VI channels won't be available in future due to rework for DE33 support. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-26-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: mixer: Convert heuristics to quirkJernej Skrabec3-5/+19
Determination if FCC unit can be used for VI layer alpha depends on number of VI channels. This info won't be available anymore in future to VI layer driver because of DE33 way of allocating planes from same pool to different mixers. While order is slightly changed, it doesn't affect anything due to double buffering of registers. New order keeps related registers together and quirk separate. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-25-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: vi_scaler: Update DE33 base calculationJernej Skrabec2-1/+4
Now that channel base calculation is straightforward, let's update VI scaler base calculation to be simpler. At the same time, also introduce macro to avoid magic numbers. Note, reason why current magic value and new macro value isn't the same is because sun8i_channel_base() already introduces offset to channel registers. Previous value is just the difference to VI scaler registers. However, new code calculates scaler base from channel base. This is also easier to understand when looking into BSP driver. Macro value can be easily found whereas old diff value was not. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-24-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: layers: add physical index argJernej Skrabec6-11/+23
This avoids plane mapping in layers code, which allows future refactoring, when layer code will move away from accessing mixer structure. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-23-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: csc: use layer arg instead of mixerJernej Skrabec3-8/+8
Layer will be more universal, due to DE33 support. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-22-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: layers: Make regmap for layers configurableJernej Skrabec8-41/+50
Till DE33, there were no reason to decouple registers from mixer. However, with future new plane driver, this will be necessary. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-21-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: vi_scaler: use layer instead of mixer for argsJernej Skrabec4-16/+16
Layer related peripherals should take layer struct as a input. This looks cleaner and also necessary for proper DE33 support later. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-20-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: ui_scaler: use layer instead of mixer for argsJernej Skrabec3-13/+14
Layer related peripherals should take layer struct as a input. This looks cleaner and also necessary for proper DE33 support later. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-19-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: vi_layer: use layer struct instead of multiple argsJernej Skrabec1-30/+28
This change is equally a cleanup (less arguments) and preparation for DE33 separate plane driver. It will introduce additional register space. No functional changes. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-18-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: ui_layer: use layer struct instead of multiple argsJernej Skrabec1-32/+30
This change is equally a cleanup (less arguments) and preparation for DE33 separate plane driver. It will introduce additional register space. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-17-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: layer: move num of planes calc out of layer codeJernej Skrabec5-15/+14
With DE33, number of planes no longer depends on mixer because layers are shared between all mixers. Get this value via parameter, so DE specific code can fill in proper value. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-16-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: ui_layer: Change index meaningJernej Skrabec2-5/+5
In the pursuit of making UI/VI layer code independent of DE version, change meaning of UI index to index of the plane within mixer. DE33 can split amount of VI and UI planes between multiple mixer in whatever way it deems acceptable, so simple calculation VI num + UI index won't be meaningful anymore. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-15-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: de2/de3: Move plane type determination to mixerJernej Skrabec5-10/+17
Plane type determination logic inside layer init functions doesn't allow index register to be repurposed to plane sequence, which it almost is. So move out the logic to mixer, which allows further rework for DE33 support. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-14-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: csc: Simplify arguments with taking plane stateJernej Skrabec3-46/+40
Taking plane state directly reduces number of arguments, avoids copying values and allows making additional decisions. For example, when plane is disabled, CSC should be turned off. This is also cleanup for later patches which will move call to another place. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-13-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: de2/de3: Simplify CSC config interfaceJernej Skrabec3-69/+40
Merging both function into one lets this one decide on it's own if CSC should be enabled or not. Currently heuristics for that is pretty simple - enable it for YUV formats and disable for RGB. DE3 and newer allows YUV pipeline, which will be easier to implement these way. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-12-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: mixer: Move layer enabling to atomic_updateJernej Skrabec3-26/+24
Enable or disable layer only in layer atomic update callback. Doing so will enable having separate layer driver later for DE33. There is no fear that enable bit would be set incorrectly, as all read-modify-write sequences for that register are now eliminated. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-11-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-12drm/sun4i: vi layer: Write attributes in one goJernej Skrabec1-44/+27
It turns out that none of the VI channel registers were meant to be read. Mostly it works fine but sometimes it returns incorrect values. Rework VI layer code to write all registers in one go to avoid reads. This rework will also allow proper code separation. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Ryan Walklin <ryan@testtoast.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251104180942.61538-10-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
generated by cgit