[Intel-gfx] [PATCH 122/190] drm/i915: Move setting of request->batch into its single callsite

request->batch_obj is only set by execbuffer for the convenience of debugging hangs. By moving that operation to the callsite, we can simplify all other callers and future patches. We also move the complications of reference handling of the request->batch_obj next to where the active tracking is

[Intel-gfx] [PATCH 115/190] drm/i915: Remove (struct_mutex) locking for busy-ioctl

By applying the same logic as for wait-ioctl, we can query whether a request has completed without holding struct_mutex. The biggest impact system-wide is removing the flush_active and the contention that causes. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 104/190] drm/i915: Remove i915_gem_execbuffer_retire_commands()

Move the single line to the callsite as the name is now misleading, and the purpose is solely to add the request to the execution queue. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 + 1 file changed, 1 insertion(+), 8

[Intel-gfx] [PATCH 097/190] drm/i915/shrinker: Flush active on objects before counting

As we inspect obj->active to decide how many objects we can shrink (we only shrink idle objects), it helps to flush the active lists first in order to have a more accurate count of available objects. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 091/190] drm/i915: Move context initialisation to first-use

Instead of allocating a new request when allocating a context, use the request that initiated the allocation to emit the context initialisation. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_lrc.c | 42

[Intel-gfx] [PATCH 103/190] drm/i915: Move pinning of dev_priv->kernel_context into its creator

Rather than have every context ask "am I owned by the kernel? pin!", move that logic into the creator of the kernel context, in order to improve code comprehension. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 53

[Intel-gfx] [PATCH 090/190] drm/i915: Refactor execlists default context pinning

Refactor pinning and unpinning of contexts, such that the default context for an engine is pinned during initialisation and unpinned during teardown (pinning of the context handles the reference counting). Thus we can eliminate the special case handling of the default context that was required to

[Intel-gfx] [PATCH 134/190] drm/i915: Refactor execbuffer relocation writing

With in the introduction of the reloc page cache, we are just one step away from refactoring the relocation write functions into one. Not only does it tidy the code (slightly), but it greatly simplifies the control logic much to gcc's satisfaction. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 108/190] drm/i915: Start passing around i915_vma from execbuffer

During execbuffer we look up the i915_vma in order to reserver them in the VM. However, we then do a double lookup of the vma in order to then pin them, all because we lack the necessary interfaces to operate on i915_vma. v2: Tidy parameter lists to remove one level of redirection in the hot

[Intel-gfx] [PATCH 114/190] drm/i915: Remove (struct_mutex) locking for wait-ioctl

With a bit of care (and leniency) we can iterate over the object and wait for previous rendering to complete with judicial use of atomic reference counting. The ABI requires us to ensure that an active object is eventually flushed (like the busy-ioctl) which is guaranteed by our management of

[Intel-gfx] [PATCH 093/190] drm/i915: Move the forced switch back to the kernel context into eviction

Currently, we always switch back to the kernel context (if available, i.e. legacy HW contexts not execlists) whenever we try and idle the GPU. We actually only require the switch when trying to evict everything (in order to prevent fragmentation from placement of the currently active context) from

[Intel-gfx] [PATCH 099/190] drm/i915: Check for request completion before choosing CS flips

Only queue a CS flip if the outstanding request is not complete, and in particular do not rely on the request tracking being fresh (since it is only updated when requests are retired). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 5 - 1

[Intel-gfx] [PATCH 101/190] drm/i915: Only retire if necessary when creating a userptr

We only want to retire requests if we have an existing object that conflicts with the fresh userptr range in order to avoid unnecessary work during creation of every userptr. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_userptr.c | 20

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Don't need a timer to wake us up

On Fri, Jan 08, 2016 at 11:29:41AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Looks like the sleeping loop in __i915_wait_request can be > simplified by using io_schedule_timeout instead of setting > up and destroying a timer. > > Signed-off-by: Tvrtko

[Intel-gfx] [PATCH 106/190] drm/i915: Split insertion/binding of an object into the VM

Split the insertion into the address space's range manager and binding of that object into the GTT to simplify the code flow when pinning a VMA. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 33 +++-- 1 file changed, 15

