- Oct 18, 2024
-
-
Thomas Zimmermann authoredAdd drm_client_lib.ko to contain DRM's built-in client. Move the existing client for fbdev emulation into the new module. Protect the new module behind CONFIG_DRM_CLIENT_LIB. The Kconfig rules separate the DRM drivers from the DRM clients. A driver can opt into the default clients, but the user configures each client individually. To do so, DRM drivers still select DRM_CLIENT_SELECTION. The option is now a tristate that further selects all dependencies of the enabled DRM clients. There's a menu option for each client. Enabling at least one client also selects DRM_CLIENT_SETUP, so that drivers call drm_client_setup(). New DRM clients should depend on DRM_CLIENT_SELECTION. There are existing kernel options in drm_fb_helper.o, so leave this file in the KMS-helper module for now. v5: - leave fbdev helpers in drm_kms_helper.ko for now v3: - fix commit changelog v2: - keep client code in core - protect lib with DRM_CLIENT_LIB - remove duplicate line from Makefile (Jocelyn) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014085740.582287-13-tzimmermann@suse.de
-
Thomas Zimmermann authored
Only build client code if DRM_CLIENT has been selected. Automatially do so if one of the default clients has been enabled. If client support has been disabled, the helpers for client-related events are empty and the regular client functions are not present. Amdgpu has an internal DRM client, so it has to select DRM_CLIENT by itself unconditionally. v3: - provide empty drm_client_debugfs_init() if DRM_CLIENT=n (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
Replace calls to radeon_fbdev_set_suspend() with calls to the client functions drm_client_dev_suspend() and drm_client_dev_resume(). Any registered in-kernel client will now receive suspend and resume events. v4: - refer to radeon_fbdev_set_suspend() in commit description (Jonathan) Signed-off-by:
-
Thomas Zimmermann authored
Replace calls to drm_fb_helper_set_suspend_unlocked() with calls to the client functions drm_client_dev_suspend() and drm_client_dev_resume(). Any registered in-kernel client will now receive suspend and resume events. Signed-off-by:
-
Thomas Zimmermann authored
Replace calls to drm_fb_helper_set_suspend_unlocked() with calls to the client functions drm_client_dev_suspend() and drm_client_dev_resume(). Any registered in-kernel client will now receive suspend and resume events. Signed-off-by:
-
Thomas Zimmermann authored
Suspend and resume is still tied to fbdev emulation. Modeset helpers and several drivers call drm_fb_helper_set_suspend_unlocked() to inform the fbdev client about suspend/resume events. To make it work with arbitrary clients, add per-client callback functions for suspend and resume. Implement them for fbdev emulation with the existing drm_fb_helper_set_suspend_unlocked(). Then update DRM's modeset helpers to call the new interface. Clients that are not fbdev can now implement suspend/resume to their requirements. The callback parameter holds_console_lock is a workaround for i915, radeon and xe, which possibly call the interface while having the console lock acquired. Even though the commit doesn't modify these drivers, it already adds the flag to avoid churn later on. New code should not hold the console lock. v4: - clarify holds_console_lock in commit description (Jonathan) Signed-off-by:
-
Thomas Zimmermann authored
A number of DRM-client functions serve as entry points from device operations to client code. Moving them info a separate file will later allow for a more fine-grained kernel configuration. For most of the users it is sufficient to include <drm/drm_client_event.h> instead of the full driver-side interface in <drm/drm_client.h> v2: - rename new files to drm_client_event.{c,h} Signed-off-by: -
Thomas Zimmermann authored
Fbdev emulation for SHMEM and TTM requires helpers from the fbdev subsystem. Select them from the modules that use them instead of the core DRM module. Signed-off-by:
-
Thomas Zimmermann authored
Commit 808a40b6 ("drm/fbdev-dma: Implement damage handling and deferred I/O") added deferred I/O for fbdev-dma. Also select the Kconfig symbol FB_DEFERRED_IO (via FB_DMAMEM_HELPERS_DEFERRED). Fixes build errors about missing fbdefio, such as drivers/gpu/drm/drm_fbdev_dma.c:218:26: error: 'struct drm_fb_helper' has no member named 'fbdefio' 218 | fb_helper->fbdefio.delay = HZ / 20; | ^~ drivers/gpu/drm/drm_fbdev_dma.c:219:26: error: 'struct drm_fb_helper' has no member named 'fbdefio' 219 | fb_helper->fbdefio.deferred_io = drm_fb_helper_deferred_io; | ^~ drivers/gpu/drm/drm_fbdev_dma.c:221:21: error: 'struct fb_info' has no member named 'fbdefio' 221 | info->fbdefio = &fb_helper->fbdefio; | ^~ drivers/gpu/drm/drm_fbdev_dma.c:221:43: error: 'struct drm_fb_helper' has no member named 'fbdefio' 221 | info->fbdefio = &fb_helper->fbdefio; | ^~ Signed-off-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410050241.Mox9QRjP-lkp@intel.com/ Fixes: 808a40b6 ("drm/fbdev-dma: Implement damage handling and deferred I/O") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> # v6.11+ Reviewed-by:
-
Thomas Zimmermann authored
The Kconfig token DRM_CLIENT_SELECTION will make DRM clients available to drivers. Select it from xe. Signed-off-by:
-
Thomas Zimmermann authored
The Kconfig token DRM_CLIENT_SELECTION will make DRM clients available to drivers. Select it from i915. Signed-off-by:
-
- Oct 17, 2024
-
-
The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block. Add just the basic support for now, i.e. RGB output up to 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features. Co-developed-by:
Algea Cao <algea.cao@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016-b4-rk3588-bridge-upstream-v10-3-87ef92a6d14e@collabora.com Signed-off-by:
-
Rockchip RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller IP. Since this is a new IP block, quite different from those used in the previous generations of Rockchip SoCs, add a dedicated binding file. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX Controller IP supports the following features, among others: * Fixed Rate Link (FRL) * Display Stream Compression (DSC) * 4K@120Hz and 8K@60Hz video modes * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka Cinema VRR * Fast Vactive (FVA), aka Quick Frame Transport (QFT) * SCDC I2C DDC access * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds * Multi-stream audio * Enhanced Audio Return Channel (EARC) Add library containing common helpers to enable basic support, i.e. RGB output up to 4K@30Hz, without audio, CEC or any HDMI 2.1 specific features. Co-developed-by:
-
Having removed one re-lock cycle on the entity->lock in a patch titled "drm/sched: Optimise drm_sched_entity_push_job", with only a tiny bit larger refactoring we can do the same optimisation on the rq->lock. (Currently both drm_sched_rq_add_entity() and drm_sched_rq_update_fifo_locked() take and release the same lock.) To achieve this we make drm_sched_rq_update_fifo_locked() and drm_sched_rq_add_entity() expect the rq->lock to be held. We also align drm_sched_rq_update_fifo_locked(), drm_sched_rq_add_entity() and drm_sched_rq_remove_fifo_locked() function signatures, by adding rq as a parameter to the latter. v2: * Fix after rebase of the series. * Avoid naming inconsistency between drm_sched_rq_add/remove. (Christian) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <pstanner@redhat.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Philipp Stanner <pstanner@redhat.com> Signed-off-by:
-
When writing to a drm_sched_entity's run-queue, writers are protected through the lock drm_sched_entity.rq_lock. This naming, however, frequently collides with the separate internal lock of struct drm_sched_rq, resulting in uses like this: spin_lock(&entity->rq_lock); spin_lock(&entity->rq->lock); Rename drm_sched_entity.rq_lock to improve readability. While at it, re-order that struct's members to make it more obvious what the lock protects. v2: * Rename some rq_lock straddlers in kerneldoc, improve commit text. (Philipp) Signed-off-by:
-
Current kerneldoc for struct drm_sched_rq incompletely documents what fields are protected by the lock. This is not good because it is misleading. Lets fix it by listing all the elements which are protected by the lock. While at it, lets also re-order the members so all protected by the lock are in a single group. v2: * Refer variables by kerneldoc syntax, more verbose commit text. (Philipp) Signed-off-by:
-
It does not seem there is a need to set the current entity in FIFO mode since ot only serves as being a "cursor" in round-robin mode. Even if scheduling mode is changed at runtime the change in behaviour is simply to restart from the first entity, instead of continuing in RR mode from where FIFO left it, and that sounds completely fine. Signed-off-by:
-
In FIFO mode (which is the default), both drm_sched_entity_push_job() and drm_sched_rq_update_fifo(), where the latter calls the former, are currently taking and releasing the same entity->rq_lock. We can avoid that design inelegance, and also have a miniscule efficiency improvement on the submit from idle path, by introducing a new drm_sched_rq_update_fifo_locked() helper and pulling up the lock taking to its callers. v2: * Remove drm_sched_rq_update_fifo() altogether. (Christian) v3: * Improved commit message. (Philipp) Signed-off-by:
-
- Oct 16, 2024
-
-
The new driver needs the dsc helper code to be available: x86_64-linux-ld: vmlinux.o: in function `s6e3ha8_amb577px01_wqhd_prepare': panel-samsung-s6e3ha8.c:(.text+0x16b1e65): undefined reference to `drm_dsc_pps_payload_pack' Select it from Kconfig as we do for other similar drivers. Fixes: 779679d3 ("drm/panel: Add support for S6E3HA8 panel driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20241015153442.3757061-1-arnd@kernel.org Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241015153442.3757061-1-arnd@kernel.org
-
Add the driver for Samsung AMS581VF01 SOFEF01-based 5.81" FHD Plus CMD mode OLED panel support found in Google Pixel 4a (sm7150-google-sunfish) Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241013212402.15624-3-danila@jiaxyga.com Signed-off-by:
-
The Samsung AMS581VF01 is a 5.81 inch 1080x2340 MIPI-DSI CMD mode OLED panel used in Google Pixel 4a (sm7150-google-sunfish) Add a dt-binding for it. Signed-off-by:
-
- Oct 14, 2024
-
-
Use atomic64_inc_return(&ref) instead of atomic64_add_return(1, &ref) to use optimized implementation and ease register pressure around the primitive for targets that implement optimized variant. Signed-off-by:
Uros Bizjak <ubizjak@gmail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241007083921.47525-1-ubizjak@gmail.com
-
Use of kmap_atomic/kunmap_atomic is deprecated, use kmap_local_page/kunmap_local instead. This is reported by checkpatch. Also fix repeated word issue. WARNING: Deprecated use of 'kmap_atomic', prefer 'kmap_local_page' instead + void *vaddr = kmap_atomic(page); WARNING: Deprecated use of 'kunmap_atomic', prefer 'kunmap_local' instead + kunmap_atomic(vaddr); WARNING: Possible repeated word: 'by' + * has been killed by by SIGKILL total: 0 errors, 3 warnings, 405 lines checked Signed-off-by:
Pintu Kumar <quic_pintu@quicinc.com> Reviewed-by:
T.J. Mercier <tjmercier@google.com> Signed-off-by:
-
These warnings/errors are reported by checkpatch. Fix them with minor changes to make it clean. No other functional changes. WARNING: Block comments use * on subsequent lines + /* only support discovering the end of the buffer, + but also allow SEEK_SET to maintain the idiomatic WARNING: Block comments use a trailing */ on a separate line + SEEK_END(0), SEEK_CUR(0) pattern */ WARNING: Block comments use a trailing */ on a separate line + * before passing the sgt back to the exporter. */ ERROR: "foo * bar" should be "foo *bar" +static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. + d = debugfs_create_file("bufinfo", S_IRUGO, dma_buf_debugfs_dir, total: 1 errors, 4 warnings, 1746 lines checked Signed-off-by:John Stultz <jstultz@google.com> Signed-off-by:
-
Thomas Zimmermann authored
The DRM aperture helpers are wrappers around video helpers from <linux/aperture.h>. There are no callers of these functions. Remove them entirely. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930130921.689876-29-tzimmermann@suse.de
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
Thomas Zimmermann authored
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by:
-
