Re: [Intel-gfx] snd-hda-intel runtime PM fail after module reload

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 > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

== 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)

[Intel-gfx] High power use from Xorg on skylake dual graphics with intel

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,

Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

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

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

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

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

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

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

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

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

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; }

Re: [Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

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; > >

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement color management on chv

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

Re: [Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

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

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Adding missing IS_KABYLAKE checks.

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

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

Re: [Intel-gfx] [PATCH V7] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

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

Re: [Intel-gfx] [PATCH] drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

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

Re: [Intel-gfx] snd-hda-intel runtime PM fail after module reload

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

[Intel-gfx] [PATCH] drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

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

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

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

Re: [Intel-gfx] snd-hda-intel runtime PM fail after module reload

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

[Intel-gfx] snd-hda-intel runtime PM fail after module reload

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.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Some FDI related dotclock stuff

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: add enable_guc_loading parameter (rev2)

== 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/

Re: [Intel-gfx] [PATCH 044/190] drm/i915: Move GEM request routines to i915_gem_request.c

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v3)

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: >

Re: [Intel-gfx] [PATCH 042/190] drm/i915: Clean up GPU hang message

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

Re: [Intel-gfx] [PATCH 039/190] drm/i915: Remove stop-rings debugfs interface

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] drm/i915: opt-out CPU and WC mmaps from FBC

== 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

[Intel-gfx] [PATCH i-g-t 3/5] lib: fb: add igt_paint_color_gradient_range

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

[Intel-gfx] [PATCH i-g-t 5/5] tests/kms_color: New test for pipe level color management

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

[Intel-gfx] [PATCH i-g-t 4/5] lib: add crc comparison function without an assert

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 +++

[Intel-gfx] [PATCH i-g-t 2/5] lib: kms: add helpers for color management properties on pipes

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

[Intel-gfx] [PATCH i-g-t 0/5] New pipe level color management tests V5

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

[Intel-gfx] [PATCH i-g-t 1/5] lib: kms: add crtc_id to igt_pipe_t

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev9)

== 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

[Intel-gfx] [PATCH] drm/i915: add enable_guc_loading parameter

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

[Intel-gfx] [PATCH igt 4/4] kms_frontbuffer_tracking: be aware of the new FBC Kernel workaround

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

[Intel-gfx] [PATCH igt 3/4] kms_frontbuffer_tracking: recreate the FBs at every subtest

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

[Intel-gfx] [PATCH igt 1/4] kms_frontbuffer_tracking: add missing igt_remove_fb calls

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

[Intel-gfx] [PATCH igt 2/4] kms_frontbuffer_tracking: prefer the BLT drawing method

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 ---

Re: [Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

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:

[Intel-gfx] [PATCH 2/2] drm/i915/fbc: enable FBC on SKL too

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:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: GPIO for CHT generic MIPI

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. > >

[Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

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:

[Intel-gfx] [PATCH 5/5] drm/i915: Implement color management on chv

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

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

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

[Intel-gfx] [PATCH 0/5] Pipe level color management V9

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):

[Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

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

[Intel-gfx] [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

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,

[Intel-gfx] [PATCH i-g-t v3] tests/drv_hangman: test for acthd increasing through invalid VM space

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

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

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()

Re: [Intel-gfx] [RFCv2 10/14] drm/i915: update PDPs by condition when submit the LRC context

-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;

Re: [Intel-gfx] [PATCH] drm/i915/guc: Support GuC SKL v6.1

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

[Intel-gfx] Graphical Corruption on Series 4 Chipset using xf86-video-intel

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS (rev2)

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

Re: [Intel-gfx] [PATCH V7] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

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

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

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 > >

[Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

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ä

Re: [Intel-gfx] [PATCH v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev8)

== 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/

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Update VBT fields for child devices

== 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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

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 >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS (rev2)

== 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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

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

[Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

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:

[Intel-gfx] [PATCH 5/5] drm/i915: Implement color management on chv

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

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

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

[Intel-gfx] [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

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,

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

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

Re: [Intel-gfx] [PATCH v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

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. >*/

[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

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 ---

[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

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.

[Intel-gfx] [PATCH RESEND_FOR_CI] drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS

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

Re: [Intel-gfx] [PATCH v2.1 5/6] drm/atomic: Handle encoder assignment conflicts in a separate check, v2.

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,

Re: [Intel-gfx] Delayed mail delivery problem

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