- 12 Dec, 2023 4 commits
-
-
Paul Cercueil authored
When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not exist yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was used as the connector type. However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as the connector type. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). 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> fix merge conflict and drop duplicated patch description. Signed-off-by:
-
Douglas Anderson authored
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about this fix: - When adding drm_atomic_helper_shutdown() to the unbind path, I added it after drm_kms_helper_poll_fini() since that's when other drivers seemed to have it. - Technically with a previous patch, ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"), we don't actually need to check to see if our "drm" pointer is NULL before calling drm_atomic_helper_shutdown(). We'll leave the "if" test in, though, so that this patch can land without any dependencies. It could potentially be removed later. - This patch also makes sure to set the drvdata to NULL in the case of bind errors to make sure that shutdown can't access freed data. Suggested-by:Maxime Ripard <mripard@kernel.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Inki Dae authored
Merge tag 'exynos-drm-next-for-v6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next Two fixups - Fix a potential error pointer dereference by checking the return value of exynos_drm_crtc_get_by_type() function before accessing to crtc object. - Fix a wrong error checking in exynos_drm_dma.c modules, which was reported by Dan[1] [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
-
- 08 Dec, 2023 2 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 6.8: UAPI Changes: - Remove Userspace Mode-Setting ioctls - v3d: New uapi to handle jobs involving the CPU Cross-subsystem Changes: Core Changes: - atomic: Add support for FB-less planes which got reverted a bit later for lack of IGT tests and userspace code, Dump private objects state in drm_state_dump. - dma-buf: Add fence deadline support - encoder: Create per-encoder debugfs directory, move the bridge chain file to that directory Driver Changes: - Include drm_auth.h in driver that use it but don't include it, Drop drm_plane_helper.h from drivers that include it but don't use it - imagination: Plenty of small fixes - panfrost: Improve interrupt handling at poweroff - qaic: Convert to persistent DRM devices - tidss: Support for the AM62A7, a few probe improvements, some cleanups - v3d: Support for jobs involving the CPU - bridge: - Create transparent aux-bridge for DP/USB-C - lt8912b: Add suspend/resume support and power regulator support - panel: - himax-hx8394: Drop prepare, unprepare and shutdown logic, Support panel rotation - New panels: BOE BP101WX1-100, Powkiddy X55, Ampire AM8001280G, Evervision VGG644804, SDC ATNA45AF01 Signed-off-by:Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/yu5heqaufyeo4nlowzieu4s5unwqrqyx4jixbfjmzdon677rpk@t53vceua2dao
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
- Improve display debug msgs and other general clean-ups (Ville, Rahuul) - PSR fixes and improvements around selective fetch (Jouni, Ville) - Remove FBC restrictions for Xe2LPD displays (Vinod) - Skip some timing checks on BXT/GLK DSI transcoders (Ville) - DP MST Fixes (Ville) - Correct the input parameter on _intel_dsb_commit (heminhong) - Fix IP version of the display WAs (Bala) - DGFX uses direct VBT pin mapping (Clint) - Proper handling of bool on PIPE_CONF_CHECK macros (Jani) - Skip state verification with TBT-ALT mod (Mika Kahona) - General organization of display code for reusage with Xe (Jouni, Luca, Jani, Maarten) - Squelch a sparse warning (Jani) - Don't use "proxy" headers (Andy Shevchenko) - Use devm_gpiod_get() for all GPIOs (Hans) - Fix ADL+ tiled plane stride (Ville) - Use octal permissions in display debugfs (Jani) Signed-off-by:
-
- 07 Dec, 2023 14 commits
-
-
Jouni Högander authored
Xe needs intel_fb_bo_framebuffer_fini for taking care of unpinning the fb and taking reference. In i915 this can be empty. Also move intel_frontbuffer_get to be done after intel_fb_bo_framebuffer_init to have reasonable sequences: intel_fb_bo_framebuffer_init intel_frontbuffer_get ... intel_frontbuffer_put intel_fb_bo_framebuffer_fini v2: Empty function instead of define Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231207083451.2184562-1-jouni.hogander@intel.com
-
Maarten Lankhorst authored
Works better for xe like that. obj is no longer const. Signed-off-by:
-
Jani Nikula authored
Octal permissions are preferred over the symbolics ones. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205134143.2427661-3-jani.nikula@intel.com
-
Jani Nikula authored
Prefer struct intel_connector over struct drm_connector, and unify the declarations in the fops. Signed-off-by:
-
Jani Nikula authored
Prefer struct intel_connector over struct drm_connector. Signed-off-by:
-
Jani Nikula authored
Reduce the duplication. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205121545.2338665-1-jani.nikula@intel.com
-
Luca Coelho authored
The uncore code may not always be available (e.g. when we build the display code with Xe), so we can't always rely on having the uncore's spinlock. To handle this, split the spin_lock/unlock_irqsave/restore() into spin_lock/unlock() followed by a call to local_irq_save/restore() and create wrapper functions for locking and unlocking the uncore's spinlock. In these functions, we have a condition check and only actually try to lock/unlock the spinlock when I915 is defined, and thus uncore is available. This keeps the ifdefs contained in these new functions and all such logic inside the display code. Cc: Tvrtko Ursulin <tvrto.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
Tomi Valkeinen authored
It's been reported that DSI host driver's detach can be called without the attach ever happening: https://lore.kernel.org/all/20230412073954.20601-1-tony@atomide.com/ After reading the code, I think this is what happens: We have a DSI host defined in the device tree and a DSI peripheral under that host (i.e. an i2c device using the DSI as data bus doesn't exhibit this behavior). The host driver calls mipi_dsi_host_register(), which causes (via a few functions) mipi_dsi_device_add() to be called for the DSI peripheral. So now we have a DSI device under the host, but attach hasn't been called. Normally the probing of the devices continues, and eventually the DSI peripheral's driver will call mipi_dsi_attach(), attaching the peripheral. However, if the host driver's probe encounters an error after calling mipi_dsi_host_register(), and before the peripheral has called mipi_dsi_attach(), the host driver will do cleanups and return an error from its probe function. The cleanups include calling mipi_dsi_host_unregister(). mipi_dsi_host_unregister() will call two functions for all its DSI peripheral devices: mipi_dsi_detach() and mipi_dsi_device_unregister(). The latter makes sense, as the device exists, but the former may be wrong as attach has not necessarily been done. To fix this, track the attached state of the peripheral, and only detach from mipi_dsi_host_unregister() if the peripheral was attached. Note that I have only tested this with a board with an i2c DSI peripheral, not with a "pure" DSI peripheral. However, slightly related, the unregister machinery still seems broken. E.g. if the DSI host driver is unbound, it'll detach and unregister the DSI peripherals. After that, when the DSI peripheral driver unbound it'll call detach either directly or using the devm variant, leading to a crash. And probably the driver will crash if it happens, for some reason, to try to send a message via the DSI bus. But that's another topic. Tested-by:
H. Nikolaus Schaller <hns@goldelico.com> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921-dsi-detach-fix-v1-1-d0de2d1621d9@ideasonboard.com
-
Tomi Valkeinen authored
If the hpd_pin is invalid, the driver returns 'ret'. But 'ret' contains 0, instead of an error value. Return -EINVAL instead. Fixes: f25ee501 ("drm/bridge: tc358767: add IRQ and HPD support") Acked-by:
-
Tomi Valkeinen authored
'ret' could be uninitialized at the end of the function, although it's not clear if that can happen in practice. Fixes: 6a3608ea ("drm: bridge: cdns-mhdp8546: Enable HDCP") Acked-by:
-
Tomi Valkeinen authored
smatch reports: drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: uninitialized symbol 'ret'. 'ret' is possibly not set when there are no errors, causing the error above. I can't say if that ever happens in real-life, but in any case I think it is good to initialize 'ret' to 0. Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
-
Tomi Valkeinen authored
smatch reports: drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized symbol 'supported_status'. 'supported_status' is only set in one code path. I'm not familiar with the code to say if that path will always be ran in real life, but whether that is the case or not, I think it is good to initialize 'supported_status' to 0 to silence the warning (and possibly fix a bug). Reviewed-by:
-
Inki Dae authored
Fix a wrong error checking in exynos_drm_dma.c module. In the exynos_drm_register_dma function, both arm_iommu_create_mapping() and iommu_get_domain_for_dev() functions are expected to return NULL as an error. However, the error checking is performed using the statement if(IS_ERR(mapping)), which doesn't provide a suitable error value. So check if 'mapping' is NULL, and if it is, return -ENODEV. This issue[1] was reported by Dan. Changelog v1: - fix build warning. [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/ Reported-by : Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Xiang Yang authored
Smatch reports the warning below: drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind() error: 'crtc' dereferencing possible ERR_PTR() The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV), which can not be used directly. Fix this by checking the return value before using it. Signed-off-by:
Xiang Yang <xiangyang3@huawei.com> Signed-off-by:
-
- 06 Dec, 2023 20 commits
-
-
Dan Carpenter authored
The i2c_master_send/recv() functions return negative error codes or they return "len" on success. So the error handling here can be written as just normal checks for "if (ret < 0) return ret;". No need to complicate things. Btw, in this code the "len" parameter can never be zero, but even if it were, then I feel like this would still be the best way to write it. Fixes: 91443799 ("drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking") Suggested-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
This function is only used when debugfs is enabled, and otherwise causes a build warning: drivers/gpu/drm/imagination/pvr_fw_trace.c:135:1: error: 'update_logtype' defined but not used [-Werror=unused-function] Move the #ifdef check to include this function as well. Fixes: cb56cd61 ("drm/imagination: Add firmware trace to debugfs") Acked-by:
Frank Binns <frank.binns@imgtec.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231204073231.1164163-1-arnd@kernel.orgSigned-off-by:
-
Donald Robson authored
Fixing the warning below due to an unused file level vtable. Removing only this causes additional warnings for the now unused functions, so I've removed those too. >> drivers/gpu/drm/imagination/pvr_fw_trace.c:205:37: warning: 'pvr_fw_trace_group_mask_fops' defined but not used [-Wunused-const-variable=] 205 | static const struct file_operations pvr_fw_trace_group_mask_fops = { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Changes since v1: - Corrected hash in Fixes tag. Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311302054.MVYPxFCE-lkp@intel.com/ Fixes: cb56cd61 ("drm/imagination: Add firmware trace to debugfs") Signed-off-by:
Donald Robson <donald.robson@imgtec.com> Signed-off-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204090852.1650-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204090852.1650-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
The udl driver is the only caller of drm_plane_helper_atomic_check(). Move the function into the driver. No functional changes. v2: * fix documenation (Sui) Signed-off-by:
-
Thomas Zimmermann authored
Remove CONFIG_DRM_LEGACY from Kconfig. Nothing depends on the option. Signed-off-by:
David Airlie <airlied@gmail.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Acked-by:
-
Thomas Zimmermann authored
The AGP subsystem supports a user-space interface via /dev/agpgart. It is only enabled with DRM support for mode setting in user space. (i.e., CONFIG_DRM_LEGACY). All of that DRM code has been removed and the option will go away. Hence remove the AGP frontend. Modern DRM drivers with kernel mode setting handle AGP support internally. Signed-off-by:
-
Thomas Zimmermann authored
Remove all remaining source code for non-KMS drivers. These drivers have been removed in v6.3 and won't comeback. Signed-off-by:
-
Thomas Zimmermann authored
Modern DRM drivers acquire ioctl locks by themselves. Legacy ioctls for user-space mode setting used to acquire drm_global_mutex. After removing the ioctl entry points, also remove the locking code. The only legacy ioctl without global locking was VBLANK_WAIT, which has been removed as well. Hence remove the related DRM_UNLOCKED flag. Signed-off-by:
-
Thomas Zimmermann authored
Remove all hooks and calls into code for user-space mode setting from the DRM core. Without the drivers and ioctl entry points, none of this is required any longer. Signed-off-by:
-
Thomas Zimmermann authored
DRM drivers with user-space mode setting have been removed in Linux v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking any of the ioctl ops will unconditionally return -EINVAL to user space. Invoking DRM_IOCTL_MODESET_CTL is different from the other legacy ioctl ops as it returns 0 even without CONFIG_DRM_LEGACY set. From the original commit 29935554 ("drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers") it is not apparent how or why the operation differs from the others. It is likely just an oversight in commit 61ae2270 ("drm: allow removal of legacy codepaths (v4.1)"), which allowed disabling leagacy ioctls in the first place. Still keep this removal separate from the other ioctls to allow an easy revert, if necessary. Signed-off-by:
-
Thomas Zimmermann authored
DRM drivers with user-space mode setting have been removed in Linux v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking any of the ioctl ops will unconditionally return -EINVAL to user space. This has already been the behavior for kernels without CONFIG_DRM_LEGACY set. Signed-off-by:
-
Thomas Zimmermann authored
Including <drm/drm_legacy.h> is not required by radeon. Signed-off-by:
-
Thomas Zimmermann authored
Include <drm/drm_device.h> in drm_ioc32.c. Resolves a depenency on <drm/drm_legacy.h>, which will be removed. Signed-off-by:
-
