Re: [Intel-gfx] [RFC 23/33] drm/i915: Convert i915_gem_flush_ggtt_writes to intel_gt

On 17/06/2019 21:01, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-17 19:12:26) From: Tvrtko Ursulin Having introduced struct intel_gt (named the anonymous structure in i915) we can start using it to compartmentalize our code better. It makes more sense logically to have the code intern

Re: [Intel-gfx] [PATCH] Documentation/i915: fix file references after display/ subdir renames

On Mon, 17 Jun 2019, Rodrigo Vivi wrote: > On Mon, Jun 17, 2019 at 01:29:44PM +0300, Jani Nikula wrote: >> Fix the plethora of Sphinx build errors after moving the display files >> under a subdirectory. >> >> Fixes: 379bc100232a ("drm/i915: move modesetting output/encoder code under >> display/"

Re: [Intel-gfx] [PATCH] drm/rcar-du: Fix error check when retrieving crtc state

Hi Sean, Thank you for the patch. On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote: > From: Sean Paul > > drm_atomic_get_crtc_state() returns an error pointer when it fails, so > the null check is doing nothing here. > > Credit to 0-day/Dan Carpenter for reporting this. > > Fixes: 6f

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Serialise both updates to PDE and our shadow (rev2)

== Series Details == Series: drm/i915/gtt: Serialise both updates to PDE and our shadow (rev2) URL : https://patchwork.freedesktop.org/series/62203/ State : success == Summary == CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13310_full

Re: [Intel-gfx] [PATCH 26/59] drm/rcar-du: Drop drm_gem_prime_export/import

Hi Daniel, Thank you for the patch. On Fri, Jun 14, 2019 at 10:35:42PM +0200, Daniel Vetter wrote: > They're the default. > > Aside: Would be really nice to switch the others over to > drm_gem_object_funcs. > > Signed-off-by: Daniel Vetter > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: li

Re: [Intel-gfx] [PATCH 28/59] drm/shmob: Drop drm_gem_prime_export/import

Hi Daniel, Thank you for the patch. On Fri, Jun 14, 2019 at 10:35:44PM +0200, Daniel Vetter wrote: > They're the default. > > Aside: Would be really nice to switch the others over to > drm_gem_object_funcs. > > Signed-off-by: Daniel Vetter > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: li

[Intel-gfx] [PATCH 05/26] drm/i915/execlists: Preempt-to-busy

When using a global seqno, we required a precise stop-the-workd event to handle preemption and unwind the global seqno counter. To accomplish this, we would preempt to a special out-of-band context and wait for the machine to report that it was idle. Given an idle machine, we could very precisely s

[Intel-gfx] [PATCH 11/26] dma-fence: Refactor signaling for manual invocation

Move the duplicated code within dma-fence.c into the header for wider reuse. In the process apply a small micro-optimisation to only prune the fence->cb_list once rather than use list_del on every entry. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/dma-buf/Makefile

[Intel-gfx] [PATCH 06/26] drm/i915/execlists: Minimalistic timeslicing

If we have multiple contexts of equal priority pending execution, activate a timer to demote the currently executing context in favour of the next in the queue when that timeslice expires. This enforces fairness between contexts (so long as they allow preemption -- forced preemption, in the future,

[Intel-gfx] [PATCH 01/26] drm/i915: Keep engine alive as we retire the context

Though we pin the context first before taking the pm wakeref, during retire we need to unpin before dropping the pm wakeref (breaking the "natural" onion). During the unpin, we may need to attach a cleanup operation on to the engine wakeref, ergo we want to keep the engine awake until after the unp

[Intel-gfx] [PATCH 03/26] drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait()

Since commit eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"), the I915_WAIT_LOCKED flags passed to i915_request_wait() has been defunct. Now go ahead and remove it from all callers. References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex") Signed-of

[Intel-gfx] [PATCH 07/26] drm/i915/execlists: Force preemption

If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging

[Intel-gfx] [PATCH 08/26] drm/i915: Make the semaphore saturation mask global

The idea behind keeping the saturation mask local to a context backfired spectacularly. The premise with the local mask was that we would be more proactive in attempting to use semaphores after each time the context idled, and that all new contexts would attempt to use semaphores ignoring the curre

[Intel-gfx] [PATCH 02/26] drm/i915: Skip shrinking already freed pages

Previously, we want to shrink the pages of freed objects before they were RCU collected. However, by removing the struct_mutex serialisation around the active reference, we need to acquire an extra reference around the wait. Unfortunately this means that we have to skip objects that are waiting RCU

[Intel-gfx] [PATCH 26/26] drm/i915: Move idle barrier cleanup into engine-pm

Now that we now longer need to guarantee that the active callback is under the struct_mutex, we can lift it out of the i915_gem_park() and into the engine parking itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_pm.c| 19 --- drivers/gpu/drm/i915/gt/i

[Intel-gfx] [PATCH 24/26] drm/i915: Teach execbuffer to take the engine wakeref not GT

In the next patch, we would like to couple into the engine wakeref to free the batch pool on idling. The caveat here is that we therefore want to track the engine wakeref more precisely and to hold it instead of the broader GT wakeref as we process the ioctl. Signed-off-by: Chris Wilson --- .../

[Intel-gfx] [PATCH 25/26] drm/i915: Replace struct_mutex for batch pool serialisation

Switch to tracking activity via i915_active on individual nodes, only keeping a list of retired objects in the cache, and reaping the cache when the engine itself idles. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuff

[Intel-gfx] [PATCH 21/26] drm/i915: Extract intel_frontbuffer active tracking

Move the active tracking for the frontbuffer operations out of the i915_gem_object and into its own first class (refcounted) object. In the process of detangling, we switch from low level request tracking to the easier i915_active -- with the plan that this avoids any potential atomic callbacks as

[Intel-gfx] [PATCH 23/26] drm/i915: Rename intel_wakeref_[is]_active

Our general rule is to use is/has as the verb for boolean functions, rename intel_wakeref_active to intel_wakeref_is_active so the question being asked is clear. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_pm.c| 3 ++- drivers/gpu/drm/i915/gt/intel_engine.h| 6 +

[Intel-gfx] [PATCH 18/26] drm/i915: Push the i915_active.retire into a worker

As we need to use a mutex to serialise i915_active activation (because we want to allow the callback to sleep), we need to push the i915_active.retire into a worker callback in case we get need to retire from an atomic context. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/g

[Intel-gfx] [PATCH 04/26] drm/i915: Flush the execution-callbacks on retiring

In the unlikely case the request completes while we regard it as not even executing on the GPU (see the next patch!), we have to flush any pending execution callbacks at retirement and ensure that we do not add any more. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 93 ++

[Intel-gfx] [PATCH 17/26] drm/i915: Provide an i915_active.acquire callback

If we introduce a callback for i915_active that is only called the first time we use the i915_active and is symmetrically paired with the i915_active.retire callback, we can replace the open-coded and non-atomic implementations -- which will be very fragile (i.e. broken) upon removing the struct_mu

[Intel-gfx] [PATCH 14/26] drm/i915: Signal fence completion from i915_request_wait

With the upcoming change to automanaged i915_active, the intent is that whenever we wait on the set of active fences, they are signaled and collected. The requirement is that all successful returns from i915_request_wait() signal the fence, so fixup the one remaining path where we may return befor

[Intel-gfx] [PATCH 15/26] drm/i915: Remove waiting & retiring from shrinker paths

i915_gem_wait_for_idle() and i915_retire_requests() introduce a dependency on the timeline->mutex. This is problematic as we want to later perform allocations underneath i915_active.mutex, forming a link between the shrinker, the timeline and active mutexes. Nip this cycle in the bud by removing th

[Intel-gfx] [PATCH 10/26] dma-fence: Report the composite sync_file status

Same as for the individual fences, we want to report the actual status of the fence when queried. Reported-by: Petri Latvala Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Petri Latvala --- drivers/dma-buf/sync_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-

[Intel-gfx] [PATCH 20/26] drm/i915: Forgo last_fence active request tracking

We were using the last_fence to track the last request that used this vma that might be interpreted by a fence register and forced ourselves to wait for this request before modifying any fence register that overlapped our vma. Due to requirement that we need to track any XY_BLT command, linear or t

[Intel-gfx] [PATCH 22/26] drm/i915: Coordinate i915_active with its own mutex

Forgo the struct_mutex serialisation for i915_active, and interpose its own mutex handling for active/retire. This is a multi-layered sleight-of-hand. First, we had to ensure that no active/retire callbacks accidentally inverted the mutex ordering rules, nor assumed that they were themselves seria

[Intel-gfx] [PATCH 19/26] drm/i915/overlay: Switch to using i915_active tracking

Remove the raw i915_active_request tracking in favour of the higher level i915_active tracking for the sole purpose of making the lockless transition easier in later patches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/display/intel_overlay.c | 130 +-- drivers/gpu/drm/i

[Intel-gfx] [PATCH 12/26] dma-fence: Always execute signal callbacks

Allow for some users to surreptiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence. This means that we may have a cb_list even if the signaling bit is not enabled, so always notify the callbacks. The cost is that dma_fence_signal() must alw

[Intel-gfx] [PATCH 09/26] dma-fence: Propagate errors to dma-fence-array container

When one of the array of fences is signaled, propagate its errors to the parent fence-array (keeping the first error to be raised). v2: Opencode cmpxchg_local to avoid compiler freakout. Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan --- drivers/dma-buf/dma-fence-array.c | 1

[Intel-gfx] [PATCH 16/26] drm/i915: Throw away the active object retirement complexity

Remove the accumulated optimisations that we have for i915_vma_retire and reduce it to the bare essential of tracking the active object reference. This allows us to only use atomic operations, and so will be able to avoid the struct_mutex requirement. The principal loss here is the shrinker MRU bu

[Intel-gfx] [PATCH 13/26] drm/i915: Track i915_active using debugobjects

Provide runtime asserts and tracking of i915_active via debugobjects. For example, this should allow us to check that the i915_active is only active when we expect it to be and is never freed too early. One consequence is that, for simplicity, we no longer allow i915_active to be on-stack which on

Re: [Intel-gfx] [PATCH 01/22] drm/i915: Restore -Wunused-but-set-variable

On Mon, 17 Jun 2019, Chris Wilson wrote: > We appear to be clear of this warning, so time to re-enable the gcc error > checking. > > Signed-off-by: Chris Wilson Acked-by: Jani Nikula > --- > drivers/gpu/drm/i915/Makefile | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm

Re: [Intel-gfx] [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import

On Tue, Jun 18, 2019 at 6:49 AM Gerd Hoffmann wrote: > > Hi, > > > > While most callbacks are pretty straight forward (just hook the same > > > callbacks into the drm_gem_object_funcs. struct) the mmap bits are a > > > bit more obscure. > > > > > > First, there seem to be two ways to mmap a gem

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for linux-next: build failure after merge of the drm-misc tree

On Fri, 14 Jun 2019, Stephen Rothwell wrote: > Hi all, > > On Fri, 14 Jun 2019 04:47:35 - Patchwork > wrote: >> >> == Series Details == >> >> Series: linux-next: build failure after merge of the drm-misc tree >> URL : https://patchwork.freedesktop.org/series/62080/ >> State : failure >>

Re: [Intel-gfx] [PATCH 23/26] drm/i915: Rename intel_wakeref_[is]_active

Quoting Chris Wilson (2019-06-18 08:41:50) > @@ -422,6 +423,11 @@ static inline void intel_engine_reset(struct > intel_engine_cs *engine, > bool intel_engine_is_idle(struct intel_engine_cs *engine); > bool intel_engines_are_idle(struct drm_i915_private *dev_priv); > > +static inline bool intel

[Intel-gfx] ✓ Fi.CI.IGT: success for prime doc polish and ... a few cleanups (rev2)

== Series Details == Series: prime doc polish and ... a few cleanups (rev2) URL : https://patchwork.freedesktop.org/series/62135/ State : success == Summary == CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13311_full Summary -

Re: [Intel-gfx] [PATCH 1/6] drm/i915: use vfuncs for reg_read/write_fw_domains

On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote: Instead of going through the if-else chain every time, let's save the function in the uncore structure. Note that the new functions are purposely not used from the reg read/write functions to keep the inlining there. Looks good to me. Reviewe

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 1/4] meson: add libatomic dependency

On 14/06/2019 09:07, Ser, Simon wrote: > On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote: >> Add conditional dependency on libatomic in order to be able to use the >> __atomic_* functions instead of the older __sync_* ones. The >> libatomic library is only needed when there aren't any na

Re: [Intel-gfx] [PATCH 3/6] drm/i915: kill uncore_to_i915

On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote: Let's get rid of it before it proliferates, since with split GT/Display uncores the container_of won't work anymore. I've kept the rpm pointer as well to minimize the pointer chasing in the MMIO accessors. Signed-off-by: Daniele Ceraolo Spurio

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/4] gitlab-ci: add libatomic to docker images

On 14/06/2019 13:53, Ser, Simon wrote: > On Fri, 2019-06-14 at 15:43 +0300, Petri Latvala wrote: >> On Fri, Jun 14, 2019 at 02:24:53PM +0300, Ser, Simon wrote: >>> On Fri, 2019-06-14 at 13:00 +0300, Petri Latvala wrote: On Thu, Jun 13, 2019 at 02:53:20PM +0100, Guillaume Tucker wrote: > Ad

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/26] drm/i915: Keep engine alive as we retire the context

