[Intel-gfx] ✓ Ro.CI.BAT: success for i915: Add fence fds to execbuffer2 uapi

== Series Details == Series: i915: Add fence fds to execbuffer2 uapi URL : https://patchwork.freedesktop.org/series/9196/ State : success == Summary == Series 9196v1 i915: Add fence fds to execbuffer2 uapi http://patchwork.freedesktop.org/api/1.0/series/9196/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH 3/5] drm/i915: nonblocking commit

Hi, On 14 June 2016 at 00:13, Daniel Vetter wrote: > +static void intel_atomic_commit_tail(struct drm_atomic_state *state) > { > + struct drm_device *dev = state->dev; > struct intel_atomic_state *intel_state = to_intel_atomic_state(state); > struct

[Intel-gfx] [PATCH i-g-t 2/2] lib/intel_chipset: Removing PCI IDs that are no longer listed as Kabylake.

This is unusual. Usually IDs listed on early stages of platform definition are kept there as reserved for later use. However these IDs here are not listed anymore in any of steppings and devices IDs tables for Kabylake on configurations overview section of BSpec. So it is better removing them

[Intel-gfx] [PATCH i-g-t 1/2] lib/intel_chipset: Add more Kabylake PCI IDs.

The spec has been updated adding new PCI IDs. v2: Avoid using "H" instead of HALO to keep names uniform - DK. Cc: Dhinakaran Pandiyan Signed-off-by: Rodrigo Vivi --- lib/intel_chipset.h | 14 ++ 1 file changed, 10

[Intel-gfx] [PATCH 2/2] intel: Removing PCI IDs that are no longer listed as Kabylake.

This is unusual. Usually IDs listed on early stages of platform definition are kept there as reserved for later use. However these IDs here are not listed anymore in any of steppings and devices IDs tables for Kabylake on configurations overview section of BSpec. So it is better removing them

[Intel-gfx] [PATCH 1/2] intel: Add more Kabylake PCI IDs.

The spec has been updated adding new PCI IDs. v2: Avoid using "H" instead of HALO to keep names uniform - DK. Cc: Dhinakaran Pandiyan Signed-off-by: Rodrigo Vivi --- intel/intel_chipset.h | 14 ++ 1 file changed, 10

[Intel-gfx] [PATCH] drm/i915/gen9: Re-allocate DDB only for changed pipes

When a display update triggers a DDB re-allocation, we should start by assuming that only the updated pipes need to be re-allocated (we have logic later that may add additional pipes if, e.g., a modeset triggers a change to the global allocation). We were erroneously using the _active_ pipes as

Re: [Intel-gfx] [RFC] i915: Add fence fds to execbuffer2 uapi

On Mon, Jun 27, 2016 at 01:18:59PM -0700, Chad Versace wrote: > On Mon 27 Jun 2016, Chad Versace wrote: > > Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an > > input and/or output fence fd, whose presence is controlled by flags. > > Also add I915_PARAM_HAS_FENCE_FD. > > > >

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

On Mon, 2016-06-27 at 20:45 +0200, Patrik Jakobsson wrote: > On Mon, Jun 27, 2016 at 7:12 PM, Vivi, Rodrigo m> wrote: > > > > On Mon, 2016-06-27 at 19:51 +0300, Imre Deak wrote: > > > > > > On Mon, 2016-06-27 at 19:32 +0300, Vivi, Rodrigo wrote: > > > > > > > > > > > >

Re: [Intel-gfx] [RFC] i915: Add fence fds to execbuffer2 uapi

On Mon 27 Jun 2016, Chad Versace wrote: > Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an > input and/or output fence fd, whose presence is controlled by flags. > Also add I915_PARAM_HAS_FENCE_FD. > > Signed-off-by: Chad Versace > --- >

Re: [Intel-gfx] [PATCH v2] Revert "sna: Refresh last detection timestamp on hotplug notifies"

On 18 June 2016 at 05:57, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 03:44:34PM -0400, Lyude wrote: >> From: Lyude Paul >> >> DRM does not always update the status of each connector during a >> hotplug event, and it's generally expected that

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

On Mon, Jun 27, 2016 at 7:12 PM, Vivi, Rodrigo wrote: > On Mon, 2016-06-27 at 19:51 +0300, Imre Deak wrote: >> On Mon, 2016-06-27 at 19:32 +0300, Vivi, Rodrigo wrote: >> > >> > On Mon, 2016-06-27 at 14:20 +0300, Imre Deak wrote: >> > > >> > > Adding Christophe, he was

Re: [Intel-gfx] [PATCH v10b 4/6] drm/i915: Interrupt driven fences

On 21/06/2016 17:27, Tvrtko Ursulin wrote: On 21/06/16 11:44, Tvrtko Ursulin wrote: On 17/06/16 12:05, john.c.harri...@intel.com wrote: From: John Harrison The intended usage model for struct fence is that the signalled status should be set on demand rather than

[Intel-gfx] [PACTH i-g-t v1] lib/drmtest: Change DRIVER_INTEL check to avoid running GEM on non-Intel

From: Robert Foss Avoid running gem_quiescent_gpu() on non-Intel hardware. Signed-off-by: Robert Foss --- lib/drmtest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/drmtest.c b/lib/drmtest.c index

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160627] [cannot apply to v4.7-rc5] [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/akash-goel-intel-com

[Intel-gfx] [RFC] i915: Add fence fds to execbuffer2 uapi

Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an input and/or output fence fd, whose presence is controlled by flags. Also add I915_PARAM_HAS_FENCE_FD. Signed-off-by: Chad Versace --- include/uapi/drm/i915_drm.h | 24 ++-- 1 file

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

On Mon, 2016-06-27 at 19:51 +0300, Imre Deak wrote: > On Mon, 2016-06-27 at 19:32 +0300, Vivi, Rodrigo wrote: > > > > On Mon, 2016-06-27 at 14:20 +0300, Imre Deak wrote: > > > > > > Adding Christophe, he was supposed to make the release after > > > validation. > > Apparently we are almost ready

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

On Mon, 2016-06-27 at 19:32 +0300, Vivi, Rodrigo wrote: > On Mon, 2016-06-27 at 14:20 +0300, Imre Deak wrote: > > Adding Christophe, he was supposed to make the release after > > validation. > > Apparently we are almost ready to release and one latest round of > final > validation was pending. >

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

On 6/27/2016 9:16 PM, Tvrtko Ursulin wrote: On 27/06/16 13:16, akash.g...@intel.com wrote: From: Akash Goel So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

On Mon, 2016-06-27 at 14:20 +0300, Imre Deak wrote: > Adding Christophe, he was supposed to make the release after > validation. Apparently we are almost ready to release and one latest round of final validation was pending. Christophe, any news on this front? > I don't think it prevents

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Decouple GuC log setup from verbosity parameter

On 6/27/2016 9:26 PM, Tvrtko Ursulin wrote: On 27/06/16 16:32, Goel, Akash wrote: On 6/27/2016 8:30 PM, Tvrtko Ursulin wrote: On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Decouple GuC log setup from verbosity parameter

On 27/06/16 16:32, Goel, Akash wrote: On 6/27/2016 8:30 PM, Tvrtko Ursulin wrote: On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level kernel parameter i915.guc_log_level. User could be

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

On 27/06/16 13:16, akash.g...@intel.com wrote: From: Akash Goel So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to supporting GuC interrupts, added new low level

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Decouple GuC log setup from verbosity parameter

On 6/27/2016 8:30 PM, Tvrtko Ursulin wrote: On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level kernel parameter i915.guc_log_level. User could be given a provision to enable logging at

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Add GuC ukernel logging related fields to fw interface file

On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble The first page of the GuC log buffer contains state info or meta data which is required to parse the logs contained in the subsequent pages. The structure representing the state info is added to

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Decouple GuC log setup from verbosity parameter

On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level kernel parameter i915.guc_log_level. User could be given a provision to enable logging at runtime and not necessarily during load time

Re: [Intel-gfx] [PATCH 09/11] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs

On 6/27/2016 7:01 PM, Jani Nikula wrote: On Mon, 27 Jun 2016, akash.g...@intel.com wrote: From: Akash Goel On recieving the log buffer flush interrupt from GuC firmware, Driver stores the snapshot of the log buffer in a local buffer, from which Userspace can pull the

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

== Series Details == Series: drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info URL : https://patchwork.freedesktop.org/series/9192/ State : warning == Summary == Series 9192v1 drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

[Intel-gfx] ✗ Ro.CI.BAT: failure for Legacy engine initialization refactoring

== Series Details == Series: Legacy engine initialization refactoring URL : https://patchwork.freedesktop.org/series/9191/ State : failure == Summary == Series 9191v1 Legacy engine initialization refactoring http://patchwork.freedesktop.org/api/1.0/series/9191/revisions/1/mbox Test

[Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

From: Akash Goel Updated the i915_drpc_info debugfs with coarse power gating & forcewake info for Gen9. v2: Change all IS_GEN9() by gen >= 9 (Damien) v3: Rebase Cc: Damien Lespiau Signed-off-by: Akash Goel ---

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160627] [cannot apply to v4.7-rc5] [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/akash-goel-intel-com

[Intel-gfx] [PATCH 10/13] drm/i915: Compact gen8_ring_sync

From: Tvrtko Ursulin Store the semaphore offset in a temporary variable to avoid having to get the VMA offset twice. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++ 1 file changed, 3 insertions(+), 4

[Intel-gfx] [PATCH 02/13] drm/i915: Consolidate add_request vfunc

From: Tvrtko Ursulin All engines apart from render select this based on Gen. Move it to the common helper as well. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- 1 file changed, 5 insertions(+),

[Intel-gfx] [PATCH 05/13] drm/i915: Consolidate get/set_seqno

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 18 ++ 1 file changed, 2 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 03/13] drm/i915: Consolidate seqno_barrier vfunc

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 13/13] drm/i915: Trim some if-else braces

