aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2017-06-19drm/amdgpu: Optimize mutex usage (v4)Alex Xie2-12/+30
In original function amdgpu_bo_list_get, the waiting for result->lock can be quite long while mutex bo_list_lock was holding. It can make other tasks waiting for bo_list_lock for long period. Secondly, this patch allows several tasks(readers of idr) to proceed at the same time. v2: use rcu and kref (Dave Airlie and Christian König) v3: update v1 commit message (Michel Dänzer) v4: rebase on upstream (Alex Deucher) Signed-off-by: Alex Xie <AlexBin.Xie@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2017-06-19drm/amdgpu: Optimization of AMDGPU_BO_LIST_OP_CREATE (v2)Alex Xie1-23/+30
v2: Remove duplication of zeroing of bo list (Christian König) Move idr_alloc function to end of ioctl (Christian König) Call kfree bo_list when amdgpu_bo_list_set return error. Combine the previous two patches into this patch. Add amdgpu_bo_list_set function prototype. Signed-off-by: Alex Xie <AlexBin.Xie@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2017-06-19Linux 4.12-rc6Linus Torvalds1-1/+1
2017-06-19mm: larger stack guard gap, between vmasHugh Dickins23-163/+152
Stack guard page is a useful feature to reduce a risk of stack smashing into a different mapping. We have been using a single page gap which is sufficient to prevent having stack adjacent to a different mapping. But this seems to be insufficient in the light of the stack usage in userspace. E.g. glibc uses as large as 64kB alloca() in many commonly used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX] which is 256kB or stack strings with MAX_ARG_STRLEN. This will become especially dangerous for suid binaries and the default no limit for the stack size limit because those applications can be tricked to consume a large portion of the stack and a single glibc call could jump over the guard page. These attacks are not theoretical, unfortunatelly. Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages; but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent, but it should reduce attack space a lot. One could argue that the gap size should be configurable from userspace, but that can be done later when somebody finds that the new 1MB is wrong for some special case applications. For now, add a kernel command line option (stack_guard_gap) to specify the stack gap size (in page units). Implementation wise, first delete all the old code for stack guard page: because although we could get away with accounting one extra page in a stack vma, accounting a larger gap can break userspace - case in point, a program run with "ulimit -S -v 20000" failed when the 1MB gap was counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK and strict non-overcommit mode. Instead of keeping gap inside the stack vma, maintain the stack guard gap as a gap between vmas: using vm_start_gap() in place of vm_start (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few places which need to respect the gap - mainly arch_get_unmapped_area(), and and the vma tree's subtree_gap support for that. Original-patch-by: Oleg Nesterov <oleg@redhat.com> Original-patch-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Tested-by: Helge Deller <deller@gmx.de> # parisc Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-18virtio_balloon: disable VIOMMU supportMichael S. Tsirkin1-0/+7
virtio balloon bypasses the DMA API entirely so does not support the VIOMMU right now. It's not clear we need that support, for now let's just make sure we don't pretend to support it. Cc: stable@vger.kernel.org Cc: Wei Wang <wei.w.wang@intel.com> Fixes: 1a937693993f ("virtio: new feature to detect IOMMU device quirk") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2017-06-17drm/nouveau/disp/nv50-: avoid creating ORs that aren't present on HWBen Skeggs14-10/+39
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-17mm: correct the comment when reclaimed pages exceed the scanned pageszhongjiang1-3/+3
Commit e1587a494540 ("mm: vmpressure: fix sending wrong events on underflow") declared that reclaimed pages exceed the scanned pages due to the thp reclaim. That is incorrect because THP will be spilt to normal page and loop again, which will result in the scanned pages increment. [akpm@linux-foundation.org: tweak comment text] Link: http://lkml.kernel.org/r/1496824266-25235-1-git-send-email-zhongjiang@huawei.com Signed-off-by: zhongjiang <zhongjiang@huawei.com> Acked-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-17userfaultfd: shmem: handle coredumping in handle_userfault()Andrea Arcangeli1-8/+21
Anon and hugetlbfs handle FOLL_DUMP set by get_dump_page() internally to __get_user_pages(). shmem as opposed has no special FOLL_DUMP handling there so handle_mm_fault() is invoked without mmap_sem and ends up calling handle_userfault() that isn't expecting to be invoked without mmap_sem held. This makes handle_userfault() fail immediately if invoked through shmem_vm_ops->fault during coredumping and solves the problem. The side effect is a BUG_ON with no lock held triggered by the coredumping process which exits. Only 4.11 is affected, pre-4.11 anon memory holes are skipped in __get_user_pages by checking FOLL_DUMP explicitly against empty pagetables (mm/gup.c:no_page_table()). It's zero cost as we already had a check for current->flags to prevent futex to trigger userfaults during exit (PF_EXITING). Link: http://lkml.kernel.org/r/20170615214838.27429-1-aarcange@redhat.com Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Reported-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: <stable@vger.kernel.org> [4.11+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-17mm: numa: avoid waiting on freed migrated pagesMark Rutland1-1/+7
In do_huge_pmd_numa_page(), we attempt to handle a migrating thp pmd by waiting until the pmd is unlocked before we return and retry. However, we can race with migrate_misplaced_transhuge_page(): // do_huge_pmd_numa_page // migrate_misplaced_transhuge_page() // Holds 0 refs on page // Holds 2 refs on page vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd); /* ... */ if (pmd_trans_migrating(*vmf->pmd)) { page = pmd_page(*vmf->pmd); spin_unlock(vmf->ptl); ptl = pmd_lock(mm, pmd); if (page_count(page) != 2)) { /* roll back */ } /* ... */ mlock_migrate_page(new_page, page); /* ... */ spin_unlock(ptl); put_page(page); put_page(page); // page freed here wait_on_page_locked(page); goto out; } This can result in the freed page having its waiters flag set unexpectedly, which trips the PAGE_FLAGS_CHECK_AT_PREP checks in the page alloc/free functions. This has been observed on arm64 KVM guests. We can avoid this by having do_huge_pmd_numa_page() take a reference on the page before dropping the pmd lock, mirroring what we do in __migration_entry_wait(). When we hit the race, migrate_misplaced_transhuge_page() will see the reference and abort the migration, as it may do today in other cases. Fixes: b8916634b77bffb2 ("mm: Prevent parallel splits during THP migration") Link: http://lkml.kernel.org/r/1497349722-6731-2-git-send-email-will.deacon@arm.com Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Steve Capper <steve.capper@arm.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-17swap: cond_resched in swap_cgroup_prepare()Yu Zhao1-0/+3
I saw need_resched() warnings when swapping on large swapfile (TBs) because continuously allocating many pages in swap_cgroup_prepare() took too long. We already cond_resched when freeing page in swap_cgroup_swapoff(). Do the same for the page allocation. Link: http://lkml.kernel.org/r/20170604200109.17606-1-yuzhao@google.com Signed-off-by: Yu Zhao <yuzhao@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-17mm/memory-failure.c: use compound_head() flags for huge pagesJames Morse1-1/+4
memory_failure() chooses a recovery action function based on the page flags. For huge pages it uses the tail page flags which don't have anything interesting set, resulting in: > Memory failure: 0x9be3b4: Unknown page state > Memory failure: 0x9be3b4: recovery action for unknown page: Failed Instead, save a copy of the head page's flags if this is a huge page, this means if there are no relevant flags for this tail page, we use the head pages flags instead. This results in the me_huge_page() recovery action being called: > Memory failure: 0x9b7969: recovery action for huge page: Delayed For hugepages that have not yet been allocated, this allows the hugepage to be dequeued. Fixes: 524fca1e7356 ("HWPOISON: fix misjudgement of page_action() for errors on mlocked pages") Link: http://lkml.kernel.org/r/20170524130204.21845-1-james.morse@arm.com Signed-off-by: James Morse <james.morse@arm.com> Tested-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-16amdgpu: use drm sync objects for shared semaphores (v6)Dave Airlie4-2/+97
This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for syncobj pre submission dependencies, and one for post submission sync obj signalling, and just takes a list of handles for each. This is based on work originally done by David Zhou at AMD, with input from Christian Konig on what things should look like. In theory VkFences could be backed with sync objects and just get passed into the cs as syncobj handles as well. NOTE: this interface addition needs a version bump to expose it to userspace. TODO: update to dep_sync when rebasing onto amdgpu master. (with this - r-b from Christian) v1.1: keep file reference on import. v2: move to using syncobjs v2.1: change some APIs to just use p pointer. v3: make more robust against CS failures, we now add the wait sems but only remove them once the CS job has been submitted. v4: rewrite names of API and base on new syncobj code. v5: move post deps earlier, rename some apis v6: lookup post deps earlier, and just replace fences in post deps stage (Christian) Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-06-16amdgpu/cs: split out fence dependency checking (v2)Dave Airlie1-42/+51
This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. v2: rebase onto other changes. v1-Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-06-16drm/amdgpu: don't check the default value for vm sizeAlex Deucher1-0/+4
Avoids printing spurious messages like this: [ 3.102059] amdgpu 0000:01:00.0: VM size (-1) must be a power of 2 Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-06-16perf unwind: Report module before querying isactivation in dwfl unwindMilian Wolff1-0/+8
The PC returned by dwfl_frame_pc() may map into a not-yet-reported module. We have to report it before we continue unwinding. But when we query for the isactivation flag in dwfl_frame_pc, libdw will actually do one more unwinding step internally which can then break and lead to missed frames or broken stacks. With libunwind we get e.g.: ~~~~~ heaptrack_gui 2228 135073.400474: 613969 cycles: 108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0) 1093bc [unknown] (/usr/lib/libQt5Core.so.5.8.0) 109e7b QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0) 1470ff [unknown] (/usr/lib/libQt5Core.so.5.8.0) 147f67 QSystemLocale::query (/usr/lib/libQt5Core.so.5.8.0) 109fbf QLocalePrivate::updateSystemPrivate (/usr/lib/libQt5Core.so.5.8.0) 10aa27 QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0) 1e02c3 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 2113bb [unknown] (/usr/lib/libQt5Core.so.5.8.0) 211505 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 1b5df0 QFileInfo::exists (/usr/lib/libQt5Core.so.5.8.0) 92eb2 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 93423 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 93d2a QLibraryInfo::location (/usr/lib/libQt5Core.so.5.8.0) 2170af [unknown] (/usr/lib/libQt5Core.so.5.8.0) 297c53 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0) f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0) 1589e8 QApplicationPrivate::init (/usr/lib/libQt5Widgets.so.5.8.0) 78622 main (/home/milian/projects/compiled/other/bin/heaptrack_gui) 20439 __libc_start_main (/usr/lib/libc-2.25.so) 78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui) heaptrack_gui 2228 135073.401156: 569521 cycles: 131633 QString::endsWith (/usr/lib/libQt5Core.so.5.8.0) 1a0701 QDir::cleanPath (/usr/lib/libQt5Core.so.5.8.0) 21b82d [unknown] (/usr/lib/libQt5Core.so.5.8.0) 1b3727 QFileInfo::canonicalFilePath (/usr/lib/libQt5Core.so.5.8.0) 2780c7 QFactoryLoader::update (/usr/lib/libQt5Core.so.5.8.0) 279525 QFactoryLoader::QFactoryLoader (/usr/lib/libQt5Core.so.5.8.0) e5bd0 QPlatformIntegrationFactory::create (/usr/lib/libQt5Gui.so.5.8.0) f5a1c QGuiApplicationPrivate::createPlatformIntegration (/usr/lib/libQt5Gui.so.5.8.0) f650c QGuiApplicationPrivate::createEventDispatcher (/usr/lib/libQt5Gui.so.5.8.0) 298524 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0) f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0) 1589e8 QApplicationPrivate::init (/usr/lib/libQt5Widgets.so.5.8.0) 78622 main (/home/milian/projects/compiled/other/bin/heaptrack_gui) 20439 __libc_start_main (/usr/lib/libc-2.25.so) 78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui) ~~~~~ Note the two frames 1589e8 and 78622 in the first sample. These are missing when unwinding with libdw. The second sample's breakage is more obvious: ~~~~~ heaptrack_gui 2228 135073.400474: 613969 cycles: 108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0) 1093bc [unknown] (/usr/lib/libQt5Core.so.5.8.0) 109e7b QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0) 1470ff [unknown] (/usr/lib/libQt5Core.so.5.8.0) 147f67 QSystemLocale::query (/usr/lib/libQt5Core.so.5.8.0) 109fbf QLocalePrivate::updateSystemPrivate (/usr/lib/libQt5Core.so.5.8.0) 10aa27 QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0) 1e02c3 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 2113bb [unknown] (/usr/lib/libQt5Core.so.5.8.0) 211505 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 1b5df0 QFileInfo::exists (/usr/lib/libQt5Core.so.5.8.0) 92eb2 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 93423 [unknown] (/usr/lib/libQt5Core.so.5.8.0) 93d2a QLibraryInfo::location (/usr/lib/libQt5Core.so.5.8.0) 2170af [unknown] (/usr/lib/libQt5Core.so.5.8.0) 297c53 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0) f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0) 20439 __libc_start_main (/usr/lib/libc-2.25.so) 78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui) heaptrack_gui 2228 135073.401156: 569521 cycles: 131633 QString::endsWith (/usr/lib/libQt5Core.so.5.8.0) 1a0701 QDir::cleanPath (/usr/lib/libQt5Core.so.5.8.0) 21b82d [unknown] (/usr/lib/libQt5Core.so.5.8.0) 1b3727 QFileInfo::canonicalFilePath (/usr/lib/libQt5Core.so.5.8.0) 2780c7 QFactoryLoader::update (/usr/lib/libQt5Core.so.5.8.0) 279525 QFactoryLoader::QFactoryLoader (/usr/lib/libQt5Core.so.5.8.0) e5bd0 QPlatformIntegrationFactory::create (/usr/lib/libQt5Gui.so.5.8.0) 723dbf [unknown] ([unknown]) ~~~~~ This patch fixes this issue and the libdw unwinder mimicks the libunwind behavior more closely. Signed-off-by: Milian Wolff <milian.wolff@kdab.com> Acked-by: Jan Kratochvil <jan.kratochvil@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/20170602143753.16907-2-milian.wolff@kdab.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2017-06-16drm/arm: mali-dp: Use CMA helper for plane buffer address calculationLiviu Dudau1-7/+5
CMA has gained a recent helper function for calculating the start of a plane buffer's physical address. Use that instead of the hand rolled version. Cc: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2017-06-16drm/mali-dp: Check PM status when sharing interrupt linesLiviu Dudau1-3/+16
If an instance of Mali DP hardware shares the interrupt line with another hardware (usually another instance of the Mali DP) its interrupt handler can get called when the device is suspended. Check the PM status before making access to the hardware registers to avoid deadlocks. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
2017-06-16drm/arm: malidp: Use crtc->mode_valid() callbackJose Abreu1-6/+5
Now that we have a callback to check if crtc supports a given mode we can use it in malidp so that we restrict the number of probbed modes to the ones we can actually display. Also, remove the mode_fixup() callback as this is no longer needed because mode_valid() will be called before. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: Carlos Palminha <palminha@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@linux.ie> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
2017-06-16fs: pass on flags in compat_writevChristoph Hellwig1-1/+1
Fixes: 793b80ef14af ("vfs: pass a flags argument to vfs_readv/vfs_writev") Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-16objtool: Add fortify_panic as __noreturn functionKees Cook1-1/+2
CONFIG_FORTIFY_SOURCE=y implements fortify_panic() as a __noreturn function, so objtool needs to know about it too. Suggested-by: Daniel Micay <danielmicay@gmail.com> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1497532835-32704-1-git-send-email-jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-16powerpc/debug: Add missing warn flag to WARN_ON's non-builtin pathAlexey Kardashevskiy1-1/+1
When trapped on WARN_ON(), report_bug() is expected to return BUG_TRAP_TYPE_WARN so the caller will increment NIP by 4 and continue. The __builtin_constant_p() path of the PPC's WARN_ON() calls (indirectly) __WARN_FLAGS() which has BUGFLAG_WARNING set, however the other branch does not which makes report_bug() report a bug rather than a warning. Fixes: f26dee15103f ("debug: Avoid setting BUGFLAG_WARNING twice") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-06-16drm/nouveau: use proper prototype in nouveau_pmops_runtime() definitionArnd Bergmann1-1/+1
There is a prototype for this function in the header, but the function itself lacks a 'void' in the argument list, causing a harmless warning when building with 'make W=1': drivers/gpu/drm/nouveau/nouveau_drm.c: In function 'nouveau_pmops_runtime': drivers/gpu/drm/nouveau/nouveau_drm.c:730:1: error: old-style function definition [-Werror=old-style-definition] Fixes: 321f5c5f2c49 ("drm/nouveau: replace multiple open-coded runpm support checks with function") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau: Skip vga_fini on non-PCI deviceMikko Perttunen1-0/+4
As with vga_init, this function doesn't make sense on non-PCI devices, and the Thunderbolt check in it dereferences a NULL pointer in that case. Add some code to skip this function when the device is not a PCI device. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/tegra: Don't leave GPU in resetMikko Perttunen1-3/+0
On Tegra186 systems with certain firmware revisions, leaving the GPU in reset can cause a hang. To prevent this, don't leave the GPU in reset. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/tegra: Skip manual unpowergating when not necessaryMikko Perttunen1-4/+6
On Tegra186, powergating is handled by the BPMP power domain provider and the "legacy" powergating API is not available. Therefore skip these calls if we are attached to a power domain. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/hwmon: Change permissions to numericOscar Salvador1-5/+5
This patch replaces the symbolic permissions with the numeric ones. Signed-off-by: Oscar Salvador <osalvador.vilardaga@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/hwmon: expose the auto_point and pwm_min/max attrsOscar Salvador1-1/+33
This patch creates a special group attributes for attrs like "*auto_point*". We check if we have support for them, and if we do, we gather them all in an attribute_group's structure which is the parameter regarding special groups of hwmon_device_register_with_info We also do the same for pwm_min/max attrs. Signed-off-by: Oscar Salvador <osalvador.vilardaga@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/hwmon: Remove old code, add .write/.read operationsOscar Salvador1-583/+261
This patch removes old code related to the old api and transforms the functions for the new api. It also adds the .write and .read operations. Signed-off-by: Oscar Salvador <osalvador.vilardaga@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_stringOscar Salvador1-0/+163
This patch introduces the nouveau_hwmon_ops structure, sets up .is_visible and .read_string operations and adds all the functions for these operations. This is also a preparation for the next patches, where most of the work is being done. This code doesn't interacture with the old one. It's just to make easier the review of all patches. Signed-off-by: Oscar Salvador <osalvador.vilardaga@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/hwmon: Add config for all sensors and their settingsOscar Salvador1-0/+72
This is a preparation for the next patches. It just adds the sensors with their possible configurable settings and then fills the struct hwmon_channel_info with all this information. Signed-off-by: Oscar Salvador <osalvador.vilardaga@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/gm200-: allow non-identity mapping of SOR <-> macro linksBen Skeggs1-2/+2
Finally, everything should be in place to handle this. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: implement a common supervisor 3.0Ben Skeggs8-338/+35
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: implement a common supervisor 2.2Ben Skeggs25-246/+321
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: implement a common supervisor 2.1Ben Skeggs3-21/+11
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: implement a common supervisor 2.0Ben Skeggs5-155/+41
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: implement a common supervisor 1.0Ben Skeggs3-12/+70
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-gt21x: remove workaround for dp->tmds hotplug issuesBen Skeggs1-27/+0
This shouldn't have been needed ever since we started executing the DisableLT script when shutting down heads. Testing of the board this was originally written for seems to agree. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/dp: use new devinit script interpreter entry-pointBen Skeggs1-38/+30
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/dp: determine link bandwidth requirements from head stateBen Skeggs7-2/+62
Training/Untraining will be hooked up to the routing logic, which doesn't allow us to pass in a data rate. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: introduce acquire/release display path methodsBen Skeggs16-40/+287
These exist to give NVKM information on the set of display paths that the DD needs to be active at any given time. Previously, the supervisor attempted to determine this solely from OR state, but there's a few configurations where this information on its own isn't enough to determine the specific display paths in question: - ANX9805, where the PIOR protocol for both DP and TMDS is TMDS. - On a device using DCB Switched Outputs. - On GM20x and newer, with a crossbar between the SOR and macro links. After this commit, the DD tells NVKM *exactly* which display path it's attempting a modeset on. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: remove hw-specific customisation of output pathsBen Skeggs28-342/+36
All of the necessary hw-specific logic is now handled at the output resource level, so all of this can go away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/gf119-: port OR DP VCPI control to nvkm_iorBen Skeggs7-14/+16
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/gt215-: port HDA ELD controls to nvkm_iorBen Skeggs20-136/+161
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP drive setting control to nvkm_iorBen Skeggs12-143/+66
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP training pattern control to nvkm_iorBen Skeggs12-30/+27
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP link power control to nvkm_iorBen Skeggs12-43/+17
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP link setup to nvkm_iorBen Skeggs12-30/+47
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP lane mapping to nvkm_iorBen Skeggs9-9/+30
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g84-: port OR HDMI control to nvkm_iorBen Skeggs29-219/+134
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: port OR manual sink detection to nvkm_iorBen Skeggs17-80/+40
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.