== Series Details == Series: series starting with [01/26] drm/i915: Keep engine alive as we retire the context URL : https://patchwork.freedesktop.org/series/62278/ State : warning == Summary == $ dim checkpatch origin/drm-tip cda76c80993d drm/i915: Keep engine alive as we retire the context

[Intel-gfx] [PATCH] drm/i915: Switch to per-crtc vblank vfuncs

From: Ville Syrjälä Switch from the driver-wide vblank vfuncs to the per-crtc ones so that we don't have so many platform specific vfuncs in the driver struct. We still need to do something about the rest fo the irq vfuncs... Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel

Re: [Intel-gfx] [PATCH 4/6] drm/i915: skip forcewake actions on forcewake-less uncore

On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote: We always call some of the setup/cleanup functions for forcewake, even if the feature is not actually available. Skipping these operations if forcewake is not available saves us some operations on older gens and prepares us for having a forcewak

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/26] drm/i915: Keep engine alive as we retire the context

== Series Details == Series: series starting with [01/26] drm/i915: Keep engine alive as we retire the context URL : https://patchwork.freedesktop.org/series/62278/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Keep engine alive as we retir

[Intel-gfx] ✓ Fi.CI.IGT: success for Display uncore prep patches

== Series Details == Series: Display uncore prep patches URL : https://patchwork.freedesktop.org/series/62232/ State : success == Summary == CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13312_full Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH] drm/i915: Check visibility in icl_build_plane_wm

