You can use the -y syntax in sub-directory Makefiles
of modules.
Demonstrate how it works.
PLEASE DO NOT APPLY FOR NOW: this is only for comments.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/i915/Makefile | 126 ++--
drivers/gpu/drm/i915/display/Makefile
On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
>
> On Sat, 3 Aug 2019 at 20:47, Maxime Ripard wrote:
> >
> > Hi Daniel, Dave,
> >
> > Here is the first (and pretty late) drm-misc-next PR.
> >
> > It's pretty big due to the lateness, but there's nothing really major
> > showing up. It's pretty
== Series Details ==
Series: kbuild: allow big modules to sub-divide Makefiles
URL : https://patchwork.freedesktop.org/series/64745/
State : failure
== Summary ==
Applying: kbuild: treat an object as multi-used when $(foo-) is set
Applying: kbuild: clean up modname calculation
Applying: kbuild
As we store a pointer to i915 in the drvdata field (as the pointer is both
an alias to the drm_device and drm_i915_private), we can use the stored
pointer directly as the i915 device.
v2: Store and use i915 inside drv_get_drvdata()
v3: Only expect i915 inside drv_get_drvdata() so drop the assumed
On Mon, 5 Aug 2019, Al Viro wrote:
> On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > > tmpfs does not set ->remount_fs() anymore and its users need
> > > to be converted to new mount API.
> >
> > Could you explain
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Defer final intel_wakeref_put
to process context
URL : https://patchwork.freedesktop.org/series/64730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6633_full -> Patchwork_13876_full
To actually DROP_IDLE means that we have to wait for ongoing submission,
and any new concurrently submitted, i.e. it should only be called during
single-threaded submission to ensure the GPU is idle before the new
action.
Signed-off-by: Chris Wilson
---
tests/i915/gem_persistent_relocs.c | 9 +++
Hi Chris,
On Tue, Aug 06, 2019 at 08:42:19AM +0100, Chris Wilson wrote:
> As we store a pointer to i915 in the drvdata field (as the pointer is both
> an alias to the drm_device and drm_i915_private), we can use the stored
> pointer directly as the i915 device.
>
> v2: Store and use i915 inside d
As we need to acquire a mutex to serialise the final
intel_wakeref_put, we need to ensure that we are in process context at
that time. However, we want to allow operation on the intel_wakeref from
inside timer and other hardirq context, which means that need to defer
that final put to a workqueue.
On Mon, 05 Aug 2019, Lucas De Marchi wrote:
> On Mon, Aug 05, 2019 at 12:48:16PM +0300, Jani Nikula wrote:
>>On Wed, 03 Jul 2019, Lucas De Marchi wrote:
>>> Let's make the just created intel_tc.c already follow the trend of using
>>> i915 instead of dev_priv and calling the intel_uncore_*() funct
== Series Details ==
Series: drm/i915: Use drm_i915_private directly from drv_get_drvdata() (rev3)
URL : https://patchwork.freedesktop.org/series/64377/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6637 -> Patchwork_13881
Hi Chris,
> +static void kill_context(struct i915_gem_context *ctx)
> +{
> + struct i915_gem_engines_iter it;
> + struct intel_engine_cs *engine;
> + intel_engine_mask_t tmp, active;
> + struct intel_context *ce;
> +
> + if (i915_gem_context_is_banned(ctx))
> + retu
Quoting Andi Shyti (2019-08-06 09:35:49)
> Hi Chris,
>
> > +static void kill_context(struct i915_gem_context *ctx)
> > +{
> > + struct i915_gem_engines_iter it;
> > + struct intel_engine_cs *engine;
> > + intel_engine_mask_t tmp, active;
> > + struct intel_context *ce;
> > +
> > +
To actually DROP_IDLE means that we have to wait for ongoing submission,
and any new concurrently submitted, i.e. it should only be called during
single-threaded submission to ensure the GPU is idle before the new
action.
v2: Also include SHRINK for thrash-all-the-things, and find a dupe in
gem_re
Am Mittwoch, 31. Juli 2019, 18:58:13 CEST schrieb Andrzej Pietrasiewicz:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Heiko Stuebner
_
Am Mittwoch, 31. Juli 2019, 18:58:14 CEST schrieb Andrzej Pietrasiewicz:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Heiko Stuebner
In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning safe. Since multiple engines/contexts
can share a single timeline, it needs to be protected by a mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 27 +++
Move the timeline from being inside the intel_ring to intel_context
itself. This saves much pointer dancing and makes the relations of the
context to its timeline much clearer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 35 +++---
.../gpu/drm/i915/gem/i91
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
Skip printing out idle engines that did not contribute to the GPU hang.
As the number of engines gets ever larger, we have increasing noise in
the error state where typically there is only one guilty request on one
engine that we need to inspect.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i
To maintain a fast lookup from a GT centric irq handler, we want the
engine lookup tables on the intel_gt. To avoid having multiple copies of
the same multi-dimension lookup table, move the generic user engine
lookup into an rbtree (for fast and flexible indexing).
v2: Split uabi_instance cf uabi_
Push the ring creation flags from the outer GEM context to the inner
intel_context to avoid an unsightly back-reference from inside the
backend.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 52 ++-
.../gpu/drm/i915/gem/i
We use timeline->mutex to protect modifications to
context->active_count, and the associated enable/disable callbacks.
Due to complications with engine-pm barrier there is a path where we used
a "superlock" to provide serialised protect and so could not
unconditionally assert with lockdep that it w
As we track when we put the GT device to sleep upon idling, we can use
that callback to sample the current rc6 counters and record the
timestamp for estimating samples after that point while asleep.
v2: Stick to using ktime_t
v3: Track user_wakerefs that interfere with the new
intel_gt_pm_wait_for
Currently we walk the entire list of obj->vma for each obj within a file
to find the matching vma of this context. Since we know we are searching
for a particular vma bound to a user context, we can use the rbtree to
search for it rather than repeatedly walk everything.
Signed-off-by: Chris Wilson
This giant switch has tendrils all other the struct and does not fit
into the rest of the driver bring up and control of i915_drv.c. Push it
to one side so that it can grow in peace.
Signed-off-by: Chris Wilson
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/g
We do not notify userspace when the scheduler capabilities are changed
(due to wedging the driver) and as such userspace will expect the caps
to be static and unchanging. Make it so, and so we only need to compute
our caps once during driver registration.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ur
As we need to acquire a mutex to serialise the final
intel_wakeref_put, we need to ensure that we are in process context at
that time. However, we want to allow operation on the intel_wakeref from
inside timer and other hardirq context, which means that need to defer
that final put to a workqueue.
Use the same mechanism to determine if a backend engine exists for a
uabi mapping as used internally.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm
Refactor the backends to handle the deferred context allocation in a
consistent manner, and allow calling it as an explicit first step in
pinning a context for the first time. This should make it easier for
backends to keep track of partially constructed contexts from
initialisation.
Signed-off-by
Modernise the mock_request factory to take intel_context not a (GEM
context, intel_engine_cs) tuple.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_request.c | 38 +++
drivers/gpu/drm/i915/selftests/mock_request.c | 6 +--
drivers/gpu/drm/i915/selftests/mock
Since we have already stopped the ring, cleared the ring, disabled the
ring (and verifying the ring is clear), a later debug message that the
ring is no longer clear serves no function. It appears it restarts
anyway, and we verify that the ring started correctly afterwards.
Signed-off-by: Chris Wi
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 | 129 +--
drivers/gpu/drm/i
Forgo the struct_mutex requirement for request retirement as we have
been transitioning over to only using the timeline->mutex for
controlling the lifetime of a request on that timeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 183 ++
drive
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
Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 -
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers
On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
>
> On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
> >
> > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard
> > wrote:
> > >
> > > Hi Daniel, Dave,
> > >
> > > Here is the first (and pretty late) drm-misc-next PR.
> > >
> > > It's pretty big due to
On Tue, Aug 6, 2019 at 11:40 AM Emil Velikov wrote:
> On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
> >
> > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
> > >
> > > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard
> > > wrote:
> > > >
> > > > Hi Daniel, Dave,
> > > >
> > > > Here is the fir
== Series Details ==
Series: series starting with drm/i915: Defer final intel_wakeref_put to process
context (rev2)
URL : https://patchwork.freedesktop.org/series/64730/
State : failure
== Summary ==
Applying: drm/i915: Defer final intel_wakeref_put to process context
Applying: drm/i915/pmu:
On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
>
> On Tue, Aug 6, 2019 at 11:40 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
> > >
> > > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
> > > >
> > > > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard
> > > > wrot
On Tue, Aug 6, 2019 at 11:49 AM Daniel Vetter wrote:
>
> On Tue, Aug 6, 2019 at 11:40 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
> > >
> > > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
> > > >
> > > > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard
> > > > w
On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote:
>
> On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
> >
> > On Tue, Aug 6, 2019 at 11:40 AM Emil Velikov
> > wrote:
> > > On Tue, 6 Aug 2019 at 08:34, Daniel Vetter wrote:
> > > >
> > > > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote:
>
Avoid including the i915_drv.h mega header from other header files to
make further header cleanup easier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++
drivers/gpu/drm/i915/display/intel_sprite.h | 8 +---
2 files changed, 7 insertions(+), 7 deletions
Everything about the file is about display, and mostly about types
related to display. Move under display/ as intel_display_types.h to
reflect the facts.
There's still plenty to clean up, but start off with moving the file
where it logically belongs and naming according to contents.
Signed-off-by
Disentangle i915_drv.h from intel_drv.h, which gets included via
i915_trace.h. This necessitates including i915_trace.h wherever it's
needed.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c| 1 +
drivers
The big theme here is to emphasize that intel_drv.h is a display header, so
rename it display/intel_display_types.h and reduce its use in non-display
code. Also reduce the inclusion of that and the other mega header i915_drv.h
from other headers.
BR,
Jani.
Jani Nikula (10):
drm/i915: move inte
Avoid including the intel_drv.h mega header from other header files to
make further header cleanup easier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_tc.c | 7 +++
drivers/gpu/drm/i915/display/intel_tc.h | 10 ++
2 files changed, 9 insertions(+), 8 deletions(-
Avoid including the intel_drv.h mega header from other header files to
make further header cleanup easier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp_mst.h | 9 ++---
2 files changed, 8 insertions(+), 7 deletio
With its original name intel_drv.h the intel_display_types.h header was
superfluously cargo-cult included all over the place, while it's really
mostly about display internals. Remove the unnecessary includes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 +--
No need for this function to be accessible outside of intel_bw.c. Avoid
including the i915_drv.h mega header from other header files to make
further header cleanup easier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bw.c | 14 ++
drivers/gpu/drm/i915/display/int
Avoid including the i915_drv.h mega header from other header files to
make further header cleanup easier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 19 +++
drivers/gpu/drm/i915/i915_irq.h | 30 ++
2 files changed, 29 insertions(+
Move the declarations of functions in intel_display.c to
intel_display.h. There is still plenty of cleanup to do in
intel_display.[ch], but one step at a time.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.h | 171 +++
drivers/gpu/drm/i915/i915_drv.h
Move the property enums closer to home. Acually make the broadcast
macros an enum while at it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_types.h | 14 ++
drivers/gpu/drm/i915/i915_drv.h| 12
2 files changed, 14 insertio
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/tgl: add GEN12_MAX_CONTEXT_HW_ID
URL : https://patchwork.freedesktop.org/series/64738/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6633_full -> Patchwork_13878_full
==
Hi,
On Tue, 6 Aug 2019 at 10:58, Daniel Vetter wrote:
> On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
> > > The thing is, dim push shouldn't allow you to do that. And the patches
> > > have clearly been applied with dim apply (or at le
As every i915_active_request should be serialised by a dedicated lock,
i915_active consists of a tree of locks; one for each node. Markup up
the i915_active_request with what lock is supposed to be guarding it so
that we can verify that the serialised updated are indeed serialised.
Signed-off-by:
Convert the list manipulation of active to use spinlocks so that we can
perform the updates from underneath a quick interrupt callback.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c| 10 --
drivers/gpu/drm/i915
On Tue, 6 Aug 2019 at 11:14, Daniel Stone wrote:
> The idea I had a few weeks ago was to have dim use 'git push
> --push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually',
> then have the hooks on the server side check for that option and
> refuse any direct pushes. (Or at least
Quoting Jani Nikula (2019-08-06 11:07:21)
> The big theme here is to emphasize that intel_drv.h is a display header, so
> rename it display/intel_display_types.h and reduce its use in non-display
> code. Also reduce the inclusion of that and the other mega header i915_drv.h
> from other headers.
>
Chris Wilson writes:
> We do not notify userspace when the scheduler capabilities are changed
> (due to wedging the driver) and as such userspace will expect the caps
> to be static and unchanging. Make it so, and so we only need to compute
> our caps once during driver registration.
>
> Signed-o
On Tue, 06 Aug 2019, Emil Velikov wrote:
> On Tue, 6 Aug 2019 at 11:14, Daniel Stone wrote:
>
>> The idea I had a few weeks ago was to have dim use 'git push
>> --push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually',
>> then have the hooks on the server side check for that opt
Quoting Mika Kuoppala (2019-08-06 11:40:48)
> Chris Wilson writes:
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 8ac7d14ec8c9..81094f250bdb 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
== Series Details ==
Series: drm/i915: some more header juggling
URL : https://patchwork.freedesktop.org/series/64764/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a6b92421ae00 drm/i915: move intel_display.c function declarations
5a0cc84ae9c6 drm/i915/sprite: un-inline icl_is_
== Series Details ==
Series: drm/i915: some more header juggling
URL : https://patchwork.freedesktop.org/series/64764/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: move intel_display.c function declarations
Okay!
Commit: drm/i915/sprite: u
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static
URL : https://patchwork.freedesktop.org/series/64761/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ff8a2db2ee62 drm/i915/gem: Make caps.scheduler static
e2d0d5983bf0 drm/i915/gt:
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static
URL : https://patchwork.freedesktop.org/series/64761/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gem: Make caps.scheduler static
Okay!
Comm
Avoid including the intel_drv.h mega header from other header files to
make further header cleanup easier.
v2: restore the over-eagerly dropped (Imre)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_tc.c | 7 +++
drivers/gpu/drm/i915/display/intel_tc.h | 9 ++---
2 fi
== Series Details ==
Series: drm/i915: some more header juggling
URL : https://patchwork.freedesktop.org/series/64764/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13883
Summary
---
**SUCCESS**
Everything about the file is about display, and mostly about types
related to display. Move under display/ as intel_display_types.h to
reflect the facts.
There's still plenty to clean up, but start off with moving the file
where it logically belongs and naming according to contents.
v2: fix the i
== Series Details ==
Series: drm/i915/dmc: Load DMC on TGL (rev2)
URL : https://patchwork.freedesktop.org/series/64628/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6634_full -> Patchwork_13879_full
Summary
---
**SU
== Series Details ==
Series: drm/i915: some more header juggling (rev3)
URL : https://patchwork.freedesktop.org/series/64764/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
38e320bf9576 drm/i915: move intel_display.c function declarations
e336fea484dd drm/i915/sprite: un-inline
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static
URL : https://patchwork.freedesktop.org/series/64761/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13884
== Series Details ==
Series: drm/i915: some more header juggling (rev3)
URL : https://patchwork.freedesktop.org/series/64764/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: move intel_display.c function declarations
Okay!
Commit: drm/i915/sp
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-08-06 11:40:48)
>> Chris Wilson writes:
>> > diff --git a/drivers/gpu/drm/i915/i915_request.c
>> > b/drivers/gpu/drm/i915/i915_request.c
>> > index 8ac7d14ec8c9..81094f250bdb 100644
>> > --- a/drivers/gpu/drm/i915/i915_request.c
>> > +++ b/driv
On Thu, 18 Jul 2019, Rodrigo Vivi wrote:
> On Thu, Jul 18, 2019 at 10:25:51PM +0100, Chris Wilson wrote:
>> Quoting Rodrigo Vivi (2019-07-18 22:14:45)
>> > On Thu, Jul 18, 2019 at 09:58:16PM +0100, Chris Wilson wrote:
>> > > Quoting Rodrigo Vivi (2019-07-18 21:49:12)
>> > > > +void intel_display_p
== Series Details ==
Series: drm/i915: some more header juggling (rev3)
URL : https://patchwork.freedesktop.org/series/64764/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13885
Summary
---
**SUCCES
From: Rodrigo Vivi
Increase abstraction of display suspend/resume operations by providing
higher level functions, and hiding the details inside
intel_display_power.c.
v2: Make checkpatch happy:
- braces {} are not necessary for single statement blocks
v3: Also move hsw/bdw PC8 sequences sinc
Rodrigo's original patch was at v5 [1], and still stuck in discussion
around the *functional* change, while 99% of the patch is
*non-functional* refactoring that does not seem to be contentious.
Let's do the sane thing and merge the refactoring first, shall we?
BR,
Jani.
[1]
http://patchwork.
The issue can be reproduced by interrupting "default-bomb" subtest of
"gem_ringfill" IGT, at least on simulation environment which is slow.
Janusz Krzysztofik (2):
drm/i915: Fix NULL pointer dereference in execlists' trace_ports()
drm/i915: Fix panic if nothing to promote after preempt on rese
Execlists state machine always falls through from PREEMPT to PROMOTE,
expecting pending to be valid. Apparently it not always happens to be
the case, at least during reset. Assuming this unexpected behavior
depends on hardware, fix the issue by introducing a conditional break.
Signed-off-by: Jan
If it ever happens trace_port() helper is called with NULL port 0,
kernel panic occurs. Fix it.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gp
Quoting Janusz Krzysztofik (2019-08-06 13:24:58)
> Execlists state machine always falls through from PREEMPT to PROMOTE,
> expecting pending to be valid. Apparently it not always happens to be
> the case, at least during reset. Assuming this unexpected behavior
> depends on hardware, fix the issu
Sanity test existing persistence and new exciting non-persistent context
behaviour.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michał Winiarski
Cc: Jon Bloomfield
---
lib/i915/gem_context.c | 37 +
lib/i915/gem_context.h | 9 ++
lib/ioctl_wrappers.c
To maintain a fast lookup from a GT centric irq handler, we want the
engine lookup tables on the intel_gt. To avoid having multiple copies of
the same multi-dimension lookup table, move the generic user engine
lookup into an rbtree (for fast and flexible indexing).
v2: Split uabi_instance cf uabi_
We do not notify userspace when the scheduler capabilities are changed
(due to wedging the driver) and as such userspace will expect the caps
to be static and unchanging. Make it so, and so we only need to compute
our caps once during driver registration.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ur
Added edid checking to dp and hdmi edid setting functions, which
are called from detect hooks. The result currently is propagated
to calling layer using drm_connector->change_counter(proposed by Daniel Vetter).
drm_helper_hpd_irq_event and intel_encoder_hotplug are currently both
responsible for ch
This series introduce to drm a way to determine if something else
except connection_status had changed during probing, which
can be used by other drivers as well. Another i915 specific part
uses this approach to determine if edid had changed without
changing the connection status and send a hotplug
Many drivers would benefit from using
drm helper to compare edid, rather
than bothering with own implementation.
v2: Added documentation for this function.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_edid.c | 33 +
include/drm/drm_edid.h | 9 +
This counter will be used by drm_helper_probe_detect caller to determine
if something else had changed except connection status,
like for example edid. Hardware specific drivers are responsible
for updating this counter when some change is detected to notify
the drm part, which can trigger for exam
On Mon, Aug 05, 2019 at 09:29:53PM +0200, Sedat Dilek wrote:
> On Wed, Jul 31, 2019 at 2:25 PM Sedat Dilek wrote:
> >
> > On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Thomas Gleixner (2019-07-26 20:18:32)
> > > > On Fri, 26 Jul 2019, Chris Wilson wrote:
> > > > > Q
== Series Details ==
Series: drm/i915: abstract display suspend/resume operations
URL : https://patchwork.freedesktop.org/series/64768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13886
Summary
---
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static
URL : https://patchwork.freedesktop.org/series/64771/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
01c5e3f89120 drm/i915/gem: Make caps.scheduler static
be2fa0bc0665 drm/i915/gt
== Series Details ==
Series: drm/i915: Fix panic if nothing to promote after preempt on reset
URL : https://patchwork.freedesktop.org/series/64769/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13887
Summa
On completion of a banned context, scrub the context image so that we do
not replay the active payload. The intent is that we skip banned
payloads on request submission so that the timeline advancement
continues on in the background. However, if we are returning to a
preempted request, i915_request
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use endless batches and will disable
the hangchec
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
If we are asked to submit a completed request, just move it onto the
active-list without modifying it's payload.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reques
Sometimes we want to emit a terminator request, a request that flushes
the pipeline and allows no request to come after it. This can be used
for a "preempt-to-idle" to ensure that upon processing the
context-switch to that request, all other active contexts have been
flushed.
Signed-off-by: Chris
On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy wrote:
> This series introduce to drm a way to determine if something else
> except connection_status had changed during probing, which
> can be used by other drivers as well. Another i915 specific part
> uses this approach to determine
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static
URL : https://patchwork.freedesktop.org/series/64771/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13888
1 - 100 of 156 matches
Mail list logo
