== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a
context WA on ring submission
URL : https://patchwork.freedesktop.org/series/74363/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dp
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Deactive FBC in
fastsets when disabled by parameter (rev2)
URL : https://patchwork.freedesktop.org/series/73618/
State : failure
== Summary ==
Applying: drm/i915/display: Deactive FBC in fastsets when disabled by par
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a
context WA on ring submission
URL : https://patchwork.freedesktop.org/series/74363/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16853
===
== Series Details ==
Series: series starting with [v4,1/2] drm/edid: Name the detailed monitor range
flags
URL : https://patchwork.freedesktop.org/series/74364/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warn
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Only load the CGM CSC based on the cgm_mode bit like we
do with the gamma/degamma LUTs. And make the function
naming and arguments consistent as well.
TODO: the code to convert the coefficients look totally
bogus. IIRC CHV uses
== Series Details ==
Series: series starting with [v4,1/2] drm/edid: Name the detailed monitor range
flags
URL : https://patchwork.freedesktop.org/series/74364/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16855
=
Quoting Patchwork (2020-03-06 04:28:26)
> == Series Details ==
>
> Series: drm/i915: properly sanity check batch_start_offset (rev2)
> URL : https://patchwork.freedesktop.org/series/74287/
> State : success
Apologies, SPF vs intel.com again.
So, I think the _end variant should be for the inclu
== Series Details ==
Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable
to dev
URL : https://patchwork.freedesktop.org/series/74298/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16831_full
==
Chris Wilson writes:
> Check the flow of requests into the hardware to verify that are
> submitted in order along their timeline.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4
> drivers/gpu/drm/i915/i915_request.c | 4
>
On Thu, 05 Mar 2020, Rajat Jain wrote:
> On Thu, Mar 5, 2020 at 1:41 AM Jani Nikula
> wrote:
>>
>> On Wed, 04 Mar 2020, Rajat Jain wrote:
>> 1) See if we can postpone creating and attaching properties to connector
>> ->late_register hook. (I didn't have the time to look into it yet, at
>> all.)
Chris Wilson writes:
> We only need to serialise the multiple pinning during the eb_reserve
> phase. Ideally this would be using the vm->mutex as an outer lock, or
> using a composite global mutex (ww_mutex), but at the moment we are
> using struct_mutex for the group.
>
> Fixes: 003d8b9143a6 ("d
Check the edge case where batch_start_offset sits exactly on the batch
size.
v2: add new range_overflows variant to capture the special case where
the size is permitted to be zero, like with batch_len.
v3: other way around. the common case is the exclusive one which should
just be >=, with that w
Quoting Patchwork (2020-03-06 06:09:52)
> == Series Details ==
>
> Series: drm/i915/phys: unconditionally call release_memory_region
> URL : https://patchwork.freedesktop.org/series/74354/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16849
> ==
A little bit of history :
Back when i915-perf was introduced (4.13), there was no way to
dynamically add new OA configurations to i915. Only the generated
configs baked in at build time were allowed.
It quickly became obvious that we would need to allow applications
to upload their
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As
The caller of i915_oa_init_reg_state() already sets this.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0069f09b988c..86c6abaa3e0e 100644
--
Quoting Patchwork (2020-03-06 05:40:31)
> == Series Details ==
>
> Series: drm/i915: be more solid in checking the alignment
> URL : https://patchwork.freedesktop.org/series/74353/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16848
> ==
Chris Wilson writes:
> We only call i915_schedule() when we know we have changed the priority
> on a request and so require to propagate any change in priority to its
> signalers (for PI). By unconditionally checking all of our signalers, we
> avoid skipping changes made prior to construction of
== Series Details ==
Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable
to dev
URL : https://patchwork.freedesktop.org/series/74299/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16832_full
==
On Thu, 05 Mar 2020, Rajat Jain wrote:
> OK, will do. In order to do that I may need to introduce driver level
> hooks that i915 driver can populate and drm core can call (or may be
> some functions to add privacy screen property that drm core exports
> and i915 driver will call).
The latter. Loo
On Thu, 05 Mar 2020, Manasi Navare wrote:
> This patch adds defines for the detailed monitor
> range flags as per the EDID specification.
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Kazlauskas Nicholas
> Signed-off-by: Manasi Navare
>
== Series Details ==
Series: series starting with [1/3] drm/i915: Assert requests within a context
are submitted in order
URL : https://patchwork.freedesktop.org/series/74369/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_
On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > renamed include/linux/reservation.h to include/linux/dma-resv.h, but
> > missed the reference in the MAINTAIN
== Series Details ==
Series: series starting with [1/3] drm/i915: Assert requests within a context
are submitted in order
URL : https://patchwork.freedesktop.org/series/74369/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8076 -> Patchwork_16856
==
== Series Details ==
Series: drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
URL : https://patchwork.freedesktop.org/series/74304/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16833_full
===
Hi Daniele,
> > > > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > index 75255aaacaed..9112a8585caf 100644
> > > > --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > @@ -26,15 +26,14 @@ vo
On Fri, 2020-03-06 at 11:39 +0100, Daniel Vetter wrote:
> On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> > Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > > renamed include/linux/reservation.h to includ
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting
Skip useless priority bumping on adding a new dependency, but otherwise
prevent tasklet scheduling until we have completed all the potential
rescheduling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
If we stop filling the ELSP due to an incompatible virtual engine
request, check if we should enable the timeslice on behalf of the queue.
This fixes the case where we are inspecting the last->next element when
we know that the last element is the last request in the execution queue,
and so decide
== Series Details ==
Series: drm/i915: Improve the start alignment of bonded pairs
URL : https://patchwork.freedesktop.org/series/74315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16835_full
Summar
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
Karthik B S (7):
drm/i915: Define flip done functions an
Support added only for async flips on primary plane.
If flip is requested on any other plane, reject it.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_displa
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt.
If the flip done event is requested then send it in the flip done handler,
and then disable the interrupt.
Signed-off-by: Karthik B S
---
drivers/gpu/d
Add enable/disable flip done functions and enable
the flip done interrupt in IER.
Flip done interrupt is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/i915_irq.c | 37
Enable support for async flips in I915.
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 4
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 5 insertions(+)
d
Make the commit call blocking in case of async flips
so that there is no delay in completing the flip.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/int
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_sprite.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/dr
Send the flip done event in the handler and disable the interrupt.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5955e737a45d..1feda9ae
On Fri, Mar 06, 2020 at 02:14:15PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Only load the CGM CSC based on the cgm_mode bit like we
> > do with the gamma/degamma LUTs. And make the function
> > naming and arguments consistent
== Series Details ==
Series: drm/i915: Actually emit the await_start
URL : https://patchwork.freedesktop.org/series/74319/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16836_full
Summary
---
*
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/i915_request.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..2a6052d609d9 100644
--- a
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
== Series Details ==
Series: drm/i915: properly sanity check batch_start_offset (rev3)
URL : https://patchwork.freedesktop.org/series/74287/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function
parame
== Series Details ==
Series: drm/i915: properly sanity check batch_start_offset (rev3)
URL : https://patchwork.freedesktop.org/series/74287/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8080 -> Patchwork_16857
Summary
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilso
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
Due to the ordering of cmpxchg()/dma_fence_signal() inside node_retire(),
we must also use the xchg() as our primary memory barrier to flush the
outstanding callbacks after expected completion of the i915_active.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_active.c | 29 +
Extend i915_request_await_active() to be able to asynchronously wait on
all the tracked timelines simultaneously.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 51 +++---
drivers/gpu/drm/i915/i915_active.h | 5 ++-
drivers/gpu/drm/i915/i915_vma.c
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
Reviewed-by:
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 ins
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct cont
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 53 +
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+)
Skip useless priority bumping on adding a new dependency, but otherwise
prevent tasklet scheduling until we have completed all the potential
rescheduling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/sel
If we stop filling the ELSP due to an incompatible virtual engine
request, check if we should enable the timeslice on behalf of the queue.
This fixes the case where we are inspecting the last->next element when
we know that the last element is the last request in the execution queue,
and so decide
On Thu, Mar 05, 2020 at 05:34:27PM +0530, Pankaj Bharadiya wrote:
> This series addresses below drm_fb_helper tasks from
> Documentation/gpu/todo.rst.
>
> - The max connector argument for drm_fb_helper_init() isn't used
> anymore and can be removed.
>
> - The helper doesn't keep an array of con
== Series Details ==
Series: drm: drm_fb_helper cleanup. (rev3)
URL : https://patchwork.freedesktop.org/series/74140/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16838_full
Summary
---
**SUCC
Do not poison the timeline link on the i915_request to allow both
forward/backward list traversal under RCU.
[ 9759.139229] RIP: 0010:active_request+0x2a/0x90 [i915]
[ 9759.139240] Code: 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 c5 60 e8
49 de dc e0 48 8b 83 e8 01 00 00 48 39 c5 74 12 48 8d
Chris Wilson writes:
> If we stop filling the ELSP due to an incompatible virtual engine
> request, check if we should enable the timeslice on behalf of the queue.
>
> This fixes the case where we are inspecting the last->next element when
> we know that the last element is the last request in th
On 06/03/2020 15:38, Chris Wilson wrote:
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed
On Fri, Mar 06, 2020 at 12:22:09AM +, Souza, Jose wrote:
> On Wed, 2020-02-19 at 20:52 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 19, 2020 at 06:37:27PM +, Souza, Jose wrote:
> > > On Wed, 2020-02-19 at 15:37 +0200, Ville Syrjälä wrote:
> > > > On Tue, Feb 18, 2020 at 05:42:28PM -0800, Jos
Chris Wilson writes:
> Due to the ordering of cmpxchg()/dma_fence_signal() inside node_retire(),
> we must also use the xchg() as our primary memory barrier to flush the
> outstanding callbacks after expected completion of the i915_active.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuopp
From: Tvrtko Ursulin
VCS is a special (non-physical) engine id/name which means load-balancing
in legacy workloads. As such when i915 balancing is not enabled it needs
to have a calibration as well.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 2 ++
1 file changed, 2 insertions(+)
From: Tvrtko Ursulin
We want to mark workload contexts as non-persistent if possible so that we
do not have to worry about leaving long (or infinite!) batches running
post exit.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 50 ---
1 file cha
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
+static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_b
Chris Wilson writes:
> For conveniences of callers that just want to use an i915_active to
> track a wide array of concurrent timelines, wrap the base i915_active
> struct inside a kref. This i915_active will self-destruct after use.
>
Found the user,
Reviewed-by: Mika Kuoppala
> Signed-off-by
On Fri, Mar 06, 2020 at 08:12:22PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > +static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_priva
== Series Details ==
Series: drm/i915: Return early for await_start on same timeline
URL : https://patchwork.freedesktop.org/series/74338/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16839_full
Summ
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
--
On 2020-03-05 8:42 p.m., Manasi Navare wrote:
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stri
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We're talking about LUT contents here so let's call the thing
'lut' rather than 'blob_data'. This is the name the load_lut()
code used before already.
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
drivers/gpu
Chris Wilson writes:
> Do not poison the timeline link on the i915_request to allow both
> forward/backward list traversal under RCU.
>
> [ 9759.139229] RIP: 0010:active_request+0x2a/0x90 [i915]
> [ 9759.139240] Code: 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 c5 60 e8
> 49 de dc e0 48 8b 8
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().
At present, since all the readouts are only gamma luts so should w
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which gene
== Series Details ==
Series: drm/i915: HDCP: fix Ri prime and R0 checks during auth (rev2)
URL : https://patchwork.freedesktop.org/series/74271/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16840_full
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.
Wow!
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
On Fri, Mar 06, 2020 at 08:48:42PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
> > let's rename it to reflect that fact. This also mirrors
> > the other direction's ch
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.
Signed-off-by: Vi
1 - 100 of 183 matches
Mail list logo
