On 2016-05-24 04:07 AM, Daniel Vetter wrote:
On Fri, May 20, 2016 at 06:59:32PM -0400, robert.f...@collabora.com wrote:
From: Robert Foss
Replace intel specific header includes with intel_drm_stubs.h.
The stubbed functions will all call igt_require(false) and cause a skip.
Signed-off-by: R
Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enabl
From: Robert Foss
Test for libdrm_intel and build for it if present.
Also expose the HAVE_INTEL #define to allow code to be conditionally
compiled.
Signed-off-by: Robert Foss
---
configure.ac | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/conf
From: Robert Foss
Changes since v1:
- Replaced the automake flags HAVE_VC4/NOUVEAU/INTEL with HAVE_LIBDRM_XXX.
- Move conditionals from Makefile.sources to Arduino.mk/Makefile.am.
- Removed duplicated i915_drm.h symbols from intel_drm_stubs.h.
- Replaced igt_require with igt_require_f to communic
From: Robert Foss
Replace the automake flag HAVE_XXX for VC4/NOUVEAU with HAVE_LIBDRM_XXX in
order for the flags to be more descriptive and also follow the same convention
as HAVE_LIBDRM_INTEL.
---
configure.ac | 8
lib/Makefile.am | 2 +-
tests/Makefile.am | 4 ++--
3 files chan
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building tools that won't
compile unless libdrm_intel is available in the build system.
Signed-off-by: Robert Foss
---
tools/Android.mk | 8
tools/Makefile.am | 8
tools/Makefile.sources | 16 ++--
From: Robert Foss
This patch provides stubs for functionality otherwise provided by intel_bufmgr.
The stubbed functions all fail with a call to igt_require_f(false,"").
Defines and enums have been copied from libdrm_intel.
Due to the stubbed tests failing with an igt_require_f() call, these stu
From: Robert Foss
Harmonize tabs/spaces etc.
Signed-off-by: Robert Foss
---
tools/Makefile.sources | 57 +-
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index 07d8d9b..7ed5fe5 100
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building tools that won't
compile unless libdrm_intel is available in the build system.
Signed-off-by: Robert Foss
---
demos/Android.mk | 5 -
demos/Makefile.am | 8 +---
demos/Makefile.sources | 7 +++
3 files c
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building benchmarks that won't
compile unless libdrm_intel is available in the build system.
Signed-off-by: Robert Foss
---
benchmarks/Android.mk | 6 ++
benchmarks/Makefile.am | 5 -
benchmarks/Makefile.sources |
From: Robert Foss
Add support for configure flag --disable-pciaccess and the associated
automake define HAVE_PCIACCESS.
Signed-off-by: Robert Foss
---
configure.ac | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 11b1d46..e46bb
From: Robert Foss
Don't try to build overlay if libpciaccess is unavailable.
This is useful for platforms that typically don't have pci hardware,
like ARM platforms.
Robert Foss (2):
configure.ac: Add support for configure flag --disable-pciaccess.
overlay/Makefile: Don't try to build overla
From: Robert Foss
Don't try to build overlay if libpciaccess is unavailable.
This is useful for platforms that typically don't have pci hardware, like ARM
platforms.
Signed-off-by: Robert Foss
---
overlay/Makefile.am | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/overl
On Mon, May 23, 2016 at 10:42:41AM -0700, Jim Bride wrote:
> On Mon, May 23, 2016 at 11:22:17AM +0300, Ander Conselvan De Oliveira wrote:
> > On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > > From: Jim Bride
> > >
> > > For DP compliance we need to be able to control the output color
On Mon, May 23, 2016 at 11:10:24AM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > Kernel does not have automation support for DP compliance Link
> > training tests. So the Link Training test handler should return
> > a TEST_NAK.
>
> Is this
On Wed, May 25, 2016 at 02:43:59PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss
>
> Don't try to build overlay if libpciaccess is unavailable.
> This is useful for platforms that typically don't have pci hardware, like ARM
> platforms.
Ok, I should be able to make the dependency o
Le 25/05/2016 à 20:18, robert.f...@collabora.com a écrit :
> From: Robert Foss
>
> Test for libdrm_intel and build for it if present.
> Also expose the HAVE_INTEL #define to allow code to be conditionally
> compiled.
>
> Signed-off-by: Robert Foss
> ---
> configure.ac | 14 +-
> 1
Forward to ML.
On 2016-05-25 03:55 PM, Emil Velikov wrote:
On Wednesday, May 25, 2016 19:18 BST, robert.f...@collabora.com wrote:
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building benchmarks that won't
compile unless libdrm_intel is available in the build system.
Signed-off
On Wednesday, May 25, 2016 19:18 BST, robert.f...@collabora.com wrote:
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building tools that won't
compile unless libdrm_intel is available in the build system.
Signed-off-by: Robert Foss
---
demos/Android.mk | 5 -
demo
On Wednesday, May 25, 2016 19:18 BST, robert.f...@collabora.com wrote:
From: Robert Foss
Harmonize tabs/spaces etc.
Signed-off-by: Robert Foss
---
tools/Makefile.sources | 57 +-
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/t
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building tools that won't
compile unless libdrm_intel is available in the build system.
Signed-off-by: Robert Foss
---
tools/Android.mk | 8
tools/Makefile.am | 8
tools/Makefile.sources | 16 ++
Forward to ML.
On Wed, May 25, 2016 at 02:43:59PM -0400, robert.f...@collabora.com wrote:
From: Robert Foss
Don't try to build overlay if libpciaccess is unavailable.
This is useful for platforms that typically don't have pci hardware, like ARM
platforms.
Ok, I should be able to make the dep
Forward to ML.
On Wednesday, May 25, 2016 19:18 BST, robert.f...@collabora.com wrote:
From: Robert Foss
This patch provides stubs for functionality otherwise provided by intel_bufmgr.
The stubbed functions all fail with a call to igt_require_f(false,"").
Defines and enums have been copied fro
Forward to ML.
On Wednesday, May 25, 2016 19:18 BST, robert.f...@collabora.com wrote:
+if test "x$INTEL" = xyes; then
+ PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
+ AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support])
+fi
+AM_CONDITIONAL(HAVE_LIBDRM_INTEL, [test "x$INTE
Forward to ML.
On Wednesday, May 25, 2016 21:04 BST, Robert Foss
wrote:
> And this is why ladies and gentlemen you don't align on the \ character. As
one adds a test/file with long name, you'll need to re-indent the whole lot. Then
again... people like these, for whatever reason :-(
>
> -E
On 25 May 2016 at 23:09, Robert Foss wrote:
> Forward to ML.
>
> On Wednesday, May 25, 2016 19:18 BST, robert.f...@collabora.com wrote:
>
>> +if test "x$INTEL" = xyes; then
>> + PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
>> + AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel supp
On Mon, May 23, 2016 at 03:00:20PM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > This video pattern test function gets invoked through the
> > compliance test handler on a HPD short pulse if the test type is
> > set to DP_TEST_VIDEO_PATTERN.
On Mon, May 23, 2016 at 11:18:20AM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > This patch addresses a few issues from the original patch for
> > DP Compliance EDID test support submitted by
> > Todd Previte
>
> Do you mean commit 559be30c
On Tue, May 24, 2016 at 08:45:45AM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-05-23 at 10:42 -0700, Jim Bride wrote:
> > On Mon, May 23, 2016 at 11:22:17AM +0300, Ander Conselvan De Oliveira wrote:
> > >
> > > On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > > >
> > > > F
On Wed, May 18, 2016 at 10:46 AM, Ville Syrjälä
wrote:
> On Wed, May 18, 2016 at 06:47:12PM +0200, Daniel Vetter wrote:
>> This reverts
>>
>> commit dfaf37baa07513d2c37afff79978807d2d10221a
>> Author: Rodrigo Vivi
>> Date: Mon Dec 7 14:45:20 2015 -0800
>>
>> drm/i915: Fix idle_frames counte
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip idling an idle engine (rev8)
URL : https://patchwork.freedesktop.org/series/7708/
State : failure
== Summary ==
Applying: drm/i915: Skip idling an idle engine
Applying: drm/i915: Defer enabling rc6 til after we submit the f
On 5/25/16, Jani Nikula wrote:
> On Wed, 25 May 2016, Sedat Dilek wrote:
>> Hi Daniel,
>>
>> with latest Linus Git I see this with my Intel SandyBridge GPU...
>>
>> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CPU pipe A FIFO underrun
>> [ 17.630652] [drm:intel_set
Op 24-05-16 om 16:00 schreef Daniel Vetter:
> On Tue, May 17, 2016 at 03:08:01PM +0200, Maarten Lankhorst wrote:
>> All of intel_post_plane_update is handled there now, so move it over.
>> This is run after the hw state checker because it can't handle checking
>> crtc's separately yet.
>>
>> Signed
On Tue, May 24, 2016 at 04:12:09PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Revert async unpin and nonblocking atomic commit
> URL : https://patchwork.freedesktop.org/series/7643/
> State : warning
>
> == Summary ==
>
> Series 7643v1 drm/i915: Revert async unpin and
On Wed, May 25, 2016 at 08:57:49AM +0200, Maarten Lankhorst wrote:
> Op 24-05-16 om 17:49 schreef Daniel Vetter:
> > This reverts the following patches:
> >
> > d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update
> > of pageflips.
> > 15c86bdb760185e871c7a0f559978328aa50097
On Tue, 24 May 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Reject the modeset if the requested dotclock exceeds the maximum allowed
> by the hardware. So far we've only checked this on gen2/3 while also
> handling the double wide vs. single wide pipe selection. Extend the
On Wed, 25 May 2016, "Sanchez, AdolfoX" wrote:
> Is the eDP hotplugging capability supported by default by the intel
> graphic driver, or is it necessary any special configuration?
Not supported. It might work by coincidence if you replace the panel
with an identical one.
BR,
Jani.
--
Jani Ni
Op 25-05-16 om 09:35 schreef Daniel Vetter:
> On Wed, May 25, 2016 at 08:57:49AM +0200, Maarten Lankhorst wrote:
>> Op 24-05-16 om 17:49 schreef Daniel Vetter:
>>> This reverts the following patches:
>>>
>>> d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update
>>> of pagefli
On ti, 2016-05-24 at 11:56 +0100, Chris Wilson wrote:
> During suspend (or module unload), if we have never accessed the engine
> (i.e. userspace never submitted a batch to it), the engine is idle. Then
> we attempt to idle the engine by forcing it to the default context,
> which actually means we
Hi Dave -
I see the main drm pull got merged, here's the first batch of fixes for
4.7 already. Fixes all around, a large portion cc: stable stuff.
BR,
Jani.
PS. I got a bit worried that Ville's "drm: Add helper for DP++ adaptors"
lacked your ack, but apparently you'd acked it on IRC [1] but i
On Wed, May 25, 2016 at 11:50:22AM +0300, Joonas Lahtinen wrote:
> On ti, 2016-05-24 at 11:56 +0100, Chris Wilson wrote:
> > During suspend (or module unload), if we have never accessed the engine
> > (i.e. userspace never submitted a batch to it), the engine is idle. Then
> > we attempt to idle th
On ma, 2016-05-23 at 12:34 +0100, Chris Wilson wrote:
> Pack the integers and related types together inside the struct.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 16 +---
> 1 file changed, 9 insertions(+), 7
On ma, 2016-05-23 at 12:34 +0100, Chris Wilson wrote:
> Print the context's owner (via the pid under file_priv) under debugfs.
> In doing so, we must be careful that the filp is not accessed after it
> is freed (notified via i915_gem_context_close).
>
> v2: Mark the file_priv as closed.
>
> Signe
On ma, 2016-05-23 at 12:34 +0100, Chris Wilson wrote:
> Rather than have every context ask "am I owned by the kernel? pin!",
> move that logic into the creator of the kernel context, in order to
> improve code comprehension.
>
> v2: Throw away the user_handle on failure to allocate the ppgtt.
>
>
On ma, 2016-05-23 at 12:34 +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
Some commit message would be nice.
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff
On Wed, 25 May 2016, Sedat Dilek wrote:
> Hi Daniel,
>
> with latest Linus Git I see this with my Intel SandyBridge GPU...
>
> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
> [ 17.630652] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
> *E
On Tue, May 24, 2016 at 10:26:48PM +, Sanchez, AdolfoX wrote:
> Hello
>
> Is the eDP hotplugging capability supported by default by the intel graphic
> driver, or is it necessary any special configuration?
Not sure what you're asking. We do enable the hpd interrupt for eDP
ports, but it's up
On ma, 2016-05-23 at 14:01 +0100, Chris Wilson wrote:
> One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
> can compare the number of allocated objects and who owns them, a
> discrepancy here often indicates a kernel bug. One allocator of unreported
> objects is for backing c
On Wed, May 25, 2016 at 12:55:21PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-05-23 at 14:01 +0100, Chris Wilson wrote:
> > One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
> > can compare the number of allocated objects and who owns them, a
> > discrepancy here often indic
On Wed, May 25, 2016 at 09:32:50AM +0200, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 04:12:09PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Revert async unpin and nonblocking atomic commit
> > URL : https://patchwork.freedesktop.org/series/7643/
> > State : war
The kernel context exists simply as a placeholder and should never be
executed with a render context. It does not need the golden render
state, as that will always be applied to a user context. By skipping the
initialisation we can avoid issues in attempting to program the golden
render context whe
During suspend (or module unload), if we have never accessed the engine
(i.e. userspace never submitted a batch to it), the engine is idle. Then
we attempt to idle the engine by forcing it to the default context,
which actually means we submit a render batch to setup the golden
context state and th
As the L3 remapping is applied before the next execution, there is no
need to wait until all previous uses are idle, the application will not
occur any sooner.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sysfs.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/
In https://bugs.freedesktop.org/show_bug.cgi?id=95634 the cause of the
warning is that we populate the GGTT without waking the device. For the
purposes of suspend, if the device is already idle we have accomplished
our goal (of making the device idle). This series tries to avoid waking
the device s
We only need to force a switch to the kernel context placeholder during
eviction. All other uses of i915_gpu_idle() just want to wait until
existing work on the GPU is idle. Rename i915_gpu_idle() to
i915_gem_wait_for_idle() to avoid any implications about "parking" the
context first.
Signed-off-b
The contexts only pin space within the global GTT. Therefore forcing the
switch to the perma-pinned kernel context only has an effect when trying
to evict from and find room within the global GTT. We can then restrict
the switch to only when operating on the default context. This is mostly
a no-op
When the GPU is reset or state lost through suspend, every default
legacy context needs to reload their state - both the golden render
state and the L3 mapping. Only context images explicitly saved to memory
(i.e. all execlists and non-default legacy contexts) will retain their
state across the res
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip idling an idle engine
URL : https://patchwork.freedesktop.org/series/7708/
State : failure
== Summary ==
Series 7708v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7708/revisions/1/mbox
Test
On ke, 2016-05-25 at 12:48 +0100, Chris Wilson wrote:
> The kernel context exists simply as a placeholder and should never be
> executed with a render context. It does not need the golden render
> state, as that will always be applied to a user context. By skipping the
> initialisation we can avoid
On Wed, May 25, 2016 at 12:48:49PM +0100, Chris Wilson wrote:
> The kernel context exists simply as a placeholder and should never be
> executed with a render context. It does not need the golden render
> state, as that will always be applied to a user context. By skipping the
> initialisation we c
On ke, 2016-05-25 at 12:48 +0100, Chris Wilson wrote:
> When the GPU is reset or state lost through suspend, every default
> legacy context needs to reload their state - both the golden render
> state and the L3 mapping. Only context images explicitly saved to memory
> (i.e. all execlists and non-d
On ke, 2016-05-25 at 12:48 +0100, Chris Wilson wrote:
> We only need to force a switch to the kernel context placeholder during
> eviction. All other uses of i915_gpu_idle() just want to wait until
> existing work on the GPU is idle. Rename i915_gpu_idle() to
> i915_gem_wait_for_idle() to avoid any
On Wed, May 25, 2016 at 03:38:44PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-05-25 at 12:48 +0100, Chris Wilson wrote:
> > + for_each_engine(engine, dev_priv) {
> > + struct intel_context *ce =
> > + &dev_priv->kernel_context->engine[engine->id];
> > +
> > +
On Wed, May 25, 2016 at 03:57:04PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-05-25 at 12:48 +0100, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> > b/drivers/gpu/drm/i915/i915_gem_evict.c
> > index b144c3f5c650..5741b58d186c 100644
> > --- a/drivers/gpu/drm/i915/i91
The i915 driver checks for color management properties changes as part
of a plane update. Therefore a color management update must imply a
plane update, otherwise we never update the transformation matrixes
and degamma/gamma LUTs.
v2: add comment about moving the commit of color management registe
The i915 driver checks for color management properties changes as part
of a plane update. Therefore a color management update must imply a
plane update, otherwise we never update the transformation matrixes
and degamma/gamma LUTs.
v2: add comment about moving the commit of color management registe
Either use a igt_fixture for crtcs or remove it entirely and use
the one already in igt_main.
CC: Chris Wilson
Signed-off-by: Marius Vlad
---
tests/kms_cursor_legacy.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/tests/kms_cursor_legacy.c b/tests/kms_cursor_
As clear_range uses scratch page on all callsites, remove
the superfluous parameter.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 46 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +--
2 files changed, 18 insertions(+), 31 deletions(-)
== Series Details ==
Series: drm/i915: add missing condition for committing planes on crtc (rev5)
URL : https://patchwork.freedesktop.org/series/5467/
State : failure
== Summary ==
Series 5467v5 drm/i915: add missing condition for committing planes on crtc
http://patchwork.freedesktop.org/api/
On Wed, May 25, 2016 at 04:50:14PM +0300, Mika Kuoppala wrote:
> As clear_range uses scratch page on all callsites, remove
> the superfluous parameter.
It's there so that we had a convenient place to enable GPU faults for
out-of-bound access.
But I think that ship has long sailed, as nobody has p
During suspend (or module unload), if we have never accessed the engine
(i.e. userspace never submitted a batch to it), the engine is idle. Then
we attempt to idle the engine by forcing it to the default context,
which actually means we submit a render batch to setup the golden
context state and th
When the GPU is reset or state lost through suspend, every default
legacy context needs to reload their state - both the golden render
state and the L3 mapping. Only context images explicitly saved to memory
(i.e. all execlists and non-default legacy contexts) will retain their
state across the res
As the L3 remapping is applied before the next execution, there is no
need to wait until all previous uses are idle, the application will not
occur any sooner.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sysfs.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/
The kernel context exists simply as a placeholder and should never be
executed with a render context. It does not need the golden render
state, as that will always be applied to a user context. By skipping the
initialisation we can avoid issues in attempting to program the golden
render context whe
This is so that we have symmetry with intel_lrc.c and avoid a source of
if (i915.enable_execlists) layering violation within i915_gem_context.c -
that is we move the specific handling of the dev_priv->kernel_context
for legacy submission into the legacy submission code.
This depends upon the init/
We only need to force a switch to the kernel context placeholder during
eviction. All other uses of i915_gpu_idle() just want to wait until
existing work on the GPU is idle. Rename i915_gpu_idle() to
i915_gem_wait_for_idle() to avoid any implications about "parking" the
context first.
v2: Tweak an
Chris Wilson writes:
> [ text/plain ]
> On Wed, May 25, 2016 at 04:50:14PM +0300, Mika Kuoppala wrote:
>> As clear_range uses scratch page on all callsites, remove
>> the superfluous parameter.
>
> It's there so that we had a convenient place to enable GPU faults for
> out-of-bound access.
>
> Bu
Chris Wilson writes:
> [ text/plain ]
> The kernel context exists simply as a placeholder and should never be
> executed with a render context. It does not need the golden render
> state, as that will always be applied to a user context. By skipping the
> initialisation we can avoid issues in att
== Series Details ==
Series: drm/i915: add missing condition for committing planes on crtc (rev6)
URL : https://patchwork.freedesktop.org/series/5467/
State : success
== Summary ==
Series 5467v6 drm/i915: add missing condition for committing planes on crtc
http://patchwork.freedesktop.org/api/
Chris Wilson writes:
> [ text/plain ]
> As the L3 remapping is applied before the next execution, there is no
> need to wait until all previous uses are idle, the application will not
> occur any sooner.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915
== Series Details ==
Series: drm/i915/gtt: Clear range always uses scratch
URL : https://patchwork.freedesktop.org/series/7725/
State : failure
== Summary ==
Series 7725v1 drm/i915/gtt: Clear range always uses scratch
http://patchwork.freedesktop.org/api/1.0/series/7725/revisions/1/mbox
Test
On Wed, May 25, 2016 at 05:16:56PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > [ text/plain ]
> > The kernel context exists simply as a placeholder and should never be
> > executed with a render context. It does not need the golden render
> > state, as that will always be applied to
Some hardware requires a valid render context before it can initiate
rc6 power gating of the GPU; the default state of the GPU is not
sufficient and may lead to undefined behaviour. The first execution of
any batch will load the "golden render state", at which point it is safe
to enable rc6.
Signe
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip idling an idle engine (rev6)
URL : https://patchwork.freedesktop.org/series/7708/
State : failure
== Summary ==
Series 7708v6 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7708/revisions/6/mbox
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip idling an idle engine (rev7)
URL : https://patchwork.freedesktop.org/series/7708/
State : failure
== Summary ==
Applying: drm/i915: Skip idling an idle engine
Applying: drm/i915: Defer enabling rc6 til after we submit the f
On Wed, May 25, 2016 at 03:58:11PM +0100, Chris Wilson wrote:
> Some hardware requires a valid render context before it can initiate
> rc6 power gating of the GPU; the default state of the GPU is not
> sufficient and may lead to undefined behaviour. The first execution of
> any batch will load the
On Fri, May 20, 2016 at 02:29:02PM +0530, Durgadoss R wrote:
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the DP panel as well as number
> of lanes that can be supported by the type-C cable. Sometimes, the
> type-C cable may limit the
Some hardware requires a valid render context before it can initiate
rc6 power gating of the GPU; the default state of the GPU is not
sufficient and may lead to undefined behaviour. The first execution of
any batch will load the "golden render state", at which point it is safe
to enable rc6.
The m
On 2016-05-24 04:01 AM, Daniel Vetter wrote:
On Mon, May 23, 2016 at 03:04:16PM +0100, Emil Velikov wrote:
On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote:
From: Robert Foss
Use the HAS_INTEL automake flag to avoid building benchmarks that won't
compile unless libdrm_inte
On 2016-05-24 04:05 AM, Daniel Vetter wrote:
On Fri, May 20, 2016 at 06:59:31PM -0400, robert.f...@collabora.com wrote:
From: Robert Foss
This patch provides stubs for functionality otherwise provided by libdrm_intel.
The stubbed functions all fail with a call to igt_require(false).
Defines
90 matches
Mail list logo
