Re: [Intel-gfx] [PATCH 1/2] drm/i915: Don't clobber the addfb2 ioctl params

On Tue, Nov 17, 2015 at 10:47:06AM +0100, Daniel Vetter wrote: > On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We try to convert the old way of of specifying fb tiling (obj->tiling) > > into the new

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect

On Tuesday 17 November 2015 02:52 PM, Ander Conselvan De Oliveira wrote: On Tue, 2015-11-17 at 11:47 +0530, Shubhangi Shrivastava wrote: On Monday 16 November 2015 07:10 PM, Ander Conselvan De Oliveira wrote: On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote: This patch moves

Re: [Intel-gfx] [PATCH 1/8] drm: Add crtc->name and use it in debug messages

On Tue, Nov 17, 2015 at 11:15:43AM +0100, Daniel Vetter wrote: > On Fri, Nov 13, 2015 at 01:03:48PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 13, 2015 at 12:18:24PM +0200, Jani Nikula wrote: > > > On Thu, 12 Nov 2015, ville.syrj...@linux.intel.com wrote: > > > > diff --git

Re: [Intel-gfx] [PATCH 1/4] drm: Fix primary plane size for stereo doubled modes for legacy setcrtc

On Mon, Nov 16, 2015 at 05:02:34PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Properly double the hdisplay/vdisplay timings that we use as the primary > plane size with stereo doubled modes. Otherwise the modeset gets > rejected on

Re: [Intel-gfx] [PATCH i-g-t] Add dmesg capture and dumping to tests and a test for it.

On 16 November 2015 at 13:22, Joonas Lahtinen wrote: > Cc: Thomas Wood > Cc: Chris Wilson > Cc: Damien Lespiau > Signed-off-by: Joonas Lahtinen > --- >

Re: [Intel-gfx] [PATCH v7 0/3] fbdev fixes (reviewed)

On Fri, Nov 13, 2015 at 09:06:29AM +0200, Jani Nikula wrote: > On Thu, 12 Nov 2015, Lukas Wunner wrote: > >> For future reference, please consider posting new versions of series as > >> new threads. This one got pretty messy in the end, with so many > >> different versions. > > >

[Intel-gfx] [PATCH 1/2] drm/i915: Mark uneven memory banks on gen4 desktop as unknown swizzling

We have varied reports of swizzling corruption on gen4 desktop, and confirmation that it is triggered by uneven memory banks. The implication is that the swizzling various between the paired channels and the remainder of memory on the single channel. As the object then has unpredictable swizzling

[Intel-gfx] [PATCH 2/2] drm/i915: Pin unknown swizzle pages

Another oddity associated with gen4 desktop is that some machines experience swizzling corruption across swapping. Typically this would imply that those machines have bit17 swizzling (where the swizzle depends upon the physical address of the page). Play it safe and apply the bit17 quirk to keep

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark uneven memory banks on gen4 desktop as unknown swizzling

On Tue, Nov 17, 2015 at 10:40:51AM +, Chris Wilson wrote: > We have varied reports of swizzling corruption on gen4 desktop, and > confirmation that it is triggered by uneven memory banks. The s/it/one at least/ > implication is that the swizzling various between the paired channels

[Intel-gfx] [PATCH i-g-t v2] lib/igt_core: Prefer CLOCK_MONOTONIC_RAW

CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock used for timing execution of tests. v2: - Cache the used clock (Chris) - Do not change the clock during execution - Spit out and error if monotonic time can not be read Cc: Thomas Wood Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Cleaning up intel_dp_hpd_pulse

On Tue, 2015-11-17 at 12:23 +0530, Shubhangi Shrivastava wrote: > > On Monday 16 November 2015 08:16 PM, Ander Conselvan De Oliveira wrote: > > On Mon, 2015-11-16 at 16:33 +0200, Ander Conselvan De Oliveira wrote: > > > On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote: > > > >

Re: [Intel-gfx] [PATCH] drm/i915: fix handling of the disable_power_well module option

On Wed, Nov 11, 2015 at 07:03:54PM +0200, Imre Deak wrote: > When this option is 0 (so the power well support is disabled) we are > supposed to enable all power wells once and don't disable them unless we > system suspend the device. Currently if the option is 0, we can call the > power well

[Intel-gfx] [PATCH v2] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

