- 13 Feb, 2017 4 commits
-
-
Chris Wilson authored
The signal threads may be running concurrently with the GPU reset. The completion from the GPU run asynchronous with the reset and two threads may see different snapshots of the state, and the signaler may mark a request as complete as we try to reset it. We don't tolerate 2 different views of the same state and complain if we try to mark a request as failed if it is already complete. Disable the signal threads during reset to prevent this conflict (even though the conflict implies that the state we resetting to is invalid, we have already made our decision!). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99733 References: https://bugs.freedesktop.org/show_bug.cgi?id=99671Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170212172002.23072-4-chris@chris-wilson.co.ukReviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
Disabling the tasklet leaves it if scheduled on the ready to run list until it is re-enabled. This will leave the ksoftird thread spinning until satisfied. To prevent this situation on starting the GPU reset, we want to kill the tasklet first and then disable. The same problem will arise when a tasklet is scheduled from another device, so a better solution is required for the general case. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 1f7b847d ("drm/i915: Disable engine->irq_tasklet around resets") Signed-off-by:
-
Chris Wilson authored
As i915_gem_reset_finish() undoes the steps from i915_gem_reset_prepare() to leave the system in a fully-working state, e.g. to be able to free the breadcrumb signal threads, make sure that we always call it even on the error path. Signed-off-by:
-
Chris Wilson authored
As the request is not complete, it should not be signaled. Assert that this is true before we process the request for a reset. References: https://bugs.freedesktop.org/show_bug.cgi?id=99671Signed-off-by:
-
- 10 Feb, 2017 16 commits
-
-
Chris Wilson authored
After a brief discussion, we settled on a naming convention for the conditional GEM debugging data that should be clearer to the casual user: GEM_DEBUG Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
When updating the bookkeeping following the reset, we need the seqno to be coherent on the CPU prior to trusting its result for deciding whether any request is completed. We need the irq_barrier before we start making these decisions, i.e. in reset_prepare. References: https://bugs.freedesktop.org/show_bug.cgi?id=99733Signed-off-by:
Michel Thierry <michel.thierry@intel.com>
-
Chris Wilson authored
As dmabufs may live beyond the PCI device removal, we need to flush the freed object worker on device release, and include a warning in case there is a leak. Signed-off-by:
-
Chris Wilson authored
We may unload the PCI device before all users (such as dma-buf) are completely shutdown. This may leave VMA in the global GTT which we want to revoke, whilst keeping the objects themselves around to service the dma-buf. Signed-off-by:
-
Chris Wilson authored
We may need to keep our memory management alive after we have unloaded the physical pci device. For example, if we have exported an object via dmabuf, that will keep the device around but the pci device may be removed before the dmabuf itself is released, use of the pci hardware will be revoked, but the memory and object management needs to persist for the dmabuf. Signed-off-by:
-
Lyude authored
This adds a file in i915's debugfs directory that allows userspace to manually control HPD storm detection. This is mainly for hotplugging tests, where we might want to test HPD storm functionality or disable storm detection to speed up hotplugging tests without breaking anything. Changes since v1: - Make HPD storm interval configurable - Misc code cleanup Signed-off-by:
Lyude <lyude@redhat.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>
-
Ville Syrjälä authored
Replace the VLV/CHV check with a HAS_GMCH_DISPLAY check in intel_fb_pitch_limit(), because it's shorter. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170208175328.11064-1-ville.syrjala@linux.intel.comReviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com>
-
Ville Syrjälä authored
Until recently vlv_steal_power_sequencer() wasn't being called for normal DP ports, and hence it could assert that it should only be called for pipe A and B (since pipe C doesn't support eDP). However that changed when we started to consider normal DP ports as well when choosing a PPS. So we will now get spurious warnings when vlv_steal_power_sequencer() does get called for pipe C. Avoid this by moving the WARN down into vlv_detach_power_sequencer() where this assertion should still hold. Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Fixes: 9f2bdb00 ("drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV") References: https://bugs.freedesktop.org/show_bug.cgi?id=95287Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Daniel Vetter authored
Chris Wilson needs the new drm_driver->release callback to make sure the shiny new dma-buf testcases don't oops the driver on unload. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
[12493.693827] WARNING: CPU: 1 PID: 14860 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x5d/0x80 [i915] [12493.693868] Unclaimed read from register 0x1f0024 [12493.693905] Modules linked in: vgem i915 drm_kms_helper drm intel_gtt i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops prime_numbers intel_powerclamp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd lpc_ich i2c_i801 mfd_core video i2c_designware_platform i2c_designware_core i2c_core button autofs4 sd_mod ahci libahci libata scsi_mod [last unloaded: i915] [12493.694039] CPU: 1 PID: 14860 Comm: intel-gpu-overl Tainted: G U 4.10.0-rc7+ #11 [12493.694079] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 03/02/2016 [12493.694121] Call Trace: [12493.694169] dump_stack+0x67/0x9d [12493.694235] __warn+0x117/0x140 [12493.694288] warn_slowpath_fmt+0x4f/0x60 [12493.694344] ? do_raw_spin_lock+0x116/0x180 [12493.694533] ? check_for_unclaimed_mmio+0x98/0xe0 [i915] [12493.694727] __unclaimed_reg_debug+0x5d/0x80 [i915] [12493.694923] fwtable_read32+0x2c5/0x330 [i915] [12493.695108] i915_interrupt_info+0xd52/0xf80 [i915] [12493.695302] ? gen6_write16+0x310/0x310 [i915] [12493.695357] seq_read+0x187/0x710 [12493.695412] full_proxy_read+0x75/0xc0 [12493.695472] __vfs_read+0x5a/0x220 [12493.695524] ? kmem_cache_free+0x6c/0x260 [12493.695577] ? putname+0x97/0xa0 [12493.695629] ? putname+0x97/0xa0 [12493.695682] ? rcu_read_lock_sched_held+0xb8/0xd0 [12493.695735] ? rw_verify_area+0x65/0x140 [12493.695787] vfs_read+0xd1/0x1f0 [12493.695840] SyS_read+0x62/0xc0 [12493.695893] entry_SYSCALL_64_fastpath+0x1c/0xb1 [12493.695943] RIP: 0033:0x7f82dca99ba0 [12493.695985] RSP: 002b:00007ffc0bdfd4f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [12493.696031] RAX: ffffffffffffffda RBX: 00007ffc0be005a0 RCX: 00007f82dca99ba0 [12493.696073] RDX: 0000000000001fff RSI: 00007ffc0bdfd500 RDI: 000000000000001a [12493.696115] RBP: ffffffff810fb639 R08: 302f6972642f6775 R09: 00007f82dca0999a [12493.696157] R10: 00007f82dcd62760 R11: 0000000000000246 R12: ffff880069a17f98 [12493.696199] R13: 00007ffc0bdfd428 R14: 0000000000000003 R15: 00007ffc0bdfd428 [12493.696250] ? trace_hardirqs_off_caller+0xd9/0x130 [12493.696300] ---[ end trace 52ccf4d39793cc59 ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99761Signed-off-by:
-
Chris Wilson authored
Now that we have fast top-down insertion into the drm_mm, we can use it for frequent runtime operations like insertion of the context object, whereas before we limited it to the one-off insertion of the pinned kernel context. Keeping the active context objects out of the mappable region of the global GTT (except under memory pressure) improves our ability to allocate mappable aperture region without triggering a GPU stall. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function intel_ddi_get_link_dpll() was added in f169660e ("drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT") to "allow for the implementation of a platform neutral upfront link training function", but such implementation never landed. So remove that function and clean up the exported shared DPLL interface. Fixes: f169660e ("drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT") Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1484310032-1863-1-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
There are currently 30 power domains, which puts us pretty close to the limit with 32 bit masks. Prepare for the future and increase the limit to 64 bit. v2: Rebase v3: s/unsigned long long/u64/ (Joonas) Allow the 64th bit of the mask to be used. (Joonas) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Some additional fixes for 4.11. Delayed a bit due to Chinese New Year. Highlights: - Powerplay fixes - VCE and UVD powergating fixes - Clean up amdgpu SI gfx code to match CI and VI - Misc bug fixes * 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux: (30 commits) drm/amdgpu: report the number of bytes moved at buffer creation drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted() drm/amdgpu: add support for new smc firmware on polaris drm/amd/powerplay: refine code to avoid potential bug that the memory not cleared. drm/amdgpu: shut up #warning for compile testing drm/amdgpu/virt: fix double kfree on bo_va drm/radeon: remove some dead code drm/radeon: avoid kernel segfault in vce when gpu fails to resume drm/amd/powerplay: set fan speed to max in profile peak mode only. drm/amd/gfx6: update gb_addr_config drm/amdgpu: update HAINAN_GB_ADDR_CONFIG_GOLDEN drm/amdgpu: update VERDE_GB_ADDR_CONFIG_GOLDEN drm/amdgpu: refine si_read_register drm/amdgpu/gfx6: clean up spi configuration drm/amdgpu/gfx6: clean up cu configuration drm/amdgpu/gfx6: clean up rb configuration drm/amdgpu: refine vce3.0 code and related powerplay pg code. drm/amdgpu: move subfunctions to the front of vce_v2_0.c. drm/amdgpu: enable vce pg feature on Kv. drm/amdgpu: refine code for VCE2.0 and related dpm code. ...
-
http://git.agner.ch/git/linux-drm-fsl-dcuDave Airlie authored
two minor fixes. * tag 'drm-fsl-dcu-for-v4.11' of http://git.agner.ch/git/linux-drm-fsl-dcu: drm/fsl-dcu: check for clk_prepare_enable() error drm/fsl-dcu: remove unneeded 'ret' assignment
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2017-02-09' of git://anongit.freedesktop.org/git/drm-misc into drm-next Just 3 bugfixes for 4.11 merge window: - fbdev module unload oops fix from Chris - patch from Dan that look really dangers, better safe than sorry * tag 'drm-misc-next-fixes-2017-02-09' of git://anongit.freedesktop.org/git/drm-misc: drm/atomic: fix an error code in mode_fixup() drm: Cancel drm_fb_helper_resume_work on unload drm: Cancel drm_fb_helper_dirty_work on unload
-
- 09 Feb, 2017 16 commits
-
-
Chris Wilson authored
Once the address space has been created (using 3 or 4 levels of page tables), we should use that to program the appropriate type into the contexts. This gives us the flexibility to handle different types of address spaces at runtime. Signed-off-by:
-
Samuel Pitoiset authored
Like ttm_bo_validate(), ttm_bo_init() might need to move BO and the number of bytes moved by TTM should be reported. This can help the throttle buffer migration mechanism to make a better decision. v2: fix computation Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Samuel Pitoiset authored
When ttm_bo_init() fails, the reservation mutex should be unlocked. In debug build, the kernel reported "possible recursive locking detected" in this codepath. For debugging purposes, I also added a "WARN_ON(ww_mutex_is_locked())" when ttm_bo_init() fails and the mutex was locked as expected. This should fix (random) GPU hangs. The easy way to reproduce the issue is to change the "Super Sampling" option from 1.0 to 2.0 in Hitman. It will create a huge buffer, evict a bunch of buffers (around ~5k) and deadlock. This regression has been introduced pretty recently. v2: only release the mutex if resv is NULL Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED handling (v2)") Reviewed-by: -
Alex Deucher authored
Some polaris variants require new smc firmware. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Maarten Lankhorst authored
i915 is pretty much feature complete. Support for atomic i915-specific connector properties is still missing; those properties can (for now) only be set through the legacy ioctl. ILK style watermarks and gen9+ watermarks are handled atomically, and nonblocking modesets work. FBC has also been made to work with atomic. gen4x- and vlv/chv watermarks still need to be fixed, so disable atomic by default there for now. Flip the switch!! Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lyude <cpaul@redhat.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1486021302-24910-1-git-send-email-maarten.lankhorst@linux.intel.com [mlankhorst: Fix checkpatch warning about extra space in match_info] Acked-by:
Daniel Stone <daniel@fooishbar.org> Reviewed-by:
-
Joonas Lahtinen authored
__create_hw_context can use a good counterpart. Signed-off-by:
-
Chris Wilson authored
The aliasing_ppgtt is just a container for the HW context that mirrors the global gtt. It should never be used directly, so assert if we make the mistake of trying to allocate a VMA for it. Signed-off-by:
-
Chris Wilson authored
We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't know the hw id we need to wait upon). Whilst waiting for the request to be submitted, we may exceed the user's timeout and need to propagate the error back. v2: Make ETIME into an error from wait_for_execute for consistent exit handling. Reported-by:
-
Zhi Wang authored
This patch makes PPGTT page table non-shrinkable when using aliasing PPGTT mode. It's just a temporary solution for making GVT-g work. Fixes: 2ce5179f ("drm/i915/gtt: Free unused lower-level page tables") Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1486559013-25251-2-git-send-email-zhi.a.wang@intel.comReviewed-by:
-
Ander Conselvan de Oliveira authored
This shaves a few lines from intel_dp_init_connector() and will serve as a good place to add other port specific information in a follow up patch. While at it, convert BUG() to MISSING_CASE() in the default case. v2: s/BUG/MISSING_CASE. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
Remove workaround for swapped HPD pins in broxton A stepping, which is pre-production hardware. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
My randconfig tests on linux-next showed a newly introduced warning: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 'amdgpu_bo_create_restricted': drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp] Generally speaking, warnings about bad kernel configuration are not particularly helpful. We could enforce the selection of X86_PAT through Kconfig, so the driver cannot even be used unless it is enabled, or we could just rely on the runtime warning that is also there. In this version, I'm making the warning conditional on CONFIG_COMPILE_TEST, which shuts it up for me, but not people that may actually want to run the kernel as a compromize. Fixes: a2e2f299 ("drm/amdgpu: Bring bo creation in line with radeon driver (v2)") Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Colin Ian King authored
bo_va is being kfree'd twice, once in the call to amdgpu_vm_bo_rmv and then a short while later. Fix this double free by removing the 2nd kfree. Detected by CoverityScan, CID#1399524 ("Double Free") Reviewed-by:Monk Liu <monk.liu@amd.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Dan Carpenter authored
If "rdev->bios" is NULL then we don't need to free it. Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jérôme Glisse authored
When GPU fails to resume we can not trust that value we write to GPU memory will post and we might get garbage (more like 0xffffffff on x86) when reading them back. This trigger out of range memory access in the kernel inside the vce resume code path. This patch use canonical value to compute offset instead of reading back value from GPU memory. Reviewed-by:
Jérôme Glisse <jglisse@redhat.com> Signed-off-by:
-
- 08 Feb, 2017 4 commits
-
-
Rex Zhu authored
Signed-off-by:
-
Flora Cui authored
Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
-
Flora Cui authored
Signed-off-by:
-
Flora Cui authored
Signed-off-by:
-
