aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-02-28drm/virtio: implement prime exportGerd Hoffmann3-0/+15
Just run drm_prime_pages_to_sg() on the ttm pages list to get an sg_table for export. The pages list is created at object initialization time, so there should be no need to handle an unpopulated page list. Add a sanity check nevertheless. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190227144441.6755-4-kraxel@redhat.com
2019-02-28drm/virtio: remove prime pin/unpin callbacks.Gerd Hoffmann3-15/+0
virtio-gpu objects never move around, so effectively they are pinned all the time. Therefore we don't need the (optional) pin/unpin callbacks. Remove them. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190227144441.6755-3-kraxel@redhat.com
2019-02-28drm/virtio: implement prime mmapGerd Hoffmann1-2/+5
Sync gem vm_node.start with ttm vm_node.start, then we can just call drm_gem_prime_mmap(). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190227144441.6755-2-kraxel@redhat.com
2019-02-28drm/bochs: Fix the ID mismatch errorAlistair Francis1-0/+4
When running RISC-V QEMU with the Bochs device attached via PCIe the probe of the Bochs device fails with: [drm:bochs_hw_init] *ERROR* ID mismatch This was introduced by this commit: 7780eb9ce8 bochs: convert to drm_dev_register To fix the error we ensure that pci_enable_device() is called before bochs_load(). Fixes: 7780eb9ce80f ("bochs: convert to drm_dev_register") Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reported-by: David Abdurachmanov <david.abdurachmanov@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190221003231.31625-1-alistair.francis@wdc.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-02-28drm: Block fb changes for async plane updatesNicholas Kazlauskas1-0/+9
The prepare_fb call always happens on new_plane_state. The drm_atomic_helper_cleanup_planes checks to see if plane state pointer has changed when deciding to call cleanup_fb on either the new_plane_state or the old_plane_state. For a non-async atomic commit the state pointer is swapped, so this helper calls prepare_fb on the new_plane_state and cleanup_fb on the old_plane_state. This makes sense, since we want to prepare the framebuffer we are going to use and cleanup the the framebuffer we are no longer using. For the async atomic update helpers this differs. The async atomic update helpers perform in-place updates on the existing state. They call drm_atomic_helper_cleanup_planes but the state pointer is not swapped. This means that prepare_fb is called on the new_plane_state and cleanup_fb is called on the new_plane_state (not the old). In the case where old_plane_state->fb == new_plane_state->fb then there should be no behavioral difference between an async update and a non-async commit. But there are issues that arise when old_plane_state->fb != new_plane_state->fb. The first is that the new_plane_state->fb is immediately cleaned up after it has been prepared, so we're using a fb that we shouldn't be. The second occurs during a sequence of async atomic updates and non-async regular atomic commits. Suppose there are two framebuffers being interleaved in a double-buffering scenario, fb1 and fb2: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 We call cleanup_fb on fb2 twice in this example scenario, and any further use will result in use-after-free. The simple fix to this problem is to block framebuffer changes in the drm_atomic_helper_async_check function for now. v2: Move check by itself, add a FIXME (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: <stable@vger.kernel.org> # v4.14+ Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/275364/ Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-02-27drm/amdgpu: clear PDs/PTs only after initializing themChristian König1-5/+6
Clear the VM PDs/PTs only after initializing all the structures. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/display: Pass app_tf by value rather than by referenceNathan Chancellor2-5/+4
Clang warns when an expression that equals zero is used as a null pointer constant (in lieu of NULL): drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3: warning: expression which evaluates to zero treated as a null pointer constant of type 'const enum color_transfer_func *' [-Wnon-literal-null-conversion] TRANSFER_FUNC_UNKNOWN, ^~~~~~~~~~~~~~~~~~~~~ 1 warning generated. This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR properties") and it could be solved by using NULL instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a pointer. However, after looking into it, there doesn't appear to be a good reason to pass app_tf by reference as it is never mutated along the way. This is the only code path in which app_tf is used: mod_freesync_build_vrr_infopacket -> build_vrr_infopacket_v2 -> build_vrr_infopacket_fs2_data Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2 modify app_tf's value and build_vrr_infopacket_fs2_data expects just the value so we can avoid dereferencing anything by just passing in app_tf's value to mod_freesync_build_vrr_infopacket and build_vrr_infopacket_v2. There is no functional change because build_vrr_infopacket_fs2_data doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same as not calling build_vrr_infopacket_fs2_data at all like before this change when NULL was used for app_tf. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27Revert "drm/amdgpu: use BACO reset on vega20 if platform support"Candice Li1-1/+0
This reverts commit 2172b89e7c94605380d8c0dedf543c93f0a0b27c. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: show the right override pcie parametersEvan Quan2-16/+34
Instead of the hard-coded ones from VBIOS. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: honor the OD settingsEvan Quan2-16/+18
Set the soft/hard max settings as max possible to not violate the OD settings. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: set default fclk for no fclk dpm support caseEvan Quan4-2/+10
Set the default fclk as what we got from VBIOS. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: support retrieving clock information from other syspllsEvan Quan3-16/+18
There will be some needs to retrieve clock information from other sysplls also except default 0. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: overwrite ODSettingsMin for UCLK_FMAX featureEvan Quan1-14/+5
For UCLK_FMAX OD feature, SMU overwrites the highest UCLK DPM level freq. Therefore it can only take values that are greater than the second highest DPM level freq. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: force FCLK to highest also for 5K or higher displaysEvan Quan1-1/+37
This can fix possible screen freeze on high resolution displays. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: need to reapply the dpm level settingsEvan Quan1-2/+1
As these settings got reset during above phm_apply_clock_adjust_rules. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: drop redundant soft min/max settingsEvan Quan1-24/+0
As these are already set during apply_clocks_adjust_rules. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI)Kevin Wang1-51/+1
if use the legacy method to allocate object, when mqd_hiq need to run uninit code, it will be cause WARNING call trace. eg: (s3 suspend test) [ 34.918944] Call Trace: [ 34.918948] [<ffffffff92961dc1>] dump_stack+0x19/0x1b [ 34.918950] [<ffffffff92297648>] __warn+0xd8/0x100 [ 34.918951] [<ffffffff9229778d>] warn_slowpath_null+0x1d/0x20 [ 34.918991] [<ffffffffc03ce1fe>] uninit_mqd_hiq_sdma+0x4e/0x50 [amdgpu] [ 34.919028] [<ffffffffc03d0ef7>] uninitialize+0x37/0xe0 [amdgpu] [ 34.919064] [<ffffffffc03d15a6>] kernel_queue_uninit+0x16/0x30 [amdgpu] [ 34.919086] [<ffffffffc03d26c2>] pm_uninit+0x12/0x20 [amdgpu] [ 34.919107] [<ffffffffc03d4915>] stop_nocpsch+0x15/0x20 [amdgpu] [ 34.919129] [<ffffffffc03c1dce>] kgd2kfd_suspend.part.4+0x2e/0x50 [amdgpu] [ 34.919150] [<ffffffffc03c2667>] kgd2kfd_suspend+0x17/0x20 [amdgpu] [ 34.919171] [<ffffffffc03c103a>] amdgpu_amdkfd_suspend+0x1a/0x20 [amdgpu] [ 34.919187] [<ffffffffc02ec428>] amdgpu_device_suspend+0x88/0x3a0 [amdgpu] [ 34.919189] [<ffffffff922e22cf>] ? enqueue_entity+0x2ef/0xbe0 [ 34.919205] [<ffffffffc02e8220>] amdgpu_pmops_suspend+0x20/0x30 [amdgpu] [ 34.919207] [<ffffffff925c56ff>] pci_pm_suspend+0x6f/0x150 [ 34.919208] [<ffffffff925c5690>] ? pci_pm_freeze+0xf0/0xf0 [ 34.919210] [<ffffffff926b45c6>] dpm_run_callback+0x46/0x90 [ 34.919212] [<ffffffff926b49db>] __device_suspend+0xfb/0x2a0 [ 34.919213] [<ffffffff926b4b9f>] async_suspend+0x1f/0xa0 [ 34.919214] [<ffffffff922c918f>] async_run_entry_fn+0x3f/0x130 [ 34.919216] [<ffffffff922b9d4f>] process_one_work+0x17f/0x440 [ 34.919217] [<ffffffff922bade6>] worker_thread+0x126/0x3c0 [ 34.919218] [<ffffffff922bacc0>] ? manage_workers.isra.25+0x2a0/0x2a0 [ 34.919220] [<ffffffff922c1c31>] kthread+0xd1/0xe0 [ 34.919221] [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40 [ 34.919222] [<ffffffff92974c1d>] ret_from_fork_nospec_begin+0x7/0x21 [ 34.919224] [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40 [ 34.919224] ---[ end trace 38cd9f65c963adad ]--- Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amdgpu: use REG32_PCIE wrapper instead for pspHuang Rui1-3/+1
This patch uses REG32_PCIE wrapper instead of writting pci_index2 and reading pci_data2 for psp. This sequence should be protected by pcie_idx_lock. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/powerplay: use REG32_PCIE wrapper instead for powerplayHuang Rui2-8/+4
This patch uses REG32_PCIE wrapper instead of writting pci_index2 and reading pci_data2 for powerplay. This sequence should be protected by pcie_idx_lock. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/display: Fix issue with link_active state not correct for MSTAnthony Koo1-4/+11
[Why] For MST, link not disabled until all streams disabled [How] Add check for stream_count before setting link_active = false for MST Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amd/display: Fix reference counting for struct dc_sink.Mathias Fröhlich3-8/+37
Reference counting in amdgpu_dm_connector for amdgpu_dm_connector::dc_sink and amdgpu_dm_connector::dc_em_sink as well as in dc_link::local_sink seems to be out of shape. Thus make reference counting consistent for these members and just plain increment the reference count when the variable gets assigned and decrement when the pointer is set to zero or replaced. Also simplify reference counting in selected function sopes to be sure the reference is released in any case. In some cases add NULL pointer check before dereferencing. At a hand full of places a comment is placed to stat that the reference increment happened already somewhere else. This actually fixes the following kernel bug on my system when enabling display core in amdgpu. There are some more similar bug reports around, so it probably helps at more places. kernel BUG at mm/slub.c:294! invalid opcode: 0000 [#1] SMP PTI CPU: 9 PID: 1180 Comm: Xorg Not tainted 5.0.0-rc1+ #2 Hardware name: Supermicro X10DAi/X10DAI, BIOS 3.0a 02/05/2018 RIP: 0010:__slab_free+0x1e2/0x3d0 Code: 8b 54 24 30 48 89 4c 24 28 e8 da fb ff ff 4c 8b 54 24 28 85 c0 0f 85 67 fe ff ff 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 49 3b 5c 24 28 75 ab 48 8b 44 24 30 49 89 4c 24 28 49 89 44 RSP: 0018:ffffb0978589fa90 EFLAGS: 00010246 RAX: ffff92f12806c400 RBX: 0000000080200019 RCX: ffff92f12806c400 RDX: ffff92f12806c400 RSI: ffffdd6421a01a00 RDI: ffff92ed2f406e80 RBP: ffffb0978589fb40 R08: 0000000000000001 R09: ffffffffc0ee4748 R10: ffff92f12806c400 R11: 0000000000000001 R12: ffffdd6421a01a00 R13: ffff92f12806c400 R14: ffff92ed2f406e80 R15: ffffdd6421a01a20 FS: 00007f4170be0ac0(0000) GS:ffff92ed2fb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562818aaa000 CR3: 000000045745a002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? drm_dbg+0x87/0x90 [drm] dc_stream_release+0x28/0x50 [amdgpu] amdgpu_dm_connector_mode_valid+0xb4/0x1f0 [amdgpu] drm_helper_probe_single_connector_modes+0x492/0x6b0 [drm_kms_helper] drm_mode_getconnector+0x457/0x490 [drm] ? drm_connector_property_set_ioctl+0x60/0x60 [drm] drm_ioctl_kernel+0xa9/0xf0 [drm] drm_ioctl+0x201/0x3a0 [drm] ? drm_connector_property_set_ioctl+0x60/0x60 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0xa4/0x630 ? __sys_recvmsg+0x83/0xa0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f417110809b Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdd8d1c268 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000562818a8ebc0 RCX: 00007f417110809b RDX: 00007ffdd8d1c2a0 RSI: 00000000c05064a7 RDI: 0000000000000012 RBP: 00007ffdd8d1c2a0 R08: 0000562819012280 R09: 0000000000000007 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c05064a7 R13: 0000000000000012 R14: 0000000000000012 R15: 00007ffdd8d1c2a0 Modules linked in: nfsv4 dns_resolver nfs lockd grace fscache fuse vfat fat amdgpu intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul chash gpu_sched crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel amd_iommu_v2 iTCO_wdt iTCO_vendor_support ttm snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio snd_hda_intel drm_kms_helper snd_hda_codec intel_cstate snd_hda_core drm snd_hwdep snd_seq snd_seq_device intel_uncore snd_pcm intel_rapl_perf snd_timer snd soundcore ioatdma pcspkr intel_wmi_thunderbolt mxm_wmi i2c_i801 lpc_ich pcc_cpufreq auth_rpcgss sunrpc igb crc32c_intel i2c_algo_bit dca wmi hid_cherry analog gameport joydev This patch is based on agd5f/drm-next-5.1-wip. This patch does not require all of that, but agd5f/drm-next-5.1-wip contains at least one more dc_sink counting fix that I could spot. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/amdgpu/powerplay: add missing breaks in polaris10_smumgrAlex Deucher1-0/+2
This was noticed by Gustavo and his -Wimplicit-fallthrough patches. However, in this case, I believe we should have breaks rather than falling though, that said, in practice we should never fall through in the first place so there should be no change in behavior. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-28Merge tag 'imx-drm-next-2019-02-22' of git://git.pengutronix.de/pza/linux into drm-nextDave Airlie8-33/+108
drm/imx: handle pending updates better, add plane zpos property support - Add a mechanism to only send commit done events once all pending updates have been applied. This closes a small race window where already armed events could fire even though the double buffered hardware update just missed the update window. - Add plane zpos property support to allow placing the overlay plane behind the primary plane. - Allow building imx-drm on all platforms under COMPILE_TEST. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Philipp Zabel <pza@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190222112350.m3ucezilqx6cyest@pengutronix.de
2019-02-28Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixesDave Airlie2-4/+24
Fix for variable refresh rate stuttering Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190227192115.14597-1-alexander.deucher@amd.com
2019-02-27drm: Wake up next in drm_read() chain if we are forced to putback the eventChris Wilson1-0/+1
After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.uk
2019-02-27drm/amd/display: Use vrr friendly pageflip throttling in DC.Mario Kleiner2-4/+24
In VRR mode, keep track of the vblank count of the last completed pageflip in amdgpu_crtc->last_flip_vblank, as recorded in the pageflip completion handler after each completed flip. Use that count to prevent mmio programming a new pageflip within the same vblank in which the last pageflip completed, iow. to throttle pageflips to at most one flip per video frame, while at the same time allowing to request a flip not only before start of vblank, but also anywhere within vblank. The old logic did the same, and made sense for regular fixed refresh rate flipping, but in vrr mode it prevents requesting a flip anywhere inside the possibly huge vblank, thereby reducing framerate in vrr mode instead of improving it, by delaying a slightly delayed flip requests up to a maximum vblank duration + 1 scanout duration. This would limit VRR usefulness to only help applications with a very high GPU demand, which can submit the flip request before start of vblank, but then have to wait long for fences to complete. With this method a flip can be both requested and - after fences have completed - executed, ie. it doesn't matter if the request (amdgpu_dm_do_flip()) gets delayed until deep into the extended vblank due to cpu execution delays. This also allows clients which want to regulate framerate within the vrr range a much more fine-grained control of flip timing, a feature that might be useful for video playback, and is very useful for neuroscience/vision research applications. In regular non-VRR mode, retain the old flip submission behavior. This to keep flip scheduling for fullscreen X11/GLX OpenGL clients intact, if they use the GLX_OML_sync_control extensions glXSwapBufferMscOML(, ..., target_msc,...) function with a specific target_msc target vblank count. glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will not flip at the proper target_msc for a non-zero target_msc if VRR mode is active with this patch. They'd often flip one frame too early. However, this limitation should not matter much in VRR mode, as scheduling based on vblank counts is pretty futile/unusable under variable refresh duration anyway, so no real extra harm is done. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27drm/i915: Avoid waking the engines just to check if they are idleChris Wilson1-6/+11
Exploit that reads of the ring registers return 0 from the engine when it is idle and we do not apply forcewake to know that if the engine is idle then both reads will be identical (and so we interpret the ring as idle). The ulterior motive is to try and reduce the number of spurious wakeups to avoid untimely death, such as: <3> [85.046836] [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request. <4> [85.051916] ------------[ cut here ]------------ <4> [85.051917] GT thread status wait timed out <4> [85.051963] WARNING: CPU: 2 PID: 2195 at drivers/gpu/drm/i915/intel_uncore.c:303 __gen6_gt_wait_for_thread_c0+0x6e/0xa0 [i915] <4> [85.051964] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal coretemp mei_hdcp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_hda_codec broadcom bcm_phy_lib i2c_i801 snd_hwdep snd_hda_core tg3 snd_pcm ptp pps_core mei_me mei prime_numbers lpc_ich <4> [85.051980] CPU: 2 PID: 2195 Comm: drm_read Tainted: G U 5.0.0-rc8-CI-CI_DRM_5662+ #1 <4> [85.051981] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 <4> [85.052012] RIP: 0010:__gen6_gt_wait_for_thread_c0+0x6e/0xa0 [i915] <4> [85.052015] Code: 8b 92 5c 80 13 00 83 e2 07 75 d5 5b 5d c3 80 3d 5b 6a 1a 00 00 75 f4 48 c7 c7 38 21 31 a0 c6 05 4b 6a 1a 00 01 e8 e2 84 ea e0 <0f> 0b eb dd 80 3d 3a 6a 1a 00 00 75 98 48 c7 c6 08 21 31 a0 48 c7 <4> [85.052016] RSP: 0018:ffffc9000043bd00 EFLAGS: 00010086 <4> [85.052019] RAX: 0000000000000000 RBX: ffff888217c50000 RCX: 0000000000000000 <4> [85.052020] RDX: 0000000000000007 RSI: ffffffff820cb141 RDI: 00000000ffffffff <4> [85.052022] RBP: 00000013cd30f2fb R08: 0000000000000000 R09: 0000000000000001 <4> [85.052024] R10: ffffc9000043bce0 R11: 0000000000000000 R12: ffff888217c50ee0 <4> [85.052025] R13: 0000000000000001 R14: 00000000ffffffff R15: ffff888218076530 <4> [85.052028] FS: 00007fc79d049980(0000) GS:ffff888227a80000(0000) knlGS:0000000000000000 <4> [85.052029] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [85.052031] CR2: 00007f782e2940f8 CR3: 000000022458e006 CR4: 00000000000606e0 <4> [85.052033] Call Trace: <4> [85.052064] gen6_read32+0x14e/0x250 [i915] <4> [85.052096] intel_engine_is_idle+0x7d/0x180 [i915] <4> [85.052126] intel_engines_are_idle+0x29/0x50 [i915] <4> [85.052153] i915_drop_caches_set+0x21c/0x290 [i915] <4> [85.052160] simple_attr_write+0xb0/0xd0 <4> [85.052165] full_proxy_write+0x51/0x80 <4> [85.052170] __vfs_write+0x31/0x190 <4> [85.052176] ? rcu_read_lock_sched_held+0x6f/0x80 <4> [85.052178] ? rcu_sync_lockdep_assert+0x29/0x50 <4> [85.052181] ? __sb_start_write+0x152/0x1f0 <4> [85.052183] ? __sb_start_write+0x163/0x1f0 <4> [85.052187] vfs_write+0xbd/0x1b0 <4> [85.052191] ksys_write+0x50/0xc0 <4> [85.052196] do_syscall_64+0x55/0x190 <4> [85.052200] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [85.052202] RIP: 0033:0x7fc79c9d3281 <4> [85.052204] Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53 <4> [85.052206] RSP: 002b:00007fffa4a0a7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 <4> [85.052208] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fc79c9d3281 <4> [85.052210] RDX: 0000000000000005 RSI: 00007fffa4a0a880 RDI: 0000000000000008 <4> [85.052212] RBP: 00007fffa4a0a820 R08: 0000000000000000 R09: 0000000000000000 <4> [85.052213] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc79c9bc718 <4> [85.052215] R13: 0000000000000003 R14: 00007fc79c9c1628 R15: 00007fc79c9bdd80 <4> [85.052223] irq event stamp: 71630 <4> [85.052226] hardirqs last enabled at (71629): [<ffffffff8197b64c>] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [85.052228] hardirqs last disabled at (71630): [<ffffffff8197b4bd>] _raw_spin_lock_irqsave+0xd/0x50 <4> [85.052231] softirqs last enabled at (70444): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 <4> [85.052234] softirqs last disabled at (70433): [<ffffffff810b51b1>] irq_exit+0xd1/0xe0 <4> [85.052264] WARNING: CPU: 2 PID: 2195 at drivers/gpu/drm/i915/intel_uncore.c:303 __gen6_gt_wait_for_thread_c0+0x6e/0xa0 [i915] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190227114958.32438-1-chris@chris-wilson.co.uk
2019-02-27drm/i915: Skip scanning for signalers if we are already inflightChris Wilson1-0/+9
When a request has its priority changed, we traverse the graph of all of its signalers to raise their priorities to match (priority inheritance). If the request has already started executing its payload, we know that all of its signalers must have signaled and we do not need to process our list of signalers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226102404.29153-1-chris@chris-wilson.co.uk
2019-02-26drm/i915: Include infoframes in the crtc state dumpVille Syrjälä1-0/+26
Dump out the infoframes in the normal crtc state dump. TODO: Try to better integrate the infoframe dumps with drm state dumps Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-10-ville.syrjala@linux.intel.com
2019-02-26drm/i915: Check infoframe state in intel_pipe_config_compare()Ville Syrjälä1-1/+48
Check the infoframes and infoframe enable state when comparing two crtc states. We'll use the infoframe logging functions from video/hdmi.c to show the infoframes as part of the state dump. TODO: Try to better integrate the infoframe dumps with drm state dumps v2: drm_printk() is no more Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-9-ville.syrjala@linux.intel.com
2019-02-26drm/i915/sdvo: Read out HDMI infoframesVille Syrjälä1-3/+91
Read the HDMI infoframes from the hbuf and unpack them into the crtc state. Well, actually just AVI infoframe for now but let's write the infoframe readout code in a more generic fashion in case we expand this later. Note that Daniel was sceptical about the benefit if this and also concerned about the potential for crappy sdvo encoders not implementing the hbuf read commands. My (admittedly limited) experience is that such encoders don't implement even the get/set hdmi encoding commands and thus would always be treated as dvi only. Hence I believe this is safe, and also IMO preferable having quirks to deal with missing readout support. The readout support is neatly isolated in the sdvo code whereas the quirk would leak to other parts of the driver (state checker, fastboot, etc.) thus complicating the lives of other people. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-8-ville.syrjala@linux.intel.com
2019-02-26drm/i915/sdvo: Precompute HDMI infoframesVille Syrjälä1-17/+45
As with regular HDMI encoders, let's precompute the infoframes (actually just AVI infoframe for the time being) with SDVO HDMI encoders. v2: Drop the WARN_ON() from drm_hdmi_avi_infoframe_from_display_mode() return since that could genuinely fail due to user asking for incompatible aspect ratio v3: .compute_config() now returns int Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-7-ville.syrjala@linux.intel.com
2019-02-26drm/i915: Read out HDMI infoframesVille Syrjälä4-0/+206
Add code to read the infoframes from the video DIP and unpack them into the crtc state. v2: Make the read funcs return void (Daniel) Drop the duplicate infoframe enabled checks (Daniel) Add a FIXME for lspcon infoframe readout Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-6-ville.syrjala@linux.intel.com
2019-02-26drm/i915: Precompute HDMI infoframesVille Syrjälä3-68/+184
Store the infoframes in the crtc state and precompute them in .compute_config(). While precomputing we'll also fill out the inforames.enable bitmask appropriately. v2: Drop the null packet stuff (Daniel) Add a FIXME for lspcon v3: .compute_config() now returns int Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-5-ville.syrjala@linux.intel.com
2019-02-26drm/i915: Store mask of enabled infoframes in the crtc stateVille Syrjälä3-2/+12
Store the mask of enabled infoframes in the crtc state. We'll start with just the readout for HDMI encoder, and we'll expand this to compute the bitmask in .compute_config() later. SDVO will also follow later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-4-ville.syrjala@linux.intel.com
2019-02-26drm/i915: Return the mask of enabled infoframes from ->inforame_enabled()Ville Syrjälä4-29/+65
We want to start tracking which infoframes are enabled, so let's replace the boolean flag with a bitmask. We'll abstract the bitmask so that it's not platform dependent. That will allow us to examine the bitmask later in platform independent code. v2: Don't map VIDEO_DIP_ENABLE to the null packet (Daniel) Put a FIXME in the lspcon function Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-3-ville.syrjala@linux.intel.com
2019-02-26drm/i915: Add the missing HDMI gamut metadata packet stuffVille Syrjälä2-3/+17
We have definitions and low level code for everything except the gamut metadata HDMI packet. Add the missing bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190225174106.2163-2-ville.syrjala@linux.intel.com
2019-02-26drm/panel: Add Ronbo RB070D30 panelKonstantin Sudakov3-0/+268
The Ronbo RB070D30 panel is a MIPI-DSI panel based on a Fitipower EK79007 controller and a 1024x600 panel. Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Konstantin Sudakov <k.sudakov@integrasources.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/3cc43c6051e89a52434053a38a36621acab7236e.1550650810.git-series.maxime.ripard@bootlin.com
2019-02-26drm/i915/query: Split out query item checksAbdiel Janulgue1-13/+26
This simplifies adding new query item objects. v2: Use query_hdr (Tvrtko, Chris). int instead of u32 in return (Tvrtko) v3: More naming fixes (Tvrtko) Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190211173251.7131-1-abdiel.janulgue@linux.intel.com
2019-02-26drm/i915/selftests: Exercise resetting during non-user payloadsChris Wilson1-0/+218
In selftests/live_hangcheck, we have a lot of tests for resetting simple spinners, but nothing quite prepared us for how the GPU reacted to triggering a reset outside of the safe spinner. These two subtests fill the ring with plain old empty, non-spinning requests, and then triggers a reset. Without a user-payload to blame, these requests will exercise the 'non-started' paths and mostly be replayed verbatim. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-4-chris@chris-wilson.co.uk
2019-02-26drm/i915: Remove i915_request.global_seqnoChris Wilson12-194/+32
Having weaned the interrupt handling off using a single global execution queue, we no longer need to emit a global_seqno. Note that we still have a few assumptions about execution order along engine timelines, but this removes the most obvious artefact! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-3-chris@chris-wilson.co.uk
2019-02-26drm/i915: Remove access to global seqno in the HWSPChris Wilson10-104/+19
Stop accessing the HWSP to read the global seqno, and stop tracking the mirror in the engine's execution timeline -- it is unused. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-2-chris@chris-wilson.co.uk
2019-02-26drm/i915: Replace global_seqno with a hangcheck heartbeat seqnoChris Wilson6-11/+77
To determine whether an engine has 'stuck', we simply check whether or not is still on the same seqno for several seconds. To keep this simple mechanism intact over the loss of a global seqno, we can simply add a new global heartbeat seqno instead. As we cannot know the sequence in which requests will then be completed, we use a primitive random number generator instead (with a cycle long enough to not matter over an interval of a few thousand requests between hangcheck samples). The alternative to using a dedicated seqno on every request is to issue a heartbeat request and query its progress through the system. Sadly this requires us to reduce struct_mutex so that we can issue requests without requiring that bkl. v2: And without the extra CS_STALL for the hangcheck seqno -- we don't need strict serialisation with what comes later, we just need to be sure we don't write the hangcheck seqno before our batch is flushed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-1-chris@chris-wilson.co.uk
2019-02-25drm/i915: Call MG_DP_MODE() macro with the right parameters orderJosé Roberto de Souza1-5/+5
The commit that this patch fixes changed the order of the parameters of MG_DP_MODE() but din't update the callers, breaking type-c on ICL. Fixes: 58106b7d816e ("drm/i915: Make MG PHY macros semantically consistent") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Manasi navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190222202437.6575-1-jose.souza@intel.com
2019-02-24Merge back earlier PM core material for v5.1.Rafael J. Wysocki2-12/+8
2019-02-23drm/i915/pmu: Always sample an active ringbufferChris Wilson2-38/+29
As we no longer have a precise indication of requests queued to an engine, make no presumptions and just sample the ring registers to see if the engine is busy. v2: Report busy while the ring is idling on a semaphore/event. v3: Give the struct a name! v4: Always 0 outside the powerwell; trusting the powerwell is accurate enough for our sampling pmu. v5: Protect against gen7 mmio madness and try to improve grammar Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190223000102.14290-1-chris@chris-wilson.co.uk
2019-02-22drm/i915: Remove unused HAS_PCH_CNP_LPRodrigo Vivi1-2/+0
Other than LPT, no other PCH needed to differentiate between LP and HP. So let's remove this before we spread this mistake to future platforms. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221211716.9433-1-rodrigo.vivi@intel.com
2019-02-22drm/amd/powerplay: fix the confusing ppfeature mask calculationsEvan Quan3-6/+6
Simplify the ppfeature mask calculations. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-22drm/powerplay: print current clock level when dpm is disabled on vg20shaoyunl1-28/+28
When DPM for the specific clock is disabled, driver should still print out current clock info for rocm-smi support on vega20 Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Reviewed-by: Eric Huang <JinhuiEric.Huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-22drm/i915: Sort newer to older platforms.Rodrigo Vivi1-6/+6
No functional change. Just a reorg to match the preferred behavior. v2: missing else (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221214430.27095-1-rodrigo.vivi@intel.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.