aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-02-11drm/mediatek: Ensure the cursor plane is on top of other overlaysSean Paul1-3/+5
Currently the cursor is placed on the first overlay plane, which means it will be at the bottom of the stack when the hw does the compositing with anything other than primary plane. Since mtk doesn't support plane zpos, change the cursor location to the top-most plane. Signed-off-by: Sean Paul <[email protected]> Signed-off-by: CK Hu <[email protected]>
2020-02-11drm/mediatek: Find the cursor plane instead of hard coding itEvan Benn1-6/+12
The cursor and primary planes were hard coded. Now search for them for passing to drm_crtc_init_with_planes Signed-off-by: Evan Benn <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: CK Hu <[email protected]>
2020-02-10drm/i915/gt: Use the BIT when checking the flags, not the indexChris Wilson1-1/+2
In converting over to using set_bit()/test_bit(), when manually inspecting the rq->fence.flags, we need to use BIT(). Fixes: e1c31fb5dde3 ("drm/i915: Merge i915_request.flags with i915_request.fence.flags") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 72ff2b8d5f2dcb09bfa37b902c23311eec426496) Signed-off-by: Jani Nikula <[email protected]>
2020-02-10drm/i915/selftests: Add a mock i915_vma to the mock_ringChris Wilson1-1/+16
Add a i915_vma to the mock_engine/mock_ring so that the core code can always assume the presence of ring->vma. Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit b63b4feaef7363d2cf46dd76bb6e87e060b2b0de) Signed-off-by: Jani Nikula <[email protected]>
2020-02-10drm/i915: Make a copy of the ggtt view for slave planeVille Syrjälä1-0/+1
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever it is present. We copy that from the master plane to the slave plane, but we fail to copy the corresponding ggtt view. Thus when it comes time to pin the slave plane's fb we use some stale ggtt view left over from the last time the plane was used as a non-slave plane. If that previous use involved 90/270 degree rotation or remapping we'll try to shuffle the pages of the new fb around accordingingly. However the new fb may be backed by a bo with less pages than what the ggtt view rotation/remapped info requires, and so we we trip a GEM_BUG(). Steps to reproduce on icl: 1. plane 1: whatever plane 6: largish !NV12 fb + 90 degree rotation 2. plane 1: smallish NV12 fb plane 6: make invisible so it gets slaved to plane 1 3. GEM_BUG() Cc: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951 Fixes: 1f594b209fe1 ("drm/i915: Remove special case slave handling during hw programming, v3.") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> (cherry picked from commit 103605e0d1e77cfb5d0f5a9e8aba7d97f1b49339) Signed-off-by: Jani Nikula <[email protected]>
2020-02-10drm/i915/gem: Take local vma references for the parserChris Wilson1-1/+36
Take and hold a reference to each of the vma (and their objects) as we process them with the cmdparser. This stops them being freed during the work if the GEM execbuf is interrupted and the request we expected to keep the objects alive is incomplete. Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser") Closes: https://gitlab.freedesktop.org/drm/intel/issues/970 Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 36c8e356a76e147f0b631fd29838147c01b50d04) Signed-off-by: Jani Nikula <[email protected]>
2020-02-10drm/i915/pmu: Correct the rc6 offset upon enablingChris Wilson1-0/+12
The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from 0 and then upon first activity (park/unpark) add in all the rc6 residency since boot. After the first park with the sampler engaged, the sleep/active counters are aligned. v2: With a wakeref to be sure Closes: https://gitlab.freedesktop.org/drm/intel/issues/973 Fixes: df6a42053513 ("drm/i915/pmu: Ensure monotonic rc6") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f4e9894b6952a2819937f363cd42e7cd7894a1e4) Signed-off-by: Jani Nikula <[email protected]>
2020-02-10drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error messageGeert Uytterhoeven1-1/+2
The code was changed to call drm_connector_init_with_ddc() instead of drm_connector_init(), but the corresponding error message was not updated. Fixes: cfb444552926989f ("drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-10drm/bridge: tc358767: fix poll timeoutsTomi Valkeinen1-4/+4
Link training fails with: Link training timeout waiting for LT_LOOPDONE! main link enable error: -110 This is caused by too tight timeouts, which were changed recently in aa92213f388b ("drm/bridge: tc358767: Simplify polling in tc_link_training()"). With a quick glance, the commit does not change the timeouts. However, the method of delaying/sleeping is different, and as the timeout in the previous implementation was not explicit, the new version in practice has much tighter timeout. The same change was made to other parts in the driver, but the link training timeout is the only one I have seen causing issues. Nevertheless, 1 us sleep is not very sane, and the timeouts look pretty tight, so lets fix all the timeouts. One exception was the aux busy poll, where the poll sleep was much longer than necessary (or optimal). I measured the times on my setup, and now the sleep times are set to such values that they result in multiple loops, but not too many (say, 5-10 loops). The timeouts were all increased to 100ms, which should be more than enough for all of these, but in case of bad errors, shouldn't stop the driver as multi-second timeouts could do. Signed-off-by: Tomi Valkeinen <[email protected]> Fixes: aa92213f388b ("drm/bridge: tc358767: Simplify polling in tc_link_training()") Tested-by: Andrey Smirnov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-10drm/i915/gvt: more locking for ppgtt mm LRU listIgor Druzhinin1-0/+4
When the lock was introduced in commit 72aabfb862e40 ("drm/i915/gvt: Add mutual lock for ppgtt mm LRU list") one place got lost. Fixes: 72aabfb862e4 ("drm/i915/gvt: Add mutual lock for ppgtt mm LRU list") Signed-off-by: Igor Druzhinin <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-10drm/i915/gvt: fix high-order allocation failure on late loadIgor Druzhinin1-2/+2
If the module happens to be loaded later at runtime there is a chance memory is already fragmented enough to fail allocation of firmware blob storage and consequently GVT init. Since it doesn't seem to be necessary to have the blob contiguous, use vmalloc() instead to avoid the issue. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Igor Druzhinin <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-09Merge tag 'kbuild-v5.6-2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild updates from Masahiro Yamada: - fix randconfig to generate a sane .config - rename hostprogs-y / always to hostprogs / always-y, which are more natual syntax. - optimize scripts/kallsyms - fix yes2modconfig and mod2yesconfig - make multiple directory targets ('make foo/ bar/') work * tag 'kbuild-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: make multiple directory targets work kconfig: Invalidate all symbols after changing to y or m. kallsyms: fix type of kallsyms_token_table[] scripts/kallsyms: change table to store (strcut sym_entry *) scripts/kallsyms: rename local variables in read_symbol() kbuild: rename hostprogs-y/always to hostprogs/always-y kbuild: fix the document to use extra-y for vmlinux.lds kconfig: fix broken dependency in randconfig-generated .config
2020-02-09drm/i915: Fix i915_error_state_store error definationZhang Xiaoxu1-2/+1
Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error capture"), function 'i915_error_state_store' was defined and used with only one parameter. But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined with two parameter. This may lead compile error. This patch fix it. Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhang Xiaoxu <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 04062c58faafddf62006c6f8e5077dc050e8207e) Signed-off-by: Jani Nikula <[email protected]>
2020-02-09drm/i915/bios: Fix the timing parametersVandita Kulkarni1-2/+4
Fix htotal and vtotal parameters derived from DTD block of VBT. The values miss the back porch. Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block") Signed-off-by: Vandita Kulkarni <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ad278f358446707d03a1fe89f880e6ac80ca06cd) Signed-off-by: Jani Nikula <[email protected]>
2020-02-09drm/i915/dsi: Ensure that the ACPI adapter lookup overrides the bus numVivek Kasireddy1-2/+1
Remove the i2c_bus_num >= 0 check from the adapter lookup function as this would prevent ACPI bus number override. This check was mainly there to return early if the bus number has already been found but we anyway return in the next line if the slave address does not match. Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <[email protected]> Cc: Nabendu Maiti <[email protected]> Cc: Matt Roper <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit de409661c4c90d63cfc64579edbad0a6b10bd50d) Signed-off-by: Jani Nikula <[email protected]>
2020-02-09drm/i915: Fix post-fastset modeset check for port syncVille Syrjälä1-26/+17
The post-fastset "does anyone still need a full modeset?" for port sync looks busted. The outer loop bails out of a full modeset is still needed by the current crtc, and then we skip forcing a full modeset on the related crtcs. That's totally the opposite of what we want. The MST path has the logic mostly the other way around so it looks correct. To fix the port sync case let's follow the MST logic for both. So, if the current crtc already needs a modeset we do nothing. otherwise we check if any of the related crtcs needs a modeset, and if so we force a full modeset for the current crtc. And while at let's change the else if to a plain if to so we don't have needless coupling between the MST and port sync checks. Cc: José Roberto de Souza <[email protected]> Cc: Manasi Navare <[email protected]> Fixes: 05a8e45136ca ("drm/i915/display: Use external dependency loop for port sync") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit d0eed1545fe75f115a548691a008e94b0e7abc45) Signed-off-by: Jani Nikula <[email protected]>
2020-02-09drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v2)Vivek Kasireddy1-16/+31
Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is enabled in the kernel config. If ACPI is not enabled or if the lookup fails, we'll fallback to using the VBT for identifying the i2c bus. v2: Add fixes tag (Jani) Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <[email protected]> Cc: Nabendu Maiti <[email protected]> Cc: Matt Roper <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Zhang Xiaoxu <[email protected]> Reported-by: Hulk Robot <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 960287ca58fd549af9826ff1cb735fe17d031486) Signed-off-by: Jani Nikula <[email protected]>
2020-02-07Merge tag 'drm-next-2020-02-07' of git://anongit.freedesktop.org/drm/drmLinus Torvalds111-940/+4507
Pull drm fixes from Dave Airlie: "Just some fixes for this merge window: the tegra changes fix some regressions in the merge, nouveau has a few modesetting fixes. The amdgpu fixes are bit bigger, but they contain a couple of weeks of fixes, and don't seem to contain anything that isn't really a fix. Summary: tegra: - merge window regression fixes nouveau: - couple of volta/turing modesetting fixes amdgpu: - EDC fixes for Arcturus - GDDR6 memory training fixe - Fix for reading gfx clockgating registers while in GFXOFF state - i2c freq fixes - Misc display fixes - TLB invalidation fix when using semaphores - VCN 2.5 instancing fixes - Switch raven1 gfxoff to a blacklist - Coreboot workaround for KV/KB - Root cause dongle fixes for display and revert workaround - Enable GPU reset for renoir and navi - Navi overclocking fixes - Fix up confusing warnings in display clock validation on raven amdkfd: - SDMA fix radeon: - Misc LUT fixes" * tag 'drm-next-2020-02-07' of git://anongit.freedesktop.org/drm/drm: (90 commits) gpu: host1x: Set DMA direction only for DMA-mapped buffer objects drm/tegra: Reuse IOVA mapping where possible drm/tegra: Relax IOMMU usage criteria on old Tegra drm/amd/dm/mst: Ignore payload update failures drm/amdgpu: update default voltage for boot od table for navi1x drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_latency drm/amdgpu/display: handle multiple numbers of fclks in dcn_calcs.c (v2) drm/amdgpu: fetch default VDDC curve voltages (v2) drm/amdgpu/smu_v11_0: Correct behavior of restoring default tables (v2) drm/amdgpu/navi10: add OD_RANGE for navi overclocking drm/amdgpu/navi: fix index for OD MCLK drm/amd/display: Fix HW/SW state mismatch drm/amd/display: Fix a typo when computing dsc configuration drm/amd/powerplay: fix navi10 system intermittent reboot issue V2 drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode drm/amd/display: Only enable cursor on pipes that need it drm/nouveau/kms/gv100-: avoid sending a core update until the first modeset drm/nouveau/kms/gv100-: move window ownership setup into modesetting path drm/nouveau/disp/gv100-: halt NV_PDISP_FE_RM_INTR_STAT_CTRL_DISP_ERROR storms ...
2020-02-07Merge tag 'amd-drm-next-5.6-2020-02-05' of ↵Dave Airlie101-867/+4334
git://people.freedesktop.org/~agd5f/linux into drm-next amd-drm-next-5.6-2020-02-05: amdgpu: - EDC fixes for Arcturus - GDDR6 memory training fixe - Fix for reading gfx clockgating registers while in GFXOFF state - i2c freq fixes - Misc display fixes - TLB invalidation fix when using semaphores - VCN 2.5 instancing fixes - Switch raven1 gfxoff to a blacklist - Coreboot workaround for KV/KB - Root cause dongle fixes for display and revert workaround - Enable GPU reset for renoir and navi - Navi overclocking fixes - Fix up confusing warnings in display clock validation on raven amdkfd: - SDMA fix radeon: - Misc LUT fixes Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-07Merge branch 'linux-5.6' of git://github.com/skeggsb/linux into drm-nextDave Airlie5-10/+50
Just a couple of fixes to Volta/Turing modesetting on some systems. Signed-off-by: Dave Airlie <[email protected]> From: Ben Skeggs <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv7=eP+Ai1ouoMyYyo1xMF0pTQki=owYjJkS=NpvKQd1fg@mail.gmail.com
2020-02-07Merge tag 'drm/tegra/for-5.6-rc1-fixes' of ↵Dave Airlie5-63/+123
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Fixes for v5.6-rc1 These are a couple of quick fixes for regressions that were found during the first two weeks of the merge window. Signed-off-by: Dave Airlie <[email protected]> From: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-06drm/edid: fix building errorMauro Rossi1-1/+1
Fixes the following building error: CC [M]  drivers/gpu/drm/drm_edid.o ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function 'cea_mode_alternate_timings': ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2: error: call to '__compiletime_assert_3282' declared with attribute error: BUILD_BUG_ON failed: cea_mode_for_vic(8)->vtotal != 262 || cea_mode_for_vic(9)->vtotal != 262 || cea_mode_for_vic(12)->vtotal != 262 || cea_mode_for_vic(13)->vtotal != 262 || cea_mode_for_vic(23)->vtotal != 312 || cea_mode_for_vic(24)->vtotal != 312 || cea_mode_for_vic(27)->vtotal != 312 || cea_mode_for_vic(28)->vtotal != 312 make[4]: *** [~/pie-x86_kernel/kernel/scripts/Makefile.build:265: drivers/gpu/drm/drm_edid.o] Error 1 Fixes: 7befe621ff81 ("drm/edid: Abstract away cea_edid_modes[]") Signed-off-by: Mauro Rossi <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-06drm/vgem: Close use-after-free race in vgem_gem_createDaniel Vetter1-3/+6
There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter <[email protected]> Cc: Hillf Danton <[email protected]> Reported-by: [email protected] Cc: [email protected] Cc: Emil Velikov <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sean Paul <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Rob Clark <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-06gpu: host1x: Set DMA direction only for DMA-mapped buffer objectsThierry Reding1-1/+1
The DMA direction is only used by the DMA API, so there is no use in setting it when a buffer object isn't mapped with the DMA API. Signed-off-by: Thierry Reding <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]>
2020-02-06drm/tegra: Reuse IOVA mapping where possibleThierry Reding3-23/+63
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately, the cache maintenance performed by dma_map_sg() and dma_unmap_sg() causes performance to drop by a factor of 10. The right solution for this would be to cache mappings for buffers per consumer device, but that's a bit involved. Instead, we simply revert to the old behaviour of sharing IOVA mappings when we know that devices can do so (i.e. they share the same IOMMU domain). Cc: <[email protected]> # v5.5 Reported-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]>
2020-02-06drm/tegra: Relax IOMMU usage criteria on old TegraThierry Reding1-17/+32
Older Tegra devices only allow addressing 32 bits of memory, so whether or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU attachment is only needed on devices that can address memory beyond the 32-bit boundary and where the host1x doesn't support the wide GATHER opcode that allows it to access buffers at higher addresses. Cc: <[email protected]> # v5.5 Signed-off-by: Thierry Reding <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]>
2020-02-04drm/amd/dm/mst: Ignore payload update failuresLyude Paul1-9/+4
Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ffffac428127f5b0 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8d1e166eee80 RCX: 0000000000000000 RDX: ffffac428127f668 RSI: ffff8d1e166eee80 RDI: ffffac428127f610 RBP: ffffac428127f640 R08: ffffffffc03d94a8 R09: 0000000000000000 R10: ffff8d1e24b02000 R11: ffffac428127f5b0 R12: ffff8d1e1b83d000 R13: ffff8d1e1bea0b08 R14: 0000000000000002 R15: 0000000000000002 FS: 00007fab23ffcd80(0000) GS:ffff8d1e28b40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f151f1711e8 CR3: 00000005997c0000 CR4: 00000000003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 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 dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd045f9068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd045f90a0 RCX: 00007fab2121f87b RDX: 00007ffd045f90a0 RSI: 00000000c06864a2 RDI: 000000000000000b RBP: 00007ffd045f90a0 R08: 0000000000000000 R09: 000055dbd2985d10 R10: 000055dbd2196280 R11: 0000000000000246 R12: 00000000c06864a2 R13: 000000000000000b R14: 0000000000000000 R15: 000055dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only been able to reproduce this on setups with 2 MST displays. Changes since v1: * Don't return false when part 1 or part 2 of updating the payloads fails, we don't want to abort at any step of the process even if things fail Reviewed-by: Mikita Lipski <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Acked-by: Harry Wentland <[email protected]> Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amdgpu: update default voltage for boot od table for navi1xAlex Deucher1-1/+8
It needed to be updated as well so it will show the proper values if you reset to the defaults. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltageAlex Deucher1-3/+5
Cull out 0 clocks to avoid a warning in DC. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_latencyAlex Deucher1-6/+9
Only send non-0 clocks to DC for validation. This mirrors what the windows driver does. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amdgpu/display: handle multiple numbers of fclks in dcn_calcs.c (v2)Alex Deucher1-11/+23
We might get different numbers of clocks from powerplay depending on what the OEM has populated. v2: add assert for at least one level Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amdgpu: fetch default VDDC curve voltages (v2)Alex Deucher1-1/+49
Ask the SMU for the default VDDC curve voltage values. This properly reports the VDDC values in the OD interface. v2: only update if the original values are 0 Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 5.5.x
2020-02-04drm/amdgpu/smu_v11_0: Correct behavior of restoring default tables (v2)Matt Coffin4-20/+22
Previously, the syfs functionality for restoring the default powerplay table was sourcing it's information from the currently-staged powerplay table. This patch adds a step to cache the first overdrive table that we see on boot, so that it can be used later to "restore" the powerplay table v2: sqaush my original with Matt's fix Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Signed-off-by: Matt Coffin <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 5.5.x
2020-02-04drm/amdgpu/navi10: add OD_RANGE for navi overclockingAlex Deucher1-0/+59
So users can see the range of valid values. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 5.5.x
2020-02-04drm/amdgpu/navi: fix index for OD MCLKAlex Deucher1-1/+1
You can only adjust the max mclk, not the min. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 5.5.x
2020-02-04drm/amd/display: Fix HW/SW state mismatchBhawanpreet Lakha1-0/+19
[Why] When we disable a connector we don't explicitly remove it from the module so the display is still cached(SW) in the hdcp_module. SST: no issues because we can only have 1 display per link MST: We have x displays per link, now if we disable 1 we don't remove it from the module so the module has x display cached(SW). If we try to enable HDCP, psp verification will fail because we are reporting x displays while the HW only has x-1 display enabled [How] Check the callback for when we disable stream and call remove display. Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amd/display: Fix a typo when computing dsc configurationMikita Lipski1-1/+1
[why] Remove a backslash symbol accidentally left in increase bpp function when computing mst dsc configuration. Signed-off-by: Mikita Lipski <[email protected]> Reviewed-by: Zhan Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amd/powerplay: fix navi10 system intermittent reboot issue V2Evan Quan6-1/+86
This workaround is needed only for Navi10 12 Gbps SKUs. V2: added SMU firmware version guard Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-02-04drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS modeYong Zhao1-4/+6
The sdma_queue_count increment should be done before execute_queues_cpsch(), which calls pm_calc_rlib_size() where sdma_queue_count is used to calculate whether over_subscription is triggered. With the previous code, when a SDMA queue is created, compute_queue_count in pm_calc_rlib_size() is one more than the actual compute queue number, because the queue_count has been incremented while sdma_queue_count has not. This patch fixes that. Signed-off-by: Yong Zhao <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04drm/amd/display: Only enable cursor on pipes that need itNicholas Kazlauskas1-0/+30
[Why] In current code we're essentially drawing the cursor on every pipe that contains it. This only works when the planes have the same scaling for src to dest rect, otherwise we'll get "double cursor" where one cursor is incorrectly filtered and offset from the real position. [How] Without dedicated cursor planes on DCN we require at least one pipe that matches the scaling of the current timing. This is an optimization and workaround for the most common case where the top-most plane is not scaled but the bottom-most plane is scaled. Whenever a pipe has a parent pipe in the blending tree whose recout fully contains the current pipe we can disable the pipe. This only applies when the pipe is actually visible of course. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-04Merge tag 'drm-next-2020-02-04' of git://anongit.freedesktop.org/drm/drmLinus Torvalds1-7/+15
Pull drm ttm/mm updates from Dave Airlie: "Thomas Hellstrom has some more changes to the TTM layer that needed a patch to the mm subsystem. This adds a new mm API vmf_insert_mixed_prot to avoid an ugly hack that has limitations in the TTM layer" * tag 'drm-next-2020-02-04' of git://anongit.freedesktop.org/drm/drm: mm, drm/ttm: Fix vm page protection handling mm: Add a vmf_insert_mixed_prot() function
2020-02-03Merge tag 'clk-for-linus' of ↵Linus Torvalds2-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "There are a few changes to the core framework this time around, in addition to the normal collection of driver updates to support new SoCs, fix incorrect data, and convert various drivers to clk_hw based APIs. In the core, we allow clk_ops::init() to return an error code now so that we can fail clk registration if the callback does something like fail to allocate memory. We also add a new "terminate" clk_op so that things done in clk_ops::init() can be undone, e.g. free memory. We also spit out a warning now when critical clks fail to enable and we support changing clk rates and enable/disable state through debugfs when developers compile the kernel themselves. On the driver front, we get support for what seems like a lot of Qualcomm and NXP SoCs given that those vendors dominate the diffstat. There are a couple new drivers for Xilinx and Amlogic SoCs too. The updates are all small things like fixing the way glitch free muxes switch parents, avoiding div-by-zero problems, or fixing data like parent names. See the updates section below for more details. Finally, the "basic" clk types have been converted to support specifying parents with clk_hw pointers. This work includes an overhaul of the fixed-rate clk type to be more modern by using clk_hw APIs. Core: - Let clk_ops::init() return an error code - Add a clk_ops::terminate() callback to undo clk_ops::init() - Warn about critical clks that fail to enable or prepare - Support dangerous debugfs actions on clks with dead code New Drivers: - Support for Xilinx Versal platform clks - Display clk controller on qcom sc7180 - Video clk controller on qcom sc7180 - Graphics clk controller on qcom sc7180 - CPU PLLs for qcom msm8916 - Move qcom msm8974 gfx3d clk to RPM control - Display port clk support on qcom sdm845 SoCs - Global clk controller on qcom ipq6018 - Add a driver for BCLK of Freescale SAI cores - Add cam, vpe and sgx clock support for TI dra7 - Add aess clock support for TI omap5 - Enable clks for CPUfreq on Allwinner A64 SoCs - Add Amlogic meson8b DDR clock controller - Add input clocks to Amlogic meson8b controllers - Add SPIBSC (SPI FLASH) clock on Renesas RZ/A2 - i.MX8MP clk driver support Updates: - Convert gpio, fixed-factor, mux, gate, divider basic clks to hw based APIs - Detect more PRMCU variants in ux500 driver - Adjust the composite clk type to new way of describing clk parents - Fixes for clk controllers on qcom msm8998 SoCs - Fix gmac main clock for TI dra7 - Move TI dra7-atl clock header to correct location - Fix hidden node name dependency on TI clkctrl clocks - Fix Amlogic meson8b mali clock update using the glitch free mux - Fix Amlogic pll driver division by zero at init - Prepare for split of Renesas R-Car H3 ES1.x and ES2.0+ config symbols - Switch more i.MX clk drivers to clk_hw based APIs - Disable non-functional divider between pll4_audio_div and pll4_post_div on imx6q - Fix watchdog2 clock name typo in imx7ulp clock driver - Set CLK_GET_RATE_NOCACHE flag for DRAM related clocks on i.MX8M SoCs - Suppress bind attrs for i.MX8M clock driver - Add a big comment in imx8qxp-lpcg driver to tell why devm_platform_ioremap_resource() shouldn't be used for the driver - A correction on i.MX8MN usb1_ctrl parent clock setting" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (140 commits) dt/bindings: clk: fsl,plldig: Drop 'bindings' from schema id clk: ls1028a: Fix warning on clamp() usage clk: qoriq: add ls1088a hwaccel clocks support clk: ls1028a: Add clock driver for Display output interface dt/bindings: clk: Add YAML schemas for LS1028A Display Clock bindings clk: fsl-sai: new driver dt-bindings: clock: document the fsl-sai driver clk: composite: add _register_composite_pdata() variants clk: qcom: rpmh: Sort OF match table dt-bindings: fix warnings in validation of qcom,gcc.yaml dt-binding: fix compilation error of the example in qcom,gcc.yaml clk: zynqmp: Add support for clock with CLK_DIVIDER_POWER_OF_TWO flag clk: zynqmp: Fix divider calculation clk: zynqmp: Add support for get max divider clk: zynqmp: Warn user if clock user are more than allowed clk: zynqmp: Extend driver for versal dt-bindings: clock: Add bindings for versal clock driver clk: ti: clkctrl: Fix hidden dependency to node name clk: ti: add clkctrl data dra7 sgx clk: ti: omap5: Add missing AESS clock ...
2020-02-04kbuild: rename hostprogs-y/always to hostprogs/always-yMasahiro Yamada1-1/+1
In old days, the "host-progs" syntax was used for specifying host programs. It was renamed to the current "hostprogs-y" in 2004. It is typically useful in scripts/Makefile because it allows Kbuild to selectively compile host programs based on the kernel configuration. This commit renames like follows: always -> always-y hostprogs-y -> hostprogs So, scripts/Makefile will look like this: always-$(CONFIG_BUILD_BIN2C) += ... always-$(CONFIG_KALLSYMS) += ... ... hostprogs := $(always-y) $(always-m) I think this makes more sense because a host program is always a host program, irrespective of the kernel configuration. We want to specify which ones to compile by CONFIG options, so always-y will be handier. The "always", "hostprogs-y", "hostprogs-m" will be kept for backward compatibility for a while. Signed-off-by: Masahiro Yamada <[email protected]>
2020-02-03drm/nouveau/kms/gv100-: avoid sending a core update until the first modesetBen Skeggs2-6/+2
The OR routing logic in NVKM does not expect to receive supervisor interrupts until the DD has provided consistent information on the ORs it's using and the EVO/NVD assembly state to match. The combination of changing window ownership + core channel update during display init triggered a situation where we'd disconnect an OR from the pad it was meant to still be driving on some systems. Signed-off-by: Ben Skeggs <[email protected]>
2020-02-03drm/nouveau/kms/gv100-: move window ownership setup into modesetting pathBen Skeggs4-6/+44
For various complicated reasons, we need to avoid sending a core update method during display init. Something, which we've been required to do on GV100 and up because we've been assigning windows to heads there and the HW is rather picky about when that's allowed. This moves window assignment into the modesetting path at a point where it's much safer to send our first update methods to NVDisplay. Signed-off-by: Ben Skeggs <[email protected]>
2020-02-03drm/nouveau/disp/gv100-: halt NV_PDISP_FE_RM_INTR_STAT_CTRL_DISP_ERROR stormsBen Skeggs1-0/+6
Signed-off-by: Ben Skeggs <[email protected]>
2020-02-03drm/panfrost: Make sure the shrinker does not reclaim referenced BOsBoris Brezillon4-1/+16
Userspace might tag a BO purgeable while it's still referenced by GPU jobs. We need to make sure the shrinker does not purge such BOs until all jobs referencing it are finished. Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-31drm/tegra: sor: Initialize runtime PM before useThierry Reding1-15/+17
Commit fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") replaced the generic runtime PM usage by a host1x bus-specific implementation in order to work around some assumptions baked into runtime PM that are in conflict with the requirements in the Tegra DRM driver. Unfortunately the new runtime PM callbacks are not setup yet at the time when the SOR driver first needs to resume the device to register the SOR pad clock, and accesses to register will cause the system to hang. Note that this only happens on Tegra124 and Tegra210 because those are the only SoCs where the SOR pad clock is registered from the SOR driver. Later generations use a SOR pad clock provided by the BPMP. Fix this by moving the registration of the SOR pad clock after the host1x client has been registered. That's somewhat suboptimal because this could potentially, though it's very unlikely, cause the Tegra DRM to be probed if the SOR happens to be the last subdevice to register, only to be immediately removed again if the SOR pad output clock fails to register. That's just a minor annoyance, though, and doesn't justify implementing a workaround. Fixes: fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") Signed-off-by: Thierry Reding <[email protected]>
2020-01-31drm/tegra: sor: Disable runtime PM on probe failureThierry Reding1-6/+8
If the driver fails to probe, make sure to disable runtime PM again. While at it, make the cleanup code in ->remove() symmetric. Signed-off-by: Thierry Reding <[email protected]>
2020-01-31drm/tegra: sor: Suspend on clock registration failureThierry Reding1-6/+7
Make sure the SOR module is suspenden after we fail to register the SOR pad output clock. Signed-off-by: Thierry Reding <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.