Re: [Intel-gfx] [PATCH 10/14] drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant

Patches 1 to 10 merged on dinq last week. Thanks for patches and reviews and sorry for the delayed update. On Wed, Sep 7, 2016 at 12:50 AM, Mika Kahola wrote: > Reviewed-by: Mika Kahola > > On Fri, 2016-09-02 at 22:05 +0300, Pandiyan, Dhinakaran

Re: [Intel-gfx] [PATCH] drm/i915: Add support for Kabylake to function obtaining shared PLL

Patch merged to dinq. Thanks for the patch. On Mon, Sep 12, 2016 at 10:02 PM, Rodrigo Vivi wrote: > Reviewed-by: Rodrigo Vivi > > On Mon, Sep 12, 2016 at 6:04 PM, Manasi Navare > wrote: >> This adds support for KBL in

Re: [Intel-gfx] [PATCH i-g-t v2 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

On 2016-09-13 07:03 AM, Chris Wilson wrote: On Mon, Sep 12, 2016 at 06:08:30PM -0400, robert.f...@collabora.com wrote: From: Robert Foss Base functions to help testing the Sync File Framework (explicit fencing mechanism ported from Android). These functions allow

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Looks good to me. Reviewed-by: Dhinakaran Pandiyan On Tue, 2016-09-13 at 10:38 -0300, Paulo Zanoni wrote: > Ever since I started working on FBC I was already aware that FBC can > really amplify the FIFO underrun symptoms. On systems where FIFO > underruns were

Re: [Intel-gfx] [PATCH v4 00/22] drm/i915: Organize most GPU features by platform

All patches reviewed and merged to dinq last week. Thanks for the patches and sorry by the delayed update. On Wed, Aug 17, 2016 at 12:30 PM, Carlos Santa wrote: > - organize most GPU features so that they are easy to group by platforms. >It seems some of the ground

Re: [Intel-gfx] [PATCH v6 1/4] drm/i915: Store port enum in intel_encoder

On Mon, 2016-09-12 at 18:00 -0700, Dhinakaran Pandiyan wrote: > Storing the port enum in intel_encoder makes it convenient to know the > port attached to an encoder. Moving the port information up from > intel_digital_port to intel_encoder avoids unecessary intel_digital_port > access and handles

[Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

I was looking at some wait_for() timeouts on a slow system, with lots of debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were mishandling the timeout, I tried to ensure that we loop at least once after first testing COND. However, the double test of COND either side of the timeout

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

Em Qua, 2016-09-07 às 12:17 -0400, Lyude escreveu: > I'm not sure that kbl has this either. The kbl machine I've been > working with thus-far has passed a few modesetting stress tests with > the chameleon, and I don't have anything trying to control sagv stuff > on it. > > This being said though

[Intel-gfx] [PATCH i-g-t v3 02/13] tests/sw_sync: Add sw_sync test

From: Robert Foss Add initial tests for sw_sync. Signed-off-by: Robert Foss Signed-off-by: Gustavo Padovan Reviewed-by: Eric Engestrom --- tests/Makefile.sources | 1 + tests/sw_sync.c

[Intel-gfx] [PATCH i-g-t v3 06/13] tests/sw_sync: Add subtest test_sync_wait

From: Robert Foss This subtest verifies that waiting on fences works properly. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 38 ++ 1 file changed, 38

[Intel-gfx] [PATCH i-g-t v3 07/13] tests/sw_sync: Add subtest test_sync_merge

From: Robert Foss Add subtest test_sync_merge that tests merging fences and the validity of the resulting merged fence. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 67

[Intel-gfx] [PATCH i-g-t v3 09/13] tests/sw_sync: Add subtest test_sync_multi_consumer

From: Robert Foss This subtest verifies the access ordering of multiple consumer threads. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 103

[Intel-gfx] [PATCH i-g-t v3 11/13] tests/sw_sync: Add subtest test_sync_random_merge

From: Robert Foss This subtest verifies that creating many timelines and merging random fences from each timeline with eachother results in merged fences that are fully functional. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom

[Intel-gfx] [PATCH i-g-t v3 12/13] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

From: Robert Foss This subtest verifies that waiting, timing out on a wait and that counting fences in various states works. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 66

[Intel-gfx] [PATCH i-g-t v3 13/13] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

From: Robert Foss This subtest runs a single consumer thread and multiple producer thread that are synchronized using multiple timelines. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 139

[Intel-gfx] [PATCH i-g-t v3 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

From: Robert Foss Base functions to help testing the Sync File Framework (explicit fencing mechanism ported from Android). These functions allow you to create, use and destroy timelines and fences. Signed-off-by: Robert Foss Signed-off-by:

[Intel-gfx] [PATCH i-g-t v3 00/13] Implement sw_sync test

From: Robert Foss This series implements the sw_sync test and the lib/sw_sync helper functions for said test. Gustavo Padovans sw_sync series was just de-staged in gregkh-staging/staging-next [1], and this test is targeted at verifying the functionality implemented in

[Intel-gfx] [PATCH i-g-t v3 03/13] tests/sw_sync: Add subtest test_alloc_fence

From: Robert Foss Add subtest alloc_fence that verifies that it's possible to allocate a fence on a timeline. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 16 1 file

[Intel-gfx] [PATCH i-g-t v3 08/13] tests/sw_sync: Add subtest test_sync_merge_same

From: Robert Foss This subtest verifies merging a fence with itself does not fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 37 - 1 file changed,

[Intel-gfx] [PATCH i-g-t v3 04/13] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline

From: Robert Foss This subtests tests that creating fences on negative timelines fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t v3 05/13] tests/sw_sync: Add subtest test_alloc_merge_fence

From: Robert Foss This subtest verifies that merging two fences works in the simples possible case. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 23 +++ 1 file

[Intel-gfx] [PATCH i-g-t v3 10/13] tests/sw_sync: Add subtest test_sync_multi_consumer_producer

From: Robert Foss This test verifies that stressing the kernel by creating multiple consumer/producer threads that wait on a single timeline to be incremented by another conumer/producer thread does not fail. And that the order amongst the threads is maintained.

[Intel-gfx] [PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

The refcount of a fence should be increased whenever it is added to a merged fence, since it will later be decreased when the merged fence is destroyed. Failing to do so will cause the original fence to be freed if the merged fence gets freed, but other places still referencing won't know about

[Intel-gfx] [PATCH] drm/i915: Standardize port type for DVO encoders

Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to

[Intel-gfx] [PATCH i-g-t] tests/sw_sync: Add subtest test_sync_expired_merge

This test creates an already expired fence, then creates a merged fence out of that expired one (passed twice to the merge operation), and finally closes the merged fence. It shows that if the refcounts are wrong on the original expired fence, it might get freed while still in use. Usually a

Re: [Intel-gfx] [PATCH 5/8] drm/i915/gen9: minimum scanlines for Y tile is not always 4

Em Qua, 2016-09-07 às 19:03 -0400, Lyude escreveu: > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote: > > > > During watermarks calculations, this value is used in 3 different > > places. Only one of them was not using a hardcoded 4. Move the code > > up > > so everybody can benefit from

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Hi. Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek: > I have > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > Integrated Graphics Controller (rev 03) 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor

[Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Hi! I have 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1 in 10 resumes?) get in state where primary monitor (DVI) is dead (in powersave) and all windows move to

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Hi! > I have > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > Integrated Graphics Controller (rev 03) > > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1 > in 10 resumes?) get in state where primary monitor (DVI) is dead (in > powersave) and all

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

Em Ter, 2016-09-13 às 20:40 +0100, Chris Wilson escreveu: > I was looking at some wait_for() timeouts on a slow system, with lots > of > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > mishandling the timeout, I tried to ensure that we loop at least once > after first testing

[Intel-gfx] [PATCH 7/9] drm/i915/gen9: fix the watermark res_blocks value

We forgot the "res_blocks += y_tile_minimum" that's described on step V of our documentation. Again, this should only affect the Y tiling cases. It looks like the relevant code was introduced in 0fda65680e92, but there's always the possibility that it matched our specification when it was

[Intel-gfx] [PATCH 6/9] drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations

The confusing thing is that plane_blocks_per_line is listed as part of the method 2 calculation but is also used for other things. We calculated it in two different places and different ways: one inside skl_wm_method2() and the other inside skl_compute_plane_wm(). The skl_wm_method2()

[Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

Hi Here's the series with the reviews implemented. There's a new patch, based on the additional issue spotted by Lyude. Thanks for all the reviews, Paulo Paulo Zanoni (9): drm/i915: SAGV is not SKL-only, so rename a few things drm/i915: introduce intel_has_sagv() drm/i915/kbl: KBL also

[Intel-gfx] [PATCH 1/9] drm/i915: SAGV is not SKL-only, so rename a few things

The plan is to introduce intel_has_sagv() and then use it to discover which platforms actually support it. I thought about keeping the functions with their current skl names, but found two problems: (i) skl_has_sagv() would become a very confusing name, and (ii) intel_atomic_commit_tail() doesn't

[Intel-gfx] [PATCH 5/9] drm/i915/gen9: minimum scanlines for Y tile is not always 4

During watermarks calculations, this value is used in 3 different places. Only one of them was not using a hardcoded 4. Move the code up so everybody can benefit from the actual value. This should only help on situations with Y tiling + 90/270 rotation + 1 or 2 bpp or NV12. Signed-off-by: Paulo

[Intel-gfx] [PATCH 9/9] drm/i915/gen9: fail the modeset instead of WARNing on unsuported config

Now that this code is part of the compute stage we can return -EINVAL to prevent the modeset instead of giving a WARN and trying anyway. Reported-by: Lyude Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2

[Intel-gfx] [PATCH 3/9] drm/i915/kbl: KBL also needs to run the SAGV code

According to BSpec, it's the "core CPUs" that need the code, which means SKL and KBL, but not BXT. I don't have a KBL to test this patch on it. v2: Only SKL should have I915_SAGV_NOT_CONTROLLED. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_pm.c | 14

[Intel-gfx] [PATCH 2/9] drm/i915: introduce intel_has_sagv()

And use it to move knowledge about the SAGV-supporting platforms from the callers to the SAGV code. We'll add more platforms to intel_has_sagv(), so IMHO it makes more sense to move all this to a single function instead of patching all the callers every time we add SAGV support to a new platform.

[Intel-gfx] [PATCH 8/9] drm/i915/gen9: implement missing case for SKL watermarks calculation

This should affect linear and X tiled planes on really small htotal cases. It doesn't seem to be a very feasible case, but let's implement it since it's on the specification and it's better to have it and never need than not have it and realize we needed it. Reviewed-by: Lyude

[Intel-gfx] [PATCH 4/9] drm/i915/gen9: fix the WaWmMemoryReadLatency implementation

Bspec says: "The mailbox response data may not account for memory read latency. If the mailbox response data for level 0 is 0us, add 2 microseconds to the result for each valid level." This means we should only do the +2 in case wm[0] == 0, not always. So split the sanitizing

[Intel-gfx] [PATCH v17 4/5] drm/i915/dp: Enable Upfront link training on DDI platforms

To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel can support more lanes. To address these

[Intel-gfx] [PATCH v5 1/5] drm/i915: Fallback to lower link rate and lane count during link training

According to the DisplayPort Spec, in case of Clock Recovery failure the link training sequence should fall back to the lower link rate followed by lower lane count until CR succeeds. On CR success, the sequence proceeds with Channel EQ. In case of Channel EQ failures, it should fallback to lower

[Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

From: Jim Bride Add upfront link training to intel_dp_mst_mode_valid() so that we know topology constraints before we validate the legality of modes to be checked. v3: * Reset the upfront values but dont unset the EDID for MST. (Manasi) v2: * Rebased on new revision

[Intel-gfx] [PATCH v2 3/5] drm/i915: Change the placement of some static functions in intel_dp.c

These static helper functions are required to be used within upfront link training related functions so they need to be placed at the top of the file. It also changes macro dev to dev_priv. v2: * Dont move around functions declared in intel_drv.h (Rodrigo Vivi) Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH 0/5] Remaining patches for upfront link training on DDI platforms

This patch series includes some of the remaining patches to enable upfront link training on DDI platforms for DP SST and MST. They are based on some of the patches submitted earlier by Ander and Durgadoss. The upfront link training had to be factored out of long pulse hanlder because of deadlock

[Intel-gfx] [PATCH v3 2/5] drm/i915: Remove the link rate and lane count loop in compute config

While configuring the pipe during modeset, it should use max clock and max lane count and reduce the bpp until the requested mode rate is less than or equal to available link BW. This is required to pass DP Compliance. v3: * Add Debug print if requested mode cannot be supported during modeset

[Intel-gfx] [PATCH] drm/i915: Add ddb size field to device info structure

Adding the ddb size into the devide info will avoid platform checks while computing wm. Suggested-by: Ander Conselvan de Oliveira Signed-off-by: Deepak M --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_pci.c | 5

Re: [Intel-gfx] [PATCH v2 12/14] drm/i915: Remove the link rate and lane count loop in compute config

On Mon, Sep 12, 2016 at 06:14:00PM -0700, Pandiyan, Dhinakaran wrote: > On Thu, 2016-09-08 at 13:02 -0700, Manasi Navare wrote: > > While configuring the pipe during modeset, it should use > > max clock and max lane count and reduce the bpp until > > the requested mode rate is less than or equal

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add ddb size field to device info structure

== Series Details == Series: drm/i915: Add ddb size field to device info structure URL : https://patchwork.freedesktop.org/series/12427/ State : success == Summary == Series 12427v1 drm/i915: Add ddb size field to device info structure

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Standardize port type for DVO encoders

== Series Details == Series: drm/i915: Standardize port type for DVO encoders URL : https://patchwork.freedesktop.org/series/12418/ State : failure == Summary == Series 12418v1 drm/i915: Standardize port type for DVO encoders

[Intel-gfx] ✗ Fi.CI.BAT: failure for SKL/KBL watermark fixes (rev2)

== Series Details == Series: SKL/KBL watermark fixes (rev2) URL : https://patchwork.freedesktop.org/series/12082/ State : failure == Summary == Series 12082v2 SKL/KBL watermark fixes https://patchwork.freedesktop.org/api/1.0/series/12082/revisions/2/mbox/ Test kms_pipe_crc_basic:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only expand COND once in wait_for()

== Series Details == Series: drm/i915: Only expand COND once in wait_for() URL : https://patchwork.freedesktop.org/series/12403/ State : failure == Summary == Series 12403v1 drm/i915: Only expand COND once in wait_for() https://patchwork.freedesktop.org/api/1.0/series/12403/revisions/1/mbox/

[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-buf/sync_file: Always increment refcount when merging fences.

== Series Details == Series: dma-buf/sync_file: Always increment refcount when merging fences. URL : https://patchwork.freedesktop.org/series/12414/ State : failure == Summary == Series 12414v1 dma-buf/sync_file: Always increment refcount when merging fences.

[Intel-gfx] ✓ Fi.CI.BAT: success for Remaining patches for upfront link training on DDI platforms

== Series Details == Series: Remaining patches for upfront link training on DDI platforms URL : https://patchwork.freedesktop.org/series/12425/ State : success == Summary == Series 12425v1 Remaining patches for upfront link training on DDI platforms

Re: [Intel-gfx] [PATCH i-g-t] tools/intel_bios_reader: Dump PSR block from VBT

On Mon, 12 Sep 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Decode the PSR block (9) from VBT. Looks like the same block ID may have > been used for something else in the past, so a version check is also > needed. > > The wakeup times part is

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

On 12/09/16 15:09, Imre Deak wrote: While user space has control over the scheduling priority of its page flipping thread, the corresponding work the driver schedules for MMIO flips always runs with normal scheduling priority. This would hinder an application that wants more stringent

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote: > On 12/09/16 15:09, Imre Deak wrote: > > While user space has control over the scheduling priority of its > > page > > flipping thread, the corresponding work the driver schedules for > > MMIO > > flips always runs with normal scheduling

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

On Tue, Sep 13, 2016 at 11:24:52AM +0100, Tvrtko Ursulin wrote: > > On 12/09/16 15:09, Imre Deak wrote: > >While user space has control over the scheduling priority of its page > >flipping thread, the corresponding work the driver schedules for MMIO > >flips always runs with normal scheduling

Re: [Intel-gfx] [PATCH] drm/i915: Ignore OpRegion panel type except on select machines

On Tue, 13 Sep 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Turns out > commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel > details") has regressed quite a few machines. So it looks like we > can't use the panel type from

Re: [Intel-gfx] [PATCH i-g-t] tools/intel_bios_reader: Dump PSR block from VBT

On Tue, Sep 13, 2016 at 12:51:05PM +0300, Jani Nikula wrote: > On Mon, 12 Sep 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Decode the PSR block (9) from VBT. Looks like the same block ID may have > > been used for something else in the

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

On ti, 2016-09-13 at 11:32 +0100, Chris Wilson wrote: > On Tue, Sep 13, 2016 at 11:24:52AM +0100, Tvrtko Ursulin wrote: > > > > On 12/09/16 15:09, Imre Deak wrote: > > > While user space has control over the scheduling priority of its > > > page > > > flipping thread, the corresponding work the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Ignore OpRegion panel type except on select machines

== Series Details == Series: drm/i915: Ignore OpRegion panel type except on select machines URL : https://patchwork.freedesktop.org/series/12380/ State : failure == Summary == Series 12380v1 drm/i915: Ignore OpRegion panel type except on select machines

Re: [Intel-gfx] [PATCH for v4.8-rc6] drm/i915: fix pointer dereference in intel_dvo_init

On Mon, 12 Sep 2016, Stefan Christ wrote: > Loading the module i915 on my IBM Thinkpad X40 fails in the function > intel_dvo_init(). The function tries to cleanup the struct drm_encoder > that was never initialized. This happens when all intel_dvo_devices > failed to be

Re: [Intel-gfx] [PATCH] Revert "drm/i915/psr: Make idle_frames sensible again"

On Thu, 08 Sep 2016, Jani Nikula wrote: > On Thu, 08 Sep 2016, Ville Syrjälä wrote: >> On Wed, Sep 07, 2016 at 05:42:31PM -0700, Rodrigo Vivi wrote: >>> This reverts commit 1c80c25fb622973dd135878e98d172be20859049. >>> >>> There are panels

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

On Sat, 10 Sep 2016, Dave Gordon wrote: > Thanks, the other things I was thinking of fixing in the remaining files > were generally things like > >if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev)) Is that a real or a made up example? IS_G33() would be redundant. But I'd

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

"Zanoni, Paulo R" writes: > Hi > > Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu: >> In the next patch we want to handle reset directly by a locked waiter >> in >> order to avoid issues with returning before the reset is handled. To >> handle the reset, we

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

On 13/09/16 11:31, Imre Deak wrote: On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote: On 12/09/16 15:09, Imre Deak wrote: While user space has control over the scheduling priority of its page flipping thread, the corresponding work the driver schedules for MMIO flips always runs with

Re: [Intel-gfx] [PATCH v3 8/14] drm/i915/dp: Move max. vswing check to it's own function

On Thu, 08 Sep 2016, Mika Kahola wrote: > This compiler warning is fixed with the next patch of the series. > > drivers/gpu/drm/i915/intel_dp_link_training.c: In function > ‘intel_dp_link_training_clock_recovery’: > drivers/gpu/drm/i915/intel_dp_link_training.c:131:6:

[Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

From: Mahesh Kumar This patch implements new DDB allocation algorithm as per HW team suggestion. This algo takecare of scenario where we allocate less DDB for the planes with lower relative pixel rate, but they require more DDB to work. It also takes care of enabling

Re: [Intel-gfx] [PATCH 4/8] drm/i915/gen9: fix the WaWmMemoryReadLatency implementation

Op 07-09-16 om 02:52 schreef Paulo Zanoni: > Bspec says: > "The mailbox response data may not account for memory read latency. >If the mailbox response data for level 0 is 0us, add 2 microseconds >to the result for each valid level." > > This means we should only do the +2 in case wm[0]

Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

Op 13-09-16 om 14:15 schreef Kumar, Mahesh: > From: Mahesh Kumar > > This patch implements new DDB allocation algorithm as per HW team > suggestion. This algo takecare of scenario where we allocate less DDB > for the planes with lower relative pixel rate, but they require

Re: [Intel-gfx] [PATCH i-g-t v2 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

On Mon, Sep 12, 2016 at 06:08:30PM -0400, robert.f...@collabora.com wrote: > From: Robert Foss > > Base functions to help testing the Sync File Framework (explicit fencing > mechanism ported from Android). > These functions allow you to create, use and destroy

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Ignore OpRegion panel type except on select machines

On Tue, Sep 13, 2016 at 10:49:50AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Ignore OpRegion panel type except on select machines > URL : https://patchwork.freedesktop.org/series/12380/ > State : failure > > == Summary == > > Series 12380v1 drm/i915: Ignore OpRegion

Re: [Intel-gfx] [PATCH igt v2] tests/kms_cursor_legacy: Boost timing sensitive subtests to RT prio

On ti, 2016-09-13 at 08:38 +0100, Chris Wilson wrote: > On Mon, Sep 12, 2016 at 11:57:54PM +0300, Imre Deak wrote: > > On Mon, 2016-09-12 at 21:04 +0100, Chris Wilson wrote: > > > On Mon, Sep 12, 2016 at 05:47:57PM +0300, Imre Deak wrote: > > > > Even in an otherwise quiescent system there may be

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

Mika Kuoppala writes: > "Zanoni, Paulo R" writes: > >> Hi >> >> Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu: >>> In the next patch we want to handle reset directly by a locked waiter >>> in >>> order to avoid issues with

Re: [Intel-gfx] [PATCH v3 3/9] drm/i915/skl: New ddb allocation algorithm

Hi, It seems I missed one condition while setting enable bit for WM's, because of which It's not enabling WM level-0 & you are observing flickers. I'll upload updated patch. On Monday 12 September 2016 06:41 PM, Maarten Lankhorst wrote: Hey, Op 09-09-16 om 10:01 schreef Kumar, Mahesh:

Re: [Intel-gfx] [PATCH] drm/i915: Ignore OpRegion panel type on Ivy Bridge + Mobile

On Sun, 11 Sep 2016, Adrien Vergé wrote: > On Terra Mobile Ultrabook 1450 II (Core i5-3337U, i915 devid = 0x166), > the screen is tiled in many 480×320 screens (like a mosaic) since v4.7. > This laptop is simply unusable. > > I have bisected the cause to commit a05628195a0d

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/fbc: disable FBC on FIFO underruns (rev4)

== Series Details == Series: drm/i915/fbc: disable FBC on FIFO underruns (rev4) URL : https://patchwork.freedesktop.org/series/8575/ State : warning == Summary == Series 8575v4 drm/i915/fbc: disable FBC on FIFO underruns https://patchwork.freedesktop.org/api/1.0/series/8575/revisions/4/mbox/

[Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Ever since I started working on FBC I was already aware that FBC can really amplify the FIFO underrun symptoms. On systems where FIFO underruns were harmless error messages, enabling FBC would cause the underruns to give black screens. We recently tried to enable FBC on Haswell and got reports of

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

On Tue, Sep 13, 2016 at 10:38:57AM -0300, Paulo Zanoni wrote: > Ever since I started working on FBC I was already aware that FBC can > really amplify the FIFO underrun symptoms. On systems where FIFO > underruns were harmless error messages, enabling FBC would cause the > underruns to give black

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Sun, 11 Sep 2016, James Hogan wrote: > I've just bisected a similar (same?) problem (slow increase and > decrease of screen brightness with a period of a few seconds) to the > same commit (this is on a Dell XPS 13 laptop) > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee

[Intel-gfx] [PATCH for v4.8-rc6] drm/i915: fix pointer dereference in intel_dvo_init

Loading the module i915 on my IBM Thinkpad X40 fails in the function intel_dvo_init(). The function tries to cleanup the struct drm_encoder that was never initialized. This happens when all intel_dvo_devices failed to be probed in the for loop. The backtrace was: BUG: unable to handle kernel

[Intel-gfx] [PATCH] drm/i915: Ignore OpRegion panel type except on select machines

From: Ville Syrjälä Turns out commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some

Re: [Intel-gfx] [PATCH igt v2] tests/kms_cursor_legacy: Boost timing sensitive subtests to RT prio

On Mon, Sep 12, 2016 at 11:57:54PM +0300, Imre Deak wrote: > On Mon, 2016-09-12 at 21:04 +0100, Chris Wilson wrote: > > On Mon, Sep 12, 2016 at 05:47:57PM +0300, Imre Deak wrote: > > > Even in an otherwise quiescent system there may be user/kernel > > > threads > > > independent of the test that