Op 17-06-2019 om 14:34 schreef Ville Syrjälä: > On Fri, Jun 14, 2019 at 12:39:41PM +0200, Maarten Lankhorst wrote: >> When a planar YUV plane is configured, but the crtc is >> marked inactive, we can end up with a linked plane without >> visibility. > How is that possible? I don't think we should b

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/26] drm/i915: Keep engine alive as we retire the context

== Series Details == Series: series starting with [01/26] drm/i915: Keep engine alive as we retire the context URL : https://patchwork.freedesktop.org/series/62278/ State : success == Summary == CI Bug Log - changes from CI_DRM_6290 -> Patchwork_13320 =

[Intel-gfx] [PATCH 2/2] drm/prime: Update docs

Yes this is a bit a big patch, but since it's essentially a complete rewrite of all the prime docs I didn't see how to better split it up. Changes: - Consistently point to drm_gem_object_funcs as the preferred hooks, where applicable. - Document all the hooks in &drm_driver that lacked kerneldo

Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > Hi all, > > As discussed with Daniel V, I'm just doing the paperwork here as drm-misc > maintainer. > > This is the topic pull request for the fbdev notifier removal. > > Bar, please make a final check and pull into your fbdev tree. > > Lee, plea

[Intel-gfx] [PATCH 1/2] drm/prime: Shuffle functions.

