Under some circumstances (see intel_context_prepare_remote_request), we
may use a request along a kernel context to modify the logical state of
another. To keep the target context in place while the request executes,
we take an active reference on it using the kernel timeline. This is the
same time
Just a heads up that icl is consistently showing
<4> [315.478830] snd_hda_intel :00:1f.3: azx_get_response timeout,
switching to polling mode: last cmd=0x202f8100
<4> [316.482799] snd_hda_intel :00:1f.3: No response from codec, disabling
MSI: last cmd=0x202f8100
<3> [508.412915] snd_hda_
Just a heads up that icl is consistently showing
<4> [315.478830] snd_hda_intel :00:1f.3: azx_get_response timeout,
switching to polling mode: last cmd=0x202f8100
<4> [316.482799] snd_hda_intel :00:1f.3: No response from codec, disabling
MSI: last cmd=0x202f8100
<3> [508.412915] snd_hda_
On Thu, 25 Jul 2019 10:03:00 +0200,
Chris Wilson wrote:
>
> Just a heads up that icl is consistently showing
>
> <4> [315.478830] snd_hda_intel :00:1f.3: azx_get_response timeout,
> switching to polling mode: last cmd=0x202f8100
> <4> [316.482799] snd_hda_intel :00:1f.3: No response from
From: Tvrtko Ursulin
Save one level of derefernce by not going via global i915.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_vma.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
== Series Details ==
Series: drm/i915: Unshare the idle-barrier from other kernel requests (rev3)
URL : https://patchwork.freedesktop.org/series/64171/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4db89a82be2b drm/i915: Unshare the idle-barrier from other kernel requests
-:114
On Thu, 25 Jul 2019 10:16:07 +0200,
Takashi Iwai wrote:
>
> On Thu, 25 Jul 2019 10:03:00 +0200,
> Chris Wilson wrote:
> >
> > Just a heads up that icl is consistently showing
> >
> > <4> [315.478830] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > switching to polling mode: last cmd=0
Quoting Takashi Iwai (2019-07-25 09:26:56)
> On Thu, 25 Jul 2019 10:16:07 +0200,
> Takashi Iwai wrote:
> >
> > On Thu, 25 Jul 2019 10:03:00 +0200,
> > Chris Wilson wrote:
> > >
> > > Just a heads up that icl is consistently showing
> > >
> > > <4> [315.478830] snd_hda_intel :00:1f.3: azx_get
Quoting Tvrtko Ursulin (2019-07-25 09:26:00)
> From: Tvrtko Ursulin
>
> Save one level of derefernce by not going via global i915.
This shouldn't actually be on intel_gt. It's used as a keepalive
mechanism for GEM clients (the display servers that take a dri3 buffer
from a client, show it and th
== Series Details ==
Series: Revert "ALSA: line6: sizeof (byte) is always 1, use that fact."
URL : https://patchwork.freedesktop.org/series/64213/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
01fd92ee262b Revert "ALSA: line6: sizeof (byte) is always 1, use that fact."
-:9: WAR
== Series Details ==
Series: drm/i915: Unshare the idle-barrier from other kernel requests (rev3)
URL : https://patchwork.freedesktop.org/series/64171/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6547 -> Patchwork_13742
S
== Series Details ==
Series: Revert "ALSA: line6: sizeof (byte) is always 1, use that fact."
URL : https://patchwork.freedesktop.org/series/64213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6547 -> Patchwork_13743
Summar
Under some circumstances (see intel_context_prepare_remote_request), we
may use a request along a kernel context to modify the logical state of
another. To keep the target context in place while the request executes,
we take an active reference on it using the kernel timeline. This is the
same time
== Series Details ==
Series: drm/i915: Use intel_gt directly when closing VMAs
URL : https://patchwork.freedesktop.org/series/64216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6548 -> Patchwork_13744
Summary
---
*
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev2)
URL : https://patchwork.freedesktop.org/series/64212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5331d8b5ce96 Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Int
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev2)
URL : https://patchwork.freedesktop.org/series/64212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6548 -> Patchwork_13745
===
Quoting Chris Wilson (2019-07-25 09:30:25)
> Quoting Takashi Iwai (2019-07-25 09:26:56)
> > On Thu, 25 Jul 2019 10:16:07 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Thu, 25 Jul 2019 10:03:00 +0200,
> > > Chris Wilson wrote:
> > > >
> > > > Just a heads up that icl is consistently showing
> > >
On 25/07/2019 12:38, Chris Wilson wrote:
Under some circumstances (see intel_context_prepare_remote_request), we
may use a request along a kernel context to modify the logical state of
another. To keep the target context in place while the request executes,
we take an active reference on it using
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h |
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
Hi all,
Just posted some tests : https://patchwork.freedesktop.org/series/64220/
And shockingly it found a few bugs.
This series is also rebased on top of Chris' on the fly OA
reconfiguration of contexts.
Cheers,
Lionel Landwerlin (9):
drm/i915/perf: introduce a versioning of the i915-perf ua
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 32 ++-
include/uapi/drm/i915_drm.h
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke thin
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
On Thu, 25 Jul 2019 12:21:11 +0200,
Chris Wilson wrote:
>
> Quoting Chris Wilson (2019-07-25 09:30:25)
> > Quoting Takashi Iwai (2019-07-25 09:26:56)
> > > On Thu, 25 Jul 2019 10:16:07 +0200,
> > > Takashi Iwai wrote:
> > > >
> > > > On Thu, 25 Jul 2019 10:03:00 +0200,
> > > > Chris Wilson wrote:
Quoting Takashi Iwai (2019-07-25 11:44:08)
> On Thu, 25 Jul 2019 12:21:11 +0200,
> Chris Wilson wrote:
> >
> > Quoting Chris Wilson (2019-07-25 09:30:25)
> > > Quoting Takashi Iwai (2019-07-25 09:26:56)
> > > > On Thu, 25 Jul 2019 10:16:07 +0200,
> > > > Takashi Iwai wrote:
> > > > >
> > > > > On
== Series Details ==
Series: Revert "ALSA: line6: sizeof (byte) is always 1, use that fact."
URL : https://patchwork.freedesktop.org/series/64213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6547_full -> Patchwork_13743_full
==
== Series Details ==
Series: drm/i915: Unshare the idle-barrier from other kernel requests (rev4)
URL : https://patchwork.freedesktop.org/series/64171/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7e8e9ad5e045 drm/i915: Unshare the idle-barrier from other kernel requests
-:115
== Series Details ==
Series: drm/i915: Unshare the idle-barrier from other kernel requests (rev4)
URL : https://patchwork.freedesktop.org/series/64171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6549 -> Patchwork_13746
S
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev10)
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
63829d5dfc38 drm/i915/perf: introduce a versioning of the i915-perf uapi
499c943ab2e5 drm/i915/per
Quoting Patchwork (2019-07-25 12:44:16)
> == Series Details ==
>
> Series: drm/i915: Unshare the idle-barrier from other kernel requests (rev4)
> URL : https://patchwork.freedesktop.org/series/64171/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6549 -> Patchwork_137
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev10)
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: introduce a versioning of the i915-perf uapi
Okay!
Comm
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev3)
URL : https://patchwork.freedesktop.org/series/64212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b9d380a28e06 Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Int
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev10)
URL : https://patchwork.freedesktop.org/series/60916/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6549 -> Patchwork_13747
Summary
---
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev3)
URL : https://patchwork.freedesktop.org/series/64212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6549 -> Patchwork_13748
===
Quoting Takashi Iwai (2019-07-25 11:44:08)
> On Thu, 25 Jul 2019 12:21:11 +0200,
> Chris Wilson wrote:
> >
> > Quoting Chris Wilson (2019-07-25 09:30:25)
> > > Quoting Takashi Iwai (2019-07-25 09:26:56)
> > > > On Thu, 25 Jul 2019 10:16:07 +0200,
> > > > Takashi Iwai wrote:
> > > > >
> > > > > On
From: Tvrtko Ursulin
for_each_engine_masked caches the engine mask but what does the caller
know.
Cache it explicitly for clarity and while at it correct the type to match.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 6 +++---
1 file changed, 3 ins
On Thu, 25 Jul 2019 14:50:18 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-07-25 11:44:08)
> > On Thu, 25 Jul 2019 12:21:11 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Chris Wilson (2019-07-25 09:30:25)
> > > > Quoting Takashi Iwai (2019-07-25 09:26:56)
> > > > > On Thu, 25 Jul
Modifying a remote context requires careful serialisation with requests
on that context, and that serialisation requires us to take their
timeline->mutex. Make it so.
Note that while struct_mutex rules, we can't create more than one
request in parallel, but that age is soon coming to an end.
v2:
Under some circumstances (see intel_context_prepare_remote_request), we
may use a request along a kernel context to modify the logical state of
another. To keep the target context in place while the request executes,
we take an active reference on it using the kernel timeline. This is the
same time
Quoting Tvrtko Ursulin (2019-07-25 13:50:56)
> From: Tvrtko Ursulin
>
> for_each_engine_masked caches the engine mask but what does the caller
> know.
>
> Cache it explicitly for clarity and while at it correct the type to match.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
Stealing
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Signed-off-by: Oleg Vasilev
Cc: intel-gfx@lists.freedesktop.org
v2: updates to match previous commit changes
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/i915/dis
On 25/07/2019 10:38, Chris Wilson wrote:
Under some circumstances (see intel_context_prepare_remote_request), we
may use a request along a kernel context to modify the logical state of
another. To keep the target context in place while the request executes,
we take an active reference on it usin
== Series Details ==
Series: drm/i915: Use intel_gt directly when closing VMAs
URL : https://patchwork.freedesktop.org/series/64216/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6548_full -> Patchwork_13744_full
Summary
--
Quoting Tvrtko Ursulin (2019-07-25 14:19:22)
>
> On 25/07/2019 10:38, Chris Wilson wrote:
> > @@ -352,22 +384,29 @@ int i915_active_acquire_preallocate_barrier(struct
> > i915_active *ref,
> >
> > GEM_BUG_ON(!engine->mask);
> > for_each_engine_masked(engine, i915, engine->mask, tmp
On Thu, 25 Jul 2019 12:49:12 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-07-25 11:44:08)
> > On Thu, 25 Jul 2019 12:21:11 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Chris Wilson (2019-07-25 09:30:25)
> > > > Quoting Takashi Iwai (2019-07-25 09:26:56)
> > > > > On Thu, 25 Jul
Quoting Takashi Iwai (2019-07-25 14:45:10)
> On Thu, 25 Jul 2019 12:49:12 +0200,
> Chris Wilson wrote:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_l...@reload.html
> > <4> [383.858354] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > switching to
Sphinx was rendering firmware layout as html table, but since
we want to add sizes relations switch to plain text graphics.
v2: also update text and do it before move (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
Documentation/gpu/i915.rst | 12 -
We moved GuC related files to new location but we missed to update
.rst file with links.
References: commit 0f261b241d9c ("drm/i915/uc: move GuC and HuC files under
gt/uc/")
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Daniele Ceraolo Spurio
---
Do
Generic uc firmware layout definitions are unlikely to change and
are separate to other GuC specific definitions.
v2: reordered
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
---
Documentation/gpu/i915.rst | 2 +-
drivers/gpu/
From GT perspective, Comet Lake is just Coffe Lake rev 5,
but there is dedicated GuC firmware for it.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Anusha Srivatsa
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/
On Tue, 23 Jul 2019 at 17:17, Chris Wilson wrote:
>
> As we never officially write to the scratch buffer, the kernel will
> leave it in the CPU read domain upon execution. Our attempt to
> invalidate the CPU cache on !llc is therefore skipped as the kernel
> doesn't believe the backing store has b
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Add to timeline requires the
timeline mutex
URL : https://patchwork.freedesktop.org/series/64227/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
400f113b3b2b drm/i915/gt: Add to timeline requires the timeline
On Thu, 25 Jul 2019 15:57:10 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-07-25 14:45:10)
> > On Thu, 25 Jul 2019 12:49:12 +0200,
> > Chris Wilson wrote:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_l...@reload.html
> > > <4> [383.858354] sn
On 7/25/19 7:27 AM, Michal Wajdeczko wrote:
From GT perspective, Comet Lake is just Coffe Lake rev 5,
but there is dedicated GuC firmware for it.
According to Anusha there is also a dedicated HuC FW for it, which
should be coming out soon, so we should probably wait and add them both
at th
== Series Details ==
Series: drm/i915: Do not rely on for loop caching the mask
URL : https://patchwork.freedesktop.org/series/64225/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6551 -> Patchwork_13749
Summary
---
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Add to timeline requires the
timeline mutex
URL : https://patchwork.freedesktop.org/series/64227/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6551 -> Patchwork_13750
===
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Fix GuC documentation links
URL : https://patchwork.freedesktop.org/series/64237/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5ed7463b65ac drm/i915: Fix GuC documentation links
-:9: WARNING:COMMIT_LOG_LONG_L
Hi all,
Substitute-Maarten here for another pull request. This week is pretty light, as
you would expect. I merged a leftover nugget from drm-misc-next that didn't make
-rc1 and am abusing covering for Maarten by sneaking in a handful of msm
changes to avoid having to send 2 pulls.
drm-misc-fixe
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Fix GuC documentation links
URL : https://patchwork.freedesktop.org/series/64237/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6551 -> Patchwork_13751
Su
== Series Details ==
Series: drm/i915/guc: Define GuC firmware version for Comet Lake (rev5)
URL : https://patchwork.freedesktop.org/series/62969/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6552 -> Patchwork_13752
Summar
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev4)
URL : https://patchwork.freedesktop.org/series/64212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4c375059e361 Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Int
guc->stage_desc_pool is required as part of the init parameters and
there is no reason we have to init them after HuC. This fixes a NULL
ptr dereference due to guc->stage_desc_pool not being set (no fixes
tag since GuC submission can't be enabled yet).
Signed-off-by: Daniele Ceraolo Spurio
Cc: Mi
== Series Details ==
Series: drm/i915: Unshare the idle-barrier from other kernel requests (rev4)
URL : https://patchwork.freedesktop.org/series/64171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6549_full -> Patchwork_13746_full
=
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev4)
URL : https://patchwork.freedesktop.org/series/64212/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6552 -> Patchwork_13753
===
== Series Details ==
Series: drm/i915/guc: init submission structures as part of guc_init
URL : https://patchwork.freedesktop.org/series/64254/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6552 -> Patchwork_13754
Summary
-
Currently we use the engine->active.lock to ensure that the request is
not retired as we capture the data. However, we only need to ensure that
the vma are not removed prior to use acquiring their contents, and
since we have already relinquished our stop-machine protection, we
assume that the user
On 2019-07-25 00:32, Lucas De Marchi wrote:
On Thu, Jul 18, 2019 at 10:09:27AM -0700, Daniele Ceraolo Spurio wrote:
On 7/18/19 6:08 AM, Ville Syrjälä wrote:
On Fri, Jul 12, 2019 at 06:09:36PM -0700, Lucas De Marchi wrote:
From: Tomasz Lis
The MOCS table is published as part of bspec, and
== Series Details ==
Series: drm/i915: Capture vma contents outside of spinlock
URL : https://patchwork.freedesktop.org/series/64256/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Capture vma contents outside of spinlock
-O:drivers/gpu/drm/i
== Series Details ==
Series: drm/i915: Capture vma contents outside of spinlock
URL : https://patchwork.freedesktop.org/series/64256/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6552 -> Patchwork_13755
Summary
---
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev10)
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6549_full -> Patchwork_13747_full
Summary
-
On 7/25/19 7:13 AM, Michal Wajdeczko wrote:
Sphinx was rendering firmware layout as html table, but since
we want to add sizes relations switch to plain text graphics.
v2: also update text and do it before move (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-
Quoting Daniele Ceraolo Spurio (2019-07-25 21:16:23)
>
>
> On 7/25/19 7:13 AM, Michal Wajdeczko wrote:
> > Sphinx was rendering firmware layout as html table, but since
> > we want to add sizes relations switch to plain text graphics.
> >
> > v2: also update text and do it before move (Daniele)
Objtool reports:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
.altinstr_replacement+0x36: redundant UACCESS disable
__copy_from_user() already does both STAC and CLAC, so the
user_access_end() in its error path adds an extra unnecessary CLAC.
Fixes: 0b2c8f8b6b0c ("i915: f
== Series Details ==
Series: Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
(rev3)
URL : https://patchwork.freedesktop.org/series/64212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6549_full -> Patchwork_13748_full
=
We are already storing runtime value of log level in private
field, so there is no need to modify modparam.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 -
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 50 -
All intel_uc_fw_* functions are taking uc_fw as first param
except intel_uc_fw_fetch() which is taking i915. Fix that.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++-
drivers
On Thu, 25 Jul 2019 at 19:24, Chris Wilson wrote:
>
> Currently we use the engine->active.lock to ensure that the request is
> not retired as we capture the data. However, we only need to ensure that
> the vma are not removed prior to use acquiring their contents, and
> since we have already relin
Quoting Matthew Auld (2019-07-25 22:04:33)
> On Thu, 25 Jul 2019 at 19:24, Chris Wilson wrote:
> >
> > Currently we use the engine->active.lock to ensure that the request is
> > not retired as we capture the data. However, we only need to ensure that
> > the vma are not removed prior to use acquir
On 7/23/19 11:38 AM, Chris Wilson wrote:
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
Quoting Michal Wajdeczko (2019-07-25 22:03:14)
> All intel_uc_fw_* functions are taking uc_fw as first param
> except intel_uc_fw_fetch() which is taking i915. Fix that.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
Has a certain logic to it,
Reviewed-by: Chris Wilson
-Chris
Quoting Michal Wajdeczko (2019-07-25 21:51:06)
> We are already storing runtime value of log level in private
> field, so there is no need to modify modparam.
There is an aspect of communicating the clamped value back to the user.
Does that have any value or alternative?
-Chris
___
On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> Objtool reports:
>
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> .altinstr_replacement+0x36: redundant UACCESS disable
>
> __copy_from_user() already does both STAC and CLAC, so the
> user_access_end() in its error path adds
== Series Details ==
Series: drm/i915: Remove redundant user_access_end() from __copy_from_user()
error path
URL : https://patchwork.freedesktop.org/series/64262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6553 -> Patchwork_13756
===
== Series Details ==
Series: drm/i915/uc: Don't sanitize guc_log_level modparam
URL : https://patchwork.freedesktop.org/series/64264/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6553 -> Patchwork_13757
Summary
---
Currently we use the engine->active.lock to ensure that the request is
not retired as we capture the data. However, we only need to ensure that
the vma are not removed prior to use acquiring their contents, and
since we have already relinquished our stop-machine protection, we
assume that the user
Modifying a remote context requires careful serialisation with requests
on that context, and that serialisation requires us to take their
timeline->mutex. Make it so.
Note that while struct_mutex rules, we can't create more than one
request in parallel, but that age is soon coming to an end.
v2:
Replace sampling the engine state every so often with a periodic
heartbeat request to measure the health of an engine. This is coupled
with the forced-preemption to allow long running requests to survive so
long as they do not block other users.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc
Currently we use the engine->active.lock to ensure that the request is
not retired as we capture the data. However, we only need to ensure that
the vma are not removed prior to use acquiring their contents, and
since we have already relinquished our stop-machine protection, we
assume that the user
Under some circumstances (see intel_context_prepare_remote_request), we
may use a request along a kernel context to modify the logical state of
another. To keep the target context in place while the request executes,
we take an active reference on it using the kernel timeline. This is the
same time
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
Replace sampling the engine state every so often with a periodic
heartbeat request to measure the health of an engine. This is coupled
with the forced-preemption to allow long running requests to survive so
long as they do not block other users.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc
> -Original Message-
> From: Chris Wilson
> Sent: Thursday, July 25, 2019 4:17 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Joonas Lahtinen
> ; Ursulin, Tvrtko ;
> Bloomfield, Jon
> Subject: [PATCH] drm/i915: Replace hangcheck by heartbeats
>
> Replace sampling the engin
Quoting Bloomfield, Jon (2019-07-26 00:21:47)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Thursday, July 25, 2019 4:17 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Joonas Lahtinen
> > ; Ursulin, Tvrtko
> > ;
> > Bloomfield, Jon
> > Subject: [PATCH] drm/i9
From: Mahesh Kumar
Bit definitions for port-select got changed for TRANS_CLK_SEL &
TRANS_DDI_FUNC_CTL registers in TGL.
v2 (Lucas):
- Nuke TRANS_DDI_PORT_NONE since it's 0: we are already clearing
{TGL_,}TRANS_DDI_PORT_MASK (suggested by Ville)
- Also cover haswell_get_ddi_port_state() i
From: Mahesh Kumar
In GEN 12 PORT_C DDI clk_off bit is not equally distanced to A/B,
it's at offset 24. Similarly TC port (5/6) clk off bits are at
offset 22/23. Extend the macros to cover the additional ports.
Cc: Matt Roper
Signed-off-by: Mahesh Kumar
Signed-off-by: Lucas De Marchi
Reviewed
1 - 100 of 152 matches
Mail list logo
