From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach b
This cover letter is included to trigger "Test-with" an IGT patch.
Signed-off-by: Umesh Nerlige Ramappa
Test-with: 20200714071334.69883-1-umesh.nerlige.rama...@intel.com
Piotr Maciejewski (1):
drm/i915/perf: Map OA buffer to user space
drivers/gpu/drm/i915/gt/intel_workarounds.c | 54 ++
On Tue, Jul 14, 2020 at 12:22:39AM -0700, Umesh Nerlige Ramappa wrote:
From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current
== Series Details ==
Series: Allow privileged user to map the OA buffer
URL : https://patchwork.freedesktop.org/series/79460/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
69208bf02940 drm/i915/perf: Map OA buffer to user space
-:214: ERROR:SPACING: space required before the op
On Fri, Jul 10, 2020 at 02:16:50PM +0300, Jyri Sarha wrote:
> Thank you Daniel,
> Now this works perfectly, all while I was on vacation.
>
> On 08/07/2020 17:20, Daniel Vetter wrote:
> > Gives us proper nonblocking support for free, and a pile of other
> > things. The tilcdc code is simply old eno
On Wed, Jul 08, 2020 at 01:17:39PM +0800, james qian wang (Arm Technology
China) wrote:
> On Tue, Jul 07, 2020 at 10:12:11PM +0200, Daniel Vetter wrote:
> > Like the helpers, nothing special. Well except not, because we the
> > critical section extends until after hw_done(), since that's the last
On Wed, Jul 08, 2020 at 02:32:40AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote:
> > Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> > nothing fancy going on here.
>
> Just looking at
== Series Details ==
Series: Allow privileged user to map the OA buffer
URL : https://patchwork.freedesktop.org/series/79460/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8741 -> Patchwork_18154
Summary
---
**FAILUR
On 06/07/2020 07:19, Chris Wilson wrote:
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronou
On Thu, Jul 09, 2020 at 04:05:31PM +0200, Sam Ravnborg wrote:
> On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
> >
> > This avoids me having to roll out dma-fence critical section
> > annotations to this copy.
> >
> > Signed-off-by: Dani
Since the breadcrumb enabling/cancelling itself is serialised by the
breadcrumbs.irq_lock, with a bit of care we can remove the outer
serialisation with i915_request.lock for concurrent
dma_fence_enable_signaling(). This has the important side-effect of
eliminating the nested i915_request.lock with
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the irq-spinlock.
Fixes: 1d9221e9d395 ("drm/i915: S
Hi Daniel.
On Tue, Jul 07, 2020 at 11:31:37PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
>
> Could al
On 07/12, Rodrigo Siqueira wrote:
> Hi,
>
> Everything looks fine to me, I just noticed that the amdgpu patches did
> not apply smoothly, however it was trivial to fix the issues.
>
> Reviewed-by: Rodrigo Siqueira
>
> Melissa,
> Since you are using vkms regularly, could you test this patch and
On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen wrote:
>
> On 07/12, Rodrigo Siqueira wrote:
> > Hi,
> >
> > Everything looks fine to me, I just noticed that the amdgpu patches did
> > not apply smoothly, however it was trivial to fix the issues.
> >
> > Reviewed-by: Rodrigo Siqueira
> >
> > Melissa
On Mon, Jul 13, 2020 at 09:51:30PM +, Patchwork wrote:
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag
URL : https://patchwork.freedesktop.org/series/79420/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8739_full -> Patch
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove i915_request.lock
requirement for execution callbacks
URL : https://patchwork.freedesktop.org/series/79467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8742 -> Patchwork_18155
=
On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
> My dma-fence lockdep annotations caught an inversion because we
> allocate memory where we really shouldn't:
>
> kmem_cache_alloc+0x2b/0x6d0
> amdgpu_fence_emit+0x30/0x330 [amdgpu]
> amdgpu_ib_schedule+0x306/0x550 [
On Mon, Jul 13, 2020 at 03:51:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 856d98c36f56..a2397f724c10 100644
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> > > @@ -11595,7 +11595,7 @@ SYSCALL_DEFINE5(per
On Wed, Jul 08, 2020 at 05:37:19PM +0200, Daniel Vetter wrote:
> On Wed, Jul 8, 2020 at 5:19 PM Alex Deucher wrote:
> >
> > On Wed, Jul 8, 2020 at 11:13 AM Daniel Vetter
> > wrote:
> > >
> > > On Wed, Jul 8, 2020 at 4:57 PM Christian König
> > > wrote:
> > > >
> > > > Could we merge this contr
On Tue, Jul 07, 2020 at 10:12:24PM +0200, Daniel Vetter wrote:
> Not going to bother with a complete&pretty commit message, just
> offending backtrace:
>
> kvmalloc_node+0x47/0x80
> dc_create_state+0x1f/0x60 [amdgpu]
> dc_commit_state+0xcb/0x9b0 [amdgpu]
> amdgpu_dm
Quoting Umesh Nerlige Ramappa (2020-07-14 08:22:39)
> From: Piotr Maciejewski
>
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
== Series Details ==
Series: series starting with [1/2] drm/i915: Remove i915_request.lock
requirement for execution callbacks
URL : https://patchwork.freedesktop.org/series/79467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8742_full -> Patchwork_18155_full
===
Am 14.07.20 um 12:49 schrieb Daniel Vetter:
On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
We need to ensure that the kernel context is using the permanently pinned
HWSP so that we can always submit a pm request from any context. By
construction, the engine->kernel_context should only be using the
engine->status_page.vma so let's assert that is still true when we have
to submit a request
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_
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b23368529a40..548ed9fb427d 100644
This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches
for a single execbuf").
This breaks ww mutex -EDEADLK handling, and we can deal with relocations
fine without it. The ww mutexes protect concur
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
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/ge
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
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
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
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
---
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
[mlankhorst: Adjusted for reloc_gpu_flush() changes]
Cc: Chris Wilson
Cc: Matthew
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(+),
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 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
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
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
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
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
This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
Breaks the execbuf ww locking series.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 314 --
.../i915/gem/se
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/
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
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
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
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
On 06/07/2020 07:19, Chris Wilson wrote:
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the
From: Tvrtko Ursulin
Use MI_MATH and MI_COND_BBE we can construct a loop that runs for a
precise number of clock cycles, as measured by the CTX_TIMESTAMP. We use
the CTX_TIMESTAMP (as opposed to the CS_TIMESTAMP) so that the elapsed
time is measured local to the context, and the length of the bat
== Series Details ==
Series: drm/i915/gt: Assert the kernel context is using the HWSP
URL : https://patchwork.freedesktop.org/series/79469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18156
Summary
-
On 06/07/2020 07:19, Chris Wilson wrote:
Pull the cmdparser allocations in to the reservation phase, and then
they are included in the common vma pinning pass.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 348 ++
drivers/gpu/drm/i915/gem/i
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only"
URL : https://patchwork.freedesktop.org/series/79470/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
78aced2defcc Revert "drm/i915/gem: Async GPU relocations only"
-:113:
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only"
URL : https://patchwork.freedesktop.org/series/79470/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checke
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only"
URL : https://patchwork.freedesktop.org/series/79470/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18157
Track the position of the HWSP for each timeline.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_timeline.c| 7 +++
drivers/gpu/drm/i915/gt/selftest_timeline.c | 13 -
2 file
Quoting Tvrtko Ursulin (2020-07-13 13:22:19)
>
> On 09/07/2020 13:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-07-09 12:59:51)
> >>
> >> On 09/07/2020 12:07, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-07-09 12:01:29)
>
> On 08/07/2020 16:36, Chris Wilson wrote:
>
Quoting Tvrtko Ursulin (2020-07-13 15:53:56)
>
> On 06/07/2020 07:19, Chris Wilson wrote:
> Just a temporary stage... are we reviewing those? Best if they can be
> avoided.
Yes, I am not chuffed in having it. But with the transition from using
an array of execobj[] to having a list that includes
The error code is not set on this error path. It's either zero or
uninitialized at this point.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
1 file changed, 1 insertion(+
On 14/07/2020 17:12, Dan Carpenter wrote:
The error code is not set on this error path. It's either zero or
uninitialized at this point.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/selftests/i91
== Series Details ==
Series: drm/i915/gt: Trace placement of timeline HWSP
URL : https://patchwork.freedesktop.org/series/79477/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18158
Summary
---
**SUC
On Tue, Jul 14, 2020 at 01:40:11PM +0200, Christian König wrote:
> Am 14.07.20 um 12:49 schrieb Daniel Vetter:
> > On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
> > > My dma-fence lockdep annotations caught an inversion because we
> > > allocate memory where we really shouldn't:
>
On Tue, Jul 14, 2020 at 05:16:33PM +0300, Lionel Landwerlin wrote:
> On 14/07/2020 17:12, Dan Carpenter wrote:
> > The error code is not set on this error path. It's either zero or
> > uninitialized at this point.
> >
> > Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
On 13/07/2020 06:09, Dave Airlie wrote:
On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
We need to add support for pwrite'ing an LMEM object.
why? DG1 is a discrete GPU, these interfaces we already gross and
overly hacky for integrated, I'd prefer not to drag them across into
discrete land
The error code needs to be set on this path. It currently returns
success.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Reported-by: Lionel Landwerlin
Signed-off-by: Dan Carpenter
---
v2: Fix a different bug instead. :P Colin fixed mine already.
dr
On 14/07/2020 17:36, Dan Carpenter wrote:
The error code needs to be set on this path. It currently returns
success.
Fixes: ed2690a9ca89 ("drm/i915/selftest: Check that GPR are restored across
noa_wait")
Reported-by: Lionel Landwerlin
Signed-off-by: Dan Carpenter
---
v2: Fix a different bug
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/ge
== Series Details ==
Series: drm/i915/selftest: Fix an error code in live_noa_gpr()
URL : https://patchwork.freedesktop.org/series/79478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18159
Summary
---
Hi,
On 07/14, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen wrote:
> >
> > On 07/12, Rodrigo Siqueira wrote:
> > > Hi,
> > >
> > > Everything looks fine to me, I just noticed that the amdgpu patches did
> > > not apply smoothly, however it was trivial to fix the issues.
> >
On Thu, Jul 9, 2020 at 8:48 AM Hans de Goede wrote:
>
> Hi,
>
> On 7/8/20 11:25 PM, Alex Deucher wrote:
> > On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
> >>
> >> Hi All,
> >>
> >> Here is the privacy-screen related code which we discussed a while ago.
> >> This series consists of a numbe
On 13/07/2020 05:48, Dave Airlie wrote:
On Fri, 10 Jul 2020 at 22:01, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
The memory region is marked with "is_devmem=true".
== Series Details ==
Series: drm/i915/gt: Assert the kernel context is using the HWSP
URL : https://patchwork.freedesktop.org/series/79469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744_full -> Patchwork_18156_full
Sum
Quoting Tvrtko Ursulin (2020-07-14 10:02:35)
>
> On 06/07/2020 07:19, Chris Wilson wrote:
> > It is reasonably common for userspace (even modern drivers like iris) to
> > reuse an active address for a new buffer. This would cause the
> > application to stall under its mutex (originally struct_mute
to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Karthik-B-S/Asynchronous-flip-implementation-for-i915/20200714-095304
base: git
== Series Details ==
Series: drm/i915/selftest: Fix an error code in live_noa_gpr() (rev2)
URL : https://patchwork.freedesktop.org/series/79478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18160
Summary
Quoting Tvrtko Ursulin (2020-07-14 13:19:22)
>
> On 06/07/2020 07:19, Chris Wilson wrote:
> > It is illegal to wait on an another vma while holding the vm->mutex, as
> > that easily leads to ABBA deadlocks (we wait on a second vma that waits
> > on us to release the vm->mutex). So while the vm->mu
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only" (rev2)
URL : https://patchwork.freedesktop.org/series/79470/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6a326d9f8985 Revert "drm/i915/gem: Async GPU relocations only"
On Tue, Jul 14, 2020 at 4:56 PM Melissa Wen wrote:
>
> Hi,
>
> On 07/14, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen wrote:
> > >
> > > On 07/12, Rodrigo Siqueira wrote:
> > > > Hi,
> > > >
> > > > Everything looks fine to me, I just noticed that the amdgpu patches did
>
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only" (rev2)
URL : https://patchwork.freedesktop.org/series/79470/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
From: Ville Syrjälä
Some spaces have snuck in where we want tabs. Fix it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/i
From: Ville Syrjälä
There's a pointless hole in struct intel_cdclk_vals, get rid of it.
Fortunately we already use named initializers so the order does not
matter.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrjälä
Since we now have proper old and new cdclk state we no longer
need to keep this flag to indicate that the force min cdclk has
changed. Instead just check if the old vs. new value are different.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_audio.c |
From: Ville Syrjälä
Explicitly check for i830 when assigning the .get_cdclk() vfunc,
and then deal with the case of not having assigned the vfunc
separately. Less confusing, and gets rid of the checkpatch complaint
about using {} on one branch but not the others.
Signed-off-by: Ville Syrjälä
--
According to BSpec this flag should not be changed while the DDI
function is enabled. On BDW+ the DP_TP_CTL register spec also states it
explicitly that the HW takes care of enabling/disabling the scrambling
for training patterns (and it must stay enabled for normal pixel
output). Assume that this
The driver enables the DDI function in the DDI_BUF_CTL register before
starting the link training and disables it when disabling the output. It
also gets disabled/re-enabled during link re-trainining.
Except of the above the value we program to the register (intel_dp->DP)
doesn't change, so no nee
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only" (rev2)
URL : https://patchwork.freedesktop.org/series/79470/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18161
=
On Tue, Jul 14, 2020 at 06:31:40PM +0300, Imre Deak wrote:
> According to BSpec this flag should not be changed while the DDI
> function is enabled. On BDW+ the DP_TP_CTL register spec also states it
> explicitly that the HW takes care of enabling/disabling the scrambling
> for training patterns (a
From: Sean Paul
Instead of doing a full modeset to enable/disable content protection,
simply go through the update_pipe flow which was introduced in the
related patch below. This avoids flashing the screen every time the user
starts viewing protected content.
Related: 634852d1f468 ("drm/i915: HD
== Series Details ==
Series: series starting with [1/4] drm/i915: Pack struct intel_cdclk_vals
URL : https://patchwork.freedesktop.org/series/79480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18162
Summ
On Tue, Jul 14, 2020 at 06:31:41PM +0300, Imre Deak wrote:
> The driver enables the DDI function in the DDI_BUF_CTL register before
> starting the link training and disables it when disabling the output. It
> also gets disabled/re-enabled during link re-trainining.
>
> Except of the above the valu
== Series Details ==
Series: drm/i915/gt: Trace placement of timeline HWSP
URL : https://patchwork.freedesktop.org/series/79477/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744_full -> Patchwork_18158_full
Summary
--
On Tue, Jul 14, 2020 at 07:08:33PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 14, 2020 at 06:31:41PM +0300, Imre Deak wrote:
> > The driver enables the DDI function in the DDI_BUF_CTL register before
> > starting the link training and disables it when disabling the output. It
> > also gets disabled/
Apply Display WA #22010492432 for combo PHY PLLs too. This should fix a
problem where the PLL output frequency is slightly off with the current
PLL fractional divider value.
I haven't seen an actual case where this causes a problem, but let's
follow the spec. It's also needed on some EHL platforms
== Series Details ==
Series: series starting with [1/2] drm/i915/ddi: Don't frob the DP link
scramble disabling flag
URL : https://patchwork.freedesktop.org/series/79481/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8744 -> Patchwork_18163
===
On Mon, Jul 13, 2020 at 04:53:33PM -0700, José Roberto de Souza wrote:
> Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> supported motherboards to use a special voltage swing table for eDP
> panels that uses less power.
>
> So here if supported by HW, OEM will set it in VB
Quoting Ville Syrjala (2020-07-14 16:26:23)
> From: Ville Syrjälä
>
> There's a pointless hole in struct intel_cdclk_vals, get rid of it.
> Fortunately we already use named initializers so the order does not
> matter.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_
Quoting Ville Syrjala (2020-07-14 16:26:25)
> From: Ville Syrjälä
>
> Explicitly check for i830 when assigning the .get_cdclk() vfunc,
> and then deal with the case of not having assigned the vfunc
> separately. Less confusing, and gets rid of the checkpatch complaint
> about using {} on one bran
Quoting Ville Syrjala (2020-07-14 16:26:24)
> From: Ville Syrjälä
>
> Some spaces have snuck in where we want tabs. Fix it.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/
> -Original Message-
> From: Auld, Matthew
> Sent: Tuesday, July 14, 2020 8:02 AM
> To: Dave Airlie
> Cc: Intel Graphics Development ; Tang, CQ
> ; Joonas Lahtinen ;
> Abdiel Janulgue ; Wilson, Chris P
> ; Balestrieri, Francesco
> ; Vishwanathapura, Niranjana
> ; Dhanalakota, Venkata S
== Series Details ==
Series: drm/i915: Avoid modeset when content protection changes
URL : https://patchwork.freedesktop.org/series/79484/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4a5730a3aea6 drm/i915: Avoid modeset when content protection changes
-:11: ERROR:GIT_COMMIT_I
1 - 100 of 214 matches
Mail list logo