[Intel-gfx] [PATCH 089/190] drm/i915: Tidy execlists submission and tracking

Other than dramatically simplifying the submission code (requests ftw), we can reduce the execlist spinlock duration and importantly avoid having to hold it across the context switch register reads. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] [PATCH 087/190] Revert "drm/i915: Clean up associated VMAs on context destruction"

This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae. The patch was only a stop-gap measure that fixed half the problem - the leak of the fbcon when restarting X. A complete solution required releasing the VMA when the object itself was closed rather than rely on file/process exit. The

[Intel-gfx] [PATCH 105/190] drm/i915: Pad GTT views of exec objects up to user specified size

Our GPUs impose certain requirements upon buffers that depend upon how exactly they are used. Typically this is expressed as that they require a larger surface than would be naively computed by pitch * height. Normally such requirements are hidden away in the userspace driver, but when we accept

Re: [Intel-gfx] [PATCH 04/13] drm/i915: Fail engine initialization if LRCA is incorrectly aligned

On Fri, Jan 08, 2016 at 11:29:43AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > LRCA can change only when it goes from unpinned to pinned so it > makes sense to check its alignment at that point rather than at > every batch buffer submission. > >

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Cache LRCA in the context

On Fri, Jan 08, 2016 at 11:29:44AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We are not allowed to call i915_gem_obj_ggtt_offset from irq > context without the big kernel lock held. > > LRCA lifetime is well defined so cache it so it can be looked up >

[Intel-gfx] [PATCH 035/190] drm/i915: Remove redundant queue_delayed_work() from throttle ioctl

We know, by design, that whilst the GPU is active (and thus we are throttling) the retire_worker is queued. Therefore attempting to requeue it with queue_delayed_work() is a no-op and we can safely remove it. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 044/190] drm/i915: Move GEM request routines to i915_gem_request.c

Migrate the request operations out of the main body of i915_gem.c and into their own C file for easier expansion. v2: Move __i915_add_request() across as well Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile | 1 +

[Intel-gfx] [PATCH 080/190] drm/i915: Store owning file on the i915_address_space

For the global GTT (and aliasing GTT), the address space is owned by the device (it is a global resource) and so the per-file owner field is NULL. For per-process GTT (where we create an address space per context), each is owned by the opening file. We can use this ownership information to both

[Intel-gfx] [PATCH 077/190] drm/i915: Amalgamate GGTT/ppGTT vma debug list walkers

As we can now have multiple VMA inside the global GTT (with partial mappings, rotations, etc), it is no longer true that there may just be a single GGTT entry and so we should walk the full vma_list to count up the actual usage. In addition to unifying the two walkers, switch from multiplying the

[Intel-gfx] [PATCH 074/190] drm/i915: Rename request->list to link for consistency

We use "list" to denote the list and "link" to denote an element on that list. Rename request->list to match this idiom. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_gem.c | 12 ++--

[Intel-gfx] [PATCH 062/190] drm/i915: Rename extern functions operating on intel_engine_cs

Using intel_ring_* to refer to the intel_engine_cs functions is most confusing! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 10 +++ drivers/gpu/drm/i915/i915_dma.c| 8 +++--- drivers/gpu/drm/i915/i915_drv.h|

[Intel-gfx] [PATCH 025/190] drm/i915: Broadwell execlists needs exactly the same seqno w/a as legacy

In legacy mode, we use the gen6 seqno barrier to insert a delay after the interrupt before reading the seqno (as the seqno write is not flushed before the interrupt is sent, the interrupt arrives before the seqno is visible). Execlists ignored the evidence of igt. Note that is harder, but not

[Intel-gfx] [PATCH 042/190] drm/i915: Clean up GPU hang message

Remove some redundant kernel messages as we deduce a hung GPU and capture the error state. v2: Fix "hang" vs "no progress" message whilst I was there Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 21 +++-- 1 file changed, 7

[Intel-gfx] [PATCH 081/190] drm/i915: i915_vma_move_to_active prep patch

This patch is broken out of the next just to remove the code motion from that patch and make it more readable. What we do here is move the i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three stages (read, write, fenced) together so that future modifications to active handling are

