summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2025-06-26drm/xe: Rename xe_uc_init_hw to xe_uc_load_hwMaarten Lankhorst
It feels to me like load is closer to the intention than init_hw. It makes the init calls slightly less confusing to me. :) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-24-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Remove xe_uc_fini_hwMaarten Lankhorst
xe_uc_init_hw() is called multiple times from xe_gt.c, and that makes the name xe_uc_fini_hw(), called for a different reason in xe_guc.c confusing. Remove it and inline the xe_uc_sanitize_reset into xe_guc.c directly. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-23-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Remove xe_uc_init_hwconfig()Maarten Lankhorst
This function is called immediately after xe_uc_init(), so just put it there instead. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-22-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Move xe_ttm_sys_mgr_init() downwards.Maarten Lankhorst
Now that all previous allocations are gone, ensure no new allocations will ever be done before xe_display_init_early(), by moving the call that allows allocations downwards. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-21-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Split init of xe_gt_init_hwconfig to xe_gt_init and *_earlyMaarten Lankhorst
Now that we added the separate step of initialising GUC in xe_gt_init_early, it should be ok to initialise the minimum during early init, and the rest after allocations are allowed. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-20-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Rename gt_init sub-functionsMaarten Lankhorst
s/gt_fw_domain_init/gt_init_with_gt_forcewake()/ s/all_fw_domain_init/gt_init_with_all_forcewake()/ Clarify that the functions are the part of gt_init() that are called with the respective power domains held. all_domain() of course only works after discovering and initialisation of force_wake on all engines, that's why the split is needed in the first place. Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-19-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Only dump PAT when xe_hw_engines_init_early failsMaarten Lankhorst
After discussion with Lucas De Marchi, it turns out that is the specific caller requiring a dump. This allows us to cleanup gt_init in a bit. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-18-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Make it possible to read instance0 MCR registers after ↵Maarten Lankhorst
xe_gt_mcr_init_early After mcr_init_early, we need to be able to do VRAM and CCS probing without hwconfig probe. Fortunately the relevant registers are all instance 0, which fortunately means no dependencies on further initialization is required. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-17-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Simplify GuC early initializationMaarten Lankhorst
Add a 2-stage GuC init. An early one for everything that is needed for VF, and a full one that loads GuC and is allowed to do allocations. Link: https://lore.kernel.org/r/20250619104858.418440-16-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-26drm/xe/sriov: Move VF bootstrap and query_config to vf_guc_initMaarten Lankhorst
We want to split up GUC init to an alloc and noalloc part to keep the init path the same for VF and !VF as much as possible. Everything in vf_guc_init should be done as early as possible, otherwise VRAM probing becomes impossible. Also move xe_gt_mmio_init to the end of xe_gt_init_early(), cleaning up the init in xe_device slightly. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-15-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/xe: Defer memirq init until neededMaarten Lankhorst
memirqs require allocations into GGTT, which we cannot use until after display is enabled. Now that the initialisation of interrupts is postponed, move memirq init too. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Link: https://lore.kernel.org/r/20250619104858.418440-14-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-26drm/i915/power: convert {SKL, ICL}_PW_CTL_IDX_TO_PG() macros to a functionJani Nikula
Add pw_ctl_idx_to_pg() helper function to deduplicate the open-coded usage of the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/3aa74825db0b900f93b94aa89d0242a354929b85.1750855148.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/power: relocate {SKL,ICL}_PW_CTL_IDX_TO_PG()Jani Nikula
Move the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros from intel_display_regs.h to intel_display_power_well.c. The mapping from index to PG can be hidden there. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/18e40b77eeb3517a056f1e567672163ec568ec55.1750855148.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/power: move enum skl_power_gate under displayJani Nikula
When the display registers were split off from i915_reg.h, enum skl_power_gate was left behind. Move it to intel_display_regs.h. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/495054983b74163ca7dcbf5a1b6a24099047bc64.1750855148.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.16-rc4). Conflicts: Documentation/netlink/specs/mptcp_pm.yaml 9e6dd4c256d0 ("netlink: specs: mptcp: replace underscores with dashes in names") ec362192aa9e ("netlink: specs: fix up indentation errors") https://lore.kernel.org/20250626122205.389c2cd4@canb.auug.org.au Adjacent changes: Documentation/netlink/specs/fou.yaml 791a9ed0a40d ("netlink: specs: fou: replace underscores with dashes in names") 880d43ca9aa4 ("netlink: specs: clean up spaces in brackets") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-26drm/xe: Implement and use the drm_pagemap populate_mm opThomas Hellström
Add runtime PM since we might call populate_mm on a foreign device. v3: - Fix a kerneldoc failure (Matt Brost) - Revert the bo type change from device to kernel (Matt Brost) v4: - Add an assert in xe_svm_alloc_vram (Matt Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250619134035.170086-4-thomas.hellstrom@linux.intel.com
2025-06-26drm/pagemap: Add a populate_mm opThomas Hellström
Add an operation to populate a part of a drm_mm with device private memory. Clarify how migration using it is intended to work. v3: - Kerneldoc fixes and updates (Matt Brost). v4: - More kerneldoc fixes. Rebase. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250619134035.170086-3-thomas.hellstrom@linux.intel.com
2025-06-26drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemapMatthew Brost
The migration functionality and track-keeping of per-pagemap VRAM mapped to the CPU mm is not per GPU_vm, but rather per pagemap. This is also reflected by the functions not needing the drm_gpusvm structures. So move to drm_pagemap. With this, drm_gpusvm shouldn't really access the page zone-device-data since its meaning is internal to drm_pagemap. Currently it's used to reject mapping ranges backed by multiple drm_pagemap allocations. For now, make the zone-device-data a void pointer. Alter the interface of drm_gpusvm_migrate_to_devmem() to ensure we don't pass a gpusvm pointer. Rename CONFIG_DRM_XE_DEVMEM_MIRROR to CONFIG_DRM_XE_PAGEMAP. Matt is listed as author of this commit since he wrote most of the code, and it makes sense to retain his git authorship. Thomas mostly moved the code around. v3: - Kerneldoc fixes (CI) - Don't update documentation about how the drm_pagemap migration should be interpreted until upcoming patches where the functionality is implemented. (Matt Brost) v4: - More kerneldoc fixes around timeslice_ms (Himal Ghimiray, Matt Brost) v6: - Fix an uninitialized pagemap pointer (CI) Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250619134035.170086-2-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm, drm_xe, Implement ttm_lru_walk_for_evict() using the guarded LRU ↵Thomas Hellström
iteration To avoid duplicating the tricky bo locking implementation, Implement ttm_lru_walk_for_evict() using the guarded bo LRU iteration. To facilitate this, support ticketlocking from the guarded bo LRU iteration. v2: - Clean up some static function interfaces (Christian König) - Fix Handling -EALREADY from ticketlocking in the loop by skipping to the next item. (Intel CI) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-4-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm, drm/xe: Modify the struct ttm_bo_lru_walk_cursor initializationThomas Hellström
Instead of the struct ttm_operation_ctx, Pass a struct ttm_lru_walk_arg to enable us to easily extend the walk functionality, and to implement ttm_lru_walk_for_evict() using the guarded LRU iteration. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-3-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm: Use a struct for the common part of struct ttm_lru_walk and struct ↵Thomas Hellström
ttm_bo_lru_cursor Let the locking functions take the new struct ttm_lru_walk_arg as argument in order for them to be easily used from both types of walk. v2: - Whitespace fix Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-2-thomas.hellstrom@linux.intel.com
2025-06-26drm/i915/selftests: Change mock_request() to return error pointersDan Carpenter
There was an error pointer vs NULL bug in __igt_breadcrumbs_smoketest(). The __mock_request_alloc() function implements the smoketest->request_alloc() function pointer. It was supposed to return error pointers, but it propogates the NULL return from mock_request() so in the event of a failure, it would lead to a NULL pointer dereference. To fix this, change the mock_request() function to return error pointers and update all the callers to expect that. Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/685c1417.050a0220.696f5.5c05@mx.google.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-26drm/panel-edp: Add CMN N116BCJ-EAKLangyan Ye
Add support for the CMN N116BCJ-EAK, pleace the EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0d ae 63 11 00 00 00 00 19 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20 a6 00 00 90 10 00 00 18 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 80 Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250626122854.193239-1-yelangyan@huaqin.corp-partner.google.com
2025-06-26drm/bridge: ti-sn65dsi86: remove unnecessary GPIO line direction checkBartosz Golaszewski
As of commit 92ac7de3175e3 ("gpiolib: don't allow setting values on input lines"), the GPIO core makes sure values cannot be set on input lines. Remove the unnecessary check. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250620074951.32758-1-brgl@bgdev.pl
2025-06-26drm/xe: Process deferred GGTT node removals on device unwindMichal Wajdeczko
While we are indirectly draining our dedicated workqueue ggtt->wq that we use to complete asynchronous removal of some GGTT nodes, this happends as part of the managed-drm unwinding (ggtt_fini_early), which could be later then manage-device unwinding, where we could already unmap our MMIO/GMS mapping (mmio_fini). This was recently observed during unsuccessful VF initialization: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes) and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] <TASK> [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3d Add managed-device action that will explicitly drain the workqueue with all pending node removals prior to releasing MMIO/GSM mapping. Fixes: 919bb54e989c ("drm/xe: Fix missing runtime outer protection for ggtt_remove_node") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250612220937.857-2-michal.wajdeczko@intel.com (cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-26drm/bridge: add warning for bridges not using devm_drm_bridge_alloc()Luca Ceresoli
To the best of my knowledge, all drivers in the mainline kernel adding a DRM bridge are now converted to using devm_drm_bridge_alloc() for allocation and initialization. Among others this ensures initialization of the bridge refcount, allowing dynamic allocation lifetime. devm_drm_bridge_alloc() is now mandatory for all new bridges. Code using the old pattern ([devm_]kzalloc + filling the struct fields + drm_bridge_add) is not allowed anymore. Any drivers that might have been missed during the conversion, patches in flight towards mainline and out-of-tre drivers still using the old pattern will already be caught by a warning looking like: ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 2 PID: 83 at lib/refcount.c:25 refcount_warn_saturate+0x120/0x148 [...] Call trace: refcount_warn_saturate+0x120/0x148 (P) drm_bridge_get.part.0+0x70/0x98 [drm] drm_bridge_add+0x34/0x108 [drm] sn65dsi83_probe+0x200/0x480 [ti_sn65dsi83] [...] This warning comes from the refcount code and happens because drm_bridge_add() is increasing the refcount, which is uninitialized and thus initially zero. Having a warning and the corresponding stack trace is surely useful, but the warning text does not clarify the root problem nor how to fix it. Add a DRM_WARN() just before increasing the refcount, so the log will be much more readable: [drm] DRM bridge corrupted or not allocated by devm_drm_bridge_alloc() ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. [...etc...] A DRM_WARN is used because drm_warn and drm_WARN require a struct drm_device pointer which is not yet available when adding a bridge. Do not print the dev_name() in the warning because struct drm_bridge has no pointer to the struct device. The affected driver should be easy to catch based on the following stack trace however. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-3-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/bridge: get/put the bridge reference in drm_bridge_attach/detach()Luca Ceresoli
drm_bridge_attach() adds the bridge to the encoder chain, so take a reference for that. Vice versa in drm_bridge_detach(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-2-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/bridge: get/put the bridge reference in drm_bridge_add/remove()Luca Ceresoli
drm_bridge_add() adds the bridge to the global bridge_list, so take a reference for that. Vice versa in drm_bridge_remove(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-1-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/xe/guc: Explicitly exit CT safe mode on unwindMichal Wajdeczko
During driver probe we might be briefly using CT safe mode, which is based on a delayed work, but usually we are able to stop this once we have IRQ fully operational. However, if we abort the probe quite early then during unwind we might try to destroy the workqueue while there is still a pending delayed work that attempts to restart itself which triggers a WARN. This was recently observed during unsuccessful VF initialization: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0 Exit the CT safe mode on unwind to avoid that warning. Fixes: 09b286950f29 ("drm/xe/guc: Allow CTB G2H processing without G2H IRQ") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250612220937.857-3-michal.wajdeczko@intel.com (cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-26drm/xe: move DPT l2 flush to a more sensible placeMatthew Auld
Only need the flush for DPT host updates here. Normal GGTT updates don't need special flush. Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250606104546.1996818-4-matthew.auld@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 35db1da40c8cfd7511dc42f342a133601eb45449) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-26drm/xe: Move DSB l2 flush to a more sensible placeMaarten Lankhorst
Flushing l2 is only needed after all data has been written. Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340") Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250606104546.1996818-3-matthew.auld@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 0dd2dd0182bc444a62652e89d08c7f0e4fde15ba) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-26drm/tidss: Add OLDI bridge supportAradhya Bhatia
The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it possible to connect them in dual-link or cloned single-link OLDI display modes. The current OLDI support in tidss_dispc.c can only support for a single OLDI TX, connected to a VP and doesn't really support configuration of OLDIs in the other modes. The current OLDI support in tidss_dispc.c also works on the principle that the OLDI output can only be served by one, and only one, DSS video-port. This isn't the case in the AM62Px SoC, where there are 2 DSS controllers present that share the OLDI TXes. Having their own devicetree and their own bridge entity will help support the various display modes and sharing possiblilities of the OLDI hardware. For all these reasons, add support for the OLDI TXes as DRM bridges. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Michael Walle <mwalle@kernel.org> # on am67a Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/20250528122544.817829-5-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26drm/tidss: Mark AM65x OLDI code separatelyAradhya Bhatia
The dss dt schema and the tidss driver have kept the single-link OLDI in AM65x integrated with the parent video-port (VP) from DSS (as the OLDI configuration happens from the source VP only). To help configure the dual-lvds modes that the OLDI has to offer in devices AM62x and later, a new OLDI bridge driver will be introduced. Mark the existing OLDI code separately by renaming all the current OLDI identifiers with the 'AM65X_' prefix in tidss driver, to help distinguish from the upcoming OLDI bridge driver. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Link: https://lore.kernel.org/r/20250528122544.817829-4-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26drm/i915/display: move unordered works to new private workqueueLuca Coelho
Create a new unordered workqueue to be used by the display code instead of relying on the i915 one. Then move all the unordered works used in the display code to use this new queue. Since this is an unordered workqueue, by definition there can't be any order dependency with non-display works, so no extra care is needed in regard to that. This is part of the effort to isolate the display code from i915. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250620091632.1256135-1-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2025-06-26drm/i915/cdclk: make struct intel_cdclk_state opaqueJani Nikula
With all the code touching struct intel_cdclk_state moved inside intel_cdclk.c, we move the struct definition there too, and make the type opaque. This nicely reduces includes from intel_cdclk.h. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/2b58c52e8cbcb66a48ecd4a1453e49dc7bd66289.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_actual() and ↵Jani Nikula
intel_cdclk_actual_voltage_level() Add intel_cdclk_actual() and intel_cdclk_actual_voltage_level() helpers to avoid looking at struct intel_cdclk_state internals outside of intel_cdclk.c. v2: Better location (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/241a9b80a8262b82fded54707ca5622af215dd86.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_read_hw()Jani Nikula
Add intel_cdclk_read_hw() function to avoid looking at struct intel_cdclk_state internals outside of intel_cdclk.c. intel_cdclk_init_hw() would be a better name, but we already have that. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/ef720d37bfeee933d59b64e382dc976f3c9fade1.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_force_min_cdclk()Jani Nikula
Add intel_cdclk_force_min_cdclk() helper to avoid modifying struct intel_cdclk_state internals outside of intel_cdclk.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/0bf8a94a1a7d3ac564406ba427d12c4c8eefb5bb.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_pmdemand_needs_update()Jani Nikula
Add intel_cdclk_pmdemand_needs_update() helper to avoid looking at struct intel_cdclk_state internals outside of intel_cdclk.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/d0d4f073707a2badb432187f6e02d6d7f9fe431b.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_bw_min_cdclk()Jani Nikula
Add intel_cdclk_bw_min_cdclk() helper to avoid looking at struct intel_cdclk_state internals outside of intel_cdclk.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/d07499174ebe55fa8fb98d4cb5ff541b6f5ec95b.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_min_cdclk()Jani Nikula
Add intel_cdclk_min_cdclk() helper to avoid looking at struct intel_cdclk_state internals outside of intel_cdclk.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/af768e7fc32d8fa8ddcbbe2683266c30ae3b925d.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/cdclk: abstract intel_cdclk_logical()Jani Nikula
Add intel_cdclk_logical() helper to avoid looking at struct intel_cdclk_state internals outside of intel_cdclk.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/e965667550e82307341d6abbeedc67b93cae9fc6.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/bw: make struct intel_bw_state opaqueJani Nikula
With all the code touching struct intel_bw_state moved inside intel_bw.c, we move the struct definition there too, and make the type opaque. to_intel_bw_state() needs to be turned into a proper function. All of this nicely reduces includes from intel_bw.h. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/743ba67e4e3c5dac4f5e58ab4d2357edea601d09.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/bw: abstract intel_bw_qgv_point_peakbw()Jani Nikula
Add intel_bw_qgv_point_peakbw() helper to avoid looking at struct intel_bw_state internals outside of intel_bw.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/49a723e0f23e06a6045f8f9e0d06648a6bc899c7.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915: move icl_sagv_{pre, post}_plane_update() to intel_bw.cJani Nikula
Prefer only looking at struct intel_bw_state internals inside intel_bw.c. To that effect, move icl_sagv_{pre,post}_plane_update() there. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/dedcbeb3389ecd50195aa37de75e9992fae5d197.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/bw: relocate intel_can_enable_sagv() and rename to ↵Jani Nikula
intel_bw_can_enable_sagv() Prefer only looking at struct intel_bw_state internals inside intel_bw.c. To that effect, move intel_can_enable_sagv() there, and rename to intel_bw_can_enable_sagv() to have consistent naming. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/dd6e3857bd1343c07a36826e99c1c04f7dd5ddb5.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/bw: abstract intel_bw_pmdemand_needs_update()Jani Nikula
Add intel_bw_pmdemand_needs_update() helper to avoid looking at struct intel_bw_state internals outside of intel_bw.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/163fda39da2e1cf0f0c4fcb9c71103c98863179e.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/wm: make struct intel_dbuf_state opaque typeJani Nikula
With all the code touching struct intel_dbuf_state moved inside skl_watermark.c, we move the struct definition there too, and make the type opaque. This nicely reduces includes from skl_watermark.h. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/83ae5f022a1d6d83c031e5c079b04dc739102565.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/wm: add more accessors to dbuf stateJani Nikula
Add intel_dbuf_num_enabled_slices() and intel_dbuf_num_active_pipes() helpers to avoid looking at struct intel_dbuf_state internals outside of skl_watermark.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/7d555e7b4e93632b732b8b5a3cd4076baf781bee.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/wm: abstract intel_dbuf_pmdemand_needs_update()Jani Nikula
Add intel_dbuf_pmdemand_needs_update() helper to avoid looking at struct intel_dbuf_state internals outside of skl_watermark.c. With this, we can also move to_intel_dbuf_state(), intel_atomic_get_old_dbuf_state(), and intel_atomic_get_new_dbuf_state() inside skl_watermark.c. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/b493f259d0d3db047151fee18d7e801ad469fa88.1750847509.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit (git 2.34.1) at 2025-09-22 16:47:39 +0000