[Intel-gfx] [PATCH 8/9] drm/i915: Rename ring->virtual_start as ring->vaddr

Just a different colour to better match virtual addresses elsewhere. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 11 +-- drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++-- 3 files

[Intel-gfx] [PATCH 7/9] drm/i915: Treat ringbuffer writes as write to normal memory

Ringbuffers are now being written to either through LLC or WC paths, so treating them as simply iomem is no longer adequate. However, for the older !llc hardware, the hardware is documentated as treating the TAIL register update as serialising, so we can relax the barriers when filling the rings

[Intel-gfx] [PATCH 1/9] drm/i915: Rename request reference/unreference to get/put

Now that we derive requests from struct fence, swap over to its nomenclature for references. It's shorter and more idiomatic across the kernel. s/i915_gem_request_reference/i915_gem_request_get/ s/i915_gem_request_unreference/i915_gem_request_put/ Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 6/9] drm/i915: Rename drm_gem_object_unreference_unlocked in preparation for lockless free

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 10 ++ drivers/gpu/drm/i915/i915_gem.c | 10 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-

[Intel-gfx] A simple batch of churn to make reference handling look consistent

And a bonus 3 patches that do a minor tweak to intel_ringbuffer.c and friends. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI,1/8] drm/i915: Move GEM request routines to i915_gem_request.c

== Series Details == Series: series starting with [CI,1/8] drm/i915: Move GEM request routines to i915_gem_request.c URL : https://patchwork.freedesktop.org/series/10078/ State : success == Summary == Series 10078v1 Series without cover letter

[Intel-gfx] [PATCH] drm-intel.rst: Clarify what "Switch to -nightly" means

Unclear whether dim co or plain cd was meant, suggested by Chris. Signed-off-by: Daniel Vetter --- drm-intel.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/drm-intel.rst b/drm-intel.rst index 6771bed6654e..492cb580bbd5 100644 --- a/drm-intel.rst +++

[Intel-gfx] [CI 5/8] drm/i915: Disable waitboosting for fence_wait()

We want to restrict waitboosting to known process contexts, where we can track which clients are receiving waitboosts and prevent excessive power wasting. For fence_wait() we do not have any client tracking and so that leaves it open to abuse. v2: Hide the IS_ERR_OR_NULL testing for special

[Intel-gfx] [CI 4/8] drm/i915: Derive GEM requests from dma-fence

dma-buf provides a generic fence class for interoperation between drivers. Internally we use the request structure as a fence, and so with only a little bit of interfacing we can rebase those requests on top of dma-buf fences. This will allow us, in the future, to pass those fences back to

[Intel-gfx] [CI 7/8] drm/i915: Mark imported dma-buf objects as being coherent

A foreign dma-buf does not share our cache domain tracking, and we rely on the producer ensuring cache coherency. Marking them as being in the CPU domain is incorrect. v2: Add commentary about the GTT domain. This is not the best place for it, but pending an actual overhaul of our domain tracking

[Intel-gfx] [CI 3/8] drm/i915: Mark all current requests as complete before resetting them

Following a GPU reset upon hang, we retire all the requests and then mark them all as complete. If we mark them as complete first, we both keep the normal retirement order (completed first then retired) and provide a small optimisation for concurrent lookups. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 8/8] drm/i915: Wait on external rendering for GEM objects

When transitioning to the GTT or CPU domain we wait on all rendering from i915 to complete (with the optimisation of allowing concurrent read access by both the GPU and client). We don't yet ensure all rendering from third parties (tracked by implicit fences on the dma-buf) is complete. Since

[Intel-gfx] [CI 2/8] drm/i915: Retire oldest completed request before allocating next

In order to keep the memory allocated for requests reasonably tight, try to reuse the oldest request (so long as it is completed and has no external references) for the next allocation. v2: Throw in a comment to hopefully make sure no one mistakes the optimistic retirement of the oldest request

[Intel-gfx] [CI 6/8] drm/i915: Disable waitboosting for mmioflips/semaphores

Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio flip RPS boosts") we have limited the waitboosting for semaphores and flips. Ideally we do not want to boost in either of these instances as no userspace

[Intel-gfx] [CI 1/8] 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 Acked-by: Mika Kuoppala Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH i-g-t v2 03/15] kms_psr_sink_crc: Use for_each_pipe_with_valid_output to find a valid config.

Op 19-07-16 om 15:58 schreef Ander Conselvan De Oliveira: > On Fri, 2016-07-15 at 14:15 +0300, Ander Conselvan De Oliveira wrote: >> On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: >>> This is the only time PIPE_ANY was used to mean something other than >>> unassign this output from a

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

On ti, 2016-07-19 at 15:27 +0100, Chris Wilson wrote: > On Tue, Jul 19, 2016 at 05:12:22PM +0300, Joonas Lahtinen wrote: > > > > On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote: > > > > > > + resv = i915_gem_object_get_dmabuf_resv(obj); > > > + if (resv) { > > > + long err; > > We

<    1   2   3