aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-02-28Merge tag 'asoc-v5.1-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-nextTakashi Iwai54-376/+539
ASoC: More changes for v5.1 Another batch of changes for ASoC, no big core changes - it's mainly small fixes and improvements for individual drivers. - A big refresh and cleanup of the Samsung drivers, fixing a number of issues which allow the driver to be used with a wider range of userspaces. - Fixes for the Intel drivers to make them more standard so less likely to get bitten by core issues. - New driver for Cirrus Logic CS35L26.
2019-02-28Merge tag 'topic/mei-hdcp-2019-02-26' of git://anongit.freedesktop.org/drm/drm-intel into char-misc-nextGreg Kroah-Hartman2-16/+4
Daniel writes: mei-hdcp driver mei driver for the me hdcp client, for use by drm/i915. Including the following prep work: - whitelist hdcp client in mei bus - merge to include char-misc-next - drm/i915 side of the mei_hdcp/i915 component interface - component prep work (including one patch touching i915&snd-hda) * tag 'topic/mei-hdcp-2019-02-26' of git://anongit.freedesktop.org/drm/drm-intel: (23 commits) misc/mei/hdcp: Component framework for I915 Interface misc/mei/hdcp: Closing wired HDCP2.2 Tx Session misc/mei/hdcp: Enabling the HDCP authentication misc/mei/hdcp: Verify M_prime misc/mei/hdcp: Repeater topology verification and ack misc/mei/hdcp: Prepare Session Key misc/mei/hdcp: Verify L_prime misc/mei/hdcp: Initiate Locality check misc/mei/hdcp: Store the HDCP Pairing info misc/mei/hdcp: Verify H_prime misc/mei/hdcp: Verify Receiver Cert and prepare km misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session misc/mei/hdcp: Define ME FW interface for HDCP2.2 misc/mei/hdcp: Client driver for HDCP application mei: bus: whitelist hdcp client drm/audio: declaration of struct device drm: helper functions for hdcp2 seq_num to from u32 drm/i915: MEI interface definition drm/i915: header for i915 - MEI_HDCP interface drm/i915: enum port definition is moved into i915_drm.h ...
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/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-24Merge back earlier PM core material for v5.1.Rafael J. Wysocki2-12/+8
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/imx: only send commit done event when all state has been appliedLucas Stach1-2/+28
Currently there is a small race window where we could manage to arm the vblank event from atomic flush, but programming the hardware was too close to the frame end, so the hardware will only apply the current state on the next vblank. In this case we will send out the commit done event too early causing userspace to reuse framebuffes that are still in use. Instead of using the event arming mechnism, just remember the pending event and send it from the vblank IRQ handler, once we are sure that all state has been applied successfully. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending, added back spinlock in atomic_flush, commit message typo fix] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22drm/imx: allow building under COMPILE_TESTPhilipp Zabel1-1/+1
Allow to compile-test imx-drm on other platforms. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22drm/imx: imx-tve: depend on COMMON_CLKPhilipp Zabel1-0/+1
Since the TVE provides a clock to the DI, the driver can only be compiled if the common clock framework is enabled. With the COMMON_CLK dependency in place, it will be possible to allow building the other parts of imx-drm under COMPILE_TEST on architectures that do not select the common clock framework. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22drm/imx: ipuv3-plane: add zpos propertyPhilipp Zabel2-30/+33
Add a zpos property to planes. Call drm_atomic_helper_check() instead of calling drm_atomic_helper_check_modeset() and drm_atomic_check_planes() manually. This effectively adds a call to drm_atomic_normalize_zpos() before checking planes. Reorder atomic update to allow changing plane zpos without modeset. Note that the initial zpos is set in ipu_plane_state_reset(). The initial value set in ipu_plane_init() is just for show. The zpos parameter of drm_plane_create_zpos_property() is ignored because the newly created plane do not have state yet. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Marius Vlad <marius.vlad@collabora.com>
2019-02-22drm/imx: ipuv3-plane: add function to query atomic update statusLucas Stach2-0/+22
This function allows upper layer to check if a requested atomic update to the plane has been applied or is still pending. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22gpu: ipu-v3: prg: add function to get channel configure statusLucas Stach1-0/+16
This allows channels using the PRG to check if a requested configuration update has been applied or is still pending. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22gpu: ipu-v3: pre: add double buffer status readbackLucas Stach2-0/+7
This allows the upper layers to check if a double buffer update has been applied by the PRE or is still pending. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> [p.zabel@pengutronix.de: inverted logic: done -> pending] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux into drm-nextDave Airlie59-611/+699
Fixes for 5.1: amdgpu: - Fix missing fw declaration after dropping old CI DPM code - Fix debugfs access to registers beyond the MMIO bar size - Fix context priority handling - Add missing license on some new files - Various cleanups and bug fixes radeon: - Fix missing break in CS parser for evergreen - Various cleanups and bug fixes sched: - Fix entities with 0 run queues Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221214134.3308-1-alexander.deucher@amd.com
2019-02-22Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixesDave Airlie10-13/+40
A bit bigger than normal for this week due to fixes for some long standing display issues that are bound for stable. These changes would be going to stable anyway, so I figured it was better via 5.0 than 5.1. - Several display fixes - Fix PX systems due to core changes in runtime pm - Disable bulk moves. They are fixed in 5.1, but fix is too invasive for 5.0 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190220225715.3240-1-alexander.deucher@amd.com
2019-02-21drm/amdgpu: Bump amdgpu version for context priority override.Bas Nieuwenhuizen1-1/+2
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-21drm/amdgpu/powerplay: fix typo in BACO header guardsAlex Deucher2-4/+4
s/BOCO/BACO/g Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-21drm/amdgpu/powerplay: fix return codes in BACO codeAlex Deucher2-5/+5
Use a proper return code rather than -1. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-21drm/amdgpu: add missing license on baco filesAlex Deucher2-0/+44
Trivial. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-21drm/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>
2019-02-20drm/amdgpu: disable bulk moves for nowChristian König1-0/+2
The changes to fix those are two invasive for backporting. Just disable the feature in 4.20 and 5.0. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> [4.20+] Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-20drm/amd/display: set clocks to 0 on suspend on dce80Bhawanpreet Lakha1-3/+16
[Why] When a dce80 asic was suspended, the clocks were not set to 0. Upon resume, the new clock was compared to the existing clock, they were found to be the same, and so the clock was not set. This resulted in a blackscreen. [How] In atomic commit, check to see if there are any active pipes. If no, set clocks to 0 Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-02-20drm/amd/display: fix optimize_bandwidth func pointer for dce80Bhawanpreet Lakha2-1/+5
[Why] optimize_bandwidth was using dce100_prepare_bandwidth this is incorrect [How] change it to dce100_optimize_bandwidth Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-02-20drm/amd/display: Fix negative cursor pos programmingNicholas Kazlauskas1-2/+2
[Why] If the cursor pos passed from DM is less than the plane_state->dst_rect top left corner then the unsigned cursor pos wraps around to a large positive number since cursor pos is a u32. There was an attempt to guard against this in hubp1_cursor_set_position by checking the src_x_offset and src_y_offset and offseting the cursor hotspot within hubp1_cursor_set_position. However, the cursor position itself is still being programmed incorrectly as a large value. This manifests itself visually as the cursor disappearing or containing strange artifacts near the middle of the screen on raven. [How] Don't subtract the destination rect top left corner from the pos but add it to the hotspot instead. This happens before the pos gets passed into hubp1_cursor_set_position. This achieves the same result but avoids the subtraction wrap around. With this fix the original cursor programming logic can be used again. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Acked-by: Murton Liu <Murton.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-20Pull in char-misc-next from GregDaniel Vetter22-110/+198
We need 32ea33a04484 ("mei: bus: export to_mei_cl_device for mei client devices drivers") for the mei-hdcp patches. References: https://lkml.org/lkml/2019/2/19/356 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2019-02-20drm/i915/fbdev: Actually configure untiled displaysChris Wilson1-5/+7
If we skipped all the connectors that were not part of a tile, we would leave conn_seq=0 and conn_configured=0, convincing ourselves that we had stagnated in our configuration attempts. Avoid this situation by starting conn_seq=ALL_CONNECTORS, and repeating until we find no more connectors to configure. Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on stagnation") Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-chris@chris-wilson.co.uk Cc: <stable@vger.kernel.org> # v3.19+ (cherry picked from commit d9b308b1f8a1acc0c3279f443d4fe0f9f663252e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-02-20Merge https://gitlab.freedesktop.org/drm/msm into drm-nextDave Airlie25-869/+286
On the display side, cleanups and fixes to enabled modifiers (QCOM_COMPRESSED). And otherwise mostly misc fixes all around. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGuZ5uBKpf=fHvKpTiD10nychuEY8rnE+HeRz0QMvtY5_A@mail.gmail.com
2019-02-20drm/nouveau/dmem: use dma addresses during migration copiesBen Skeggs1-106/+53
Removes the need for temporary VMM mappings. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-02-20drm/nouveau/dmem: use physical vram addresses during migration copiesBen Skeggs1-20/+4
Removes the need for temporary VMM mappings. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.