From: Tvrtko Ursulin In the following commit: commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae Author: Tvrtko Ursulin Date: Mon Oct 5 13:26:36 2015 +0100 drm/i915: Clean up associated VMAs on context destruction I added

[Intel-gfx] [PATCH] drm/i915: Fix gpu frequency change tracing

With gen < 9 we have had always 50Mhz units as our hw ratio. With gen >= 9 the hw ratio changed to 16.667Mhz (50/3). The result was that our gpu frequency tracing started to output values 3 times larger than expected due to hardcoded scaling value. Fix this by using Use intel_gpu_freq() when

[Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

From: Tvrtko Ursulin In the following commit: commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae Author: Tvrtko Ursulin Date: Mon Oct 5 13:26:36 2015 +0100 drm/i915: Clean up associated VMAs on context destruction I added

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In the following commit: > > commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae > Author: Tvrtko Ursulin > Date: Mon Oct 5 13:26:36 2015

Re: [Intel-gfx] [PATCH v2] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On Tue, Nov 17, 2015 at 03:53:24PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In the following commit: > > commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae > Author: Tvrtko Ursulin > Date: Mon Oct 5 13:26:36 2015

Re: [Intel-gfx] [PATCH] drm/i915: Fix gpu frequency change tracing

On Tue, Nov 17, 2015 at 06:14:26PM +0200, Mika Kuoppala wrote: > With gen < 9 we have had always 50Mhz units as our hw > ratio. With gen >= 9 the hw ratio changed to 16.667Mhz (50/3). > The result was that our gpu frequency tracing started to output > values 3 times larger than expected due to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

On Fri, Oct 30, 2015 at 04:58:41PM +, Chris Wilson wrote: > On Fri, Oct 30, 2015 at 05:14:21PM +0100, Daniel Vetter wrote: > > On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote: > > > When accessing through the GTT from one CPU whilst concurrently updating > > > the GGTT PTEs in

Re: [Intel-gfx] [PATCH 3/5] drm/atomic: add a drm_atomic_clean_old_fb helper.

Op 11-11-15 om 11:29 schreef Maarten Lankhorst: > From: Maarten Lankhorst > > This is useful for all the boilerplate code about cleaning old_fb. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 2/2] drm: Pass the user drm_mode_fb_cmd2 as const to .fb_create()

This seems to have caused a warning to appear. I generally build with -Werror which means my build is broken :(. intel_display.c: In function 'intel_user_framebuffer_create': i915/intel_display.c(14593)2: warning: passing argument 2 of 'intel_framebuffer_create' discards 'const' qualifier from

Re: [Intel-gfx] [PATCH 2/2] drm/i915: force link training when requested by Sink

On Tue, Nov 17, 2015 at 09:12:58AM +, Shrivastava, Shubhangi wrote: > Hi Daniel, > > Is something else required for this patch series (2 patches) to be merged? Me coming back from vacation ;-) Both patches applied to dinq. Aside: The test request tracking seems a bit too much ad-hoc. But I

