- 14 Jul, 2017 9 commits
-
-
Alex Deucher authored
No need to do this as the vbios does this for us. As such we no longer need to stop the mc during init. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
No need to do this as the vbios does this for us. As such we no longer need to stop the mc during init. Reviewed-by:
-
Alex Deucher authored
This makes mc programming much simpler in future patches. Since evergreen, the vbios has been programming the fb location to the proper vram size. The only reason to reprogram it would be to change the location. Reviewed-by:
-
Alex Deucher authored
This makes mc programming much simpler in future patches. Since evergreen, the vbios has been programming the fb location to the proper vram size. The only reason to reprogram it would be to change the location. Reviewed-by:
-
Alex Deucher authored
This makes mc programming much simpler in future patches. Since evergreen, the vbios has been programming the fb location to the proper vram size. The only reason to reprogram it would be to change the location. Reviewed-by:
-
Alex Deucher authored
This got dropped accidently with the fb location changes, but for some reason, this doesn't seem to cause an issue on all cards which is why I never saw it despite extensive testing. I suspect it may only be an issue on systems with a legacy sbios that enables vga. Tested-by:
Andres Rodriguez <andresx7@gmail.com> Signed-off-by:
-
Christian König authored
Now that we don't join PTE updates any more we don't need to call the update function twice for this. v2: rebased Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Hawking Zhang authored
v1: enable 4 level-page table on raven v2: add back legacy 2 level page table on raven v3: set num_level in initial switch statement Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
Alex Deucher authored
Use the kernel provided version. Reviewed-by:
-
- 13 Jul, 2017 4 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
single r700 fix. * 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: Fix eDP for single-display iMac10,1 (v2)
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2017-07-10' of git://anongit.freedesktop.org/git/drm-misc into drm-next Core Changes: - Fix empty timestamps on hw without vlbank counter (Laurent) - Clear atomic state before retrying ww/mutex acquisition in remove_fb (Maarten) Driver Changes: - rockchip: Fix incorrect NULL pointer check after allocation (Gustavo) Cc: Gustavo A. R. Silva <garsilva@embeddedor.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> * tag 'drm-misc-next-fixes-2017-07-10' of git://anongit.freedesktop.org/git/drm-misc: drm/rockchip: fix NULL check on devm_kzalloc() return value drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb drm: vblank: Fix vblank timestamp update DRM: Fix an incorrectly formatted table bridge: Fix panel-bridge error return on !panel. drm/rockchip: gem: add the lacks lock and trivial changes
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2017-07-11' of git://anongit.freedesktop.org/git/drm-intel into drm-next drm/i915 fixes for v4.13-rc1 * tag 'drm-intel-next-fixes-2017-07-11' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: Make DP-MST connector info work drm/i915/gvt: Use fence error from GVT request for workload status drm/i915/gvt: remove scheduler_mutex in per-engine workload_thread drm/i915/gvt: Revert "drm/i915/gvt: Fix possible recursive locking issue" drm/i915/gvt: Audit the command buffer address drm/i915/gvt: Fix a memory leak in intel_gvt_init_gtt() drm/i915/fbdev: Check for existence of ifbdev->vma before operations drm/i915: Hold RPM wakelock while initializing OA buffer drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming drm/i915/cfl: Fix Workarounds. drm/i915: Avoid undefined behaviour of "u32 >> 32" drm/i915: reintroduce VLV/CHV PFI programming power domain workaround drm/i915: Fix an error checking test drm/i915: Disable MSI for all pre-gen5 drm/i915/gvt: Make function dpy_reg_mmio_readx safe drm/i915/gvt: Don't read ADPA_CRT_HOTPLUG_MONITOR from host drm/i915/gvt: Set initial PORT_CLK_SEL vreg for BDW drm/i915/gvt: Fix inconsistent locks holding sequence drm/i915/gvt: Fix possible recursive locking issue
-
Dave Airlie authored
Merge branch 'mediatek-drm-next-4.13' of https://github.com/ckhu-mediatek/linux.git-tags into drm-next This include new color format support and some fixups. * 'mediatek-drm-next-4.13' of https://github.com/ckhu-mediatek/linux.git-tags: drm/mediatek: separate color module to fixup error memory reallocation drm/mediatek: check for memory allocation failure drm/mediatek: re-phrase DRM_INFO error message drm/mediatek: use platform_register_drivers drm/mediatek: Support UYVY and YUYV format for overlay
-
- 11 Jul, 2017 7 commits
-
-
https://github.com/01org/gvt-linuxJani Nikula authored
gvt-fixes-2017-07-11 - Revert "drm/i915/gvt: Fix possible recursive locking issue" (Chuanxiao), which is incomplete fix and it's actually VFIO issue, so revert. - remove unneeded scheduler mutex for performance fix (Weinan) - other misc error handling fix and cmd address audit Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711055333.jhrmvx6ilvg2qlnn@zhen-hp.sh.intel.com
-
Maarten Lankhorst authored
Commit 9a148a96 ("drm/i915/debugfs: add dp mst info") adds support for DP-MST to intel_connector_info, but forgot to remove the early return for DP-MST. Remove it, and print out MST connectors directly. Fixes: 9a148a96 ("drm/i915/debugfs: add dp mst info") Cc: <stable@vger.kernel.org> # v4.11+ Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626083349.24389-1-maarten.lankhorst@linux.intel.comReviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> (cherry picked from commit 77d1f615) Signed-off-by:
-
Chuanxiao Dong authored
The req->fence.error will be set if this request caused GPU hang so we can use this value to workload->status to indicate whether this GVT request caused any problem. If it caused GPU hang, we shouldn't trigger any context switch back to the guest. v2: - only take -EIO from fence->error. (Zhenyu) Fixes: 8f1117ab (drm/i915/gvt: handle workload lifecycle properly) Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Weinan Li authored
For the vGPU workloads, now GVT-g use per vGPU scheduler, the per-ring work_thread only pick workload belongs to the current vGPU. And with time slice based scheduler, it waits all the engines become idle before do vGPU switch. So we can run free dispatch in per-ring work_thread, different ring running in different 'vGPU' won't happen. For the workloads between vGPU and Host, this scheduler_mutex can't block host to dispatch workload into other ring engines. Here remove this mutex since it impacts the performance when applications use more than 1 ring engines in 1 vgpu. ring0 running in vGPU1, ring1 running in Host. Will happen. ring0 running in vGPU1, ring1 running in vGPU2. Won't happen. Signed-off-by:
Weinan Li <weinan.z.li@intel.com> Signed-off-by:
Ping Gao <ping.a.gao@intel.com> Signed-off-by:
-
Chuanxiao Dong authored
This reverts commit 62d02fd1. The rwsem recursive trace should not be fixed from kvmgt side by using a workqueue and it is an issue should be fixed in VFIO. So this one should be reverted. Signed-off-by:
-
Ping Gao authored
The command buffer address in context like ring buffer base address and wa_ctx address need to be audit to make sure they are in the valid GGTT range. Signed-off-by:
-
Zhou, Wenjia authored
It will causes memory leak, if the function setup_spt_oos() fail, in the function intel_gvt_init_gtt(), which allocated by get_zeroed_page() and mapped by dma_map_page(). Unmap and free the page, after STP oos initialize fail, it will fix this issue. Signed-off-by:
Zhou, Wenjia <zhiyuan_zhu@htc.com> Signed-off-by:
-
- 10 Jul, 2017 2 commits
-
-
Gustavo A. R. Silva authored
The right variable to check here is port, not dp. This issue was detected using Coccinelle and the following semantic patch: @@ expression x; identifier fld; @@ * x = devm_kzalloc(...); ... when != x == NULL x->fld Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by:
Mark Yao <mark.yao@rock-chips.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170706215833.GA25411@embeddedgus
-
Chris Wilson authored
Commit fabef825 ("drm/i915: Drop struct_mutex around frontbuffer flushes") adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only against the existence of the ifbdev->fb and not against ifbdev->vma. This leaves a window of opportunity where we may try to operate on the fbdev prior to it being probed (thanks to asynchronous booting). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534 Fixes: fabef825 ("drm/i915: Drop struct_mutex around frontbuffer flushes") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170622160211.783-1-chris@chris-wilson.co.ukReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org (cherry picked from commit 15727ed0) Signed-off-by:
-
- 07 Jul, 2017 1 commit
-
-
Mario Kleiner authored
The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via MiniDP to DVI or HDMI adapter. However, booting the machine single-display with only eDP panel results in a completely black display - even backlight powering off, as soon as the radeon modesetting driver loads. This patch fixes the single dispay eDP case by assigning encoders based on dig->linkb, similar to DCE-4+. While this should not be generally necessary (Alex: "...atom on normal boards should be able to handle any mapping."), Apple seems to use some special routing here. One remaining problem not solved by this patch is that an external Minidisplayport->DP sink does still not work on iMac10,1, whereas external DVI and HDMI sinks continue to work. The problem affects at least all tested kernels since Linux 3.13 - didn't test earlier kernels, so backporting to stable probably makes sense. v2: With the original patch from 2016, Alex was worried it will break other DCE3.2 systems. Use dmi_match() to apply this special encoder assignment only for the Apple iMac 10,1 from late 2009. Signed-off-by:Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 06 Jul, 2017 2 commits
-
-
Chris Wilson authored
the drm_file parameter is unused, so remove it. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Fixes for 4.13: - Various fixes for Raven - Various fixes for Vega10 - Stability fixes for KIQ - Fix reloading the driver - Fix S3 on vega10 - Misc other fixes * 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux: (26 commits) drm/amd/powerplay: fix bug fail to remove sysfs when rmmod amdgpu. amdgpu: Set cik/si_support to 1 by default if radeon isn't built drm/amdgpu/gfx9: fix driver reload with KIQ drm/amdgpu/gfx8: fix driver reload with KIQ drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay drm/ttm: Fix use-after-free in ttm_bo_clean_mm drm/amd/amdgpu: move get memory type function from early init to sw init drm/amdgpu/cgs: always set reference clock in mode_info drm/amdgpu: fix vblank_time when displays are off drm/amd/powerplay: power value format change for Vega10 drm/amdgpu/gfx9: support the amdgpu.disable_cu option drm/amd/powerplay: change PPSMC_MSG_GetCurrPkgPwr for Vega10 drm/amdgpu: Make amdgpu_cs_parser_init static (v2) drm/amdgpu/cs: fix a typo in a comment drm/amdgpu: Fix the exported always on CU bitmap drm/amdgpu/gfx9: gfx_v9_0_enable_gfx_static_mg_power_gating() can be static drm/amdgpu/psp: upper_32_bits/lower_32_bits for address setup drm/amd/powerplay/cz: print message if smc message fails drm/amdgpu: fix typo in amdgpu_debugfs_test_ib_init drm/amdgpu: enable mmhub pg on raven ...
-
- 05 Jul, 2017 1 commit
-
-
Rex Zhu authored
when hw_fini, pp will disable dpm.so remove sysfs before disable dpm. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Tested-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
- 04 Jul, 2017 3 commits
-
-
Michel Dänzer authored
It was required to explicitly set these parameters to 1, even if the radeon driver isn't built at all, which is not intuitive. Reported-by:
Shawn Starr <shawn.starr@rogers.com> Signed-off-by:
-
Alex Deucher authored
Drop the KCQ disabling via KIQ. We disable the MEC shortly after anyway, so there is no need to wait for all of this. Doing so seems to leave the MEC in a bad way. Acked-by:
-
Alex Deucher authored
Drop the deactivation in KIQ init and drop the KCQ disabling via KIQ. We disable the MEC shortly after anyway, so there is no need to wait for all of this. Doing so seems to leave the MEC in a bad way. Tested-by:
-
- 03 Jul, 2017 10 commits
-
-
John Brooks authored
amd_powerplay_destroy() expects a handle pointing to a struct pp_instance. On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The resulting attempt to kfree() fields of the wrong struct ends in fire: [ 91.560405] BUG: unable to handle kernel paging request at ffffebe000000620 [ 91.560414] IP: kfree+0x57/0x160 [ 91.560416] PGD 0 [ 91.560416] P4D 0 [ 91.560420] Oops: 0000 [#1] SMP [ 91.560422] Modules linked in: tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [ 91.560438] CPU: 6 PID: 3598 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [ 91.560443] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [ 91.560448] task: ffff8805063d6a00 task.stack: ffffc90003400000 [ 91.560451] RIP: 0010:kfree+0x57/0x160 [ 91.560454] RSP: 0018:ffffc90003403cc0 EFLAGS: 00010286 [ 91.560457] RAX: 000077ff80000000 RBX: 00000000000186a0 RCX: 0000000180400035 [ 91.560460] RDX: 0000000180400036 RSI: ffffea001418e740 RDI: ffffea0000000000 [ 91.560463] RBP: ffffc90003403cd8 R08: 000000000639d201 R09: 0000000180400035 [ 91.560467] R10: ffffebe000000600 R11: 0000000000000300 R12: ffff880500530030 [ 91.560470] R13: ffffffffa01e70fc R14: 00000000ffffffff R15: ffff880500530000 [ 91.560473] FS: 00007f7e500c3700(0000) GS:ffff88051ed80000(0000) knlGS:0000000000000000 [ 91.560478] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 91.560480] CR2: ffffebe000000620 CR3: 0000000503103000 CR4: 00000000001406e0 [ 91.560483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 91.560487] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 91.560489] Call Trace: [ 91.560530] amd_powerplay_destroy+0x1c/0x60 [amdgpu] [ 91.560558] amdgpu_pp_late_fini+0x44/0x60 [amdgpu] [ 91.560575] amdgpu_fini+0x254/0x490 [amdgpu] [ 91.560593] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [ 91.560610] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [ 91.560622] drm_dev_unregister+0x3c/0xe0 [drm] [ 91.560638] amdgpu_pci_remove+0x19/0x30 [amdgpu] [ 91.560643] pci_device_remove+0x39/0xc0 [ 91.560648] device_release_driver_internal+0x155/0x210 [ 91.560651] driver_detach+0x38/0x70 [ 91.560655] bus_remove_driver+0x4c/0xa0 [ 91.560658] driver_unregister+0x2c/0x40 [ 91.560662] pci_unregister_driver+0x21/0x90 [ 91.560689] amdgpu_exit+0x15/0x406 [amdgpu] [ 91.560694] SyS_delete_module+0x1a8/0x270 [ 91.560698] ? exit_to_usermode_loop+0x92/0xa0 [ 91.560702] entry_SYSCALL_64_fastpath+0x13/0x94 [ 91.560705] RIP: 0033:0x7f7e4fc118e7 [ 91.560708] RSP: 002b:00007fff978ca118 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 91.560713] RAX: ffffffffffffffda RBX: 000055afe21bc200 RCX: 00007f7e4fc118e7 [ 91.560716] RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055afe21bc268 [ 91.560719] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [ 91.560722] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fff978c9100 [ 91.560725] R13: 0000000000000000 R14: 0000000000000000 R15: 000055afe21bc200 [ 91.560728] Code: 00 00 00 80 ff 77 00 00 48 bf 00 00 00 00 00 ea ff ff 49 01 da 48 0f 42 05 57 33 bd 00 49 01 c2 49 c1 ea 0c 49 c1 e2 06 49 01 fa <49> 8b 42 20 48 8d 78 ff a8 01 4c 0f 45 d7 49 8b 52 20 48 8d 42 [ 91.560759] RIP: kfree+0x57/0x160 RSP: ffffc90003403cc0 [ 91.560761] CR2: ffffebe000000620 [ 91.560765] ---[ end trace 08a9f3cd82223c1d ]--- Fixes: 1c863802 (drm/amd/powerplay: refine powerplay interface.) Signed-off-by:
John Brooks <john@fastquake.com> Acked-by:
-
John Brooks authored
We unref the man->move fence in ttm_bo_clean_mm() and then call ttm_bo_force_list_clean() which waits on it, except the refcount is now zero so a warning is generated (or worse): [149492.279301] refcount_t: increment on 0; use-after-free. [149492.279309] ------------[ cut here ]------------ [149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30 [149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu( -) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [149492.279327] task: ffff8804ddfedcc0 task.stack: ffffc90008d20000 [149492.279329] RIP: 0010:refcount_inc+0x2b/0x30 [149492.279330] RSP: 0018:ffffc90008d23c30 EFLAGS: 00010286 [149492.279331] RAX: 000000000000002b RBX: 0000000000000170 RCX: 0000000000000000 [149492.279331] RDX: 0000000000000000 RSI: ffff88051ecccbe8 RDI: ffff88051ecccbe8 [149492.279332] RBP: ffffc90008d23c30 R08: 0000000000000001 R09: 00000000000003ee [149492.279333] R10: ffffc90008d23bb0 R11: 00000000000003ee R12: ffff88043aaac960 [149492.279333] R13: ffff8805005e28a8 R14: 0000000000000002 R15: ffff88050115e178 [149492.279334] FS: 00007fc540168700(0000) GS:ffff88051ecc0000(0000) knlGS:0000000000000000 [149492.279335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [149492.279336] CR2: 00007fc3e8654140 CR3: 000000027ba77000 CR4: 00000000001426e0 [149492.279337] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [149492.279337] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [149492.279338] Call Trace: [149492.279345] ttm_bo_force_list_clean+0xb9/0x110 [ttm] [149492.279348] ttm_bo_clean_mm+0x7a/0xe0 [ttm] [149492.279375] amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu] [149492.279392] amdgpu_bo_fini+0x12/0x40 [amdgpu] [149492.279415] gmc_v7_0_sw_fini+0x32/0x40 [amdgpu] [149492.279430] amdgpu_fini+0x2c9/0x490 [amdgpu] [149492.279445] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [149492.279461] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [149492.279470] drm_dev_unregister+0x3c/0xe0 [drm] [149492.279485] amdgpu_pci_remove+0x19/0x30 [amdgpu] [149492.279487] pci_device_remove+0x39/0xc0 [149492.279490] device_release_driver_internal+0x155/0x210 [149492.279491] driver_detach+0x38/0x70 [149492.279493] bus_remove_driver+0x4c/0xa0 [149492.279494] driver_unregister+0x2c/0x40 [149492.279496] pci_unregister_driver+0x21/0x90 [149492.279520] amdgpu_exit+0x15/0x406 [amdgpu] [149492.279523] SyS_delete_module+0x1a8/0x270 [149492.279525] ? exit_to_usermode_loop+0x92/0xa0 [149492.279528] entry_SYSCALL_64_fastpath+0x13/0x94 [149492.279529] RIP: 0033:0x7fc53fcb68e7 [149492.279529] RSP: 002b:00007ffcfbfaabb8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [149492.279531] RAX: ffffffffffffffda RBX: 0000563117adb200 RCX: 00007fc53fcb68e7 [149492.279531] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000563117adb268 [149492.279532] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [149492.279533] R10: 0000000000000883 R11: 0000000000000206 R12: 00007ffcfbfa9ba0 [149492.279533] R13: 0000000000000000 R14: 0000000000000000 R15: 0000563117adb200 [149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff [149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]--- Unref the fence *after* waiting for it. v2: Set man->move to NULL after dropping the last ref (Christian König) Fixes: aff98ba1 (drm/ttm: wait for eviction in ttm_bo_force_list_clean) Signed-off-by:
-
sagar.a.kamble@intel.com authored
OA buffer initialization involves access to HW registers to set the OA base, head and tail. Ensure device is awake while setting these. With this, all oa.ops are covered under RPM and forcewake wakelock. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Navare, Manasi D authored
The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register and hence the CURSOR_COEFF_MASK should be (0x3F << 0) Fixes: 04416108 ("drm/i915/cnl: Add registers related to voltage swing sequences.") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
During the review of Coffee Lake workarounds Mika pointed out that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC should be removed from CFL and with that I should carry the rv-b. However when doing the v2 I removed another Workaround that should remain because although not mentioned by spec the history of hangs around it advocates on its favor. On some follow-up patches I continued operating on the wrong workardound, but Ville noticed that, so here is the fix for the current CFL code that is upstream already. Fixes: 46c26662 ("drm/i915/cfl: Introduce Coffee Lake workarounds.") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Chris Wilson authored
When computing a hash for looking up relocation target handles in an execbuf, we start with a large size for the hashtable and proceed to halve it until the allocation succeeds. The final attempt is with an order of 0 (i.e. a single element). This means that we then pass bits=0 to hash_32() which then computes "hash >> (32 - 0)" to lookup the single element. Right shifting a value by the width of the operand is undefined, so limit the smallest hash table we use to order 1. v2: Keep the retry allocation flag for the final pass Fixes: 4ff4b44c ("drm/i915: Store a direct lookup from object handle to vma") Signed-off-by:
-
Gabriel Krisman Bertazi authored
There are still cases on these platforms where an attempt is made to configure the CDCLK while the power domain is off, like when coming back from a suspend. So the workaround below is still needed. This effectively reverts commit 63ff3044 ("drm/i915: Nuke the VLV/CHV PFI programming power domain workaround"). Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.ukReviewed-by:
-
Christophe JAILLET authored
'dma_buf_vmap' returns NULL on error, not an error pointer. Fixes: 6cca22ed ("drm/i915: Add some mock tests for dmabuf interop") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: http://patchwork.freedesktop.org/patch/msgid/20170627053854.21152-1-christophe.jaillet@wanadoo.frReviewed-by:
-
Ville Syrjälä authored
We have pretty clear evidence that MSIs are getting lost on g4x and somehow the interrupt logic doesn't seem to recover from that state even if we try hard to clear the IIR. Disabling IER around the normal IIR clearing in the irq handler isn't sufficient to avoid this, so the problem really seems to be further up the interrupt chain. This should guarantee that there's always an edge if any IIR bits are set after the interrupt handler is done, which should normally guarantee that the CPU interrupt is generated. That approach seems to work perfectly on VLV/CHV, but apparently not on g4x. MSI is documented to be broken on 965gm at least. The chipset spec says MSI is defeatured because interrupts can be delayed or lost, which fits well with what we're seeing on g4x. Previously we've already disabled GMBUS interrupts on g4x because somehow GMBUS manages to raise legacy interrupts even when MSI is enabled. Since there's such widespread MSI breakahge all over in the pre-gen5 land let's just give up on MSI on these platforms. Seqno reporting might be negatively affected by this since the legcy interrupts aren't guaranteed to be ordered with the seqno writes, whereas MSI interrupts may be? But an occasioanlly missed seqno seems like a small price to pay for generally working interrupts. Cc: stable@vger.kernel.org Cc: Diego Viola <diego.viola@gmail.com> Tested-by:
Diego Viola <diego.viola@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit e38c2da0) Signed-off-by:
-
Maarten Lankhorst authored
All atomic state should be cleared when drm_modeset_backoff() is called, because it drops all locks and the state becomes invalid. The call to drm_atomic_state_clear was missing in atomic_remove_fb, so add the missing call there. Signed-off-by:
-
- 30 Jun, 2017 1 commit
-
-
Jim Qu authored
On PX system, it will get memory type before gpu post , and get unkown type. Signed-off-by:
Jim Qu <Jim.Qu@amd.com> Reviewed-by:
-
