aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2016-11-09drm/i915: Restrict DRM_DEBUG_MM automatic selectionChris Wilson1-1/+1
DRM_DEBUG_MM is only valid if the DRM.ko is builtin as currently depot_save_stack is not exported. Fixes: 5c7fcf2db027 ("drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161108131917.6253-1-chris@chris-wilson.co.uk
2016-11-09drm: Restrict stackdepot usage to builtin drm.koChris Wilson1-1/+1
I misread the kbuild result thinking that we had missed the include (which we had for completeness anyway), what kbuild was actually warning me about was that depot_save_stack was not exported. Temporarily fix this by only selecting STACKDEPOT iff drm.ko is builtin Reported-by: kbuild test robot <fengguang.wu@intel.com> Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161108131917.6253-2-chris@chris-wilson.co.uk
2016-11-08drm/msm: module param to dump state on error irqRob Clark3-0/+25
Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-8-git-send-email-robdclark@gmail.com
2016-11-08drm/msm/mdp5: add atomic_print_state supportRob Clark2-1/+29
We subclass drm_plane_state, so add mdp5_plane_atomic_print_state() to dump out our own driver specific plane state. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-7-git-send-email-robdclark@gmail.com
2016-11-08drm/atomic: add debugfs file to dump out atomic stateRob Clark3-0/+79
Useful to dump current state from debugfs, if turning on the drm.debug bit is too much overhead. The drm_state_dump() can also be used by drivers, for example to implement a module param that dumps state on error irqs. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-6-git-send-email-robdclark@gmail.com
2016-11-08drm/atomic: add new drm_debug bit to dump atomic stateRob Clark5-0/+133
The contents of drm_{plane,crtc,connector}_state is dumped before commit. If a driver extends any of the state structs, it can implement the corresponding funcs->atomic_print_state() to add it's own driver specific state. Signed-off-by: Rob Clark <robdclark@gmail.com> [seanpaul resolved conflict in drm_plane.h] Signed-off-by: Sean Paul <seanpaul@chromium.org>
2016-11-08drm: add helpers to go from plane state to drm_rectRob Clark4-26/+30
Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> [seanpaul resolved conflict in drm_plane.h] Signed-off-by: Sean Paul <seanpaul@chromium.org>
2016-11-08drm: add helper for printing to log or seq_fileRob Clark4-1/+189
Sometimes it is nice not to duplicate equivalent printk() and seq_printf() code. v2: simplify things w/ va_format, and use dev_printk, docs Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-3-git-send-email-robdclark@gmail.com
2016-11-08drm: helper macros to print composite typesRob Clark3-16/+24
I'll want to print things in a similar way in a later patch. This will make it easier. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-2-git-send-email-robdclark@gmail.com
2016-11-09reservation: revert "wait only with non-zero timeout specified (v3)" v2Christian König1-4/+1
Reverts commit fb8b7d2b9d80 ("reservation: wait only with non-zero timeout specified (v3)") Otherwise signaling might never be activated on the fences. This can result in infinite waiting with hardware which has unreliable interrupts. v2: still return one when the timeout is zero and we don't have any fences. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: fix checkpatch warnings] Link: http://patchwork.freedesktop.org/patch/msgid/1478553376-18575-4-git-send-email-alexander.deucher@amd.com
2016-11-09drm/ttm: fix ttm_bo_waitChristian König1-1/+8
reservation_object_wait_timeout_rcu() should enable signaling even with a zero timeout, but ttm_bo_wait() can also be called from atomic context and then it is not a good idea to do this. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: fix checkpatch warnings] Link: http://patchwork.freedesktop.org/patch/msgid/1478553376-18575-3-git-send-email-alexander.deucher@amd.com
2016-11-09dma-buf/fence: revert "don't wait when specified timeout is zero" (v2)Alex Deucher1-3/+0
Reverts commit 847b19a39e4c ("dma-buf/fence: don't wait when specified timeout is zero") When we don't call the wait function software signaling might never be activated. This can cause infinite polling loops with unreliable interrupt driven hardware. v2: rebase on drm-next Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: reword commit msg for checkpatch warnings] Link: http://patchwork.freedesktop.org/patch/msgid/1478553376-18575-2-git-send-email-alexander.deucher@amd.com
2016-11-09dma-buf/fence: make timeout handling in fence_default_wait consistent (v2)Alex Deucher1-3/+5
Kernel functions taking a timeout usually return 1 on success even when they get a zero timeout. v2: agd: rebase on drm-next Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478553376-18575-1-git-send-email-alexander.deucher@amd.com
2016-11-09drm/amdgpu: add the interface of waiting multiple fences (v4)Junwei Zhang5-1/+207
v2: agd: rebase and squash in all the previous optimizations and changes so everything compiles. v3: squash in Slava's 32bit build fix v4: rebase on drm-next (fence -> dma_fence), squash in Monk's ioctl update patch Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: fix checkpatch warnings] Link: http://patchwork.freedesktop.org/patch/msgid/1478290570-30982-2-git-send-email-alexander.deucher@amd.com
2016-11-09dma-buf: return index of the first signaled fence (v2)monk.liu2-6/+18
Return the index of the first signaled fence. This information is useful in some APIs like Vulkan. v2: rebase on drm-next (fence -> dma_fence) Signed-off-by: monk.liu <monk.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: fix warnings] Link: http://patchwork.freedesktop.org/patch/msgid/1478290570-30982-1-git-send-email-alexander.deucher@amd.com
2016-11-08MAINTAINERS: update Sync File Framework filesGustavo Padovan1-1/+3
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1477515862-7980-1-git-send-email-gustavo@padovan.org
2016-11-08dma-buf/sw_sync: put fence reference from the fence creationGustavo Padovan1-1/+1
Once sw_sync_ioctl_create_fence() returns we no longer have the *pt pointer to the fence base object thus we need to put the reference we have from the fence creation to keep a correct reference accounting. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1477515599-7685-1-git-send-email-gustavo@padovan.org
2016-11-08dma-buf/sw_sync: mark sync_timeline_create() staticBaoyou Xie1-1/+1
We get 1 warning when building kernel with W=1: drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 'sync_timeline_create' [-Wmissing-prototypes] In fact, this function is only used in the file in which it is declared and don't need a declaration, but can be made static. So this patch marks it 'static'. Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1474202961-10099-1-git-send-email-baoyou.xie@linaro.org
2016-11-08drm: Add stackdepot include for DRM_DEBUG_MMChris Wilson1-0/+2
0day found that stackdepot.h doesn't get automatically included on all architectures, so remember to add our #include. Reported-by: kbuild test robot <fengguang.wu@intel.com> Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com>. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161108115601.22873-1-chris@chris-wilson.co.uk
2016-11-08drm/plane: add inline doc for struct drm_planeGustavo Padovan1-14/+44
Some of the members of struct drm_plane had extra comments so for these add inline kernel comment to consolidate all documentation in one place. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> [danvet: Bikeshed a bit more to have real paragraphs with real sentences.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-4-git-send-email-gustavo@padovan.org
2016-11-08drm/msm: use drm_atomic_set_fence_for_plane() to set the fenceGustavo Padovan1-1/+2
drm_atomic_set_fence_for_plane() is smart and won't overwrite plane_state->fence if the user already set an explicit fence there. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-3-git-send-email-gustavo@padovan.org
2016-11-08drm/imx: use drm_atomic_set_fence_for_plane() to set the fenceGustavo Padovan1-2/+4
drm_atomic_set_fence_for_plane() is smart and won't overwrite plane_state->fence if the user already set an explicit fence there. Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-2-git-send-email-gustavo@padovan.org
2016-11-08drm/atomic: add drm_atomic_set_fence_for_plane()Gustavo Padovan3-1/+33
This new function should be used by drivers when setting a implicit fence for the plane. It abstracts the fact that the user might have chosen explicit fencing instead. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478513013-3221-1-git-send-email-gustavo@padovan.org
2016-11-08drm: don't override possible_crtcs for primary/cursor planesRob Clark1-2/+2
It is kind of a pointless restriction. If userspace does silly things like using crtcA's cursor plane on crtcB, and then setcursor on crtcA, it will end up with the overlay disabled on crtcB. But userspace is allowed to shoot itself like this. v2: don't WARN_ON() if caller did not set ->possible_crtcs. This keeps the existing behavior by default, if caller does not set the ->possible_crtcs. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478357521-26542-1-git-send-email-robdclark@gmail.com
2016-11-08drm/uapi: Add a warning that mode flags must match the xrandr definitionsVille Syrjälä1-1/+9
Existing userspace expected the mode flags to match the xrandr definitions 1:1, and even adding new flags in he previously unused bits is likely to break existing userspace. Add a comment warning people about this potential trap. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478182201-26086-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-08drm/edid: Add the missing "Hz" to VIC 58,59 commentVille Syrjälä1-2/+2
All the VICs apart from 58 and 59 have the word "Hz" included in the comment. Include it for 59 and 59 as well. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-08drm/gma500: remove unused ioctl declarationsJiang Biao1-4/+0
psb_gem_create_ioctl and psb_gem_mmap_ioctl are not used currently, their declarations are useless. Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477990879-13139-1-git-send-email-jiang.biao2@zte.com.cn
2016-11-08drm/gma500: make function static to eliminate compiling warningJiang Biao1-1/+1
psb_gtt_remove is only used in this file, and make it static to eliminate missing-prototypes compiling warning. Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477972185-24826-1-git-send-email-jiang.biao2@zte.com.cn
2016-11-08drm/atomic-helper: fix reference to drm_atomic_helper_commit_planesStefan Agner1-8/+8
The kernel-doc references drm_atomic_commit_planes() which does not exist. The functions name is drm_atomic_helper_commit_planes(). Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161031173646.19453-1-stefan@agner.ch
2016-11-08drm: update the documentation of drm_framebuffer_unregister_privateRongrong Zou1-0/+5
Add obvious description to drm_framebuffer_unregister_private() to explain it is deprecated. Signed-off-by: Rongrong Zou <zourongrong@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477915196-100299-1-git-send-email-zourongrong@gmail.com
2016-11-08drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUGChris Wilson1-0/+1
A frequent issue that arises on shutdown is the drm_mm range manager complaining of a leak. To aide debugging those, drm can now track the allocation callsite and print those for the leaks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161029184214.17329-2-chris@chris-wilson.co.uk
2016-11-08drm: Track drm_mm allocators and show leaks on shutdownChris Wilson3-3/+90
We can use the kernel's stack tracer and depot to record the allocation site of every drm_mm user. Then on shutdown, as well as warning that allocated nodes still reside with the drm_mm range manager, we can display who allocated them to aide tracking down the leak. v2: Move Kconfig around so it lies underneath the DRM options submenu. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161031090806.20073-1-chris@chris-wilson.co.uk
2016-11-08drm/i915: Update DRIVER_DATE to 20161108Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-11-07drm/i915: Mark CPU cache as dirty when used for renderingChris Wilson1-0/+8
On LLC, or even snooped, machines rendering via the GPU ends up in the CPU cache. This cacheline dirt also needs to be flushed to main memory when moving to an incoherent domain, such as the display's scanout engine. Mostly, this happens because either the object is marked as dirty from its first use or is avoided by setting the object into the display domain from the start. v2: Treat WT as not requiring a clflush prior to use on the display engine as well. Fixes: 0f71979ab7fb ("drm/i915: Performed deferred clflush inside set-cache-level") References: https://bugs.freedesktop.org/show_bug.cgi?id=95414 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.0+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161107165204.7008-1-chris@chris-wilson.co.uk
2016-11-07drm/i915: Add assert for no pending GPU requests during suspend/resume in LR modeImre Deak1-0/+3
During resume we will reset the SW/HW tracking for each ring head/tail pointers and so are not prepared to replay any pending requests (as opposed to GPU reset time). Add an assert for this both to the suspend and the resume code. v2: - Check for ELSP port idle already during suspend and check !gt.awake during resume. (Chris) v3: - Move the !gt.awake check to i915_gem_resume(). v4: - s/intel_lr_engines_idle/intel_execlists_idle/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-4-git-send-email-imre.deak@intel.com
2016-11-07drm/i915: Make sure engines are idle during GPU idling in LR modeImre Deak3-0/+33
We assume that the GPU is idle once receiving the seqno via the last request's user interrupt. In execlist mode the corresponding context completed interrupt can be delayed though and until this latter interrupt arrives we consider the request to be pending on the ELSP submit port. This can cause a problem during system suspend where this last request will be seen by the resume code as still pending. Such pending requests are normally replayed after a GPU reset, but during resume we reset both SW and HW tracking of the ring head/tail pointers, so replaying the pending request with its stale tail pointer will leave the ring in an inconsistent state. A subsequent request submission can lead then to the GPU executing from uninitialized area in the ring behind the above stale tail pointer. Fix this by making sure any pending request on the ELSP port is completed before suspending. I used a polling wait since the completion time I measured was <1ms and since normally we only need to wait during system suspend. GPU idling during runtime suspend is scheduled with a delay (currently 50-100ms) after the retirement of the last request at which point the context completed interrupt must have arrived already. The chance of this bug was increased by commit 1c777c5d1dcdf8fa0223fcff35fb387b5bb9517a Author: Imre Deak <imre.deak@intel.com> Date: Wed Oct 12 17:46:37 2016 +0300 drm/i915/hsw: Fix GPU hang during resume from S3-devices state but it could happen even without the explicit GPU reset, since we disable interrupts afterwards during the suspend sequence. v2: - Do an unlocked poll-wait first. (Chris) v3-4: - s/intel_lr_engines_idle/intel_execlists_idle/ and move i915.enable_execlists check to the new helper. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-3-git-send-email-imre.deak@intel.com
2016-11-07drm/i915: Avoid early GPU idling due to race with new requestImre Deak1-0/+7
There is a small race where a new request can be submitted and retired after the idle worker started to run which leads to idling the GPU too early. Fix this by deferring the idling to the pending instance of the worker. This scenario was pointed out by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-2-git-send-email-imre.deak@intel.com
2016-11-07drm/i915: Avoid early GPU idling due to already pending idle workImre Deak1-3/+3
Atm, in case an idle work handler is already pending but haven't yet started to run, retiring a new request will not extend the active period as required, rather simply leaves the pending idle work to be scheduled at the original expiration time. This may lead to idling the GPU too early. Fix this by using the delayed-work scheduler alternative which makes sure the handler's expiration time is extended in this case. Cc: Chris Wilson <chris@chris-wilson.co.uk> Requested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-1-git-send-email-imre.deak@intel.com
2016-11-07drm/i915: Limit Valleyview and earlier to only using mappable scanoutChris Wilson1-2/+16
Valleyview appears to be limited to only scanning out from the first 512MiB of the Global GTT. Lets presume that this behaviour was inherited from the display block copied from g4x (not Ironlake) and all earlier generations are similarly affected, though testing suggests different symptoms. For simplicity, impose that these platforms must scanout from the mappable region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this catches Cherryview which does not appear to be limited to the low aperture for its scanout.) v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about limiting this workaround to the old style of display engine. v3: Update changelog to reflect testing by Ville Syrjälä v4: Include the changes to the comments as well Reported-by: Luis Botello <luis.botello.ortega@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036 Fixes: 2efb813d5388 ("drm/i915: Fallback to using unmappable memory for scanout") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Akash Goel <akash.goel@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20161107110128.28762-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com
2016-11-07drm/i915: Round tile chunks up for constructing partial VMAsChris Wilson1-1/+1
When we split a large object up into chunks for GTT faulting (because we can't fit the whole object into the aperture) we have to align our cuts with the fence registers. Each partial VMA must cover a complete set of tile rows or the offset into each partial VMA is not aligned with the whole image. Currently we enforce a minimum size on each partial VMA, but this minimum size itself was not aligned to the tile row causing distortion. Reported-by: Andreas Reis <andreas.reis@gmail.com> Reported-by: Chris Clayton <chris2553@googlemail.com> Reported-by: Norbert Preining <preining@logic.at> Tested-by: Norbert Preining <preining@logic.at> Tested-by: Chris Clayton <chris2553@googlemail.com> Fixes: 03af84fe7f48 ("drm/i915: Choose partial chunksize based on tile row size") Fixes: a61007a83a46 ("drm/i915: Fix partial GGTT faulting") # enabling patch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98402 Testcase: igt/gem_mmap_gtt/medium-copy-odd Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20161107105443.27855-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2016-11-07drm/i915: Remove the vma from the object list upon closeChris Wilson1-2/+3
Currently, the vma is being unlink from the object lookup on destroy. However, we are meant to be decoupling it upon close so that the user cannot access the closed vma whilst it remains active on the GPU. [ 34.074858] kernel BUG at drivers/gpu/drm/i915/i915_gem_gtt.c:3561! [ 34.074875] invalid opcode: 0000 [#1] PREEMPT SMP [ 34.074888] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich mei_me mei snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec snd_hwdep snd_hda_core i2c_designware_platform i2c_designware_core snd_pcm e1000e ptp pps_core sdhci_acpi sdhci mmc_core i2c_hid [last unloaded: i915] [ 34.075010] CPU: 1 PID: 6224 Comm: gem_close_race Tainted: G U 4.9.0-rc3-CI-CI_DRM_1800+ #1 [ 34.075034] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0355.2016.0224.1501 02/24/2016 [ 34.075057] task: ffff8802459a8040 task.stack: ffffc90000524000 [ 34.075074] RIP: 0010:[<ffffffffa0392cbc>] [<ffffffffa0392cbc>] i915_gem_obj_lookup_or_create_vma+0x8c/0xc0 [i915] [ 34.075118] RSP: 0018:ffffc90000527b68 EFLAGS: 00010202 [ 34.075135] RAX: ffff8802426c5e40 RBX: 0000000000000000 RCX: ffff8802447fc2a8 [ 34.075158] RDX: 0000000000000000 RSI: ffff8802447fc2a8 RDI: ffff880248a4a880 [ 34.075181] RBP: ffffc90000527b88 R08: 0000000000000008 R09: 0000000000000000 [ 34.075203] R10: 0000000000000001 R11: 0000000000000000 R12: ffff880248a4a880 [ 34.075225] R13: ffff8802447fc2a8 R14: ffff880243e9afa8 R15: ffff880248a4a9c8 [ 34.075248] FS: 00007f9b43e59740(0000) GS:ffff880256c80000(0000) knlGS:0000000000000000 [ 34.075273] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 34.075292] CR2: 00007f9b43419140 CR3: 000000024455d000 CR4: 00000000003406e0 [ 34.075314] Stack: [ 34.075323] 0000000000000000 ffffc90000527bd0 ffff880243cb8008 ffff880243e9afa8 [ 34.075353] ffffc90000527c08 ffffffffa03874c7 ffffc90000527bb8 ffff880243e9afa8 [ 34.075383] ffff880243e9afb0 ffffc90000527e10 ffff8802447fc2a8 ffff880243cb8040 [ 34.075414] Call Trace: [ 34.075435] [<ffffffffa03874c7>] eb_lookup_vmas.isra.7+0x247/0x330 [i915] [ 34.075468] [<ffffffffa0388c34>] i915_gem_do_execbuffer.isra.15+0x604/0x1a10 [i915] [ 34.075507] [<ffffffffa039c957>] ? i915_gem_object_get_sg+0x347/0x380 [i915] [ 34.075532] [<ffffffff811a69ce>] ? __might_fault+0x3e/0x90 [ 34.075562] [<ffffffffa038a430>] i915_gem_execbuffer2+0xc0/0x250 [i915] [ 34.075585] [<ffffffff81552926>] drm_ioctl+0x1f6/0x480 [ 34.075604] [<ffffffff8100107a>] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 34.075635] [<ffffffffa038a370>] ? i915_gem_execbuffer+0x330/0x330 [i915] [ 34.075658] [<ffffffff81202d2e>] do_vfs_ioctl+0x8e/0x690 [ 34.075677] [<ffffffff8181582d>] ? _raw_spin_unlock_irqrestore+0x3d/0x60 [ 34.075700] [<ffffffff810fcd51>] ? SyS_timer_settime+0x141/0x1e0 [ 34.075721] [<ffffffff810d6de2>] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 34.075742] [<ffffffff8120336c>] SyS_ioctl+0x3c/0x70 [ 34.075760] [<ffffffff8181602e>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 34.075781] Code: 44 a0 48 c7 c2 9a 7e 43 a0 be e0 0d 00 00 48 c7 c7 a0 45 44 a0 e8 55 b8 ce e0 48 85 db 74 a3 49 83 bd f8 03 00 00 00 74 99 0f 0b <0f> 0b 48 89 da 4c 89 ee 4c 89 e7 e8 04 a9 ff ff 48 89 da 49 89 [ 34.075955] RIP [<ffffffffa0392cbc>] i915_gem_obj_lookup_or_create_vma+0x8c/0xc0 [i915] [ 34.075994] RSP <ffffc90000527b68> Testcase: igt/gem_close_race/basic-threads Fixes: db6c2b4151f2 ("drm/i915: Store the vma in an rbtree...") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161104161241.25871-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-11-07drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutexBen Skeggs2-6/+11
This avoids an issue that occurs when we're attempting to preempt multiple channels simultaneously. HW seems to ignore preempt requests while it's still processing a previous one, which, well, makes sense. Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel piglit runs on (at least) GM107. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2016-11-07drm/nouveau/gr: fallback to legacy paths during firmware lookupAlexandre Courbot1-4/+46
Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia/<chip>/gr/" path. Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external firmwares") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2016-11-07drm/nouveau/kms/nv50: initial support for DP 1.2 multi-streamBen Skeggs4-2/+571
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: allow encoder update to be called from other modulesBen Skeggs2-44/+44
MST encoders will make use of this to share code with SOR> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: rename remaining nv50_crtc to nv50_headBen Skeggs1-58/+55
No code changes, just renames + shuffles. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: remove code to create ctxdma for every framebufferBen Skeggs3-90/+7
This is now handled by prepare_fb(). Legacy flips were the last user. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: remove code to support non-atomic page flipsBen Skeggs8-288/+27
Made completely unreachable (and broken) by atomic commits. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: remove code to support non-atomic connector propertiesBen Skeggs4-27/+9
Made completely unreachable by atomic commits. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: remove code to support non-atomic dpmsBen Skeggs2-84/+2
Made completely unreachable (and broken) by atomic commits. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.