[Intel-gfx] [PATCH 079/190] drm/i915: Reduce the pointer dance of i915_is_ggtt()

The multiple levels of indirect do nothing but hinder the compiler and the pointer chasing turns to be quite painful but painless to fix. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 13 ++--- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 069/190] drm/i915: Remove duplicate golden render state init from execlists

Now that we use the same vfuncs for emitting the batch buffer in both execlists and legacy, the golden render state initialisation is identical between both. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_render_state.c | 22 --

[Intel-gfx] [PATCH 072/190] drm/i915: Execlists cannot pin a context without the object

Given that the intel_lr_context_pin cannot succeed without the object, we cannot reach intel_lr_context_unpin() without first allocating that object - so we can remove the redundant test. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 19

[Intel-gfx] [PATCH 053/190] drm/i915: Convert i915_semaphores_is_enabled over to early sanitize

Rather than recomputing whether semaphores are enabled, we can do that computation once during early initialisation as the i915.semaphores module parameter is now read-only. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +-

[Intel-gfx] [PATCH 066/190] drm/i915: Simplify request_alloc by returning the allocated request

If is simpler and leads to more readable code through the callstack if the allocation returns the allocated struct through the return value. The importance of this is that it no longer looks like we accidentally allocate requests as side-effect of calling certain functions. Signed-off-by: Chris

[Intel-gfx] [PATCH 057/190] drm/i915: Remove the identical implementations of request space reservation

Now that we share intel_ring_begin(), reserving space for the tail of the request is identical between legacy/execlists and so the tautology can be removed. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 7 +++

[Intel-gfx] [PATCH 071/190] drm/i915: Simplify calling engine->sync_to

Since requests can no longer be generated as a side-effect of intel_ring_begin(), we know that the seqno will be unchanged during ring-emission. This predicatablity then means we do not have to check for the seqno wrapping around whilst emitting the semaphore for engine->sync_to(). Signed-off-by:

[Intel-gfx] [PATCH 049/190] drm/i915: Disable waitboosting for mmioflips/semaphores

Since commit a6f766f3975185af66a31a2cea2cd38721645999 Author: Chris Wilson Date: Mon Apr 27 13:41:20 2015 +0100 drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts and commit bcafc4e38b6ad03f48989b7ecaff03845b5b7acf Author: Chris Wilson

[Intel-gfx] [PATCH 003/190] drm/i915: Add an optional selection from i915 of CONFIG_MMU_NOTIFIER

userptr requires mmu-notifier for full unprivileged support. Most systems have mmu-notifier support already enabled as a requirement for virtualisation support, but we should make the option for i915 to take advantage of mmu-notifiers explicit (and enable by default so that regular userspace can

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE dmesg-warn -> PASS

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms:

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms:

[Intel-gfx] [PATCH 102/190] drm/i915: Move the "per-ring" default_context to the device

We have a false notion of a default_context allocated per engine, whereas actually it is a singular context reserved for kernel use. Remove it from the engines, and rename it thus. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 19

[Intel-gfx] [PATCH 127/190] drm/i915: Cache kmap between relocations

When doing relocations, we have to obtain a mapping to the page containing the target address. This is either a kmap or iomap depending on GPU and its cache coherency. Neighbouring relocation entries are typically within the same page and so we can cache our kmapping between them and avoid those

[Intel-gfx] [PATCH 098/190] drm/i915: Double check the active status on the batch pool

We should not rely on obj->active being uptodate unless we manually flush it. Instead, we can verify that the next available batch object is idle by looking at its last active request (and checking it for completion). Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 112/190] drm/i915: Move obj->active:5 to obj->flags

We are motivated to avoid using a bitfield for obj->active for a couple of reasons. Firstly, we wish to document our lockless read of obj->active using READ_ONCE inside i915_gem_busy_ioctl() and that requires an integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code when

[Intel-gfx] [PATCH 118/190] drm/i915: Remove locking for get_tiling

