On 19/03/18 18:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As well as exposing active requests on engines via PMU, we can also export
the current raw values (as tracked by i915 command submission) via a
dedicated query.
This is to satisfy customers who have userspace load balancing solution
On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > This was my bad, spec says that the name of this bit is
> > 'Y-coordinate valid' but the values for it is:
> > 0: Include Y-coordinate valid eDP1.4a
> > 1: Do not inc
On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> This was my bad, spec says that the name of this bit is
> 'Y-coordinate valid' but the values for it is:
> 0: Include Y-coordinate valid eDP1.4a
> 1: Do not include Y-coordinate valid eDP 1.4
> So renaming the bit and not setting it
Quoting Chris Wilson (2018-03-22 07:35:32)
> 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
== Series Details ==
Series: series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON
to HSW+ function
URL : https://patchwork.freedesktop.org/series/40978/
State : warning
== Summary ==
Series 40978v1 series starting with [01/11] drm/i915/psr: Move specific HSW+
WARN_ON to HSW+
== Series Details ==
Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status
URL : https://patchwork.freedesktop.org/series/40977/
State : failure
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
dmesg-warn
== Series Details ==
Series: series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON
to HSW+ function
URL : https://patchwork.freedesktop.org/series/40978/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
499cc3f929a4 drm/i915/psr: Move specific HSW+ WARN_ON to HSW+
When PSR/PSR2 is enabled hardware can do aux ch transactions by it
self.
Spec requires that PSR is inactive before do any aux ch transaction
in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
recommended.
So exiting PSR/PSR2 and waiting the transition to inactive to prevent
any con
intel_psr_activate_block_get() should be called when by some reason
PSR should not be activated for some time, it will increment counter
and it should the decremented by intel_psr_activate_block_put()
when PSR can be activated again.
intel_psr_activate_block_put() will not actually activate PSR, us
To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to
differentiate between VLV/CHV and HSW+ hardware, so here moving each
hardware handling to his own function.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h |
eDP spec states that sink device will do a short pulse in HPD
line when there is a PSR/PSR2 error that needs to be handled by
source, this is handling the first and most simples error:
DP_PSR_SINK_INTERNAL_ERROR.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
'drm/i915/dp: Exit PSR before do a aux channel transaction' cause all
IGT PSR and frontbuffer tracking tests to not be userful.
Those tests depend in reading the calculated CRC value of the
frontbuffer in sink and doing a aux transaction now causes the PSR
to exit.
So any bug in software and hardwa
The disable and exit sequence are very similar with a lot common
code between both, so here sharing the code.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_psr.c | 84 ++
Export this functions so other modules can activate and exit PSR.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_psr.c | 94 +---
2 files changed, 89 inser
It is not necessary as is possible to get the pipe information
from intel_dp.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/intel_psr.c | 13 ++---
2 files changed, 7 insertions(+), 9 de
Sink will interrupt source when it have any problem saving or reading
the remote frame buffer.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915
It was reading some random register in VLV and CHV.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm
Sink can be configured to calculate the CRC over the static frame and
compare with the CRC calculated and transmited in the VSC SDP by
source, if there is a mismatch sink will do a short pulse in HPD
and set DP_PSR_LINK_CRC_ERROR on DP_PSR_ERROR_STATUS.
Spec: 7723
Signed-off-by: José Roberto de S
== Series Details ==
Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status
URL : https://patchwork.freedesktop.org/series/40977/
State : success
== Summary ==
Series 40977v1 series starting with [1/2] drm/i915/debugfs: Print sink PSR
status
https://patchwork.freedesktop.o
== Series Details ==
Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status
URL : https://patchwork.freedesktop.org/series/40977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9444b2175c0a drm/i915/debugfs: Print sink PSR status
6d65247b0089 drm/i915/psr/cnl
== Series Details ==
Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts
on hsw (rev2)
URL : https://patchwork.freedesktop.org/series/40704/
State : failure
== Summary ==
Applying: drm/i915: Enable edp psr error interrupts on hsw
Applying: drm/i915: Enable edp psr
On Fri, 2018-03-30 at 14:15 -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
>
> There are no locks
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So renaming the bit and not setting it.
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
driv
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +
1 file changed, 29 insertio
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
There are no locks to serialize PSR debug enabling from
irq_postinstall() and debugfs for simplic
On Fri, 2018-03-30 at 19:19 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > > IGT tests could be improved with sink status, knowing for sure that
> > > hardware have activate or exi
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev2)
URL : https://patchwork.freedesktop.org/series/40181/
State : failure
== Summary ==
Possible new issues:
Test gem_exec_params:
Subgroup invalid-flag:
pass -> FAIL
On 30/03/18 08:42, Lis, Tomasz wrote:
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 E
On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
>
>Четверг, 29 марта 2018, 21:46 +03:00 от Tvrtko Ursulin :
>
>+#define engine_ptr(engines, n) \
>+((struct engine *)((unsigned char *)(&engines->engine) + (n) * sizeof(struct
>engine)))
I think (&engines->engine + (n)) is easier to read.
>+if (fd < 0 && !cnt->optional)
>+return -1;
I've tried
Ville Syrjala writes:
> From: Ville Syrjälä
>
> Up to now we've used the plane's modifier list as the primary
> source of information for which modifiers are supported by a
> given plane. In order to allow auxiliary metadata to be embedded
> within the bits of the modifier we need to stop doing
Francisco Jerez writes:
> This series attempts to solve an energy efficiency problem of the
> current active-mode non-HWP governor of the intel_pstate driver used
> for the most part on low-power platforms. Under heavy IO load the
> current controller tends to increase frequencies to the maximum
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev2)
URL : https://patchwork.freedesktop.org/series/40181/
State : success
== Summary ==
Series 40181v2 drm/i915: Add Exec param to control data port coherency.
https://patchwork.freedesktop.org/api/1.0/ser
On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
> v3: rebased
>
> drivers
On 27/03/18 16: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 preemption result from
Context Status Buffer.
Preemption in previous gens required a spe
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev2)
URL : https://patchwork.freedesktop.org/series/40181/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
415de02a8f37 drm/i915: Add Exec param to control data port coherency.
-:14: WARNING:C
On Fri, 2018-03-30 at 10:36 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > For Geminilake and Cannonlake+ the Y-coordinate support must be
> > enabled in PSR2_CTL too.
> >
> > Spec: 7713 and 7720
> >
> > Cc: Dhinakaran Pandiyan
> >
On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote:
> In the 2 eDP1.4a pannels tested set or not set bit have no effect
> but is better set it and comply with specification.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
patche
On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
>
> Spec: 7713 and 7720
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
> v3:
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
== 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
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
33a1831a25b2 drm/i915/selftests: Avoid repeatedl
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/
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
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
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
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
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
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
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
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
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
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
== 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
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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
935d891f5719 trace: Default to using trace_globa
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(-)
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
:
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
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
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
== 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:
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
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
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
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
== 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 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: 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
== 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
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
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
== 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://
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
>
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
== 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:
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
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,
== 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
== 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 : 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
0a86b9f594fb drm/i915/execlists: Track begin/end
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
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
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
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
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
1 - 100 of 139 matches
Mail list logo