- 04 Nov, 2022 2 commits
-
-
Thomas Zimmermann authored
Properties of 32-bit integers are returned from the OF device tree as type __be32. Convert PCI vendor and device IDs from __be32 to host endianness before comparing them to constants. All relevant machines are old, big-endian Macintosh systems; hence the bug never happened in practice. Fixes sparse warnings shown below. drivers/gpu/drm/tiny/ofdrm.c:237:17: warning: restricted __be32 degrades to integer drivers/gpu/drm/tiny/ofdrm.c:238:18: warning: restricted __be32 degrades to integer drivers/gpu/drm/tiny/ofdrm.c:238:54: warning: restricted __be32 degrades to integer See [1] for the bug report. v2: * convert endianness (Alex) Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/dri-devel/202210192208.D888I6X7-lkp@intel.com/ # [1] Link: https://patchwork.freedesktop.org/patch/msgid/20221103101627.32502-2-tzimmermann@suse.de
-
Yuan Can authored
A problem about modprobe ingenic-drm failed is triggered with the following log given: [ 303.561088] Error: Driver 'ingenic-ipu' is already registered, aborting... modprobe: ERROR: could not insert 'ingenic_drm': Device or resource busy The reason is that ingenic_drm_init() returns platform_driver_register() directly without checking its return value, if platform_driver_register() failed, it returns without unregistering ingenic_ipu_driver_ptr, resulting the ingenic-drm can never be installed later. A simple call graph is shown as below: ingenic_drm_init() platform_driver_register() # ingenic_ipu_driver_ptr are registered platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without unregister ingenic_ipu_driver_ptr Fixing this problem by checking the return value of platform_driver_register() and do platform_unregister_drivers() if error happened. Fixes: fc1acf31 ("drm/ingenic: Add support for the IPU") Signed-off-by:Yuan Can <yuancan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20221104064512.8569-1-yuancan@huawei.com
-
- 03 Nov, 2022 14 commits
-
-
Christian König authored
This now matches much better what this is doing. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014084641.128280-14-christian.koenig@amd.com
-
Christian König authored
This was buggy because when we had to wait for entities which were killed as well we would just deadlock. Instead move all the dependency handling into the callbacks so that will all happen asynchronously. Signed-off-by:
-
Christian König authored
Not used any more. Signed-off-by:
-
Christian König authored
Entirely remove the sync obj in the job. Signed-off-by:
-
Christian König authored
Instead of putting that into the job sync object. Signed-off-by:
-
Christian König authored
Instead of putting that into the job sync object. Signed-off-by:
-
Christian König authored
This moves the memory allocation out of the critical code path. Signed-off-by:
-
Christian König authored
Init the DRM scheduler base class while allocating the job. This makes the whole handling much more cleaner. v2: fix coding style Signed-off-by:
-
Christian König authored
Instead return the fence directly. Avoids memory allocation to store the fence. v2: cleanup coding style as well Signed-off-by:
-
Christian König authored
This is always the job anyway. Signed-off-by:
-
Christian König authored
Use the new common scheduler functions to figure out what to wait for. Signed-off-by:
-
Christian König authored
Add a new function to update job dependencies from a resv obj. Signed-off-by:
-
Thomas Zimmermann authored
Add a dependency on CONFIG_MMU to ofdrm. The driver uses GEM SHMEM helpers, which require MMU support. A reported error message [1] is shown below. arm-linux-gnueabi-ld: drivers/gpu/drm/drm_gem_shmem_helper.o: in function `drm_gem_shmem_fault': >> drivers/gpu/drm/drm_gem_shmem_helper.c:562: undefined reference to `vmf_insert_pfn' Reported-by:
-
Nathan Chancellor authored
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/meson/meson_encoder_cvbs.c:211:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_bridge *, const struct drm_display_info *, const struct drm_display_mode *)' with an expression of type 'int (struct drm_bridge *, const struct drm_display_info *, const struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = meson_encoder_cvbs_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. ->mode_valid() in 'struct drm_bridge_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of meson_encoder_cvbs_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750Reported-by:Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221102155242.1927166-1-nathan@kernel.org
-
- 02 Nov, 2022 4 commits
-
-
Arthur Grillo authored
As reported by Michał, the drm_mm and drm_buddy unit tests lost the printk with seed value after they were refactored into KUnit. Add kunit_info with seed value information to assure reproducibility. Reported-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20221028221755.340487-1-arthurgrillo@riseup.net
-
Dmitry Osipenko authored
The drm_gem_vunmap() will crash with a NULL dereference if the passed object pointer is NULL. It wasn't a problem before we added the locking support to drm_gem_vunmap function because the mapping argument was always NULL together with the object. Make drm_client_buffer_delete() to check whether GEM is NULL before trying to unmap the GEM, it will happen on framebuffer creation error. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221030154412.8320-3-dmitry.osipenko@collabora.com
-
Dmitry Osipenko authored
The dma_buf_detach() locks attach->dmabuf->resv and then unlocks dmabuf->resv, which could be a two different locks from a static code checker perspective. In particular this triggers Smatch to report the "double unlock" error. Make the locking pointers consistent. Reported-by:
-
Gaosheng Cui authored
Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Fixes: 3312be8f ("drm/ttm: move populated state into page flags") Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by:
-
- 01 Nov, 2022 4 commits
-
-
Marek Vasut authored
In case mipi_dsi_attach() fails, call drm_panel_remove() to avoid memory leak. Fixes: 849b2e3f ("drm/panel: Add Sitronix ST7701 panel driver") Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221014231106.468063-1-marex@denx.de
-
Marek Vasut authored
There are two command register files, CMD1 and CMD2, where only the CMD2 contains additional register sub-files BK0..3 . Pull the register file selection call into separate function instead of duplicating it all over the driver. The CMD2BK2 file is undocumented in datasheet, and is used for BIST. No functional change. Signed-off-by:
-
Marek Vasut authored
The RTNI field is multiplied by 16 and incremented by 512 before being used as the minimum number of pixel clock per horizontal line, hence it is necessary to subtract those 512 bytes from htotal and then divide the result by 16 before writing the value into the RTNI field. Fix the calculation. Fixes: de2b4917 ("drm/panel/panel-sitronix-st7701: Infer horizontal pixel count from TFT mode") Signed-off-by:
-
Marco Felsch authored
If a axi bus master with a higher priority do a lot of memory access FIFO underruns can be inspected. Increase the burst size to 256B to avoid such underruns and to improve the memory access efficiency. Fixes: 9db35bb3 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
-
- 31 Oct, 2022 2 commits
-
-
Zack Rusin authored
Cursor snooping depended on implicit size and format which made debugging quite difficult. Make the code easier to following by making everything explicit and instead of using magic numbers predefine all the parameters the code depends on. Also fixes incorrectly computed pitches for non-aligned cursor snoops. Fix which has no practical effect because non-aligned cursor snoops are not used by the X11 driver and Wayland cursors will go through mob cursors, instead of surface dma's. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Michael Banack <banackm@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-2-zack@kde.org
-
Zack Rusin authored
Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor. Signed-off-by:
-
- 29 Oct, 2022 5 commits
-
-
Zhang Qilong authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 34cc0aa2 ("drm/rockchip: Add support for Rockchip Soc LVDS") Fixes: cca1705c ("drm/rockchip: lvds: Add PX30 support") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220922132107.105419-3-zhangqilong3@huawei.com
-
Yuan Can authored
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() to avoid device usage counter leak. Signed-off-by:
-
Jiapeng Chong authored
The function dsi_update_bits() is defined in the dw-mipi-dsi-rockchip.c file, but not called elsewhere, so delete this unused function. drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:367:20: warning: unused function 'dsi_update_bits'. https://bugzilla.openanolis.cn/show_bug.cgi?id=2414Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Sascha Hauer authored
Esmart0-win0 could serve as primary plane, so mark it as such. On RK3568 this window will never be used as primary plane, because the three windows at the beginning of the rk3568_vop_win_data[] array will be used. On RK3566 however, two of the windows at the beginning of the rk3568_vop_win_data[] array cannot not be used due to hardware limitations, so without this patch we end up with CRTCs without primary planes when multiple VPs are active. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Tested-by:
Chris Morgan <macromorgan@hotmail.com> Signed-off-by:
-
Johan Jonker authored
The function rockchip_drm_framebuffer_init() was in use in the rockchip_drm_fbdev.c file, but that is now replaced by a generic fbdev setup. Reduce the image size by removing the rockchip_drm_framebuffer_init() and sub function rockchip_fb_alloc() and cleanup the rockchip_drm_fb.h header file. Signed-off-by:
Johan Jonker <jbx6244@gmail.com> Reviewed-by:
John Keeping <john@metanate.com> Signed-off-by:
-
- 28 Oct, 2022 8 commits
-
-
Ahmad Fatoum authored
adv7511 probe may need to be attempted multiple times before no -EPROBE_DEFER is returned. Currently, every such probe results in an error message: [ 4.534229] adv7511 1-003d: failed to find dsi host [ 4.580288] adv7511 1-003d: failed to find dsi host This is misleading, as there is no error and probe deferral is normal behavior. Fix this by using dev_err_probe that will suppress -EPROBE_DEFER errors. While at it, we touch all dev_err in the probe path. This makes the code more concise and included the error code everywhere to aid user in debugging. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
-
Maxime Ripard authored
Following the clock rate range improvements to the clock framework, trying to set a disjoint range on a clock will now result in an error. Thus, we can't set a minimum rate higher than the maximum reported by the firmware, or clk_set_min_rate() will fail. Thus we need to clamp the rate we are about to ask for to the maximum rate possible on that clock. Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v5-7-fe9e7ac8b111@cerno.techSigned-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Dom Cobley authored
At least the 4096x2160@60Hz mode requires some overclocking that isn't available by default, even if hdmi_enable_4kp60 is enabled. Let's add some logic to detect whether we can satisfy the core clock requirements for that mode, and prevent it from being used otherwise. Signed-off-by:
Dom Cobley <popcornmix@gmail.com> Reviewed-by:
-
Maxime Ripard authored
In order to support higher HDMI frequencies, users have to set the hdmi_enable_4kp60 parameter in their config.txt file. This will have the side-effect of raising the maximum of the core clock, tied to the HVS, and managed by the HVS driver. However, we are querying this in the HDMI driver by poking into the HVS structure to get our struct clk handle. Let's make this part of the HVS bind implementation to have all the core clock related setup in the same place. Reviewed-by:
-
Maxime Ripard authored
In order to support higher HDMI frequencies, users have to set the hdmi_enable_4kp60 parameter in their config.txt file. We were detecting this so far by calling clk_round_rate() on the core clock with the frequency we're supposed to run at when one of those modes is enabled. Whether or not the parameter was enabled could then be inferred by the returned rate since the maximum clock rate reported by the firmware was one of the side effect of setting that parameter. However, the recent clock rework we did changed what clk_round_rate() was returning to always return the minimum allowed, and thus this test wasn't reliable anymore. Let's use the new clk_get_max_rate() function to reliably determine the maximum rate allowed on that clock and fix the 4k@60Hz output. Fixes: e9d6cea2 ("clk: bcm: rpi: Run some clocks at the minimum rate allowed") Reviewed-by:
-
Maxime Ripard authored
The firmware allows to query for its clocks the operating range of a given clock. We'll need this for some drivers (KMS, in particular) to infer the state of some configuration options, so let's create a function to do so. Acked-by:
Stephen Boyd <sboyd@kernel.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
-
Maxime Ripard authored
We'll need the clock IDs in more drivers than just the clock driver from now on, so let's move them in the firmware header. Reviewed-by:
-
Maxime Ripard authored
A significant number of RaspberryPi drivers using the firmware don't have a phandle to it, so end up scanning the device tree to find a node with the firmware compatible. That code is duplicated everywhere, so let's introduce a helper instead. Acked-by:
-
- 27 Oct, 2022 1 commit
-
-
Pin-yen Lin authored
`pm_runtime_get_sync` may return 1 on success. Fix the `if` statement here to make the code less confusing, even though additional calls to `it6505_poweron` doesn't break anything when it's already powered. This was reported by Dan Carpenter <dan.carpenter@oracle.com> in https://lore.kernel.org/all/Y1fMCs6VnxbDcB41@kili/ Fixes: 10517777 ("drm/bridge: it6505: Adapt runtime power management framework") Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
