summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorLyude <lyude@redhat.com>2016-11-02 00:31:32 +0300
committerLyude <lyude@redhat.com>2016-11-04 20:50:13 +0300
commitf97f193613dc7b723fa1b7e187da0ba585a7f2de (patch)
tree17c7c67f6f9497925c404f96b18637f0d715c08b /tools/perf/scripts/python/export-to-postgresql.py
parent9c7540241885838cfc7fa58c4a8bd75be0303ed1 (diff)
downloadlinux-f97f193613dc7b723fa1b7e187da0ba585a7f2de.tar.xz
drm/i915: Remove redundant reprobe in i915_drm_resume
Weine's investigation on benchmarking the suspend/resume process pointed out a lot of the time in suspend/resume is being spent reprobing. While the reprobing process is a lengthy one for good reason, we don't need to hold up the entire suspend/resume process while we wait for it to finish. Luckily as it turns out, we already trigger a full connector reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in i915_drm_resume() entirely. This won't lead to less time spent resuming just yet since now the bottleneck will be waiting for the mode_config lock in drm_kms_helper_poll_enable(), since that will be held as long as i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll address that in the next patch. Signed-off-by: Lyude <lyude@redhat.com> Tested-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions