- 23 Mar, 2023 1 commit
-
-
AngeloGioacchino Del Regno authored
In preparation for adding new bindings for new MediaTek SoCs, split out the power-domains variation from the `else` in the current mediatek,mt8183-mali conditional. The sram-supply part is left in place to be disallowed for anything that is not compatible with "mediatek,mt8183-mali" as this regulator is MediaTek-specific and it is, and will ever be, used only for this specific string due to the addition of the mediatek-regulator-coupler driver. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316102041.210269-2-angelogioacchino.delregno@collabora.com
-
- 22 Mar, 2023 14 commits
-
-
Alfredo Cruz authored
devm_regmap_init_mmio() may return an invalid pointer in case of an error. This patch adds the corresponding IS_ERR check to vop2->map. Signed-off-by:
Alfredo Cruz <alfredo.carlon@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230322224411.15612-1-alfredo.carlon@gmail.com
-
Toby Chen authored
This fixes a use-after-free crash during rmmod. The DRM encoder is embedded inside the larger rockchip_hdmi, which is allocated with the component. The component memory gets freed before the main drm device is destroyed. Fix it by running encoder cleanup before tearing down its container. Signed-off-by:
Toby Chen <tobyc@nvidia.com> [moved encoder cleanup above clk_disable, similar to bind-error-path] Signed-off-by:
-
Tom Rix authored
clang reportes this error drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error: variable 'possible_crtcs' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (vp) { ^~ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2336:36: note: uninitialized use occurs here ret = vop2_plane_init(vop2, win, possible_crtcs); ^~~~~~~~~~~~~~ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:4: note: remove the 'if' if its condition is always true if (vp) { ^~~~~~~~ The else-statement changes the win->type to OVERLAY without setting the possible_crtcs variable. Rework the block, initialize possible_crtcs to 0 to remove the else-statement. Split the else-if-statement out to its own if-statement so the OVERLAY check will catch when the win-type has been changed. Fixes: 368419a2 ("drm/rockchip: vop2: initialize possible_crtcs properly") Signed-off-by:Tom Rix <trix@redhat.com> Acked-by:
Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by:
-
Thomas Zimmermann authored
Rename symbols to match the style of other fbdev-emulation source code. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Zack Rusin <zackr@vmware.com> Tested-by:
Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
Consolidate all handling of CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM by making the module parameter optional in drm_fb_helper.c. Without the config option, modules can set smem_start in struct fb_info for internal usage, but not export if to userspace. The address can only be exported by enabling the option and setting the module parameter. Also update the comment. Signed-off-by:
-
Thomas Zimmermann authored
Clean up fbdev and client state if the probe function fails. It used to leak allocated resources. Also reorder the individual steps to simplify cleanup. v2: * move screen_size update into separate patches Signed-off-by:
-
Thomas Zimmermann authored
The size of the screen memory should be equivalent to the size of the screen's GEM buffer. Don't recalculate the value. Signed-off-by:
-
Thomas Zimmermann authored
The size of the framebuffer can either be stored in screen_info or smem_len. Take both into account in the deferred I/O code. Signed-off-by:
-
Thomas Zimmermann authored
Export the fb_info release code as drm_fb_helper_release_info(). Will help with cleaning up failed fbdev probing. Signed-off-by:
-
Thomas Zimmermann authored
Remove the flag prefer_shadow_fbdev from struct drm_mode_config. Drivers set this flag to enable shadow buffering in the generic fbdev emulation. Such shadow buffering is now mandatory, so the flag is unused. Signed-off-by:
-
Thomas Zimmermann authored
Remove all codepaths that implement fbdev output directly on GEM buffers. Always allocate a shadow buffer in system memory and set up deferred I/O for mmap. The fbdev code that operated directly on GEM buffers was used by drivers based on GEM DMA helpers. Those drivers have been migrated to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All remaining users of fbdev-generic require shadow buffering. Memory management of the remaining callers uses TTM, GEM SHMEM helpers or a variant of GEM DMA helpers that is incompatible with fbdev-dma. Therefore remove the unused codepaths from fbdev-generic and simplify the code. Using a shadow buffer with deferred I/O is probably the best case for most remaining callers. Some of the TTM-based drivers might benefit from a dedicated fbdev emulation that operates directly on the driver's video memory. Signed-off-by:
-
Ye Xingchen authored
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by:
Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/202303221622511915615@zte.com.cn
-
Ye Xingchen authored
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by:
-
Christian König authored
Not used by any drivers any more, the only use case in drm_dev_init() can be inlined now. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316082035.567520-2-christian.koenig@amd.com
-
- 21 Mar, 2023 2 commits
-
-
Maíra Canal authored
As lima_gem_add_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in Lima in order to simply use the DRM function. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Qiang Yu <yuq825@gmail.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230224214133.411966-1-mcanal@igalia.com
-
Tom Rix authored
clang with W=1 reports drivers/gpu/drm/gma500/psb_irq.c:35:19: error: unused function 'gma_pipe_event' [-Werror,-Wunused-function] static inline u32 gma_pipe_event(int pipe) ^ This function is not used, so remove it. Signed-off-by:Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230319142320.1704336-1-trix@redhat.com
-
- 20 Mar, 2023 23 commits
-
-
Maíra Canal authored
Commit 45d9c8dd ("drm/vgem: use shmem helpers") introduced shmem helpers to vgem and with that, removed all uses of the struct drm_vgem_gem_object. So, as the struct is no longer used, delete it. Signed-off-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Petr Tesarik authored
The DRM device passed to drm_gem_prime_fd_to_handle() is where the dma-buf is being imported, not the device where it was exported. Also fix a trivial typo in drm_gem_prime_import_dev(). Signed-off-by:
Petr Tesarik <petr.tesarik.ext@huawei.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Thomas Zimmermann authored
Instead of the DRM framebuffer, pass the FB info strcuture to the fbdev page-fault handler psb_fbdev_vm_fault(). The framebuffer is a high-level data structure and does not belong into fault handling. The fb_info has all necessary information. Also set fix.smem_start to the correct value (the beginning of the framebuffer in physical address space) and streamline the page-fault handler. v2: * remove unused struct drm_psb_private.fb_base (Patrik) Signed-off-by:
-
Thomas Zimmermann authored
Implement fbdevemulation on top of struct drm_client and its helpers. This ad-hoc interfaces for restoring and closing fbdev emulation with per-client callback for hotplugging, restoring and unregistering. A single function, psb_fbdev_setup(), starts fbdev emulation after the DRM device has been registered. Hence, fbdev acts like a regular DRM client. The setup call only prepares the fbdev emulation. It then implements connector hotplugging. The first successful hotplug event initializes fbdev emulation. Unregistering depends on the hotplugging. Fully initialized emulation is cleaned up through drm_fb_helper_unregister_info() and fb_destroy. For prepared-only setups, unregistering unprepares the emulation and releases all resources. In both cases, fbdev emulation will be cleaned up. v2: * declare empty setup function as 'static inline' (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
Inline psbfb_create() into its only caller psbfb_probe(). Streamline the color-depth selection. Also clean up the naming around struct drm_fb_helper_funcs. v2: * rename psbfb_probe() (Patrik) Signed-off-by:
-
Thomas Zimmermann authored
Fix some names around struct fb_ops to better fit the overall naming conventions. No functional changes. v2: * fix typo in commit message Signed-off-by:
-