Since we are not concerned with userspace racing itself with set-tiling (the order is indeterminant even if we take a lock), then we can safely read back the single obj->tiling_mode and do the static lookup of swizzle mode without having to take a lock. get-tiling is reasonably frequent due to

[Intel-gfx] [PATCH 135/190] drm/i915: Move map-and-fenceable tracking to the VMA

By moving map-and-fenceable tracking from the object to the VMA, we gain fine-grained tracking and the ability to track individual fences on the VMA (subsequent patch). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 46

[Intel-gfx] [PATCH 131/190] drm/i915: Pin the pages first in shmem prepare read/write

There is an improbable, but not impossible, case that if we leave the pages unpin as we operate on the object, then somebody may steal the lock and change the cache domains after we have already inspected them. (Whilst here, avail ourselves of the opportunity to take a couple of steps to make the

[Intel-gfx] [PATCH 110/190] drm/i915: Move vma->pin_count:4 to vma->flags

Let's aide gcc in our pin_count tracking as i915_vma_pin()/i915_vma_unpin() are some of the hotest of the hot functions and gcc doesn't like bitfields that much! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h| 20 +++

[Intel-gfx] [PATCH 111/190] drm/i915: Make fb_tracking.lock a spinlock

We only need a very lightweight mechanism here as the locking is only used for co-ordinating a bitfield. Also double check that the object is still pinned to the display plane before processing the state change. v2: Move the cheap unlikely tests into the caller Signed-off-by: Chris Wilson

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-nuci7) pass -> DMESG-WARN (skl-i7k-2)

Re: [Intel-gfx] [PATCH] drm/i915: Handle error paths during watermark sanitization properly (v2)

Hey, Op 11-01-16 om 19:27 schreef Matt Roper: > sanitize_watermarks() does not properly handle errors returned by > drm_atomic_helper_duplicate_state(). Make failures drop locks before > returning. We also change the lock of connection_mutex to a > drm_modeset_lock_all_ctx() to make sure any

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on a90796840c30dac6d9907439bf98d1d08046c49d drm-intel-nightly: 2016y-01m-11d-17h-22m-54s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE Test kms_pipe_crc_basic: Subgroup

Re: [Intel-gfx] [PATCH 13/22] drm/exynos: Remove event cancelling from postclose

Hi Daniel, It seems your patch is exactly same as below my one I posted before, http://www.spinics.net/lists/dri-devel/msg97922.html Anyway, it's ok if this patch can go to mainline. Acked-by: Inki Dae 2016년 01월 12일 06:41에 Daniel Vetter 이(가) 쓴 글: > The core takes care of

Re: [Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl

On Tue, 12 Jan 2016, Jonathan Corbet wrote: > In my mind, there's clearly no good that can come from (further) delaying > something that works in favor of an "it would be nice" that may never > even exist. So I'm currently thinking that I'll pull this into the docs > tree once

Re: [Intel-gfx] [PATCH v2 0/6] drm/i915: start hiding away vbt structure from the driver

On Mon, 11 Jan 2016, Lukas Wunner wrote: > Hi, > > On Mon, Jan 11, 2016 at 09:54:36PM +0200, Jani Nikula wrote: >> Hi all, first real patches since the RFC at [1]. >> >> The VBT is a monster and it keeps growing. Originally we've extracted >> bits and pieces out of there, and

Re: [Intel-gfx] [PATCH 5/7] drm/i915/dp: Add methods to update link train params

>-Original Message- >From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] >Sent: Monday, January 11, 2016 8:07 PM >To: R, Durgadoss; intel-gfx@lists.freedesktop.org >Subject: Re: [PATCH 5/7] drm/i915/dp: Add methods to update link train params > >On Fri, 2015-12-11 at 15:09

