- Jan 14, 2022
-
-
Daniel Vetter authored
Merge tag 'drm-misc-next-fixes-2022-01-14' of git://anongit.freedesktop.org/drm/drm-misc into drm-next * atomic helpers: Fix error messages * mipi-dbi: Fix buffer mapping Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YeGHu7qU92pjuQOn@linux-uq9g
-
git://anongit.freedesktop.org/drm/drm-miscDaniel Vetter authored
Two DT bindings fixes for meson, a device refcounting fix for sun4i, a probe fix for vga16fb, a locking fix for the CMA dma-buf heap and a compilation fix for ttm. Signed-off-by:
-
Thomas Zimmermann authored
Set the source-buffer address after mapping the buffer into the kernel's address space. Makes MIPI DBI helpers work again. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Fixes: c47160d8 ("drm/mipi-dbi: Remove dependency on GEM CMA helper library") Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Reported-by:
-
Claudio Suarez authored
The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c") fails when the drm_device cannot be found in the parameter plane_state->crtc. Fix it using plane_state->plane. Reported-by:kernel test robot <oliver.sang@intel.com> Fixes: 6e22dc35 ("drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c") Signed-off-by:
Claudio Suarez <cssk@net-c.es> [danvet: fix Fixes: line] Signed-off-by:
-
Daniel Vetter authored
Merge tag 'drm-misc-next-fixes-2022-01-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next * Fix use of CRTC state's active vs enable in atomic helper Signed-off-by:
-
Daniel Vetter authored
Merge tag 'drm-intel-next-fixes-2022-01-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Hold runtime PM wakelock during PXP unbind (Juston Li) - Three fixes for the TTM backend fault handling (Matthew Auld) - Make sure to unmap when purging in the TTM backend (Matthew Auld) Signed-off-by:
-
Johannes Berg authored
Even if it's probably not really useful, it can get selected by e.g. randconfig builds, and then failing to compile is an annoyance. Unfortunately, it's hard to fix in Kconfig, since DRM_TTM is selected by many things that don't really depend on any specific architecture, and just depend on PCI (which is indeed now available in ARCH=um via simulation/emulation). Fix this in the code instead by just ifdef'ing the relevant two lines that depend on "real X86". Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- Jan 13, 2022
-
-
Weizhao Ouyang authored
Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt and vaddr. Fixes: a5d2d29e ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by:
Weizhao Ouyang <o451686892@gmail.com> Acked-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220104073545.124244-1-o451686892@gmail.com
-
- Jan 12, 2022
-
-
Javier Martinez Canillas authored
The vga16fb framebuffer driver only supports Enhanced Graphics Adapter (EGA) and Video Graphics Array (VGA) 16 color graphic cards. But it doesn't check if the adapter is one of those or if a VGA16 mode is used. This means that the driver will be probed even if a VESA BIOS Extensions (VBE) or Graphics Output Protocol (GOP) interface is used. This issue has been present for a long time but it was only exposed by commit d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") since the platform device registration to match the {vesa,efi}fb drivers is done later as a consequence of that change. All non-x86 architectures though treat orig_video_isVGA as a boolean so only do the supported video mode check for x86 and not for other arches. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215001 Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by:
Kris Karas <bugs-a21@moonlit-rail.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Tested-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220110095625.278836-3-javierm@redhat.com
-
- Jan 11, 2022
-
-
Liu Ying authored
Actual hardware state of CRTC is controlled by the member 'active' in struct drm_crtc_state instead of the member 'enable', according to the kernel doc of the member 'enable'. In fact, the drm client modeset and atomic helpers are using the member 'active' to do the control. Referencing the member 'enable' of new_crtc_state, the function crtc_needs_disable() may fail to reflect if CRTC needs disable in self refresh mode, e.g., when the framebuffer emulation will be blanked through the client modeset helper with the next commit, the member 'enable' of new_crtc_state is still true while the member 'active' is false, hence the relevant potential encoder and bridges won't be disabled. So, let's check new_crtc_state->active to determine if CRTC needs disable in self refresh mode instead of new_crtc_state->enable. Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers") Cc: Sean Paul <seanpaul@chromium.org> Cc: Rob Clark <robdclark@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
-
Miaoqian Lin authored
The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling path. Fixes: 9bf37977 ("drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
- Jan 10, 2022
-
-
Matthew Auld authored
Purging can happen during swapping out, or directly invoked with the madvise ioctl. In such cases this doesn't involve a ttm move, which skips umapping the object. v2(Thomas): - add ttm_truncate helper, and just call into i915_ttm_move_notify() to handle the unmapping step Fixes: 213d5092 ("drm/i915/ttm: Introduce a TTM i915 gem object backend") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-4-matthew.auld@intel.com (cherry picked from commit ab4911b7 ) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Matthew Auld authored
Ensure we call ttm_bo_unmap_virtual when releasing the pages. Importantly this should now handle the ttm swapping case, and all other places that already call into i915_ttm_move_notify(). v2: fix up the selftest Fixes: cf3e3e86 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by:
-
Matthew Auld authored
Don't attempt to fault and re-populate purged objects. By some fluke this passes the dontneed-after-mmap IGT, but for the wrong reasons. Fixes: cf3e3e86 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by:
-
Matthew Auld authored
The TTM backend is in theory the only user here(also purge should only be called once we have dropped the pages), where it is setup at object creation and is only removed once the object is destroyed. Also resetting the node here might be iffy since the ttm fault handler uses the stored fake offset to determine the page offset within the pages array. This also blows up in the dontneed-before-mmap test, since the expectation is that the vma_node will live on, until the object is destroyed: <2> [749.062902] kernel BUG at drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943! <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted: G U W 5.16.0-rc8-CI-CI_DRM_11046+ #1 <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390 Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019 <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d [i915] <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a a0 e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00 e8 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6 c0 23 4e a0 48 <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246 <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX: 0000000000000006 <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009 <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09: 0000000000000001 <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12: ffff888112a1a000 <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15: ffff888112a1a000 <4> [749.063074] FS: 00007f6e5fcad500(0000) GS:ffff8884ad600000(0000) knlGS:0000000000000000 <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4: 00000000003706f0 <4> [749.063085] Call Trace: <4> [749.063087] <TASK> <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915] <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915] <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915] <4> [749.063325] drm_ioctl_kernel+0xae/0x140 <4> [749.063330] drm_ioctl+0x201/0x3d0 <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915] <4> [749.063409] ? do_user_addr_fault+0x200/0x670 <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0 <4> [749.063419] do_syscall_64+0x3a/0xb0 <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae <4> [749.063428] RIP: 0033:0x7f6e5f100317 Testcase: igt/gem_madvise/dontneed-before-mmap Fixes: cf3e3e86 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by:
-
Juston Li authored
Similar to commit b8d84368 ("drm/i915/gt: Hold RPM wakelock during PXP suspend") but to fix the same warning for unbind during shutdown: ------------[ cut here ]------------ RPM wakelock ref not held during HW access WARNING: CPU: 0 PID: 4139 at drivers/gpu/drm/i915/intel_runtime_pm.h:115 gen12_fwtable_write32+0x1b7/0 Modules linked in: 8021q ccm rfcomm cmac algif_hash algif_skcipher af_alg uinput snd_hda_codec_hdmi vf industrialio iwl7000_mac80211 cros_ec_sensorhub lzo_rle lzo_compress zram iwlwifi cfg80211 joydev CPU: 0 PID: 4139 Comm: halt Tainted: G U W 5.10.84 #13 344e11e079c4a03940d949e537eab645f6 RIP: 0010:gen12_fwtable_write32+0x1b7/0x200 Code: 48 c7 c7 fc b3 b5 89 31 c0 e8 2c f3 ad ff 0f 0b e9 04 ff ff ff c6 05 71 e9 1d 01 01 48 c7 c7 d67 RSP: 0018:ffffa09ec0bb3bb0 EFLAGS: 00010246 RAX: 12dde97bbd260300 RBX: 00000000000320f0 RCX: ffffffff89e60ea0 RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: ffffffff89e60e70 RBP: ffffa09ec0bb3bd8 R08:...
-
- Jan 03, 2022
-
-
Alexander Stein authored
This is used in meson-gx and meson-g12. Add the property to the binding. This fixes the dtschema warning: hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
Alexander Stein <alexander.stein@mailbox.org> Fixes: 376bf52d ("dt-bindings: display: amlogic, meson-dw-hdmi: convert to yaml") Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Alexander Stein authored
This property was already mentioned in the old textual bindings amlogic,meson-vpu.txt, but got dropped during conversion. Adding it back similar to amlogic,gx-vdec.yaml. Fixes: 6b9ebf1e ("dt-bindings: display: amlogic, meson-vpu: convert to yaml") Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
- Dec 30, 2021
-
-
ssh://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-5.17-2021-12-30: amdgpu: - Suspend/resume fixes - Fence fix - Misc code cleanups - IP discovery fixes - SRIOV fixes - RAS fixes - GMC 8 VRAM detection fix - FRU fixes for Aldebaran - Display fixes amdkfd: - SVM fixes - IP discovery fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211230141032.613596-1-alexander.deucher@amd.com
-
Alex Deucher authored
Chips with no display hardware should return false for DC support. v2: drop Arcturus and Aldebaran Fixes: f7f12b25 ("drm/amdgpu: default to true in amdgpu_device_asic_has_dc_support") Reviewed-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Reported-by:
Tareque Md.Hanif <tarequemd.hanif@yahoo.com> Signed-off-by:
-
José Expósito authored
The "plane_state" pointer was access before checking if it was NULL. Avoid a possible NULL pointer dereference by accessing the plane address after the check. Addresses-Coverity-ID: 1493892 ("Dereference before null check") Fixes: 3f68c01b ("drm/amd/display: add cyan_skillfish display support") Signed-off-by:José Expósito <jose.exposito89@gmail.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Alex Deucher authored
If the platform suspend happens to fail and the power rail is not turned off, the GPU will be in an unknown state on resume, so reset the asic so that it will be in a known good state on resume even if the platform suspend failed. v2: handle s0ix Acked-by:
Luben Tuikov <luben.tuikov@amd.com> Acked-by:
-
Evan Quan authored
By setting mp1_state as PP_MP1_STATE_UNLOAD, MP1 will do some proper cleanups and put itself into a state ready for PNP. That can workaround some random resuming failure observed on BOCO capable platforms. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Yizhuo Zhai authored
In function enable_stream_features(), the variable "old_downspread.raw" could be uninitialized if core_link_read_dpcd() fails, however, it is used in the later if statement, and further, core_link_write_dpcd() may write random value, which is potentially unsafe. Fixes: 6016cd9d ("drm/amd/display: add helper for enabling mst stream features") Cc: stable@vger.kernel.org Signed-off-by:
Yizhuo Zhai <yzhai003@ucr.edu> Signed-off-by:
-
Alex Deucher authored
It's not only supported by HG/PX laptops. It's supported by all dGPUs which supports BOCO/BACO functionality (runtime D3). BOCO - Bus Off, Chip Off. The entire chip is powered off. This is controlled by ACPI. BACO - Bus Active, Chip Off. The chip still shows up on the PCI bus, but the device itself is powered down. v2: fix missed HG/PX reference Reviewed-by: -
Marina Nikolic authored
== Description == Setting values of pm attributes through sysfs should not be allowed in SRIOV mode. These calls will not be processed by FW anyway, but error handling on sysfs level should be improved. == Changes == This patch prohibits performing of all set commands in SRIOV mode on sysfs level. It offers better error handling as calls that are not allowed will not be propagated further. == Test == Writing to any sysfs file in passthrough mode will succeed. Writing to any sysfs file in ONEVF mode will yield error: "calling process does not have sufficient permission to execute a command". Signed-off-by:
Marina Nikolic <Marina.Nikolic@amd.com> Acked-by:
-
Tao Zhou authored
Otherwise the RAS error count couldn't be queried from sysfs. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Stanley.Yang <Stanley.Yang@amd.com> Signed-off-by:
-
Guchun Chen authored
A minor typo. Signed-off-by:
-
Wenjing Liu authored
[why] When reboot the link res map should be persisted. So during boot up, driver will look at the map to determine which link should take priority to use certain link res. This is to ensure that link res remains unshuffled after a reboot. Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Wenjing Liu <wenjing.liu@amd.com> Signed-off-by:
-
Wenjing Liu authored
[why] When there are more DP2.0 RXs connected than the number HPO DP link encoders we have, we need to dynamically allocate HPO DP link encoder to the port that needs it. [how] Only allocate HPO DP link encoder when it is needed. Tested-by:
-
Wenjing Liu authored
[why] Update all accesses to use hpo dp link encoder through link resource only. Tested-by:
-
Wenjing Liu authored
[why] This commit is to populate link res in preparation of the next commit. The next commit will replace all existing code to use link res instead Tested-by:
-
Wenjing Liu authored
[why] There will be a series of re-arch changes in Link Resource Management. They are more and more muxable link resource objects and the resource is insufficient for a one to one allocation to all links created. Therefore a link resource sharing logic is required to determine which link should use certain link resource. This commit is the first one in this series that starts by defining a link resource struct, this struct will be available to all interfaces that need to perform link programming sequence. In later commits, we will granduately decouple link resource objects out of dc link. So instead of access a link resource from dc link. Current link's resource can be accessible through pipe_ctx->link_res during commit, or by calling dc_link_get_cur_link_res function with current link passed in after commit. Tested-by:
-
Aric Cyr authored
This version brings along the following: - Fixes and improvements in the LTTPR code - Improve z-state - Fix null pointer check - Improve communication with s0i2 - Update multiple-display split policy - Add missing registers Tested-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
-
Anthony Koo authored
Tested-by:
Anthony Koo <Anthony.Koo@amd.com> Signed-off-by:
-
Martin Leung authored
Undo ODM Combine regression causing causing pipe allocation issues. Tested-by:
Martin Leung <Martin.Leung@amd.com> Signed-off-by:
-
Wesley Chalmers authored
[WHY] These registers are currently missing from the DCN303 header files Tested-by:
George Shen <George.Shen@amd.com> Acked-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Signed-off-by:
-
Angus Wang authored
[WHY] Current implementation of pipe split policy prevents pipe split with multiple displays connected, which caused the MCLK speed to be stuck at max [HOW] Changed the pipe split policies so that pipe split is allowed for multi-display configurations Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1522 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1709 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1655 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Tested-by:
Angus Wang <angus.wang@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] We'll exit optimized power state to do link detection but we won't enter back into the optimized power state. This could potentially block s2idle entry depending on the sequencing, but it also means we're losing some power during the transition period. [How] Hook up the handler like DCN21. It was also missed like the exit_optimized_pwr_state callback. Fixes: 64b1d0e8 ("drm/amd/display: Add DCN3.1 HWSEQ") Tested-by:
Eric Yang <Eric.Yang2@amd.com> Acked-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
George Shen authored
[Why] DP spec specifies that DPRX shall use the read interval in the TRAINING_AUX_RD_INTERVAL_PHY_REPEATER LTTPR DPCD register. This register's bit definition is the same as the AUX read interval register for DPRX. [How} Remove logic which forces AUX read interval to 100us for repeaters when in LTTPR non-transparent mode. Tested-by:
-