Re: [Intel-gfx] [PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array

Em Tue, 17 Nov 2015 07:44:31 -0700 Jonathan Corbet escreveu: > On Tue, 17 Nov 2015 08:40:46 -0200 > Mauro Carvalho Chehab wrote: > > > The above causes some versions of perl to fail, as keys expect a > > hash argument: > > > > Execution of

[Intel-gfx] [PATCH v2] drm/i915: fix handling of the disable_power_well module option

When this option is 0 (so the power well support is disabled) we are supposed to enable all power wells once and don't disable them unless we system suspend the device. Currently if the option is 0, we can call the power well enable handlers multiple times, whenever their refcount changes from

Re: [Intel-gfx] [PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array

On Tue, 17 Nov 2015 08:40:46 -0200 Mauro Carvalho Chehab wrote: > The above causes some versions of perl to fail, as keys expect a > hash argument: > > Execution of .//scripts/kernel-doc aborted due to compilation errors. > Type of arg 1 to keys must be hash (not

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Fix Watermark calculation for Broxton

On 17/11/15 14:52, Jani Nikula wrote: On Tue, 17 Nov 2015, Daniel Vetter wrote: On Fri, Oct 23, 2015 at 09:53:35AM -0700, Matt Roper wrote: On Mon, Sep 21, 2015 at 11:41:18PM +0530, Kumar, Mahesh wrote: In case of Y-Tiling, "plane_blocks_per_line" calculation is different

Re: [Intel-gfx] [PATCH i-g-t 2/3] Unify handling of slow/combinatorial tests

On Tue, Oct 27, 2015 at 08:47:28AM +0200, David Weinehall wrote: > On Mon, Oct 26, 2015 at 03:59:24PM -0200, Paulo Zanoni wrote: > > 2015-10-26 15:30 GMT-02:00 David Weinehall > > : > > > On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote: > > >>

[Intel-gfx] [PATCH v2 05/10] drm/i915/skl: init/uninit display core as part of the HW power domain state

We need to initialize the display core part early, before initializing the rest of the display power state. This is also described in the bspec termed "Display initialization sequence". Atm we run this sequence during driver loading after power domain HW state initialization which is too late and

Re: [Intel-gfx] [PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array

On 17-11-2015 13:29, Mauro Carvalho Chehab wrote: > Em Tue, 17 Nov 2015 07:44:31 -0700 > Jonathan Corbet escreveu: > >> On Tue, 17 Nov 2015 08:40:46 -0200 >> Mauro Carvalho Chehab wrote: >> >>> The above causes some versions of perl to fail, as keys

Re: [Intel-gfx] [PATCH i-g-t 2/3] Unify handling of slow/combinatorial tests

2015-11-17 13:34 GMT-02:00 Daniel Vetter : > On Mon, Oct 26, 2015 at 03:59:24PM -0200, Paulo Zanoni wrote: >> 2015-10-26 15:30 GMT-02:00 David Weinehall : >> > On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote: >> >> 2015-10-26 12:59

Re: [Intel-gfx] intel_display.c:3916 intel_crtc_wait_for_pending_flips+0xe9/0x1cd() intel_check_page_flip+0xb3/0xd2()

On Tue, 17 Nov 2015, Marc MERLIN wrote: > So, this is probably the 3rd time I send such a report with different > kernels and get 0 response. > Is this a write only list and no one is really seeing any of them, or is > this an unknown/known problem that no one can work on?

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Use passed plane state for sprite planes, v2.

On Mon, Oct 26, 2015 at 10:30:22AM +0100, Maarten Lankhorst wrote: > Op 22-10-15 om 14:58 schreef Daniel Vetter: > > On Thu, Oct 22, 2015 at 01:56:26PM +0200, Maarten Lankhorst wrote: > >> Don't use plane->state directly, use the pointer from commit_plane. > >> > >> Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Kill off intel_crtc->atomic.wait_vblank.

On Mon, Oct 26, 2015 at 09:31:48AM +0100, Maarten Lankhorst wrote: > Op 22-10-15 om 17:15 schreef Ville Syrjälä: > > On Thu, Oct 22, 2015 at 04:50:05PM +0200, Maarten Lankhorst wrote: > >> Op 22-10-15 om 15:30 schreef Ville Syrjälä: > >>> On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst

Re: [Intel-gfx] [PATCH i-g-t 2/3] Unify handling of slow/combinatorial tests

On Mon, Oct 26, 2015 at 03:59:24PM -0200, Paulo Zanoni wrote: > 2015-10-26 15:30 GMT-02:00 David Weinehall : > > On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote: > >> 2015-10-26 12:59 GMT-02:00 David Weinehall > >> : >

Re: [Intel-gfx] [PATCH 1/4] drm: Fix primary plane size for stereo doubled modes for legacy setcrtc

On Tue, 17 Nov 2015, Daniel Vetter wrote: > On Mon, Nov 16, 2015 at 05:02:34PM +0200, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> Properly double the hdisplay/vdisplay timings that we use as the primary >> plane size with

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Fix Watermark calculation for Broxton

On Tue, 17 Nov 2015, Daniel Vetter wrote: > On Fri, Oct 23, 2015 at 09:53:35AM -0700, Matt Roper wrote: >> On Mon, Sep 21, 2015 at 11:41:18PM +0530, Kumar, Mahesh wrote: >> > In case of Y-Tiling, "plane_blocks_per_line" calculation is different >> > than X/None-Tiling case. >> >

Re: [Intel-gfx] [PATCH 2/2] drm: Pass the user drm_mode_fb_cmd2 as const to .fb_create()

On Tue, 17 Nov 2015, John Harrison wrote: > This seems to have caused a warning to appear. I generally build with > -Werror which means my build is broken :(. > > intel_display.c: In function 'intel_user_framebuffer_create': > i915/intel_display.c(14593)2: warning:

Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.

On Mon, Nov 16, 2015 at 04:05:42PM +, Rodrigo Vivi wrote: > Ok, so after trying it we saw that we really cannot trust on aux mutex.At > least not on all SKL/KBL > It worked in a KBL but failed on a SKL that I have here... > > So without aux mutex option we still need to get sink_crc more

Re: [Intel-gfx] [PATCH v2 0/2] fbdev fixes (need review)

On Sun, Nov 08, 2015 at 01:56:53PM +0100, Lukas Wunner wrote: > On Fri, Oct 30, 2015 at 07:23:45PM +0100, Daniel Vetter wrote: > > I don't think there's a leak here really. We always assign ifbdev->fb in > > intelfb_alloc, which means the fbdev teardown code will take care of it. > > The correct

Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_core: Prefer CLOCK_MONOTONIC_RAW

On Tue, Nov 17, 2015 at 02:18:09PM +0200, Joonas Lahtinen wrote: > CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock > used for timing execution of tests. > > v2: > - Cache the used clock (Chris) > - Do not change the clock during execution > - Spit out and error if monotonic

Re: [Intel-gfx] [PATCH] drm/i915/skl: Correct other-pipe watermark update condition check (v2)

On Fri, Oct 23, 2015 at 09:41:34AM -0700, Matt Roper wrote: > From: "Kumar, Mahesh" > > If ddb allocation for planes in current CRTC is changed, that doesn't > lead to ddb allocation change for other CRTCs, because our DDB allocation > is not dynamic according to plane

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Fix Watermark calculation for Broxton

On Fri, Oct 23, 2015 at 09:53:35AM -0700, Matt Roper wrote: > On Mon, Sep 21, 2015 at 11:41:18PM +0530, Kumar, Mahesh wrote: > > In case of Y-Tiling, "plane_blocks_per_line" calculation is different > > than X/None-Tiling case. > > This patch corrects this calculation according to Bspec. > > plane

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Don't clobber the addfb2 ioctl params

On Tue, 17 Nov 2015, Ville Syrjälä wrote: > On Tue, Nov 17, 2015 at 01:04:21PM +0200, Ville Syrjälä wrote: >> On Tue, Nov 17, 2015 at 10:47:06AM +0100, Daniel Vetter wrote: >> > On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrj...@linux.intel.com >> > wrote: >>

Re: [Intel-gfx] [RFC 5/9] drm/i915: Add per context timelines to fence object

On Wed, Oct 28, 2015 at 12:59:31PM +, John Harrison wrote: > Have finally had some time to come back to this and respond to/incorporate > the comments made some while ago... > > > On 23/07/2015 14:50, Tvrtko Ursulin wrote: > >Hi, > > > >On 07/17/2015 03:31 PM, john.c.harri...@intel.com

Re: [Intel-gfx] [RFC 9/9] drm/i915: Add sync framework support to execbuff IOCTL

On Wed, Oct 28, 2015 at 01:01:17PM +, John Harrison wrote: > On 27/07/2015 14:00, Tvrtko Ursulin wrote: > >On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>Various projects desire a mechanism for managing dependencies between

Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/skl: Do not allow scaling when crtc is disabled.

Op 03-11-15 om 14:11 schreef Ville Syrjälä: > On Tue, Nov 03, 2015 at 01:00:32PM +0100, Maarten Lankhorst wrote: >> Op 03-11-15 om 11:40 schreef Ville Syrjälä: >>> On Tue, Nov 03, 2015 at 11:06:53AM +0100, Maarten Lankhorst wrote: Op 03-11-15 om 10:09 schreef Ville Syrjälä: > On Tue, Nov

Re: [Intel-gfx] [PATCH] drm/i915: Clear intel_crtc->atomic before updating it.

On Mon, 16 Nov 2015, Ville Syrjälä wrote: > On Mon, Nov 16, 2015 at 01:41:54PM +0100, Maarten Lankhorst wrote: >> Op 16-11-15 om 13:35 schreef Jani Nikula: >> > On Mon, 16 Nov 2015, Maarten Lankhorst wrote: >> >> If an atomic update fails

Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/skl: Do not allow scaling when crtc is disabled.

On Tue, Nov 17, 2015 at 02:59:35PM +0100, Maarten Lankhorst wrote: > Op 03-11-15 om 14:11 schreef Ville Syrjälä: > > On Tue, Nov 03, 2015 at 01:00:32PM +0100, Maarten Lankhorst wrote: > >> Op 03-11-15 om 11:40 schreef Ville Syrjälä: > >>> On Tue, Nov 03, 2015 at 11:06:53AM +0100, Maarten Lankhorst

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_tiling IOCTL

On ma, 2015-11-09 at 20:56 +, Chris Wilson wrote: > On Mon, Nov 09, 2015 at 08:16:26PM +0200, Imre Deak wrote: > > After fixing the same issue in the set_caching IOCTL and Chris' > > request > > to check out the possibilities for an improved RPM ref handling I > > noticed that we have the same

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On 17/11/15 17:24, Tvrtko Ursulin wrote: On 17/11/15 17:08, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:54:50PM +, Tvrtko Ursulin wrote: On 17/11/15 16:39, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

On Wed, Nov 04, 2015 at 03:34:54PM +0530, Sagar Arun Kamble wrote: > RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 > setup registers. If those are not setup Driver should not enable RC6. > For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values > to know if

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On 17/11/15 16:39, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In the following commit: commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae Author: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On 17/11/15 17:08, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:54:50PM +, Tvrtko Ursulin wrote: On 17/11/15 16:39, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In the following commit:

Re: [Intel-gfx] [PATCH igt v7 1/4] lib/tests: Add igt_assert_*() self-tests

On Thu, Oct 29, 2015 at 11:03:55AM +, Daniel Stone wrote: > Make sure our igt_assert variants are doing something that looks vaguely > like the right thing. > > Signed-off-by: Daniel Stone > --- > lib/tests/Makefile.sources | 1 + > lib/tests/igt_simple.c | 173

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

On Tue, Nov 17, 2015 at 05:45:06PM +0100, Daniel Vetter wrote: > On Wed, Nov 04, 2015 at 03:34:54PM +0530, Sagar Arun Kamble wrote: > > RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 > > setup registers. If those are not setup Driver should not enable RC6. > > For

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On Tue, Nov 17, 2015 at 04:54:50PM +, Tvrtko Ursulin wrote: > > On 17/11/15 16:39, Daniel Vetter wrote: > >On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>In the following commit: > >> > >> commit

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On 17/11/15 17:32, Tvrtko Ursulin wrote: On 17/11/15 17:24, Tvrtko Ursulin wrote: On 17/11/15 17:08, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:54:50PM +, Tvrtko Ursulin wrote: On 17/11/15 16:39, Daniel Vetter wrote: On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array

Hi Danilo, Em Tue, 28 Jul 2015 16:45:16 -0300 Danilo Cesar Lemes de Paula escreveu: > The "highlight" code is very sensible to the order of the hash keys, > but the order of the keys cannot be predicted on Perl. It generates > faulty DocBook entries like: > -

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_core: Prefer CLOCK_MONOTONIC_RAW

On Tue, Nov 17, 2015 at 12:24:13PM +0200, Joonas Lahtinen wrote: > CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock > used for timing execution of tests. > > Cc: Thomas Wood > Cc: Chris Wilson > Signed-off-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 5/5] drm/core: Fix old_fb handling in pan_display_atomic.

On Tue, 17 Nov 2015, Daniel Vetter wrote: > On Wed, Nov 11, 2015 at 11:29:11AM +0100, Maarten Lankhorst wrote: >> From: Maarten Lankhorst >> >> Signed-off-by: Maarten Lankhorst > > Needs "Don't touch

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Don't clobber the addfb2 ioctl params

On Tue, Nov 17, 2015 at 01:04:21PM +0200, Ville Syrjälä wrote: > On Tue, Nov 17, 2015 at 10:47:06AM +0100, Daniel Vetter wrote: > > On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > We try to

Re: [Intel-gfx] [PATCH i-g-t] Add dmesg capture and dumping to tests and a test for it.

On ti, 2015-11-17 at 13:05 +, Thomas Wood wrote: > On 16 November 2015 at 13:22, Joonas Lahtinen > wrote: > > +static void _igt_kmsg_capture_dump(void) > > +{ > > > > + //fputs(strchr(igt_kmsg_capture_dump_buf, ';') + 1, > > stderr); > > This

[Intel-gfx] [drm-intel:drm-intel-next-queued 0/1] warning: (DRM_I915) selects STOP_MACHINE which has unmet direct dependencies (SMP && ..)

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: e64e6bd0f46c78b53b236474f59bd1290b834c89 commit: 5bab6f60cb4d1417ad7c599166bcfec87529c1a2 [0/1] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell config: x86_64-randconfig-x011-11162304 (attached

Re: [Intel-gfx] [PATCH 12/12] drm/i915/skl: Remove unused suspend and resume callbacks

On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > Signed-off-by: Patrik Jakobsson Reviewed-by: Imre Deak > --- >  drivers/gpu/drm/i915/i915_drv.c | 17 - >  1 file changed, 17 deletions(-) > > diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Allow unready gpu to be reset on gen8

On Mon, Nov 02, 2015 at 11:25:08AM +0200, Mika Kuoppala wrote: > Gen9 has had demonstrated cases where forcing a not ready gpu > into reset has caused system hang [1]. > > Gen8 has never to this date demonstrated such behaviour. > > In our CI tests there have been two cases of bsw ending in a

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Make prepare_plane_fb fully interruptible."

On Mon, Nov 02, 2015 at 05:38:07PM +0200, Ville Syrjälä wrote: > On Mon, Nov 02, 2015 at 01:41:03PM +0100, Maarten Lankhorst wrote: > > Hey, > > > > Op 30-10-15 om 22:06 schreef ville.syrj...@linux.intel.com: > > > From: Ville Syrjälä > > > > > > This reverts

Re: [Intel-gfx] [PATCH v3] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed

On Tue, Nov 17, 2015 at 05:24:01PM +, Tvrtko Ursulin wrote: > > On 17/11/15 17:08, Daniel Vetter wrote: > >On Tue, Nov 17, 2015 at 04:54:50PM +, Tvrtko Ursulin wrote: > >> > >>On 17/11/15 16:39, Daniel Vetter wrote: > >>>On Tue, Nov 17, 2015 at 04:27:12PM +, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH] drm/i915: Unpin framebuffers when crtc is deconfigured.

On Wed, Nov 04, 2015 at 02:43:31PM +0100, Maarten Lankhorst wrote: > When setcrtc is called and steals the last connector away from a crtc > it's turned off because it can't stay configured without connectors. > > The framebuffer is still preserved however, and that causes troubles > in the IGT

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On Wed, Nov 04, 2015 at 05:47:12PM -0200, Paulo Zanoni wrote: > 2015-11-04 17:25 GMT-02:00 Imre Deak : > > After Damien's D3 fix I started to get runtime suspend residency for the > > first time and that revealed a breakage on the set_caching IOCTL path > > that accesses the

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commit: 76dc3769d7c3 ("drm/i915: Don't clobber the addfb2 ioctl params") from the drm-intel-fixes tree and commit: dcb1394e74e3 ("drm/i915: On fb alloc failure, unref

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On Tue, 2015-11-17 at 22:38 +, Chris Wilson wrote: > On Tue, Nov 17, 2015 at 11:16:09PM +0100, Daniel Vetter wrote: > > On Thu, Nov 5, 2015 at 12:56 PM, Chris Wilson > o.uk> wrote: > > > The tricky part is reviewing the i915_gem_release_mmap() callers > > > to > > >

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On Tue, Nov 17, 2015 at 11:16:09PM +0100, Daniel Vetter wrote: > On Thu, Nov 5, 2015 at 12:56 PM, Chris Wilson > wrote: > > The tricky part is reviewing the i915_gem_release_mmap() callers to > > ensure that they have the right barrier. If you make > >

Re: [Intel-gfx] [PATCH 4/4] drm/i915: PSR: Mask LPSP hw tracking back again.

On Mon, 2015-11-16 at 17:27 -0200, Paulo Zanoni wrote: > 2015-11-11 19:20 GMT-02:00 Rodrigo Vivi : > > At the beginning it was masked to allow PSR at all. > > Than it got removed later by my > > commit 09108b90f040 ("drm/i915: PSR: Remove Low Power HW tracking > > mask.")

Re: [Intel-gfx] [PATCH v2 2/4] scripts/kernel-doc: Replacing highlights hash by an array

On Tue, 17 Nov 2015 13:29:49 -0200 Mauro Carvalho Chehab wrote: > The enclosed patch should do the trick. I tested it with perl 5.10 and > perl 5.22 it worked fine with both versions. Indeed it seems to work - thanks! Applied to the docs tree, I'll get it upstream

Re: [Intel-gfx] [PATCH] drm/i915: fix handling of the disable_power_well module option

On ti, 2015-11-17 at 13:46 +0100, Patrik Jakobsson wrote: > On Wed, Nov 11, 2015 at 07:03:54PM +0200, Imre Deak wrote: > > When this option is 0 (so the power well support is disabled) we are > > supposed to enable all power wells once and don't disable them unless we > > system suspend the

[Intel-gfx] i915 Skylake: "Invalid ROM contents"

Typing: # cat /sys/devices/pci:00/:00:02.0/rom Provokes: i915 :00:02.0: Invalid ROM contents This is on a Dell XPS 13 9350 (Skylake). This is 4.3.0 plus some wireless-next bits. --Andy -- Andy Lutomirski AMA Capital Management, LLC

Re: [Intel-gfx] [PATCH v2 00/12] Skylake DMC/DC-state fixes and redesign

On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > This v2 of the series is rebased on top of a new series from Imre [1] > and contains a few new patches and reordering. > > These patches should sit on top of the DMC redesign patches from > Animesh/Imre [2] which in turn depends on

Re: [Intel-gfx] [PATCH 0/6] Fixing sink count related detection over

On Mon, Nov 02, 2015 at 06:25:10PM +0530, Shubhangi Shrivastava wrote: > This patch set cleans up DP detection logic to bring all DPCD > operations at one place and to create a clear demarcation > between handling of long and short pulses. This simplifies > fixing of sink count related detection

Re: [Intel-gfx] [PATCH v4 10/12] drm/i915/gen9: Turn DC handling into a power well

On ma, 2015-11-16 at 16:20 +0100, Patrik Jakobsson wrote: > Handle DC off as a power well where enabling the power well will > prevent > the DMC to enter selected DC states (required around modesets and Aux > A). Disabling the power well will allow DC states again. For now the > highest DC state

Re: [Intel-gfx] [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL

On ti, 2015-11-17 at 20:00 +0100, Daniel Vetter wrote: > On Wed, Nov 04, 2015 at 05:47:12PM -0200, Paulo Zanoni wrote: > > 2015-11-04 17:25 GMT-02:00 Imre Deak : > > > After Damien's D3 fix I started to get runtime suspend residency > > > for the > > > first time and that

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences

On ke, 2015-11-04 at 19:24 +0200, Imre Deak wrote: > From: Damien Lespiau > > Before this patch, we used the intel_display_power_{get,put} > functions > to make sure the PW1 and Misc I/O power wells were enabled all the > time while LCPLL was enabled. We called a get()

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commit: 76dc3769d7c3 ("drm/i915: Don't clobber the addfb2 ioctl params") from the drm-intel-fixes tree and commit: 528344410b5c ("drm: Pass the user drm_mode_fb_cmd2 as

Re: [Intel-gfx] [PATCH 0/6] Fixing sink count related detection over

On Wednesday 18 November 2015 01:23 AM, Daniel Vetter wrote: On Mon, Nov 02, 2015 at 06:25:10PM +0530, Shubhangi Shrivastava wrote: This patch set cleans up DP detection logic to bring all DPCD operations at one place and to create a clear demarcation between handling of long and short

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect

On Tue, 2015-11-17 at 11:47 +0530, Shubhangi Shrivastava wrote: > > On Monday 16 November 2015 07:10 PM, Ander Conselvan De Oliveira wrote: > > On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote: > > > This patch moves probing for panel, DPCD read etc to another > > > function

Re: [Intel-gfx] [PATCH 5/5] drm/core: Fix old_fb handling in pan_display_atomic.

On Wed, Nov 11, 2015 at 11:29:11AM +0100, Maarten Lankhorst wrote: > From: Maarten Lankhorst > > Signed-off-by: Maarten Lankhorst Needs "Don't touch plane->old_fb/fb without having the right locks held." like the previous

Re: [Intel-gfx] [PATCH 0/6] drm: Give crtcs and planes actual names

On Thu, Nov 12, 2015 at 06:52:20PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I got sick and tired of staring at the line noise produced by drm.debug=0x1e, > so I decided to give the crtcs and planes human readable names. Each driver >

Re: [Intel-gfx] [PATCH 3/5] drm/atomic: add a drm_atomic_clean_old_fb helper.

On Wed, Nov 11, 2015 at 11:29:09AM +0100, Maarten Lankhorst wrote: > From: Maarten Lankhorst > > This is useful for all the boilerplate code about cleaning old_fb. > --- > drivers/gpu/drm/drm_atomic.c | 58 > ++-- >

Re: [Intel-gfx] [PATCH 0/6] drm: Give crtcs and planes actual names

On Tue, 17 Nov 2015, Daniel Vetter wrote: > On Thu, Nov 12, 2015 at 06:52:20PM +0200, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> I got sick and tired of staring at the line noise produced by drm.debug=0x1e, >> so I decided

Re: [Intel-gfx] [PATCH 1/8] drm: Add crtc->name and use it in debug messages

On Fri, Nov 13, 2015 at 01:03:48PM +0200, Ville Syrjälä wrote: > On Fri, Nov 13, 2015 at 12:18:24PM +0200, Jani Nikula wrote: > > On Thu, 12 Nov 2015, ville.syrj...@linux.intel.com wrote: > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > > index 24c5434..ea00a69 100644

[Intel-gfx] [PATCH i-g-t] lib/igt_core: Prefer CLOCK_MONOTONIC_RAW

CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock used for timing execution of tests. Cc: Thomas Wood Cc: Chris Wilson Signed-off-by: Joonas Lahtinen --- lib/igt_core.c | 9 +++-- 1 file

Re: [Intel-gfx] [PATCH i-g-t] Add dmesg capture and dumping to tests and a test for it.

On ma, 2015-11-16 at 14:06 +, Chris Wilson wrote: > On Mon, Nov 16, 2015 at 03:22:23PM +0200, Joonas Lahtinen wrote: > > Cc: Thomas Wood > > Cc: Chris Wilson > > Cc: Damien Lespiau > > Signed-off-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 2/5] drm/core: Fix old_fb handling in drm_mode_atomic_ioctl.

On Wed, Nov 11, 2015 at 11:29:08AM +0100, Maarten Lankhorst wrote: > From: Maarten Lankhorst > > plane_mask should be cleared inside the retry loop, > because it gets reset on every retry. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Don't clobber the addfb2 ioctl params

On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We try to convert the old way of of specifying fb tiling (obj->tiling) > into the new fb modifiers. We store the result in the passed in mode_cmd > structure.

Re: [Intel-gfx] [PATCH 1/5] drm/core: Set legacy_cursor_update in drm_atomic_helper_disable_plane.

On Wed, Nov 11, 2015 at 11:29:07AM +0100, Maarten Lankhorst wrote: > From: Maarten Lankhorst > > legacy_cursor_update was being set in restore_fbdev_mode_atomic which was > probably unintended. Fix this by only setting it in the function that needs > it. > >

[Intel-gfx] [PATCH 8/8] drm/i915: Remove commit_plane function pointer.

With sprites, cursors and primary planes taking the atomic state this is now unused. It's removed in a separate commit to allow a revert. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +--- drivers/gpu/drm/i915/intel_drv.h

[Intel-gfx] [PATCH 7/8] drm/i915: Use plane state for primary plane updates.

Pass in the atomic states to allow for proper updates. This removes uses of intel_crtc->config and direct access to plane->state. This breaks the last bit of kgdboc, but that appears to be dead code. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 4/8] drm/i915: Only rotate cursor base when the cursor is visible.

There is a if branch in i9xx_update_cursor that may get taken otherwise, resulting in cursor not being made invisible accidentally. Cc: sta...@vger.kernel.org Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 5/8] drm/i915: Make disable_cursor_plane similar to commit_cursor_plane.

Update cursor_bo and cursor_addr after being called. This is required to make commit_cursor_plane take a crtc_state and a plane_state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 4 1 file changed, 4 insertions(+) diff

[Intel-gfx] [PATCH 6/8] drm/i915: Use the plane state for cursor updates.

Cursor planes grab the state from plane->state instead of the state that was passed. The only cursor updates dpme are atomic now, so use the plane_state that's passed in. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 70

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms!

On 11/15/2015 06:32 AM, Chris Wilson wrote: When waiting for high frequency requests, the finite amount of time required to set up the irq and wait upon it limits the response rate. By busywaiting on the request completion for a short while we can service the high frequency waits as quick as

  1   2   >