== 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
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
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
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
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
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
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
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.
> >
> >
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:
> > > >
> > > >
> > > >
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
> ---
>
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
== 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
== 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
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
---
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
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
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(+),
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
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
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
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
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
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
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
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
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
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
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 +++-
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
---
== 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
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,
== 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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
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
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 +,
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
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
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
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 ]
> > > >
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
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
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
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
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
81 matches
Mail list logo