- 09 Apr, 2020 6 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-fixes-5.7-2020-04-08: amdgpu: - Various Renoir fixes - Fix gfx clockgating sequence on gfx10 - RAS fixes - Avoid MST property creation after registration - Various cursor/viewport fixes - Fix a confusing log message about optional firmwares Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200408222240.3942-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2020-04-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Flush all the reloc_gpu batch (Chris) - Ignore readonly failures when updating relocs (Chris) - Fill all the unused space in the GGTT (Chris) - Return the right vswing table (Jose) - Don't enable DDI IO power on a TypeC port in TBT mode for ICL+ (Imre) Signed-off-by:
-
Thomas Hellstrom (VMware) authored
With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are errors like: BUG: non-zero pgtables_bytes on freeing mm and: BUG: Bad rss-counter state with TTM transparent huge-pages. Until we've figured out what other TTM drivers do differently compared to vmwgfx, disable the huge_fault() callback, eliminating transhuge page-table entries. Cc: Christian König <christian.koenig@amd.com> Signed-off-by:
Thomas Hellstrom (VMware) <thomas_os@shipmail.org> Reported-by:
Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Tested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2020-04-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-next A few DMA-related fixes, an OOB fix for virtio and a probe-related fix for analogix_dp Signed-off-by:
-
Marek Szyprowski authored
Analogix_dp driver acquires all its resources in the ->bind() callback, what is a bit against the component driver based approach, where the driver initialization is split into a probe(), where all resources are gathered, and a bind(), where all objects are created and a compound driver is initialized. Extract all the resource related operations to analogix_dp_probe() and analogix_dp_remove(), then call them before/after registration of the device components from the main Exynos DP and Rockchip DP drivers. Also move the plat_data initialization to the probe() to make it available for the analogix_dp_probe() function. This fixes the multiple calls to the bind() of the DRM compound driver when the DP PHY driver is not yet loaded/probed: [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops [exynosdrm]) exynos-dp 145b0000.dp-controller: no DP phy configured exynos-drm exynos-drm: failed to bind 145b0000.dp-controller (ops exynos_dp_ops [exynosdrm]): -517 exynos-drm exynos-drm: master bind failed: -517 ... [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 145b0000.dp-controller (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_enable [exynosdrm]) [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Console: switching to colour frame buffer device 170x48 exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 ... Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Andy Yan <andy.yan@rock-chips.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Chris Wilson authored
drm_local_map.offset is not only used for resource_size_t but also dma_addr_t which may be of different sizes. Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Fixes: 8e4ff9b5 ("drm: Remove the dma_alloc_coherent wrapper for internal usage") Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@gmail.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200402215926.30714-1-chris@chris-wilson.co.uk
-
- 08 Apr, 2020 4 commits
-
-
Alex Deucher authored
fixes unused variable warning. Reported-by:
Eric Biggers <ebiggers@kernel.org> Acked-by:
Mikita Lipski <mikita.lipski@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Aaron Liu authored
Make the fw_write_wait default case true since presumably all new gfx9 asics will have updated firmware. That is using unique WAIT_REG_MEM packet with opration=1. Signed-off-by:
Aaron Liu <aaron.liu@amd.com> Tested-by:
Yuxian Dai <Yuxian.Dai@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Evan Quan authored
For Arcturus, forcing clock to some specific level is not supported with 54.18 and onwards SMU firmware. As according to firmware team, they adopt new gfx dpm tuned parameters which can cover all the use case in a much smooth way. Thus setting through driver interface is not needed and maybe do a disservice. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Prike Liang authored
The system will be hang up during S3 suspend because of SMU is pending for GC not respose the register CP_HQD_ACTIVE access request.This issue root cause of accessing the GC register under enter GFX CGGPG and can be fixed by disable GFX CGPG before perform suspend. v2: Use disable the GFX CGPG instead of RLC safe mode guard. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Tested-by:
Mengbing Wang <Mengbing.Wang@amd.com> Reviewed-by:
-
- 07 Apr, 2020 28 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.7-2020-04-01: amdgpu: - HDCP fixes - gfx10 fix - Misc display fixes - BACO fixes amdkfd: - Fix memory leak Signed-off-by:
-
git://github.com/skeggsb/linuxDave Airlie authored
A couple of misc fixes/workarounds for some issues that are causing a lot of pain for people. Of most interest are the PCI power management and GR init WARs, which effect a rather significant number of laptop systems that are in use today. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2020-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next A bunch of fixes to avoid null pointer dereference in fbcon, fix a return in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation, and a conflicting framebuffer in vboxvideo. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2020-04-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Only gvt fixes on this round: - Fix non-privilege access warning (Tina) - Fix display port type (Tina) - BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan) - Bypass length check of LRI (Yan) - Fix one klocwork warning (Tina) Signed-off-by:
-
Michael Strauss authored
[WHY] In cases where a clock table is malformed such that fclk entries have frequencies but not voltages listed, we don't catch the error and set clocks to 0 instead of using hardcoded values as we should. [HOW] Add check for clock tables fclk entry's voltage as well Signed-off-by:
Michael Strauss <michael.strauss@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Joshua Aberback authored
[Why] If dc->clk_mgr->funcs->are_clock_states_equal is set, then wm_optimized_required is never checked. In that case, when going from a higher mode to a lower mode, wm_optimized_required remains true until the next mode change. [How] - move from else-if to unconditional or Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Reviewed-by:
Yongqiang Sun <yongqiang.sun@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] In some usecases, like tiled display, the stream and plane configuration can be setup in a way where the caller expects DAL to perform the clipping, eg: P0: src_rect(0, 0, w, h) dst_rect(0, 0, w, h) P1: src_rect(w, 0, w, h) dst_rect(0, 0, w, h) Cursor is enabled on both streams with the same position. This can result in double cursor on tiled display, even though this behavior is technically correct from the DC interface point of view. We need a mechanism to control this dynamically. [How] This is something that should live in the DM layer based on detection of the specified configuration but it's not something that we really have enough information to deal with today. Add a flag to the cursor position state that specifies whether we want DC to do the translation or not and make it opt-in and let the DM decide when to do it. Signed-off-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] If a plane isn't being actively enabled or disabled then DC won't always recalculate scaling rects and ratios for the primary plane. This results in only a partial or corrupted rect being displayed on the screen instead of scaling to fit the screen. [How] Add back the logic to recalculate the scaling rects into dc_commit_updates_for_stream since this is the expected place to do it in DC. This was previously removed a few years ago to fix an underscan issue but underscan is still functional now with this change - and it should be, since this is only updating to the latest plane state getting passed in. Signed-off-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] For medium updates that change nothing but the source rect position the viewport doesn't change on DCN20. We're missing the check for the position update bit that was there in the DCN10 hardware sequencer. [How] Check the position bit along with the scaling bit like we were doing with DCN20. We shouldn't actually hit a case where context != current_state in our programming/commit model but guard against it anyway since it was guarded for the other bits. Signed-off-by:
Zhan Liu <Zhan.Liu@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] Cursor pos is correctly adjusted from DC side for source rect offset on DCN ASIC, but only on the overlay. This is because DM places offsets the cursor for primary planes only to workaround missing code in DCE for the adjustment we're now correctly doing in DC for DCN ASIC. [How] Drop the adjustment for source rect from the DM side of things and put the code where it actually belongs - in DC on the pipe level. This matches what we do for DCN now. Signed-off-by:
-
Eric Yang authored
[Why] Changing policy to dynamic will allow 4k multi display configs to be supported at DPM0 Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Cursor is drawn as part of the framebuffer for a plane on AMD hardware. The cursor position on the framebuffer does not change even if the source rect viewport for the cursor does. This causes the cursor to be clipped. The following IGT tests fail as a result of this issue: - kms_plane_cursor@pipe-*-viewport-size-* [How] Offset cursor position by plane source rect viewport. If the viewport is unscaled then the cursor is now correctly positioned on any plane - primary or overlay. There is still a hardware limitation for dealing with the cursor size being incorrectly scaled but that's not something we can address. Add some documentation explaining some of this in the code while we're at it. Signed-off-by:
-
Isabel Zhang authored
[Why] After v_total_min and max are updated in vrr structure, the changes are not reflected in stream adjust. When these values are read from stream adjust it does not reflect the actual state of the system. [How] Set stream adjust values equal to vrr adjust values after vrr adjust values are updated. Signed-off-by:
Isabel Zhang <isabel.zhang@amd.com> Reviewed-by:
Alvin Lee <Alvin.Lee2@amd.com> Acked-by:
-
Jerry (Fangzhi) Zuo authored
[Why] Prop are created at boot stage, and not allowed to create new prop after device registration. [How] Reuse the connector property from SST if exist. Signed-off-by:
Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
Alex Deucher authored
Replace dev_warn() with dev_info() and note that they are optional to avoid confusing users. The RAS TAs only exist on server boards and the HDCP and DTM TAs only exist on client boards. They are optional either way. Acked-by:
Nirmoy Das <nirmoy.das@amd.com> Signed-off-by:
-
John Clements authored
prefix RAS error related dmesg print with pci device info Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
John Clements authored
upon receiving uncorrectable error, query every GPU node for ras errors Reviewed-by:
-
Chengming Gui authored
Incorrect CG sequence will cause gfx timedout, if we keep switching power profile mode (enter profile mod such as PEAK will disable CG, exit profile mode EXIT will enable CG) when run Vulkan test case(case used for test: vkexample). Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Acked-by:
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Certain boards with GP107/GP108 chipsets hang (often, but randomly) for unknown reasons during GR initialisation. The first tell-tale symptom of this issue is: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ] appearing in dmesg, likely followed by many other failures being logged. Karol found this WAR for the issue a while back, but efforts to isolate the root cause and proper fix have not yielded success so far. I've modified the original patch to include a few more details, limit it to GP107/GP108 by default, and added a config option to override this choice. Signed-off-by:
Karol Herbst <kherbst@redhat.com>
-
Karol Herbst authored
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state, currently in D3" "nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)" followed by backtraces of kernel crashes or timeouts within nouveau. It's still unkown why this issue exists, but this is a reliable workaround and solves a very annoying issue for user having to choose between a crashing kernel or higher power consumption of their Laptops. Signed-off-by:
-
Ralph Campbell authored
When nouveau processes GPU faults, it checks to see if the fault address falls within the "unmanaged" range which is reserved for fixed allocations instead of addresses chosen by the core mm code. If start is greater than or equal to svmm->unmanaged.limit, then limit will also be greater than svmm->unmanaged.limit which is greater than svmm->unmanaged.start and the start = max_t(u64, start, svmm->unmanaged.limit) will change nothing. Just remove the useless lines of code. Signed-off-by:
Ralph Campbell <rcampbell@nvidia.com> Signed-off-by:
-
Ralph Campbell authored
When migrating system memory to GPU memory, check that SVM has been enabled. Even though most errors can be ignored since migration is a performance optimization, return an error because this is a violation of the API. Signed-off-by:
-
Ralph Campbell authored
find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for this and can call migrate_vma_setup() with a starting address less than vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for the range instead of nouveau skipping that part of the range and migrating the rest. Signed-off-by:
-
Wambui Karuga authored
As there is no need to check for the return value of debugfs_create_file and drm_debugfs_create_files, remove unnecessary checks and error handling in nouveau_drm_debugfs_init. Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:
-
- 06 Apr, 2020 2 commits
-
-
Chris Wilson authored
__i915_gem_object_flush_map() takes a byte range, so feed it the written bytes and do not mistake the u32 index as bytes! Fixes: a679f58d ("drm/i915: Flush pages on acquisition") Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406114821.10949-1-chris@chris-wilson.co.uk (cherry picked from commit 30c88a47) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
If the user passes in a readonly reloc[], by the time we notice we have already committed to modifying the execobjects, or have indeed done so already. Reporting the failure just compounds the issue as we have no second pass to fall back to anymore. "Be damned if you do, and damned if you don't." Testcase: igt/gem_exec_reloc/readonly Fixes: 7dc8f114 ("drm/i915/gem: Drop relocation slowpath") References: fddcd00a ("drm/i915: Force the slow path after a user-write error") Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200331162150.3635-1-chris@chris-wilson.co.uk (cherry picked from commit 97a37c91) Signed-off-by:
-
