| Age | Commit message (Collapse) | Author |
|---|
|
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same table of coefficients for
all 3 curves on DP500.
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
|
|
Add a custom CRTC state struct to enable storing driver's private
state. This patch only adds the base drm_crtc_state struct and
the atomic functions that handle it.
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
Now that we are using a custom plane state in mali-dp, we need a
bespoke reset that takes into account the larger structure.
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
[Updated commit message]
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
The newly introduced function causes a harmless build warning:
drivers/gpu/drm/arm/malidp_planes.c: In function 'malidp_plane_atomic_print_state':
drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp' [-Werror=unused-variable]
The variable serves no purpose here and can be removed.
Fixes: 242f43b69c61 ("drm: mali-dp: add atomic_print_state for planes")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
Add function to dump the state of the plane.
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
Enable runtime and system Power Management. Clocks are now managed
from malidp_crtc_{enable,disable} functions. Suspend-to-RAM tested
as working on Juno.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
Mali DP needs to have all the planes that are becoming inactive in the
new state disabled before re-enabling the active CRTC, otherwise we
start streaming out data from old pointers in memory.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.
In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:
[ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[ 60.044118] Read of size 8 by task gem_exec_fence/530
[ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46
[ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[ 60.044290] Call Trace:
[ 60.044337] dump_stack+0x4d/0x6a
[ 60.044383] kasan_object_err+0x21/0x70
[ 60.044435] kasan_report+0x225/0x4e0
[ 60.044488] ? __list_add_valid+0x1d/0xd0
[ 60.044534] ? kasan_kmalloc+0xad/0xe0
[ 60.044587] __asan_load8+0x5e/0x70
[ 60.044639] __list_add_valid+0x1d/0xd0
[ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915]
[ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915]
[ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.045077] ? save_stack+0xb1/0xd0
[ 60.045105] ? save_stack_trace+0x1b/0x20
[ 60.045132] ? save_stack+0x46/0xd0
[ 60.045158] ? kasan_kmalloc+0xad/0xe0
[ 60.045184] ? __kmalloc+0xd8/0x670
[ 60.045229] ? drm_ioctl+0x359/0x640 [drm]
[ 60.045256] ? SyS_ioctl+0x41/0x70
[ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915]
[ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0
[ 60.045387] ? tty_flip_buffer_push+0x63/0x70
[ 60.045414] ? remove_wait_queue+0xa9/0xc0
[ 60.045441] ? kasan_unpoison_shadow+0x35/0x50
[ 60.045467] ? kasan_kmalloc+0xad/0xe0
[ 60.045494] ? kasan_check_write+0x14/0x20
[ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.045616] drm_ioctl+0x359/0x640 [drm]
[ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[ 60.045751] ? drm_version+0x150/0x150 [drm]
[ 60.045778] ? compat_start_thread+0x60/0x60
[ 60.045805] ? plist_del+0xda/0x1a0
[ 60.045833] do_vfs_ioctl+0x12e/0x910
[ 60.045860] ? ioctl_preallocate+0x130/0x130
[ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0
[ 60.045913] ? vfs_write+0x196/0x240
[ 60.045939] ? __fget_light+0xa7/0xc0
[ 60.045965] SyS_ioctl+0x41/0x70
[ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.046017] RIP: 0033:0x7feb2baefc47
[ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[ 60.046225] Allocated:
[ 60.046246] PID = 530
[ 60.046269] save_stack_trace+0x1b/0x20
[ 60.046292] save_stack+0x46/0xd0
[ 60.046318] kasan_kmalloc+0xad/0xe0
[ 60.046343] kasan_slab_alloc+0x12/0x20
[ 60.046368] kmem_cache_alloc+0xab/0x650
[ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915]
[ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.046936] drm_ioctl+0x359/0x640 [drm]
[ 60.046987] do_vfs_ioctl+0x12e/0x910
[ 60.047038] SyS_ioctl+0x41/0x70
[ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.047139] Freed:
[ 60.047179] PID = 530
[ 60.047223] save_stack_trace+0x1b/0x20
[ 60.047269] save_stack+0x46/0xd0
[ 60.047317] kasan_slab_free+0x72/0xc0
[ 60.047366] kmem_cache_free+0x39/0x160
[ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915]
[ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915]
[ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.047942] drm_ioctl+0x359/0x640 [drm]
[ 60.047968] do_vfs_ioctl+0x12e/0x910
[ 60.047993] SyS_ioctl+0x41/0x70
[ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.048044] Memory state around the buggy address:
[ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 60.048170] ^
[ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.
Fixes: 52e542090701 ("drm/i915/scheduler: Record all dependencies upon request construction")
Testcase: igt/gem_exec_fence/expired-history
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
|
|
Change "S_IRUSR | S_IWUSR" to "0600", it's easier to parse mentally.
This change should be part of commit 50f837371dd9 ("drm/vmwgfx: Revert
"drm/vmwgfx: Replace numeric parameter like 0444 with macro""), but the
patch was truncated somewhere in the patch route, so add the missing
change. Extract from the original commit message:
commit 50f837371dd9aea5470c06d5d10bc9ca3e8155b6
Author: Øyvind A. Holm <sunny@sunbase.org>
Date: Thu Mar 23 14:54:48 2017 -0700
drm/vmwgfx: Revert "drm/vmwgfx: Replace numeric parameter like 0444
with macro"
This reverts commit 2d8e60e8b074 ("drm/vmwgfx: Replace numeric
parameter like 0444 with macro")
The commit belongs to the series of 1285 patches sent to LKML on
2016-08-02, it changes the representation of file permissions from
the octal value "0600" to "S_IRUSR | S_IWUSR".
The general consensus was that the changes does not increase
readability, quite the opposite; 0600 is easier to parse mentally
than S_IRUSR | S_IWUSR.
Signed-off-by: Øyvind A. Holm <sunny@sunbase.org>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
|
|
The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:
[ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
[ 62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
[ 62.034933] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 62.034934] Workqueue: pm pm_runtime_work
[ 62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
[ 62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
[ 62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
[ 62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
[ 62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
[ 62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
[ 62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
[ 62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
[ 62.034945] FS: 0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
[ 62.034945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
[ 62.034947] Call Trace:
[ 62.034948] intel_wait_for_register+0x77/0x140 [i915]
[ 62.034949] vlv_suspend_complete+0x23/0x5b0 [i915]
[ 62.034950] intel_runtime_suspend+0x16c/0x2a0 [i915]
[ 62.034950] pci_pm_runtime_suspend+0x50/0x180
[ 62.034951] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034952] __rpm_callback+0xc5/0x210
[ 62.034953] rpm_callback+0x1f/0x80
[ 62.034953] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034954] rpm_suspend+0x118/0x580
[ 62.034955] pm_runtime_work+0x64/0x90
[ 62.034956] process_one_work+0x1bb/0x3e0
[ 62.034956] worker_thread+0x46/0x4f0
[ 62.034957] ? __schedule+0x18b/0x610
[ 62.034958] kthread+0xff/0x140
[ 62.034958] ? process_one_work+0x3e0/0x3e0
[ 62.034959] ? kthread_create_on_node+
and related hard lockups in CI for byt and bsw.
Note this effectively reverts commits 41ce405e6894 and b27366958869
("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
v2: Convert bool allow into a u32 mask for clarity and repeat the
comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville)
Fixes: 41ce405e6894 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Fixes: b27366958869 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.uk
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
|
|
The hangcheck runs independently to the main flow of seqno through the
driver. However, we have an odd coupling of the seqno reset that is
unwelcome, and if poked at just the right rate can cause spurious hangs
(e.g. gem_exec_whisper) on an apparently idle engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421083113.21321-1-chris@chris-wilson.co.uk
|
|
git://anongit.freedesktop.org/git/drm-misc into drm-next
drm-misc-next-fixes-2017-04-20
Core changes:
- Maintain sti via drm-misc (Vincent)
- Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)
Driver changes:
- Fix UHD displays on stih407 (Vincent)
- Fix uninitialized var return in atmel-hlcdc (Dan)
* tag 'drm-misc-next-fixes-2017-04-20' of git://anongit.freedesktop.org/git/drm-misc:
dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs()
drm/sti: fix GDP size to support up to UHD resolution
MAINTAINERS: add drm/sti driver into drm-misc
|
|
The contents of a ring are only valid between HEAD and TAIL, when the
ring is idle (HEAD == TAIL) we can simply let the pages go under memory
pressure if they are not pinned by an active context. Any new content
will be written after HEAD and so the ring will again be valid between
HEAD and TAIL, everything outside can be discarded.
Note that we take care of ensuring that we do not reset the HEAD
backwards following a GPU hang on an idle ring.
The same precautions are what enable us to use stolen memory for rings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170420101709.27250-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Avoid having too large a stack by creating the fake struct inode/file on
the heap instead.
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.
I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.
Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)
[1] https://www.spinics.net/lists/target-devel/msg15070.html
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1492630570-879-1-git-send-email-logang@deltatee.com
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next
Allwinner DRM changes for 4.12
Not any functional changes, but a lot of preliminary rework in order to
support multiple display pipelines.
* tag 'sunxi-drm-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: (26 commits)
MAINTAINERS: Add sun4i-drm git repo
drm/sun4i: Pass pointer for underlying backend into layer init
drm/sun4i: Pass pointers for associated backend and tcon into crtc init
drm/sun4i: tv: Get tcon and backend pointers from associated crtc
drm/sun4i: Use embedded tcon pointer to get the tcon's output port node
drm/sun4i: Fix tcon channel 0 comment about backporch = backporch + hsync
drm/sun4i: Fix TCON clock and regmap initialization sequence
drm/sun4i: Grab reserved memory region
drm/sun4i: Add backend and tcon pointers to sun4i_crtc
drm/sun4i: Add backend pointer to sun4i_layer
drm/sun4i: rgb: Pass tcon pointer when initializing RGB encoder
drm/sun4i: tv: Switch to drm_of_find_possible_crtcs
drm/sun4i: Drop hardcoded .possible_crtcs values from layers
drm/sun4i: Drop primary layer pointer from sun4i_drv
drm/sun4i: Initialize crtc from tcon bind function
drm/sun4i: Move layers from sun4i_drv to sun4i_crtc
drm/sun4i: Add end of list element for sun4i_layers_init's returned list
drm/sun4i: Set drm_crtc.port to the underlying TCON's output port node
drm/sun4i: Make sunxi_rgb2yuv_coef constant
drm/sun4i: Make sun4i_crtc_init return ERR_PTR style error codes
...
|
|
While highly unlikely, this makes sure that the string built from
engine names won't be processed as a format string.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170411045630.GA6612@beast
|
|
Move the BUILD_BUG_ONs for busy-wait duration outside the
_wait_for_atomic macro as discussed on the mailing list.
v2: Simplify the macro by omitting the ret__ local. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Fixes: 1d1a9774e404 ("drm/i915: Extend intel_wait_for_register_fw() with fast timeout")
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170418105211.7089-1-tvrtko.ursulin@linux.intel.com
|
|
Backmerge Linux 4.11-rc7 from Linus tree, to fix some
conflicts that were causing problems with the rerere cache
in drm-tip.
|
|
Previously with commit a9c1f90c8e17
("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
to be unmasked for IVB and SNB in order to prevent system hang
with chained batchbuffers.
Our CI was seeing incomplete results with tests that used
chained batches and it was found out that HSW needs to have this
same bit unmasked to reliably survive chained batches.
Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to
prevent system hang with batch chaining.
Testcase: igt/gem_exec_fence/nb-await-default
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
|
|
It's not possible for endpoint to be zero so the test doesn't work. If
we break on the first iteration through the loop then endpoint is 1 and
"ret" is uninitialized.
Fixes: ebc944613567 ("drm: convert drivers to use drm_of_find_panel_or_bridge")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170415192142.GA6416@mwanda
|
|
There are two bugs here. The && should be || and the > is off by one so
it should be >= ARRAY_SIZE().
Fixes: 8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.
Use this at your discretion, the contents of the error state. although
compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
eternity (until the error state is destroyed).
Based on an earlier patch by Ben Widawsky <ben@bwidawsk.net>
Testcase: igt/gem_exec_capture
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Matt Turner <mattst88@gmail.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170415093902.22581-1-chris@chris-wilson.co.uk
|
|
If "crtc" is NULL, then my static checker complains that "ret" isn't
initialized on that path. It doesn't really cause a problem unless
"ret" is somehow set to -EDEADLK which is not likely.
Chris Wilson also noticed another error path where "ret" isn't set
correctly.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170414195425.GA8144@mwanda
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
i915_gem_request_alloc() uses error pointers. It never returns NULLs.
Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwanda
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.
This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.
This patch is a resend of the original commit id (233ce881dd91fb
"drm/i915: Implement Link Rate fallback on Link training failure")
which got reverted in this commit id (afc1ebf4562a14 Revert
"drm/i915: Implement Link Rate fallback on Link training failure")
due to CI failures.
After investigating the CI failures it was found that these
were essentially the failures which were always there but hidden because
they used to be DRM_DEBUG_KMS messages for link failures so never got
caught by CI. But now this patch actually throws DRM_ERROR if the link
training fails at RBR and 1 lane. So it caught these link train failures.
There were two failures:
1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
without eDP on Port A. But our VBT initialization code in the driver writes
VBT defaults in a way that it always sets DP flag on Port A and this does
not get cleared after parsing the VBT outputs. This has been fixed in
commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set
when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate
errors from intel_bios_init())
2. On ILK-650 desktop - This was happening because of a bad monitor desktop
combination. I switched the monitor in the CI lab and that helped get rid
of the link failures on ILK system.
v10:
* Rebase on drm-tip and resend after revert
v9:
* Use the trimmed max values of link rate/lane count based on
link train fallback (Daniel Vetter)
v8:
* Set link_status to BAD first and then call mode_valid (Jani Nikula)
v7:
Remove the redundant variable in previous patch itself
v6:
* Obtain link rate index from fallback_link_rate using
the helper intel_dp_link_rate_index (Jani Nikula)
* Include fallback within intel_dp_start_link_train (Jani Nikula)
v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <Harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
|
|
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.
To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c37bb3
("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
why that was there. Perhaps to avoid an EDID read if the connector
status didn't appear to change, but that sort of thing is quite racy
and would have failed anyway if we failed to keep up with the
hotplugs (if we missed the HPD down in between two HPD ups). And
now that we take this codepath unconditionally we definitely need
to drop the goto as otherwise we would never do the EDID read.
v2: Drop the goto that made us skip EDID reads entirely. Doh!
v3: Rebase due to locking changes
s/apparely/apparently/ in the comment (Chris)
Cc: stable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
|
|
The wopcm registers are write-once, so any write after the first one
will just be ignored. The registers survive a GPU reset but not
always a suspend/resume cycle, so to keep things simple keep the
writes in the intel_uc_init_hw function instead of moving it earlier
to make sure we attempt them every time we try to load GuC.
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491524332-23860-1-git-send-email-daniele.ceraolospurio@intel.com
|
|
On stih407-410 chip family the GDP layers are able to support up to UHD
resolution (3840 x 2160).
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Tested-by: Lee Jones <lee.jones@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1490280292-30466-1-git-send-email-vincent.abriou@st.com
|
|
Make sure to take runtime pm when write PTE flush which ensure to
write to hw properly. This fixes warning during mdev/vgpu creation
which will do ggtt reset.
------------[ cut here ]------------
WARNING: CPU: 1 PID: 9375 at drivers/gpu/drm/i915/intel_drv.h:1748 fwtable_write32+0x1c2/0x1e0 [i915]
RPM wakelock ref not held during HW access
Call Trace:
? dump_stack+0x5c/0x81
? __warn+0xbe/0xe0
? warn_slowpath_fmt+0x5a/0x80
? wake_up_klogd+0x37/0x40
? vprintk_emit+0x2ef/0x370
? fwtable_write32+0x1c2/0x1e0 [i915]
? gtt_set_entry64+0xbb/0xd0 [i915]
? intel_vgpu_reset_ggtt+0x88/0xf0 [i915]
? intel_vgpu_init_gtt+0xa5/0x4f0 [i915]
? intel_gvt_create_vgpu+0x1b5/0x250 [i915]
? kobject_put+0x1b/0x50
? intel_vgpu_create+0x4e/0x130 [kvmgt]
? mdev_device_create+0x186/0x2a0 [mdev]
? create_store+0xba/0xe0 [mdev]
? create_store+0xba/0xe0 [mdev]
? kernfs_fop_write+0x109/0x1a0
? kernfs_fop_write+0x109/0x1a0
? __vfs_write+0x33/0x160
? __fput+0x161/0x1d0
? vfs_write+0xb0/0x190
? SyS_write+0x52/0xc0
? exit_to_usermode_loop+0x7a/0xa0
? entry_SYSCALL_64_fastpath+0x1e/0xad
v2: remove unrelated oops info
v3: change to take runtime pm for ggtt reset instead of get/put for
each pte write flush
Fixes: d650ac060237 ("drm/i915/gvt: reset the GGTT entry when vGPU created")
Cc: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
As those debug messages might appear in every timer call for scheduler,
it's too noisy, eat too much log and aren't meaningful. So remove them.
Cc: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
git://anongit.freedesktop.org/git/drm-misc into drm-next
drm-misc-next-fixes-2017-04-12
Core changes:
- Fix off-by-one bug in get_property ioctl for enums/bitmasks (Daniel)
Driver changes:
- Add mode_fixup to dw-hdmi bridge driver to ensure mode is validated (Romain)
* tag 'drm-misc-next-fixes-2017-04-12' of git://anongit.freedesktop.org/git/drm-misc:
drm: Fix get_property logic fumble
drm: dw-hdmi: Implement the mode_fixup drm helper
|
|
GP107 modesetting support (just recognising the chipset, no other changes until 4.12)
a couple of regression fixes, one of them a rather serious double-free issue that appeared in 4.10.
* 'linux-4.11' of git://github.com/skeggsb/linux:
drm/nouveau: initial support (display-only) for GP107
drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane state
drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi method
drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one
drm/nouveau/mpeg: mthd returns true on success now
|
|
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
drm/i915 fixes for v4.11-rc7
one rcu related fix, and a few GVT fixes.
* tag 'drm-intel-fixes-2017-04-12' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
drm/i915/gvt: set the correct default value of CTX STATUS PTR
drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state
drm/i915: Use a dummy timeline name for a signaled fence
drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
drm/i915/gvt: remove the redundant info NULL check
drm/i915/gvt: adjust mem size for low resolution type
drm/i915: Avoid lock dropping between rescheduling
drm/i915/gvt: exclude cfg space from failsafe mode
drm/i915/gvt: Activate/de-activate vGPU in mdev ops.
drm/i915/execlists: Wrap tail pointer after reset tweaking
drm/i915/perf: remove user triggerable warn
drm/i915/perf: destroy stream on sample_flags mismatch
drm/i915: Align "unfenced" tiled access on gen2, early gen3
|
|
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
drm-misc-fixes for 2017-04-11
Core changes:
- None
Driver changes
- udl: Fix unaligned memory access on SPARC (Jonathan)
* tag 'drm-misc-fixes-2017-04-11' of git://anongit.freedesktop.org/git/drm-misc:
drm/udl: Fix unaligned memory access in udl_render_hline
|
|
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358
[31908.547297] Read of size 8 by task drv_selftest/3781
[31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G BU W 4.10.0+ #451
[31908.547553] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[31908.547682] Call Trace:
[31908.547772] dump_stack+0x68/0x9f
[31908.547857] kasan_object_err+0x1c/0x70
[31908.547947] kasan_report_error+0x1f1/0x4f0
[31908.548038] ? kfree+0xaa/0x170
[31908.548121] kasan_report+0x34/0x40
[31908.548211] ? klist_children_get+0x20/0x30
[31908.548472] ? intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.548567] __asan_load8+0x5e/0x70
[31908.548824] intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.549080] intel_audio_deinit+0x28/0x80 [i915]
[31908.549315] i915_driver_unload+0xe4/0x360 [i915]
[31908.549551] ? i915_driver_load+0x1d70/0x1d70 [i915]
[31908.549651] ? trace_hardirqs_on+0xd/0x10
[31908.549885] i915_pci_remove+0x23/0x30 [i915]
[31908.549978] pci_device_remove+0x5c/0x100
[31908.550069] device_release_driver_internal+0x1db/0x2e0
[31908.550165] driver_detach+0x68/0xc0
[31908.550256] bus_remove_driver+0x8b/0x150
[31908.550346] driver_unregister+0x3e/0x60
[31908.550439] pci_unregister_driver+0x1d/0x110
[31908.550531] ? find_module_all+0x7a/0xa0
[31908.550791] i915_exit+0x1a/0x87 [i915]
[31908.550881] SyS_delete_module+0x264/0x2c0
[31908.550971] ? free_module+0x430/0x430
[31908.551064] ? trace_hardirqs_off_caller+0x16/0x110
[31908.551159] ? trace_hardirqs_on_caller+0x16/0x280
[31908.551256] ? trace_hardirqs_on_thunk+0x1a/0x1c
[31908.551350] entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.551440] RIP: 0033:0x7f1d67312ec7
[31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7
[31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8
[31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8
[31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000
[31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860
[31908.552121] ? trace_hardirqs_off_caller+0x16/0x110
[31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048
[31908.552306] Allocated:
[31908.552377] PID = 3781
[31908.552456] save_stack_trace+0x16/0x20
[31908.552539] kasan_kmalloc+0xee/0x190
[31908.552627] __kmalloc+0xdb/0x1b0
[31908.552713] platform_device_alloc+0x27/0x90
[31908.552804] platform_device_register_full+0x36/0x220
[31908.553066] intel_lpe_audio_init+0x41e/0x570 [i915]
[31908.553320] intel_audio_init+0xd/0x40 [i915]
[31908.553552] i915_driver_load+0x13f5/0x1d70 [i915]
[31908.553788] i915_pci_probe+0x65/0xe0 [i915]
[31908.553881] pci_device_probe+0xda/0x140
[31908.553969] driver_probe_device+0x400/0x660
[31908.554058] __driver_attach+0x11c/0x120
[31908.554147] bus_for_each_dev+0xe6/0x150
[31908.554237] driver_attach+0x26/0x30
[31908.554325] bus_add_driver+0x26b/0x3b0
[31908.554412] driver_register+0xce/0x190
[31908.554502] __pci_register_driver+0xaf/0xc0
[31908.554589] 0xffffffffa0550063
[31908.554675] do_one_initcall+0x8b/0x1e0
[31908.554764] do_init_module+0x102/0x325
[31908.554852] load_module+0x3aad/0x45e0
[31908.554944] SyS_finit_module+0x169/0x1a0
[31908.555033] entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.555119] Freed:
[31908.555188] PID = 3781
[31908.555266] save_stack_trace+0x16/0x20
[31908.555349] kasan_slab_free+0xb0/0x180
[31908.555436] kfree+0xaa/0x170
[31908.555520] platform_device_release+0x76/0x80
[31908.555610] device_release+0x45/0xe0
[31908.555698] kobject_put+0x11f/0x260
[31908.555785] put_device+0x12/0x20
[31908.555871] platform_device_unregister+0x1b/0x20
[31908.556135] intel_lpe_audio_teardown+0x5c/0xb0 [i915]
[31908.556390] intel_audio_deinit+0x28/0x80 [i915]
[31908.556622] i915_driver_unload+0xe4/0x360 [i915]
[31908.556858] i915_pci_remove+0x23/0x30 [i915]
[31908.556948] pci_device_remove+0x5c/0x100
[31908.557037] device_release_driver_internal+0x1db/0x2e0
[31908.557129] driver_detach+0x68/0xc0
[31908.557217] bus_remove_driver+0x8b/0x150
[31908.557304] driver_unregister+0x3e/0x60
[31908.557394] pci_unregister_driver+0x1d/0x110
[31908.557653] i915_exit+0x1a/0x87 [i915]
[31908.557741] SyS_delete_module+0x264/0x2c0
[31908.557834] entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.557919] Memory state around the buggy address:
[31908.558005] ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558127] ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558374] ^
[31908.558467] ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558595] ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe,
and we need to coordinate a proper fix in platform_device itself.
Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Jerome Anand <jerome.anand@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.uk
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.12-rc1
This contains two new drivers for a Sitronix and a Samsung panel as well
as two new panels supported by the panel-simple driver.
* tag 'drm/panel/for-4.12-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: simple: Add support for Winstar WF35LTIACD
devicetree: add vendor prefix for Winstar Display Corp.
drm/panel: Add driver for sitronix ST7789V LCD controller
dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
drm/panel: Add support for S6E3HA2 panel driver on TM2 board
dt-bindings: Add support for Samsung s6e3ha2 panel binding
drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H
dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
|
|
Yet again I've proven that I can't negate conditions :(
Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170410115445.13829-1-daniel.vetter@ffwll.ch
|
|
Add the missing unlock before return from function etnaviv_gpu_submit()
in the error handling case.
lst: fixed label name.
Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with
GPU mutex")
CC: stable@vger.kernel.org #4.9+
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
|
Currently intel_dp_check_link_status() tries to retrain the link if
Clock recovery or Channel EQ for any of the lanes indicated by
intel_dp->lane_count is not set. However these values cached in intel_dp
structure can be stale if link training has failed for these values
during previous modeset. Or these values can get stale since we have
now re read the DPCD registers or it can be 0 in case of connected boot
case.
This patch validates these values against the max link rate and max lane
count values.
This is absolutely required incase the common_rates or max lane count
are now different due to link fallback.
v2:
* Include the FIXME commnet inside the function (Ville Syrjala)
* Remove the redundant parenthesis (Ville Syrjala)
v3 by Jani:
* rebase on the DP refactoring series
* rename intel_dp_link_params_is_valid to intel_dp_link_params_valid
* minor stylistic changes
v4:
* Compare the link rate against max link rate not the
common_rates since common_rates does not account for the
lowered fallback link rate value. (Ville Syrjala)
v5:
* Fixed a warning for unused variable (Manasi)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491512412-30016-1-git-send-email-manasi.d.navare@intel.com
|
|
igt_mmap_offset_exhaustion() selftest was using live requests to make an
object busy, but we did not hold a runtime pm wakeref for submitting the
requests. Acquire it to avoid triggering "RPM wakelock ref not held
during HW access" warnings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170411234427.14841-3-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
If we have a mock engine and it has no more requests in flight, report
it as idle as there is no hardware to contradict us! Otherwise we
attempt to query the hw that doesn't exist and find that the hw hasn't
set its idle bit and we get upset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170411234427.14841-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Provide dummy function pointers for the mock device in case we do hit
mmio during testing.
v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412092143.3822-1-chris@chris-wilson.co.uk
|
|
When discussing a new WC mmap, we based the interface upon the
assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef
("drm/i915: Wait for writes through the GTT to land before reading
back") and ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer
coherency issue") demonstrate that writes through the GTT are indeed
delayed and may be overtaken by direct WC access. To be safe, if
userspace is mixing WC mmaps with other potential GTT access (pwrite,
GTT mmaps) it should use set_domain(WC).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96563
Testcase: igt/gem_pwrite/small-gtt*
Testcase: igt/drv_selftest/coherency
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412110111.26626-2-chris@chris-wilson.co.uk
|
|
In the next patch, we will introduce a new cache domain for
differentiating between GTT access and direct WC access. This will
require us to include WC in our write_domain flushes. Rather than
duplicate a third function, combine the existing two into one and
flushing WC writes will then be automatically handled as well.
v2: Be smarter and clearer by passing in the write domains to flush (Joonas)
v3: One missed ~ in v2 conversion
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412110111.26626-1-chris@chris-wilson.co.uk
|
|
There is no need to acquire all locks here,
doing a commit after forcing a modeset on the affected crtc
is enough. Any other locks needed will be acquired as needed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491312297-18673-1-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This reverts commit ea49c9acf2db7082f0406bb3a570cc6bad37082b.
mode_config.mutex was originally added to fix WARNs in connector
functions, but now that atomic nonblocking modeset support is
included, we will likely never hold any any lock at all.
The WARN mentioned in commit bbf35e9defb9a6d1 ("drm/i915:
Pass atomic state to intel_audio_codec_enable, v2."), so it's
safe to revert this now.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491312168-18147-1-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No properties are supported, so just use the helper and reject everything.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491815239-10685-6-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No properties are supported, so just use the helper and reject
everything.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491815239-10685-5-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