Reorder all the functions in drm_prime.[hc] into three groups: core, export helpers, import helpers. Not other changes beyond moving the functions and their unchanged kerneldoc around in here. Cc: Sam Ravnborg Cc: Eric Anholt Cc: Emil Velikov Signed-off-by: Daniel Vetter --- drivers/gpu/drm/

Re: [Intel-gfx] [PATCH 5/6] drm/i915: dynamically allocate forcewake domains

On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote: We'd like to introduce a display uncore with no forcewake domains, so let's avoid wasting memory and be ready to allocate only what we need. Even without multiple uncore, we still don't need all the domains on all gens. Looks good in principle

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Switch to per-crtc vblank vfuncs

== Series Details == Series: drm/i915: Switch to per-crtc vblank vfuncs URL : https://patchwork.freedesktop.org/series/62287/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Switch to per-crtc vblank vfuncs +drivers/gpu/drm/i915/i915_irq.c:338

Re: [Intel-gfx] [PATCH 20/59] drm/meson: Drop drm_gem_prime_export/import

On 14/06/2019 22:35, Daniel Vetter wrote: > They're the default. > > Aside: Would be really nice to switch the others over to > drm_gem_object_funcs. Yep, adding this to my infinite TODO list > > Signed-off-by: Daniel Vetter > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: linux-amlo...@lists.i