Re: [Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl

On Sat, 12 Dec 2015 12:13:45 +0100 Daniel Vetter wrote: > I just figured there's no way this could get it, and I'd > much rather improve the docs themselves than trying to convince core > kernel folks that this might be useful. So I'm not quite sure why you figured that; I

Re: [Intel-gfx] [RFC 2/2] drm/i915: Render decompression support for Gen9

> -Original Message- > From: Daniel Stone [mailto:dan...@fooishbar.org] > Sent: Wednesday, December 23, 2015 1:37 AM > To: Kannan, Vandana > Cc: intel-gfx; Konduru, Chandra; Murthy, Arun R > Subject: Re: [Intel-gfx] [RFC 2/2] drm/i915: Render decompression support for > Gen9 > > Hi

Re: [Intel-gfx] [PATCH v4 02/38] drm/i915: Explicit power enable during deferred context initialisation

On Mon, Jan 11, 2016 at 06:42:31PM +, john.c.harri...@intel.com wrote: > From: John Harrison > > A later patch in this series re-organises the batch buffer submission > code. Part of that is to reduce the scope of a pm_get/put pair. > Specifically, they previously

Re: [Intel-gfx] [PATCH v4 00/38] GPU scheduler for i915 driver

> From: john.c.harri...@intel.com > Sent: Tuesday, January 12, 2016 2:42 AM > > From: John Harrison > > Implemented a batch buffer submission scheduler for the i915 DRM driver. > > The general theory of operation is that when batch buffers are > submitted to the

Re: [Intel-gfx] [PATCH] igt/gem_trtt: Exercise the TRTT hardware

> From: akash.g...@intel.com > Sent: Saturday, January 09, 2016 7:32 PM > [...] > > There is a provision to keep TR-TT Tables in virtual space, where the pages of > TRTT tables will be mapped to PPGTT. This is the adopted mode, as in this mode > UMD will have a full control on TR-TT

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects

On Mon, Jan 11, 2016 at 05:15:54PM +, Tvrtko Ursulin wrote: > > Is that not what was written? I take it my telepathy isn't working > > again. > > Sorry not a new loop, new case in a old loop. This is the hunk I think > is not helping readability: > > @@ -869,11 +967,29 @@

[Intel-gfx] [PATCH 01/22] drm: kerneldoc for drm_fops.c

Just prep work before I throw more drm_event refactorings on top. Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter --- Documentation/DocBook/gpu.tmpl | 48 +--

[Intel-gfx] [PATCH 00/22] drm_event cleanup, round 2

Hi all, Mostly just small changes from review feedback (plus a few misplaced hunks, silly me). Plus an attempt at better kerneldoc to explain how this works. Since that caused questions both from Thomas and Laurent let me explain things also here: Currently anyone using drm_events (vblank code,

[Intel-gfx] [PATCH 16/22] drm/omap: Nuke close hooks

Again since the core takes care of this we can remove them. While at it also remove the postclose hook, it's empty. v2: Laurent pointed me at even more code to delete. Cc: Laurent Pinchart Cc: Tomi Valkeinen Acked-by: Daniel Stone

[Intel-gfx] [PATCH 03/22] drm/exynos: Use the new event init/free functions

Also fixes a bug in IPP with not correctly checking/allocating for space in the event space. Not a too serious bug since it's not a real ringbuffer, just a limit to avoid too much kernel allocations. Cc: Rob Clark Cc: Inki Dae Acked-by: Daniel Stone

[Intel-gfx] [PATCH 19/22] drm/tegra: Stop cancelling page flip events

The core takes care of that now. v2: Fixup misplaced hunk. Cc: Thierry Reding Cc: Terje Bergström Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 15/22] drm/msm: Nuke preclose hooks

They only complete the page flip events to avoid oops when the drm file closes. The core takes care of that now and we can remove this code. Cc: Rob Clark Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by:

[Intel-gfx] [PATCH 02/22] drm: Add functions to setup/tear down drm_events.

An attempt at not spreading out the file_priv->event_space stuff out quite so far and wide. And I think fixes something in ipp_get_event() that is broken (or if they are doing something more weird/subtle, then breaks it in a fun way). Based upon a patch from Rob Clark, rebased and polished. v2:

[Intel-gfx] [PATCH 10/22] drm: Nuke vblank event file cleanup code

The core code now takes care of unlinking drm_events from the file in a generic way, so this code isn't needed any more. For those wondering where the drm_vblank_put went to: With the new logic events only get unlinked, but still exist. Hence any resources (like vblank counters) don't need to be

[Intel-gfx] [PATCH] drm/vmwgfx: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: I've completely missed eaction->fpriv_head and all the related code. We need to nuke that too to avoid accidentally deferencing the freed-up vmwgfx-private fpriv. v3: Also remove

[Intel-gfx] [PATCH 13/22] drm/exynos: Remove event cancelling from postclose

The core takes care of this now. And since kfree(NULL) is ok we can simplify the function even further now. Cc: Inki Dae Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 18/22] drm/shmob: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: Fixup misplaced hunk. Cc: Laurent Pinchart Acked-by: Daniel Stone Reviewed-by: Alex Deucher (v1)

