- 07 Dec, 2023 11 commits
-
-
Rodrigo Vivi authored
Current drm-xe-next doesn't have any drm/scheduler patch that is not already accepted in drm-misc-next. This completed this goal with the consensus of how the drm/scheduler fits to the fw scheduling and the relationship between drm_gpu_scheduler and drm_sched_entity. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-3-rodrigo.vivi@intel.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Matthew Brost authored
No DRM scheduler changes required, drivers just return NULL in run_job vfunc. The rough consensus is that no helper or extra scaffolding is needed around long-running jobs and no further changes to drm-scheduler. At least for now. Other drivers that currently do long-running workloads have no plat to use drm-scheduler. Besides, the current consensus is that this solution of simply returning NULL to the run_job function should work without extra code duplication or complication. On top of that, this item was already a non-blocking one for upstreaming Xe, so let's move that to the 'Completed' section and revisit the long-running solution as a community after Xe is integrated in DRM. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Marek Szyprowski authored
encoder->funcs entry might be NULL, so check it first before calling its methods. This fixes NULL pointer dereference observed on Rasberry Pi 3b/4b boards. Fixes: caf525ed ("drm/encoder: register per-encoder debugfs dir") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Nishanth Menon <nm@ti.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Nathan Chancellor authored
sparse complains: drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c: note: in included file: include/drm/bridge/aux-bridge.h:29:16: sparse: sparse: Using plain integer as NULL pointer Return NULL to clear up the warning. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312060025.BdeqZrWx-lkp@intel.com/ Fixes: e560518a ("drm/bridge: implement generic DP HPD bridge") Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Nathan Chancellor authored
CONFIG_DRM_AUX_HPD_BRIDGE depends on CONFIG_OF but that dependency is not included when CONFIG_TYPEC_QCOM_PMIC selects it, resulting in a Kconfig warning when CONFIG_OF is disabled: WARNING: unmet direct dependencies detected for DRM_AUX_HPD_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n] Selected by [m]: - TYPEC_QCOM_PMIC [=m] && USB_SUPPORT [=y] && TYPEC [=m] && TYPEC_TCPM [=m] && (ARCH_QCOM || COMPILE_TEST [=y]) && (DRM [=m] || DRM [=m]=n) && DRM_BRIDGE [=y] Only select CONFIG_DRM_AUX_HPD_BRIDGE with both CONFIG_DRM_BRIDGE and CONFIG_OF to clear up the warning. Fixes: 7d9f1b72 ("usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE") Signed-off-by:Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
-
Nathan Chancellor authored
CONFIG_DRM_AUX_BRIDGE depends on CONFIG_OF but that dependency is not included when CONFIG_TYPEC_MUX_NB7VPQ904M selects it, resulting in a Kconfig warning when CONFIG_OF is disabled: WARNING: unmet direct dependencies detected for DRM_AUX_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n] Selected by [y]: - TYPEC_MUX_NB7VPQ904M [=y] && USB_SUPPORT [=y] && TYPEC [=y] && I2C [=y] && (DRM [=y] || DRM [=y]=n) && DRM_BRIDGE [=y] Only select CONFIG_DRM_AUX_BRIDGE with both CONFIG_DRM_BRIDGE and CONFIG_OF to clear up the warning. Fixes: c5d296ba ("usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE") Signed-off-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:
Maxime Ripard <mripard@kernel.org> Reviewed-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:
-
- 06 Dec, 2023 24 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: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:
-
Thomas Zimmermann authored
One of the source files includes <drm/drm_auth.h> via <drm/drm_legacy.h>, which will be removed. Include drm_auth.h directly. Signed-off-by:
-
Thomas Zimmermann authored
One of the source files includes <drm/drm_auth.h> via <drm/drm_legacy.h>, which will be removed. Include drm_auth.h directly. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
One of the source files includes <drm/drm_auth.h> via <drm/drm_legacy.h>, which will be removed. Include drm_auth.h directly. Signed-off-by:
-
Thomas Zimmermann authored
Non-KMS drivers have been removed from DRM. Update the TODO list accordingly. Signed-off-by:
-
- 05 Dec, 2023 5 commits
-
-
Pin-yen Lin authored
Move the order of CMN 0x14e5 to make the list sorted. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231205123630.988663-3-treapking@chromium.org
-
Abel Vesa authored
Add support for the SDC ATNA45AF01 panel. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
The drm_atomic_print_new_state() already prints private object state via drm_atomic_private_obj_print_state(). Add private object state dumping to __drm_state_dump(), so that it is also included into drm_state_dump() output and into debugfs/dri/N/state file. Reviewed-by:
Rob Clark <robdclark@gmail.com> Acked-by:
-
Boris Brezillon authored
Some users need to release resources attached to the vm_bo object when it's destroyed. In Panthor's case, we need to release the pin ref so BO pages can be returned to the system when all GPU mappings are gone. This could be done through a custom drm_gpuvm::vm_bo_free() hook, but this has all sort of locking implications that would force us to expose a drm_gem_shmem_unpin_locked() helper, not to mention the fact that having a ::vm_bo_free() implementation without a ::vm_bo_alloc() one seems odd. So let's keep things simple, and extend drm_gpuvm_bo_put() to report when the object is destroyed. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204151406.1977285-1-boris.brezillon@collabora.com
-
AngeloGioacchino Del Regno authored
To make sure that we don't unintentionally perform any unclocked and/or unpowered R/W operation on GPU registers, before turning off clocks and regulators we must make sure that no GPU, JOB or MMU ISR execution is pending: doing that requires to add a mechanism to synchronize the interrupts on suspend. Add functions panfrost_{gpu,job,mmu}_suspend_irq() which will perform interrupts masking and ISR execution synchronization, and then call those in the panfrost_device_runtime_suspend() handler in the exact sequence of job (may require mmu!) -> mmu -> gpu. As a side note, JOB and MMU suspend_irq functions needed some special treatment: as their interrupt handlers will unmask interrupts, it was necessary to add an `is_suspended` bitmap which is used to address the possible corner case of unintentional IRQ unmasking because of ISR execution after a call to synchronize_irq(). At resume, clear each is_suspended bit in the reset path of JOB/MMU to allow unmasking the interrupts. Signed-off-by:AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
