- 02 Nov, 2022 1 commit
-
-
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:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221031113350.4180975-1-cuigaosheng1@huawei.comSigned-off-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:
Yuan Can <yuancan@huawei.com> 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:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221026125246.3188260-1-a.fatoum@pengutronix.de
-
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 2 commits
-
-
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:
-
Somalapuram Amaranath authored
Change ttm_resource structure from num_pages to size_t size in bytes. v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages v1 -> v2: change bo->resource->size to bo->base.size at some places v1 -> v2: remove the local variable v1 -> v2: cleanup cmp_size_smaller_first() v2 -> v3: adding missing PFN_UP in ttm_bo_vm_fault_reserved Signed-off-by:
Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221027091237.983582-1-Amaranath.Somalapuram@amd.comReviewed-by:
-
- 26 Oct, 2022 16 commits
-
-
Jani Nikula authored
Convert to drm_kms_dbg/drm_err where possible, and reference the connector using [CONNECTOR:%d:%s]. Pass connectors around a bit more to enable this. Where this is not possible, unify the rest of the debugs to DRM_DEBUG_KMS. Rewrite tile debug logging to one line while at it. v2: - Use [CONNECTOR:%d:%s] throughout (Ville) - Tile debug logging revamp - Pass connector around a bit more Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e48346bfe09a632d5a5faa55e3c161b196cf21e8.1666614699.git.jani.nikula@intel.com
-
Jani Nikula authored
Reference the connector using [CONNECTOR:%d:%s] in existing device based debug logging. Signed-off-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/5884410682bcbc032de4d3af8562c0b271edaa7f.1666614699.git.jani.nikula@intel.com
-
Jani Nikula authored
Conform to device specific logging. v2: Include [CONNECTOR:%d:%s] (Ville) Signed-off-by:
-
Jani Nikula authored
The EDID loader is internal to drm, not for drivers. Signed-off-by:
-
Jani Nikula authored
There's a lot going on here, but the main thing is switching the firmware EDID loader to use struct drm_edid. Unfortunately, it's difficult to reasonably split to smaller pieces. Convert the EDID loader to struct drm_edid. There's a functional change in validation; it no longer tries to fix errors or filter invalid blocks. It's stricter in this sense. Hopefully this will not be an issue. As a by-product, this change also allows HF-EEODB extended EDIDs to be passed via override/firmware EDID. Signed-off-by:
-
Jani Nikula authored
Follow the usual naming convention by file name. Signed-off-by:
-
Jani Nikula authored
Stop passing around something that's readily available in connector->name. Signed-off-by:
-
Jani Nikula authored
Having the EDID override debugfs directly update the EDID property is problematic. The update is partial only. The driver has no way of knowing it's been updated. Mode list is not updated. It's an inconsistent state. Detach debugfs EDID override from the property update completely. Only set and reset a separate override EDID copy from debugfs, and have it take effect only at detect (via EDID read). The copy is at connector->edid_override, protected by connector->edid_override_mutex. This also brings override EDID closer to firmware EDID in behaviour. Add validation of the override EDID which we completely lacked. Note that IGT already forces a detect whenever tests update the override EDID. v2: Add locking (Ville) Signed-off-by:
-
Jani Nikula authored
We've lacked a function for immutable validity check on drm_edid. Add one. Signed-off-by:
-
Jani Nikula authored
Split the drm_edid block count helper to a base version that reports the block count indicated by EDID contents, and another on top that limits the block count based on size allocated for the EDID. Signed-off-by:
-
Jani Nikula authored
Follow the naming of both EDID override functions as well as drm_edid_connector_update(). This also matches better what the function does; a combination of EDID property update and add modes. Indeed it should later be converted to call drm_edid_connector_update(). Signed-off-by:
-
Jani Nikula authored
Add a function to dump the override EDID in debugfs. This hides the override EDID management better in drm_edid.c. Signed-off-by:
-
Jani Nikula authored
It's useful debugging information to know if and when an override EDID was set or reset. Signed-off-by:
-
Jani Nikula authored
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Xinhui Pan <Xinhui.Pan@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/c901869ff8a4e3aebc4abec99c7dd7b4c224f6e6.1666614699.git.jani.nikula@intel.com
-
Jani Nikula authored
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. The check for override_edid was added in commit 30190629 ("drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set") to facilitate mode list cross-checking against modes in override EDID when the connector in question isn't even connected. The dual mode detect fallback would do VBT based limiting in this case. Instead of override EDID, check for connector forcing in the fallback. v2: Simply use !connector->force (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
For normal connector detect, there's really no point in trying dual mode detect if the connector is disconnected. We can simplify the detect sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only called when EDID is present, we can drop the has_edid parameter. The functional effect is speeding up disconnected connector detection ever so slightly, and, combined with firmware EDID, also stop logging about assuming dual mode adaptor. It's a bit subtle, but this will also skip dual mode detect if the connector is force connected and a) there's no EDID of any kind, normal or override/firmware or b) there's EDID but it does not indicate digital. These are corner cases no matter what, and arguably forcing should not be limited by dual mode detect. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 25 Oct, 2022 2 commits
-
-
Zack Rusin authored
Fixes a warning about extra docs about a function argument that has been removed a while back: drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3888: warning: Excess function parameter 'sync_file' description in 'vmw_execbuf_copy_fence_user' Fixes: a0f90c88 ("drm/vmwgfx: Fix stale file descriptors on failed usercopy") Signed-off-by:
Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-18-zack@kde.org
-
Zack Rusin authored
It's important to get the initial size of cotables right because otherwise every app needs to start with a synchronous cotable resize. This has an measurable impact on system wide performance but is not relevant for long running single full screen apps for which the cotable resizes will happen early in the lifecycle and will continue running just fine. To eliminate the initial cotable resizes match the initial sizes to what the userspace expects. The actual result of the patch is simply setting the initial size of two of the cotables to a size that will align them to two pages instead of one. For a piglit run, before: name | total | per frame | per sec vmw_cotable_resize | 1405 | 0.12 | 1.58 vmw_execbuf_ioctl | 290805 | 25.43 | 326.05 After: name | total | per frame | per sec vmw_cotable_resize | 4 | 0.00 | 0.00 vmw_execbuf_ioctl | 281673 | 25.10 | 274.68 Signed-off-by:
-
