> + Zhi and Zhenyu
>
> Quoting Xiong Zhang (2018-03-29 13:58:41)
> > Four drm_mm_node are used to reserve guest ggtt space, but some of
> > them may aren't initialized and used in intel_vgt_balloon(), so these
> > unused drm_mm_node couldn't be removed through
> drm_mm_remove_node().
>
> I'm not
On 2018.03.30 07:01:02 +, Zhang, Xiong Y wrote:
> > + Zhi and Zhenyu
> >
> > Quoting Xiong Zhang (2018-03-29 13:58:41)
> > > Four drm_mm_node are used to reserve guest ggtt space, but some of
> > > them may aren't initialized and used in intel_vgt_balloon(), so these
> > > unused drm_mm_node c
On platforms with GuC SLPC enabled, we need to ensure Host RPS functions
don't update HW RPS state that will be controlled by GuC SLPC then.
Host RPS functions are now gated by either USES_GUC_SLPC() or rps->enabled
checks. If SLPC is enabled following functions will be bypassed
1. gpu_ips_init
Populate SLPC shared data with required default values for slice count,
power source/plan, IA perf MSRs.
v1: Update for SLPC interface version 2015.2.4. intel_slpc_active()
returns 1 if slpc initialized (Paulo)
change default host_os to "Windows"
Spelling fixes (Sagar and Nick Hoath).
From: Tom O'Rourke
If SLPC is to enabled, then set GUC_CTL_ENABLE_SLPC flag in GuC control
param GUC_CTL_FEATURE word during GuC load. This is required for early
SLPC init in GuC init path. SLPC gets enabled fully on sending this flag
during GuC load and on doing SLPC reset through Host to GuC ac
SLPC (Single Loop Power Controller) is a replacement for some host-based
power management features. The SLPC implementation runs in GuC firmware.
This series has been tested with SKL/APL/KBL GuC firmware v9 and v10.
The graphics power management features in SLPC are called GTPERF, BALANCER
and DCC
SLPC behavior can be changed through set of parameters. These parameters
can be updated and queried from i915 though Host to GuC SLPC events. This
patch adds parameter update events for setting/unsetting/getting params.
Setting parameter leads to overridding of default parameter value. Unset
leads
Communication with SLPC is via Host to GuC interrupt through shared data
and parameters. This patch defines the structure of shared data,
parameters, data structure to be passed as input and received as output
from SLPC. This patch also defines the events to be sent as input and
status values outpu
SLPC operates based on parameters setup in shared data between i915 and
GuC SLPC. This is to be created/initialized in intel_guc_slpc_init. From
there onwards i915 can control the SLPC operations by enabling, disabling
complete SLPC or changing SLPC parameters. During cleanup, SLPC shared
data has
Host to GuC actions for SLPC receive additional data as output through
scratch registers currently. intel_guc_send_and_receive handles this.
We need to define SLPC specific Host to GuC send action (slpc_send) as
wrapper on top of it to process the SLPC status that is received in
SOFT_SCRATCH(1).
S
From: Tom O'Rourke
Send SLPC shutdown event during uc_fini_hw or prior to enabling SLPC
done while communicating updated parameters in shared data.
v1: Return void instead of ignored error code (Paulo). Removed WARN_ON
for checking msb of gtt address of shared gem obj. (Chris)
Added SLPC
From: Tom O'Rourke
GuC is currently being used for submission and HuC authentication.
Choices can be configured through enable_guc modparam. GuC SLPC is GT
Power and Performance management feature in GuC. Add another option to
enable_guc modparam to control SLPC.
v1: Add early call to sanitize e
On engine reset, SLPC needs to be notified for it to clear metrics/stats.
This is done by sending GUC_SLPC_EVENT_RESET with a flag
GUC_SLPC_RESET_FLAG_TDR_OCCURRED.
v2: Full GPU reset in i915 triggers reload of GuC and SLPC reset happens
along that path. Hence only handling engine reset.
Sign
Input string parsing used in CRC control parameter parsing is generic and
can be reused for other debugfs interfaces. We plan to use this in the
next patch for SLPC debugfs control. Hence name it as buffer_tokenize
instead of tying to display_crc. Also fix the function desciption for CRC
control pa
From: Tom O'Rourke
Adds debugfs hooks for enabling/disabling each SLPC task.
The enable/disable debugfs files are:
i915_guc_slpc_gtperf, i915_guc_slpc_balancer, and i915_guc_slpc_dcc.
Each of these can take the values: "default", "enabled", or "disabled"
v1: update for SLPC v2015.2.4
dfps
Add support to set/read parameters and unset the parameters which will
revert them to default SLPC internal values. Explicit SLPC reset is needed
on setting/unsetting some of the parameters.
This patch adds two debugfs interfaces:
1. i915_guc_slpc_params: List of all parameters that Host can confi
Update sysfs functions to set SLPC parameters when setting max/min user
frequency limits.
v1: Update for SLPC 2015.2.4 (params for both slice and unslice). Replace
HAS_SLPC with intel_slpc_active() (Paulo)
v2-v4: Rebase.
v5: Removed typecasting the frequency values to u32. (Chris). Changed
When SLPC is controlling frequency requests, RPS state related to
autotuning is no longer valid. Make user aware through banner
upfront. Value read from register RPNSWREQ likely has the frequency
requested last by GuC SLPC.
v1: Replace HAS_SLPC with intel_slpc_active (Paulo)
Avoid magic number
From: Tom O'Rourke
i915_guc_slpc_info shows the contents of SLPC shared data parsed into text
format.
v1: Reformat slpc info (Radek). Squashed query task state info in slpc
info, kunmap before seq_print (Paulo) Return void instead of ignored
return value (Paulo)
Avoid magic numbers a
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 2484925..dd2de06 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers
== Series Details ==
Series: Add support for GuC-based SLPC (rev12)
URL : https://patchwork.freedesktop.org/series/2691/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d53e35c3815d drm/i915/guc/slpc: Add SLPC control to enable_guc modparam
6cf8c81b2bca drm/i915/guc/slpc: Disable
== Series Details ==
Series: Add support for GuC-based SLPC (rev12)
URL : https://patchwork.freedesktop.org/series/2691/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/guc/slpc: Add SLPC control to enable_guc modparam
Okay!
Commit: drm/i915/guc/slpc: Disable host R
== Series Details ==
Series: Add support for GuC-based SLPC (rev12)
URL : https://patchwork.freedesktop.org/series/2691/
State : failure
== Summary ==
Series 2691v12 Add support for GuC-based SLPC
https://patchwork.freedesktop.org/api/1.0/series/2691/revisions/12/mbox/
Warning: Kernel 32bit b
I think the adoption is not a problem here.
If driver can query that patch is active on the specific setup, new
capabilities will be always reported to the user.
-Original Message-
Quoting Dunajski, Bartosz (2018-03-26 12:46:13)
> Here is pull request with patch usage:
> https://github.co
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4)
URL : https://patchwork.freedesktop.org/series/36068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5ab2dbdddfa3 drm/i915: Introduce CRTC output format
-:86: CHECK:PARENTHESIS_ALIGNMENT: Alignment s
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4)
URL : https://patchwork.freedesktop.org/series/36068/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Introduce CRTC output format
Okay!
Commit: drm/i915: Add CRTC output format YCBCR 4
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4)
URL : https://patchwork.freedesktop.org/series/36068/
State : warning
== Summary ==
Series 36068v4 YCBCR 4:2:0/4:4:4 output support for LSPCON
https://patchwork.freedesktop.org/api/1.0/series/36068/revisions/4/mbox
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will rerun the submission tasklet
to evaluate the n
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
Reviewed-by: Jeff McGee
---
dr
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
-
Ideally, we want to atomically flush and disable the tasklet before
resetting the GPU. At present, we rely on being the only part to touch
our tasklet and serialisation of the reset process to ensure that we can
suspend the tasklet from the mix of reset/wedge pathways. In this patch,
we move the ta
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: Michał Winiarski
CC:
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, likely leading to that
context/process being ba
We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 inserti
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
Before adding a new feature to execlists submission, we should endeavour
to cover the baseline behaviour with selftests. So start the ball
rolling.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i91
When circumstances allow, trying resetting the engine directly from the
preemption timeout handler. As this is softirq context, we have to be
careful both not to sleep and not to spin on anything we may be
interrupting (e.g. the submission tasklet).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
v2: Install the timer on scheduling the preempt request; long bef
Fleshed out the reset from within the timer context (hardirq) to the
point where it at least passes selftests...
Not that CI even likes the sanitycheck at the moment.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freede
We would like to start doing some bookkeeping at the beginning, between
contexts and at the end of execlists submission. We already mark the
beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication
when the HW is idle. This give us a pair of sequence points we can then
expand on for
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.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Revi
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
trigg
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 22
drivers/gpu/drm/i915/i915_gem_context.h| 13 +
drivers/gpu/drm/i915/i915_request.c| 8 ++-
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0a86b9f594fb drm/i915/execlists: Track begin/end
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : failure
== Summary ==
Series 40927v1 series starting with [01/17] drm/i915/execlists: Track begin/end
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d71000599823 drm/i915/execlists: Track begin/end
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : success
== Summary ==
Series 40927v1 series starting with [01/17] drm/i915/execlists: Track begin/end
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail,
Quoting Hans de Goede (2018-03-30 13:27:15)
> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> skipping the first 4k by passing 4096 as start of the address range passed
> to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
> reserve the firmware frame
== Series Details ==
Series: series starting with [01/17] drm/i915/execlists: Track begin/end of
execlists submission sequences
URL : https://patchwork.freedesktop.org/series/40927/
State : failure
== Summary ==
Possible new issues:
Test drv_selftest:
Subgroup live_hangcheck:
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node(
On Fri, 30 Mar 2018 10:31:46 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
GuC is currently being used for submission and HuC authentication.
Choices can be configured through enable_guc modparam. GuC SLPC is GT
Power and Performance management feature in GuC. Add another option to
ena
Quoting Hans de Goede (2018-03-30 13:37:40)
> Hi,
>
> On 30-03-18 14:30, Chris Wilson wrote:
> > Quoting Hans de Goede (2018-03-30 13:27:15)
> >> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> >> skipping the first 4k by passing 4096 as start of the address range passed
>
== Series Details ==
Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated
buffers
URL : https://patchwork.freedesktop.org/series/40929/
State : success
== Summary ==
Series 40929v1 drm/i915: Do NOT skip the first 4k of stolen memory for
pre-allocated buffers
https://
We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrum
Hi,
On 30-03-18 14:44, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:37:40)
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start
== Series Details ==
Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40941/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
477c0fa0c0b5 drm/i915/selftests: Avoid repeatedly harming the same innocent
c
== Series Details ==
Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated
buffers
URL : https://patchwork.freedesktop.org/series/40929/
State : success
== Summary ==
Known issues:
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race:
fail
On Fri, 30 Mar 2018 10:31:50 +0200, Sagar Arun Kamble
wrote:
Communication with SLPC is via Host to GuC interrupt through shared data
and parameters. This patch defines the structure of shared data,
parameters, data structure to be passed as input and received as output
from SLPC. This patch
== Series Details ==
Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40941/
State : success
== Summary ==
Series 40941v1 drm/i915/selftests: Avoid repeatedly harming the same innocent
context
https://patchwork.freed
On Thu, 29 Mar 2018 23:25:57 +0100
Chris Wilson wrote:
> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sch
Quoting Steven Rostedt (2018-03-30 14:48:45)
> On Thu, 29 Mar 2018 23:25:57 +0100
> Chris Wilson wrote:
>
> > Across suspend, we may see a very large drift in timestamps if the sched
> > clock is unstable, prompting the global trace's ringbuffer code to warn
> > and suggest switching to the globa
Hi,
I've been working on a getfb2[0] ioctl, which amongst other things
supports multi-planar framebuffers as well as modifiers. getfb
currently calls the framebuffer's handle_create hook, which doesn't
support multiple planes.
Thanks to Noralf's recent work, drivers can just store GEM objects
dire
Hi,
On 30-03-18 15:25, Hans de Goede wrote:
Hi,
On 30-03-18 14:44, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:37:40)
Hi,
On 30-03-18 14:30, Chris Wilson wrote:
Quoting Hans de Goede (2018-03-30 13:27:15)
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
s
== Series Details ==
Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40941/
State : failure
== Summary ==
Possible new issues:
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic-transitions:
On Fri, 30 Mar 2018 15:07:53 +0100
Chris Wilson wrote:
> Sure, I was mainly floating the idea of trying to pick sensible
> defaults. Unstable clocks are quite rare nowadays, the ones we have in
> the lab are a pair of Core2 Duo.
I still have a box too ;-)
I'm not so against having global_clock
On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote:
> Hi,
> I've been working on a getfb2[0] ioctl, which amongst other things
> supports multi-planar framebuffers as well as modifiers. getfb
> currently calls the framebuffer's handle_create hook, which doesn't
> support multiple planes.
>
> Tha
:
https://github.com/0day-ci/linux/commits/Tvrtko-Ursulin/drm-i915-execlists-Consistent-seqno-reporting-in-GEM_TRACE/20180330-120802
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x0-03302126 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
Across suspend, we may see a very large drift in timestamps if the sched
clock is unstable, prompting the global trace's ringbuffer code to warn
and suggest switching to the global clock. Preempt this request by
detecting when the sched clock is unstable (determined during
late_initcall) and automa
Mention the alternative of adding trace_clock=global to the kernel
command line when we detect that we've used an unstable clock across a
suspend/resume cycle.
Signed-off-by: Chris Wilson
Cc: Steven Rostedt
---
kernel/trace/ring_buffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
== Series Details ==
Series: series starting with [v2,1/2] trace: Default to using
trace_global_clock if sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
935d891f5719 trace: Default to using trace_globa
Thanks for the review. Will update with all suggestions in the next rev.
On 3/30/2018 6:07 PM, Michal Wajdeczko wrote:
On Fri, 30 Mar 2018 10:31:46 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
GuC is currently being used for submission and HuC authentication.
Choices can be configure
== Series Details ==
Series: series starting with [v2,1/2] trace: Default to using
trace_global_clock if sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40952/
State : failure
== Summary ==
Series 40952v1 series starting with [v2,1/2] trace: Default to using
trace_glob
On 2018-03-29 00:28, Chris Wilson wrote:
Quoting Lis, Tomasz (2018-03-28 17:06:58)
On 2018-03-28 01:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving p
Fixed up the couple of bugs in the selftests that CI was tripping over,
or so I hope...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrum
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.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Revi
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
Reviewed-by: Jeff McGee
---
dr
Ideally, we want to atomically flush and disable the tasklet before
resetting the GPU. At present, we rely on being the only part to touch
our tasklet and serialisation of the reset process to ensure that we can
suspend the tasklet from the mix of reset/wedge pathways. In this patch,
we move the ta
We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so
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: Michał Winiarski
CC:
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 inserti
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4
We would like to start doing some bookkeeping at the beginning, between
contexts and at the end of execlists submission. We already mark the
beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication
when the HW is idle. This give us a pair of sequence points we can then
expand on for
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
trigg
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will rerun the submission tasklet
to evaluate the n
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 22
drivers/gpu/drm/i915/i915_gem_context.h| 13 +
drivers/gpu/drm/i915/i915_request.c| 8 ++-
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915
Before adding a new feature to execlists submission, we should endeavour
to cover the baseline behaviour with selftests. So start the ball
rolling.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i91
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
-
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, likely leading to that
context/process being ba
When circumstances allow, trying resetting the engine directly from the
preemption timeout handler. As this is softirq context, we have to be
careful both not to sleep and not to spin on anything we may be
interrupting (e.g. the submission tasklet).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
v2: Install the timer on scheduling the preempt request; long bef
On 3/30/2018 7:07 PM, Michal Wajdeczko wrote:
On Fri, 30 Mar 2018 10:31:50 +0200, Sagar Arun Kamble
wrote:
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.h
b/drivers/gpu/drm/i915/intel_guc_slpc.h
index 66c76fe..81250c0 100644
--- a/drivers/gpu/drm/i915/intel_guc_slpc.h
+++ b/drivers/gpu/
== Series Details ==
Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly
harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40961/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
33a1831a25b2 drm/i915/selftests: Avoid repeatedl
== Series Details ==
Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly
harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40961/
State : success
== Summary ==
Series 40961v1 series starting with [01/18] drm/i915/selftests: Avoid
repeatedl
== Series Details ==
Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly
harming the same innocent context
URL : https://patchwork.freedesktop.org/series/40961/
State : failure
== Summary ==
Possible new issues:
Test gem_ctx_param:
Subgroup invalid-param-ge
The patch adds a parameter to control the data port coherency functionality
on a per-exec call basis. When data port coherency flag value is different
than what it was in previous call for the context, a command to switch data
port coherency state is added before the buffer to be executed.
Rationa
1 - 100 of 139 matches
Mail list logo
