aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2022-12-01drm/modes: Use strscpy() to copy command-line mode nameMaxime Ripard1-1/+1
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 <[email protected]> Addresses-Coverity-ID: 1527354 ("Security best practices violations") Fixes: a7ab155397dd ("drm/modes: Switch to named mode descriptors") Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-01drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()Matti Vaittinen1-20/+3
Simplify using the devm_regulator_get_enable_optional(). Also drop the now unused struct member 'hdmi_supply'. Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/df0096b5aea2a18d1540cde379c5abf589ccd7c4.1669799805.git.mazziesaccount@gmail.com
2022-12-01drm/bridge: sii902x: Use devm_regulator_bulk_get_enable()Matti Vaittinen1-22/+4
Simplify using devm_regulator_bulk_get_enable() Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Robert Foss <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e6153c7beb2076b9ea13082b2024ec3296bc08bc.1669799805.git.mazziesaccount@gmail.com
2022-12-01drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420Guillaume BRUN1-3/+3
Cheap monitors sometimes advertise YUV modes they don't really have (HDMI specification mandates YUV support so even monitors without actual support will often wrongfully advertise it) which results in YUV matches and user forum complaints of a red tint to light colour display areas in common desktop environments. Moving the default RGB fall-back before YUV selection results in RGB mode matching in most cases, reducing complaints. Fixes: 6c3c719936da ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") Signed-off-by: Guillaume BRUN <[email protected]> Tested-by: Christian Hewitt <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/exynos: remove FOLL_FORCE usageDavid Hildenbrand1-1/+1
FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages using unpin_user_pages_dirty_lock(true), the assumption is that all these pages are writable. FOLL_FORCE in this case seems to be a legacy leftover. Let's just remove it. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: Inki Dae <[email protected]> Cc: Seung-Woo Kim <[email protected]> Cc: Kyungmin Park <[email protected]> Cc: David Airlie <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-11-30drm/etnaviv: remove FOLL_FORCE usageDavid Hildenbrand1-3/+5
GUP now supports reliable R/O long-term pinning in COW mappings, such that we break COW early. MAP_SHARED VMAs only use the shared zeropage so far in one corner case (DAXFS file with holes), which can be ignored because GUP does not support long-term pinning in fsdax (see check_vma_flags()). commit cd5297b0855f ("drm/etnaviv: Use FOLL_FORCE for userptr") documents that FOLL_FORCE | FOLL_WRITE was really only used for reliable R/O pinning. Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop using FOLL_FORCE, which is really only for ptrace access. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Christian Gmeiner <[email protected]> Cc: David Airlie <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-11-30Merge branch 'mm-hotfixes-stable' into mm-stableAndrew Morton1-0/+7
2022-11-30drm/amdgpu: temporarily disable broken Clang builds due to blown stack-frameLee Jones1-0/+7
Patch series "Fix a bunch of allmodconfig errors", v2. Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig builds. This leads to some interesting build failures when using Clang, each resolved in this set. With this set applied, I am able to obtain a successful allmodconfig Arm build. This patch (of 2): calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) architectures built with Clang (all released versions), whereby the stack frame gets blown up to well over 5k. This would cause an immediate kernel panic on most architectures. We'll revert this when the following bug report has been resolved: https://github.com/llvm/llvm-project/issues/41896. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: David Airlie <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Lee Jones <[email protected]> Cc: Leo Li <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: Rodrigo Siqueira <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Tom Rix <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-11-30drm/i915/guc: Use GuC submission API version numberJohn Harrison5-26/+137
The GuC firmware includes an extra version number to specify the submission API level. So use that rather than the main firmware version number for submission related checks. Also, while it is guaranteed that GuC version number components are only 8-bits in size, other firmwares do not have that restriction. So stop making assumptions about them generically fitting in a u16 individually, or in a u32 as a combined 8.8.8. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/uc: More refactoring of UC version numbersJohn Harrison3-49/+48
As a precursor to a coming change (for adding a GuC submission API version), abstract the UC version number into its own private structure separate to the firmware filename. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/uc: Rationalise delimiters in filename macrosJohn Harrison1-8/+8
The way delimiters (underscores and dots) were added to the UC filenames was different for different types of delimiter. Rationalise them to all be done the same way - implicitly in the concatenation macro rather than explicitly in the file name prefix. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/hdmi: SPD infoframe update for discreteTaylor, Clinton A1-1/+6
Replace integrated with discrete for dgfx platforms. v2: commit title reword (Jani) v3: use variable name i915 (Jani) v4: commit message reword (MattR) Cc: Jani Nikula <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Taylor, Clinton A <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/gt: Add dedicated MCR lockMatt Roper6-10/+101
We've been overloading uncore->lock to protect access to the MCR steering register. That's not really what uncore->lock is intended for, and it would be better if we didn't need to hold such a high-traffic spinlock for the whole sequence of (apply steering, access MCR register, restore steering). Let's create a dedicated MCR lock to protect the steering control register over this critical section and stop relying on the high-traffic uncore->lock. For now the new lock is a software lock. However some platforms (MTL and beyond) have a hardware-provided locking mechanism that can be used to serialize not only software accesses, but also hardware/firmware accesses as well; support for that hardware level lock will be added in a future patch. v2: - Use irqsave/irqrestore spinlock calls; platforms using execlist submission rather than GuC submission can perform MCR accesses in interrupt context because reset -> errordump happens in a tasklet. Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Balasubramani Vivekanandan <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/gt: Pass gt rather than uncore to lowest-level reads/writesMatt Roper1-8/+10
Passing the GT rather than uncore to the lowest level MCR read and write functions will make it easier to introduce dedicated MCR locking in a following patch. Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg()Matt Roper1-1/+1
The kerneldoc function name was not updated when this function was converted to a non-fw form. Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR register") Reported-by: kernel test robot <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915: fix TLB invalidation for Gen12 video and compute enginesAndrzej Hajda1-0/+5
In case of Gen12 video and compute engines, TLB_INV registers are masked - to modify one bit, corresponding bit in upper half of the register must be enabled, otherwise nothing happens. CVE: CVE-2022-4139 Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Andrzej Hajda <[email protected]> Acked-by: Daniel Vetter <[email protected]> Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store") Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
2022-11-30drm/bridge: ti-sn65dsi86: Fix output polarity setting bugQiqi Zhang1-2/+2
According to the description in ti-sn65dsi86's datasheet: CHA_HSYNC_POLARITY: 0 = Active High Pulse. Synchronization signal is high for the sync pulse width. (default) 1 = Active Low Pulse. Synchronization signal is low for the sync pulse width. CHA_VSYNC_POLARITY: 0 = Active High Pulse. Synchronization signal is high for the sync pulse width. (Default) 1 = Active Low Pulse. Synchronization signal is low for the sync pulse width. We should only set these bits when the polarity is negative. Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: Qiqi Zhang <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Tested-by: Douglas Anderson <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/dmc: Update DG2 DMC version to v2.08Gustavo Sousa1-2/+2
Release notes: 1. Fixes for Register noclaims and few restore. Fixes: c4cf059d9c2c ("drm/i915/dmc: Update DG2 DMC firmware to v2.07") Signed-off-by: Gustavo Sousa <[email protected]> Reviewed-by: Anusha Srivatsa <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6ee6692520133a14b0d0f3ddddf8c44783cfee06) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-30drm/i915/huc: always init the delayed load fenceDaniele Ceraolo Spurio1-13/+34
The fence is only tracking if the HuC load is in progress or not and doesn't distinguish between already loaded, not supported or disabled, so we can always initialize it to completed, no matter the actual support. We already do that for most platforms, but we skip it on GTs that lack VCS engines (e.g. MTL root GT), so fix that. Note that the cleanup is already unconditional. While at it, move the init/fini to helper functions. Fixes: 8e5f37828145 ("drm/i915/huc: fix leak of debug object in huc load fence on driver unload") Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: John Harrison <[email protected]> Cc: Alan Previn <[email protected]> Reviewed-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 14347a9c889fbdbae81e500f6c6e313f5d8e5271) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-30drm/i915/dmc: Update DG2 DMC version to v2.08Gustavo Sousa1-2/+2
Release notes: 1. Fixes for Register noclaims and few restore. Fixes: c4cf059d9c2c ("drm/i915/dmc: Update DG2 DMC firmware to v2.07") Signed-off-by: Gustavo Sousa <[email protected]> Reviewed-by: Anusha Srivatsa <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30drm/i915/dsc: Refactor dsc gen checksSwati Sharma3-10/+8
Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc member. Platforms supporting dsc has this flag enabled; no need of DISPLAY_VER() check. Also, simplified intel_dsc_source_support() based on above changes. Suggested-by: Jani Nikula <[email protected]> Signed-off-by: Swati Sharma <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30Merge tag 'drm-msm-next-2022-11-28' of ↵Dave Airlie12-66/+150
https://gitlab.freedesktop.org/drm/msm into drm-next msm-next for v6.2 (the gpu/gem bits) - Remove exclusive-fence hack that caused over-synchronization - Fix speed-bin detection vs. probe-defer - Enable clamp_to_idle on 7c3 - Improved hangcheck detection Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvT1h_S4d=YRgphgR8i7aMaxQaNW8mru7QaoUo9uiUk2A@mail.gmail.com
2022-11-30Merge tag 'drm-msm-display-for-6.2' of ↵Dave Airlie28-438/+530
https://gitlab.freedesktop.org/lumag/msm into drm-next drm/msm updates for 6.2 Core: - MSM_INFO_GET_FLAGS support - Cleaned up MSM IOMMU wrapper code DPU: - Added support for XR30 and P010 image formats - Reworked MDSS/DPU schema, added SM8250 MDSS bindings - Added Qualcomm SM6115 support DP: - Dropped unsane sanity checks DSI: - Fix calculation of DSC pps payload DSI PHY: - DSI PHY support for QCM2290 HDMI: - Reworked dev init path Signed-off-by: Dave Airlie <[email protected]> From: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30Merge tag 'amd-drm-next-6.2-2022-11-25' of ↵Dave Airlie65-216/+896
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.2-2022-11-25: amdgpu: - Old GCC fix - GFX11 fixes - PSP suspend/resume fix - PCI ref count fix - DC KASAN fix - DCN 3.2.x fixes - Dell platform suspend/resume fixes - DCN 3.1.4 fixes - RAS fixes - SMU 13.x fixes - Flex array changes - VCN 4.0 RAS updates - Add missing licsense to some files - Documentation updates - SR-IOV fixes - DP MST DSC fix amdkfd: - Fix topology locking in error case Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30Merge tag 'drm/tegra/for-6.2-rc1' of ↵Dave Airlie14-76/+319
https://gitlab.freedesktop.org/drm/tegra into drm-next drm/tegra: Changes for v6.2-rc1 This contains a bunch of cleanups across the board as well as support for the NVDEC hardware found on the Tegra234 SoC. Signed-off-by: Dave Airlie <[email protected]> From: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-30Merge tag 'drm-accel-2022-11-22' of ↵Dave Airlie4-36/+92
https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel into drm-next This tag contains the patches that add the new compute acceleration subsystem, which is part of the DRM subsystem. The patches: - Add a new directory at drivers/accel. - Add a new major (261) for compute accelerators. - Add a new DRM minor type for compute accelerators. - Integrate the accel core code with DRM core code. - Add documentation for the accel subsystem. Signed-off-by: Dave Airlie <[email protected]> some acks from the list (some are in the patch series): Acked-by: Daniel Stone <[email protected]> Acked-by: Sonal Santan <[email protected]> Acked-by: Maxime Ripard <[email protected]> Acked-by: Jacek Lawrynowicz <[email protected]> Tested-by: Jacek Lawrynowicz <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> From: Oded Gabbay <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/vkms: change min cursor size to accept smaller valuesAlaa Emad1-2/+2
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 <[email protected]> Reviewed-by: Melissa Wen <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/vkms: Fix null-ptr-deref in vkms_release()Yuan Can1-1/+2
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-gd465bff130bf #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: 6c234fe37c57 ("drm/vkms: Implement CRC debugfs API") Signed-off-by: Yuan Can <[email protected]> Reviewed-by: Melissa Wen <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/vkms: Fix memory leak in vkms_init()Yuan Can1-1/+6
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: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: Yuan Can <[email protected]> Reviewed-by: Melissa Wen <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/panel-samsung-atna33xc20: Extend autosuspend delayDrew Davenport1-1/+1
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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.5.I96ce2a565ff893eddcbee70174c991179311a3ae@changeid
2022-11-29drm/bridge/parade-ps8640: Extend autosuspendDrew Davenport1-2/+2
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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.4.If6153da69ec4bc9e83d5f095ef6e6b07283940a5@changeid
2022-11-29drm/panel-simple: Use ktime_get_boottime for delaysDrew Davenport1-3/+3
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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.3.Iebd9f79aba0a62015fd2383fe6986c2d6fe12cfd@changeid
2022-11-29drm/panel-samsung-atna33xc20: Use ktime_get_boottime for delaysDrew Davenport1-4/+4
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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.2.Iebd9f79aba0a62015fd2383fe6986c2d6fe12cfd@changeid
2022-11-29drm/panel-edp: Use ktime_get_boottime for delaysDrew Davenport1-4/+4
ktime_get is based on CLOCK_MONOTONIC which stops on suspend. On suspend, the time that the panel was powerd off is recorded with ktime_get, and on resume this time is compared to the current ktime_get time to determine if the driver should wait for the panel to power down completely before re-enabling it. Because we're using ktime_get, this delay doesn't account for the time that the device is suspended, during which the power down delay may have already elapsed. Change to use ktime_get_boottime throughout, which uses CLOCK_BOOTTIME which does not stop when suspended. This 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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.1.I51639dc112bbbe27259df6bdad56dbabd655d91a@changeid
2022-11-29drm/bridge: ti-sn65dsi86: Convert to i2c's .probe_new()Uwe Kleine-König1-3/+2
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/i915/dsi: fix VBT send packet port selection for dual link DSIMikko Kovanen1-2/+2
intel_dsi->ports contains bitmask of enabled ports and correspondingly logic for selecting port for VBT packet sending must use port specific bitmask when deciding appropriate port. Fixes: 08c59dde71b7 ("drm/i915/dsi: fix VBT send packet port selection for ICL+") Cc: [email protected] Signed-off-by: Mikko Kovanen <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/DBBPR09MB466592B16885D99ABBF2393A91119@DBBPR09MB4665.eurprd09.prod.outlook.com (cherry picked from commit 8d58bb7991c45f6b60710cc04c9498c6ea96db90) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-29drm/i915/bios: fix a memory leak in generate_lfp_data_ptrsXia Fukun1-1/+1
When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs. However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. Fixes: a87d0a847607 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them") Signed-off-by: Xia Fukun <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-29drm/i915: Never return 0 if not all requests retiredJanusz Krzysztofik1-1/+1
Users of intel_gt_retire_requests_timeout() expect 0 return value on success. However, we have no protection from passing back 0 potentially returned by a call to dma_fence_wait_timeout() when it succedes right after its timeout has expired. Replace 0 with -ETIME before potentially using the timeout value as return code, so -ETIME is returned if there are still some requests not retired after timeout, 0 otherwise. v3: Use conditional expression, more compact but also better reflecting intention standing behind the change. v2: Move the added lines down so flush_submission() is not affected. Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request") Signed-off-by: Janusz Krzysztofik <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Cc: [email protected] # v5.5+ Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f301a29f143760ce8d3d6b6a8436d45d3448cde6) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-29drm/i915: Fix negative value passed as remaining timeJanusz Krzysztofik1-2/+7
Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC") extended the API of intel_gt_retire_requests_timeout() with an extra argument 'remaining_timeout', intended for passing back unconsumed portion of requested timeout when 0 (success) is returned. However, when request retirement happens to succeed despite an error returned by a call to dma_fence_wait_timeout(), that error code (a negative value) is passed back instead of remaining time. If we then pass that negative value forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG will be triggered. If request retirement succeeds but an error code is passed back via remaininig_timeout, we may have no clue on how much of the initial timeout might have been left for spending it on waiting for GuC to become idle. OTOH, since all pending requests have been successfully retired, that error code has been already ignored by intel_gt_retire_requests_timeout(), then we shouldn't fail. Assume no more time has been left on error and pass 0 timeout value to intel_uc_wait_for_idle() to give it a chance to return success if GuC is already idle. v3: Don't fail on any error passed back via remaining_timeout. v2: Fix the issue on the caller side, not the provider. Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC") Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: [email protected] # v5.15+ Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f235dbd5b768e238d365fd05d92de5a32abc1c1f) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-29drm/i915/huc: fix leak of debug object in huc load fence on driver unloadDaniele Ceraolo Spurio2-5/+8
The fence is always initialized in huc_init_early, but the cleanup in huc_fini is only being run if HuC is enabled. This causes a leaking of the debug object when HuC is disabled/not supported, which can in turn trigger a warning if we try to register a new debug offset at the same address on driver reload. To fix the issue, make sure to always run the cleanup code. Reported-by: Tvrtko Ursulin <[email protected]> Reported-by: Brian Norris <[email protected]> Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence") Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Brian Norris <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Tested-by: Brian Norris <[email protected]> Reviewed-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 02224691cb0f367acb476911bddfa21e2d596ca5) Signed-off-by: Rodrigo Vivi <[email protected]>
2022-11-29drm/bridge: megachips: Fix error handling in i2c_register_driver()Yuan Can1-1/+5
A problem about insmod megachips-stdpxxxx-ge-b850v3-fw.ko failed is triggered with the following log given: [ 4497.981497] Error: Driver 'stdp4028-ge-b850v3-fw' is already registered, aborting... insmod: ERROR: could not insert module megachips-stdpxxxx-ge-b850v3-fw.ko: Device or resource busy The reason is that stdpxxxx_ge_b850v3_init() returns i2c_add_driver() directly without checking its return value, if i2c_add_driver() failed, it returns without calling i2c_del_driver() on the previous i2c driver, resulting the megachips-stdpxxxx-ge-b850v3-fw can never be installed later. A simple call graph is shown as below: stdpxxxx_ge_b850v3_init() i2c_add_driver(&stdp4028_ge_b850v3_fw_driver) i2c_add_driver(&stdp2690_ge_b850v3_fw_driver) i2c_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without delete stdp4028_ge_b850v3_fw_driver Fix by calling i2c_del_driver() on stdp4028_ge_b850v3_fw_driver when i2c_add_driver() returns error. Fixes: fcfa0ddc18ed ("drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)") Signed-off-by: Yuan Can <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Tested-by: Ian Ray <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/i915/huc: always init the delayed load fenceDaniele Ceraolo Spurio1-13/+34
The fence is only tracking if the HuC load is in progress or not and doesn't distinguish between already loaded, not supported or disabled, so we can always initialize it to completed, no matter the actual support. We already do that for most platforms, but we skip it on GTs that lack VCS engines (e.g. MTL root GT), so fix that. Note that the cleanup is already unconditional. While at it, move the init/fini to helper functions. Fixes: 02224691cb0f ("drm/i915/huc: fix leak of debug object in huc load fence on driver unload") Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: John Harrison <[email protected]> Cc: Alan Previn <[email protected]> Reviewed-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-29drm/amdgpu: Fix logic errorKonstantin Meskhidze1-2/+2
This commit fixes logic error in function 'amdgpu_hw_ip_info': - value 'uvd' might be 'vcn'. Signed-off-by: Konstantin Meskhidze <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amdkfd: Fix memory leakageKonstantin Meskhidze1-1/+1
This patch fixes potential memory leakage and seg fault in _gpuvm_import_dmabuf() function Fixes: d4ec4bdc0bd5 ("drm/amdkfd: Allow access for mmapping KFD BOs") Signed-off-by: Konstantin Meskhidze <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()Xiongfeng Wang1-0/+1
As comment of pci_get_class() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL. If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we need to call pci_dev_put() to decrease the refcount. Add the missing pci_dev_put() to avoid refcount leak. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Signed-off-by: Xiongfeng Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amdgpu: use dev_dbg to print messages in runtime cycleGuchun Chen2-2/+2
Runtime PM can happen pretty frequently, as these printings may be annoyed, switch to dev_dbg. Suggested-by: Lijo Lazar <[email protected]> Signed-off-by: Guchun Chen <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amd/display: Fix DTBCLK disable requests and SRC_SEL programmingAlvin Lee2-6/+2
[Description] - When transitioning FRL / DP2 is not required, we will always request DTBCLK = 0Mhz, but PMFW returns the min freq - This causes us to make DTBCLK requests every time we call optimize after transitioning from FRL to non-FRL - If DTBCLK is not required, request the min instead (then we only need to make 1 extra request at boot time) - Also when programming PIPE_DTO_SRC_SEL, don't programming for DP first, just programming once for the required selection (programming DP on an HDMI connection then switching back causes corruption) Reviewed-by: Dillon Varone <[email protected]> Acked-by: Jasdeep Dhillon <[email protected]> Signed-off-by: Alvin Lee <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amd/display: Create debugfs to tell if connector is DPIA linkStylon Wang1-1/+22
[Why] Tests need to tell if display is connected via USB4 DPIA link. Currently this is only possible via analyzing dmesg logs. [How] Create a per-connector debugfs entry to report if the link is tunneled via USB4 DPIA. Reviewed-by: Wayne Lin <[email protected]> Acked-by: Jasdeep Dhillon <[email protected]> Signed-off-by: Stylon Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amd/display: program output tf when requiredDillon Varone1-1/+4
[Description] Output transfer function must be programmed per pipe as part of a front end update when the plane changes, or output transfer function changes for a given plane. Reviewed-by: Alvin Lee <[email protected]> Acked-by: Jasdeep Dhillon <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-11-29drm/amd/display: Use DCC meta pitch for MALL allocation requirementsDillon Varone2-6/+11
[Description] Calculations for determining DCC meta size should be pitch*height*bpp/256. Reviewed-by: Alvin Lee <[email protected]> Acked-by: Jasdeep Dhillon <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.