Hi Dave,
Here goes drm-intel-fixes-2018-03-21:
One fix for DP MST and one fix for GPU reset on hang check.
Thanks,
Rodrigo.
The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f:
Linux 4.16-rc6 (2018-03-18 17:48:42 -0700)
are available in the git repository at:
git:
== Series Details ==
Series: drm: Fix uabi regression by allowing garbage mode->type from userspace
URL : https://patchwork.freedesktop.org/series/40416/
State : success
== Summary ==
Known issues:
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Include the trace as a
debug aide
URL : https://patchwork.freedesktop.org/series/40410/
State : warning
== Summary ==
Possible new issues:
Test kms_atomic_transition:
Subgroup plane-toggle-modeset-transi
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/scheduler.c
between commit:
fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
from Linus' tree and commit:
b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinn
== Series Details ==
Series: series starting with [1/2] drm/i915: Use full serialisation around
engine->irq_posted
URL : https://patchwork.freedesktop.org/series/40406/
State : warning
== Summary ==
Possible new issues:
Test gem_eio:
Subgroup execbuf:
pass
On Thu, 2018-03-15 at 11:28 +0100, Maarten Lankhorst wrote:
> Currently tests modify i915.enable_psr and then do a modeset cycle
> to change PSR. We can write a value to i915_edp_psr_status to force
> a certain value without a modeset.
>
> To retain compatibility with older userspace, we also stil
== Series Details ==
Series: drm/i915: Use full serialisation around engine->irq_posted
URL : https://patchwork.freedesktop.org/series/40403/
State : success
== Summary ==
Known issues:
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS (
== Series Details ==
Series: drm/i915/gvt: don't dereference 'workload' before null checking it
URL : https://patchwork.freedesktop.org/series/40401/
State : success
== Summary ==
Known issues:
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS
== Series Details ==
Series: drm/i915/selftests: Stress resets-vs-request-priority
URL : https://patchwork.freedesktop.org/series/40397/
State : failure
== Summary ==
Possible new issues:
Test drv_selftest:
Subgroup live_hangcheck:
pass -> DMESG-FAIL (shard-
On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote:
> On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > > From: Dani
On Wed, 2018-03-21 at 21:48 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> > Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
> > PSR entry.
> >
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > Cc: Daniel Vetter
> > Si
On Wed, 2018-03-21 at 21:45 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> >
> > User can make such a
== Series Details ==
Series: cgroup private data and DRM/i915 integration (rev3)
URL : https://patchwork.freedesktop.org/series/40142/
State : success
== Summary ==
Series 40142v3 cgroup private data and DRM/i915 integration
https://patchwork.freedesktop.org/api/1.0/series/40142/revisions/3/mb
== Series Details ==
Series: cgroup private data and DRM/i915 integration (rev3)
URL : https://patchwork.freedesktop.org/series/40142/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8c23fa59eef7 cgroup: Allow registration and lookup of cgroup private data (v3)
95f12a7ecd5d cgrou
Update i915_context_status to include priority information.
v2:
- Clarify that the offset is based on cgroup (Chris)
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i
In preparation for adding cgroup-based priority adjustments, let's
define the driver's priority values a little more clearly.
v2:
- checkpatch warning fix (Intel CI)
Cc: Chris Wilson
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_co
Usually display-boosted contexts get treated as
I915_CONTEXT_MAX_USER_PRIORITY+1, which prioritizes them above regular
GPU contexts. Now that we allow a much larger range of effective
priority values via per-cgroup priority offsets, a system administrator
may want more detailed control over how mu
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to
There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-lev
Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow
userspace to set i915-specific parameters for individual cgroups. i915
cgroup data will be registered and later looked up via the new
cgroup_priv infrastructure.
v2:
- Large rebase/rewrite for new cgroup_priv interface
v3:
- A
Getting cgroup private data for the current process' cgroup is such a
common pattern that we should add a convenience wrapper for it.
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 1 +
kernel/cgroup/cgroup.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/
This version of the patch series just contains some minor updates to
address checkpatch and sparse warnings. There are no serious design or
implementation changes since v4.
You can find the previous versions of this series (and more detailed
cover letters) here:
(v1) https://lists.freedesktop.or
Wraps task_dfl_cgroup() to also take a reference to the cgroup.
v2:
- Eliminate cgroup_mutex and make lighter-weight (Tejun)
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 29 +
1 file changed, 29 insertions(+)
dif
Thanks Sagar and Joonas! I probably need reconfigure my email client.
I will add these docs to i915.rst. Since we've already had a GuC chapter
defined in i915.rst,
so I will include these doc like:
WOPCM
WOPCM Layout doc
GuC
GuC Address Space doc
Please let me kn
== Series Details ==
Series: drm: Fix uabi regression by allowing garbage mode->type from userspace
URL : https://patchwork.freedesktop.org/series/40416/
State : success
== Summary ==
Series 40416v1 drm: Fix uabi regression by allowing garbage mode->type from
userspace
https://patchwork.freed
== Series Details ==
Series: drm: Fix uabi regression by allowing garbage mode->type from userspace
URL : https://patchwork.freedesktop.org/series/40416/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ace93ec3e0c drm: Fix uabi regression by allowing garbage mode->type from
use
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Include the trace as a
debug aide
URL : https://patchwork.freedesktop.org/series/40410/
State : success
== Summary ==
Series 40410v1 series starting with [1/2] drm/i915/selftests: Include the trace
as a debug aide
ht
Em Ter, 2018-02-27 às 14:22 -0800, James Ausmus escreveu:
> On Thu, Feb 22, 2018 at 12:55:03AM -0300, Paulo Zanoni wrote:
> > There's a lot of code for the PLL enabling, so let's first only
> > introduce the register definitions in order to make patch reviewing
> > a
> > little easier.
> >
> > v2:
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Include the trace as a
debug aide
URL : https://patchwork.freedesktop.org/series/40410/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5775fcc92769 drm/i915/selftests: Include the trace as a debug aide
== Series Details ==
Series: drm/i915: Flush pending interrupt following a GPU reset
URL : https://patchwork.freedesktop.org/series/40383/
State : success
== Summary ==
Known issues:
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS (sha
From: Ville Syrjälä
Apparently xf86-video-vmware leaves the mode->type uninitialized
when feeding the mode to the kernel. Thus we have no choice but
to accept the garbage in. We'll just ignore any of the bits we
don't want. The mode type is just a hint anyway, and more
useful for the kernel->user
On 03/21/2018 09:51 PM, Ville Syrjälä wrote:
On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote:
Hi, Ville,
On 11/14/2017 07:32 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as
Watch what happens if we try to reset with a queue of requests with
varying priorities -- that may need reordering or preemption across the
reset.
v2: Tweak priorities to avoid starving the hanging thread.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 189 ++
If we fail to reset the GPU in a timely fashion, dump the GEM trace so
that we can see what operations were in flight when the GPU got stuck.
v2: There's more than one timeout that deserves tracing!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 23 ++
Hi, Ville,
On 11/14/2017 07:32 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as are drivers when probing modes.
Reject any mode with bogus flags/type.
Hopefully this won't break any current u
On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote:
> Hi, Ville,
>
> On 11/14/2017 07:32 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently userspace is allowed to feed in any king of garbage in the
> > high bits of the mode flags/type, as are drivers when probing mo
== Series Details ==
Series: series starting with [1/2] drm/i915: Use full serialisation around
engine->irq_posted
URL : https://patchwork.freedesktop.org/series/40406/
State : success
== Summary ==
Series 40406v1 series starting with [1/2] drm/i915: Use full serialisation
around engine->irq
On Tue, Mar 13, 2018 at 08:46:56PM +, Souza, Jose wrote:
> On Mon, 2018-03-12 at 20:46 -0700, Dhinakaran Pandiyan wrote:
> > HSW and BDW have SRD_AUX_{CTL, STATUS} registers that the driver
> > needs to
> > setup for the HW to use whenever exiting PSR. SKL+ hardware use
> > hardcoded
> > values
== Series Details ==
Series: series starting with [1/2] drm/i915: Use full serialisation around
engine->irq_posted
URL : https://patchwork.freedesktop.org/series/40406/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ffea28ec97fb drm/i915: Use full serialisation around engine->i
On Mon, Mar 12, 2018 at 08:46:45PM -0700, Dhinakaran Pandiyan wrote:
> Non-functional change useful for the following patch.
>
> Cc: Rodrigo Vivi
> Cc: José Roberto de Souza
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_psr.c | 31
== Series Details ==
Series: drm/i915: Use full serialisation around engine->irq_posted
URL : https://patchwork.freedesktop.org/series/40403/
State : success
== Summary ==
Series 40403v1 drm/i915: Use full serialisation around engine->irq_posted
https://patchwork.freedesktop.org/api/1.0/series
Using engine->irq_posted for execlists, we are not always serialised by
the tasklet as we supposed. On the reset paths, the tasklet is disabled
and ignored. Instead, we manipulate the engine->irq_posted directly to
account for the reset, but if an interrupt fired before the reset and so
wrote to en
After resetting the GPU (or subset of engines), call synchronize_irq()
to flush any pending irq before proceeding with the cleanup. For a
device level reset, we disable the interupts around the reset, but when
resetting just one engine, we have to avoid such global disabling. This
leaves us open to
== Series Details ==
Series: drm/i915/gvt: don't dereference 'workload' before null checking it
URL : https://patchwork.freedesktop.org/series/40401/
State : success
== Summary ==
Series 40401v1 drm/i915/gvt: don't dereference 'workload' before null checking
it
https://patchwork.freedesktop.o
On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
> PSR entry.
>
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Daniel Vetter
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/i915_deb
On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote:
> Interrupts other than the one for AUX errors are required only for debug,
> so unmask them via debugfs when the user requests debug.
>
> User can make such a request with
> echo 1 > /dri/0/i915_edp_psr_debug
>
> Cc: Rodrigo Vi
On 3/21/2018 3:16 AM, Chris Wilson wrote:
Quoting Oscar Mateo (2018-03-20 18:43:45)
On 3/19/2018 7:14 AM, Lis, Tomasz wrote:
On 2018-03-19 13:43, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-19 12:37:35)
The patch adds a parameter to control the data port coherency
functionality
on a p
Em Sex, 2018-03-16 às 16:01 +0100, Maarten Lankhorst escreveu:
> Instead of taking fbc->lock inside the worker, don't take any lock
> and cancel the work synchronously to prevent races. Since the worker
> waits for a vblank before activating, wake up all vblank waiters
> after
> signalling the canc
On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > From: Daniel Vetter
> > >
> > > The definitions for the error register should be
== Series Details ==
Series: drm/i915/selftests: Stress resets-vs-request-priority
URL : https://patchwork.freedesktop.org/series/40397/
State : success
== Summary ==
Series 40397v1 drm/i915/selftests: Stress resets-vs-request-priority
https://patchwork.freedesktop.org/api/1.0/series/40397/rev
On 21/03/18 19:23, Chris Wilson wrote:
> Quoting Colin Ian King (2018-03-21 19:18:28)
>> On 21/03/18 19:09, Joe Perches wrote:
>>> On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
From: Colin Ian King
The pointer workload is dereferenced before it is null checked, hence
the
On Wed, 2018-03-21 at 19:18 +, Colin Ian King wrote:
> On 21/03/18 19:09, Joe Perches wrote:
> > On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > The pointer workload is dereferenced before it is null checked, hence
> > > there is a potential for a n
Quoting Colin Ian King (2018-03-21 19:18:28)
> On 21/03/18 19:09, Joe Perches wrote:
> > On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> The pointer workload is dereferenced before it is null checked, hence
> >> there is a potential for a null pointer deref
On Wed, Mar 21, 2018 at 12:25:40PM +0200, Ville Syrjälä wrote:
> > > This structure seems to be poorly organized for 64bit machines.
> >
> >
> > Yes, there's a 4-bytes right there. Fixing this unfortunately
> > involves changing
> > all tables inside dpll_mgr.c.
>
> Those aren't using named in
On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > From: Daniel Vetter
> >
> > The definitions for the error register should be valid on bdw/skl too,
> > but there we haven't even enabled DE_MISC handling yet.
> >
On 21/03/18 19:09, Joe Perches wrote:
> On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
>> From: Colin Ian King
>>
>> The pointer workload is dereferenced before it is null checked, hence
>> there is a potential for a null pointer dereference on workload. Fix
>> this by only dereferencing wor
Using engine->irq_posted for execlists, we are not always serialised by
the tasklet as we supposed. On the reset paths, the tasklet is disabled
and ignored. Instead, we manipulate the engine->irq_posted directly to
account for the reset, but if an interrupt fired before the reset and so
wrote to en
== Series Details ==
Series: drm/i915/selftests: Stress resets-vs-request-priority
URL : https://patchwork.freedesktop.org/series/40397/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
db8550b31cc9 drm/i915/selftests: Stress resets-vs-request-priority
-:272: CHECK:SPACING: spaces
On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> From: Colin Ian King
>
> The pointer workload is dereferenced before it is null checked, hence
> there is a potential for a null pointer dereference on workload. Fix
> this by only dereferencing workload after it is null checked.
>
> Detecte
From: Colin Ian King
The pointer workload is dereferenced before it is null checked, hence
there is a potential for a null pointer dereference on workload. Fix
this by only dereferencing workload after it is null checked.
Detected by CoverityScan, CID#1466017 ("Dereference before null check")
F
Quoting Chris Wilson (2018-03-21 18:12:51)
> Quoting Jeff McGee (2018-03-21 17:31:45)
> > On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > Engine reset is fast. A context switch interrupt may be generated just
> > > prior to the reset such t
Quoting Jeff McGee (2018-03-21 18:29:46)
> On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote:
> > Quoting Jeff McGee (2018-03-21 17:33:04)
> > > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > > > From: Jeff McGee
> > > >
> > > > Signed-off-by: Jeff McGee
> >
On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> From: Daniel Vetter
>
> The definitions for the error register should be valid on bdw/skl too,
> but there we haven't even enabled DE_MISC handling yet.
>
> Somewhat confusing the the moved register offset on bdw is only for
Watch what happens if we try to reset with a queue of requests with
varying priorities -- that may need reordering or preemption across the
reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 154 +++
1 file changed, 103 insertions(+), 51
== Series Details ==
Series: Force preemption (rev2)
URL : https://patchwork.freedesktop.org/series/40120/
State : failure
== Summary ==
Applying: drm/i915/execlists: Refactor out complete_preempt_context()
Applying: drm/i915: Add control flags to i915_handle_error()
error: Failed to merge in
On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-21 17:33:04)
> > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > Signed-off-by: Jeff McGee
> > > ---
> > > drivers/gpu/drm/i915/intel_lrc.c | 2 +-
== Series Details ==
Series: lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill
function
URL : https://patchwork.freedesktop.org/series/40378/
State : success
== Summary ==
Possible new issues:
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-at
Quoting Jeff McGee (2018-03-21 17:31:45)
> On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > Engine reset is fast. A context switch interrupt may be generated just
> > prior to the reset such that the top half handler is racing with reset
> > post-
Quoting Jeff McGee (2018-03-21 17:33:04)
> On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > Signed-off-by: Jeff McGee
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/dr
On Fri, Mar 16, 2018 at 04:01:21PM +0100, Maarten Lankhorst wrote:
> Instead of taking fbc->lock inside the worker, don't take any lock
> and cancel the work synchronously to prevent races. Since the worker
> waits for a vblank before activating, wake up all vblank waiters after
> signalling the ca
On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Signed-off-by: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/in
On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Engine reset is fast. A context switch interrupt may be generated just
> prior to the reset such that the top half handler is racing with reset
> post-processing. The handler may set the irq_posted bit ag
From: Chris Wilson
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson
Cc: M
From: Jeff McGee
Force preemption uses engine reset to enforce a limit on the time
that a request targeted for preemption can block. This feature is
a requirement in automotive systems where the GPU may be shared by
clients of critically high priority and clients of low priority that
may not have
From: Jeff McGee
The hardware can complete the requested preemption at only certain points
in execution. Thus an uncooperative request that avoids those points can
block a preemption indefinitely. Our only option to bound the preemption
latency is to trigger reset and recovery just as we would if
From: Chris Wilson
Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.
v2: Pass msg down to i915_reset/i915_reset_en
From: Chris Wilson
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
---
drivers/gpu/
From: Chris Wilson
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 355
From: Jeff McGee
Engine reset is fast. A context switch interrupt may be generated just
prior to the reset such that the top half handler is racing with reset
post-processing. The handler may set the irq_posted bit again after
the reset code has cleared it to start fresh. Then the re-enabled
task
From: Jeff McGee
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index beb81f13a3cc..cec4e1653daf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
From: Chris Wilson
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
driver
== Series Details ==
Series: drm/i915/selftests: Include the trace as a debug aide (rev2)
URL : https://patchwork.freedesktop.org/series/40362/
State : success
== Summary ==
Known issues:
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
pass -> FAIL
On Wed, Mar 21, 2018 at 04:42:32PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-21 15:55:16)
> > On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > > After resetting the GPU (or subset of engines), call synchronize_irq()
> > > to flush any pending irq before proceeding wi
== Series Details ==
Series: drm/i915: Flush pending interrupt following a GPU reset
URL : https://patchwork.freedesktop.org/series/40383/
State : success
== Summary ==
Series 40383v1 drm/i915: Flush pending interrupt following a GPU reset
https://patchwork.freedesktop.org/api/1.0/series/40383
Quoting Michel Thierry (2018-03-21 17:01:12)
> On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> >> We were relying on the uncached reads when processing the CSB to provide
> >> ourselves with the serialisation with the interrupt handler (so we could
> >> detect new interr
Maxime Ripard writes:
> [ Unknown signature status ]
> Hi,
>
> On Mon, Mar 05, 2018 at 03:21:26PM +0100, Maxime Ripard wrote:
>> Here is an RFC at starting to test the plane formats using the
>> Chamelium over the HDMI. This was tested using the vc4 DRM driver
>> found on the RaspberryPi.
>>
>>
Quoting Chris Wilson (2018-03-21 17:05:06)
> Quoting Michel Thierry (2018-03-21 17:01:12)
> > On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
> > > Chris Wilson writes:
> > >
> > >> We were relying on the uncached reads when processing the CSB to provide
> > >> ourselves with the serialisation with th
Quoting Michel Thierry (2018-03-21 17:01:12)
> On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> >> We were relying on the uncached reads when processing the CSB to provide
> >> ourselves with the serialisation with the interrupt handler (so we could
> >> detect new interr
On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
Chris Wilson writes:
We were relying on the uncached reads when processing the CSB to provide
ourselves with the serialisation with the interrupt handler (so we could
detect new interrupts in the middle of processing the old one). However,
in commit 7
== Series Details ==
Series: drm/i915: Flush pending interrupt following a GPU reset
URL : https://patchwork.freedesktop.org/series/40383/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c3bbd56f3b68 drm/i915: Flush pending interrupt following a GPU reset
-:23: WARNING:COMMIT_LOG
Quoting Jeff McGee (2018-03-21 15:55:16)
> On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > After resetting the GPU (or subset of engines), call synchronize_irq()
> > to flush any pending irq before proceeding with the cleanup. For a
> > device level reset, we disable the interupts
Quoting Jeff McGee (2018-03-21 15:55:16)
> On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > After resetting the GPU (or subset of engines), call synchronize_irq()
> > to flush any pending irq before proceeding with the cleanup. For a
> > device level reset, we disable the interupts
On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> After resetting the GPU (or subset of engines), call synchronize_irq()
> to flush any pending irq before proceeding with the cleanup. For a
> device level reset, we disable the interupts around the reset, but when
> resetting just one
Quoting Zhenyu Wang (2018-03-20 04:41:08)
>
> Hi, Joonas
>
> Here's gvt-next-fixes update for 4.17. One regression that
> caused guest VM gpu hang has been fixed and with other changes
> as details below.
Pulled, thanks.
Regards, Joonas
___
Intel-gfx
Quoting Michał Winiarski (2018-03-20 18:56:59)
> On Mon, Mar 19, 2018 at 12:50:49PM +, Michal Wajdeczko wrote:
> > We already try to keep all GuC log related code in separate file,
> > handling flush event should be placed there too. This will also
> > allow future code reuse.
> >
> > v2: reba
Quoting Michal Wajdeczko (2018-03-20 16:20:20)
> There is no need to mix parameter types in public CT functions
> as we can always accept intel_guc_ct.
>
> v2: fix 'Return' doc, s/dev_priv/i915 (Sagar)
>
> Signed-off-by: Michal Wajdeczko
> Cc: Sagar Arun Kamble
> Cc: Chris Wilson
> Reviewed-by
Quoting Patchwork (2018-03-20 19:04:24)
> == Series Details ==
>
> Series: series starting with [CI,1/3] drm/i915/guc: Unify naming of private
> GuC action functions
> URL : https://patchwork.freedesktop.org/series/40311/
> State : success
>
> == Summary ==
>
> Series 40311v1 series starting
Quoting Michel Thierry (2018-03-14 23:34:33)
> On 14/03/18 15:23, Michal Wajdeczko wrote:
> > On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry
> > wrote:
> >
> >> On 14/03/18 13:04, Michal Wajdeczko wrote:
> >>> We try to keep all HuC related code in dedicated file.
> >>> There is no need to p
On Wed, 21 Mar 2018, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915: prefer INTEL_GEN() over
> INTEL_INFO()->gen
> URL : https://patchwork.freedesktop.org/series/40380/
> State : failure
>
> == Summary ==
>
> CHK include/config/kernel.release
>
After resetting the GPU (or subset of engines), call synchronize_irq()
to flush any pending irq before proceeding with the cleanup. For a
device level reset, we disable the interupts around the reset, but when
resetting just one engine, we have to avoid such global disabling. This
leaves us open to
1 - 100 of 155 matches
Mail list logo
