Chris Wilson writes:
> Quoting Mika Kuoppala (2019-06-14 10:22:16)
>> Chris Wilson writes:
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
>> > b/drivers/gpu/drm/i915/gt/intel_context.c
>> > index c78ec0b58e77..8e299c631575 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
>>
== Series Details ==
Series: drm/i915: Refine i915_reset.lock_map (rev3)
URL : https://patchwork.freedesktop.org/series/62017/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13272
Summary
---
== Series Details ==
Series: i915: gvt: no need to check return value of debugfs_create functions
URL : https://patchwork.freedesktop.org/series/62042/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13271
== Series Details ==
Series: drm/i915: Enable refcount debugging for default debug levels
URL : https://patchwork.freedesktop.org/series/62027/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13270
Summary
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
Same comment on libatomic1 as in the other thread applies here.
--
On Thu, Jun 13, 2019 at 02:53:20PM +0100, Guillaume Tucker wrote:
> Add libatomic to the Fedora docker image so it can link binaries that
> use __atomic_* functions. Also explicitly add libatomic1 to Debian
> docker images even though it's already installed as a dependency.
>
> Signed-off-by:
Quoting Tvrtko Ursulin (2019-06-14 10:42:11)
>
> On 14/06/2019 10:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-06-14 10:06:41)
> >>
> >> On 13/06/2019 14:49, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-06-13 14:35:17)
> From: Tvrtko Ursulin
>
> Start using
== Series Details ==
Series: series starting with [v2] drm/i915: Keep contexts pinned until after
the next kernel context switch (rev2)
URL : https://patchwork.freedesktop.org/series/61946/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6251_full -> Patchwork_13254_full
On 13/06/2019 15:08, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 14:35:31)
From: Tvrtko Ursulin
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes
On 14/06/2019 10:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-14 10:06:41)
On 13/06/2019 14:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 14:35:17)
From: Tvrtko Ursulin
Start using the newly introduced struct intel_gt to fuse together correct
logical init flow with
Quoting Tvrtko Ursulin (2019-06-14 10:34:06)
>
> On 13/06/2019 17:30, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-06-13 17:11:43)
> >>
> >> On 13/06/2019 14:59, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-06-13 14:35:24)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>
On 13/06/2019 15:03, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 14:35:27)
From: Tvrtko Ursulin
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes
On Fri, Jun 14, 2019 at 10:57:34AM +0200, Maarten Lankhorst wrote:
> Hi Dave and Daniel,
>
> Next pull request, with more fixes and features!
>
> drm-misc-next-2019-06-14:
> drm-misc-next for v5.3:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
> - Add code to signal all dma-fences when freed
Quoting Mika Kuoppala (2019-06-14 10:22:16)
> Chris Wilson writes:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index c78ec0b58e77..8e299c631575 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++
On 13/06/2019 17:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 17:11:43)
On 13/06/2019 14:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 14:35:24)
From: Tvrtko Ursulin
More removal of implicit dev_priv from using old mmio accessors.
Actually the top level
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, please make a final check and pull into your backlight tree.
Greg,
Quoting Tvrtko Ursulin (2019-06-14 10:06:41)
>
> On 13/06/2019 14:49, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-06-13 14:35:17)
> >> From: Tvrtko Ursulin
> >>
> >> Start using the newly introduced struct intel_gt to fuse together correct
> >> logical init flow with uncore for more
Chris Wilson writes:
> We need to keep the context image pinned in memory until after the GPU
> has finished writing into it. Since it continues to write as we signal
> the final breadcrumb, we need to keep it pinned until the request after
> it is complete. Currently we know the order in which
On Fri, 14 Jun 2019 at 08:11, Chris Wilson wrote:
>
> Since commit a679f58d0510 ("drm/i915: Flush pages on acquisition"), we
> flush objects on acquire their pages and as such when we create an
acquiring
> object for the purpose of writing into it, we do not need to manually
> flush.
>
>
On 13/06/2019 14:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 14:35:17)
From: Tvrtko Ursulin
Start using the newly introduced struct intel_gt to fuse together correct
logical init flow with uncore for more removal of implicit dev_priv in
mmio access.
Signed-off-by: Tvrtko
Hi Dave and Daniel,
Next pull request, with more fixes and features!
drm-misc-next-2019-06-14:
drm-misc-next for v5.3:
UAPI Changes:
Cross-subsystem Changes:
- Add code to signal all dma-fences when freed with pending signals.
- Annotate reservation object access in CONFIG_DEBUG_MUTEXES
Core
On Fri, 14 Jun 2019, Jani Nikula wrote:
>On Thu, 13 Jun 2019, "Lee, Shawn C" wrote:
>> Follow generla eDP backlight enable control sequence. Add T8 (valid
>> video data to backlight enable) delay before turn backlight_enable on.
>> And T9 (backlight disable to end of valida video data) delay
On Fri, Jun 07, 2019 at 11:24:01AM +0100, Emil Velikov wrote:
> On Wed, 5 Jun 2019 at 13:08, Daniel Vetter wrote:
> >
> > This completes Emil's series of removing DRM_UNLOCKED from modern
> > drivers. It's entirely cargo-culted since we ignore it on
> > non-DRIVER_LEGACY drivers since:
> >
> >
On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote:
> 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:
On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote:
> 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
On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote:
> Add libatomic to the Fedora docker image so it can link binaries that
> use __atomic_* functions. Also explicitly add libatomic1 to Debian
> docker images even though it's already installed as a dependency.
>
> Signed-off-by: Guillaume
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 native support
> on the current architecture,
On Thu, 13 Jun 2019, "Lee, Shawn C" wrote:
> Follow generla eDP backlight enable control sequence. Add T8 (valid video
> data to backlight enable) delay before turn backlight_enable on.
> And T9 (backlight disable to end of valida video data) delay after
> backlight_enable off.
There are two
On Fri, 14 Jun 2019, "Lee, Shawn C" wrote:
> On Thu, 13 Jun 2019, Jani Nikula wrote:
>>On Thu, 13 Jun 2019, Ville Syrjälä wrote:
>>> On Wed, Jun 12, 2019 at 10:47:22PM -0700, Lee, Shawn C wrote:
Modify aux backlight enable sequence just like what we did for
genernal eDP panel.
Op 14-06-2019 om 02:27 schreef Sean Paul:
> From: Sean Paul
>
> I missed amdgpu in my connnector_helper_funcs->atomic_check conversion,
> which is understandably causing compilation failures.
>
> Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to
> accept
== Series Details ==
Series: series starting with [01/39] drm/i915: Discard some redundant cache
domain flushes
URL : https://patchwork.freedesktop.org/series/62085/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Discard some redundant
== Series Details ==
Series: series starting with [01/39] drm/i915: Discard some redundant cache
domain flushes
URL : https://patchwork.freedesktop.org/series/62085/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6eb3b4d8d4bd drm/i915: Discard some redundant cache domain
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
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 |
Since commit a679f58d0510 ("drm/i915: Flush pages on acquisition"), we
flush objects on acquire their pages and as such when we create an
object for the purpose of writing into it, we do not need to manually
flush.
Signed-off-by: Chris Wilson
---
We only need to keep a unique tag for the active lifetime of the
context, and for as long as we need to identify that context. The HW
uses the tag to determine if it should use a lite-restore (why not the
LRCA?) and passes the tag back for various status identifies. The only
status we need to
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 16 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 ++---
drivers/gpu/drm/i915/i915_gem.c | 38 ---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 ++--
drivers/gpu/drm/i915/i915_vma.c
refcount_t is our first line of defence against use-after-free, so let's
enable it for debugging.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 88 +++--
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/intel_display.c | 146 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c| 1 -
5
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 27 +--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 -
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 30 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 11 +-
If we let pages be allocated asynchronously, we also then want to push
the binding process into an asynchronous task. Make it so, utilising the
recent improvements to fence error tracking and struct_mutex reduction.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c|
I am about to stuff more objects into the plane_config and would like to
have it clean up after itself. Move the current framebuffer release into
a common function so it can be extended with the new object with
relative ease.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
Serialising insertion into each of the global GTT and ppGTT accounts for
a large chunk of the current struct_mutex serialisation requireemnts.
(Note that it is not just the drm_mm / gtt management itself being
serialised, but the pin count and various flags.) Previously, the main
blocker for
While we need to flush the wakeref before parking, we do not need to
perform the i915_gem_park() itself underneath the wakeref lock, merely
the struct_mutex. If we rearrange the locks, we can avoid the unnecessary
tainting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c
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
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
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
As we need to use a mutex to serialisation 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
---
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 38
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 6 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 -
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 -
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 12 ++-
Assume that pages may be pinned in a background task and use a
completion event to synchronise with callers that must access the pages
immediately.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
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
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
Errors spread like wildfire, and must eventually be returned to the
user. They need to be captured and passed along the flow of fences,
infecting each in turn with the existing error, until finally they fall
out of a user visible result.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
This series is still under development, getting the coordination right
for async vma (having just make i915_vma refcounted, I need to actually
prevent the refcycles and fixup good old userspace in ggtt,
vma->open_count for everyone incl. gem_vm_ops).
[PATCH 01/39] drm/i915: Discard some redundant
How well does this work in practice? It means that unless someone else
is attempting to run we do not reset infinite loops. Maybe that is a
good thing.
Opens:
* This sacrifices error capture. Maybe make that an opt-in with a
watchdog.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko
We can reduce the locking for fence registers from the dev->struct_mutex
to a local mutex. We could introduce a mutex for the sole purpose of
tracking the fence acquisition, except there is a little bit of overlap
with the fault tracking, so use the i915_ggtt.mutex as it covers both.
We already use a mutex to serialise i915_reset() and wedging, so all we
need it to link that into i915_request_wait() and we have our lock cycle
detection.
v2.5: Take error mutex for selftests
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c|
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/i915_active.h | 19
drivers/gpu/drm/i915/intel_overlay.c |
In order to allow for asynchronous gathering of pages tracked by the
obj->resv, we take advantage of pinning the pages before doing waiting
on the reservation, and where possible do an early wait before acquiring
the object lock (with a follow up locked waited to ensure we have
exclusive access
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple
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
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
The premise here is to simply avoiding having to acquire the vm->mutex
inside vma create/destroy to update the vm->unbound_lists, to avoid some
nasty lock recursions later.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c
Throughout the code base we internally track vma (objects bound into
a particular GTT), with the objects themselves being the common backing
storage. By making the vma itself reference counted we can start
operating on the vma concurrently, moving work into async threads.
Just the conversion to
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
We no longer track the execution order along the engine and so no longer
need to enforce ordering of retire along the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 128 +++-
1 file changed, 52 insertions(+), 76 deletions(-)
diff --git
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
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
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
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
If we enter i915_request_wait() with an already completed request, but
unsignaled dma-fence, signal the fence before returning. This allows us
to execute any of the signal callbacks at the earliest opportunity.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file
On 14/06/2019 01:28, Robert M. Fosha wrote:
From: John Harrison
Updated whitelist table for ICL.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 87 +++--
1 file changed,
On 14/06/2019 01:28, Robert M. Fosha wrote:
From: John Harrison
Updated whitelist table for CFL.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 35 -
1 file changed,
On 14/06/2019 01:28, Robert M. Fosha wrote:
From: John Harrison
Newer hardware requires setting up whitelists on engines other than
render. So, extend the whitelist code to support all engines.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
On 14/06/2019 01:28, Robert M. Fosha wrote:
From: John Harrison
Newer hardware adds flags to the whitelist work-around register. These
allow per access direction privileges and ranges.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
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
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
>
== Series Details ==
Series: drm/kms: Catch mode_object lifetime errors
URL : https://patchwork.freedesktop.org/series/62083/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4800ebbe4df3 drm/kms: Catch mode_object lifetime errors
-:63: WARNING:NO_AUTHOR_SIGN_OFF: Missing
Only dynamic mode objects, i.e. those which are refcounted and have a free
callback, can be added while the overall drm_device is visible to
userspace. All others must be added before drm_dev_register and
removed after drm_dev_unregister.
Small issue around drivers still using the load/unload
301 - 379 of 379 matches
Mail list logo
