- 20 Nov, 2022 2 commits
-
-
Thomas Zimmermann authored
This reverts commit 7f5cc4a3. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
This reverts commit 27c3e945. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by:
-
- 18 Nov, 2022 1 commit
-
-
Lukasz Wiecaszek authored
The reason behind that patch is associated with videobuf2 subsystem (or more genrally with v4l2 framework) and user created dma buffers (udmabuf). In some circumstances when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem wants to use dma_buf_vmap() method on the attached dma buffer. As udmabuf does not have .vmap operation implemented, such dma_buf_vmap() natually fails. videobuf2_common: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each videobuf2_common: __prepare_dmabuf: buffer for plane 0 changed videobuf2_common: __prepare_dmabuf: failed to map dmabuf for plane 0 videobuf2_common: __buf_prepare: buffer preparation failed: -14 The patch itself seems to be strighforward. It adds implementation of .vmap and .vunmap methods to 'struct dma_buf_ops udmabuf_ops'. .vmap method itself uses vm_map_ram() to map pages linearly into the kernel virtual address space. .vunmap removes mapping created earlier by .vmap. All locking and 'vmapping counting' is done in dma_buf.c so it seems to be redundant/unnecessary in .vmap/.vunmap. Signed-off-by:
Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221117171810.75637-1-lukasz.wiecaszek@gmail.comSigned-off-by:
-
- 17 Nov, 2022 3 commits
-
-
Thomas Zimmermann authored
Make fb_modesetting_disabled() a static-inline function when it is defined in the header file. Avoid the linker error shown below. ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled': fbmon.c:(.text+0x1e4): multiple definition of `fb_modesetting_disabled'; drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here A bug report is at [1]. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Fixes: 0ba2fa8c ("fbdev: Add support for the nomodeset kernel parameter") Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Helge Deller <deller@gmx.de> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/dri-devel/20221117183214.2473e745@canb.auug.org.au/T/#u # 1 Link: https://patchwork.freedesktop.org/patch/msgid/20221117114729.7570-1-tzimmermann@suse.de
-
Maxime Ripard authored
The SPDX header is missing, let's add it and fix the corresponding checkpatch warning. Suggested-by:
Maíra Canal <mairacanal@riseup.net> Fixes: 44a39283 ("drm/tests: Add Kunit Helpers") Reviewed-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Some extra blank lines slipped through, remove them. Fixes: 8fc0380f ("drm/client: Add some tests for drm_connector_pick_cmdline_mode()") Reviewed-by:
-
- 16 Nov, 2022 17 commits
-
-
Maxime Ripard authored
The MODULE_LICENSE macro is missing from the kunit helpers file, thus leading to a build error. Let's introduce it along with MODULE_AUTHOR. Fixes: 44a39283 ("drm/tests: Add Kunit Helpers") Reported-by:
-
Maxime Ripard authored
The kunit helpers code weren't including its header, leading to a warning that no previous prototype had been defined for public functions. Include the matching header to fix the warning. Fixes: 44a39283 ("drm/tests: Add Kunit Helpers") Reported-by:
-
Jani Nikula authored
We've used a temporary platform device for firmware EDID loading since it was introduced in commit da0df92b ("drm: allow loading an EDID as firmware to override broken monitor"), but there's no explanation why. Using a temporary device does not play well with CONFIG_FW_CACHE=y, which caches firmware images (e.g. on suspend) so that drivers can request firmware when the system is not ready for it, and return the images from the cache (e.g. during resume). This works automatically for regular devices, but obviously not for a temporarily created device. Stop using the throwaway platform device, and use the drm device instead. Note that this may still be problematic for cases where the display was plugged in during suspend, and the firmware wasn't loaded and therefore not cached before suspend. References: https://lore.kernel.org/r/20220727074152.43059-1-matthieu.charette@gmail.com Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061Reported-by:
Matthieu CHARETTE <matthieu.charette@gmail.com> Tested-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
-
Thomas Zimmermann authored
Support the kernel's nomodeset parameter for all PCI-based fbdev drivers that use aperture helpers to remove other, hardware-agnostic graphics drivers. The parameter is a simple way of using the firmware-provided scanout buffer if the hardware's native driver is broken. The same effect could be achieved with per-driver options, but the importance of the graphics output for many users makes a single, unified approach worthwhile. With nomodeset specified, the fbdev driver module will not load. This unifies behavior with similar DRM drivers. In DRM helpers, modules first check the nomodeset parameter before registering the PCI driver. As fbdev has no such module helpers, we have to modify each driver individually. The name 'nomodeset' is slightly misleading, but has been chosen for historical reasons. Several drivers implemented it before it became a general option for DRM. So keeping the existing name was preferred over introducing a new one. v2: * print a warning if a driver does not init (Helge) * wrap video_firmware_drivers_only() in helper Signed-off-by:
-
Thomas Zimmermann authored
Move the nomodeset kernel parameter to drivers/video to make it available to non-DRM drivers. Adapt the interface, but keep the DRM interface drm_firmware_drivers_only() to avoid churn within DRM. The function should later be inlined into callers. The parameter disables any DRM graphics driver that would replace a driver for firmware-provided scanout buffers. It is an option to easily fallback to basic graphics output if the hardware's native driver is broken. Moving it to a more prominent location wil make it available to fbdev as well. v2: * clarify the meaning of the nomodeset parameter (Javier) Signed-off-by:
-
Thomas Zimmermann authored
The fbdev damage worker is unused, so remove it. Signed-off-by:
-
Thomas Zimmermann authored
Schedule the deferred-I/O worker instead of the damage worker after writing to the fbdev framebuffer. The deferred-I/O worker then performs the dirty-fb update. The fbdev emulation will initialize deferred I/O for all drivers that require damage updates. It is therefore a valid assumption that the deferred-I/O worker is present. It would be possible to perform the damage handling directly from within the write operation. But doing this could increase the overhead of the write or interfere with a concurrently scheduled deferred-I/O worker. Instead, scheduling the deferred-I/O worker with its regular delay of 50 ms removes load off the write operation and allows the deferred-I/O worker to handle multiple write operations that arrived during the delay time window. v3: * remove unused variable (lkp) v2: * keep drm_fb_helper_damage() (Daniel) * use fb_deferred_io_schedule_flush() (Daniel) * clarify comments (Daniel) Signed-off-by:
-
Thomas Zimmermann authored
Call fb_dirty directly from drm_fb_helper_deferred_io() to avoid the latency of running the damage worker. The deferred-I/O helper drm_fb_helper_deferred_io() runs in a worker thread at regular intervals as part of writing to mmaped framebuffer memory. It used to schedule the fbdev damage worker to flush the framebuffer. Changing this to flushing the framebuffer directly avoids the latency introduced by the damage worker. v2: * remove fb_dirty from defio in separate patch (Daniel) Signed-off-by:
-
Thomas Zimmermann authored
The helper for processing deferred I/O on pages has no dependency on the fb_dirty damge-handling callback; so remove the test. In practice, deferred I/O is only used with damage handling and the damage worker already guarantees the presence of the fb_dirty callback. Signed-off-by:
-
Thomas Zimmermann authored
Move the dirty-fb update from the damage-worker callback into the new helper drm_fb_helper_fb_dirty(), so that it can run outside the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Set the damage area in the new helper drm_fb_helper_add_damage_clip(). It can now be updated without scheduling the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by:
-
Brian Starkey authored
These formats are not subsampled, but that means hsub and vsub should be 1, not 0. Fixes: 94b292b2 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats") Reported-by:
George Kennedy <george.kennedy@oracle.com> Reported-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com> Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Danilo Krummrich authored
drm_mode_config_init() simply calls drmm_mode_config_init(), hence cleanup is automatically handled through registering drm_mode_config_cleanup() with drmm_add_action_or_reset(). While at it, get rid of the deprecated drm_mode_config_init() and replace it with drmm_mode_config_init() directly. Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Signed-off-by:
-
Danilo Krummrich authored
Use drm managed resource allocation (drmm_universal_plane_alloc()) in order to get rid of the explicit destroy hook in struct drm_plane_funcs. Signed-off-by:
-
Danilo Krummrich authored
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes() to get rid of the explicit destroy hook in struct drm_plane_funcs. Signed-off-by:
-
Danilo Krummrich authored
Using drm_device->dev_private is deprecated. Since we've switched to devm_drm_dev_alloc(), struct drm_device is now embedded in struct malidp_drm, hence we can use container_of() to get the struct drm_device instance instead. Signed-off-by:
-
Danilo Krummrich authored
Use drm managed resources to allocate driver structures and get rid of the deprecated drm_dev_alloc() call and replace it with devm_drm_dev_alloc(). This also serves as preparation to get rid of drm_device->dev_private and to fix use-after-free issues on driver unload. Signed-off-by:
-
- 15 Nov, 2022 9 commits
-
-
Maxime Ripard authored
We'll need to get the pixel clock to generate proper display modes for all the current named modes. Let's add it to struct drm_cmdline_mode and fill it when parsing the named mode. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Tested-by:
Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v9-12-24b168e5bcd5@cerno.techSigned-off-by:
-
Maxime Ripard authored
The current code to deal with named modes will only set the mode name, and then it's up to drivers to try to match that name to whatever mode or configuration they see fit. The plan is to remove that need and move the named mode handling out of drivers and into the core, and only rely on modes and properties. Let's start by properly filling drm_cmdline_mode from a named mode. Reviewed-by:
-
Maxime Ripard authored
The current named mode parsing relies only on the mode name, and doesn't allow to specify any other parameter. Let's convert that string list to an array of a custom structure that will hold the name and some additional parameters in the future. Reviewed-by:
-
Maxime Ripard authored
The current construction of the named mode parsing doesn't allow to extend it easily. Let's move it to a separate function so we can add more parameters and modes. In order for the tests to still pass, some extra checks are needed, so it's not a 1:1 move. Reviewed-by:
-
Maxime Ripard authored
drm_connector_pick_cmdline_mode() is in charge of finding a proper drm_display_mode from the definition we got in the video= command line argument. Let's add some unit tests to make sure we're not getting any regressions there. Acked-by:
-
Maxime Ripard authored
As the number of kunit tests in KMS grows further, we start to have multiple test suites that, for example, need to register a mock DRM driver to interact with the KMS function they are supposed to test. Let's add a file meant to provide those kind of helpers to avoid duplication. Reviewed-by:
-
Maxime Ripard authored
KMS supports a number of named modes already, but it's never been documented anywhere, let's fix that. Reviewed-by:
-
José Expósito authored
Commit 6bed2ea3 ("drm/vc4: hdmi: Reset link on hotplug") introduced the vc4_hdmi_reset_link() function. This function dereferences the "connector" pointer before checking whether it is NULL or not. Rework variable assignment to avoid this issue. Fixes: 6bed2ea3 ("drm/vc4: hdmi: Reset link on hotplug") Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20221110134752.238820-3-jose.exposito89@gmail.comSigned-off-by:
-
José Expósito authored
Simplify vc4_hdmi_supports_scrambling() by changing its first parameter from struct drm_encoder to struct vc4_hdmi. Signed-off-by:
-
- 14 Nov, 2022 5 commits
-
-
Douglas Anderson authored
If we fail to get a valid panel ID in drm_edid_get_panel_id() we'd like to see the EDID that was read so we have a chance of understanding what's wrong. There's already a function for that, so let's call it in the error case. NOTE: edid_block_read() has a retry loop in it, so actually we'll only print the block read back from the final attempt. This still seems better than nothing. Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221021130637.1.I8c2de0954a4e54e0c59a72938268e2ead91daa98@changeid
-
Dmitry Osipenko authored
Recently DRM framebuffer core and all drivers were moved to unlocked vmapping functions that take the reservation lock. The drm_gem_vram_vmap() was missed out by accident and now deadlocks drivers that use drm_gem_vram helpers when framebuffer is updated, like Bochs driver. Remove the locking from drm_gem_vram_v[un]map() functions to fix the deadlock. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Fixes: 79e2cf2e ("drm/gem: Take reservation lock for vmap/vunmap operations") Signed-off-by:
-
Chris Morgan authored
Support NewVision NV3051D panels as found on the Anbernic RG353P and RG353V. The underlying LCD part number for the RG353x devices is unknown, so the device name and a fallback for the driver IC is used instead. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> [Fixed checkpatch moan about parens] Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221111203130.9615-4-macroalpha82@gmail.com
-
Chris Morgan authored
Add documentation for the NewVision NV3051D panel bindings. Note that for the two expected consumers of this panel binding the underlying LCD model is unknown. Name "anbernic,rg353p-panel" is used because the hardware itself is known as "anbernic,rg353p". Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Chris Morgan authored
NewVision (also sometimes written as New Vision) is a company based in Shenzen that manufactures ICs for controlling LCD panels. https://www.newvisiondisplay.com/Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
- 11 Nov, 2022 3 commits
-
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-8-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Signed-off-by: -
Ville Syrjälä authored
Initialize on-stack modes with drm_mode_init() to guarantee no stack garbage in the list head. Based on the following cocci script, with manual fixups: @decl@ identifier M; expression E; @@ - struct drm_display_mode M = E; + struct drm_display_mode M; @@ identifier decl.M; expression decl.E; statement S, S1; @@ struct drm_display_mode M; ... when != S + drm_mode_init(&M, &E); + S1 @@ expression decl.E; @@ - &*E + E Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
