Age | Commit message (Collapse) | Author | Files | Lines |
|
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Stefan Christ <contact@stefanchrist.eu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-4-git-send-email-contact@stefanchrist.eu
|
|
Add additional members fb_debug_enter and fb_debug_leave to helper
define. They are shared by all fb_ops implementations.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Stefan Christ <contact@stefanchrist.eu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-3-git-send-email-contact@stefanchrist.eu
|
|
A drm driver that is implementing
fb_debug_enter and fb_debug_leave
in struct fb_ops with drm fb helper functions
drm_fb_helper_debug_enter and drm_fb_helper_debug_leave
must also implement the callback 'mode_set_base_atomic' in struct
drm_crtc_helper_funcs. See Documentation/DocBook/kgdb.tmpl. The current
implementation will segfault when 'mode_set_base_atomic' is a NULL
pointer.
Before this patch at least the drm drivers armada, ast, qxl, udl and
virtio do not have a 'mode_set_base_atomic' implementation but using
drm_fb_helper_debug_(enter|leave). So these drivers may segfault when
callbacks fb_debug_(enter|leave) are called.
Avoid the issue by just checking for NULL pointers. So all drivers can
unconditionally implement fb_debug_(enter|leave) with the drm_fb_helper
functions. If callback 'mode_set_base_atomic' is not implemented, the
code in drm_fb_helper_debug_(enter|leave) does effectively nothing.
Signed-off-by: Stefan Christ <contact@stefanchrist.eu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-2-git-send-email-contact@stefanchrist.eu
|
|
In the err_free_vram and err_release_fbi error paths in astfb_create(), we
attempt to free afbdev->sysram. The only jumps to these error paths occur
before we assign afbdev->sysram = sysram. Free sysram instead.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161114030359.27852-1-andrew.donnellan@au1.ibm.com
|
|
These component_ops structures are only used as the second argument to
component_add and component_del, which are declared as const, so the
structures can be declared as const as well.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct component_ops i@p = { ... };
@ok1@
identifier r.i;
expression e1;
position p;
@@
component_add(e1,&i@p)
@ok2@
identifier r.i;
expression e1;
position p;
@@
component_del(e1, &i@p)
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct component_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct component_ops i = { ... };
// </smpl>
The result of the size command before the change is (arm):
text data bss dec hex filename
5266 236 8 5510 1586 sun4i_backend.o
6393 236 8 6637 19ed sun4i_tcon.o
3700 368 8 4076 fec sun4i_tv.o
1668 108 0 1776 6f0 sun6i_drc.o
and after the change:
text data bss dec hex filename
5274 228 8 5510 1586 sun4i_backend.o
6401 228 8 6637 19ed sun4i_tcon.o
3708 360 8 4076 fec sun4i_tv.o
1676 100 0 1776 6f0 sun6i_drc.o
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr
|
|
The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.
Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.
Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark <robdclark@gmail.com>
Cc: Christian König <christian.koenig@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Sinclair Yeh <syeh@vmware.com> (vmwgfx)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161112011309.9799-1-eric@engestrom.ch
|
|
Add 3 missing mutex_destroy to drm_dev_init teardown and
drm_dev_release.
v2:
- Also include drm_dev_release
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478785835-4142-1-git-send-email-joonas.lahtinen@linux.intel.com
Link: http://patchwork.freedesktop.org/patch/msgid/1478785835-4142-1-git-send-email-joonas.lahtinen@linux.intel.com
|
|
0day continues to complain about trying to save a stacktrace for the
users of the drm_mm range allocator. This time, it is that m68k has no
save_stack_trace(), which is apparently guarded by STACKTRACE_SUPPORT.
Make it depend so!
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161109143906.11057-1-chris@chris-wilson.co.uk
|
|
Adapting the videomode to the hardware constraints is something that
can and must happen during normal operation and isn't something that
the user can avoid. So printing a warning each time it happens isn't
helpful.
Demote this message to the debug level.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
It's possible for CVAL to get set whilst we are in config mode. If this
happens, afer we leave config mode the HW will latch whatever
configuration is in the registers at the next vsync. Most likely this
will be a partial configuration, as we'll be racing against the ongoing
atomic_commit.
To avoid this, clear CVAL before leaving config mode.
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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
|
|
Support downsizing to 1/2 width and/or height in the CSI.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Since the atomic modeset conversion, this should not be an issue
anymore.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
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
|
|
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
|
|
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
|
|
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
|