[Intel-gfx] [PATCH] drm/i915/blt: Remove recursive vma->lock

As we have already plugged the w->dma into the reservation_object, and have set ourselves up to automatically signal the request and w->dma on completion, we do not need to export the rq->fence directly and just use the w->dma fence. This avoids having to take the reservation_lock inside the worke

Re: [Intel-gfx] [PATCH 30/59] drm/stm: Drop drm_gem_prime_export/import

Hi Daniel, Acked-by: Philippe Cornu We will have a look to simplify this part of the code. Thank you for your patch. Philippe :-) On 6/14/19 10:35 PM, Daniel Vetter wrote: > They're the default. > > Aside: Would be really nice to switch the others over to > drm_gem_object_funcs. > > Signed-

[Intel-gfx] ✗ Fi.CI.BAT: failure for prime doc polish and ... a few cleanups (rev4)

== Series Details == Series: prime doc polish and ... a few cleanups (rev4) URL : https://patchwork.freedesktop.org/series/62135/ State : failure == Summary == Applying: drm/todo: Improve drm_gem_object funcs todo Using index info to reconstruct a base tree... M Documentation/gpu/todo.rs

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Switch to per-crtc vblank vfuncs

== Series Details == Series: drm/i915: Switch to per-crtc vblank vfuncs URL : https://patchwork.freedesktop.org/series/62287/ State : success == Summary == CI Bug Log - changes from CI_DRM_6290 -> Patchwork_13321 Summary --- **SUCCES

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/blt: Remove recursive vma->lock

== Series Details == Series: drm/i915/blt: Remove recursive vma->lock URL : https://patchwork.freedesktop.org/series/62290/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h AR

Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > Hi all, > > > > As discussed with Daniel V, I'm just doing the paperwork here as drm-misc > > maintainer. > > > > This is the topic pull request for the fbdev notifier removal. > > > > Bar, pleas

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/rcar-du: Fix error check when retrieving crtc state

== Series Details == Series: drm/rcar-du: Fix error check when retrieving crtc state URL : https://patchwork.freedesktop.org/series/62234/ State : success == Summary == CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13314_full Summ

Re: [Intel-gfx] [PATCH 4/6] drm/i915: skip forcewake actions on forcewake-less uncore

Quoting Daniele Ceraolo Spurio (2019-06-17 19:09:33) > We always call some of the setup/cleanup functions for forcewake, even > if the feature is not actually available. Skipping these operations if > forcewake is not available saves us some operations on older gens and > prepares us for having a f

Re: [Intel-gfx] [PATCH] drm/i915/guc: Reduce verbosity on log overflows

