== Series Details ==
Series: drm/i915: intel_dp_link_is_valid() should only return status of link
(rev3)
URL : https://patchwork.freedesktop.org/series/9737/
State : failure
== Summary ==
Series 9737v3 drm/i915: intel_dp_link_is_valid() should only return status of
link
http://patchwork.free
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/mst: Validate modes against
available link bandwidth
URL : https://patchwork.freedesktop.org/series/11039/
State : failure
== Summary ==
Series 11039v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/seri
== Series Details ==
Series: drm/i915: Embrace the race in busy-ioctl
URL : https://patchwork.freedesktop.org/series/11034/
State : failure
== Summary ==
Series 11034v1 drm/i915: Embrace the race in busy-ioctl
http://patchwork.freedesktop.org/api/1.0/series/11034/revisions/1/mbox
Test kms_cur
Intel_dp_link_is_valid() function reads the Link status registers
and returns a boolean to indicate link is valid or not.
If the link has lost lock and is not valid any more, link
training is performed outside the function else previously trained link
is retained.
This gives us flexibility of check
On Sat, 2016-08-13 at 00:16 +, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-08-12 at 08:18 +0300, Ville Syrjälä wrote:
> > On Fri, Aug 12, 2016 at 04:28:09AM +, Pandiyan, Dhinakaran wrote:
> > > On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> > > > On Thu, Aug 11, 2016 at 07:10:39AM
On Fri, Aug 12, 2016 at 02:50:58PM -0700, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-08-12 at 10:56 -0700, Manasi Navare wrote:
> > On Thu, Aug 11, 2016 at 08:18:54PM -0700, Pandiyan, Dhinakaran wrote:
> > > On Thu, 2016-08-11 at 15:23 -0700, Manasi Navare wrote:
> > > > Intel_dp_link_is_valid() fu
On Fri, 2016-08-12 at 08:18 +0300, Ville Syrjälä wrote:
> On Fri, Aug 12, 2016 at 04:28:09AM +, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 11, 2016 at 07:10:39AM +, Pandiyan, Dhinakaran wrote:
> > > > On Thu, 2016-08-11 at 09:26
On Fri, 2016-06-10 at 22:18 -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FBC would cause the
> underruns to give black screens.
On Fri, 2016-08-12 at 10:56 -0700, Manasi Navare wrote:
> On Thu, Aug 11, 2016 at 08:18:54PM -0700, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-08-11 at 15:23 -0700, Manasi Navare wrote:
> > > Intel_dp_link_is_valid() function reads the Link status registers
> > > and returns a boolean to indicate
Hi Anusha,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.8-rc1 next-20160812]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Anusha-Srivatsa/drm-i915-mst-Validate-modes
Add a function that returns the available link bandwidth for
MST port so that we can accurately determine whether a new
mode is valid for the link or not.
v2: Put the Signed-off to the end of commit message
Cc: dri-de...@lists.freedesktop.org
Cc: dhinakaran.pandi...@intel.com
Signed-off-by: Anus
Validate the modes against available link bandwidth rather than
maximum link bandwidth so that we have a better idea as to whether
a proposed mode can truly run beside existing stream.
v2: Put the Signed-off to the end of the commit message
Cc: dhinakaran.pandi...@intel.com
Signed-off-by: Anusha
On Wed, Aug 10, 2016 at 06:15:56PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 09, 2016 at 03:41:23PM +0200, Daniel Vetter wrote:
> > - Move the intro section into a DOC comment, and update it slightly.
> > - kernel-doc for struct drm_framebuffer!
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > D
On Wed, Aug 10, 2016 at 10:48:20AM -0400, Sean Paul wrote:
> On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> >
> > -/**
> > - * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
> > - * @dev: DRM device whose CRTCs to turn off
> > - *
> > - * Drivers may want to call this on
On 12 August 2016 at 18:58, Chris Wilson wrote:
> On Fri, Aug 12, 2016 at 06:42:30PM +0100, Matthew Auld wrote:
>> > -#define STD_MI_OPCODE_MASK 0xFF80
>> > -#define STD_3D_OPCODE_MASK 0x
>> > -#define STD_2D_OPCODE_MASK 0xFFC0
>> > -#define STD_MFX_OPCODE_MASK 0x
>> > +
On Fri, Aug 12, 2016 at 08:25:43PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote:
> > If my upcoming testing of the two changes together pans out, I will
> > give you a Tested-by -- I am guessing that you don't want to wait
> > until the next merge
On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote:
> If my upcoming testing of the two changes together pans out, I will
> give you a Tested-by -- I am guessing that you don't want to wait
> until the next merge window for these changes.
I was planning to stuff them in tip/locking/u
On Fri, Aug 12, 2016 at 06:42:30PM +0100, Matthew Auld wrote:
> > -#define STD_MI_OPCODE_MASK 0xFF80
> > -#define STD_3D_OPCODE_MASK 0x
> > -#define STD_2D_OPCODE_MASK 0xFFC0
> > -#define STD_MFX_OPCODE_MASK 0x
> > +#define STD_MI_OPCODE_SHIFT (32 - 9)
> > +#define STD_3
Daniel Vetter proposed a new challenge to the serialisation inside the
busy-ioctl that exposed a flaw that could result in us reporting the
wrong engine as being busy. If the request is reallocated as we test
its busyness and then reassigned to this object by another thread, we
would not notice tha
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Aug 11, 2016 at 08:18:54PM -0700, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-08-11 at 15:23 -0700, Manasi Navare wrote:
> > Intel_dp_link_is_valid() function reads the Link status registers
> > and returns a boolean to indicate link is valid or not.
> > If the link has lost lock and is not
> -#define STD_MI_OPCODE_MASK 0xFF80
> -#define STD_3D_OPCODE_MASK 0x
> -#define STD_2D_OPCODE_MASK 0xFFC0
> -#define STD_MFX_OPCODE_MASK 0x
> +#define STD_MI_OPCODE_SHIFT (32 - 9)
> +#define STD_3D_OPCODE_SHIFT (32 - 16)
> +#define STD_2D_OPCODE_SHIFT (32 - 10)
> +#de
Hi Dave,
- more fence destaging and cleanup (Gustavo&Sumit)
- DRIVER_LEGACY to untangle from DRIVER_MODESET
- drm_mm refactor (Chris)
- fbdev-less compile fies
- clipped plane src/dst rects (Ville)
- + a few mediatek patches that build on top of that (Bibby+Daniel)
- small stuff all over really
C
Hi Dave,
drm-intel-next-2016-08-08:
- refactor ddi buffer programming a bit (Ville)
- large-scale renaming to untangle naming in the gem code (Chris)
- rework vma/active tracking for accurately reaping idle mappings of shared
objects (Chris)
- misc dp sst/mst probing corner case fixes (Ville)
-
On 8/12/2016 9:27 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, 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 8/12/2016 8:46 PM, Chris Wilson wrote:
On Fri, Aug 12, 2016 at 08:43:58PM +0530, Goel, Akash wrote:
On 8/12/2016 4:19 PM, Tvrtko Ursulin wrote:
Unreleated and unmentioned change to no guard page. Best to remove IMHO.
Can keep the RB in that case.
Though its not called out, sorry for that
On 8/12/2016 9:52 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is
done
at the end and so the relay channel debugfs file is also created after
that
but the GuC firmware is loaded m
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver
On 8/12/2016 7:37 PM, Tvrtko Ursulin wrote:
On 12/08/16 14:45, Goel, Akash wrote:
On 8/12/2016 6:47 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, 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 corres
On 8/12/2016 7:23 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, 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 Fri, Aug 12, 2016 at 09:34:23PM +0530, Goel, Akash wrote:
>
>
> On 8/12/2016 9:22 PM, Chris Wilson wrote:
> >On Fri, Aug 12, 2016 at 09:16:03PM +0530, Goel, Akash wrote:
> >>On 8/12/2016 9:02 PM, Chris Wilson wrote:
> >>>There's (or will be) a function to dump the error object in a uniform
> >
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
In order to have fast reads from the GuC log buffer, used SSE4.1 movntdqa
based memcpy function i915_memcpy_from_wc.
GuC log buffer has a WC type vmalloc mapping and copying using movntqda from
WC type memory is almost as fast as
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
Host needs to sample the GuC log buffer on every flush interrupt from GuC.
To ensure that we always get the up-to-date data from log buffer, its
better to access the buffer through an uncached CPU mapping. Also the way
buffer is a
On 8/12/2016 9:22 PM, Chris Wilson wrote:
On Fri, Aug 12, 2016 at 09:16:03PM +0530, Goel, Akash wrote:
On 8/12/2016 9:02 PM, Chris Wilson wrote:
There's (or will be) a function to dump the error object in a uniform
manner. This patch is obsolete.
There is a print_error_obj() function, but t
On 12 August 2016 at 16:07, Chris Wilson wrote:
> A signifcant proportion of the cmdparsing time for some batches is the
> cost to find the register in the mmiotable. We ensure that those tables
> are in ascending order such that we could do a binary search if it was
> ever merited. It is.
>
> Sig
On Thu, Aug 11, 2016 at 04:33:32PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 02:32:44PM +0300, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 22/07/16 16:43, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > The global mode_config.rotation_property is going away, s
On 12/08/16 07:25, 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 Fri, Aug 12, 2016 at 09:16:03PM +0530, Goel, Akash wrote:
> On 8/12/2016 9:02 PM, Chris Wilson wrote:
> >There's (or will be) a function to dump the error object in a uniform
> >manner. This patch is obsolete.
>
> There is a print_error_obj() function, but that prints one dword per line.
It us
On 8/12/2016 9:02 PM, Chris Wilson wrote:
On Fri, Aug 12, 2016 at 04:20:03PM +0100, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determin
== Series Details ==
Series: series starting with [1/9] drm/i915/cmdparser: Make initialisation
failure non-fatal
URL : https://patchwork.freedesktop.org/series/11031/
State : failure
== Summary ==
Applying: drm/i915/cmdparser: Make initialisation failure non-fatal
fatal: sha1 information is
On 8/12/2016 8:35 PM, Tvrtko Ursulin wrote:
On 12/08/16 15:31, Goel, Akash wrote:
On 8/12/2016 7:01 PM, Tvrtko Ursulin wrote:
+static void gen9_guc2host_events_work(struct work_struct *work)
+{
+struct drm_i915_private *dev_priv =
+container_of(work, struct drm_i915_private,
guc.
On Fri, Aug 12, 2016 at 04:20:03PM +0100, Tvrtko Ursulin wrote:
>
> On 12/08/16 07:25, akash.g...@intel.com wrote:
> >From: Akash Goel
> >
> >Added the dump of GuC log buffer to i915 error state, as the contents of
> >GuC log buffer would also be useful to determine that why the GPU reset
> >was
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.
Suggested-by: Chris Wilson
Signed-off-by: Akash Goel
---
drivers/
On Fri, Aug 12, 2016 at 08:43:58PM +0530, Goel, Akash wrote:
> On 8/12/2016 4:19 PM, Tvrtko Ursulin wrote:
> >Unreleated and unmentioned change to no guard page. Best to remove IMHO.
> >Can keep the RB in that case.
>
> Though its not called out, sorry for that, but isn't it better to
> avoid usin
On Fri, Aug 12, 2016 at 04:07:30PM +0100, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2fe88d930ca7..8dcdc27afe80 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -715,18 +7
On 8/12/2016 4:19 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Chris Wilson
vmaps has a provision for controlling the page protection bits, with
which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their ma
If the command descriptor says to skip it, ignore checking for anyother
other conflict.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
i
If we need to use clflush to prepare our batch for reads from memory, we
can bypass the cache instead by using non-temporal copies.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 58 ++
drivers/gpu/drm/i915/i915_debugfs.c| 24
A signifcant proportion of the cmdparsing time for some batches is the
cost to find the register in the mmiotable. We ensure that those tables
are in ascending order such that we could do a binary search if it was
ever merited. It is.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd
The existing code's hashfunction is very suboptimal (most 3D commands
use the same bucket degrading the hash to a long list). The code even
acknowledge that the issue was known and the fix simple:
/*
* If we attempt to generate a perfect hash, we should be able to look at bits
* 31:29 of a comma
On the blitter (and in test code), we see long sequences of repeated
commands, e.g. XY_PIXEL_BLT, XY_SCANLINE_BLT, or XY_SRC_COPY. For these,
we can skip the hashtable lookup by remembering the previous command
descriptor and doing a straightforward compare of the command header.
The corollary is t
If the developer adds a register in the wrong order, we BUG during boot.
That makes development and testing very difficult. Let's be a bit more
friendly and disable the command parser with a big warning if the tables
are invalid.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_pars
For simplicity, we want to continue using a contiguous mapping of the
command buffer, but we can reduce the number of vmappings we hold by
switching over to a page-by-page copy from the user batch buffer to the
shadow. The cost for saving one linear mapping is about 5% in trivial
workloads - which
From the moment the cmdparser was enabled (4.0) we got regression reports
about the performance regression, e.g. most notable on Baytrail
http://www.spinics.net/lists/dri-devel/msg80933.html
msg->id:1428627643.3417.22.ca...@collabora.com
Whilst this doesn't make the cmdparser free
Since I have been using the BCS_TIMESTAMP to measure latency of
execution upon the blitter ring, allow regular userspace to also read
from that register. They are already allowed RCS_TIMESTAMP!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 5 +
1 file changed, 5 in
The single largest factor in the overhead of parsing the commands is the
setup of the virtual mapping to provide a continuous block for the batch
buffer. If we keep those vmappings around (against the better judgement
of mm/vmalloc.c, which we offset by handwaving and looking suggestively
at the sh
On 12/08/16 15:48, Goel, Akash wrote:
On 8/12/2016 8:12 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
an
On 12/08/16 15:31, Goel, Akash wrote:
On 8/12/2016 7:01 PM, Tvrtko Ursulin wrote:
+static void gen9_guc2host_events_work(struct work_struct *work)
+{
+struct drm_i915_private *dev_priv =
+container_of(work, struct drm_i915_private, guc.events_work);
+
+spin_lock_irq(&dev_priv->i
On 8/12/2016 7:25 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
With the addition of new Host2GuC actions related to GuC logging, there
is a need of a lock to serialize them, as they can execute concurrently
with each other and also with other exi
On 8/12/2016 7:56 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it
becomes half full. GuC firmware also tracks how many times the
buffer overflowed.
It would be useful to maintain a stat
On 8/12/2016 8:12 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
and can just copy only the newly written
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
and can just copy only the newly written data by GuC into the local
buffer, i.e. as per
On 8/12/2016 7:01 PM, Tvrtko Ursulin wrote:
On 12/08/16 14:10, Goel, Akash wrote:
On 8/12/2016 5:24 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it
becomes half full. GuC firmware also tracks how many times the
buffer overflowed.
It would be useful to maintain a statistics of how many flush
interrupts were receiv
== Series Details ==
Series: series starting with [CI,01/31] drm/i915: Record the position of the
start of the request
URL : https://patchwork.freedesktop.org/series/11029/
State : failure
== Summary ==
Series 11029v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
On 12/08/16 14:45, Goel, Akash wrote:
On 8/12/2016 6:47 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, 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 i
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
With the addition of new Host2GuC actions related to GuC logging, there
is a need of a lock to serialize them, as they can execute concurrently
with each other and also with other existing actions.
v2: Use mutex in place of spinl
On 12/08/16 07:25, 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
Since the scratch allocation and cleanup is shared by all engine
submission backends, move it out of the legacy intel_ringbuffer.c and
into the new home for common routines, intel_engine_cs.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm
Use the GGTT VMA as the primary cookie for handing ring objects as
the most common action upon the ring is mapping and unmapping which act
upon the VMA itself. By restructuring the code to work with the ring
VMA, we can shrink the code and remove a few cycles from context pinning.
v2: Move the flu
In a few places, we repeat a call to clear a pointer to a vma whilst
unpinning and releasing a reference to its owner. Refactor those into a
common function.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 12
drivers/gpu/dr
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_overlay.c | 39
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 90f3ab42
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 16 -
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel
This little helper only exists to safely discard the upper unused 32bits
of the general 64-bit VMA address - as we know that all Global GTT
currently are less than 4GiB in size and so that the upper bits must be
zero. In many places, we use a u32 for the global GTT offset and we want
to document wh
It is useful when looking at captured error states to check the recorded
BBADDR register (the address of the last batchbuffer instruction loaded)
against the expected offset of the batch buffer, and so do a quick check
that (a) the capture is true or (b) HEAD hasn't wandered off into the
badlands.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 40 +++-
drivers/gpu/drm/i915/i915_gem_render_state.h | 2 +-
2 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_render
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 58 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +--
3 files changed, 35 insertions(+), 29 deletions(-)
diff
When working with contexts, we most frequently want the GGTT VMA for the
context state, first and foremost. Since the object is available via the
VMA, we need only then store the VMA.
v2: Formatting tweaks to debugfs output, restored some comments removed
in the next patch
Signed-off-by: Chris Wi
Treat the VMA as the primary struct responsible for tracking bindings
into the GPU's VM. That is we want to treat the VMA returned after we
pin an object into the VM as the cookie we hold and eventually release
when unpinning. Doing so eliminates the ambiguity in pinning the object
and then searchi
Just another useful register to inspect following a GPU hang.
v2: Remove partial decoding of RING_MODE to userspace, be consistent and
use GEN > 2 guards around RING_MODE everywhere.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
dri
There is no other state pertaining to the completed requests in the
hang, other than gleamed through the ringbuffer, so including the
expired requests in the list of outstanding requests simply adds noise.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Matthew Auld
---
d
Since the intel_engine_init_seqno() is shared by all engine submission
backends, move it out of the legacy intel_ringbuffer.c and
into the new home for common routines, intel_engine_cs.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915
Access through the GTT requires the device to be awake. Ideally
i915_vma_pin_iomap() is short-lived and the pinning demarcates the
access through the iomap. This is not entirely true, we have a mixture
of long lived pins that exceed the wakelock (such as legacy ringbuffers)
and short lived pin that
Since the guc allocates and pins and object into the GGTT for its usage,
it is more natural to use that pinned VMA as our resource cookie.
v2: Embrace naming tautology
v3: Rewrite comments for guc_allocate_vma()
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 18 +--
drivers/gpu/drm/i915/intel_rin
Lookup the GGTT vma once for the object assigned to the fence, and then
derive everything from that vma.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_fence.c | 55 +--
1 file changed, 26 insertions(+), 29 deletions(-)
We know that the only access to the context object is via the GPU, and
the only time when it can be out of the GPU domain is when it is swapped
out and unbound. Therefore we only need to clflush the object when
binding, thus avoiding any potential stall on touching the domain on an
active context.
The VMA are unreferenced, they belong to the object and live until they
are closed. However, if we want to use the VMA as a cookie and use it to
keep the object alive, we want to hold onto a reference to the object
for the lifetime of the VMA cookie. To facilitate this, add a couple of
simple wrapp
v2: Rename functions to suit their more active role
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 51 --
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
Not only does it make for good documentation and debugging aide, but it is
also vital for when we want to unwind requests - such as when throwing away
an incomplete request.
Signed-off-by: Chris Wilson
Link:
http://patchwork.freedesktop.org/patch/msgid/1470414607-32453-2-git-send-email-arun.silu
It's an outright programming error, so explode if it is ever hit.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_request.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/driver
No longer is knowing how much of the GTT (both mappable aperture and
beyond) relevant, and the output clutters the real information - that is
how many objects are allocated and bound (and by who) so that we can
quickly grasp if there is a leak.
v2: Relent, and rename pinned to indicate display onl
Previously, we would only set the vma->pages pointer for GGTT entries.
However, if we always set it, we can use it to prettify some code that
may want to access the backing store associated with the VMA (as
assigned to the VMA).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drive
With execlists, we have context objects everywhere, not just RCS. So
store them for post-mortem debugging. This also has a secondary effect
of removing one more unsafe list iteration with using preserved state
from the hanging request. And now we can cross-reference the request's
context state with
When capturing the error state, we do not need to know about every
address space - just those that are related to the error. We know which
context is active at the time, therefore we know which VM are implicated
in the error. We can then restrict the VM which we report to the
relevant subset.
v2:
These two files (i915_gem_active, i915_gem_inactive) no longer give
pertinent information since active/inactive tracking is per-vm and so we
need the information per-vm. They are obsolete so remove them.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debu
Only those objects pinned to the display have semi-permanent pins of a
global nature (other pins are transient within their local vm). Simplify
i915_gem_pinned to only show the pertinent information about the pinned
objects within the GGTT.
v2: i915_gem_gtt_info is still shared with debugfs/i915_g
A simple little macro to clear a pointer and return the old value. This
is useful for writing
value = *ptr;
if (!value)
return;
*ptr = 0;
...
free(value);
in a slightly more concise form:
value = fetch_and_zero(ptr);
if (!v
In many places, we wish to store the VMA in preference to the object
itself and so being able to create the persistent VMA is useful.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +
On 8/12/2016 6:47 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, 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
1 - 100 of 186 matches
Mail list logo
