- 05 Nov, 2015 1 commit
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- Updated register headers for GFX 8.1 for Stoney - Add some new CZ revisions - minor pageflip optimizations - Fencing clean up - Warning fix - More fence cleanup - oops fix - Fiji fixes * 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: (29 commits) drm/amdgpu: group together common fence implementation drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE drm/amdgpu: remove now unused fence functions drm/amdgpu: fix fence fallback check drm/amdgpu: fix stoping the scheduler timeout drm/amdgpu: cleanup on error in amdgpu_cs_ioctl() drm/amdgpu: update Fiji's Golden setting drm/amdgpu: update Fiji's rev id drm/amdgpu: extract common code in vi_common_early_init drm/amd/scheduler: don't oops on failure to load drm/amdgpu: don't oops on failure to load (v2) drm/amdgpu: don't VT switch on suspend drm/amdgpu: Make amdgpu_mn functions inline drm/amdgpu: remove amdgpu_fence_ref/unref drm/amdgpu: use common fence for sync drm/amdgpu: use the new fence_is_later drm/amdgpu: use common fences for VMID management v2 drm/amdgpu: move ring_from_fence to common code drm/amdgpu: switch to common fence_wait_any_timeout v2 drm/amdgpu: remove unneeded fence functions ...
-
- 04 Nov, 2015 7 commits
-
-
Christian König authored
And also add some missing function documentation. No functional change. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
Moves are exclusive operations anyway, just use the undefined owner for those. Signed-off-by:
-
Christian König authored
Signed-off-by:
-
Christian König authored
Interrupts are notorious unreliable, enable the fallback at a couple of more places. Signed-off-by:
-
Christian König authored
cancel_delayed_work_sync is forbidden in interrupt context. Signed-off-by:
-
Dan Carpenter authored
We recently changed the locking in this function and now there is a missing unlock on error. Also there are some other resources that we should probably release as well... Fixes: f48b2659 ('drm/amdgpu: fix the broken vm->mutex V2') Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com>
-
Daniel Stone authored
The GuC firmware load requires struct_mutex to create a GEM object, but this collides badly with request_firmware. Move struct_mutex locking down into the loader itself, so we don't hold it across the entire load process, including request_firmware. [ 20.451400] ====================================================== [ 20.451420] [ INFO: possible circular locking dependency detected ] [ 20.451441] 4.3.0-rc5+ #1 Tainted: G W [ 20.451457] ------------------------------------------------------- [ 20.451477] plymouthd/371 is trying to acquire lock: [ 20.451494] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0093c62>] drm_gem_mmap+0x112/0x290 [drm] [ 20.451538] but task is already holding lock: [ 20.451557] (&mm->mmap_sem){++++++}, at: [<ffffffff811fd9ac>] vm_mmap_pgoff+0x8c/0xf0 [ 20.451591] which lock already depends on the new lock. [ 20.451617] the existing dependency chain (in reverse order) is: [ 20.451640] -> #3 (&mm->mmap_sem){++++++}: [ 20.451661] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.451683] [<ffffffff8120ec9a>] __might_fault+0x7a/0xa0 [ 20.451705] [<ffffffff8127e34e>] filldir+0x9e/0x130 [ 20.451726] [<ffffffff81295b86>] dcache_readdir+0x186/0x230 [ 20.451748] [<ffffffff8127e117>] iterate_dir+0x97/0x130 [ 20.451769] [<ffffffff8127e66a>] SyS_getdents+0x9a/0x130 [ 20.451790] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.451829] -> #2 (&sb->s_type->i_mutex_key#2){+.+.+.}: [ 20.451852] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.451872] [<ffffffff8184b516>] mutex_lock_nested+0x86/0x400 [ 20.451893] [<ffffffff81277790>] walk_component+0x1d0/0x2a0 [ 20.451914] [<ffffffff812779f0>] link_path_walk+0x190/0x5a0 [ 20.451935] [<ffffffff8127803b>] path_openat+0xab/0x1260 [ 20.451955] [<ffffffff8127a651>] do_filp_open+0x91/0x100 [ 20.451975] [<ffffffff81267e67>] file_open_name+0xf7/0x150 [ 20.451995] [<ffffffff81267ef3>] filp_open+0x33/0x60 [ 20.452014] [<ffffffff8157e1e7>] _request_firmware+0x277/0x880 [ 20.452038] [<ffffffff8157e9e4>] request_firmware_work_func+0x34/0x80 [ 20.452060] [<ffffffff810c7020>] process_one_work+0x230/0x680 [ 20.452082] [<ffffffff810c74be>] worker_thread+0x4e/0x450 [ 20.452102] [<ffffffff810ce511>] kthread+0x101/0x120 [ 20.452121] [<ffffffff8184f66f>] ret_from_fork+0x3f/0x70 [ 20.452140] -> #1 (umhelper_sem){++++.+}: [ 20.452159] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.452178] [<ffffffff8184c5c1>] down_read+0x51/0xa0 [ 20.452197] [<ffffffff810c203b>] usermodehelper_read_trylock+0x5b/0x130 [ 20.452221] [<ffffffff8157e147>] _request_firmware+0x1d7/0x880 [ 20.452242] [<ffffffff8157e821>] request_firmware+0x31/0x50 [ 20.452262] [<ffffffffa01b54a4>] intel_guc_ucode_init+0xf4/0x400 [i915] [ 20.452305] [<ffffffffa0213913>] i915_driver_load+0xd63/0x16e0 [i915] [ 20.452343] [<ffffffffa00987d9>] drm_dev_register+0xa9/0xc0 [drm] [ 20.452369] [<ffffffffa009ae3d>] drm_get_pci_dev+0x8d/0x1e0 [drm] [ 20.452396] [<ffffffffa01521e4>] i915_pci_probe+0x34/0x50 [i915] [ 20.452421] [<ffffffff81464675>] local_pci_probe+0x45/0xa0 [ 20.452443] [<ffffffff81465a6d>] pci_device_probe+0xfd/0x140 [ 20.452464] [<ffffffff8156a2e4>] driver_probe_device+0x224/0x480 [ 20.452486] [<ffffffff8156a5c8>] __driver_attach+0x88/0x90 [ 20.452505] [<ffffffff81567cf3>] bus_for_each_dev+0x73/0xc0 [ 20.452526] [<ffffffff81569a7e>] driver_attach+0x1e/0x20 [ 20.452546] [<ffffffff815695ae>] bus_add_driver+0x1ee/0x280 [ 20.452566] [<ffffffff8156b100>] driver_register+0x60/0xe0 [ 20.453197] [<ffffffff81464050>] __pci_register_driver+0x60/0x70 [ 20.453845] [<ffffffffa009b070>] drm_pci_init+0xe0/0x110 [drm] [ 20.454497] [<ffffffffa027f092>] 0xffffffffa027f092 [ 20.455156] [<ffffffff81002123>] do_one_initcall+0xb3/0x200 [ 20.455796] [<ffffffff811d8c01>] do_init_module+0x5f/0x1e7 [ 20.456434] [<ffffffff8114c4e6>] load_module+0x2126/0x27d0 [ 20.457071] [<ffffffff8114cdf9>] SyS_finit_module+0xb9/0xf0 [ 20.457738] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.458370] -> #0 (&dev->struct_mutex){+.+.+.}: [ 20.459773] [<ffffffff8110584f>] __lock_acquire+0x191f/0x1ba0 [ 20.460451] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.461074] [<ffffffffa0093c88>] drm_gem_mmap+0x138/0x290 [drm] [ 20.461693] [<ffffffff8121a5ec>] mmap_region+0x3ec/0x670 [ 20.462298] [<ffffffff8121abb2>] do_mmap+0x342/0x420 [ 20.462901] [<ffffffff811fd9d2>] vm_mmap_pgoff+0xb2/0xf0 [ 20.463532] [<ffffffff81218f62>] SyS_mmap_pgoff+0x1f2/0x290 [ 20.464118] [<ffffffff8102187b>] SyS_mmap+0x1b/0x30 [ 20.464702] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.465289] other info that might help us debug this: [ 20.467179] Chain exists of: &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem [ 20.468928] Possible unsafe locking scenario: [ 20.470161] CPU0 CPU1 [ 20.470745] ---- ---- [ 20.471325] lock(&mm->mmap_sem); [ 20.471902] lock(&sb->s_type->i_mutex_key#2); [ 20.472538] lock(&mm->mmap_sem); [ 20.473118] lock(&dev->struct_mutex); [ 20.473704] *** DEADLOCK *** Signed-off-by:Daniel Stone <daniels@collabora.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 03 Nov, 2015 32 commits
-
-
Flora Cui authored
Change-Id: Ic3f3bfce4767cc05d04f6eb24e22a0f3e7ceacaa Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Jammy Zhou <Jammy.Zhou@amd.com>
-
Flora Cui authored
Change-Id: I0018e2b72feb771683c57960ba3ce942bec5d3ab Signed-off-by:
-
Flora Cui authored
Change-Id: I9ed25353c559e27bc1b1d5b50f977b0ff03de87f Signed-off-by:
-
Dave Airlie authored
In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. agd: Split out from from the original patch since the scheduler is a driver independent. Reviewed-by:
-
Dave Airlie authored
In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. v2 (agd): split out scheduler change into a separate patch Reviewed-by:
-
Alex Deucher authored
Reviewed-by:
-
git://anongit.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
- Vast improvements to gk20a instmem handling. - Improved PGOB detection + GK107 support. - Compatibility between old/new interfaces added, final missing piece to finally enabling userspace to start using them. - Kepler GDDR5 PLL stability improvements - Support for non-GPIO (PWM) voltage controllers - G8x/GT2xx memory clock improvements - Misc other fixes * 'linux-4.4' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (45 commits) drm/nouveau: bump patchlevel to indicate availability of abi16/nvif interop drm/nouveau/abi16: implement limited interoperability with usif/nvif drm/nouveau/abi16: introduce locked variant of nouveau_abi16_get() drm/nouveau/abi16: remove unused argument from nouveau_abi16_get() drm/nouveau/pci: enable c800 magic for Medion Erazer X7827 drm/nouveau/pci: enable c800 magic for Lenovo Y510P drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5 drm/nouveau/clk/g84: Enable reclocking for GDDR3 G94-G200 drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristic drm/nouveau/fb/ramnv50: Script changes for G94 and up drm/nouveau/fb/ramnv50: Deal with cards without timing entries drm/nouveau/fb/ramnv50: Voltage GPIOs drm/nouveau/fb/ramgt215: Restructure r111100 calculation for DDR2 drm/nouveau/fb/ramgt215: Change FBVDD/Q when BIOS asks for it drm/nouveau/fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific to generic drm/nouveau/bios/rammap: Identify DLLoff for >= GF100 drm/nouveau/pci: Handle 5-bit and 8-bit tag field drm/nouveau/disp,pm: constify nvkm_object_func structures drm/nouveau/gr: add FERMI_COMPUTE_B class to GF110+ drm/nouveau/gr: document mp error 0x10 ...
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This pull request includes comprehensive cleanups to HDMI part and several fixups. In addition, this pull request includes also a defconfig patch which enables mixer driver as default. For this, I got already Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (34 commits) drm/exynos/gem: remove DMA-mapping hacks used for constructing page array ARM: exynos_defconfig: enable Exynos DRM Mixer driver drm/exynos: simplify Kconfig component names drm/exynos: re-arrange Kconfig entries drm/exynos: abstract out common dependency drm/exynos: separate Mixer and HDMI drivers drm/exynos/mixer: replace direct cross-driver call with drm mode validation drm/exynos: add atomic_check callback to exynos_crtc drm/exynos/decon5433: add support for DECON-TV drm/exynos/decon5433: remove duplicated initialization drm/exynos/decon5433: merge different flag fields drm/exynos/decon5433: add function to set particular register bits drm/exynos/decon5433: fix timing registers writes drm/exynos/decon5433: add PCLK clock drm/exynos: cleanup name of gem object for exynos_drm drm/exynos: fix to detach device of iommu drm/exynos: add cursor plane support drm/exynos: add global macro for the default primary plane drm/exynos: fix spelling errors drm: exynos: mixer: fix using usleep() in atomic context ...
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
USIF already takes the client mutex, but will need access to ABI16 data in order to provide some limited interoperability. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ilia Mirkin authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Ilia Mirkin authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75Signed-off-by:
-
Karol Herbst authored
This patch uses an approach closer to the nvidia driver to configure both PLLs for high gddr5 memory clocks (usually above 2400MHz) Previously nouveau used the one PLL as it was used for the lower clocks and just adjusted the second PLL to get as close as possible to the requested clock. This means for my card, that I got a 4050 MHz clock although 4008 MHz was requested. Now the driver iterates over a list of PLL configuration also used by the nvidia driver and then adjust the second PLL to get near the requested clock. Also it hold to some restriction I found while analyzing the PLL configurations This won't fix all gddr5 high clock issues itself, but it should be fine on hybrid gpu systems as found on many laptops these days. Also switching while normal desktop usage should be a lot more stable than before. v2: move the pll code into ramgk104 Signed-off-by:
Karol Herbst <nouveau@karolherbst.de> Signed-off-by:
-
Roy Spliet authored
Your milage may vary, as it's only been tested on a single G94 and one G96. Signed-off-by:
Roy Spliet <rspliet@eclipso.eu> Tested-by:
Pierre Moreau <pierre.morrow@free.fr> Signed-off-by:
-
Roy Spliet authored
Avoids waiting for VBLANKS that never arrive on headless or otherwise unconventional set-ups. Strategy taken from MEMX. Signed-off-by:
-
Roy Spliet authored
10053c is not even read on some cards, and I have no idea exactly what the criteria are. Likely NVIDIA pre-scans the VBIOS and in their driver disables all features that are never used. The practical effect should be the same as this implementation though. Signed-off-by:
-
Roy Spliet authored
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up. Signed-off-by:
-
Roy Spliet authored
Does not seem to be necessary for NVA0, hence untested by me. Signed-off-by:
-
Roy Spliet authored
Seems to be mostly equal to DDR3 on < GT218, should improve stability for DDR2 reclocks. Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
In preparation of changing FBVDDQ, as observed on at least one GDDR3 card. While at it, adhere to func.log[1] properly for consistency. Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Pierre Moreau authored
If the hardware supports extended tag field (8-bit ones), then enable it. This is usually done by the VBIOS, but not on some MBPs (see fdo#86537). In case extended tag field is not supported, 5-bit tag field is used which limits the possible number of requests to 32. Apparently bits 7:0 of 0x08841c stores some number of outstanding requests, so cap it to 32 if extended tag is unsupported. Fixes: fdo#86537 v2: Restrict changes to chipsets >= 0x84 v3: * Add nvkm_pci_mask to pci.h * Mask bit 8 before setting it v4: * Rename `add` argument of nvkm_pci_mask to `value` * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset checks v5: * Rebase code on latest PCI structure * Restore PCIe check * Fix namings in nvkm_pci_mask * Rephrase part of the commit message Signed-off-by: -
Julia Lawall authored
These nvkm_object_func structures are never modified. All other nvkm_object_func structures are declared as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Ilia Mirkin authored
GF110+ supports both the A and B compute classes, make sure to accept both. Signed-off-by:
-
Ilia Mirkin authored
NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by:
-
Sudip Mukherjee authored
If pm_runtime_get_sync() we were going to "out" but we missed freeing vma. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Sudip Mukherjee authored
coverity.com reported that memset was using a buffer of size 0, on checking the code it turned out that the function was not being used. So remove it. Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Signed-off-by:
-
Ben Skeggs authored
Reported to be needed as per fdo#70354 comment #61. Signed-off-by: -
Ben Skeggs authored
Not 100% confirmed, but seems to match from the few boards I've looked at so far. Signed-off-by:
-
