IRC acked-by: Daniel Vetter
On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> Storing the port enum in intel_encoder makes it convenient to know the
> port attached to an encoder. Moving the port information up from
> intel_digital_port to intel_encoder avoids unecessary intel_digit
== Series Details ==
Series: drm/i915/skl: Don't try to update plane watermarks if they haven't
changed
URL : https://patchwork.freedesktop.org/series/11654/
State : success
== Summary ==
Series 11654v1 drm/i915/skl: Don't try to update plane watermarks if they
haven't changed
http://patchwo
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
On Fri, Aug 26, 2016 at 08:46:25PM +0100, Dave Gordon wrote:
> @@ -1520,6 +1528,14 @@ static void eb_export_fence(struct drm_i915_gem_object
> *obj,
> if (ret)
> return ret;
>
> + if (instp_mode != I915_EXEC_CONSTANTS_REL_GENERAL) {
> + /* Restore default valu
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync
On 26/08/16 19:47, Chris Wilson wrote:
On Fri, Aug 26, 2016 at 07:25:57PM +0100, Dave Gordon wrote:
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically rest
On Fri, Aug 26, 2016 at 07:47:19PM +0100, Chris Wilson wrote:
> On Fri, Aug 26, 2016 at 07:25:57PM +0100, Dave Gordon wrote:
> > 'relative_constants_mode' has always been tracked per-device, but this
> > has actually been wrong ever since hardware contexts were introduced, as
> > the INSTPM registe
== Series Details ==
Series: Reclassify messages from GuC loader/submission (rev5)
URL : https://patchwork.freedesktop.org/series/10918/
State : warning
== Summary ==
Series 10918v5 Reclassify messages from GuC loader/submission
http://patchwork.freedesktop.org/api/1.0/series/10918/revisions/5
On Fri, Aug 26, 2016 at 07:25:57PM +0100, Dave Gordon wrote:
> 'relative_constants_mode' has always been tracked per-device, but this
> has actually been wrong ever since hardware contexts were introduced, as
> the INSTPM register is saved (and automatically restored) as part of the
> render ring c
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync
== Series Details ==
Series: drm/i915/guc: use symbolic names for module parameter values (rev4)
URL : https://patchwork.freedesktop.org/series/10188/
State : success
== Summary ==
Series 10188v4 drm/i915/guc: use symbolic names for module parameter values
http://patchwork.freedesktop.org/api/
On Fri, Aug 26, 2016 at 06:50:56PM +0100, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
> provides several other useful intermediate levels such as NOTICE and
> WARNING. So this patch fills out the set by providing simple macros for
> the additional le
Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.
v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()
Signed-off-by: Dave Gordon
Reviewed-b
Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. As general principles:
* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or m
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 insertions(+), 1
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing simple macros for
the additional levels. We don't provide _DEV_ or _ONCE or RATELIMITED
versions yet as
Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
drivers/gpu/drm/i9
The existing code that accesses the "guc_log_level" parameter
uses an explicit numerical value for the "no logging" case,
whereas there are symbolic names for the other levels.
So this patch just provides and uses a name for the default log
level (NONE), with the same numeric value that is already
Previously the code allowed *any* values for the enable_guc_loading and
enable_guc_submission parameters, and forced them into range by clipping
at each extremum. This version instead ignores unknown values, treating
them as DEFAULT (which then gets converted to DISABLED or PREFERRED).
Of course w
Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
Cc: Jani Nikula
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_params.c | 10 +-
The existing code that accesses the "enable_guc_loading"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean
0/1 mapping to specific values (which could be confusing
for maintainers).
So this patch just provides and uses names for the v
The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).
So this patch just provides and uses names for the
There are various literal constants used in the GuC module-parameter
processing code; this sequence of patches replaces them with symbolic
names for greater clarity.
And then it re-enables GuC submission by default :)
v3:
Original patch broken into two (1/4 + 2/4)
Name for GuC log level NONE
On Fri, Aug 26, 2016 at 11:19:56AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to SNB
> URL : https://patchwork.freedesktop.org/series/11607/
> State : success
>
> == Summary ==
>
> Series 11607v1 drm/i915: Add GEN7_P
On Fri, Aug 26, 2016 at 02:39:01PM +0100, John Harrison wrote:
> On 25/08/2016 10:08, Chris Wilson wrote:
> >Now that we have fences in place to drive request submission, we can
> >employ those to queue requests after their dependencies as opposed to
> >stalling in the middle of an execbuf ioctl. (
On Fri, Aug 26, 2016 at 01:47:50PM +0100, John Harrison wrote:
> On 25/08/2016 10:08, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 5e60519ede8d..babeaa8b1273 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu
On Fri, Aug 26, 2016 at 04:29:57PM +0100, John Harrison wrote:
> On 26/08/2016 16:08, John Harrison wrote:
> >On 25/08/2016 10:08, Chris Wilson wrote:
> >>Now that the user can opt-out of implicit fencing, we need to give them
> >>back control over the fencing. We employ sync_file to wrap our
> >>d
On 26/08/2016 16:08, John Harrison wrote:
On 25/08/2016 10:08, Chris Wilson wrote:
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other syn
On 25/08/2016 10:08, Chris Wilson wrote:
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to w
Regards
Shashank
On 8/25/2016 8:59 PM, Imre Deak wrote:
Hi,
On ti, 2016-08-16 at 22:17 +0530, Shashank Sharma wrote:
LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.
These modes are:
- Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi
passive dongl
On 25/08/2016 10:08, Chris Wilson wrote:
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.
Testcase: igt/prime_vgem/fence-wait
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_g
On 25/08/2016 10:08, Chris Wilson wrote:
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is fast
On 25/08/2016 10:08, Chris Wilson wrote:
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in t
On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> We seem to have an xrandr regression with skylake now. What's
> happening is that I can get output on to a projector, but the system
> is losing video when I change the xrandr sessions (like going from a
> --above b to a --same-as b).
We seem to have an xrandr regression with skylake now. What's
happening is that I can get output on to a projector, but the system is
losing video when I change the xrandr sessions (like going from a -
-above b to a --same-as b). The main screen goes blank, which is
basically a reboot situation.
Signed-off-by: Jani Nikula
---
dim | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dim b/dim
index 301f7c8b0f8e..2a2cd9e27e0c 100755
--- a/dim
+++ b/dim
@@ -1238,9 +1238,9 @@ function dim_fixes
local tag=$(git tag --contains $1 | grep ^v | sort -V | head -n 1)
On Fri, Aug 26, 2016 at 01:38:26PM +0100, Chris Wilson wrote:
> On Fri, Aug 26, 2016 at 02:29:41PM +0200, David Weinehall wrote:
> > On Thu, Aug 25, 2016 at 04:32:41PM +0100, Chris Wilson wrote:
> > [snip]
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > > b/drivers/gpu/drm/i915/i915
On 25/08/2016 10:08, Chris Wilson wrote:
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, s
On Fri, Aug 26, 2016 at 02:29:41PM +0200, David Weinehall wrote:
> On Thu, Aug 25, 2016 at 04:32:41PM +0100, Chris Wilson wrote:
> [snip]
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 3c97f0e7a003..c618bb86aeb9 100644
> > --- a/dri
On Thu, Aug 25, 2016 at 04:32:41PM +0100, Chris Wilson wrote:
[snip]
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 3c97f0e7a003..c618bb86aeb9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_co
On Thu, Aug 25, 2016 at 11:07:01AM +0200, Maarten Lankhorst wrote:
> The mentioned commit changes intel_display_crc_init to take a dev_priv,
> but forgets to change the stub.
Doh!
>
> Cc: David Weinehall
> Fixes: 36cdd0138b7f ("drm/i915: debugfs spring cleaning")
> Signed-off-by: Maarten Lankho
On Thu, 25 Aug 2016, Paolo Stivanin wrote:
> Hello,
> I applied these patches[1][2] to the latest kernel revision (
> 4.8.0-rc3-g61c0457) but the brightness keys are not working on my
> laptop.
> With the older patches from the 29th of June the brightness keys were
> working correctly.
Maarten, a
On Fri, Aug 26, 2016 at 08:10:24AM +0100, Chris Wilson wrote:
> static void i915_gem_reset_engine_cleanup(struct intel_engine_cs *engine)
> {
> struct drm_i915_gem_request *request;
> + unsigned long flags;
> struct intel_ring *ring;
>
> + /* Ensure irq handler finishes or i
On 08/24/2016 12:42 PM, Chris Wilson wrote:
> From about kernel 4.9, GTT mmaps are virtually unlimited. A new
> parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
> feature so query it and use it to avoid limiting tiled allocations to
> only fit within the mappable aperture.
>
> Sig
On 08/24/2016 11:35 PM, Xiang, Haihao wrote:
-Original Message-
From: Randy Li [mailto:randy...@rock-chips.com]
Sent: Wednesday, August 24, 2016 6:30 PM
To: Xiang, Haihao ; li...@lists.freedesktop.org
Cc: nicolas.dufre...@collabora.co.uk; Balachandran, Sreerenj
Subject: Re: I want to
Hello,
I applied these patches[1][2] to the latest kernel revision (
4.8.0-rc3-g61c0457) but the brightness keys are not working on my
laptop.
With the older patches from the 29th of June the brightness keys were
working correctly.
Cheers,
[1] https://patchwork.freedesktop.org/patch/107280/
[2] h
On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > Takashi Iwai wrote:
> > > > I had to modify the intel_gpu_reset() call because
== Series Details ==
Series: drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to SNB
URL : https://patchwork.freedesktop.org/series/11607/
State : success
== Summary ==
Series 11607v1 drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to
SNB
http://patchwork.freedeskto
On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > On Fri, 26 Aug 2016 11:18:00 +0200,
> > Takashi Iwai wrote:
> > > I had to modify the intel_gpu_reset() call because the test was done
> > > on the older kernel, so it's like:
>
According to the CI test machines, SNB also uses the
GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
GEN6_PCODE_MIN_FREQ_TABLE request.
[ 157.744641] WARNING: CPU: 5 PID: 9238 at
drivers/gpu/drm/i915/intel_pm.c:7760 sandybridge_pcode_write+0x141/0x200 [i915]
[ 157.744642] M
On Fri, Aug 26, 2016 at 01:43:42PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Fri, Aug 26, 2016 at 12:41:16PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson writes:
> >>
> >> > Leave the more complicated request dequeueing to the tasklet and instead
> >> > just kick start the ta
Chris Wilson writes:
> On Fri, Aug 26, 2016 at 12:41:16PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > Leave the more complicated request dequeueing to the tasklet and instead
>> > just kick start the tasklet if we detect we are adding the first
>> > request.
>> >
>> > Signed-off
On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> On Fri, 26 Aug 2016 11:18:00 +0200,
> Takashi Iwai wrote:
> > I had to modify the intel_gpu_reset() call because the test was done
> > on the older kernel, so it's like:
> >
> > + intel_gpu_reset(dev_to_i915(dev)->dev);
> >
> >
On Fri, 26 Aug 2016 11:18:00 +0200,
Takashi Iwai wrote:
>
> On Thu, 25 Aug 2016 18:15:37 +0200,
> Takashi Iwai wrote:
> >
> > On Thu, 25 Aug 2016 18:12:19 +0200,
> > Chris Wilson wrote:
> > >
> > > > Maybe But it's hard to tell exactly whether this is
> > > > the 100% culprit. As said, there ha
On Fri, Aug 26, 2016 at 12:41:16PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Leave the more complicated request dequeueing to the tasklet and instead
> > just kick start the tasklet if we detect we are adding the first
> > request.
> >
> > Signed-off-by: Chris Wilson
> > ---
> >
On Fri, Aug 26, 2016 at 12:41:16PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Leave the more complicated request dequeueing to the tasklet and instead
> > just kick start the tasklet if we detect we are adding the first
> > request.
> >
> > Signed-off-by: Chris Wilson
> > ---
> >
Chris Wilson writes:
> Leave the more complicated request dequeueing to the tasklet and instead
> just kick start the tasklet if we detect we are adding the first
> request.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 28
> 1 file chan
On Thu, 25 Aug 2016 18:15:37 +0200,
Takashi Iwai wrote:
>
> On Thu, 25 Aug 2016 18:12:19 +0200,
> Chris Wilson wrote:
> >
> > > Maybe But it's hard to tell exactly whether this is
> > > the 100% culprit. As said, there have been multiple S4 bugs, so far.
> > > IVY worked without this patch (afte
Chris Wilson writes:
> Adding to the tail of the client request list as the only other user is
> in the throttle ioctl that iterates forwards over the list. It only
> needs protection against deletion of a request as it reads it, it simply
> won't see a new request added to the end of the list, o
On Tue, Aug 23, 2016 at 12:23:56PM +0300, David Weinehall wrote:
> The eDP backlight and panel enable/disable delays are quite
> useful to know when measuring time consumed by suspend/resume,
> and while the information is printed to the kernel log as debug
> messages, having this information in de
== Series Details ==
Series: drm/i915: Add a debugfs file to dump complete context
URL : https://patchwork.freedesktop.org/series/11568/
State : warning
== Summary ==
Series 11568v1 drm/i915: Add a debugfs file to dump complete context
http://patchwork.freedesktop.org/api/1.0/series/11568/revi
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)
Signed-off-by: C
Rather than blindly assuming we need to advance the tail for
resubmitting the request via the ELSP, record the position.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_request.h | 15 +--
drivers/gpu/drm/i915/intel_lrc.c| 4 ++--
2
Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.
The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
I spent some time with Mika yesterday working through the comments,
trying to improve what I could, so here goes!
Also available at
https://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=eb-fence
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
Emulate HW to track and manage ELSP queue. A set of SW ports are defined
and requests are assigned to these ports before submitting them to HW. This
helps in cleaning up incomplete requests during reset recovery easier
especially after engine reset by decoupling elsp queue management. This
will bec
Leave the more complicated request dequeueing to the tasklet and instead
just kick start the tasklet if we detect we are adding the first
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
This is really a core kernel struct in disguise until we can finally
place it in kernel/. There is an immediate need for a fence collection
mechanism that is more flexible than fence-array, in particular being
able to easily drive request submission via events (and not just
interrupt driven). The s
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, so the callback is
immediate.
A side-effect
Just rearrange the code to reduce churn in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 76
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
Similar to the issue with reading from the context status buffer,
see commit 26720ab97fea, we frequently write to the ELSP register (4
writes per interrupt) and know we hold the required spinlock and
forcewake throughout. We can further reduce the cost of writing these
registers beyond the I915_WRI
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in the near future.
Signed-off-by: Chris Wilso
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.
Testcase: igt/prime_vgem/fence-wait
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
1 file cha
75 matches
Mail list logo
