Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

On 01/04/2016 12:57 PM, Chris Wilson wrote: > On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote: >> So this one has my ack. > > This series makes a number of fundamental mistakes in seqno-interrupt > handling, so no. Well unless you can enumerate the issues in enough detail for us to

Re: [Intel-gfx] [PATCH 18/32] drm/i915: Use HWS for seqno tracking everywhere

On Mon, Jan 04, 2016 at 06:11:56PM +, Dave Gordon wrote: > So previously, we wrote the seqno and other dummy data into the > SCRATCH page, whereas now it's going to the HWSP. Does that make the > scratch page redundant? Or are there other bits of code that write > other stuff into it? The

Re: [Intel-gfx] [PATCH v2, 2/4] drm/i915: simplify testing for the global default context

On Mon, Jan 04, 2016 at 05:43:10PM +, Dave Gordon wrote: > On 23/12/15 21:02, Chris Wilson wrote: > >On Wed, Dec 23, 2015 at 07:33:53PM +, Dave Gordon wrote: > >>There are quite a number of places where the driver tests whether > >>a given context is or is not the global default context,

Re: [Intel-gfx] [PATCH v2 0/5] Add GuC ADS (Addition Data Structure)

On 18/12/15 20:00, yu@intel.com wrote: From: Alex Dai The GuC firmware uses this for various purposes. The ADS itself is a chunk of memory created by driver to share with GuC. This series creates the GuC ADS object and setup some basic settings for it. This version

Re: [Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

Hi! > > I then ran a git bissect between v4.0 and v4.1 from Linus's tree and > > found the "guilty" commit was > > > > commit 317b4e903636305cfe702ab3e5b3d68547a69e72 > > Author: Ben Widawsky > > Date: Mon Mar 16 16:00:55 2015 + > > > > drm/i915: Extract

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote: > So this one has my ack. This series makes a number of fundamental mistakes in seqno-interrupt handling, so no. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx

Re: [Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

On Mon, Jan 04, 2016 at 09:12:11PM +0100, Pavel Machek wrote: > Hi! > > > > I then ran a git bissect between v4.0 and v4.1 from Linus's tree and > > > found the "guilty" commit was > > > > > > commit 317b4e903636305cfe702ab3e5b3d68547a69e72 > > > Author: Ben Widawsky

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 79686f613b3955a4ed09cee936e7f70ec4e61b67 drm-intel-nightly: 2015y-12m-30d-11h-59m-54s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) Test kms_flip: Subgroup basic-flip-vs-dpms:

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On 14/12/15 15:11, Chris Wilson wrote: On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote: Hi, On 11/12/15 11:33, Chris Wilson wrote: Now that we have split out the seqno-barrier from the engine->get_seqno() callback itself, we can move the users of the seqno-barrier to the

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote: > On 14/12/15 15:11, Chris Wilson wrote: > >On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote: > >> > >>Hi, > >> > >>On 11/12/15 11:33, Chris Wilson wrote: > >>>Now that we have split out the seqno-barrier from the >

Re: [Intel-gfx] [RFC] drm/i915/bxt: Add pipe_src size property

Hey, Op 23-12-15 om 12:05 schreef Nabendu Maiti: > This patch is adding pipesource size as property as intel property.User > application is allowed to change the pipe source size in runtime on BXT/SKL. > Added the property as inteli crtc property. > > Comments and suggestions are requested for

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == HEAD is now at c1e9dc2 drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC integration manifest Applying: drm/i915: Force clean compilation with -Werror Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 drm/i915:

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) Subgroup basic-flip-vs-modeset:

[Intel-gfx] [PATCH v2 2/6] drm/atomic: Add __drm_atomic_helper_connector_reset, v2.

This is useful for drivers that subclass connector_state, like tegra. Changes since v1: - Docbook updates. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 30 ++ include/drm/drm_atomic_helper.h | 2

[Intel-gfx] [PATCH v2 1/6] drm/i915: Set connector_state->connector using the helper.

The atomic helper sets connector_state->connector, which the i915 code didn't. This will become a problem when we start using it. Signed-off-by: Maarten Lankhorst Acked-by: Thierry Reding --- drivers/gpu/drm/i915/intel_display.c | 6 ++

