- 08 Dec, 2022 1 commit
-
-
Maxime Ripard authored
We'll need to use those helpers from drivers too, so let's move it to a more visible location. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-1-4615a663a84a@cerno.techSigned-off-by:
Maxime Ripard <maxime@cerno.tech>
-
- 07 Dec, 2022 2 commits
-
-
Allen Ballway authored
Like the ASUS T100HAN for which there is already a quirk, the DynaBook K50 has a 800x1280 portrait screen mounted in the tablet part of a landscape oriented 2-in-1. Update the quirk to be more generic and apply to this device. Signed-off-by:
Allen Ballway <ballway@chromium.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
The Lenovo Yoga Tab 3 X90F has a portrait 1600x2560 LCD used in landscape mode, add a quirk for this. Signed-off-by:
-
- 06 Dec, 2022 10 commits
-
-
Noralf Trønnes authored
gud has a module parameter that controls whether framebuffer flushing happens synchronously during the commit or asynchronously in a worker. GNOME before version 3.38 handled all displays in the same rendering loop. This lead to gud slowing down the refresh rate for a faster monitor. This has now been fixed so lets change the default. The plan is to remove async flushing in the future. The code is now structured in a way that makes it easy to do this. Link: https://blogs.gnome.org/shell-dev/2020/07/02/splitting-up-the-frame-clock/Suggested-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-6-435037990a83@tronnes.org
-
Noralf Trønnes authored
Use the shadow plane helper to take care of mapping the framebuffer for CPU access. The synchronous flushing is now done inline without the use of a worker. The async path now uses a shadow buffer to hold framebuffer changes and it doesn't read the framebuffer behind userspace's back anymore. v2: - Use src as variable name for iosys_map (Thomas) - Prepare imported buffer for CPU access in the driver (Thomas) Reviewed-by:
-
Noralf Trønnes authored
In preparation for moving to the shadow plane helper prepare the framebuffer for CPU access as early as possible. v2: - Use src as variable name for iosys_map (Thomas) Reviewed-by:
-
Noralf Trønnes authored
In preparation for inlining synchronous flushing split out the part of gud_flush_work() that can be shared by the sync and async code paths. Reviewed-by:
-
Noralf Trønnes authored
If a framebuffer flush fails the driver will do one retry by requeing the worker. Currently the worker is used even for synchronous flushing, but a later patch will inline it, so this needs to change. Thinking about how to solve this I came to the conclusion that this retry mechanism was a fix for a problem that was only in the mind of the developer (me) and not something that solved a real problem. So let's remove this for now and revisit later should it become necessary. gud_add_damage() has now only one caller so it can be inlined. Reviewed-by:
-
Noralf Trønnes authored
UBSAN complains about invalid value for bool: [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1 [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device [ 101.213426] usbcore: registered new interface driver gud [ 101.989431] ================================================================================ [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9 [ 101.989447] load of value 121 is not a valid value for type '_Bool' [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3 [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018 [ 101.989459] Workqueue: events_long gud_flush_work [gud] [ 101.989471] Call Trace: [ 101.989474] <TASK> [ 101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busiest_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [ 101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [ 101.989708] ================================================================================ The source of this warning is in iosys_map_clear() called from dma_buf_vmap(). It conditionally sets values based on map->is_iomem. The iosys_map variables are allocated uninitialized on the stack leading to ->is_iomem having all kinds of values and not only 0/1. Fix this by zeroing the iosys_map variables. Fixes: 40e1a70b ("drm: Add GUD USB Display driver") Cc: <stable@vger.kernel.org> # v5.18+ Reviewed-by:
-
Christian König authored
Make sure that we use the correct settings from the context. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-8-christian.koenig@amd.com
-
Christian König authored
Merge and cleanup the two headers into a single description of the object API. Also move all the documentation to the implementation and drop unnecessary includes from the header. No functional change. v2: minimal checkpatch.pl cleanup Signed-off-by:
-
Christian König authored
Instead of a single worker going over the list of delete BOs in regular intervals use a per BO worker which blocks for the resv object and locking of the BO. This not only simplifies the handling massively, but also results in much better response time when cleaning up buffers. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Christian König authored
Those functions never worked correctly since it is still perfectly possible that a buffer object is released and the background worker restarted even after calling them. Signed-off-by:
-
- 05 Dec, 2022 8 commits
-
-
Thomas Zimmermann authored
Call drm_dev_enter() and drm_dev_exit() in the outer-most callbacks of the modesetting pipeline. If drm_dev_enter() fails, the driver can thus avoid unnecessary work. Signed-off-by:
-
Thomas Zimmermann authored
Use the buffer mappings provided by shadow-plane helpers. As the mappings are established while the commit can still fail, errors are now reported correctly to callers. v2: * use shadow-plane state directly (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Implement MIPI DBI planes with struct drm_shadow_plane_state, so that the respective drivers can use the vmap'ed GEM-buffer memory. Implement state helpers, the {begin,end}_fb_access helpers and wire up everything. With this commit, MIPI DBI drivers can access the GEM object's memory that is provided by shadow-plane state. The actual changes to drivers are implemented separately. v2: * use shadow-plane state directly (Noralf) Signed-off-by: -
Thomas Zimmermann authored
Move the vmap/vunmap blocks from the inner fb_dirty helpers into the MIPI DBI update helpers. The function calls can result in waiting and/or processing overhead. Reduce the penalties by executing the functions once in the outer-most function of the pipe update. This change also prepares for MIPI DBI for shadow-plane helpers. With shadow-plane helpers, transfer source buffers are mapped into kernel address space automatically. v2: * keep each driver's existing buffer-mapping patter (Noralf) * zero-initialize iosys_map arrays (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Introduce DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS to initialize MIPI-DBI helpers to default values and convert drivers. The prepare_fb function set by some drivers is called implicitly by simple-kms helpers, so leave it out. Signed-off-by:
-
Thomas Zimmermann authored
MIPI DBI drivers validate each mode against their native resolution. Add this test to st7586. Signed-off-by:
-
Thomas Zimmermann authored
MIPI DBI drivers validate each mode against their native resolution. Add this test to ili9225. Signed-off-by:
-
Thomas Zimmermann authored
The helper drm_gem_simple_display_pipe_prepare_fb() is simple-KMS' default implementation for prepare_fb. Remove the call from drivers that set it explicitly. Then inline the helper into the only caller within simple-kms helpers. No functional changes. Simple-KMS drivers that implement the prepare_fb callback should call drm_gem_plane_helper_prepare_fb() directly. v2: * fix typo in commit message Signed-off-by:
-
- 01 Dec, 2022 12 commits
-
-
Dave Stevenson authored
The mapping is incorrect for RGB565_1X16 as it should be DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3. Fixes: 08302c35 ("drm/vc4: Add DPI driver") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-7-eb76e26a772d@cerno.techSigned-off-by:
-
Dave Stevenson authored
DPI hasn't really been used up until now, so the default has been meaningless. In theory we should be able to pass the desired format for the adjacent bridge chip through, but framework seems to be missing for that. As the main device to use DPI is the VGA666 or Adafruit Kippah, both of which use RGB666, change the default to being RGB666 instead of RGB888. Signed-off-by:
-
Joerg Quinten authored
The VC4 DPI output can support multiple BGR666 variants, but they were never added to the driver. Let's add the the support for those formats. Signed-off-by:
Joerg Quinten <aBUGSworstnightmare@gmail.com> Reviewed-by:
-
Chris Morgan authored
The RGB565 format with padding over 24 bits (MEDIA_BUS_FMT_RGB565_1X24_CPADHI) is supported by the vc4 DPI controller. This is what the Geekworm MZP280 DPI display uses, so let's add support for it in the DPI controller driver. Reviewed-by:
Chris Morgan <macromorgan@hotmail.com> Reviewed-by:
-
Joerg Quinten authored
Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X24_CPADHI supported by the RaspberryPi. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-3-eb76e26a772d@cerno.techSigned-off-by:
-
Joerg Quinten authored
Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X18 supported by the RaspberryPi. Signed-off-by:
-
Chris Morgan authored
Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm MZP280 panel for the Raspberry Pi. Signed-off-by:
-
Maxime Ripard authored
The len variable is used while uninitialized. Initialize it. Fixes: 1e4a91db ("drm/probe-helper: Provide a TV get_modes helper") Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Maxime Ripard authored
The mode name in struct drm_cmdline_mode can hold 32 characters at most, which can easily get overrun. Switch to strscpy() to prevent such a thing. Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1527354 ("Security best practices violations") Fixes: a7ab1553 ("drm/modes: Switch to named mode descriptors") Reviewed-by:
-
Maxime Ripard authored
The underline length for the new Analog TV properties section doesn't match the title length, resulting in a warning. Fixes: 7d63cd85 ("drm/connector: Add TV standard property") Reported-by:
-
Matti Vaittinen authored
Simplify using the devm_regulator_get_enable_optional(). Also drop the now unused struct member 'hdmi_supply'. Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/df0096b5aea2a18d1540cde379c5abf589ccd7c4.1669799805.git.mazziesaccount@gmail.com
-
Matti Vaittinen authored
Simplify using devm_regulator_bulk_get_enable() Signed-off-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
- 29 Nov, 2022 7 commits
-
-
Alaa Emad authored
Change min cursor size of vkms driver from 20 to 10, to increase the IGT test coverage of vkms by enabling 32x10 cursor size subtests in kms_cursor_crc Signed-off-by:
Alaa Emad <aemad@igalia.com> Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221109113945.20938-1-aemad@igalia.com
-
Yuan Can authored
A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff1 #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below: vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release(). Fixes: 6c234fe3 ("drm/vkms: Implement CRC debugfs API") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
-
Yuan Can authored
A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace: [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened. Fixes: 2df7af93 ("drm/vkms: Add vkms_config type") Signed-off-by: -
Drew Davenport authored
Avoid the panel oscillating on and off during boot. In some cases it will be more than 1000ms between powering the panel to read the EDID early during boot, and enabling the panel for display. Extending the autosuspend delay avoids autosuspending during this interval. Signed-off-by:
Drew Davenport <ddavenport@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Drew Davenport authored
Same change as done for panel-samsung-atna33xc20. Extend the autosuspend delay to avoid oscillating between power status during boot. Signed-off-by:
-
Drew Davenport authored
ktime_get_boottime continues while the device is suspended. This change ensures that the resume path will not be delayed if the power off delay has already been met while the device is suspended Signed-off-by:
-
Drew Davenport authored
ktime_get_boottime continues while the device is suspended. This change ensures that the resume path will not be delayed if the power off delay has already been met while the device is suspended Signed-off-by:
-