Quoting Michal Wajdeczko (2019-06-17 15:38:53) > On Mon, 17 Jun 2019 12:09:17 +0200, Chris Wilson > wrote: > > > If the user is clearing the log buffer too slowly, we overflow. As this > > is an expected condition, and the driver tries to handle it, reduce the > > error message down to a notice

Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

On Tue, Jun 18, 2019 at 11:03:47AM +0100, Lee Jones wrote: > On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > > > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > > Hi all, > > > > > > As discussed with Daniel V, I'm just doing the paperwork here as drm-misc > > > maintainer. > > > > > > This

Re: [Intel-gfx] [PATCH] drm/i915/guc: Reduce verbosity on log overflows

On Tue, 18 Jun 2019 12:24:30 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-06-17 15:38:53) On Mon, 17 Jun 2019 12:09:17 +0200, Chris Wilson wrote: > If the user is clearing the log buffer too slowly, we overflow. As this > is an expected condition, and the driver tries to han

Re: [Intel-gfx] [PATCH 00/59] prime doc polish and ... a few cleanups

On 2019/06/17, Emil Velikov wrote: > Hi Daniel, > > On Fri, 14 Jun 2019 at 21:36, Daniel Vetter wrote: > > > > Hi all, > > > > So I figured let's get going and polish the docs for the last part of drm > > core/helpers that hasn't yet seen some neat polish last few years. With > > the goal to make

Re: [Intel-gfx] [PATCH 6/6] drm/i915/gvt: decouple check_vgpu() from uncore_init()

Quoting Daniele Ceraolo Spurio (2019-06-17 19:09:35) > With multiple uncore to initialize (GT vs Display), it makes little > sense to have the vgpu_check inside uncore_init(). We also have > a catch-22 scenario where the uncore is required to read the vgpu > capabilities while the vgpu capabilities

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Signal fence completion from i915_request_wait

== Series Details == Series: drm/i915: Signal fence completion from i915_request_wait URL : https://patchwork.freedesktop.org/series/62241/ State : success == Summary == CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13315_full Sum

[Intel-gfx] [PATCH] drm/i915/execlists: Detect cross-contamination with GuC

The process_csb routine from execlists_submission is incompatible with the GuC backend. Add a warning to detect if we accidentally end up in the wrong spot. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Michal Wajdeczko Cc: Michał Winiarski --- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +

Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

Hi, On 6/18/19 11:20 AM, Maarten Lankhorst wrote: > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: >> Hi all, >> >> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc >> maintainer. >> >> This is the topic pull request for the fbdev notifier removal. >> >> Bar, please m

Re: [Intel-gfx] [PATCH i-g-t v2] gitlab-ci: add build for MIPS

On 14/06/2019 11:33, Arkadiusz Hiler wrote: > On Thu, Jun 13, 2019 at 03:01:06PM +0100, Guillaume Tucker wrote: >> Add Docker image and Gitlab CI steps to run builds for the MIPS >> architecture using Debian Stretch with backports. >> >> Signed-off-by: Guillaume Tucker >> --- >> .gitlab-ci.yml

Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

On Tue, 18 Jun 2019, Daniel Vetter wrote: > On Tue, Jun 18, 2019 at 11:03:47AM +0100, Lee Jones wrote: > > On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > > > > > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > > > Hi all, > > > > > > > > As discussed with Daniel V, I'm just doing the paper

Re: [Intel-gfx] [PATCH] drm/i915: Check visibility in icl_build_plane_wm

On Tue, Jun 18, 2019 at 11:16:41AM +0200, Maarten Lankhorst wrote: > Op 17-06-2019 om 14:34 schreef Ville Syrjälä: > > On Fri, Jun 14, 2019 at 12:39:41PM +0200, Maarten Lankhorst wrote: > >> When a planar YUV plane is configured, but the crtc is > >> marked inactive, we can end up with a linked pla

Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz: > Hi, > > On 6/18/19 11:20 AM, Maarten Lankhorst wrote: >> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: >>> Hi all, >>> >>> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc >>> maintainer. >>> >>> This is the t

[Intel-gfx] [PATCH 2/6] drm/ttm: remove the backing store if no placement is given