[Intel-gfx] [PATCH v2 3/6] drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state, v2.

Changes since v1: - Do not reset if state allocation fails. Signed-off-by: Maarten Lankhorst Acked-by: Thierry Reding #irc --- drivers/gpu/drm/tegra/dsi.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git

[Intel-gfx] [PATCH v2 6/6] drm/atomic: Remove drm_atomic_connectors_for_crtc.

Now that connector_mask is reliable there's no need for this function any more. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic.c| 30 -- drivers/gpu/drm/drm_atomic_helper.c | 10 --

[Intel-gfx] [PATCH v2 5/6] drm/i915: Update connector_mask during readout.

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index

[Intel-gfx] [PATCH v2 4/6] drm/atomic: add connector mask to drm_crtc_state.

It can be useful to iterate over connectors without grabbing connection_mutex. It can also be used to see how many connectors are on a crtc without iterating over the list. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic.c | 11 +++

[Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation

The current error path for failure when establishing a handle for a GEM object is unbalance, e.g. we call object_close() without calling first object_open(). Use the typical onion structure to only undo what has been set up prior to the error. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 2/3] drm: Only bump object-reference count when adding first handle

We only need a single reference count for all handles (i.e. non-zero obj->handle_count) and so can trim a few atomic operations by only taking the reference on the first handle and dropping it after the last. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_gem.c |

[Intel-gfx] [PATCH 3/3] drm: Use a normal idr allocation for the obj->name

Unlike the handle, the name table uses a sleeping mutex rather than a spinlock. The allocation is in a normal context, and we can use the simpler sleeping gfp_t, rather than have to take from the atomic reserves. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH] drm/i915: Force clean compilation with -Werror

