summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-10drm/amdgpu: move GTT to shmem after eviction for hibernationSamuel Zhang
When hibernate with data center dGPUs, huge number of VRAM BOs evicted to GTT and takes too much system memory. This will cause hibernation fail due to insufficient memory for creating the hibernation image. Move GTT BOs to shmem in KMD, then shmem to swap disk in kernel hibernation code to make room for hibernation image. Signed-off-by: Samuel Zhang <guoqing.zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250710062313.3226149-3-guoqing.zhang@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2025-07-10drm/ttm: add new api ttm_device_prepare_hibernation()Samuel Zhang
This new api is used for hibernation to move GTT BOs to shmem after VRAM eviction. shmem will be flushed to swap disk later to reduce the system memory usage for hibernation. Signed-off-by: Samuel Zhang <guoqing.zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250710062313.3226149-2-guoqing.zhang@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2025-07-10drm/nouveau: Remove waitque for sched teardownPhilipp Stanner
struct nouveau_sched contains a waitque needed to prevent drm_sched_fini() from being called while there are still jobs pending. Doing so so far would have caused memory leaks. With the new memleak-free mode of operation switched on in drm_sched_fini() by providing the callback nouveau_sched_cancel_job() the waitque is not necessary anymore. Remove the waitque. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-10-phasta@kernel.org
2025-07-10drm/nouveau: Add new callback for scheduler teardownPhilipp Stanner
There is a new callback for always tearing the scheduler down in a leak-free, deadlock-free manner. Port Nouveau as its first user by providing the scheduler with a callback that ensures the fence context gets killed in drm_sched_fini(). Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-9-phasta@kernel.org
2025-07-10drm/nouveau: Make fence container helper usable driver-widePhilipp Stanner
In order to implement a new DRM GPU scheduler callback in Nouveau, a helper for obtaining a nouveau_fence from a dma_fence is necessary. Such a helper exists already inside nouveau_fence.c, called from_fence(). Make that helper available to other C files with a more precise name. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-8-phasta@kernel.org
2025-07-10drm/sched: Warn if pending_list is not emptyPhilipp Stanner
drm_sched_fini() can leak jobs under certain circumstances. Warn if that happens. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-7-phasta@kernel.org
2025-07-10drm/sched/tests: Add unit test for cancel_job()Philipp Stanner
The scheduler unit tests now provide a new callback, cancel_job(). This callback gets used by drm_sched_fini() for all still pending jobs to cancel them. Implement a new unit test to test this. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-6-phasta@kernel.org
2025-07-10drm/sched/tests: Implement cancel_job() callbackPhilipp Stanner
The GPU Scheduler now supports a new callback, cancel_job(), which lets the scheduler cancel all jobs which might not yet be freed when drm_sched_fini() runs. Using this callback allows for significantly simplifying the mock scheduler teardown code. Implement the cancel_job() callback and adjust the code where necessary. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-5-phasta@kernel.org
2025-07-10drm/sched: Avoid memory leaks with cancel_job() callbackPhilipp Stanner
Since its inception, the GPU scheduler can leak memory if the driver calls drm_sched_fini() while there are still jobs in flight. The simplest way to solve this in a backwards compatible manner is by adding a new callback, drm_sched_backend_ops.cancel_job(), which instructs the driver to signal the hardware fence associated with the job. Afterwards, the scheduler can safely use the established free_job() callback for freeing the job. Implement the new backend_ops callback cancel_job(). Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/dri-devel/20250418113211.69956-1-tvrtko.ursulin@igalia.com/ Reviewed-by: Maíra Canal <mcanal@igalia.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-4-phasta@kernel.org
2025-07-10drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs codeSimona Vetter
The object is potentially already gone after the drm_gem_object_put(). In general the object should be fully constructed before calling drm_gem_handle_create(), except the debugfs tracking uses a separate lock and list and separate flag to denotate whether the object is actually initialized. Since I'm touching this all anyway simplify this by only adding the object to the debugfs when it's ready for that, which allows us to delete that separate flag. panthor_gem_debugfs_bo_rm() already checks whether we've actually been added to the list or this is some error path cleanup. v2: Fix build issues for !CONFIG_DEBUGFS (Adrián) v3: Add linebreak and remove outdated comment (Liviu) Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Cc: Adrián Larumbe <adrian.larumbe@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250709135220.1428931-1-simona.vetter@ffwll.ch
2025-07-09fbcon: Fix outdated registered_fb reference in commentShixiong Ou
The variable was renamed to fbcon_registered_fb, but this comment was not updated along with the change. Correct it to avoid confusion. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Fixes: efc3acbc105a ("fbcon: Maintain a private array of fb_info") [sima: Add Fixes: line.] Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250709103438.572309-1-oushixiong1025@163.com
2025-07-09drm/ast: Gen7: Switch default registers to gen4+ stateThomas Zimmermann
Change the default register settings for Gen7 to mach Gen4 and later. Gen7 currently uses the settings for Gen1, which is most likely incorrect. Using Gen4+ settings enables E2M linear-access modes in VGACRA2. It appears to be related to the chip's PCIE2MBOX feature, which is unused. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-11-tzimmermann@suse.de
2025-07-09drm/ast: Gen7: Disable VGASR0[1] as on Gen4+Thomas Zimmermann
Set VGACRB6[5], which disables asynchronous sequencer resets via VGASR0[1]. This was most likely an oversight when adding support for Gen7. Aligns Gen7 with the earlier Gen4+. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-10-tzimmermann@suse.de
2025-07-09drm/ast: Split ast_set_def_ext_reg() by chip generationThomas Zimmermann
Duplicate ast_set_def_ext_reg() for individual chip generations and move call it into per-chip source files. Remove the original code. AST2100 and AST2500 reuse the function from earlier chips. AST2600 appears to be incorrect as it uses an older function. Keep this behavior for now. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-9-tzimmermann@suse.de
2025-07-09drm/ast: Handle known struct ast_dramstruct with helpersThomas Zimmermann
Most of struct ast_dramstruct stores hardware state. Some index values have known or special meaning. The known values are - 0xffff - Terminal entry in the array - 0xff00 - Delays the programming for usecs - 0x0004 - Sets the type of DRAM Add constants and helper macros for these cases. Also add a helper macro for testing. Update Gen1 and Gen2+ accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-8-tzimmermann@suse.de
2025-07-09drm/ast: Move struct ast_dramstruct to ast_post.hThomas Zimmermann
Declare struct ast_dramstruct in ast_post.h and remove its original header file. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-7-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen2+ and Gen1 POST code to separate source filesThomas Zimmermann
Move POST code for Gen2+ and Gen1 to separate source files and hide it in ast_2100_post() ans ast_2000_post(). With P2A configuration, the POST logic for these chip generations has been mingled in ast_init_dram_reg(). Hence, handle all generations in a single change. The split simplifies both cases. Also move the DRAM init tables for each Gen into the respective source file. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-6-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen4+ POST code to separate source fileThomas Zimmermann
Move POST code for Gen4+ to separate source file and hide it in ast_2300_post(). With P2A configuration, it performs a full board POST and enables the transmitter chip; otherwise it only enables the transmitter chip. Also fix coding style in several places. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-5-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen6+ POST code to separate source fileThomas Zimmermann
Move POST code for Gen6+ to separate source file and hide it in ast_2500_post(). With P2A configuration, it performs a full board POST; otherwise it enables the transmitter chip. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-4-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen7+ POST code to separate source fileThomas Zimmermann
Move POST code for Gen7+ to separate source file and hide it in ast_2600_post(). There's not much going on here except for enabling the DP transmitter chip. v2: - simplify logic (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-3-tzimmermann@suse.de
2025-07-09drm/ast: Declare helpers for POST in headerThomas Zimmermann
Provide POST helpers in header file before splitting up the AST POST code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-2-tzimmermann@suse.de
2025-07-09dma-buf: heaps: Give default CMA heap a fixed nameJared Kangas
The CMA heap's name in devtmpfs can vary depending on how the heap is defined. Its name defaults to "reserved", but if a CMA area is defined in the devicetree, the heap takes on the devicetree node's name, such as "default-pool" or "linux,cma". To simplify naming, unconditionally name it "default_cma_region", but keep a legacy node in place backed by the same underlying allocator for backwards compatibility. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jared Kangas <jkangas@redhat.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250610131231.1724627-4-jkangas@redhat.com
2025-07-09dma-buf: heaps: Parameterize heap name in __add_cma_heap()Jared Kangas
Prepare for the introduction of a fixed-name CMA heap by replacing the unused void pointer parameter in __add_cma_heap() with the heap name. Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: John Stultz <jstultz@google.com> Signed-off-by: Jared Kangas <jkangas@redhat.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250610131231.1724627-3-jkangas@redhat.com
2025-07-09Documentation: dma-buf: heaps: Fix code markupJared Kangas
Code snippets should be wrapped in double backticks to follow reStructuredText semantics; the use of single backticks uses the :title-reference: role by default, which isn't quite what we want. Add double backticks to code snippets to fix this. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jared Kangas <jkangas@redhat.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250610131231.1724627-2-jkangas@redhat.com
2025-07-09dma-buf: system_heap: No separate allocation for attachment sg_tablesT.J. Mercier
struct dma_heap_attachment is a separate allocation from the struct sg_table it contains, but there is no reason for this. Let's use the slab allocator just once instead of twice for dma_heap_attachment. Signed-off-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250417180943.1559755-1-tjmercier@google.com
2025-07-09drm/sched: Consolidate drm_sched_rq_select_entity_rrTvrtko Ursulin
Extract out two copies of the identical code to drm_sched_rq_select_entity_rr()'s epilogue to make it smaller and more readable. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> [phasta: commit message] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250708122121.75689-1-tvrtko.ursulin@igalia.com
2025-07-09drm/sti: hda: convert to devm_drm_bridge_alloc() APILuca Ceresoli
devm_drm_bridge_alloc() is the new API to be used for allocating (and partially initializing) a private driver struct embedding a struct drm_bridge. This driver was missed during the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API") and following commits. The lack of conversion for this driver is a bug since commit a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") which is the first commmit having added a drm_bridge_get/put() pair and thus exposing the incorrect initial refcount issue. Fix this by switching the driver to the new API. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/ Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-2-6285de8c3759@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-07-09drm/sti: hdmi: convert to devm_drm_bridge_alloc() APILuca Ceresoli
devm_drm_bridge_alloc() is the new API to be used for allocating (and partially initializing) a private driver struct embedding a struct drm_bridge. This driver was missed during the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API") and following commits. The lack of conversion for this driver is a bug since commit a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") which is the first commmit having added a drm_bridge_get/put() pair and thus exposing the incorrect initial refcount issue. Fix this by switching the driver to the new API. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/ Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-1-6285de8c3759@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-07-09drm/amdgpu: fix the logic to validate fpriv and root boSunil Khatri
Fix the smatch warning, smatch warnings: drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:2146 amdgpu_pt_info_read() error: we previously assumed 'fpriv' could be null (see line 2146) "if (!fpriv && !fpriv->vm.root.bo)", It has to be an OR condition rather than an AND which makes an NULL dereference in case fpriv is NULL. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507090525.9rDWGhz3-lkp@intel.com/ Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20250709071618.591866-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2025-07-09drm/amdgpu: fix MQD debugfs undefined symbol when DEBUG_FS=nSunil Khatri
Fix undefined reference to amdgpu_mqd_info_fops during debugfs_create_file if DEBUG_FS=n Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20250708101551.68033-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2025-07-08gpu/trace: make TRACE_GPU_MEM configurableJuston Li
Move the source to a better place in Device Drivers -> Graphics support now that its configurable. v4: - Move source location (Tvrtko) v3: - Patch introduced to replace per-driver config (Lucas) Signed-off-by: Juston Li <justonli@chromium.org> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250611225145.1739201-1-justonli@chromium.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-08drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there ↵Andy Yan
are multi display output on rk3588/rk3568 The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL and OVL_PORT_SEL registers, and the configuration of these two registers can be set to take effect when the vsync signal arrives at a certain Video Port. If two threads for two display output choose to update these two registers simultaneously to meet their own plane adjustment requirements(change plane zpos or switch plane from one crtc to another), then no matter which Video Port'svsync signal we choose to follow for these two registers, the display output of the other Video Port will be abnormal. This is because the configuration of this Video Port does not take effect at the right time (its configuration should take effect when its VSYNC signal arrives). In order to solve this problem, when performing plane migration or change the zpos of planes, there are two things to be observed and followed: 1. When a plane is migrated from one VP to another, the configuration of the layer can only take effect after the Port mux configuration is enabled. 2. When change the zpos of planes, we must ensure that the change for the previous VP takes effect before we proceed to change the next VP. Otherwise, the new configuration might overwrite the previous one for the previous VP, or it could lead to the configuration of the previous VP being take effect along with the VSYNC of the new VP. This issue only occurs in scenarios where multi-display output is enabled. Fixes: c5996e4ab109 ("drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250421102156.424480-1-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Simpify clk get/enable by devm_clk_get_enabled apiAndy Yan
Make use of devm_clk_get_enabled() to replace devm_clk_get() and clk_prepare_enable(), which will make the cleanup of clk code simpler. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-9-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: switch i2c registration to devm functionsAndy Yan
Switch from i2c_add_adapter() to resource managed devm_i2c_add_adapter(), which will make the cleanup code more simpler. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-8-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Use sleep_range instead of udelayAndy Yan
usleep_range is preferred over udelay. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-7-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Move ddc/i2c configuration and HOTPLUG unmute to ↵Andy Yan
inno_hdmi_init_hw Putting these scattered initialization code together is helpful for the following migration to the DRM bridge driver mode. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-6-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Rename function inno_hdmi_reset to inno_hdmi_init_hwAndy Yan
This function not only configure hardware reset register, but also do some other configurations. Therefore, it is more appropriate to name it inno_hdmi_init_hw, which will also facilitate the addition of other functions to this function in the following patch. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-5-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Remove unnecessary parentheses to make checkpatch happyAndy Yan
Remove unnecessary parentheses to make checkpatch happy. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-4-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Refactor register macros to make checkpatch happyAndy Yan
1. Prefer using the BIT macro 2. Macro argument 'n' as '(n)' to avoid precedence issues 3. Add a blank line after enum declarations Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-3-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Merge register definition to c fileAndy Yan
Since this register definition is only use in one single c file, there is no need to put it in a separate header. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-2-andyshrk@163.com
2025-07-08drm/rockchip: dw_hdmi: Use dev_err_probe() to simplify codeYumeng Fang
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. Signed-off-by: Yumeng Fang <fang.yumeng@zte.com.cn> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250515203554564-j1jBXUXR6bdiN6zARicC@zte.com.cn
2025-07-08drm/rockchip: cdn-dp: Convert to drm bridgeChaoyi Chen
Convert it to drm bridge driver, it will be convenient for us to migrate the connector part to the display driver later. Considering that some code depend on the connector, the following changes have been made: - Only process edid in &drm_bridge_funcs.edid_read(), so no need to store additional edid info. - Now cdn_dp_get_sink_capability() only focused on reading DPCD_REV. - Update bpc info in cdn_dp_bridge_atomic_enable() instead of cdn_dp_encoder_mode_set(). Actually, the bpc data will be used in cdn_dp_bridge_atomic_enable(). - Switch to use DRM_BRIDGE_OP_DP_AUDIO helpers. This patch also convert to use devm_drm_bridge_alloc() API. Tested with RK3399 EVB IND board. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250529071334.441-1-kernel@airkyi.com
2025-07-08drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-portHeiko Stuebner
Each window of a vop2 is usable by a specific set of video ports, so while binding the vop2, we look through the list of available windows trying to find one designated as primary-plane and usable by that specific port. The code later wants to use drm_crtc_init_with_planes with that found primary plane, but nothing has checked so far if a primary plane was actually found. For whatever reason, the rk3576 vp2 does not have a usable primary window (if vp0 is also in use) which brought the issue to light and ended in a null-pointer dereference further down. As we expect a primary-plane to exist for a video-port, add a check at the end of the window-iteration and fail probing if none was found. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250610212748.1062375-1-heiko@sntech.de
2025-07-08drm/rockchip: lvds: Convert to drm bridgeChaoyi Chen
Convert it to drm bridge driver, it will be convenient for us to migrate the connector part to the display driver later. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> [on a not-upstream px30 board with lvds display] Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250526015834.102-1-kernel@airkyi.com
2025-07-08Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst
Pull in drm-intel-next for the updates to drm panic handling. Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-07-08Merge tag 'drm-msm-next-2025-07-05' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/msm into drm-next Updates for v6.17 CI: - uprev mesa and ci-templates - use shallow clone to speed up build jobs - remove sdm845/cheza jobs. These runners are no more (RIP dear chezas) - fix runner tag for i915 cml runners - uprev igt to pull in msm test fixes Core: - VM_BIND support! - single source of truth for UBWC configuration. Adds a global soc driver for UBWC config which is used from display and GPU. (And later vidc/camera/etc) - Decouple ties between GPU and KMS, adding a `separate_gpu_kms` modparam to allow the GPU and KMS to bind to separate DRM devices. This should better deal with more exotic SoC configurations where the number of GPUs is different from number of DPUs. The default behavior is to still come up as a single unified DRM device to avoid surprising userspace. DP: - major rework of the I/O accessors DPU: - use version checks instead of feature bits - SM8750 support - set min_prefill_lines for SC8180X DSI: - SM8750 support GPU: - speedbin support for X1-85 - X1-45 support MDSS: - SM8750 support Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Robin Clark <robin.clark@oss.qualcomm.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACSVV0217R+kpoWQJeuYGHf6q_4aFyEJuKa=dZZKOnLQzFwppg@mail.gmail.com
2025-07-08Merge tag 'drm-intel-next-2025-07-04' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull #2 for v6.17: Features and functionality: - Add drm_panic support for both i915 and xe drivers (Jocelyn Falempe) - Add initial flip queue implementation, disabled by default, for LNL and PTL (Ville) - Add support for Wildcat Lake (WCL) display, version 30.02 (Matt Roper, Matt Atwood, Dnyaneshwar) - Extend drm_panel and follower support to DDI eDP (Arun) Refactoring and cleanups: - Make all global state objects opaque (Jani) - Move display works to display specific unordered workqueue (Luca) - Add and use struct drm_device based pcode interface (Jani, Lucas) - Use clamp() instead of max()+min() combo (Ankit) - Simplify wait for power well disable (Jani) - Various stylistics cleanups and renames (Jani) Fixes: - Deal with loss of pipe DMC state (Ville) - Fix PTL HDCP2 stream status check (Suraj) - Add workaround for ADL-P DKL PHY DP and HDMI (Nemesa) - Fix skl_print_wm_changes() stack usage with KMSAN (Arnd Bergmann) - Fix PCON capability reads on non-branch devices (Chaitanya) - Fix which platforms have ultra joiner (Ankit) DRM core changes: - Add ttm_bo_kmap_try_from_panic() for xe drm_panic support (Jocelyn Falempe) - Add private pointer to struct drm_scanout buffer for xe/i915 drm_panic support (Jocelyn Falempe) Merges: - Backmerge drm-next for drm_panel and xe changes (Jani) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6d728bf6ef23681b00dfbc7da9aeae41042dee02@intel.com
2025-07-07drm/tegra: Use dma_buf from GEM object instanceThomas Zimmermann
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach an implementation detail of PRIME. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20250619113100.70292-3-tzimmermann@suse.de
2025-07-07drm/tegra: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20250619113100.70292-2-tzimmermann@suse.de
2025-07-07drm/vgem/vgem_drv convert to use faux_deviceGreg Kroah-Hartman
The vgem driver does not need to create a platform device, as there is no real platform resources associated it, it only did so because it was simple to do that in order to get a device to use for resource management of drm resources. Change the driver to use the faux device instead as this is NOT a real platform device. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/2025070114-iron-shiny-b92e@gregkh
generated by cgit (git 2.34.1) at 2025-09-11 05:36:46 +0000