On Thu, 25 Feb 2016 22:57:34 +0100,
Ville Syrjälä wrote:
>
> On Thu, Feb 25, 2016 at 09:28:59PM +0100, Takashi Iwai wrote:
> > On Thu, 25 Feb 2016 20:19:08 +0100,
> > Ville Syrjälä wrote:
> > >
> > > Hi,
> > >
> > > My investigation into some sporadic i915 runtime PM failures seem to
> > >
== Series Details ==
Series: drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)
URL : https://patchwork.freedesktop.org/series/3827/
State : failure
== Summary ==
Series 3827v1 drm/i915: Balance assert_rpm_wakelock_held() for
!IS_ENABLED(CONFIG_PM)
Can you help me find out why my laptop uses about 6W extra when X is
running with the intel graphics running?
Are there special kernel options I can give to the i915 driver to use less
power,
or include in xorg.conf to do the same?
Is there also a way to make sure my nvidia chip I'm not using,
On 2/26/2016 12:11 AM, Joseph Salisbury wrote:
On 02/24/2016 10:53 PM, Jindal, Sonika wrote:
Hi Joe,
Yes, first thing to try is to increase the tries.
We testing with 300 retries, but the second monitor still did not show
up. However, it did show up in lspci.
Can you please point me to
Hi Joonas:
Thanks for you time and comments. :) See my replies below.
On 02/23/16 20:42, Joonas Lahtinen wrote:
Hi,
Code is looking a lot better.
A general question still; why you seem to be preferring multi-stage
alloc and destroy?
Are there going to be scenarios when things will be
On 02/24/16 16:08, Tian, Kevin wrote:
From: Wang, Zhi A
Sent: Thursday, February 18, 2016 7:42 PM
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
new file mode 100644
index 000..52cfa32
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
[...]
+
+#include
On 02/24/16 16:22, Tian, Kevin wrote:
From: Wang, Zhi A
Sent: Thursday, February 18, 2016 7:42 PM
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 52cfa32..2099b7e 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -348,6
On 02/24/16 15:42, Tian, Kevin wrote:
From: Wang, Zhi A
Sent: Tuesday, February 23, 2016 9:23 PM
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private
*dev_priv)
goto err;
}
On Fri, Feb 26, 2016 at 12:36:12AM +, Emil Velikov wrote:
...
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1554,6 +1554,41 @@ static int
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > return -ENOMEM;
> >
On Thu, Feb 25, 2016 at 03:33:43PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
>
> v2: Update contributors
>
> v3: Refactor degamma/gamma LUTs load into a single function
>
> v4: Remove unused variable
>
> Signed-off-by: Shashank Sharma
Hi Lionel,
A bunch of suggestions - feel free to take or ignore them :-)
On 25 February 2016 at 10:58, Lionel Landwerlin
wrote:
> Patch based on a previous series by Shashank Sharma.
>
> This introduces optional properties to enable color correction at the
> pipe
Hi Jani and Daniel,
I believe I forgot to cc:stable on this one and this is missing on
most branches out there including Linus 4.5-r5.
Is there any chance to get this patch in for 4.5? without this i915 is
not working on KBL.
Good thing is that this platform is still protected by
On Thu, Feb 25, 2016 at 03:33:42PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
>
> v2: Do not read GAMMA_MODE register to figure what mode we're in
>
> v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0
>
> Add documentation on how the
On 02/25/2016 05:49 AM, Ville Syrjälä wrote:
On Tue, Feb 16, 2016 at 09:44:55AM -0800, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Set cdclk based on the max required pixel clock based on VCO
selected. Track boot vco instead of boot cdclk.
The vco is now
On Thu, Feb 25, 2016 at 10:58:46AM +, Lionel Landwerlin wrote:
> Implement Daniel Stone's recommendation to not read registers to infer
> the hardware's state.
>
> v2: Read GAMMA_MODE register value at init (Matt Roper's comment)
>
> v3: Read GAMMA_MODE register in
On Thu, 2016-02-25 at 21:10 +, Chris Wilson wrote:
> commit 09731280028ce03e6a27e1998137f1775a2839f3
> Author: Imre Deak
> Date: Wed Feb 17 14:17:42 2016 +0200
>
> drm/i915: Add helper to get a display power ref if it was already
> enabled
>
> left the rpm
On Thu, Feb 25, 2016 at 09:28:59PM +0100, Takashi Iwai wrote:
> On Thu, 25 Feb 2016 20:19:08 +0100,
> Ville Syrjälä wrote:
> >
> > Hi,
> >
> > My investigation into some sporadic i915 runtime PM failures seem to
> > point the finger at snd-hda-intel.
> >
> > I just tried to play around unloding
commit 09731280028ce03e6a27e1998137f1775a2839f3
Author: Imre Deak
Date: Wed Feb 17 14:17:42 2016 +0200
drm/i915: Add helper to get a display power ref if it was already enabled
left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as
On Tue, Feb 23, 2016 at 9:33 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
>>
>> As it turns out, resuming DP MST is racey since we don't make sure MST
>> is ready before we start modesetting, it just usually happens to be
>> ready in
On Thu, 25 Feb 2016 20:19:08 +0100,
Ville Syrjälä wrote:
>
> Hi,
>
> My investigation into some sporadic i915 runtime PM failures seem to
> point the finger at snd-hda-intel.
>
> I just tried to play around unloding and reloading snd-hda-intel and
> sometimes I get snd-hda-intel loaded with
Hi,
My investigation into some sporadic i915 runtime PM failures seem to
point the finger at snd-hda-intel.
I just tried to play around unloding and reloading snd-hda-intel and
sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
but actually the device won't runtime suspend.
On Fri, Feb 19, 2016 at 01:45:03PM -, Patchwork wrote:
> == Summary ==
>
> Series 3541v1 drm/i915: Some FDI related dotclock stuff
> http://patchwork.freedesktop.org/api/1.0/series/3541/revisions/1/mbox/
>
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn
== Series Details ==
Series: drm/i915: add enable_guc_loading parameter (rev2)
URL : https://patchwork.freedesktop.org/series/3045/
State : warning
== Summary ==
Series 3045v2 drm/i915: add enable_guc_loading parameter
http://patchwork.freedesktop.org/api/1.0/series/3045/revisions/2/mbox/
On 11/01/2016 09:16, Chris Wilson wrote:
Migrate the request operations out of the main body of i915_gem.c and
into their own C file for easier expansion.
v2: Move __i915_add_request() across as well
Signed-off-by: Chris Wilson
---
don't we lose the history in git
On Tue, Feb 16, 2016 at 11:28:05AM -, Patchwork wrote:
> == Summary ==
>
> Series 3455v1 drm/i915: Handle fb->offsets[] and rewrite fb rotation handling
> to be more generic (v3)
> http://patchwork.freedesktop.org/api/1.0/series/3455/revisions/1/mbox/
>
> Test gem_ringfill:
>
On 11/01/2016 09:16, Chris Wilson wrote:
Remove some redundant kernel messages as we deduce a hung GPU and
capture the error state.
v2: Fix "hang" vs "no progress" message whilst I was there
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 21
On 11/01/2016 09:16, Chris Wilson wrote:
Now that we have (near) universal GPU recovery code, we can inject a
real hang from userspace and not need any fakery. Not only does this
mean that the testing is far more realistic, but we can simplify the
kernel in the process.
v2: Replace the
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: opt-out CPU and WC mmaps from
FBC
URL : https://patchwork.freedesktop.org/series/3817/
State : failure
== Summary ==
Series 3817v1 Series without cover letter
This is a helper to draw a gradient between 2 colors.
Signed-off-by: Lionel Landwerlin
---
lib/igt_fb.c | 34 ++
lib/igt_fb.h | 3 +++
lib/igt_kms.c | 2 +-
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git
This test enables testing of :
* degamma LUTs
* csc matrix
* gamma LUTs
* legacy gamma LUTs
v2: turn assert into require to skip on platform not supporting color
management
v3: add invalid blob ids tests
v4: Try to match CRC results against several values around the
Signed-off-by: Lionel Landwerlin
---
lib/igt_debugfs.c | 17 +
lib/igt_debugfs.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index c291ef3..a32ed78 100644
--- a/lib/igt_debugfs.c
+++
v2: Rename CTM_MATRIX property to CTM
Signed-off-by: Lionel Landwerlin
---
lib/igt_kms.c | 74 +++
lib/igt_kms.h | 17 +-
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git
Hi,
This series enables testing pipe level color management using kernel patches
from this serie :
https://patchwork.freedesktop.org/series/2720/
Most of the tests use pipe CRCs to check the results by comparing the output
with the expected output drawn using cairo.
Cheers,
Lionel
Lionel
Signed-off-by: Lionel Landwerlin
---
lib/igt_kms.c | 1 +
lib/igt_kms.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 90c8da7..dd4ca45 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1047,6 +1047,7 @@ void
== Series Details ==
Series: Pipe level color management (rev9)
URL : https://patchwork.freedesktop.org/series/2720/
State : failure
== Summary ==
Series 2720v9 Pipe level color management
http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/9/mbox/
Test kms_flip:
Subgroup
Split the function of "enable_guc_submission" into two separate options.
The new one "enable_guc_loading" controls only the *fetching and loading*
of the GuC firmware image. The existing one is redefined to control only
the *use* of the GuC for batch submission once the firmware is loaded.
In
We recently implemented a Kernel workaround that deactivates FBC in
case the FBC frontbuffer was ever CPU or WC mmapped. Change the test
suite to take this into account, otherwise we'll fail many tests with
!fbc_enabled assertions.
Also notice that if your Kernel doesn't have the workaround, then
We're studying the possibility to implement a Kernel FBC workaround
that will deactivate FBC every time the FBC frontbuffer was ever
CPU/WC mmapped. Due to this, we can't just reuse our FBs between
tests: the test suite will eventually CPU mmap every buffer, so FBC
will be disabled forever. In
Let's be good citizens and properly handle our garbage.
Signed-off-by: Paulo Zanoni
---
tests/kms_frontbuffer_tracking.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 26e12d0..0ea1dde
While PSR has problems with GTT mmaps, we're studying the possibility
of implementing a workaround for FBC that affects CPU and WC mmaps. So
prefer the BLT method since it behaves the same with both features.
Signed-off-by: Paulo Zanoni
---
I never got a CI email for this (probably because fdo was down for a while),
but I can see the results below in patchwork
> Test gem_cs_prefetch:
> Subgroup basic-default:
> incomplete -> PASS (ilk-hp8440p)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
Now that we're more protected against user space doing frontbuffer
mmap rendering, the last - how many times did I say this before? -
SKL problem seems to be solved. So let's give it a try.
If you reached this commit through git bisect or if you just want more
information about FBC, please see:
On Wed, Feb 24, 2016 at 07:13:46PM +0530, Deepak M wrote:
> From: Yogesh Mohan Marimuthu
>
> The GPIO configuration and register offsets are different from
> baytrail for cherrytrail. Port the gpio programming accordingly
> for cherrytrail in this patch.
>
>
Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.
v2: Read GAMMA_MODE register value at init (Matt Roper's comment)
v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).
Signed-off-by:
Patch based on a previous series by Shashank Sharma.
v2: Update contributors
v3: Refactor degamma/gamma LUTs load into a single function
v4: Remove unused variable
Signed-off-by: Shashank Sharma
Signed-off-by: Lionel Landwerlin
Patch based on a previous series by Shashank Sharma.
This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix
This series introduces pipe level color management through a set of properties
attached to the CRTC. It also provides an implementation for some Intel
platforms.
This series is based of a previous set of patches by Shashank Sharma.
Cheers,
Lionel
v9: Rebase on nightly
Lionel Landwerlin (5):
Patch based on a previous series by Shashank Sharma.
v2: Do not read GAMMA_MODE register to figure what mode we're in
v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0
Add documentation on how the Broadcast RGB property is affected by CTM
v4: Update contributors
v5: Refactor
The moves a couple of functions programming the gamma LUT and CSC
units into their own file.
On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
From: Daniele Ceraolo Spurio
The hangcheck logic will not flag an hang if acthd keeps increasing.
However, if a malformed batch jumps to an invalid offset in the ppgtt it
can potentially continue executing through the whole address space
without triggering the
Unfortunately MST is a wild beast, and doesn't work at all like other
connectors. This being said, putting it above intel_display_resume() was the
first thing I tried but that didn't work. Originally I had thought putting it
this high up was required because I had assumed drm_mode_config_reset()
-Original Message-
From: Tian, Kevin
Sent: Wednesday, February 24, 2016 4:50 PM
To: Wang, Zhi A; intel-gfx@lists.freedesktop.org; igv...@lists.01.org
Cc: Lv, Zhiyuan; Niu, Bing; Song, Jike; daniel.vet...@ffwll.ch; Cowperthwaite,
David J; ch...@chris-wilson.co.uk;
On 24/02/16 16:49, yu@intel.com wrote:
From: Alex Dai
This version of GuC firmware fixes the engine reset issue where golden
context LRC address is treated as page index by mistake. It also fixes
the problem that scheduler stops submiting to one engine when the other
Hello all,
I recently updated the graphics drivers on a large amount of office machines
and noticed that some of the machines are now showing graphical corruption
on icons and other parts of the XFCE4 interface (e.g. the clock or icons on
the panel) when you mouse over them (when the icon should
On Thu, Feb 25, 2016 at 11:10 AM, Patchwork
wrote:
== Series Details ==
Series: drm/i915/lrc: Only set RS ctx enable in ctx control reg if there
is a RS (rev2)
URL : https://patchwork.freedesktop.org/series/3725/
State : failure
== Summary ==
Series 3725v2
On Tue, Feb 16, 2016 at 09:44:55AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Set cdclk based on the max required pixel clock based on VCO
> selected. Track boot vco instead of boot cdclk.
>
> The vco is now tracked at the atomic level and all
On ke, 2016-02-24 at 07:42 +, Tian, Kevin wrote:
> > From: Wang, Zhi A
> > Sent: Tuesday, February 23, 2016 9:23 PM
> > > > --- a/drivers/gpu/drm/i915/gvt/gvt.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> > > > @@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private
> >
From: Ville Syrjälä
To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.
v2: Let's not forget DDI, toss in a debug message while at it
Signed-off-by: Ville Syrjälä
On 25/02/16 10:05, Chris Wilson wrote:
On Wed, Feb 24, 2016 at 10:02:58AM +, Dave Gordon wrote:
@@ -907,7 +942,8 @@ int intel_logical_ring_reserve_space(struct
drm_i915_gem_request *request)
* adding any commands to it then there might not actually be
* sufficient room
On 25/02/16 11:32, Chris Wilson wrote:
On Thu, Feb 25, 2016 at 11:12:06AM +, Daniele Ceraolo Spurio wrote:
On 25/02/16 10:41, Chris Wilson wrote:
On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote:
+/* This test covers the case where we end up in an
== Series Details ==
Series: Pipe level color management (rev8)
URL : https://patchwork.freedesktop.org/series/2720/
State : failure
== Summary ==
Series 2720v8 Pipe level color management
2016-02-25T10:37:34.469471
http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/8/mbox/
== Series Details ==
Series: series starting with [1/2] drm/i915: Update VBT fields for child devices
URL : https://patchwork.freedesktop.org/series/3785/
State : failure
== Summary ==
Series 3785v1 Series without cover letter
On Thu, Feb 25, 2016 at 11:12:06AM +, Daniele Ceraolo Spurio wrote:
>
>
> On 25/02/16 10:41, Chris Wilson wrote:
> >On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com
> >wrote:
> >>+/* This test covers the case where we end up in an uninitialised area of
> >>the
>
== Series Details ==
Series: drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a
RS (rev2)
URL : https://patchwork.freedesktop.org/series/3725/
State : failure
== Summary ==
Series 3725v2 drm/i915/lrc: Only set RS ctx enable in ctx control reg if there
is a RS
On 25/02/16 10:41, Chris Wilson wrote:
On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote:
+/* This test covers the case where we end up in an uninitialised area of the
+ * ppgtt at an offset greater than the one where the last buffer is mapped.
This
+ * is
Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.
v2: Read GAMMA_MODE register value at init (Matt Roper's comment)
v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).
Signed-off-by:
Patch based on a previous series by Shashank Sharma.
v2: Update contributors
v3: Refactor degamma/gamma LUTs load into a single function
v4: Remove unused variable
Signed-off-by: Shashank Sharma
Signed-off-by: Lionel Landwerlin
Patch based on a previous series by Shashank Sharma.
This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix
The moves a couple of functions programming the gamma LUT and CSC
units into their own file.
On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote:
> +/* This test covers the case where we end up in an uninitialised area of the
> + * ppgtt at an offset greater than the one where the last buffer is mapped.
> This
> + * is particularly relevant if 48b ppgtt is
On Wed, Feb 24, 2016 at 10:02:58AM +, Dave Gordon wrote:
> @@ -907,7 +942,8 @@ int intel_logical_ring_reserve_space(struct
> drm_i915_gem_request *request)
>* adding any commands to it then there might not actually be
>* sufficient room for the submission commands.
>*/
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
---
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic.
The driver should only set the "RS context enable" bit in the context
image if we plan to use the resource streamer.
Reviewed-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
1 file changed, 2
The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.
Changes since v1:
- Return early when encoder_mask is empty,
Hi,
On 25 February 2016 at 05:15, Tian, Kevin wrote:
> I had some replies to this mailing list yesterday, but received below
> notification:
>
> ---
> Delivery is delayed to these recipients or groups:
>
> intel-gfx@lists.freedesktop.org
>
> Subject: RE: [RFCv2 PATCH
76 matches
Mail list logo