From: Tvrtko Ursulin Just a bit of cleanup after the previous refactoring. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

[Intel-gfx] [PATCH 04/13] drm/i915: Consolidate get and put irq vfuncs

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 46 - 1 file changed, 17 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 08/13] drm/i915: Consolidate semaphore vfuncs init

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 48 + 1 file changed, 18 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 12/13] drm/i915: Remove redundant warning and consolidate gen8 render semaphore vfunc

From: Tvrtko Ursulin Warning could not trigger due code just above it making sure the semaphores revert to disabled state if the object allocation has failed. Move the relevant vfunc on the success path for clarity as well. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [PATCH 00/13] Legacy engine initialization refactoring

From: Tvrtko Ursulin Preparation step towards unifying what can be unified between legacy and execlist. This series tries to simplify the engine initializers by moving some of the commonatility replicated between all of the engines into a shared helper function - the

[Intel-gfx] [PATCH 07/13] drm/i915: Consolidate dispatch_execbuffer vfunc

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 25 ++--- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 11/13] drm/i915: Consolidate legacy semaphore initialization

From: Tvrtko Ursulin Replace per-engine initialization with a common half-programatic, half-data driven code for ease of maintenance and compactness. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 110

[Intel-gfx] [PATCH 06/13] drm/i915: Consolidate init_hw vfunc

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 09/13] drm/i915: Compact Gen8 semaphore initialization

