== Series Details ==
Series: drm/i915/skl: Fix (most) pipe underruns, properly this time (rev2)
URL : https://patchwork.freedesktop.org/series/10059/
State : failure
== Summary ==
Applying: drm/i915/skl: Update plane watermarks atomically during plane updates
fatal: sha1 information is lacking
== Series Details ==
Series: series starting with [v3,1/3] drm: extra printk() wrapper macros
URL : https://patchwork.freedesktop.org/series/10060/
State : failure
== Summary ==
Series 10060v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10060/revisions/1/mbox
T
Hi all,
We are pleased to announce another update of Intel GVT-g for KVM.
Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with
mediated pass-through, starting from 5th generation Intel Core™ processors with
Intel Graphics processors. A virtual GPU instance is maintaine
On 7/19/2016 4:54 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
This patch provides debugfs interface i915_guc_output_control for
on the fly enabling/disabling of logging in GuC firmware and controlling
the verbosity level of logs.
The valu
On 7/19/2016 4:51 PM, Chris Wilson wrote:
On Tue, Jul 19, 2016 at 12:12:20PM +0100, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
If GuC logs are being captured, there should be a force log buffer flush
action sent to GuC before proceeding wit
On 7/19/2016 5:01 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to
On 7/19/2016 4:28 PM, Tvrtko Ursulin wrote:
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
GuC ukernel sends an interrupt to Host to flush the log buffer
and expects Host to correspondingly update the read pointer
information in the state structure, once it has consu
On Tue, 19 Jul 2016 13:42:54 +0200
Daniel Vetter wrote:
> Unfortunately warnings generated after parsing in sphinx can end up
> with entirely bogus files and line numbers as sources. Strangely for
> outright errors this is not a problem. Trying to convert warnings to
> errors also doesn't fix it.
From: Clint Taylor
Skip decode options and formatting when the quiet option is used during
mmio reads. Makes intel_reg usable by scripts to return MMIO values.
Signed-off-by: Clint Taylor
---
tools/intel_reg.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/inte
Marc kicked me to the other side of the fence. I'm now cheering for the
symbolic links back again.
We cannot block users to use some new firmware version if they
like/want/need.
Also, also as Chris highlighted the hardcoded version doesn't help the
bisect but make it unlikely. I don't believe a
Versioning dependencies isn't exactly a new problem outside the kernel,
so please allow me to share my experience below. Thanks to Rodrigo for
glancing over this email and preventing me from writing anything too
stupid or that was said already.
>> The firmware should be side-ways compatible for
On Tue, Jul 19, 2016 at 07:43:56PM +0100, Dave Gordon wrote:
> On 14/07/16 15:15, Daniel Vetter wrote:
> > I forgot to remove these when reworking the firmware loading sequence
> > last year. The new sequence is that we load firmware, and if it's not
> > there we entirely (and permanently) fail dmc
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
On 14/07/16 15:15, Daniel Vetter wrote:
I forgot to remove these when reworking the firmware loading sequence
last year. The new sequence is that we load firmware, and if it's not
there we entirely (and permanently) fail dmc setup.
Reported-by: Dave Gordon
Signed-off-by: Daniel Vetter
---
dr
On 15/07/16 14:13, Tvrtko Ursulin wrote:
On 29/06/16 17:00, Chris Wilson wrote:
On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote:
On 29/06/16 16:34, Chris Wilson wrote:
On Wed, Jun 29, 2016 at 04:09:31PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Replace per-engine in
On pe, 2016-07-01 at 14:54 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/bxt: Fix performance due to bogus MOCS entry
> URL : https://patchwork.freedesktop.org/series/9377/
> State : warning
>
> == Summary ==
>
> Series 9377v1 drm/i915/bxt: Fix performance due to bogus MO
On Tue, Jul 19, 2016 at 1:19 PM, Matt Roper wrote:
> On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote:
>> Now that we update the watermark values atomically, we still need to fix
>> the case of how we update watermarks when we haven't added or removed
>> pipes.
>>
>> When we haven't added or
On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote:
> Now that we update the watermark values atomically, we still need to fix
> the case of how we update watermarks when we haven't added or removed
> pipes.
>
> When we haven't added or removed any pipes, we don't need to worry about
> the ddb
On Tue, Jul 19, 2016 at 12:30:55PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> va
== Series Details ==
Series: drm/i915/skl: Fix (most) pipe underruns, properly this time
URL : https://patchwork.freedesktop.org/series/10059/
State : failure
== Summary ==
Applying: drm/i915/skl: Update plane watermarks atomically during plane updates
fatal: sha1 information is lacking or use
== Series Details ==
Series: drm: drm_connector->s/connector_id/index/ for consistency (rev2)
URL : https://patchwork.freedesktop.org/series/10029/
State : success
== Summary ==
Series 10029v2 drm: drm_connector->s/connector_id/index/ for consistency
http://patchwork.freedesktop.org/api/1.0/se
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 both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
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()
[Tvrtko Ursulin].
Signed-o
Unfortunately as a few of you are aware, Skylake is still very prone to pipe
underruns. Most of this comes from not doing things atomically enough (e.g.
needing to ensure that we update watermarks with other plane attributes, not
forcefully flushing pipes until we need to, etc.). Now that I've fina
Now that we update the watermark values atomically, we still need to fix
the case of how we update watermarks when we haven't added or removed
pipes.
When we haven't added or removed any pipes, we don't need to worry about
the ddb allocation changing. As such there's no order of flushing pipes
we
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
connector_id in the uapi actually means drm_connector->base.id, which
is something entirely different. And ->index is also consistent with
plane/encoder/CRTCS and the various drm_*_index() functions.
While at it also improve/align the kerneldoc comment.
v2: Mention where those ids are from ...
v
On Tue, Jul 19, 2016 at 04:50:49PM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote:
> > On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote:
> > > num_levels should be level+1, not level, else num_levels - 1 becomes
> > > negative. This resul
On 19/07/16 15:26, Tvrtko Ursulin wrote:
On 19/07/16 13:20, Dave Gordon wrote:
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 :)
Signed-off-by: Dave Go
On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote:
> > num_levels should be level+1, not level, else num_levels - 1 becomes
> > negative. This resulted in bogus watermarks being written to the first
> > 255 levels like
On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter wrote:
> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
> wrote:
>>
>> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>>
>>> Unfortunately warnings generated after parsing in sphinx can end up
>>> with entirely bogus files and line numbers as sources
On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote:
> num_levels should be level+1, not level, else num_levels - 1 becomes
> negative. This resulted in bogus watermarks being written to the first
> 255 levels like below:
>
> [drm] Setting FIFO watermarks - C: plane=0, cursor=0, spri
On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
wrote:
>
> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>
>> Unfortunately warnings generated after parsing in sphinx can end up
>> with entirely bogus files and line numbers as sources. Strangely for
>> outright errors this is not a problem. Trying
num_levels should be level+1, not level, else num_levels - 1 becomes
negative. This resulted in bogus watermarks being written to the first
255 levels like below:
[drm] Setting FIFO watermarks - C: plane=0, cursor=0, sprite0=0, sprite1=0, SR:
plane=0, cursor=0 level=255 cxsr=0
[drm:chv_set_memory
On 19/07/16 16:02, Tvrtko Ursulin wrote:
On 19/07/16 13:59, Dave Gordon wrote:
When using a single GuC client for multiple engines, the i915 driver has
to merge all work items into a single work queue, which the GuC firmware
then demultiplexes into separate submission queues per engine. In
theo
On 19/07/16 13:59, Dave Gordon wrote:
Now that host structures are indexed by host engine-id rather than
guc_id, we can usefully convert some for_each_engine() loops to use
for_each_engine_id() and avoid multiple dereferences of engine->id.
Also a few related tweaks to cache structure members l
On 19/07/16 13:59, Dave Gordon wrote:
When using a single GuC client for multiple engines, the i915 driver has
to merge all work items into a single work queue, which the GuC firmware
then demultiplexes into separate submission queues per engine. In
theory, this could lead to the single queue be
On 19/07/16 15:16, Patchwork wrote:
== Series Details ==
Series: series starting with [1/5] drm/i915/guc: doorbell reset should avoid
used doorbells
URL : https://patchwork.freedesktop.org/series/10040/
State : failure
== Summary ==
Series 10040v1 Series without cover letter
http://patchwor
On 19/07/16 13:59, Dave Gordon wrote:
The Context Descriptor passed by the kernel to the GuC contains a field
specifying which engine(s) the context will use. Historically, this was
always set to "all of them", but now that we have one client per engine,
we can be more precise, and set only the
On 19/07/16 13:59, Dave Gordon wrote:
Commit message missing! :)
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/driv
On 19/07/16 13:59, Dave Gordon wrote:
guc_init_doorbell_hw() borrows the (currently single) GuC client to use
in reinitialising ALL the doorbell registers (as the hardware doesn't
reset them when the GuC is reset). As a prerequisite for accommodating
multiple clients, it should only reset doorbe
On 19/07/16 14:53, Patchwork wrote:
== Series Details ==
Series: series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros
URL : https://patchwork.freedesktop.org/series/10036/
State : success
== Summary ==
Series 10036v1 Series without cover letter
http://patchwork.freedesktop
On Tue, Jul 19, 2016 at 05:12:22PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> > + resv = i915_gem_object_get_dmabuf_resv(obj);
> > + if (resv) {
> > + long err;
>
> We already have ret in the function scope.
ret is int, we need a long. At
On Tue, Jul 19, 2016 at 09:28:34AM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> > On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > > Even after adding individual page support for GTT mmaping, we can still
> > > fail to find any space
On Tue, Jul 19, 2016 at 12:42:36PM +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
> > > Signed-off-by: Lionel Landwerlin
> >
> > Do we have the time for those in the BAT budget?
>
On 19/07/16 13:20, Dave Gordon wrote:
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 :)
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_guc
On 19/07/16 08:05, Daniel Vetter wrote:
On Mon, Jul 04, 2016 at 11:30:06AM -0400, Jeff Mahoney wrote:
This fixes the following build error with -Werror and gcc 6.1:
drivers/gpu/drm/i915/i915_debugfs.c:2103:6: error: suggest explicit braces to
avoid ambiguous 'else' [-Werror=parentheses]
Signe
On 19/07/16 13:20, Dave Gordon wrote:
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
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 in
== Series Details ==
Series: series starting with [1/5] drm/i915/guc: doorbell reset should avoid
used doorbells
URL : https://patchwork.freedesktop.org/series/10040/
State : failure
== Summary ==
Series 10040v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10040
On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> When transitioning to the GTT or CPU domain we wait on all rendering
> from i915 to complete (with the optimisation of allowing concurrent read
> access by both the GPU and client). We don't yet ensure all rendering
> from third parties (track
On Fri, 2016-07-15 at 14:15 +0300, Ander Conselvan De Oliveira wrote:
> On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> >
> > This is the only time PIPE_ANY was used to mean something other than
> > unassign this output from a pipe. Without this PIPE_ANY can be aliased
> > to PIPE_NO
We only enable pipe A tests and basic size fuzzing tests to minimize
the amount of time spend. From experience color management issues
tends to trigger failures on all pipes so only testing one seems
reasonable.
Signed-off-by: Lionel Landwerlin
---
tests/kms_pipe_color.c | 37 +++
== Series Details ==
Series: series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros
URL : https://patchwork.freedesktop.org/series/10036/
State : success
== Summary ==
Series 10036v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10036/revisions/1/
On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> A foreign dma-buf does not share our cache domain tracking, and we rely
> on the producer ensuring cache coherency. Marking them as being in the
> CPU domain is incorrect.
>
> Signed-off-by: Chris Wilson
Maybe even add a comment above the a
On 19/07/16 13:49, Chris Wilson wrote:
On Tue, Jul 19, 2016 at 01:21:23PM +0100, Lionel Landwerlin wrote:
On 19/07/16 12:42, Chris Wilson wrote:
On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
Signed-off-by: Lio
Now that host structures are indexed by host engine-id rather than
guc_id, we can usefully convert some for_each_engine() loops to use
for_each_engine_id() and avoid multiple dereferences of engine->id.
Also a few related tweaks to cache structure members locally wherever
they're used more than on
When using a single GuC client for multiple engines, the i915 driver has
to merge all work items into a single work queue, which the GuC firmware
then demultiplexes into separate submission queues per engine. In
theory, this could lead to the single queue becoming a bottleneck in
which an excess of
The Context Descriptor passed by the kernel to the GuC contains a field
specifying which engine(s) the context will use. Historically, this was
always set to "all of them", but now that we have one client per engine,
we can be more precise, and set only the single bit for the engine that
the client
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d8402e4..dc5f485 100644
---
guc_init_doorbell_hw() borrows the (currently single) GuC client to use
in reinitialising ALL the doorbell registers (as the hardware doesn't
reset them when the GuC is reset). As a prerequisite for accommodating
multiple clients, it should only reset doorbells that are supposed to be
disabled, avo
Hey,
Op 13-07-16 om 14:13 schreef Daniel Vetter:
> On Wed, Jul 06, 2016 at 11:55:41AM +0200, Maarten Lankhorst wrote:
>> This is the same as using config.pipe because the order of crtcs will
>> never change.
>>
>> Signed-off-by: Maarten Lankhorst
> In the interest of generic igt, I'm somewhat inc
connector_id in the uapi actually means drm_connector->base.id, which
is something entirely different. And ->index is also consistent with
plane/encoder/CRTCS and the various drm_*_index() functions.
While at it also improve/align the kerneldoc comment.
v2: Mention where those ids are from ...
v
On Tue, Jul 19, 2016 at 01:21:23PM +0100, Lionel Landwerlin wrote:
> On 19/07/16 12:42, Chris Wilson wrote:
> >On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
> >>On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
> >>>Signed-off-by: Lionel Landwerlin
> >>Do we have
On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
> These are the leftovers I could only track down using keep_warnings =
> True. For some of them we might want to update our style guide on how
> to reference structures and constants, not sure ...
>
> Cc: Markus Heiser
> Cc: Jonathan
On 19/07/16 12:42, Chris Wilson wrote:
On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
Signed-off-by: Lionel Landwerlin
Do we have the time for those in the BAT budget?
Do we not? It has been demonstrated that
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
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/
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 :)
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_guc_loader.c | 34 ---
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 both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
On Tue, Jul 19, 2016 at 12:57:52PM +0200, Daniel Vetter wrote:
> connector_id in the uapi actually means drm_connector->base.id, which
> is something entirely different. And ->index is also consistent with
> plane/encoder/CRTCS and the various drm_*_index() functions.
>
> While at it also improve/
On Tue, Jul 19, 2016 at 12:57:52PM +0200, Daniel Vetter wrote:
> connector_id in the uapi actually means drm_connector->base.id, which
> is something entirely different. And ->index is also consistent with
> plane/encoder/CRTCS and the various drm_*_index() functions.
>
> While at it also improve/
== Series Details ==
Series: series starting with [1/2] doc/sphinx: Enable keep_warnings
URL : https://patchwork.freedesktop.org/series/10033/
State : failure
== Summary ==
Applying: doc/sphinx: Enable keep_warnings
Applying: drm/doc: Fix more kerneldoc/sphinx warnings
fatal: sha1 information
== Series Details ==
Series: drm: drm_connector->s/connector_id/index/ for consistency
URL : https://patchwork.freedesktop.org/series/10029/
State : failure
== Summary ==
Series 10029v1 drm: drm_connector->s/connector_id/index/ for consistency
http://patchwork.freedesktop.org/api/1.0/series/10
On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote:
> > Signed-off-by: Lionel Landwerlin
>
> Do we have the time for those in the BAT budget?
Do we not? It has been demonstrated that people notice when gamma is
broke
Unfortunately warnings generated after parsing in sphinx can end up
with entirely bogus files and line numbers as sources. Strangely for
outright errors this is not a problem. Trying to convert warnings to
errors also doesn't fix it.
The only way to get useful output out of sphinx to be able to ro
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
d
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Akash Goel
Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to just use a relay API to store
snapshots of the
== Series Details ==
Series: series starting with [1/8] drm/i915: Move GEM request routines to
i915_gem_request.c
URL : https://patchwork.freedesktop.org/series/10028/
State : failure
== Summary ==
Series 10028v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/1002
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
This patch provides debugfs interface i915_guc_output_control for
on the fly enabling/disabling of logging in GuC firmware and controlling
the verbosity level of logs.
The value written to the file, should have bit 0 set to
On Tue, Jul 19, 2016 at 12:12:20PM +0100, Tvrtko Ursulin wrote:
>
> On 10/07/16 14:41, akash.g...@intel.com wrote:
> >From: Sagar Arun Kamble
> >
> >If GuC logs are being captured, there should be a force log buffer flush
> >action sent to GuC before proceeding with GPU reset and re-initializing
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
If GuC logs are being captured, there should be a force log buffer flush
action sent to GuC before proceeding with GPU reset and re-initializing
GUC. Those logs would be useful to understand why the GPU reset was
initiated.
On 10/07/16 14:41, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
GuC ukernel sends an interrupt to Host to flush the log buffer
and expects Host to correspondingly update the read pointer
information in the state structure, once it has consumed the
log buffer contents by copying them to
connector_id in the uapi actually means drm_connector->base.id, which
is something entirely different. And ->index is also consistent with
plane/encoder/CRTCS and the various drm_*_index() functions.
While at it also improve/align the kerneldoc comment.
v2: Mention where those ids are from ...
C
A foreign dma-buf does not share our cache domain tracking, and we rely
on the producer ensuring cache coherency. Marking them as being in the
CPU domain is incorrect.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dri
When transitioning to the GTT or CPU domain we wait on all rendering
from i915 to complete (with the optimisation of allowing concurrent read
access by both the GPU and client). We don't yet ensure all rendering
from third parties (tracked by implicit fences on the dma-buf) is
complete. Since impli
Following a GPU reset upon hang, we retire all the requests and then
mark them all as complete. If we mark them as complete first, we both
keep the normal retirement order (completed first then retired) and
provide a small optimisation for concurrent lookups.
Signed-off-by: Chris Wilson
Reviewed-
In order to keep the memory allocated for requests reasonably tight, try
to reuse the oldest request (so long as it is completed and has no
external references) for the next allocation.
v2: Throw in a comment to hopefully make sure no one mistakes the
optimistic retirement of the oldest request fo
We want to restrict waitboosting to known process contexts, where we can
track which clients are receiving waitboosts and prevent excessive power
wasting. For fence_wait() we do not have any client tracking and so that
leaves it open to abuse.
v2: Hide the IS_ERR_OR_NULL testing for special client
Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw
sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio
flip RPS boosts") we have limited the waitboosting for semaphores and
flips. Ideally we do not want to boost in either of these instances as no
userspace cons
dma-buf provides a generic fence class for interoperation between
drivers. Internally we use the request structure as a fence, and so with
only a little bit of interfacing we can rebase those requests on top of
dma-buf fences. This will allow us, in the future, to pass those fences
back to userspac
Migrate the request operations out of the main body of i915_gem.c and
into their own C file for easier expansion.
v2: Move __i915_add_request() across as well
Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/Makefile | 1 +
On 18/07/16 16:06, Tvrtko Ursulin wrote:
On 18/07/16 14:46, Tvrtko Ursulin wrote:
[snip]
This version generates the smallest code:
static void __memcpy_ntdqa(struct qw2 *dst, const struct qw2 *src, unsigned
long len)
{
unsigned long l4;
kernel_fpu_begin();
l4 = len
On some platforms the MOCS values are not always saved and restored
on RC6 enter/exit. The rational is that the context with restore
these values. On these platforms the test will fail as it tests the
values by directly reading the MOCS registers.
So this change removes the direct testing of the v
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Kamble, Sagar A
> Sent: Tuesday, July 19, 2016 7:56 AM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915:gen9: restrict
> W
On Fri, Jul 15, 2016 at 09:47:58PM +0200, Daniel Vetter wrote:
> Right now there's nothing, and kernel-doc produces a warning because
> of that. Remove it until we need it for a clean build.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Pulled in the entire pile with Chris' irc-ack, a
On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > Even after adding individual page support for GTT mmaping, we can still
> > fail to find any space within the mappable region, and
> > drm_mm_insert_node() will then re
== Series Details ==
Series: drm/i915: Simplify shrinker_lock
URL : https://patchwork.freedesktop.org/series/10016/
State : failure
== Summary ==
Series 10016v1 drm/i915: Simplify shrinker_lock
http://patchwork.freedesktop.org/api/1.0/series/10016/revisions/1/mbox
Test gem_exec_gttfill:
On Fri, Jul 15, 2016 at 09:03:40AM +0100, Dave Gordon wrote:
> On 14/07/16 15:03, Chris Wilson wrote:
> >On Thu, Jul 14, 2016 at 02:12:55PM +0100, Dave Gordon wrote:
> >>On 13/07/16 13:44, Chris Wilson wrote:
> >>>On Wed, Jul 13, 2016 at 02:38:16PM +0200, Daniel Vetter wrote:
> On Thu, Jun 30,
On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote:
> > Even after adding individual page support for GTT mmaping, we can still
> > fail to find any space within the mappable region, and
> > drm_mm_insert_node() will then re
On Fri, Jul 15, 2016 at 09:52:27AM +0100, Dave Gordon wrote:
> On 15/07/16 09:15, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [CI,resend,1/2] drm/i915: compile-time
> > consistency check on __EXEC_OBJECT flags
> > URL : https://patchwork.freedesktop.org/series
1 - 100 of 102 matches
Mail list logo