Pipeline removal of the BOs backing store when no placement is given during validation. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index c7de667d482a

[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10

On the exporter side we add optional explicit pinning callbacks. If those callbacks are implemented the framework no longer caches sg tables and the map/unmap callbacks are always called with the lock of the reservation object held. On the importer side we add an optional invalidate callback. This

[Intel-gfx] [PATCH 6/6] drm/amdgpu: add independent DMA-buf import v6

Instead of relying on the DRM functions just implement our own import functions. This prepares support for taking care of unpinned DMA-buf. v2: enable for all exporters, not just amdgpu, fix invalidation handling, lock reservation object while setting callback v3: change to new dma_buf attach

[Intel-gfx] [PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

Avoid that we ping/pong the buffers when we stop to pin DMA-buf exports by using the allowed domains for exported buffers. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/

[Intel-gfx] [PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6

The caching of SGT's is actually quite harmful and should probably removed altogether when all drivers are audited. Start by providing a separate DMA-buf export implementation in amdgpu. This is also a prerequisite of unpinned DMA-buf handling. v2: fix unintended recursion, remove debugging lefto

[Intel-gfx] [PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2

This way we can even pipeline imported BO evictions. v2: Limit this to only cases when the parent object uses a separate reservation object as well. This fixes another OOM problem. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++- 1 file changed

Re: [Intel-gfx] [PATCH] drm/i915: Check visibility in icl_build_plane_wm

On Tue, Jun 18, 2019 at 02:44:00PM +0300, Ville Syrjälä wrote: > On Tue, Jun 18, 2019 at 11:16:41AM +0200, Maarten Lankhorst wrote: > > Op 17-06-2019 om 14:34 schreef Ville Syrjälä: > > > On Fri, Jun 14, 2019 at 12:39:41PM +0200, Maarten Lankhorst wrote: > > >> When a planar YUV plane is configured

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: Force manual PSR exit in older gens

== Series Details == Series: drm/i915/psr: Force manual PSR exit in older gens URL : https://patchwork.freedesktop.org/series/62249/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13316_full Summary --

Re: [Intel-gfx] [PATCH 02/26] drm/i915: Skip shrinking already freed pages

Quoting Chris Wilson (2019-06-18 08:41:29) > Previously, we want to shrink the pages of freed objects before they > were RCU collected. However, by removing the struct_mutex serialisation > around the active reference, we need to acquire an extra reference > around the wait. Unfortunately this mean

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Don't clobber M/N values during fastset check

On Thu, Jun 13, 2019 at 12:24:59PM +0300, Ville Syrjälä wrote: > On Wed, Jun 12, 2019 at 08:24:23PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We're now calling intel_pipe_config_compare(..., true) uncoditionally > > which means we're always going clobber the calculated M/N value

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Constify intel_pipe_config_compare()

On Wed, Jun 12, 2019 at 04:07:59PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Now that intel_pipe_config_compare() no longer clobbers the passed > in state we can make both crtc states const. And while at we simplify > the calling convention, and clean up intel_compare_link_m_n() a bit

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Detect cross-contamination with GuC

== Series Details == Series: drm/i915/execlists: Detect cross-contamination with GuC URL : https://patchwork.freedesktop.org/series/62296/ State : success == Summary == CI Bug Log - changes from CI_DRM_6291 -> Patchwork_13324 Summary --

[Intel-gfx] [PATCH i-g-t v3 4/4] tests/sw_sync: use atomic_* instead of __sync_*

Replace calls to the older __sync_* functions with the new atomic_* standard ones to be consistent with other tests and improve portability across CPU architectures. Add dependency of sw_sync on libatomic. Signed-off-by: Guillaume Tucker Reviewed-by: Simon Ser --- Notes: v2: use atomic_* a

[Intel-gfx] [PATCH i-g-t v3 3/4] i915/gem_create: use atomic_* instead of __sync_*

This fixes builds on some architectures, in particular MIPS which doesn't have __sync_add_and_fetch_8 and __sync_val_compare_and_swap_8 for 64-bit variable handling. * replace calls to the older __sync_* functions with the new atomic_* standard ones * use the _Atomic type modifier as required wi

[Intel-gfx] [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

Add libatomic to the Fedora docker image so it can link binaries that use __atomic_* functions. Also explicitly add libatomic1 to Debian docker images as it is needed in particular on non-x86 architectures for run-time linkage. Signed-off-by: Guillaume Tucker --- Notes: v2: add libatomic1 i

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10

== Series Details == Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10 URL : https://patchwork.freedesktop.org/series/62299/ State : warning == Summary == $ dim checkpatch origin/drm-tip 82449d2b5de6 dma-buf: add dynamic DMA-buf handling v10 -:11: WARNING:COMMIT_LOG_

[Intel-gfx] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

Add conditional dependency on libatomic in order to be able to use the __atomic_* functions instead of the older __sync_* ones. The libatomic library is only needed when there aren't any native support on the current architecture, so a linker test is used for this purpose. This enables atomic ope

[Intel-gfx] [PATCH i-g-t v3 0/4] Use C11 atomics

This series replaces calls to the __sync_* functions with the more recent atomic_* ones defined in stdatomic.h in gem_create and sw_sync. It also adds dependency on libatomic when required, that is to say when the CPU architecture doesn't provide native support for some atomic operations. This ma

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10

== Series Details == Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10 URL : https://patchwork.freedesktop.org/series/62299/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: dma-buf: add dynamic DMA-buf handling v10 Okay! Comm

Re: [Intel-gfx] [PATCH 48/59] drm/vgem: Ditch attach trickery in the fence ioctl

Quoting Daniel Vetter (2019-06-14 21:36:04) > It looks like this was done purely to get a consistent place to look > up the reservation object pointer. With the drm_prime.c helper code > now also setting gem_object->resv for imported objects we can just use > that pointer directly, instead of first

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Drop the _INCOMPLETE for has_infoframe

On Wed, Jun 12, 2019 at 04:08:01PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We have full infoframe readout now so we can replace the > PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_infoframe) with the normal > PIPE_CONF_CHECK_BOOL(has_infoframe). > > Signed-off-by: Ville Syrjälä Reviewed-by

[Intel-gfx] [PATCH i-g-t v3 1/1] gitlab-ci: add build and tests for MIPS

Add Docker image and Gitlab CI steps to run builds and tests for the MIPS architecture using Debian Stretch with backports. Signed-off-by: Guillaume Tucker --- Notes: v2: use stretch-backports and require libatomic1 v3: add mips ci tests and require Debian libatomic1 for mips .gitlab-c

Re: [Intel-gfx] [PATCH] drm/i915/blt: Remove recursive vma->lock

On Tue, 18 Jun 2019 at 10:53, Chris Wilson wrote: > > As we have already plugged the w->dma into the reservation_object, and > have set ourselves up to automatically signal the request and w->dma on > completion, we do not need to export the rq->fence directly and just use > the w->dma fence. > >

Re: [Intel-gfx] [PATCH] drm/i915: Switch to per-crtc vblank vfuncs

On Tue, 18 Jun 2019, Ville Syrjala wrote: > From: Ville Syrjälä > > Switch from the driver-wide vblank vfuncs to the per-crtc ones so that > we don't have so many platform specific vfuncs in the driver struct. > > We still need to do something about the rest fo the irq vfuncs... We'll also need

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Drop the _INCOMPLETE for has_infoframe

On Tue, Jun 18, 2019 at 03:34:46PM +0300, Imre Deak wrote: > On Wed, Jun 12, 2019 at 04:08:01PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We have full infoframe readout now so we can replace the > > PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_infoframe) with the normal > > PIPE_CONF_CHE

[Intel-gfx] [PATCH] drm/i915: Use drm_gem_object.resv

Since commit 1ba627148ef5 ("drm: Add reservation_object to drm_gem_object"), struct drm_gem_object grew its own builtin reservation_object rendering our own private own bloat. Remove our redundant reservation_object and point into obj->base.resv instead. Signed-off-by: Chris Wilson Cc: Tvrtko Urs

  1   2   3   >