From: Tvrtko Ursulin Replace the macro initializer with a programatic loop which results in smaller code and hopefully just as clear. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +++-

[Intel-gfx] [PATCH 01/13] drm/i915: Consolidate write_tail vfunc initializer

From: Tvrtko Ursulin Introduce a function which initializes vfuncs mostly common across engines and move write_tail initialization in it since only one engine overrides the default. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev3)

== Series Details == Series: Support for sustained capturing of GuC firmware logs (rev3) URL : https://patchwork.freedesktop.org/series/7910/ State : failure == Summary == Series 7910v3 Support for sustained capturing of GuC firmware logs

Re: [Intel-gfx] [PATCH 09/11] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs

On Mon, 27 Jun 2016, akash.g...@intel.com wrote: > From: Akash Goel > > On recieving the log buffer flush interrupt from GuC firmware, Driver > stores the snapshot of the log buffer in a local buffer, from which > Userspace can pull the logs. By default Driver store, up to,

[Intel-gfx] ✓ Ro.CI.BAT: success for gpu: i915: fix build errors when ACPI is not enabled (rev2)

== Series Details == Series: gpu: i915: fix build errors when ACPI is not enabled (rev2) URL : https://patchwork.freedesktop.org/series/9163/ State : success == Summary == Series 9163v2 gpu: i915: fix build errors when ACPI is not enabled

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/guc: don't ever forward VBlank to the GuC

On 24/06/16 16:25, Patchwork wrote: == Series Details == Series: drm/i915/guc: don't ever forward VBlank to the GuC URL : https://patchwork.freedesktop.org/series/9145/ State : success == Summary == Series 9145v1 drm/i915/guc: don't ever forward VBlank to the GuC

Re: [Intel-gfx] [PATCH v3] drm/i915/guc: don't ever forward VBlank to the GuC

On 24/06/16 15:57, Dave Gordon wrote: If a context waiting for VBlank were switched out, switching in the next context and generating a CSB event in the process, then the GuC would have to put the context back in the queue, and then observe the subsequent VBlank interrupt so that it could

