- 22 Mar, 2023 2 commits
-
-
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/202303221621336645576@zte.com.cn
-
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:Tom Rix <trix@redhat.com> 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 28 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 <tzimmermann@suse.de> Acked-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:
-
Thomas Zimmermann authored
Remove fbdev emulations' open and close implementaitons for the VM. The functions are empty. Also update the naming of the VMA code. Signed-off-by:
-
Thomas Zimmermann authored
Move the fbdev emulation from framebuffer.c to fbdev.c. Only build the source code if the Kconfig symbol has been selected. Remaining in framebuffer.c is gma500's code for DRM framebuffers. No functional changes. v2: * remove 'extern' from function declaration (Patrik) * declare empty init/fini functions as 'static inline' (kernel test robot) * rebase onto vm_flags_set() * typo fixes in commit message Signed-off-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements from framebuffer.c. No functional changes. Signed-off-by:
-
Adam Ford authored
When dynamically switching lanes was removed, the intent of the code was to check to make sure that higher speed items used 4 lanes, but it had the unintended consequence of removing the slower speeds for 4-lane users. This attempts to remedy this by doing a check to see that the max frequency doesn't exceed the chip limit, and a second check to make sure that the max bit-rate doesn't exceed the number of lanes * max bit rate / lane. Fixes: 9a0cdcd6 ("drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge") Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
-
Tom Rix authored
clang with W=1 reports drivers/gpu/drm/bridge/sii9234.c:870:31: error: unused function 'bridge_to_sii9234' [-Werror,-Wunused-function] static inline struct sii9234 *bridge_to_sii9234(struct drm_bridge *bridge) ^ This static function is not used, so remove it. Signed-off-by:
-
- 18 Mar, 2023 1 commit
-
-
Simon Ser authored
This was pointed out by Ville and Pekka in their replies, but forgot to apply the change properly before pushing. Sorry for the noise! Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230305103503.42619-1-contact@emersion.fr
-
- 17 Mar, 2023 4 commits
-
-
Javier Martinez Canillas authored
There's a nice macro to calculate the destination pitch that already takes into account sub-byte pixel formats. Use that instead of open coding it. Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Yang Li authored
According to commit 7945f929 ("drivers: provide devm_platform_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to Use devm_platform_ioremap_resource(), as this is exactly what this function does. Since 'struct platform_device *pdev = to_platform_device(drm->dev)', 'drm->dev' is equivalent to 'pdev->deva'. Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Yang Li authored
According to commit 890cc39a ("drivers: provide devm_platform_get_and_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Since 'struct platform_device *pdev = to_platform_device(dev)', 'pdev->dev' is equivalent to 'dev'. Signed-off-by:
-
Lee Jones authored
'bulk' description taken from another in the same file. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/ttm/ttm_bo.c:98: warning: Function parameter or member 'bulk' not described in 'ttm_bo_set_bulk_move' drivers/gpu/drm/ttm/ttm_bo.c:768: warning: Function parameter or member 'placement' not described in 'ttm_bo_mem_space' drivers/gpu/drm/ttm/ttm_bo.c:768: warning: Excess function parameter 'proposed_placement' description in 'ttm_bo_mem_space' Signed-off-by:
Lee Jones <lee@kernel.org> Reviewed-by:
-
- 16 Mar, 2023 3 commits
-
-
Arthur Grillo authored
This test case uses an arbitrary pitch size, different of the default one, to test if the conversions methods obey. Change the "destination_pitch" colors to change the monochrome expected result from being just zeros, as this makes the arbitrary pitch use unusable. Signed-off-by:
Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by:
-
Arthur Grillo authored
Extend the existing test cases to test the conversion from XRGB8888 to monochromatic. Signed-off-by:
-
Tom Rix authored
gcc with W=1 reports drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: error: no previous prototype for ‘wpr_generic_header_dump’ [-Werror=missing-prototypes] 49 | wpr_generic_header_dump(struct nvkm_subdev *subdev, | ^~~~~~~~~~~~~~~~~~~~~~~ wpr_generic_header_dump is only used in acr.c, so it should be static Signed-off-by:Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
