We may have fused or unused pipes in our system. Let's check that the pipe
in question is within limits of accessible pipes. In case, that we are not
able to access the pipe, we return early with a warning.
v2: Rephrasing of the commit message (Jani)
Bugzilla: https://bugs.freedesktop.org/show_bu
On Sat, 16 Dec 2017, sohu0106 wrote:
> I found a similar Double-Fetch bug in drivers/gpu/drm/i915/i915_gem.c
> when I was examining the source code.
Similar to what?
> In function i915_gem_pread_ioctl(), the driver check user space data
> by pointer data_ptr via access_ok() in line 694, and aft
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
On Fri, 2017-12-15 at 16:23 +0200, Mika Kahola wrote:
> On Fri, 2017-12-15 at 19:20 +0530, Jaswinder Singh Rajput wrote:
> >
> > On Fri, 2017-12-15 at 14:44 +0200, Mika Kahola wrote:
> > >
> > >
> > > Hi,
> > >
> > > This is a known issue. Could you try out this patch to see if
> > > that
> > >
On 15/12/2017 18:04, Lionel Landwerlin wrote:
It doesn't look like tracepoint have any guarantee to have always the
same ordering of their parameter. Instead of relying on a predefined
regexp, let's split the parameters on commas and access the values
through a map.
Signed-off-by: Lionel Landwe
On Fri, 2017-12-15 at 14:44 +0200, Mika Kahola wrote:
> Hi,
>
> This is a known issue. Could you try out this patch to see if that
> would fix this issue for you?
>
> https://patchwork.freedesktop.org/series/35389/
>
Yes, Thanks. It works :-)
When this patch will merge with linus kernel.
Than
Hi,
I found a similar Double-Fetch bug in drivers/gpu/drm/i915/i915_gem.c when I
was examining the source code.
In function i915_gem_pread_ioctl(), the driver check user space data by pointer
data_ptr via access_ok() in line 694, and after run a while, in function
shmem_pread_slow in
== Series Details ==
Series: drm/i915: Check for fused or unused pipes (rev3)
URL : https://patchwork.freedesktop.org/series/35389/
State : success
== Summary ==
Series 35389v3 drm/i915: Check for fused or unused pipes
https://patchwork.freedesktop.org/api/1.0/series/35389/revisions/3/mbox/
T
== Series Details ==
Series: drm/i915: Check for fused or unused pipes (rev3)
URL : https://patchwork.freedesktop.org/series/35389/
State : failure
== Summary ==
Test kms_chv_cursor_fail:
Subgroup pipe-c-64x64-bottom-edge:
pass -> INCOMPLETE (shard-hsw)
Test drv_s
The HW frame counter can get reset when devices enters low power
states and this messes up any following vblank count updates. So, compute
the missed vblank interrupts for that low power state duration using time
stamps. This is similar to _crtc_vblank_on() except that it doesn't enable
vblank inte
When DC states are enabled and PSR is active, the hardware enters DC5/DC6
states resulting in frame counter resets. The frame counter resets mess
up the vblank counting logic. So in order to disable DC states when
vblank interrupts are required and to disallow DC states when vblanks
interrupts are
Updating the vblank counts requires register reads and these reads may not
return meaningful values after the vblank interrupts are disabled as the
device may go to low power state. An additional change would be to allow
the driver to save the vblank counts before entering a low power state, but
th
Convert the power_domains->domain_use_count array that tracks per-domain
use count to atomic_t type. This is needed to be able to read/write the use
counts outside of the power domain mutex.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i
Disable DC states before enabling vblank interrupts and conversely
enable DC states after disabling. Since the frame counter may have got
reset between disabling and enabling, use drm_crtc_vblank_restore() to
compute the missed vblanks.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915
We have an existing helper for testing obj->mm.pages, so use it.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
Op 15-12-17 om 23:43 schreef Rodrigo Vivi:
> In case we have multiple modesets for different connectors
> happening in parallel we could have a race on the RMW on these
> shared registers.
>
> This possibility was initially raised by Paulo when reviewing
> commit '555e38d27317 ("drm/i915/cnl: DDI -
Quoting Matthew Auld (2017-12-18 10:38:55)
> We have an existing helper for testing obj->mm.pages, so use it.
>
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
== Series Details ==
Series: series starting with [CI,v2,1/5] drm/vblank: Do not update vblank
counts if vblanks are already disabled.
URL : https://patchwork.freedesktop.org/series/35501/
State : failure
== Summary ==
Series 35501v1 series starting with [CI,v2,1/5] drm/vblank: Do not update
== Series Details ==
Series: drm/i915: prefer i915_gem_object_has_pages()
URL : https://patchwork.freedesktop.org/series/35502/
State : success
== Summary ==
Series 35502v1 drm/i915: prefer i915_gem_object_has_pages()
https://patchwork.freedesktop.org/api/1.0/series/35502/revisions/1/mbox/
Te
On 17/12/2017 13:28, Chris Wilson wrote:
Inside i915_gem_reset(), we start touching the HW and so require the
low-level HW to be re-enabled, in particular the PCI BARs.
Fixes: 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an
idle engine")
Testcase: igt/drv_hangman #
On 17/12/2017 13:28, Chris Wilson wrote:
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++
1 fil
Quoting Chris Wilson (2017-12-17 13:28:51)
> A useful bit of information for inspecting GPU stalls from
> intel_engine_dump() are the error registers, IPEIR and IPEHR.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 7 +
Quoting Tvrtko Ursulin (2017-12-18 11:14:19)
>
> On 17/12/2017 13:28, Chris Wilson wrote:
> > A useful bit of information for inspecting GPU stalls from
> > intel_engine_dump() are the error registers, IPEIR and IPEHR.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Joonas Lah
Quoting Tvrtko Ursulin (2017-12-18 11:11:49)
>
> On 17/12/2017 13:28, Chris Wilson wrote:
> > Inside i915_gem_reset(), we start touching the HW and so require the
> > low-level HW to be re-enabled, in particular the PCI BARs.
> >
> > Fixes: 7b6da818d86f ("drm/i915: Restore the kernel context afte
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
v2: Fixup gen changes in register offsets (Tvrtko)
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engi
On Sun, Dec 17, 2017 at 10:45:13PM -0200, Gabriel Krisman Bertazi wrote:
>
> Hi Ben and list folks,
>
> I've been investigating some CI failures with the kms_ccs testcase in
> the GLK hardware. The original bug is linked below, but there are other
> more basic tests failing when trying CCS on pi
On Fri, Dec 15, 2017 at 02:59:36PM -0500, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> tools/intel_vbt_decode.c | 4 ++--
> tools/intel_vbt_defs.h | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
This mail was rejected by Patchwork because of "X-Mailer" header,
indic
== Series Details ==
Series: drm/i915: prefer i915_gem_object_has_pages()
URL : https://patchwork.freedesktop.org/series/35502/
State : success
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass -> FAIL (shard-s
Quoting Patchwork (2017-12-18 11:52:05)
> == Series Details ==
>
> Series: drm/i915: prefer i915_gem_object_has_pages()
> URL : https://patchwork.freedesktop.org/series/35502/
> State : success
>
> == Summary ==
>
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-dr
发自我的华为手机i have see copy user pointer to a kernel temp struct before call i915_gem_pead_ioctl thanks for your reply 原始邮件 主题：Re: Linux kernel: drivers/gpu/drm/i915/i915_gem.c: i915_gem_pread_ioctl similar Double-Fetch bug发件人：Jani Nikula 收件人：sohu0106 ,joonas.lahti...@linux.intel.com,ro
From: Tvrtko Ursulin
Instead of hard-coding the order of key-value pairs into regular
expressions, auto-detect them as we go.
At the same time re-factor the code so it is smaller and even
slightly faster (10-15% by a quick measurement).
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc:
On 18/12/2017 11:26, Chris Wilson wrote:
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
v2: Fixup gen changes in register offsets (Tvrtko)
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko U
When monitoring the GPU with i915 perf, reports are tagged with a hw
id. Gem context creation tracepoints already have a hw_id field,
unfortunately you only get this correlation between a process id and a
hw context id once when the context is created. It doesn't help if you
started monitoring afte
Let's make the order of the fields of the tracepoints involving gem
request match across i915. This makes userspace processing of
tracepoint a bit easier.
Suggested-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_trace.h | 4 ++--
1 file changed, 2 insertions(+),
Hi,
These are just a couple of changes to allow process/hw_id correlation
when using i915 perf to monitor the workloads on the GPU.
Cheers,
Lionel Landwerlin (2):
drm/i915: reorder field in gem_request tracepoints
drm/i915/trace: add hw_id to gem requests trace points
drivers/gpu/drm/i915/
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
v2: Fixup gen changes in register offsets (Tvrtko)
v3: Old FADDR location as well
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani Nikula
> Sent: Thursday, October 12, 2017 9:36 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Daniel Vetter
>
> Subject: [Intel-gfx] [PATCH 4/4] drm/i915: push shared
On 18/12/2017 12:17, Chris Wilson wrote:
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
v2: Fixup gen changes in register offsets (Tvrtko)
v3: Old FADDR location as well
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc
Quoting Tvrtko Ursulin (2017-12-18 12:32:37)
>
> On 18/12/2017 12:17, Chris Wilson wrote:
> > A useful bit of information for inspecting GPU stalls from
> > intel_engine_dump() are the error registers, IPEIR and IPEHR.
> >
> > v2: Fixup gen changes in register offsets (Tvrtko)
> > v3: Old FADDR l
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
v2: Fixup gen changes in register offsets (Tvrtko)
v3: Old FADDR location as well
v4: Use I915_READ64_2x32
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
On Mon, 18 Dec 2017, "Chauhan, Madhav" wrote:
>> -Original Message-
>> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>> Jani Nikula
>> Sent: Thursday, October 12, 2017 9:36 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Nikula, Jani ; Daniel Vetter
>>
>>
== Series Details ==
Series: drm/i915: improve tracepoints for process/hw_id tracking
URL : https://patchwork.freedesktop.org/series/35506/
State : success
== Summary ==
Series 35506v1 drm/i915: improve tracepoints for process/hw_id tracking
https://patchwork.freedesktop.org/api/1.0/series/355
On 18/12/2017 12:39, Chris Wilson wrote:
A useful bit of information for inspecting GPU stalls from
intel_engine_dump() are the error registers, IPEIR and IPEHR.
v2: Fixup gen changes in register offsets (Tvrtko)
v3: Old FADDR location as well
v4: Use I915_READ64_2x32
Signed-off-by: Chris Wils
> -Original Message-
> From: Nikula, Jani
> Sent: Monday, December 18, 2017 6:21 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Daniel Vetter
> Subject: RE: [Intel-gfx] [PATCH 4/4] drm/i915: push shared dpll enable to
> encoders on DDI platforms
>
> On Mon, 18 Dec 20
== Series Details ==
Series: series starting with [1/3] drm/i915: Re-enable GGTT earlier after GPU
reset (rev4)
URL : https://patchwork.freedesktop.org/series/35471/
State : failure
== Summary ==
Series 35471v4 series starting with [1/3] drm/i915: Re-enable GGTT earlier
after GPU reset
https
On 15/12/2017 14:48, Chris Wilson wrote:
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it a
Quoting Tvrtko Ursulin (2017-12-18 12:58:51)
>
> On 18/12/2017 12:39, Chris Wilson wrote:
> > A useful bit of information for inspecting GPU stalls from
> > intel_engine_dump() are the error registers, IPEIR and IPEHR.
> >
> > v2: Fixup gen changes in register offsets (Tvrtko)
> > v3: Old FADDR l
== Series Details ==
Series: intel_vbt_decode: Typo fixes
URL : https://patchwork.freedesktop.org/series/35441/
State : warning
== Summary ==
IGT patchset tested on top of latest successful build
c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking:
Correctly handle debugfs
Quoting Lionel Landwerlin (2017-12-18 12:12:47)
> Let's make the order of the fields of the tracepoints involving gem
> request match across i915. This makes userspace processing of
> tracepoint a bit easier.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Lionel Landwerlin
We could argue for d
Quoting Lionel Landwerlin (2017-12-18 12:12:48)
> When monitoring the GPU with i915 perf, reports are tagged with a hw
> id. Gem context creation tracepoints already have a hw_id field,
> unfortunately you only get this correlation between a process id and a
> hw context id once when the context is
== Series Details ==
Series: scripts/trace.pl: Auto-detect tracepoint field order
URL : https://patchwork.freedesktop.org/series/35504/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking:
On 18/12/17 13:35, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-12-18 12:12:48)
When monitoring the GPU with i915 perf, reports are tagged with a hw
id. Gem context creation tracepoints already have a hw_id field,
unfortunately you only get this correlation between a process id and a
hw c
== Series Details ==
Series: intel_vbt_decode: Typo fixes
URL : https://patchwork.freedesktop.org/series/35441/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking:
Correctly handle debugfs
Let's make the order of the fields of the tracepoints involving gem
request match across i915. This makes userspace processing of
tracepoint a bit easier.
Suggested-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_trace.h | 4 ++--
1 fil
When monitoring the GPU with i915 perf, reports are tagged with a hw
id. Gem context creation tracepoints already have a hw_id field,
unfortunately you only get this correlation between a process id and a
hw context id once when the context is created. It doesn't help if you
started monitoring afte
Hey,
I did miss a tracepoint in patch 2. Fixed!
Cheers,
Lionel Landwerlin (2):
drm/i915: reorder field in gem_request tracepoints
drm/i915/trace: add hw_id to gem requests trace points
drivers/gpu/drm/i915/i915_trace.h | 40 +++
1 file changed, 24 insert
Quoting Lionel Landwerlin (2017-12-18 15:19:59)
> When monitoring the GPU with i915 perf, reports are tagged with a hw
> id. Gem context creation tracepoints already have a hw_id field,
> unfortunately you only get this correlation between a process id and a
> hw context id once when the context is
Hi all,
This series a respin of a few attempts ([1], [2], [3]) to expose RCS
topology to userspace.
The motivation for this is to be able to monitor part of the GPU using
i915 perf and have detailled knowledge about what execution units are
fused off. Let's say you monitor slice 1, knowing how ma
Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slice
While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.
slice0 (subslice_mask=0x7):
subslice0:
eu_mask: 0xff (8)
subslice1:
eu_mask
Now that we have that information in topology fields, let's just reused it.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu
With the introduction of asymetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.
This is essential for monitoring parts of
This might be useful information for developers looking at an error
state.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/
There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die
Signed-off-by: Lionel Landwerlin
---
tests/Makefile.sources | 1 +
tests/meson.build | 1 +
tests/query.c | 262 +
3 files changed, 264 insertions(+)
create mode 100644 tests/query.c
diff --git a/tests/Makefile.sources b/tests/Ma
Quoting Lionel Landwerlin (2017-12-18 15:35:18)
> This might be useful information for developers looking at an error
> state.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 35
> +++
> 1 file changed, 35 insertions(+)
>
> d
== Series Details ==
Series: drm/i915: improve tracepoints for process/hw_id tracking (rev2)
URL : https://patchwork.freedesktop.org/series/35506/
State : success
== Summary ==
Series 35506v2 drm/i915: improve tracepoints for process/hw_id tracking
https://patchwork.freedesktop.org/api/1.0/ser
We dump modparams in few places (debugfs, gpu_error) using different
functions. Lets add reusable function to avoid code duplication.
add/remove: 1/0 grow/shrink: 0/2 up/down: 1096/-2339 (-1243)
Function old new delta
i915_params_dump
We dump device flags in few places (init_early, debugfs, gpu_error)
using different functions. Lets add reusable function to avoid
code duplication.
add/remove: 1/0 grow/shrink: 0/3 up/down: 1296/-3572 (-2276)
Function old new delta
intel_device_info_dump_
On 18/12/17 12:02, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of hard-coding the order of key-value pairs into regular
expressions, auto-detect them as we go.
At the same time re-factor the code so it is smaller and even
slightly faster (10-15% by a quick measurement).
Signed-off-by:
== Series Details ==
Series: drm/i915: expose RCS topology to userspace
URL : https://patchwork.freedesktop.org/series/35519/
State : warning
== Summary ==
Series 35519v1 drm/i915: expose RCS topology to userspace
https://patchwork.freedesktop.org/api/1.0/series/35519/revisions/1/mbox/
Test k
Quoting Michal Wajdeczko (2017-12-18 15:51:31)
> We dump device flags in few places (init_early, debugfs, gpu_error)
> using different functions. Lets add reusable function to avoid
> code duplication.
>
> add/remove: 1/0 grow/shrink: 0/3 up/down: 1296/-3572 (-2276)
> Function
Hi Alex,
On Friday, 15 December 2017 03:57:48 EET Alex Deucher wrote:
> On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> > DK put some nice docs into the commit introducing driver private
> > state, but in the git history alone it'll be lost.
> >
> > Also, since Ville remove the void* usag
Quoting Michal Wajdeczko (2017-12-18 15:51:32)
> We dump modparams in few places (debugfs, gpu_error) using different
> functions. Lets add reusable function to avoid code duplication.
>
> add/remove: 1/0 grow/shrink: 0/2 up/down: 1096/-2339 (-1243)
> Function o
Hi Daniel,
Thank you for the patch.
On Thursday, 14 December 2017 22:30:53 EET Daniel Vetter wrote:
> DK put some nice docs into the commit introducing driver private
> state, but in the git history alone it'll be lost.
You might want to spell DK's name fully.
> Also, since Ville remove the voi
On 18/12/17 15:22, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-12-18 15:19:59)
When monitoring the GPU with i915 perf, reports are tagged with a hw
id. Gem context creation tracepoints already have a hw_id field,
unfortunately you only get this correlation between a process id and a
hw c
== Series Details ==
Series: series starting with [1/2] drm/i915: Add pretty printer for device info
flags
URL : https://patchwork.freedesktop.org/series/35521/
State : success
== Summary ==
Series 35521v1 series starting with [1/2] drm/i915: Add pretty printer for
device info flags
https://
== Series Details ==
Series: tests: add i915 query tests
URL : https://patchwork.freedesktop.org/series/35520/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking:
Correctly handle debugfs e
Oops, forgot to send the patch dumping the i915 headers :(
On 18/12/17 16:49, Patchwork wrote:
== Series Details ==
Series: tests: add i915 query tests
URL : https://patchwork.freedesktop.org/series/35520/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
c0
== Series Details ==
Series: drm/i915: improve tracepoints for process/hw_id tracking (rev2)
URL : https://patchwork.freedesktop.org/series/35506/
State : failure
== Summary ==
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass -> SKIP (shard-sn
From: Tvrtko Ursulin
Remove some inactive code which was only uised to support the old execlists
implementation. It is hidden behind a toggle which is not user accesible
anyway.
Signed-off-by: Tvrtko Ursulin
Cc: John Harrison
---
scripts/trace.pl | 31 ---
1 file c
== Series Details ==
Series: series starting with [1/2] drm/i915: Add pretty printer for device info
flags
URL : https://patchwork.freedesktop.org/series/35521/
State : success
== Summary ==
Test drv_selftest:
Subgroup live_hangcheck:
incomplete -> PASS (shard-sn
Op 18-12-17 om 08:08 schreef Daniel Vetter:
> Hm, the bisect looks funny. Only way I can explain that is that my
> patch fixed a pre-existing lockdep splat, and uncovered the issue in
> the ww-mutex self tests. That one is uncovered by the new
> cross-release lockdep checks in 4.15.
>
> Anyway I th
On Mon, 18 Dec 2017, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2017-12-18 15:51:31)
>> We dump device flags in few places (init_early, debugfs, gpu_error)
>> using different functions. Lets add reusable function to avoid
>> code duplication.
>>
>> add/remove: 1/0 grow/shrink: 0/3 up/down: 1
On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
>
> This didn't seem to have made it into -rc4. Anything needed to get it
> going?
Do you actually see the problem in -rc4?
Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot
== Series Details ==
Series: scripts/trace.pl: Remove some old code
URL : https://patchwork.freedesktop.org/series/35526/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
cfb711c046c22c3881d2334f0b43ec4eb0b9a5fc scripts/trace.pl: Auto-detect
tracepoint field
On 15/12/17 16:14, Chris Wilson wrote:
Quoting Antonio Argenziano (2017-12-15 19:01:11)
Since commit: drm/i915/scheduler: Support user-defined priorities, the
driver support an extra context param to set context's priority. Add
tests for that interface and update invalid tests.
Signed-off-by:
The Additional Data Struct (ADS) contains objects that are required by
GuC post FW load and are not necessarily submission-only. Even with
submission disabled we may require something inside the ADS, so it
makes more sense for them to be always created.
Similarly, we still want to access GuC logs
Op 14-11-17 om 16:17 schreef Shashank Sharma:
> Different LSPCON vendors specify their custom methods to pass
> AVI infoframes to the LSPCON chip, so does Parade tech.
>
> This patch adds functions to arrange and write AVI infoframes
> into Parade LSPCON chips.
>
> Signed-off-by: Shashank Sharma
>
Op 14-11-17 om 16:17 schreef Shashank Sharma:
> LSPCON chips are capable of generating YCBCR 4:2:0 outputs, if asked
> nicely :). In order to generate YCBCR 4:2:0 outputs, a source must:
> - send YCBCR 4:4:4 signals to LSPCON
> - program color space as 4:2:0 in AVI infoframes
>
> This will indicate
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, December 15, 2017 3:03 PM
>To: Wajdeczko, Michal
>Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
>
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK
>
>On Fri, Dec 15, 2017 at 06:07:27AM +, Michal
== Series Details ==
Series: scripts/trace.pl: Remove some old code
URL : https://patchwork.freedesktop.org/series/35526/
State : warning
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail -> PASS (shard-snb) fd
== Series Details ==
Series: drm/i915/guc : Decoupling ADS and logs from submission
URL : https://patchwork.freedesktop.org/series/35530/
State : success
== Summary ==
Series 35530v1 drm/i915/guc : Decoupling ADS and logs from submission
https://patchwork.freedesktop.org/api/1.0/series/35530/r
On Thu, Dec 7, 2017 at 5:38 AM, Jose Abreu wrote:
> Hi Sean,
>
> On 07-12-2017 00:00, Sean Paul wrote:
>> Welcome to version 4 of the patchset. I think we're nearing the finish line
>> (hopefully) now. This set addresses the review feedback from v3. I applied
>> some
>> R-b's from v3 review, and
Hi Dave,
I expect to have one more pile next week for rc6. But for now consider
already applying this one.
On this one here we had one backmerge for a reconciliation drm_print.h
between us and drm-misc-next. But that should be transparent to you.
On the GVT side it is worth to highlight that amo
== Series Details ==
Series: drm/i915/guc : Decoupling ADS and logs from submission
URL : https://patchwork.freedesktop.org/series/35530/
State : success
== Summary ==
Test drv_suspend:
Subgroup debugfs-reader:
skip -> PASS (shard-hsw)
Test kms_frontbuffer_t
Quoting Antonio Argenziano (2017-12-18 18:15:35)
>
>
> On 15/12/17 16:14, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2017-12-15 19:01:11)
> >> + arg.param = I915_CONTEXT_PARAM_PRIORITY;
> >> +
> >> + igt_subtest("root-set-priority") {
> >> + arg.ctx_id = ctx;
>
On Mon, 18 Dec 2017 20:25:17 +0100, Srivatsa, Anusha
wrote:
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, December 15, 2017 3:03 PM
To: Wajdeczko, Michal
Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
Subject: Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and Hu
Quoting Jani Nikula (2017-12-18 17:37:13)
> On Mon, 18 Dec 2017, Chris Wilson wrote:
> > Looks good, I'm thinking we might push the drm_printer to the caller of
> > intel_device_info_dump(), but this is already a substantial improvement
>
> Param ordering seems a bit surprising in both patches. T
From: Zhipeng Gong
SKL platforms requires a higher ring multiplier when there's massive
GPU load. Current driver doesn't provide a way to override the ring
multiplier.
This patch adds a new module parameter to allow the overriding of
ring multiplier for Gen9 platforms.
Cc: Ben Widawsky
Cc: Chr
1 - 100 of 131 matches
Mail list logo