Re: [Intel-gfx] [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()

On 15.06.2016 14:25, Joerg Roedel wrote: > On Wed, Jun 01, 2016 at 12:10:08PM +0100, Chris Wilson wrote: >> Between acquiring the this_cpu_ptr() and using it, ideally we don't want >> to be preempted and work on another CPU's private data. this_cpu_ptr() >> checks whether or not preemption is

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: fix out-of-bounds page_table access (rev2)

On 27/06/16 12:59, Dave Gordon wrote: On 25/06/16 06:26, Patchwork wrote: == Series Details == Series: drm/i915: fix out-of-bounds page_table access (rev2) URL : https://patchwork.freedesktop.org/series/9148/ State : warning == Summary == Series 9148v2 drm/i915: fix out-of-bounds

Re: [Intel-gfx] drm/i915: Delay with fbc enabled

On Fri, 24 Jun 2016, Manuel Groß wrote: > since upgrading to Kernel 4.6, I experienced weird display delay issues > on my Thinkpad x250. Downgrading to 4.5 or disabling fbc both fix that > issue. If that's Haswell, FBC has been disabled by default (again, *sigh*). The fix is

Re: [Intel-gfx] [PATCH 23/25] drm/i915: Move the get/put irq locking into the caller

On 25/06/16 11:13, Chris Wilson wrote: With only a single callsite for intel_engine_cs->irq_get and ->irq_put, we can reduce the code size by moving the common preamble into the caller, and we can also eliminate the reference counting. For completeness, as we are no longer doing reference

[Intel-gfx] [PATCH 08/11] drm/i915: Debugfs support for GuC logging control

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. v2: Add a forceful flush, to collect left over logs, on disabling logging.

[Intel-gfx] [PATCH 05/11] drm/i915: Handle log buffer flush interrupt event from GuC

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 a file or buffer. Even

[Intel-gfx] [PATCH 10/11] drm/i915: Support to create write combined type vmaps

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 mapping type, we add a parameter to i915_gem_object_pin_map - but we

[Intel-gfx] [PATCH 11/11] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

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 accessed from GuC & Host

[Intel-gfx] [PATCH 09/11] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs

From: Akash Goel On recieving the log buffer flush interrupt from GuC firmware, Driver stores the snapshot of the log buffer in a local buffer, from which Userspace can pull the logs. By default Driver store, up to, 4 snapshots of the log buffer in a local buffer (managed

[Intel-gfx] [PATCH 06/11] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

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 GuC log buffer in the

[Intel-gfx] [PATCH 03/11] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

From: Akash Goel So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to supporting GuC interrupts, added new low level routines so as to allow sharing the programming of PM

[Intel-gfx] [PATCH 07/11] drm/i915: Forcefully flush GuC log buffer on reset

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. Signed-off-by: Sagar

[Intel-gfx] [PATCH 02/11] drm/i915: Add GuC ukernel logging related fields to fw interface file

From: Sagar Arun Kamble The first page of the GuC log buffer contains state info or meta data which is required to parse the logs contained in the subsequent pages. The structure representing the state info is added to interface file as Driver would need to handle log

[Intel-gfx] [PATCH 04/11] drm/i915: Support for GuC interrupts

From: Sagar Arun Kamble There are certain types of interrupts which Host can recieve from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel. This patch adds support to receive interrupts from

[Intel-gfx] [PATCH 01/11] drm/i915: Decouple GuC log setup from verbosity parameter

From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level kernel parameter i915.guc_log_level. User could be given a provision to enable logging at runtime and not necessarily during load time only. This patch will perform allocation of shared

[Intel-gfx] [PATCH v2 00/11] Support for sustained capturing of GuC firmware logs

From: Akash Goel GuC firmware log its debug messages into a Host-GuC shared memory buffer and when the buffer is half full it sends a Flush interrupt to Host. GuC firmware expects that while it is writing to 2nd half of the buffer, first half would get consumed by Host and

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: fix out-of-bounds page_table access (rev2)

On 25/06/16 06:26, Patchwork wrote: == Series Details == Series: drm/i915: fix out-of-bounds page_table access (rev2) URL : https://patchwork.freedesktop.org/series/9148/ State : warning == Summary == Series 9148v2 drm/i915: fix out-of-bounds page_table access

Re: [Intel-gfx] [PATCH 22/25] drm/i915: Embed signaling node into the GEM request

On 25/06/16 11:13, Chris Wilson wrote: Under the assumption that enabling signaling will be a frequent operation, lets preallocate our attachments for signaling inside the (rather large) request struct (and so benefiting from the slab cache). v2: Convert from void * to more meaningful names

[Intel-gfx] [PATCH] drm/i915: fix build errors when ACPI is not enabled

From: Randy Dunlap Fix build errors when ACPI is not enabled by adding function stubs: ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend': ../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of function 'intel_opregion_unregister'

Re: [Intel-gfx] [PATCH 21/25] drm/i915: Convert trace-irq to the breadcrumb waiter

On 25/06/16 11:13, Chris Wilson wrote: If we convert the tracing over from direct use of ring->irq_get() and over to the breadcrumb infrastructure, we only have a single user of the ring->irq_get and so we will be able to simplify the driver routines (eliminating the redundant validation and

Re: [Intel-gfx] [PATCH v2] iommu/vt-d: fix overflow of iommu->domains array

On Mon, Jun 06, 2016 at 02:20:11PM +0200, Jan Niehusmann wrote: > The valid range of 'did' in get_iommu_domain(*iommu, did) > is 0..cap_ndoms(iommu->cap), so don't exceed that > range in free_all_cpu_cached_iovas(). > > The user-visible impact of the out-of-bounds access is the machine > hanging

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

Adding Christophe, he was supposed to make the release after validation. I don't think it prevents merging this patch though, the result is failure to load the firmware in either case. --Imre On ma, 2016-06-27 at 12:57 +0200, Patrik Jakobsson wrote: > On Wed, Jun 15, 2016 at 12:11:55AM +,

Re: [Intel-gfx] [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()

On Sun, Jun 26, 2016 at 12:54:19PM +0200, Thorsten Leemhuis wrote: > Joerg, what's the status here? This made it on my 4.7 regressions > report, as the patches from this thread are supposed to fix a > regression; see > http://thread.gmane.org/gmane.linux.usb.general/143504/focus=153154 > for

Re: [Intel-gfx] [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()

On Wed, Jun 01, 2016 at 12:10:08PM +0100, Chris Wilson wrote: > drivers/iommu/iova.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) Okay, applied this patch to iommu/fixes and will send it upstream this week. ___ Intel-gfx mailing list

[Intel-gfx] [PACTH i-g-t v1] lib/igt_gt: Fix unused variable warning for non-x86 targets

From: Robert Foss Moved variable declaration inside #if case to avoid unused variable warnings on non-x86 targets. Signed-off-by: Robert Foss --- lib/igt_gt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links

On Wed, Jun 15, 2016 at 12:11:55AM +, Vivi, Rodrigo wrote: > On Mon, 2016-05-23 at 10:57 +0200, Patrik Jakobsson wrote: > > On Wed, May 18, 2016 at 01:24:12PM +0300, Mika Kuoppala wrote: > > > Patrik Jakobsson writes: > > > > > > > [ text/plain ] > > > >

Re: [Intel-gfx] [PATCH 11/25] drm/i915: Spin after waking up for an interrupt

On 25/06/16 11:12, Chris Wilson wrote: When waiting for an interrupt (waiting for the GPU to complete some work), we know we are the single waiter for the GPU. We also know when You mean we know we were the first waiter, if we have been woken up? Or perhaps the single waiter for this

Re: [Intel-gfx] [PATCH 20/25] drm/i915: Only query timestamp when measuring elapsed time

On 25/06/16 11:13, Chris Wilson wrote: Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as we only need to compute the elapsed time for a timed wait. v2: Eliminate the unused local variable reducing the function size by 64 bytes (using the storage space on the callers stack

Re: [Intel-gfx] [PATCH 18/25] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

On 25/06/16 11:13, Chris Wilson wrote: If we flag the seqno as potentially stale upon receiving an interrupt, we can use that information to reduce the frequency that we apply the heavyweight coherent seqno read (i.e. if we wake up a chain of waiters). v2: Use cmpxchg to replace

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

On Mon, Jun 13, 2016 at 7:52 PM, Daniel Vetter wrote: > On Fri, Jun 10, 2016 at 03:14:36PM +0530, Agrawal, Akshu wrote: >> On 6/8/2016 2:10 PM, Daniel Vetter wrote: >> > On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote: >> > > CHV pipe C hits underrun when we get -ve

[Intel-gfx] [v4.7-rc5] i915: *ERROR* (CPU pipe|PCH transcoder) A FIFO underrun

Hi Daniel, I had already reported this issue in a email-thread called "[v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun". This is still happening here on Sandybridge (and Ivybridge GPU reported by Chris Bainbridge). I have updated the bug-report in [1]. Chris