Our driver compiles clean (nowadays thanks to 0day) but for me, at least, it would be beneficial if the compiler threw an error rather than a warning when it found a piece of suspect code. (I use this to compile-check patch series and want to break on the first compiler error in order to fix the

[Intel-gfx] [PATCH v5 2/3] drm/i915: Check DP no aux transaction bit on link training

Check if no AUX transactions are required on DP link training. If this bit is set, we can reuse the known good drive current and pre-emphasis level from the last "full" link training. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393 Signed-off-by: Mika Kahola

[Intel-gfx] [PATCH v5 3/3] drm/i915: DP channel EQ check for use of DP link training optimization

Don't use DP link training optimization if channel EQ is not ok. It has been reported that in case of failure in channel EQ check the link training optimization can be enabled and therefore may not be able to reuse the previously computed drive current and pre-emphasis levels. Bugzilla:

[Intel-gfx] [PATCH v5 0/3] drm/i915: Disable link training optimization if DP config has changed

These three patches are fixes for DP link trainging failures and flickering issues reported by Mika Kahola (3): drm/i915: Disable fast link training if DP config changes drm/i915: Check DP no aux transaction bit on link training drm/i915: DP channel EQ check for use of DP link training

[Intel-gfx] [PATCH v5 1/3] drm/i915: Disable fast link training if DP config changes

Disable DP link training optimization if DP link configuration changes. If one of the DP link parameters i.e. link rate or lane count changes the link training does no longer apply the previously computed drive current and pre-emphasis level. Instead, the link training is started with zero values.

Re: [Intel-gfx] LPSS backlight control (Dell Venue 8 Pro)

On 01/04/2016 03:12 PM, Jani Nikula wrote: On Fri, 01 Jan 2016, "C. B." wrote: Hello All, Re: http://lists.freedesktop.org/archives/intel-gfx/2015-April/065313.html Recently I noticed another device Dell Venue 8 Pro (BYT-CR) which should be using LPSS backlight control.

Re: [Intel-gfx] [PATCH v5 0/3] drm/i915: Disable link training optimization if DP config has changed

On Mon, 2016-01-04 at 13:11 +0100, Maarten Lankhorst wrote: > Op 04-01-16 om 12:21 schreef Mika Kahola: > > These three patches are fixes for DP link trainging failures and flickering > > issues > > reported by > Did your message get accidentally truncated here? It seems. The story should

Re: [Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation

On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote: > The current error path for failure when establishing a handle for a GEM > object is unbalance, e.g. we call object_close() without calling first > object_open(). Use the typical onion structure to only undo what has > been set up

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC integration manifest Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (skl-i7k-2) Test gem_cpu_reloc: Subgroup basic:

Re: [Intel-gfx] [PATCH v5 0/3] drm/i915: Disable link training optimization if DP config has changed

Op 04-01-16 om 12:21 schreef Mika Kahola: > These three patches are fixes for DP link trainging failures and flickering > issues > reported by Did your message get accidentally truncated here? > Mika Kahola (3): > drm/i915: Disable fast link training if DP config changes > drm/i915: Check DP

Re: [Intel-gfx] LPSS backlight control (Dell Venue 8 Pro)

On Fri, 01 Jan 2016, "C. B." wrote: > Hello All, > > Re: http://lists.freedesktop.org/archives/intel-gfx/2015-April/065313.html > >>Recently I noticed another device Dell Venue 8 Pro (BYT-CR) which >>should be using LPSS backlight control. There is already a LPSS PWM >>chip

Re: [Intel-gfx] [PATCH v2, 2/4] drm/i915: simplify testing for the global default context

On 01/04/2016 11:39 AM, Chris Wilson wrote: > On Mon, Jan 04, 2016 at 05:43:10PM +, Dave Gordon wrote: >> On 23/12/15 21:02, Chris Wilson wrote: >>> On Wed, Dec 23, 2015 at 07:33:53PM +, Dave Gordon wrote: There are quite a number of places where the driver tests whether a given

[Intel-gfx] [PATCH] drm/i915: Allow a way to disable watermark for debuging purposes.

Without watermark the power consumption will blow up, but when enabling platforms and dealing with different kinds of crashes, screen corruptions, pipe underuns, etc we need to be able to easily disable watermark to see if we are on the right investigation track. Another possibility was to skip

Re: [Intel-gfx] [PATCH 21/32] drm/i915: Broadwell execlists needs exactly the same seqno w/a as legacy

On 12/11/2015 03:33 AM, Chris Wilson wrote: > + * Note that this effectively effectively stalls the read by the time > + * it takes to do a memory transaction, which more or less ensures > + * that the write from the GPU has sufficient time to invalidate > + * the CPU

[Intel-gfx] [PATCH 3/3] drm/i915: Move HAS_CORE_RING_FREQ definition to the platform definition.

No functional changes with this patch. The idea is just to organize the platform features in a standard place making new platform aditions easily and possible to see all the present features of the platform on the intel info dumped information at dmesg. Also for this one it is better to put the

[Intel-gfx] [PATCH 1/3] drm/i915: Move HAS_PSR definition to the platform definition.

No functional changes with this patch. The idea is just to organize the platform features in a standard place making new platform aditions easily and possible to see all the present features of the platform on the intel info dumped information at dmesg. Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 2/3] drm/i915: Move HAS_RUNTIME_PM definition to the platform definition.

No functional changes with this patch. The idea is just to organize the platform features in a standard place making new platform aditions easily and possible to see all the present features of the platform on the intel info dumped information at dmesg. (I just wonder why Ivy Bridge doesn't have

Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.

Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle delay calculation(Ville). Cc: Ville Syrjälä Signed-off-by: Abhay

[Intel-gfx] [PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c

This patch fix some spelling typos found in Documentation/Docbook gpu/ch04s03.html. This file was generated from comments within source, so I have to fix typos in i915_gem_fence.c. Signed-off-by: Masanari Iida --- drivers/gpu/drm/i915/i915_gem_fence.c | 10 +- 1

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Derive GEM requests from dma-fence

On 12/12/15 15:34, Chris Wilson wrote: dma-buf provides a generic fence class for interoperation between drivers. Internally we use the request structure as a fence, and so with only a little bit of interfacing we can rebase those requests on top of dma-buf fences. This will allow us, in the

Re: [Intel-gfx] [PATCH] drm/i915: Add RPM references in the *_get_hw_state functions

Hi, I'm still seeing these warning(s) with both this patch and the one for i915_driver_unload() (http://patchwork.freedesktop.org/patch/69227/), in more than two cases: $ tests/kms_flip --run-subtest basic-flip-vs-wf_vblank [ 226.580012] [

Re: [Intel-gfx] [PATCH v2] drm/i915: Add RPM references in the *_get_hw_state functions

Hey, Op 31-12-15 om 16:52 schreef Gabriel Feceoru: > This gets rid of errors like: > > [ 906.286213] [ cut here ] > [ 906.286233] WARNING: CPU: 0 PID: 12252 at > drivers/gpu/drm/i915/intel_drv.h:1457 gen6_read32+0x1ca/0x1e0 [i915]() > [ 906.286234] RPM wakelock ref not

Re: [Intel-gfx] [PATCH] drm/i915/skl: Increase ddb blocks to support large cursor sizes

On 12/23/2015 08:22 AM, Kumar, Shobhit wrote: On 12/21/2015 05:39 PM, Daniel Vetter wrote: On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote: On Fri, Dec 18, 2015 at 07:14:17AM -0800, Matt Roper wrote: On Fri, Dec 18, 2015 at 05:10:12PM +0200, Ville Syrjälä wrote: On Fri, Dec 18,

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On Mon, Jan 04, 2016 at 01:02:25PM +, Dave Gordon wrote: > On 04/01/16 11:26, Chris Wilson wrote: > >On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote: > >>On 14/12/15 15:11, Chris Wilson wrote: > >>>On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote: > > Hi, >

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On Mon, Jan 04, 2016 at 02:09:53PM +, Dave Gordon wrote: > On 04/01/16 13:02, Dave Gordon wrote: > >On 04/01/16 11:26, Chris Wilson wrote: > >>On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote: > >>>On 14/12/15 15:11, Chris Wilson wrote: > On Mon, Dec 14, 2015 at 02:59:30PM

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) Test kms_flip: Subgroup basic-flip-vs-dpms:

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Derive GEM requests from dma-fence

On Mon, Jan 04, 2016 at 12:17:47PM +, Dave Gordon wrote: > On 12/12/15 15:34, Chris Wilson wrote: > >dma-buf provides a generic fence class for interoperation between > >drivers. Internally we use the request structure as a fence, and so with > >only a little bit of interfacing we can rebase

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On 04/01/16 11:26, Chris Wilson wrote: On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote: On 14/12/15 15:11, Chris Wilson wrote: On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote: Hi, On 11/12/15 11:33, Chris Wilson wrote: Now that we have split out the seqno-barrier

Re: [Intel-gfx] [PATCH v2] i915: correctly handling failed allocation

On Wed, 30 Dec 2015, Insu Yun wrote: > Since devm_kzalloc can be failed, it needs to be checked > if not, NULL dereference could be happened. > > Signed-off-by: Insu Yun Pushed to drm-intel-next-queued, thanks for the patch. BR, Jani. > --- >

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On 04/01/16 13:02, Dave Gordon wrote: On 04/01/16 11:26, Chris Wilson wrote: On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote: On 14/12/15 15:11, Chris Wilson wrote: On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote: Hi, On 11/12/15 11:33, Chris Wilson wrote: Now

Re: [Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

Hi, >> Can you verify that reverting this patch (on top of 4.4?) fixes it? >> >> If so, is it time to revert it? >> >> Thanks, >> Pavel > > It's highly unlikely you'll be able to revert this on top of 4.4. > Unfortunately, >

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 0417da5e6f56078d87d366d5f959f8290ae9d16d drm-intel-nightly: 2016y-01m-04d-14h-05m-39s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (skl-i7k-2)

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 0417da5e6f56078d87d366d5f959f8290ae9d16d drm-intel-nightly: 2016y-01m-04d-14h-05m-39s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (skl-i7k-2)

Re: [Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation

On Mon, Jan 04, 2016 at 10:18:50AM +, Chris Wilson wrote: > On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote: > > The current error path for failure when establishing a handle for a GEM > > object is unbalance, e.g. we call object_close() without calling first > > object_open().

Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/kms_chv_cursor_fail: Add a test to exercise CHV pipe C cursor fail

On Mon, Dec 21, 2015 at 10:42:53AM +, Thomas Wood wrote: > On 18 December 2015 at 17:25, wrote: > > From: Ville Syrjälä > > > > The test tries to anger CHV pipe C cursor by walking the edges of the > > screen while moving the

Re: [Intel-gfx] [PATCH v2] drm/i915: Add RPM references in the *_get_hw_state functions

On Thu, Dec 31, 2015 at 05:52:07PM +0200, Gabriel Feceoru wrote: > This gets rid of errors like: > > [ 906.286213] [ cut here ] > [ 906.286233] WARNING: CPU: 0 PID: 12252 at > drivers/gpu/drm/i915/intel_drv.h:1457 gen6_read32+0x1ca/0x1e0 [i915]() > [ 906.286234] RPM

Re: [Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation

On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote: > The current error path for failure when establishing a handle for a GEM > object is unbalance, e.g. we call object_close() without calling first > object_open(). Use the typical onion structure to only undo what has > been set up

Re: [Intel-gfx] [PATCH 07/32] drm/i915: Store the reset counter when constructing a request

On 16/12/15 10:19, Chris Wilson wrote: On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote: On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote: As the request is only valid during the same global reset epoch, we can record the current reset_counter when constructing the

Re: [Intel-gfx] [PATCH 2/3] drm: Only bump object-reference count when adding first handle

On Mon, Jan 04, 2016 at 10:11:00AM +, Chris Wilson wrote: > We only need a single reference count for all handles (i.e. non-zero > obj->handle_count) and so can trim a few atomic operations by only > taking the reference on the first handle and dropping it after the last. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 3/3] drm: Use a normal idr allocation for the obj->name

On Mon, Jan 04, 2016 at 10:11:01AM +, Chris Wilson wrote: > Unlike the handle, the name table uses a sleeping mutex rather than a > spinlock. The allocation is in a normal context, and we can use the > simpler sleeping gfp_t, rather than have to take from the atomic > reserves. > >

Re: [Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation

On Mon, Jan 04, 2016 at 05:24:11PM +0200, Ville Syrjälä wrote: > On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote: > > The current error path for failure when establishing a handle for a GEM > > object is unbalance, e.g. we call object_close() without calling first > > object_open().

Re: [Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation

On Mon, Jan 04, 2016 at 05:33:45PM +0200, Ville Syrjälä wrote: > On Mon, Jan 04, 2016 at 10:18:50AM +, Chris Wilson wrote: > > On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote: > > > The current error path for failure when establishing a handle for a GEM > > > object is unbalance,

Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce for_each_engine(), rework for_each_ring()

On 29/12/15 19:18, Chris Wilson wrote: On Tue, Dec 29, 2015 at 06:59:57PM +, Dave Gordon wrote: In the discussions around commit 373701b1 (Jani Nikula) drm: fix potential dangling else problems in for_each_ macros Daniel Vetter mooted the idea of a for_each_engine(ring, dev_priv) macro

Re: [Intel-gfx] [PATCH 07/32] drm/i915: Store the reset counter when constructing a request

On Mon, Jan 04, 2016 at 03:58:21PM +, Dave Gordon wrote: > On 16/12/15 10:19, Chris Wilson wrote: > >On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote: > >>On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote: > >>>@@ -1288,7 +1286,7 @@ int __i915_wait_request(struct

Re: [Intel-gfx] [PATCH i-g-t 4/6] lib: Add igt_pipe_crc_new_nonblock()

On Mon, Dec 21, 2015 at 04:53:34PM +0100, Daniel Vetter wrote: > On Fri, Dec 18, 2015 at 07:25:48PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Add support for reading the CRC in non-blocking mode. Useful for tests > > that want to

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915: DP channel EQ check for use of DP link training optimization

On Mon, Jan 04, 2016 at 06:44:09PM +0200, Ville Syrjälä wrote: > On Mon, Jan 04, 2016 at 01:21:24PM +0200, Mika Kahola wrote: > > Don't use DP link training optimization if channel EQ is not ok. It has > > been reported that in case of failure in channel EQ check the link training > > optimization

Re: [Intel-gfx] [RFC] drm/i915/bxt: Add pipe_src size property

On Mon, Jan 04, 2016 at 11:16:39AM +0100, Maarten Lankhorst wrote: > Hey, > > Op 23-12-15 om 12:05 schreef Nabendu Maiti: > > This patch is adding pipesource size as property as intel property.User > > application is allowed to change the pipe source size in runtime on BXT/SKL. > > Added the

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

On 12/17/2015 09:43 AM, Jesse Barnes wrote: > On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote: >> From: John Harrison >> >> There is a construct in the linux kernel called 'struct fence' that is >> intended to keep track of work that is executed on hardware.

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Check DP no aux transaction bit on link training

On Tue, Dec 22, 2015 at 04:53:41PM +0100, Lukas Wunner wrote: > Hi Mika, > > On Mon, Dec 21, 2015 at 01:39:15PM +0200, Mika Kahola wrote: > > Check if no AUX transactions are required on DP link training. > > If this bit is set, we can reuse the known good drive current > > and pre-emphasis level

Re: [Intel-gfx] [PATCH 17/32] drm/i915: Remove the lazy_coherency parameter from request-completed?

On 04/01/16 14:20, Chris Wilson wrote: On Mon, Jan 04, 2016 at 02:09:53PM +, Dave Gordon wrote: On 04/01/16 13:02, Dave Gordon wrote: On 04/01/16 11:26, Chris Wilson wrote: On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote: On 14/12/15 15:11, Chris Wilson wrote: On Mon, Dec

Re: [Intel-gfx] [PATCH v2, 2/4] drm/i915: simplify testing for the global default context

On 23/12/15 21:02, Chris Wilson wrote: On Wed, Dec 23, 2015 at 07:33:53PM +, Dave Gordon wrote: There are quite a number of places where the driver tests whether a given context is or is not the global default context, usually by checking whether an engine's default_pointer points to the

Re: [Intel-gfx] [PATCH 07/32] drm/i915: Store the reset counter when constructing a request

On 04/01/16 16:10, Chris Wilson wrote: On Mon, Jan 04, 2016 at 03:58:21PM +, Dave Gordon wrote: On 16/12/15 10:19, Chris Wilson wrote: On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote: On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote: @@ -1288,7 +1286,7 @@ int

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915: DP channel EQ check for use of DP link training optimization

On Mon, Jan 04, 2016 at 01:21:24PM +0200, Mika Kahola wrote: > Don't use DP link training optimization if channel EQ is not ok. It has > been reported that in case of failure in channel EQ check the link training > optimization can be enabled and therefore may not be able to reuse the > previously

Re: [Intel-gfx] [PATCH 2/2] drm/i915: add dp mst judgement in hsw_audio_codec_enable

On Wed, Dec 23, 2015 at 02:50:47PM +0800, libin.y...@linux.intel.com wrote: > From: Libin Yang > > hsw platforms supports DP MST while ilk doesn't. > This patch fixes the bug. > > Signed-off-by: Libin Yang > --- >

Re: [Intel-gfx] [PATCH i-g-t 2/6] lib: Extract ssme common fb create+fill methods into helpers

On Mon, Dec 21, 2015 at 10:42:46AM +, Thomas Wood wrote: > On 18 December 2015 at 17:25, wrote: > > From: Ville Syrjälä > > > > Several tests do one or more of the followin: > > * igt_create_fb() + igt_paint_test_pattern() > > *

Re: [Intel-gfx] [PATCH v5 1/3] drm/i915: Disable fast link training if DP config changes

On Mon, Jan 04, 2016 at 01:21:22PM +0200, Mika Kahola wrote: > Disable DP link training optimization if DP link configuration > changes. If one of the DP link parameters i.e. link rate or > lane count changes the link training does no longer apply the > previously computed drive current and

Re: [Intel-gfx] [PATCH 18/32] drm/i915: Use HWS for seqno tracking everywhere

On 11/12/15 11:33, Chris Wilson wrote: By using the same address for storing the HWS on every platform, we can remove the platform specific vfuncs and reduce the get-seqno routine to a single read of a cached memory location. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Wed, Dec 30, 2015 at 09:48:43AM +1000, Dave Airlie wrote: > On 11 Dec 2015 7:09 PM, "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