summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2025-09-09drm/xe/guc: Always add CT disable action during second init stepMichal Wajdeczko
On DGFX, during init_post_hwconfig() step, we are reinitializing CTB BO in VRAM and we have to replace cleanup action to disable CT communication prior to release of underlying BO. But that introduces some discrepancy between DGFX and iGFX, as for iGFX we keep previously added disable CT action that would be called during unwind much later. To keep the same flow on both types of platforms, always replace old cleanup action and register new one. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908102053.539-2-michal.wajdeczko@intel.com
2025-09-09drm/xe: Extend Wa_13011645652 to PTL-H, WCLJulia Filipchuk
Expand workaround to additional graphics architectures. Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.17+ Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250903190122.1028373-2-julia.filipchuk@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 6fc957185e1691bb6dfa4193698a229db537c2a2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/xe: Block exec and rebind worker while evicting for suspend / hibernateThomas Hellström
When the xe pm_notifier evicts for suspend / hibernate, there might be racing tasks trying to re-validate again. This can lead to suspend taking excessive time or get stuck in a live-lock. This behaviour becomes much worse with the fix that actually makes re-validation bring back bos to VRAM rather than letting them remain in TT. Prevent that by having exec and the rebind worker waiting for a completion that is set to block by the pm_notifier before suspend and is signaled by the pm_notifier after resume / wakeup. It's probably still possible to craft malicious applications that block suspending. More work is pending to fix that. v3: - Avoid wait_for_completion() in the kernel worker since it could potentially cause work item flushes from freezable processes to wait forever. Instead terminate the rebind workers if needed and re-launch at resume. (Matt Auld) v4: - Fix some bad naming and leftover debug printouts. - Fix kerneldoc. - Use drmm_mutex_init() for the xe->rebind_resume_lock (Matt Auld). - Rework the interface of xe_vm_rebind_resume_worker (Matt Auld). Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4288 Fixes: c6a4d46ec1d7 ("drm/xe: evict user memory in PM notifier") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250904160715.2613-4-thomas.hellstrom@linux.intel.com (cherry picked from commit 599334572a5a99111015fbbd5152ce4dedc2f8b7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/xe: Allow the pm notifier to continue on failureThomas Hellström
Its actions are opportunistic anyway and will be completed on device suspend. Marking as a fix to simplify backporting of the fix that follows in the series. v2: - Keep the runtime pm reference over suspend / hibernate and document why. (Matt Auld, Rodrigo Vivi): Fixes: c6a4d46ec1d7 ("drm/xe: evict user memory in PM notifier") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250904160715.2613-3-thomas.hellstrom@linux.intel.com (cherry picked from commit ebd546fdffddfcaeab08afdd68ec93052c8fa740) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/xe: Attempt to bring bos back to VRAM after evictionThomas Hellström
VRAM+TT bos that are evicted from VRAM to TT may remain in TT also after a revalidation following eviction or suspend. This manifests itself as applications becoming sluggish after buffer objects get evicted or after a resume from suspend or hibernation. If the bo supports placement in both VRAM and TT, and we are on DGFX, mark the TT placement as fallback. This means that it is tried only after VRAM + eviction. This flaw has probably been present since the xe module was upstreamed but use a Fixes: commit below where backporting is likely to be simple. For earlier versions we need to open- code the fallback algorithm in the driver. v2: - Remove check for dgfx. (Matthew Auld) - Update the xe_dma_buf kunit test for the new strategy (CI) - Allow dma-buf to pin in current placement (CI) - Make xe_bo_validate() for pinned bos a NOP. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5995 Fixes: a78a8da51b36 ("drm/ttm: replace busy placement with flags v6") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250904160715.2613-2-thomas.hellstrom@linux.intel.com (cherry picked from commit cb3d7b3b46b799c96b54f8e8fe36794a55a77f0b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/xe/configfs: Don't touch survivability_mode on finiMichal Wajdeczko
This is a user controlled configfs attribute, we should not modify that outside the configfs attr.store() implementation. Fixes: bc417e54e24b ("drm/xe: Enable configfs support for survivability mode") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250904103521.7130-1-michal.wajdeczko@intel.com (cherry picked from commit 079a5c83dbd23db7a6eed8f558cf75e264d8a17b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/xe: Never report L3 bank mask for media GT going forwardMatt Roper
We currently report an L3 bank mask as part of the GT topology on both GTs (primary and media) because a copy of the L3 bank fuse register exists on both GTs (e.g., $gsi_offset + 0x9130 on Xe3). After recent discussions it's come to light that the only known userspace software that uses this part of the uapi (the compute UMD and Mesa) only uses the value reported for the primary GT; the value reported for the media GT is ignored by both projects, and the media UMDs don't have any use for L3 information today. Since we always strive to have our uapi match the specific needs of userspace and not include additional unused baggage, let's officially drop L3 bank reporting on the media GT going forward and only keep it around for the primary GT where it actually gets used. This change will only apply to future platforms (Xe3 and later); even though it would probably be safe to remove it from Xe1/Xe2 as well, we don't want to take any chances with changing existing ABI. Note that we'd already disabled reading/reporting of the L3 bank for the media GT on PTL in commit 9ab440a9d042 ("drm/xe/ptl: L3bank mask is not available on the media GT") because it was discovered that the copy of the fuse registers on the media GT were just reporting a bogus ~0 value rather than an accurate mask. So this is just extending that PTL behavior forward to WCL and other future platforms. Note that we're also free to reinstate this part of the uapi in the future if/when some new userspace consumer emerges that _does_ have a use for media-specific L3 bank masks. Cc: Fei Yang <fei.yang@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250905215614.796247-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-09-09amd/amdkfd: correct mem limit calculation for small APUsYifan Zhang
Current mem limit check leaks some GTT memory (reserved_for_pt reserved_for_ras + adev->vram_pin_size) for small APUs. Since carveout VRAM is tunable on APUs, there are three case regarding the carveout VRAM size relative to GTT: 1. 0 < carveout < gtt apu_prefer_gtt = true, is_app_apu = false 2. carveout > gtt / 2 apu_prefer_gtt = false, is_app_apu = false 3. 0 = carveout apu_prefer_gtt = true, is_app_apu = true It doesn't make sense to check below limitation in case 1 (default case, small carveout) because the values in the below expression are mixed with carveout and gtt. adev->kfd.vram_used[xcp_id] + vram_needed > vram_size - reserved_for_pt - reserved_for_ras - atomic64_read(&adev->vram_pin_size) gtt: kfd.vram_used, vram_needed, vram_size carveout: reserved_for_pt, reserved_for_ras, adev->vram_pin_size In case 1, vram allocation will go to gtt domain, skip vram check since ttm_mem_limit check already cover this allocation. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fa7c99f04f6dd299388e9282812b14e95558ac8e)
2025-09-09drm/amdkfd: fix p2p links bug in topologyEric Huang
When creating p2p links, KFD needs to check XGMI link with two conditions, hive_id and is_sharing_enabled, but it is missing to check is_sharing_enabled, so add it to fix the error. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 36cc7d13178d901982da7a122c883861d98da624)
2025-09-09drm/amd/display: remove oem i2c adapter on finishGeoffrey McRae
Fixes a bug where unbinding of the GPU would leave the oem i2c adapter registered resulting in a null pointer dereference when applications try to access the invalid device. Fixes: 3d5470c97314 ("drm/amd/display/dm: add support for OEM i2c bus") Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Geoffrey McRae <geoffrey.mcrae@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6) Cc: stable@vger.kernel.org
2025-09-09drm/amd/display: Drop dm_prepare_suspend() and dm_complete()Mario Limonciello (AMD)
[Why] dm_prepare_suspend() was added in commit 50e0bae34fa6b ("drm/amd/display: Add and use new dm_prepare_suspend() callback") to allow display to turn off earlier in the suspend sequence. This caused a regression that HDMI audio sometimes didn't work properly after resume unless audio was playing during suspend. [How] Drop dm_prepare_suspend() callback. All code in it will still run during dm_suspend(). Also drop unnecessary dm_complete() callback. dm_complete() was used for failed prepare and also for any case of successful resume. The code in it already runs in dm_resume(). This change will introduce more time that the display is turned on during suspend sequence. The compositor can turn it off sooner if desired. Cc: Harry Wentland <harry.wentland@amd.com> Reported-by: Przemysław Kopa <prz.kopa@gmail.com> Closes: https://lore.kernel.org/amd-gfx/1cea0d56-7739-4ad9-bf8e-c9330faea2bb@kernel.org/T/#m383d9c08397043a271b36c32b64bb80e524e4b0f Reported-by: Kalvin <hikaph+oss@gmail.com> Closes: https://github.com/alsa-project/alsa-lib/issues/465 Closes: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4809 Fixes: 50e0bae34fa6b ("drm/amd/display: Add and use new dm_prepare_suspend() callback") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2fd653b9bb5aacec5d4c421ab290905898fe85a2) Cc: stable@vger.kernel.org
2025-09-09drm/amd/display: Correct sequences and delays for DCN35 PG & RCGOvidiu Bunea
[why] The current PG & RCG programming in driver has some gaps and incorrect sequences. [how] Added delays after ungating clocks to allow ramp up, increased polling to allow more time for power up, and removed the incorrect sequences. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1bde5584e297921f45911ae874b0175dce5ed4b5) Cc: stable@vger.kernel.org
2025-09-09drm/amd/display: Disable DPCD Probe QuirkFangzhi Zuo
Disable dpcd probe quirk to native aux. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4500 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250904191351.746707-1-Jerry.Zuo@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c5f4fb40584ee591da9fa090c6f265d11cbb1acf) Cc: stable@vger.kernel.org # 6.16.y: 5281cbe0b55a Cc: stable@vger.kernel.org # 6.16.y: 0b4aa85e8981 Cc: stable@vger.kernel.org # 6.16.y: b87ed522b364 Cc: stable@vger.kernel.org # 6.16.y
2025-09-09drm/i915/gt: Fix memory leak in hangcheck selftestJonathan Cavitt
In active_engines, if intel_context_create fails, we need to go backwards through all the created contexts to free/put them. However, the way this is currently performed skips the first created context, as if count == 1, then --count returns 0 and exits the while-loop prematurely without performing the intel_context_put on context 0. Fix this by post-decrementing count in the while-loop, rather than pre-decrementing it. This change makes the prior guard against count underflowing unnecessary, as the while-loop exits when count == 0. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Krzysztof Karas <krzysztof.karas@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20250904193041.12888-2-jonathan.cavitt@intel.com
2025-09-09drm/xe/debugfs: Don't expose dgfx residencies attributes on VFMichal Wajdeczko
In addition of checking if we are running on the BATTLEMAGE, we should also check for not being a VF driver, as VFs can't access necessary registers, and doing so leads to: | .. [drm] GT0: VF is trying to read an inaccessible register 0x35b004+0x0 | RIP: 0010:xe_gt_sriov_vf_read32+0x5e2/0x8a0 [xe] | Call Trace: | xe_mmio_read32+0x110/0x280 [xe] | read_residency_counter+0x42/0xd0 [xe] | dgfx_pkg_residencies_show+0x115/0x190 [xe] | .. [drm] Package G2 counter failed to read, ret -19 or | .. [drm] GT0: VF is trying to read an inaccessible register 0x35b004+0x0 | RIP: 0010:xe_gt_sriov_vf_read32+0x5e2/0x8a0 [xe] | Call Trace: | xe_mmio_read32+0x110/0x280 [xe] | read_residency_counter+0x42/0xd0 [xe] | dgfx_pcie_link_residencies_show+0xe7/0x160 [xe] | .. [drm] PCIE LINK L0 RESIDENCY counter failed to read, ret -19 Similarly, there is no point to expose inject_csc_hw_error on VFs, as HW errors support is already disabled for VFs. Bspec: 53221 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Soham Purkait <soham.purkait@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250905173625.8398-1-michal.wajdeczko@intel.com
2025-09-09drm/i915: Drop unused struct_mutex from drm_i915_privateLuiz Otavio Mello
The struct_mutex field in drm_i915_private is no longer used anywhere in the driver. This patch removes it completely to clean up unused code and avoid confusion. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-9-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Clean-up outdated struct_mutex commentsLuiz Otavio Mello
The struct_mutex will be removed from the DRM subsystem, as it was a legacy BKL that was only used by i915 driver. After review, it was concluded that its usage was no longer necessary This patch updates various comments in the i915 codebase to either remove or clarify references to struct_mutex, in order to prevent future misunderstandings. * i915_drv.h: Removed the statement that stolen_lock is the inner lock when overlaps with struct_mutex, since struct_mutex is no longer used in the driver. * i915_gem.c: Removed parentheses suggesting usage of struct_mutex, which which is no longer used. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-8-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915/display: Remove outdated struct_mutex commentsLuiz Otavio Mello
The struct_mutex will be removed from the DRM subsystem, as it was a legacy BKL that was only used by i915 driver. After review, it was concluded that its usage was no longer necessary This patch update a comment about struct_mutex in i915/display, in order to prevent future misunderstandings. * intel_fbc.c: Removed the statement that intel_fbc->lock is the inner lock when overlapping with struct_mutex, since struct_mutex is no longer used anywhere in the driver. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-7-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915/gem: Clean-up outdated struct_mutex commentsLuiz Otavio Mello
The struct_mutex will be removed from the DRM subsystem, as it was a legacy BKL that was only used by i915 driver. After review, it was concluded that its usage was no longer necessary This patch updates various comments in the i915/gem and i915/gt codebase to either remove or clarify references to struct_mutex, in order to prevent future misunderstandings. * i915_gem_execbuffer.c: Replace reference to struct_mutex with vm->mutex, as noted in the eb_reserve() function, which states that vm->mutex handles deadlocks. * i915_gem_object.c: Change struct_mutex by drm_i915_gem_object->vma.lock. i915_gem_object_unbind() in i915_gem.c states that this lock is who actually protects the unbind. * i915_gem_shrinker.c: The correct lock is actually i915->mm.obj, as already documented in its declaration. * i915_gem_wait.c: The existing comment already mentioned that struct_mutex was no longer necessary. Updated to refer to a generic global lock instead. * intel_reset_types.h: Cleaned up the comment text. Updated to refer to a generic global lock instead. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-6-luiz.mello@estudante.ufscar.br Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Replace struct_mutex in intel_guc_logLuiz Otavio Mello
Remove the use of struct_mutex from intel_guc_log.c and replace it with a dedicated lock, guc_lock, defined within the intel_guc_log struct.      The struct_mutex was previously used to protect concurrent access and modification of intel_guc_log->level in intel_guc_log_set_level(). However, it was suggested that the lock should reside within the intel_guc_log struct itself.      Initialize the new guc_lock in intel_guc_log_init_early(), alongside the existing relay.lock. The lock is initialized using drmm_mutex_init(), which also ensures it is properly destroyed when the driver is unloaded. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-5-luiz.mello@estudante.ufscar.br Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Change mutex initialization in intel_guc_logLuiz Otavio Mello
The intel_guc_log->relay.lock is currently initialized in intel_guc_log_init_early(), but it lacks a corresponding destructor, which can lead to a memory leak. This patch replaces the use of mutex_init() with drmm_mutex_init(), which ensures the lock is properly destroyed when the driver is unloaded. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-4-luiz.mello@estudante.ufscar.br Acked-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/bridge: ite-it6263: Support HDMI vendor specific infoframeLiu Ying
IT6263 supports HDMI vendor specific infoframe. The infoframe header and payload are configurable via NULL packet registers. The infoframe is enabled and disabled via PKT_NULL_CTRL register. Add the HDMI vendor specific infoframe support. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250908-it6263-vendor-specific-infoframe-v2-1-3f2ebd9135ad@nxp.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/bridge: write full Audio InfoFrameDmitry Baryshkov
Instead of writing the first byte of the infoframe (and hoping that the rest is default / zeroes), hook Audio InfoFrame support into the write_infoframe / clear_infoframes callbacks and use drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the frame. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/bridge: adv7511: use update latch for AVI infoframesDmitry Baryshkov
Instead of disabling and then reenabling AVI infoframe, use the recommended way of updating it on the fly: latch current values using the ADV7511_REG_INFOFRAME_UPDATE register. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-1-05b24459b9a4@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/i915: Remove struct_mutex in i915_irq.cLuiz Otavio Mello
Remove struct_mutex from ivb_parity_work() function. The ivb_parity_work runs in a workqueue so it cannot race with itself. Also, it is not protecting anything with the other remaining usage of struct_mutex. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-3-luiz.mello@estudante.ufscar.br Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/i915: Move struct_mutex to drm_i915_privateLuiz Otavio Mello
Move legacy BKL struct_mutex from drm_device to drm_i915_private, which is the last remaining user. Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250908131518.36625-2-luiz.mello@estudante.ufscar.br Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-09drm/msm/mdp4: remove the use of dev_err_probe()Liao Yuanhong
Logging messages that show some type of "out of memory" error are generally unnecessary as there is a generic message and a stack dump done by the memory subsystem. These messages generally increase kernel size without much added value[1]. The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. [1]: https://lore.kernel.org/lkml/1402419340.30479.18.camel@joe-AO725/ Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/670017/ Link: https://lore.kernel.org/r/20250820131300.499727-1-liaoyuanhong@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/dpu: fix incorrect type for retQianfeng Rong
Change 'ret' from unsigned long to int, as storing negative error codes in an unsigned long makes it never equal to -ETIMEDOUT, causing logical errors. Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/671100/ Link: https://lore.kernel.org/r/20250826092047.224341-1-rongqianfeng@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/a6xx: Add a comment to acd_probe()Akhil P Oommen
It is not obvious why we can skip error checking of dev_pm_opp_find_freq_exact() API. Add a comment explaining it. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/672263/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-4-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/adreno: Add a modparam to skip GPUAkhil P Oommen
During bringup of a new GPU support, it is convenient to have knob to quickly disable GPU, but keep the display support. This helps to fallback to 'kms_swrast' in case of bootup issues due to GPU. Add a modparam to support this. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/672262/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-3-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm: Fix bootup splat with separate_gpu_drm modparamAkhil P Oommen
The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses drm_gem_obj.gpuva.list, which is not initialized when the drm driver does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam is set: [ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0 [ 9.523160] Mem abort info: [ 9.523161] ESR = 0x0000000096000006 [ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits [ 9.523165] SET = 0, FnV = 0 [ 9.523166] EA = 0, S1PTW = 0 [ 9.523167] FSC = 0x06: level 2 translation fault [ 9.523169] Data abort info: [ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000 [ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000 [ 9.523184] Internal error: Oops: 0000000096000006 [#1] SMP [ 9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT [ 9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024 [ 9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 9.592973] pc : lookup_vma+0x28/0xe0 [msm] [ 9.592996] lr : get_vma_locked+0x2c/0x128 [msm] [ 9.763632] sp : ffff800082dab460 [ 9.763666] Call trace: [ 9.763668] lookup_vma+0x28/0xe0 [msm] (P) [ 9.763688] get_vma_locked+0x2c/0x128 [msm] [ 9.763706] msm_gem_get_and_pin_iova_range+0x68/0x11c [msm] [ 9.763723] msm_gem_get_and_pin_iova+0x18/0x24 [msm] [ 9.763740] msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm] [ 9.763760] __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper] [ 9.763771] drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper] [ 9.763779] drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib] [ 9.763782] drm_client_register+0x58/0x9c [drm] [ 9.763806] drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib] [ 9.763809] drm_client_setup+0xb4/0xd8 [drm_client_lib] [ 9.763811] msm_drm_kms_post_init+0x2c/0x3c [msm] [ 9.763830] msm_drm_init+0x1a8/0x22c [msm] [ 9.763848] msm_drm_bind+0x30/0x3c [msm] [ 9.919273] try_to_bring_up_aggregate_device+0x168/0x1d4 [ 9.919283] __component_add+0xa4/0x170 [ 9.919286] component_add+0x14/0x20 [ 9.919288] msm_dp_display_probe_tail+0x4c/0xac [msm] [ 9.919315] msm_dp_auxbus_done_probe+0x14/0x20 [msm] [ 9.919335] dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus] [ 9.919341] really_probe+0xbc/0x298 [ 9.919345] __driver_probe_device+0x78/0x12c [ 9.919348] driver_probe_device+0x40/0x160 [ 9.919350] __driver_attach+0x94/0x19c [ 9.919353] bus_for_each_dev+0x74/0xd4 [ 9.919355] driver_attach+0x24/0x30 [ 9.919358] bus_add_driver+0xe4/0x208 [ 9.919360] driver_register+0x60/0x128 [ 9.919363] __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus] [ 9.919365] atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20] [ 9.919370] do_one_initcall+0x6c/0x1b0 [ 9.919374] do_init_module+0x58/0x234 [ 9.919377] load_module+0x19cc/0x1bd4 [ 9.919380] init_module_from_file+0x84/0xc4 [ 9.919382] __arm64_sys_finit_module+0x1b8/0x2cc [ 9.919384] invoke_syscall+0x48/0x110 [ 9.919389] el0_svc_common.constprop.0+0xc8/0xe8 [ 9.919393] do_el0_svc+0x20/0x2c [ 9.919396] el0_svc+0x34/0xf0 [ 9.919401] el0t_64_sync_handler+0xa0/0xe4 [ 9.919403] el0t_64_sync+0x198/0x19c [ 9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44) [ 9.919410] ---[ end trace 0000000000000000 ]--- Fixes: 217ed15bd399 ("drm/msm: enable separate binding of GPU and display devices") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/672257/ Link: https://lore.kernel.org/r/20250902-assorted-sept-1-v1-1-f3ec9baed513@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09drm/msm/dsi/phy: Fix reading zero as PLL rates when unpreparedKrzysztof Kozlowski
Hardware Programming Guide for DSI PHY says that PLL_SHUTDOWNB and DIGTOP_PWRDN_B have to be asserted for any PLL register access. Whenever dsi_pll_7nm_vco_recalc_rate() or dsi_pll_7nm_vco_set_rate() were called on unprepared PLL, driver read values of zero leading to all sort of further troubles, like failing to set pixel and byte clock rates. Asserting the PLL shutdown bit is done by dsi_pll_enable_pll_bias() (and corresponding dsi_pll_disable_pll_bias()) which are called through the code, including from PLL .prepare() and .unprepare() callbacks. The .set_rate() and .recalc_rate() can be called almost anytime from external users including times when PLL is or is not prepared, thus driver should not interfere with the prepare status. Implement simple reference counting for the PLL bias, so set_rate/recalc_rate will not change the status of prepared PLL. Issue of reading 0 in .recalc_rate() did not show up on existing devices, but only after re-ordering the code for SM8750. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673416/ Link: https://lore.kernel.org/r/20250908094950.72877-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-09gpu: drm: display: drm_dp_cec: update Hans' email addressHans Verkuil
Replace hverkuil@xs4all.nl by hverkuil@kernel.org. Signed-off-by: Hans Verkuil <hverkuil@kernel.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-09-09drm/xe/hwmon: Use devm_mutex_init()Christophe JAILLET
Use devm_mutex_init() instead of hand-writing it. This saves some LoC, improves readability and saves some space in the generated .o file. Before: ====== text data bss dec hex filename 36884 10296 64 47244 b88c drivers/gpu/drm/xe/xe_hwmon.o After: ===== text data bss dec hex filename 36651 10224 64 46939 b75b drivers/gpu/drm/xe/xe_hwmon.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/989e96369e9e1f8a44b816962917ec76877c912d.1757252520.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-09drm/xe/debugfs: Make residencies definitions constMichal Wajdeczko
No need to keep them non-const. Also fix declaration of .name member, as it points to the const string. This translates to: add/remove: 1/0 grow/shrink: 0/2 up/down: 80/-248 (-168) Function old new delta residencies - 80 +80 dgfx_pcie_link_residencies_show 365 263 -102 dgfx_pkg_residencies_show 454 308 -146 Total: Before=2821548, After=2821380, chg -0.01% Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Soham Purkait <soham.purkait@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Karthik Poosa <karthik.poosa@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250905180225.8434-1-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-09drm/xe/i2c: Enable bus masteringRaag Jadav
Enable bus mastering for I2C controller to support device initiated in-band transactions. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250908055320.2549722-1-raag.jadav@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-09drm/xe/vf: Move VF CCS debugfs attributeMichal Wajdeczko
The VF CCS handling is per-device so its debugfs file should not be exposed on per-GT basis. Move it up to the device level. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-8-michal.wajdeczko@intel.com
2025-09-09drm/xe/vf: Move VF CCS data to xe_deviceMichal Wajdeczko
We only need single set of VF CCS contexts, they are not per-tile as initial implementation might suggest. Move all VF CCS data from xe_tile.sriov.vf to xe_device.sriov.vf. Also rename some structs to align with the usage and fix their kernel-doc. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-7-michal.wajdeczko@intel.com
2025-09-09drm/xe/bo: Add xe_bo_has_valid_ccs_bb helperMichal Wajdeczko
This will allow as to drop ugly IS_VF_CCS_BB_VALID macro. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-6-michal.wajdeczko@intel.com
2025-09-09drm/xe/vf: Use single check when calling VF CCS functionsMichal Wajdeczko
All xe_sriov_vf_ccs() functions but init() expect to be called when initialization was successful and CCS handling is ready. Update IS_VF_CCS_READY macro and use it as single entry guard. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-5-michal.wajdeczko@intel.com
2025-09-09drm/xe/vf: Drop IS_VF_CCS_INIT_NEEDED macroMichal Wajdeczko
We only use this macro once and we can open-code it to explicitly show relevant conditions and avoid duplications. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-4-michal.wajdeczko@intel.com
2025-09-09drm/xe/guc: Use proper flag definitions when registering contextMichal Wajdeczko
In H2G action context type is specified in flags dword in bits 2:1. Use generic FIELD_PREP macro instead of misleading BIT logic. 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/20250908123025.747-3-michal.wajdeczko@intel.com
2025-09-09drm/xe/guc: Rename xe_guc_register_exec_queueMichal Wajdeczko
This function is dedicated for use by the VFs, we shouldn't use name that might suggests it's general purpose. While there, update asserts to better reflect intended usage. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://lore.kernel.org/r/20250908123025.747-2-michal.wajdeczko@intel.com
2025-09-09drm/gma500: Do not clear framebuffer GEM objects during cleanupThomas Zimmermann
Gma500 unnecessarily clears the framebuffer's GEM-object pointer before calling drm_framebuffer_cleanup(). Remove this code to make gma500 consistent with the rest of the drivers. The change is cosmetic, as drm_framebuffer_cleanup() does not touch the object pointer on gma500. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250904121157.395128-1-tzimmermann@suse.de
2025-09-09drm/i915/power: fix size for for_each_set_bit() in abox iterationJani Nikula
for_each_set_bit() expects size to be in bits, not bytes. The abox mask iteration uses bytes, but it works by coincidence, because the local variable holding the mask is unsigned long, and the mask only ever has bit 2 as the highest bit. Using a smaller type could lead to subtle and very hard to track bugs. Fixes: 62afef2811e4 ("drm/i915/rkl: RKL uses ABOX0 for pixel transfers") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v5.9+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250905104149.1144751-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7ea3baa6efe4bb93d11e1c0e6528b1468d7debf6) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-09-09drm/i915/display: add intel_display_device_present()Jani Nikula
Add a proper function for display && HAS_DISPLAY(display) to hide indirect struct intel_display access via the macro from a number of places outside of display. This makes struct intel_display * an opaque pointer in these places. All HAS_DISPLAY() usage is now constrained within display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250903090408.3492875-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-09drm/i915/backlight: Disable backlight when using luminance controlSuraj Kandpal
We just return when using luminance control instead we should be calling the disable helper to get everything cleaned up properly by default. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250904044804.948391-1-suraj.kandpal@intel.com
2025-09-09drm/bridge: simple: add Realtek RTD2171 DP-to-HDMI bridgeNeil Armstrong
Add support for the transparent Realtek RTD2171 DP-to-HDMI bridge. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250908-topic-x1e80100-hdmi-v3-2-c53b0f2bc2fb@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-08rust: drm: gem: Simplify use of genericsLyude Paul
Now that my rust skills have been honed, I noticed that there's a lot of generics in our gem bindings that don't actually need to be here. Currently the hierarchy of traits in our gem bindings looks like this: * Drivers implement: * BaseDriverObject<T: DriverObject> (has the callbacks) * DriverObject (has the drm::Driver type) * Crate implements: * IntoGEMObject for Object<T> where T: DriverObject Handles conversion to/from raw object pointers * BaseObject for T where T: IntoGEMObject Provides methods common to all gem interfaces Also of note, this leaves us with two different drm::Driver associated types: * DriverObject::Driver * IntoGEMObject::Driver I'm not entirely sure of the original intent here unfortunately (if anyone is, please let me know!), but my guess is that the idea would be that some objects can implement IntoGEMObject using a different ::Driver than DriverObject - presumably to enable the usage of gem objects from different drivers. A reasonable usecase of course. However - if I'm not mistaken, I don't think that this is actually how things would go in practice. Driver implementations are of course implemented by their associated drivers, and generally drivers are not linked to each-other when building the kernel. Which is to say that even in a situation where we would theoretically deal with gem objects from another driver, we still wouldn't have access to its drm::driver::Driver implementation. It's more likely we would simply want a variant of gem objects in such a situation that have no association with a drm::driver::Driver type. Taking that into consideration, we can assume the following: * Anything that implements BaseDriverObject will implement DriverObject In other words, all BaseDriverObjects indirectly have an associated ::Driver type - so the two traits can be combined into one with no generics. * Not everything that implements IntoGEMObject will have an associated ::Driver, and that's OK. And with this, we now can do quite a bit of cleanup with the use of generics here. As such, this commit: * Removes the generics on BaseDriverObject * Moves DriverObject::Driver into BaseDriverObject * Removes DriverObject * Removes IntoGEMObject::Driver * Add AllocImpl::Driver, which we can use as a binding to figure out the correct File type for BaseObject Leaving us with a simpler trait hierarchy that now looks like this: * Drivers implement: BaseDriverObject * Crate implements: * IntoGEMObject for Object<T> where T: DriverObject * BaseObject for T where T: IntoGEMObject Which makes the code a lot easier to understand and build on :). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250908185239.135849-2-lyude@redhat.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-08drm/panel-edp: Add 4 more panels needed by mt8189 ChromebooksZhongtian Wu
Add a few generic edp panels used by mt8189 chromebooks. For BOE-NV140WUM-N44 , the enable timing required 80ms. For CSW-MNE007QB3-1, the hpd_absent timing rquired 80ms, the enable timing required 50ms, the disable timing required 50ms. For CSW-MNE007QS3-6, the enable timing required 50ms. For CMN-N140JCA-ELK, the enable timing required 80ms and disable timing required 50ms. BOE NV140WUM-N44 V8.2 edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 6a 0a 00 00 00 00 2e 20 01 04 a5 1e 13 78 03 fb f5 96 5d 5a 91 29 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 61 40 80 04 71 b0 3c 40 30 20 36 00 2d bc 10 00 00 1a 81 33 80 04 71 b0 3c 40 30 20 36 00 2d bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 56 31 34 30 57 55 4d 2d 4e 34 34 0a 01 7c 02 03 0d 00 68 1a 00 00 01 01 28 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 CSW MNE007QB3-1: edid-decode (hex): 00 ff ff ff ff ff ff 00 0e 77 6e 14 00 00 00 00 00 23 01 04 a5 1e 13 78 07 ee 95 a3 54 4c 99 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 35 3c 80 a0 70 b0 23 40 30 20 36 00 2d bc 10 00 00 18 2b 30 80 a0 70 b0 23 40 30 20 36 00 2d bc 10 00 00 18 00 00 00 fd 00 28 3c 4a 4a 0f 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4d 4e 45 30 30 37 51 42 33 2d 31 0a 20 01 69 70 20 79 02 00 21 00 1d c8 0b 5d 07 80 07 b0 04 00 3d 8a 54 cd a4 99 66 62 0f 02 45 54 40 5e 40 5e 00 44 12 78 2e 00 06 00 44 40 5e 40 5e 81 00 20 74 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 8d 00 e3 05 04 00 e6 06 01 00 60 60 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 68 90 CSW MNE007QS3-6: edid-decode (hex): 00 ff ff ff ff ff ff 00 0e 77 3f 14 00 00 00 00 00 22 01 04 a5 1e 13 78 03 2c c5 94 5c 59 95 29 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ea 3d 80 c8 70 b0 2e 40 30 20 36 00 2e bd 10 00 00 1a 88 31 80 c8 70 b0 2e 40 30 20 36 00 2e bd 10 00 00 1a 00 00 00 fd 00 28 3c 4b 4b 10 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4d 4e 45 30 30 37 51 53 33 2d 36 0a 20 01 80 70 20 79 02 00 81 00 14 74 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9e 90 CMN N140JCA-ELK: edid-decode (hex): 00 ff ff ff ff ff ff 00 0d ae 41 14 00 00 00 00 25 21 01 04 a5 1e 13 78 03 28 65 97 59 54 8e 27 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 42 3c 80 a0 70 b0 24 40 30 20 a6 00 2d bc 10 00 00 18 35 30 80 a0 70 b0 24 40 30 20 a6 00 2d bc 10 00 00 18 00 00 00 fd 00 28 3c 4b 4b 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 31 34 30 4a 43 41 2d 45 4c 4b 0a 20 01 14 02 03 0d 00 68 1a 00 00 01 01 28 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Zhongtian Wu <wuzhongtian@huaqin.corp-partner.google.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250908063732.764289-1-wuzhongtian@huaqin.corp-partner.google.com
generated by cgit v1.3 (git 2.53.0) at 2026-11-02 13:50:38 +0000