- 21 Mar, 2022 6 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: Jyri Sarha <jyri.sarha@iki.fi> Cc: Tomi Valkeinen <tomba@kernel.org> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-17-ville.syrjala@linux.intel.comReviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
-
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: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
-
Zack Rusin authored
With very limited vram on svga3 it's difficult to handle all the surface migrations. Without gbobjects, i.e. the ability to store surfaces in guest mobs, there's no reason to support intermediate svga2 features, especially because we can fall back to fb traces and svga3 will never support those in-between features. On svga3 we wither want to use fb traces or screen targets (i.e. gbobjects), nothing in between. This fixes presentation on a lot of fusion/esxi tech previews where the exposed svga3 caps haven't been finalized yet. Signed-off-by:
Zack Rusin <zackr@vmware.com> Fixes: 2cd80dbd ("drm/vmwgfx: Add basic support for SVGA3") Cc: <stable@vger.kernel.org> # v5.14+ Reviewed-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-5-zack@kde.org
-
Zack Rusin authored
The kms code wasn't validating the modifiers and was letting through unsupported formats. rgb8 was never properly supported and has no matching svga screen target format so remove it. This fixes format/modifier failures in kms_addfb_basic from IGT. Signed-off-by:
-
Zack Rusin authored
Writes to SVGA_REG_CURSOR_MOBID did not wait for the buffers to be fully populated. This sometimes results in the device not being aware of the buffer when the cursor mob register was written. Properly wait for the buffer to be fully populated before setting it as a cursor mob. Signed-off-by:
-
Zack Rusin authored
vmw_move assumed that buffers to be moved would always be vmw_buffer_object's but after introduction of new placement for mob pages that's no longer the case. The resulting invalid read didn't have any practical consequences because the memory isn't used unless the object actually is a vmw_buffer_object. Fix it by moving the cast to the spot where the results are used. Signed-off-by:
Chuck Lever III <chuck.lever@oracle.com> Reviewed-by:
-
- 18 Mar, 2022 2 commits
-
-
Chuansheng Liu authored
Easily hit the below list corruption: == list_add corruption. prev->next should be next (ffffffffc0ceb090), but was ffffec604507edc8. (prev=ffffec604507edc8). WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26 __list_add_valid+0x53/0x80 CPU: 65 PID: 3959 Comm: fbdev Tainted: G U RIP: 0010:__list_add_valid+0x53/0x80 Call Trace: <TASK> fb_deferred_io_mkwrite+0xea/0x150 do_page_mkwrite+0x57/0xc0 do_wp_page+0x278/0x2f0 __handle_mm_fault+0xdc2/0x1590 handle_mm_fault+0xdd/0x2c0 do_user_addr_fault+0x1d3/0x650 exc_page_fault+0x77/0x180 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x7fd98fc8fad1 == Figure out the race happens when one process is adding &page->lru into the pagelist tail in fb_deferred_io_mkwrite(), another process is re-initializing the same &page->lru in fb_deferred_io_fault(), which is not protected by the lock. This fix is to init all the page lists one time during initialization, it not only fixes the list corruption, but also avoids INIT_LIST_HEAD() redundantly. V2: change "int i" to "unsigned int i" (Geert Uytterhoeven) Signed-off-by:
Chuansheng Liu <chuansheng.liu@intel.com> Fixes: 105a9404 ("fbdev/defio: Early-out if page is already enlisted") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Sankeerth Billakanti authored
Add panel identification entry for the sharp LQ140M1JW46 eDP panel with power sequencing delay information. Signed-off-by:
Sankeerth Billakanti <quic_sbillaka@quicinc.com> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 17 Mar, 2022 13 commits
-
-
Christophe Branchereau authored
Add binding for the leadtek ltk035c5444t, which is a 640x480 mipi-dbi over spi / 24-bit RGB panel based on the newvision NV03052C chipset. It is found in the Anbernic RG350M mips handheld. Signed-off-by:
Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220311170240.173846-5-cbranchereau@gmail.com
-
Thomas Zimmermann authored
Commit 0d030118 ("fbdev: Improve performance of cfb_imageblit()") broke cfb_imageblit() for image widths that are not aligned to 8-bit boundaries. Fix this by handling the trailing pixels on each line separately. The performance improvements in the original commit do not regress by this change. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reported-by:
-
Thomas Zimmermann authored
Commit 6f29e049 ("fbdev: Improve performance of sys_imageblit()") broke sys_imageblit() for image width that are not aligned to 8-bit boundaries. Fix this by handling the trailing pixels on each line separately. The performance improvements in the original commit do not regress by this change. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220313192952.12058-2-tzimmermann@suse.de
-
Patrik Jakobsson authored
Use the gma_ prefix instead of psb_ since the code is common for all chips. Various coding style fixes. Removal of unused code. Removal of duplicate function declarations. Signed-off-by:
-
Patrik Jakobsson authored
The drm_crtc_funcs are all generic and no chip specific functions are necessary. We can therefore directly put gma_crtc_funcs into the drm_crtc. Signed-off-by:
-
Patrik Jakobsson authored
All functions live in gma_display.c already so move the vtable. Also shorten the name to gma_crtc_funcs. Signed-off-by:
-
Patrik Jakobsson authored
Most of these are old leftovers from one of the driver merges. This is all dead code. Signed-off-by:
-
Melissa Wen authored
Trace submit_cl_ioctl and related IRQs for CL submission and bin/render jobs execution. It might be helpful to get a rendering timeline and track job throttling. Signed-off-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220201212651.zhltjmaokisffq3x@mail.igalia.com
-
Geert Uytterhoeven authored
ssd130x_clear_screen() allocates a temporary buffer sized to hold one byte per pixel, while it only needs to hold one bit per pixel. ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one byte per pixel for the whole frame buffer, while it only needs to hold one bit per pixel for the part that is to be updated. Pass dst_pitch to drm_fb_xrgb8888_to_mono(), as we have already calculated it anyway. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
-
Geert Uytterhoeven authored
The rectangle update functions ssd130x_fb_blit_rect() and ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 != 0, or when y1 or y2 are not aligned to display page boundaries. E.g. when used as a text console, only the first line of text is shown on the display. 1. The buffer passed by ssd130x_fb_blit_rect() points to the first byte of monochrome bitmap data, and thus has its origin at (x1, y1), while ssd130x_update_rect() assumes it is at (0, 0). Fix ssd130x_update_rect() by changing the vertical and horizontal loop ranges, and adding the offsets only when needed. 2. In ssd130x_fb_blit_rect(), align y1 and y2 to the display page boundaries before doing the color conversion, so the full page is converted and updated. Remove the correction for an unaligned y1 from ssd130x_update_rect(), and add a check to make sure y1 is aligned. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by: -
Geert Uytterhoeven authored
The conversion functions drm_fb_xrgb8888_to_mono() and drm_fb_gray8_to_mono_line() do not behave correctly when the horizontal boundaries of the clip rectangle are not multiples of 8: a. When x1 % 8 != 0, the calculated pitch is not correct, b. When x2 % 8 != 0, the pixel data for the last byte is wrong. Simplify the code and fix (a) by: 1. Removing start_offset, and always storing the first pixel in the first bit of the monochrome destination buffer. Drivers that require the first pixel in a byte to be located at an x-coordinate that is a multiple of 8 can always align the clip rectangle before calling drm_fb_xrgb8888_to_mono(). Note that: - The ssd130x driver does not need the alignment, as the monochrome buffer is a temporary format, - The repaper driver always updates the full screen, so the clip rectangle is always aligned. 2. Passing the number of pixels to drm_fb_gray8_to_mono_line(), instead of the number of bytes, and the number of pixels in the last byte. Fix (b) by explicitly setting the target bit, instead of always setting bit 7 and shifting the value in each loop iteration. Remove the bogus pitch check, which operates on bytes instead of pixels, and triggers when e.g. flashing the cursor on a text console with a font that is 8 pixels wide. Drop the confusing comment about scanlines, as a pitch in bytes always contains a multiple of 8 pixels. While at it, use the drm_rect_height() helper instead of open-coding the same operation. Update the comments accordingly. Fixes: bcf8b616 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by:Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
There is no "reversed" handling in drm_fb_xrgb8888_to_mono_reversed(): the function just converts from color to grayscale, and reduces the number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is mapped to 0, 128-255 to 1). All "reversed" handling is done in the repaper driver, where this function originated. Hence make this clear by renaming drm_fb_xrgb8888_to_mono_reversed() to drm_fb_xrgb8888_to_mono(), and documenting the black/white pixel mapping. Fixes: bcf8b616 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by:
-
Jeffrey Hugo authored
The documentation for render nodes indicates that only "PRIME-related" ioctls are valid on render nodes, but the documentation does not clarify what that means. If the reader is not familiar with PRIME, they may beleive this to be only the ioctls with "PRIME" in the name and not other ioctls such as set of syncobj ioctls. Clarify the situation for the reader by referencing where the reader will find a current list of valid ioctls. Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
-
- 16 Mar, 2022 15 commits
-
-
Colin Ian King authored
There is a spelling mistake in a nvdev_error error message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Thomas Zimmermann authored
Move the setup code for GTT/GATT memory ranges into a new helper and call the function from psb_gtt_init() and psb_gtt_resume(). Removes code duplication. Signed-off-by:
-
Thomas Zimmermann authored
Move the code for enabling and disabling the GTT into helpers and call the functions in psb_gtt_init(), psb_gtt_fini() and psb_gtt_resume(). Removes code duplication. Signed-off-by:
-
Thomas Zimmermann authored
Move GEM functions from gtt.c to gem.c. Adapt some names. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Inline psb_gtt_restore() into its only caller in power.c. Perform the GTT restoration in psb_gem_mm_resume(). The restoration step is part of GEM anyway and will be moved over at some point. Signed-off-by:
-
Thomas Zimmermann authored
The GTT init, fini and resume functions contain both, GTT and GEM, code. Split each into a separate GTT and a GEM function. The GEM code is responsible for mmap_mutex and the stolen memory area. The rest of the functionality is left in GTT functions. Signed-off-by:
-
Thomas Zimmermann authored
Replace psb_gtt_takedown() with finalizer function that is only called for unloading the driver. Use roll-back pattern for error handling in psb_gtt_init() and _resume(). Also fixes a bug where vmap_addr was never unmapped. Signed-off-by:
-
Thomas Zimmermann authored
The current implementation of psb_gtt_init() also does resume handling. Move the resume code into its own helper. Signed-off-by:
-
Thomas Zimmermann authored
The GTT init and restore functions contain logic to populate the GTT entries. Move the code into helper functions. Signed-off-by:
-
Thomas Zimmermann authored
The semaphore at struct psb_mmu_driver.sem protects access to the MMU fields. Additional locking with struct psb_gtt.sem is unnecessary. Remove the field and related code. Signed-off-by:
-
Thomas Zimmermann authored
Acquire the GTT mutex in psb_gtt_{insert,remove}_pages(). Remove locking from callers. Also remove the GTT locking around the resume code. Resume does not run concurrently with other GTT operations. Signed-off-by: -
Thomas Zimmermann authored
Protect concurrent access to struct psb_gem_object by acquiring the GEM object's reservation lock; as it's supposed to be. The use of the GTT mutex can now be moved into GTT code. Signed-off-by:
-
Thomas Zimmermann authored
Calculate the number of pages in the BO's backing storage from the size. Remove the npage field. Signed-off-by:
-
YueHaibing authored
WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n] Selected by [m]: - DRM_SSD130X [=m] && HAS_IOMEM [=y] && DRM [=m] DRM_GEM_SHMEM_HELPER depends on MMU, DRM_SSD130X should also depends on MMU. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
-
Dmitry Baryshkov authored
The documentation for drm_rotation_simplify() uses DRM_MODE_ROTATE_X, while it's clear the comment should mention DRM_MODE_REFLECT_X instead. The example passes all flags except the DRM_MODE_REFLECT_X as supported and expects to eliminate this flag. Fixes: c2c446ad ("drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
- 14 Mar, 2022 4 commits
-
-
Ville Syrjälä authored
Replace the hand rolled drm_mode_duplicate() with the real thing. @is_dup@ @@ drm_mode_duplicate(...) { ... } @depends on !is_dup@ expression dev, oldmode; identifier newmode; @@ - newmode = drm_mode_create(dev); + newmode = drm_mode_duplicate(dev, oldmode); ... - drm_mode_copy(newmode, oldmode); Signed-off-by:Sam Ravnborg <sam@ravnborg.org>
-
Ville Syrjälä authored
Replace the hand rolled drm_mode_duplicate() with the real thing. @is_dup@ @@ drm_mode_duplicate(...) { ... } @depends on !is_dup@ expression dev, oldmode; identifier newmode; @@ - newmode = drm_mode_create(dev); + newmode = drm_mode_duplicate(dev, oldmode); ... - drm_mode_copy(newmode, oldmode); Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:Philipp Zabel <p.zabel@pengutronix.de>
-
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: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Ville Syrjälä authored
Add a variant of drm_mode_copy() that explicitly clears out the list head of the destination mode. Helpful to guarantee we don't have stack garbage left in there for on-stack modes. Signed-off-by:
Harry Wentland <harry.wentland@amd.com>
-