[Intel-gfx] [PATCH 11/22] drm/i915: Nuke intel_modeset_preclose

Now that the drm core unlinks/disarms events there's no need to do so ourselves anymore. Nuke the code. Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_dma.c

[Intel-gfx] [PATCH 04/22] drm/vmwgfx: Use the new event init/free functions

Cc: Rob Clark Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 32

[Intel-gfx] [PATCH 07/22] drm/armada: Remove NULL open/pre/postclose hooks

The compiler will do this, but the void hits when grepping all the hooks for a subsystem wide audit are slightly annoying. So remove them for next time around. Cc: Russell King Acked-by: Daniel Stone Reviewed-by: Alex Deucher

[Intel-gfx] [PATCH 14/22] drm/imx: Unconfuse preclose logic

So this one is special, since it tries to prevent races when userspace crashes simply by disabling the vblank machinery. Well except that imx always has vblanks enabled, and the disable_vblank hook actually just tries to cancel a pending pageflip. Without any locking whatsoever. Of course this is

[Intel-gfx] [PATCH 09/22] drm: Clean up pending events in the core

There's really no reason to not do so, instead of replicating this for every use-case and every driver. Now we can't just nuke the events, since that would still mean that all drm_event users would need to know when that has happened, since calling e.g. drm_send_event isn't allowed any more.

[Intel-gfx] [PATCH 12/22] drm/atmel: Nuke preclose

The only thing this did was cancle pending flip events, and the core takes care of that now. Cc: Boris Brezillon Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 08/22] drm/gma500: Remove empty preclose hook

I'm auditing them all, empty ones just confuse ... Cc: Patrik Jakobsson Acked-by: Daniel Stone Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter --- drivers/gpu/drm/gma500/psb_drv.c

[Intel-gfx] [PATCH 05/22] drm: Create drm_send_event helpers

Use them in the core vblank code and exynos/vmwgfx drivers. Note that the difference between wake_up_all and _interruptible in vmwgfx doesn't matter since the only waiter is the core code in drm_fops.c. And that is interruptible. v2: Adjust existing kerneldoc too. Reviewed-by: Alex Deucher

[Intel-gfx] [PATCH 21/22] drm/vc4: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: Fixup misplaced hunk. Cc: Eric Anholt Acked-by: Daniel Stone Reviewed-by: Alex Deucher (v1) Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 17/22] drm/rcar: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. Cc: Laurent Pinchart Acked-by: Daniel Stone Reviewed-by: Alex Deucher Reviewed-by: Laurent Pinchart

[Intel-gfx] [PATCH 22/22] drm/vmwgfx: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: I've completely missed eaction->fpriv_head and all the related code. We need to nuke that too to avoid accidentally deferencing the freed-up vmwgfx-private fpriv. v3: Also remove

[Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: Fixup misplaced hunks. Cc: Rob Clark Acked-by: Daniel Stone Reviewed-by: Alex Deucher (v1) Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties

Hi, On 5 January 2016 at 10:23, Daniel Vetter wrote: > On Wed, Dec 23, 2015 at 09:47:00AM +, Daniel Stone wrote: >> It's not even a legacy vs. atomic thing, this can happen in >> pure-atomic as well. Same as the render-compression plane property >> that I just replied to

Re: [Intel-gfx] [PATCH] drm/i915: Support to enable TRTT on GEN9

On 1/11/2016 2:19 PM, Chris Wilson wrote: On Mon, Jan 11, 2016 at 01:09:50PM +0530, Goel, Akash wrote: On 1/10/2016 11:09 PM, Chris Wilson wrote: On Sat, Jan 09, 2016 at 05:00:21PM +0530, akash.g...@intel.com wrote: From: Akash Goel Gen9 has an additional address

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Cache ringbuffer GTT address

On Mon, Jan 11, 2016 at 02:08:37PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Purpose is to avoid calling i915_gem_obj_ggtt_offset from the > interrupt context without the big lock held. No. Tracking the pinned VMA has none of these problems. -Chris --

Re: [Intel-gfx] [PATCH] igt/gem_trtt: Exercise the TRTT hardware

On Mon, Jan 11, 2016 at 12:32:08PM +, Chris Wilson wrote: > On Sat, Jan 09, 2016 at 05:01:30PM +0530, akash.g...@intel.com wrote: > > +static void submit_and_sync(int fd, struct drm_i915_gem_execbuffer2 > > *execbuf, > > + uint32_t batch_buf_handle) > > +{ > > +

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

Patchwork writes: > == Summary == > > Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: > 2016y-01m-11d-07h-30m-16s UTC integration manifest > > Test gem_storedw_loop: > Subgroup basic-render: > pass ->

[Intel-gfx] [PATCH] tools/Android.mk: Add zlib support

IGT does not build for Android due to a zlib dependency being added to intel_error_decode.c in a recent patch. This patch fixes the error by updating the Android makefile to add the path to the zlib library and using any LDFLAGS specified in Makefile.sources. Signed-off-by: Derek Morton

[Intel-gfx] [PATCH v2 0.999/9] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

Use our newly created encoder_mask to iterate over the encoders. Signed-off-by: Maarten Lankhorst --- This depends on the atomic encoder_mask patches and is required for unifying power domain handling. diff --git a/drivers/gpu/drm/i915/intel_display.c

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Adding the parsing logic for the i2c element

On Mon, 11 Jan 2016, Jani Nikula wrote: > On Thu, 07 Jan 2016, Ville Syrjälä wrote: >> On Mon, Dec 21, 2015 at 03:11:02PM +0200, Jani Nikula wrote: >>> From: vkorjani >>> >>> New sequence element for i2c is been

Re: [Intel-gfx] [PATCH igt] core/sighelper: Interrupt everyone in the process group

On Mon, Jan 11, 2016 at 01:29:12PM +, Dave Gordon wrote: > On 11/01/16 12:34, Chris Wilson wrote: > >On Mon, Jan 11, 2016 at 12:25:07PM +, Dave Gordon wrote: > >>On 11/01/16 09:06, Daniel Vetter wrote: > >>>On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote: > On Mon, Jan 11,

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects

On 22/12/15 17:40, Chris Wilson wrote: On Tue, Dec 22, 2015 at 11:58:33AM +, Tvrtko Ursulin wrote: Maybe: if (!obj->base.filp || cpu_write_needs_clflush(obj)) ret = i915_gem_gtt_pwrite_fast(...); if (ret == -EFAULT && !obj->base.filp) { ret

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page

On Mon, Jan 11, 2016 at 11:39:27AM +, Michel Thierry wrote: > Kernel and userspace are able to handle 4GB (1<<32) address space range, > but "A32 Stateless Model" is not. According to documentation, A32 accesses > are based on General State Base Address and bound checking is in place. >

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Adding the parsing logic for the i2c element

On Thu, 07 Jan 2016, Ville Syrjälä wrote: > On Mon, Dec 21, 2015 at 03:11:02PM +0200, Jani Nikula wrote: >> From: vkorjani >> >> New sequence element for i2c is been added in the >> mipi sequence block of the VBT. This patch parses >> and

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC integration manifest Test core_auth: Subgroup basic-auth: pass -> SKIP (snb-dellxps) pass -> SKIP (bdw-ultra) Test

[Intel-gfx] [PATCH] drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page

Kernel and userspace are able to handle 4GB (1<<32) address space range, but "A32 Stateless Model" is not. According to documentation, A32 accesses are based on General State Base Address and bound checking is in place. Because size field (instruction State Base Address) limitation, it is not

<    1   2   3   4   5   >